From nobody Mon Jun 4 13:39:57 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B322130DE2 for ; Mon, 4 Jun 2018 13:39:53 -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_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgFHV5bVQt-P for ; Mon, 4 Jun 2018 13:39:50 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 8329F130DE1 for ; Mon, 4 Jun 2018 13:39:50 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w54KbM73014578 for ; Mon, 4 Jun 2018 21:39:49 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : subject : message-id : mime-version : content-type; s=jan2016.eng; bh=qOysJ2g+H9GfVr9NMryTCbCVtsSJdiGqUWilzk6oRxU=; b=jQc/EkBiNXYWzbkIJnke18DM+Cst98lesVfKOtMOxKIF3u88PAH9m1F4Ok8Qt+T/atIw e7xWPODrC/993dCzBinbioGeML6PEf4T8BZVxJ1iswSO5PhVXOxyCZPXzrOWAtb4HpbM JFlgEMHQXmNLZewcJRyPvKnPBYKQXiKHrkeox9hZ8HB5m6exiakwAoSjgxYdEoheiJvj 2s+V3b8q/M2m3UKdjPocUWxRrexQHcxFTbMazOFpc6hZVH9zkgDKWYB48MWbhQ+Fev2X F+L9uh3SnCv8OkhU41wnae0XSK4T5SDJ2fHMsgrgFcFaUU9BOSb6MiFj6EYLj5ZF5krV Qg== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2jbp6j9ugw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 04 Jun 2018 21:39:49 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w54Kdmab022641 for ; Mon, 4 Jun 2018 16:39:48 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2jbpjwbdec-1 for ; Mon, 04 Jun 2018 16:39:48 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 8A22F20068 for ; Mon, 4 Jun 2018 20:39:48 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1fPwGZ-0007U5-Qh for tls@ietf.org; Mon, 04 Jun 2018 15:39:47 -0500 Date: Mon, 4 Jun 2018 15:39:47 -0500 From: Benjamin Kaduk To: tls@ietf.org Message-ID: <20180604203947.GW13834@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-04_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=43 suspectscore=12 malwarescore=0 phishscore=0 bulkscore=0 spamscore=43 mlxscore=43 mlxlogscore=12 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806040236 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-04_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=44 priorityscore=1501 malwarescore=0 suspectscore=12 phishscore=0 bulkscore=0 spamscore=44 clxscore=1015 lowpriorityscore=0 mlxscore=44 impostorscore=0 mlxlogscore=11 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806040236 Archived-At: Subject: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2018 20:39:54 -0000 Hi folks, I've taken a stab at putting together some security considerations text for draft-ietf-tls-dnssec-chain-extension that reflects my understanding of the current state of affairs. It's in a pull request at https://github.com/tlswg/dnssec-chain-extension/pull/19 , along with Viktor's commit to update the text about the actual DNS records involved (which as far as I can tell seems to improve the technical accuracy of the text), and also inserting a variable-length array that's reserved for future attempts to mitigate the (now-)documented security considerations. I'd be interested to hear what aspects people agree with and disagree with, whether on- or off-list. Thanks, Ben (with no hats) From nobody Mon Jun 4 21:26:32 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5110130DDE for ; Mon, 4 Jun 2018 21:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 XFUmnSNuTEHM for ; Mon, 4 Jun 2018 21:26:29 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BEDC130EA9 for ; Mon, 4 Jun 2018 21:26:29 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 951447A3309 for ; Tue, 5 Jun 2018 04:26:26 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Viktor Dukhovni In-Reply-To: <20180604203947.GW13834@akamai.com> Date: Tue, 5 Jun 2018 00:26:24 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: <5D00366C-1FDA-4852-B4E9-2F556B6FF33E@dukhovni.org> References: <20180604203947.GW13834@akamai.com> To: TLS WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jun 2018 04:26:31 -0000 > On Jun 4, 2018, at 4:39 PM, Benjamin Kaduk = wrote: >=20 > I'd be interested to hear what aspects people agree with and disagree = with, > whether on- or off-list. Looks like a solid proposal to me, especially the updated security = considerations. Thanks! I added two very minor comments on the PR, one correcting a = typo, the other slightly more technical correcting an erroneous NSEC record in the NSEC = denial of existence example. Thanks again... --=20 Viktor. From nobody Tue Jun 5 06:51:20 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B04F130DCA for ; Tue, 5 Jun 2018 06:51:18 -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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waomIa4q9Ay8 for ; Tue, 5 Jun 2018 06:51:14 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 2CE8C130E31 for ; Tue, 5 Jun 2018 06:51:14 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 410Y9m6kbzzDvS; Tue, 5 Jun 2018 15:51:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1528206669; bh=UNxkyfRKzD+yntPq4ckwz0MY8igpsvPzCe/EwOm281g=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=PKGaNBB7K5zagbCniqD/H3W5CHxqdbFREXeWQJseJAL9NBjOMBUw35s3Pw2S8zFI0 pn0S32t7/PGst1r8DeEh9joeZuRzvYkd8n/pH5PgYxt6blgnKE37Svrd4F3BTwMmY3 l7GjH4NlA0wxb40+n+I0ODDNglagqWQ+asOY1HGo= 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 01w5WZzzmy84; Tue, 5 Jun 2018 15:51:05 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 5 Jun 2018 15:51:04 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id CCBAB4FB76B; Tue, 5 Jun 2018 09:51:03 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca CCBAB4FB76B Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C421B418A9B9; Tue, 5 Jun 2018 09:51:03 -0400 (EDT) Date: Tue, 5 Jun 2018 09:51:03 -0400 (EDT) From: Paul Wouters To: Benjamin Kaduk cc: tls@ietf.org In-Reply-To: <20180604203947.GW13834@akamai.com> Message-ID: References: <20180604203947.GW13834@akamai.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jun 2018 13:51:19 -0000 On Mon, 4 Jun 2018, Benjamin Kaduk wrote: Hi Ben, > I've taken a stab at putting together some security considerations text for > draft-ietf-tls-dnssec-chain-extension that reflects my understanding of the > current state of affairs. It's in a pull request at > https://github.com/tlswg/dnssec-chain-extension/pull/19 , along with Viktor's > commit to update the text about the actual DNS records involved (which as > far as I can tell seems to improve the technical accuracy of the text), and > also inserting a variable-length array that's reserved for future attempts > to mitigate the (now-)documented security considerations. Thanks for writing the proposed text. The new opaque Reserved field along with the denial of existence changes you propose addresses all my concerns. One corner case that might be worth mentioning with the proposed DoE text is the odd corner case of hitting a server with a Host header for which it is not configured. You will hit the "default vhost" but you have no appropriate extension data to populate for that hostname. So either the server will return the (cached) TLSA/DoA data of the 'wrong' hostname, or it could just omit the extension. I'd mostly like to say something to prevent an implementation of forgetting this corner case and causing some vulnerability in their code later on by pointing to bogus memory or crashing on dereferencing a NULL. Some nits: If the server supports this extension it performs the appropriate DNS queries, In my PR I had changed this into "obtains the appropriate DNS RRsets", because I envision that TLS servers might not do DNS lookups themselves, but just read this via a file or other method. Eg a cron job that regenerates these hourly for all the hosted domains. It also reduces some fear that all TLS servers suddenly could need to link against a DNSSEC library. They don't if they can just reload a blob from disk regularly to serve up. Similarly: it will need to rebuild is better written as "it will need rebuilt data" "authenticates the chain" That should probably be "validate the chain", but the document has more mixups of validate vs authenticate. In my PR request I had not corrected them in an effort to keep the diff as small as possible. I had modified the examples slightly, so the NSEC example would show a simpler NSEC chain (from www to zzz) instead of the one wrapping around from www to the zone apex. The example quoted is the wrong NSEC record (the one from apex to www.example.com does not show that the _443._tcp.www.example.com does not exist, you need the one from www.example.com to the apex at the end of the zone) I'm not sure what you mean with: validated negative TTL I guess you mean to say the shortest TTL of any data in the chain? But sometimes the negative cache time is larger then the TTL (eg if TTL = 0) Since this is just generic DNS handling, I would probably just write something like "up to the appropriate lifetime" and leave it out of this document. denial of existence RRset Technically that should be "RRsets" since you usually will need more then one RRset to prove this (to disprove existence of the wildcard record) - DNSSEC authentication chain extension from a server, SHOULD use this + DNSSEC authentication chain extension from a server, uses this I'm not sure why the SHOULD was removed here? Since it is describing TLS client behaviour the "uses this" confuses me as I dont know if that means MAY, SHOULD or MUST. + Specifically, the relevant DANE records are included + in the TLS handshake transcript hash, so both sides + possess identical records; I'm not sure why you suggest to add this text. A TLS client might still have cached a valid TLSA records from a previous connection 1 second ago and might decide to not use this information at all. Also, it seems to suggest that the transscript hash protects this data, but it is "protection" using the webpki or proof of lack of MITM, but the data does not need this protecting as it is protected by DNSSEC signatures. + the client remains responsible + for actually performing the domain name validation of + the DANE records. Well, if it just fired up a previous TLS connection, perhaps it will be content with the same pubkey used and skip re-validating this data? I guess we sort of say the same thing due to the lack of a MUST ? + The Reserved field is reserved for future updates to this + document; in particular it is hoped that the issues discussed + in can be addressed. + Implementations of this specification MUST send a zero-length vector Perhaps that last line can be clarified a bit: Implementation not implementing any updates to this document MUST send a zero-length vector This sentence does not parse: "whether or not to the exclusion" This text is a little confusing to me: + certified by the DNS key hierarchy, that the + server does not support DANE authentication The TLS server itself might support "DANE authentication", but there is simply no data. Perhaps say that the server's configured hostname does not support DANE authentication? Thanks again for the write up! Paul From nobody Tue Jun 5 10:27:07 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B26B513111D; Tue, 5 Jun 2018 10:27:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152821962468.19221.8257248977941764928@ietfa.amsl.com> Date: Tue, 05 Jun 2018 10:27:04 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-exported-authenticator-07.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 List-Id: "This is the mailing list 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, 05 Jun 2018 17:27:06 -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 WG of the IETF. Title : Exported Authenticators in TLS Author : Nick Sullivan Filename : draft-ietf-tls-exported-authenticator-07.txt Pages : 12 Date : 2018-06-05 Abstract: This document describes a mechanism in Transport Layer Security (TLS) to provide an exportable proof of ownership of a certificate that can be transmitted out of band and verified by the other party. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-07 https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-authenticator-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-exported-authenticator-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 6 10:32:33 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A30130F83; Wed, 6 Jun 2018 10:32:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152830634989.6264.3566629916218895862@ietfa.amsl.com> Date: Wed, 06 Jun 2018 10:32:29 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-grease-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 List-Id: "This is the mailing list 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, 06 Jun 2018 17:32:30 -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 WG of the IETF. Title : Applying GREASE to TLS Extensibility Author : David Benjamin Filename : draft-ietf-tls-grease-01.txt Pages : 10 Date : 2018-06-06 Abstract: This document describes GREASE (Generate Random Extensions And Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-grease/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-grease-01 https://datatracker.ietf.org/doc/html/draft-ietf-tls-grease-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-grease-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 Wed Jun 6 12:08:47 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D3212F295 for ; Wed, 6 Jun 2018 12:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.951 X-Spam-Level: X-Spam-Status: No, score=-9.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5S2wnGw9GE67 for ; Wed, 6 Jun 2018 12:08:42 -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 17BA0129619 for ; Wed, 6 Jun 2018 12:08:42 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id w23-v6so4682476qkb.8 for ; Wed, 06 Jun 2018 12:08:42 -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; bh=5xObDPTJbs0zoUfW1GLQxTMt0RgbxuAFOt8S7n+dlok=; b=SvsdrLkRIp7Uqv4SXfxdvu0TJugxrQheKR/nBaYM+clQypiJq7zaL0L9MYXbsqTGvu hoapKUbRBJtPkPVoDvYEuwHJxuhNMK2RYR2qikDyczQ+mPlGfkvB8wdDZpe10ZOxdZNS J2+Z9cJ256WKKBNL0MnmWxc3cV9xzBXvCZOJk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=5xObDPTJbs0zoUfW1GLQxTMt0RgbxuAFOt8S7n+dlok=; b=IpfpdinuxqS8xKkVJviMbSfmHYQaIIVEd+UqEFC17M+qsSVE1EMcGsqzJ1nNr4uckc cEGpWq0xAEwLAfeU86MvsB+X+KJvopMbxUASBi0wnVM6vF1Bs8XybXZYVuCFy9q/2RqE OdN5MIZf03CIsNJScr+1AfzQAzxir28eFdwMcj//DTbx+pjhWS//vieVzdxq66tfsZ59 Z88U0gnz7Pe0YLQw6LXQVZpqXAp134wupNdMs89Q6jOCLLmxwyGvYzAsMxZfbh10BJg1 czZOfgcGoxDQhJsAc3epjY1RMSTa+HfE9Jm0Pyoxt7qMZgNEBPyRWOZFxQqv97+UuaFq ClFg== X-Gm-Message-State: APt69E34fgeOCRcAgogtoB8LYVcQ+iUaVsxXl8i9+HYMpEJGeT2BhpoD eFZaKYlFSkHFpn/N/vQs+YxhZ2xJXzE/K2JZ8AEVHwA= X-Google-Smtp-Source: ADUXVKJVuLsAQFvZEsVQMb8w22CrC7rDRW/7r6uYI5Kswdb6+JNAdY9A1ZzBupwIhTgvw+1ZZ4at2iOtdsPVHMnKDW0= X-Received: by 2002:ae9:dc81:: with SMTP id q123-v6mr3831439qkf.318.1528312120638; Wed, 06 Jun 2018 12:08:40 -0700 (PDT) MIME-Version: 1.0 References: <152830634989.6264.3566629916218895862@ietfa.amsl.com> In-Reply-To: <152830634989.6264.3566629916218895862@ietfa.amsl.com> From: David Benjamin Date: Wed, 6 Jun 2018 15:08:28 -0400 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="0000000000000f5e34056dfde566" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-grease-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 06 Jun 2018 19:08:46 -0000 --0000000000000f5e34056dfde566 Content-Type: text/plain; charset="UTF-8" Hi all, Apologies for the probably record time delay in actually updating this thing. I like the graph... apparently -00 was expired for nearly twice as long as it was valid? Oops! Per the discussion from a really really long while ago, I've rebased the document atop TLS 1.3 and added values for the many more bits added in TLS 1.3. Since TLS 1.3 has server-offered extensions, this needed a bit of reorganization. For the one-bit PSK KE values, I borrowed the pattern from draft-bishop-httpbis-grease-00. Let me know if folks have any comments. Additionally, I'm curious what folks thoughts are on the following (not incorporated into the document): 1) "ignore/" is a pretty long ALPN prefix and also might encourage folks to parse out the "ignore/" string. Instead, what do folks think about just using two byte strings. Perhaps the same two byte pattern we're currently doing? 2) This is somewhat of a "how much badly I abuse the registries" thing. :-) I have observed one TLS implementation which just transcribed the registry directly into their source code. This was done all the way down to mapping "Reserved for Private Use" to some dedicated symbol. They successfully ignored the private use value, but the actual unallocated values for each of NamedGroup, HashAlgorithm, and SignatureAlgorithm were unmapped and treated as syntax errors! This was just a single implementation, but it suggests GREASE works better when it's not so obviously allocated in the registry. Of course, not recording the values at all is unreasonable as we must avoid allocating the values for real. What do folks think about leaving them out of the table but instead adding a note in the registry like: "The values 0x0A0A, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A, 0x7A7A, 0x8A8A, 0x9A9A, 0xAAAA, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, and 0xFAFA are used by [[this document]] for testing implementation correctness. They should be left permanently unassigned." An implementor infinitely bad at reading may well still special-case the and defeat all these measures, but that was always the case. Rather, the goal is to find inexpensive ways to lower the failure probability. It seems inexpensive to me, but I don't know how much trouble it would cause for IANA. David On Wed, Jun 6, 2018 at 1:32 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > > Title : Applying GREASE to TLS Extensibility > Author : David Benjamin > Filename : draft-ietf-tls-grease-01.txt > Pages : 10 > Date : 2018-06-06 > > Abstract: > This document describes GREASE (Generate Random Extensions And > Sustain Extensibility), a mechanism to prevent extensibility failures > in the TLS ecosystem. It reserves a set of TLS protocol values that > may be advertised to ensure peers correctly handle unknown values. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-grease/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-grease-01 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-grease-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-grease-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/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000000f5e34056dfde566 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Apologies for the pr= obably record time delay in actually updating this thing. I like the graph.= .. apparently -00 was expired for nearly twice as long as it was valid? Oop= s!

Per the discussion from a really really long wh= ile ago, I've rebased the document atop TLS 1.3 and added values for th= e many more bits added in TLS 1.3.

Since TLS 1.3 h= as server-offered extensions, this needed a bit of reorganization. For the = one-bit PSK KE values, I borrowed the pattern from draft-bishop-httpbis-gre= ase-00.

Let me know if folks have any comments. Ad= ditionally, I'm curious what folks thoughts are on the following (not i= ncorporated into the document):

1) "ignore/&q= uot; is a pretty long ALPN prefix and also might encourage folks to parse o= ut the "ignore/" string. Instead, what do folks think about just = using two byte strings. Perhaps the same two byte pattern we're current= ly doing?

2) This is somewhat of a "how much = badly I abuse the registries" thing. :-) I have observed one TLS imple= mentation which just transcribed the registry directly into their source co= de. This was done all the way down to mapping "Reserved for Private Us= e" to some dedicated symbol. They successfully ignored the private use= value, but the actual unallocated values for each of=C2=A0NamedGroup, Hash= Algorithm, and SignatureAlgorithm were unmapped and treated as syntax error= s!

This was just a single implementation, but it s= uggests GREASE works better when it's not so obviously allocated in the= registry. Of course, not recording the values at all is unreasonable as we= must avoid allocating the values for real. What do folks think about leavi= ng them out of the table but instead adding a note in the registry like:

"The values 0x0A0A, 0x1A1A, 0x2A2A, 0x3A3A, 0x4= A4A, 0x5A5A, 0x6A6A, 0x7A7A, 0x8A8A, 0x9A9A, 0xAAAA, 0xBABA, 0xCACA, 0xDADA= , 0xEAEA, and 0xFAFA are used by [[this document]] for testing implementati= on correctness. They should be left permanently unassigned."
=

An implementor infinitely bad at reading may well still= special-case the and defeat all these measures, but that was always the ca= se. Rather, the goal is to find inexpensive ways to lower the failure proba= bility. It seems inexpensive to me, but I don't know how much trouble i= t would cause for IANA.

David

On Wed, Jun 6, 2018 at 1:32 PM <internet-drafts@ietf.org> wrot= e:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Transport Layer Security WG of the IETF.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Applying GREASE to TLS Extensibility
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Davi= d Benjamin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-tls-grease-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-06-06

Abstract:
=C2=A0 =C2=A0This document describes GREASE (Generate Random Extensions And=
=C2=A0 =C2=A0Sustain Extensibility), a mechanism to prevent extensibility f= ailures
=C2=A0 =C2=A0in the TLS ecosystem.=C2=A0 It reserves a set of TLS protocol = values that
=C2=A0 =C2=A0may be advertised to ensure peers correctly handle unknown val= ues.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-t= ls-grease/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-greas= e-01
https://datatracker.ietf.org/doc/html/= draft-ietf-tls-grease-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-tls-grease-01


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

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

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000000f5e34056dfde566-- From nobody Thu Jun 7 11:35:16 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40241130FCB for ; Thu, 7 Jun 2018 11:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 2ATS8QcUOD7u for ; Thu, 7 Jun 2018 11:35:09 -0700 (PDT) Received: from smtp.ufl.edu (smtp-prod04.osg.ufl.edu [128.227.74.220]) (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 EEE89130FC7 for ; Thu, 7 Jun 2018 11:35:07 -0700 (PDT) X-UFL-GatorLink-Authenticated: authenticated as (<>) with from 10.36.133.35 Received: from exmbxprd04.ad.ufl.edu ([10.36.133.35]) by smtp.ufl.edu (8.14.4/8.14.4/3.0.0) with ESMTP id w57IZ6X0021616 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 7 Jun 2018 14:35:06 -0400 Received: from exmbxprd23.ad.ufl.edu (128.227.145.167) by exmbxprd04.ad.ufl.edu (10.36.133.35) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 7 Jun 2018 14:35:06 -0400 Received: from exmbxprd21.ad.ufl.edu (128.227.145.166) by exmbxprd23.ad.ufl.edu (128.227.145.167) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 7 Jun 2018 14:35:06 -0400 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (207.46.163.51) by exmbxprd21.ad.ufl.edu (128.227.145.166) with Microsoft SMTP Server (TLS) id 15.0.1365.1 via Frontend Transport; Thu, 7 Jun 2018 14:35:06 -0400 Received: from BN6PR22MB0737.namprd22.prod.outlook.com (10.171.179.148) by BN6PR22MB0932.namprd22.prod.outlook.com (10.171.181.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.14; Thu, 7 Jun 2018 18:35:04 +0000 Received: from BN6PR22MB0737.namprd22.prod.outlook.com ([fe80::e57a:ee7e:b3bc:ea15]) by BN6PR22MB0737.namprd22.prod.outlook.com ([fe80::e57a:ee7e:b3bc:ea15%2]) with mapi id 15.20.0841.015; Thu, 7 Jun 2018 18:35:04 +0000 From: "Patton,Christopher J" To: "tls@ietf.org" Thread-Topic: Editorial comments for draft-ietf-tls-subcerts Thread-Index: AQHT/o4XupjU9e8+o0OfkkMv+JBj3w== Date: Thu, 7 Jun 2018 18:35:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2606:4700:ff01:8210:608b:32ec:e29c:f691] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR22MB0932; 7:HkESc5jw4kx7FL3+hNlwIOT1Kpag4jX8w6cNb9sld9Eb6h4ATzUah4MRN5G8lff1qUTMe4yJqzf9pobfJtm2NRQ+ts57KwDTKNbBZfGJDGquY2hbCHVcNqp64cqspJtONIkEIfv83ZhSmLi2A0inhM3jAAYzmMqHA0/LA9QG2ejbuFHKUUmDKz6RcGPqOiLqjIkFhGhLOgvwPy05If7OoiE8Ppj06Quwo8+st6MBv0FhF2sU44enL/7Q8P5yeIS4 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7153060)(7193020); SRVR:BN6PR22MB0932; x-ms-traffictypediagnostic: BN6PR22MB0932: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:BN6PR22MB0932; BCL:0; PCL:0; RULEID:; SRVR:BN6PR22MB0932; x-forefront-prvs: 06968FD8C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39850400004)(39380400002)(366004)(346002)(376002)(53754006)(199004)(189003)(6916009)(99286004)(33656002)(68736007)(2351001)(19627405001)(55016002)(86362001)(8936002)(1730700003)(2900100001)(6116002)(966005)(3280700002)(478600001)(3660700001)(105586002)(486006)(6436002)(5640700003)(606006)(46003)(75432002)(476003)(786003)(316002)(106356001)(14454004)(53936002)(7736002)(236005)(6306002)(74316002)(53336002)(186003)(5250100002)(9686003)(6506007)(5660300001)(81166006)(81156014)(558084003)(54896002)(2906002)(2501003)(8676002)(97736004)(25786009)(6606003)(7696005)(102836004)(88552002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR22MB0932; H:BN6PR22MB0737.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ufl.edu does not designate permitted sender hosts) x-microsoft-antispam-message-info: WefljrKDBN2tNgY3LTHNk5zhNwAV4nV6i+jRitQiZSNSEvS901iwR+buEay7fzK5zXGekFHLLZOXHrrFwTERrNJil1ea7FWTMIeYAt0N7+cPMfwjEU2Qla48rVQ4j29qHfjwG2oPTIrdMFOSYTJL7WhskwVXIQbIgIxysXQIwwEHKZ3C4xnZy8J5qTuWsNaD spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR22MB073781B96DD50AEE77F6C13DC6640BN6PR22MB0737namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: f2a0e8b4-e687-49ac-fd9f-08d5cca56321 X-MS-Exchange-CrossTenant-Network-Message-Id: f2a0e8b4-e687-49ac-fd9f-08d5cca56321 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2018 18:35:04.6154 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0d4da0f8-4a31-4d76-ace6-0a62331e1b84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR22MB0932 X-OriginatorOrg: ufl.edu X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-07_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=950 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806070198 X-UFL-Spam-Level: * Archived-At: Subject: [TLS] Editorial comments for draft-ietf-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2018 18:35:14 -0000 --_000_BN6PR22MB073781B96DD50AEE77F6C13DC6640BN6PR22MB0737namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Another PR with editorial changes: https://github.com/tlswg/tls-subcerts/pull/3 The most significant change is renaming of "DelegatedCredentialParams" to s= imply "Credential". Thanks Christopher Patton --_000_BN6PR22MB073781B96DD50AEE77F6C13DC6640BN6PR22MB0737namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = all,


Another PR with editorial changes:
https://github.com/tlswg/tls= -subcerts/pull/3

The most significant change is renaming of "DelegatedCredentialParams&= quot; to simply "Credential".

Thanks
Christopher Patton

--_000_BN6PR22MB073781B96DD50AEE77F6C13DC6640BN6PR22MB0737namp_-- From nobody Thu Jun 7 13:17:42 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB61130934 for ; Thu, 7 Jun 2018 13:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_zcTDwvlDHi for ; Thu, 7 Jun 2018 13:17:34 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [IPv6:2610:20:6005:13::150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF07E127332 for ; Thu, 7 Jun 2018 13:17:33 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 7 Jun 2018 16:19:02 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.399.0; Thu, 7 Jun 2018 16:17:29 -0400 Received: from [129.6.105.183] (cooper-optiplex-9010.campus.nist.gov [129.6.105.183]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id w57KHN8N011074 for ; Thu, 7 Jun 2018 16:17:23 -0400 To: "tls@ietf.org" From: "David A. Cooper" Message-ID: <7604787b-6356-f447-727f-38d376d30677@nist.gov> Date: Thu, 7 Jun 2018 16:17:31 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-NIST-MailScanner-Information: Archived-At: Subject: [TLS] draft-ietf-tls-grease and RFC 7919 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2018 20:17:38 -0000 I would like to suggest that one additional value be added to the list of GREASE values for named groups. Section 2 of RFC 7919 says:    Codepoints in the "Supported Groups Registry" with a high byte of    0x01 (that is, between 256 and 511, inclusive) are set aside for    FFDHE groups. Section 4 of RFC 7919 says:    If a compatible TLS server receives a Supported Groups extension from    a client that includes any FFDHE group (i.e., any codepoint between    256 and 511, inclusive, even if unknown to the server), and if none    of the client-proposed FFDHE groups are known and acceptable to the    server, then the server MUST NOT select an FFDHE cipher suite. So, it would be helpful in testing this requirement of RFC 7919 if there were one GREASE value for named groups between 261 and 507 (according to https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8, these are the values in the specified range that are currently unassigned). Thank you, David From nobody Thu Jun 7 14:00:52 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEB8130F58 for ; Thu, 7 Jun 2018 14:00:49 -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_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0m-POVfZZcrj for ; Thu, 7 Jun 2018 14:00:46 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 D3D5F130F49 for ; Thu, 7 Jun 2018 14:00:45 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w57Kw2Iw011222; Thu, 7 Jun 2018 22:00:43 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=92Av1cQzxtFuuvYRdXgRhuowsZsZyGnKEByN09Sdn/0=; b=axYfsjckv6i7Le6FLwKxWE8MVRAGgRLFhJZ8OqcsKustT0Z4PuIT4F8OMzCUf8Nx5vJS fp3FTtxonmcuVRLpTDz/RViOoL0qODNkOzJo9deJpYCkj+jvGdrlqWwpsarpvmZ1v8+d Pk6QNit/JmYA3RFtgoXORjhJZUUXwC+akPZBX25fTFx614JxvzP1AzvSpC0uz0nPUUJW xtKguXShcuYNfGFtuUfSXeSHeikuuFQiHLuZw5ABGdR1RRP1DMZvep5G4oS+X+4Cv9Zp 260anYIUknZzGI0uoNPKHcgowQQOdk4CD6NyDqU6Pi+MBAMp1XRRHUE9tm19tY9JT+RJ Yg== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2jf7331a57-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 Jun 2018 22:00:43 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w57Kp28b011572; Thu, 7 Jun 2018 17:00:42 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2jbpjwrxgw-1; Thu, 07 Jun 2018 17:00:42 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 11C832006F; Thu, 7 Jun 2018 21:00:42 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1fR21R-0004ib-46; Thu, 07 Jun 2018 16:00:41 -0500 Date: Thu, 7 Jun 2018 16:00:40 -0500 From: Benjamin Kaduk To: David Benjamin Cc: tls@ietf.org Message-ID: <20180607210040.GA13834@akamai.com> References: <152830634989.6264.3566629916218895862@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-07_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806070221 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-07_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806070222 Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-grease-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2018 21:00:50 -0000 On Wed, Jun 06, 2018 at 03:08:28PM -0400, David Benjamin wrote: > Hi all, > > Apologies for the probably record time delay in actually updating this > thing. I like the graph... apparently -00 was expired for nearly twice as > long as it was valid? Oops! > > Per the discussion from a really really long while ago, I've rebased the > document atop TLS 1.3 and added values for the many more bits added in TLS > 1.3. > > Since TLS 1.3 has server-offered extensions, this needed a bit of > reorganization. For the one-bit PSK KE values, I borrowed the pattern from > draft-bishop-httpbis-grease-00. > > Let me know if folks have any comments. Additionally, I'm curious what > folks thoughts are on the following (not incorporated into the document): > > 1) "ignore/" is a pretty long ALPN prefix and also might encourage folks to > parse out the "ignore/" string. Instead, what do folks think about just > using two byte strings. Perhaps the same two byte pattern we're currently > doing? > > 2) This is somewhat of a "how much badly I abuse the registries" thing. :-) > I have observed one TLS implementation which just transcribed the registry > directly into their source code. This was done all the way down to mapping > "Reserved for Private Use" to some dedicated symbol. They successfully > ignored the private use value, but the actual unallocated values for each > of NamedGroup, HashAlgorithm, and SignatureAlgorithm were unmapped and > treated as syntax errors! > > This was just a single implementation, but it suggests GREASE works better > when it's not so obviously allocated in the registry. Of course, not > recording the values at all is unreasonable as we must avoid allocating the > values for real. What do folks think about leaving them out of the table > but instead adding a note in the registry like: > > "The values 0x0A0A, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A, 0x7A7A, > 0x8A8A, 0x9A9A, 0xAAAA, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, and 0xFAFA are used > by [[this document]] for testing implementation correctness. They should be > left permanently unassigned." > > An implementor infinitely bad at reading may well still special-case the > and defeat all these measures, but that was always the case. Rather, the > goal is to find inexpensive ways to lower the failure probability. It seems > inexpensive to me, but I don't know how much trouble it would cause for > IANA. Unfortunately, (my understanding is that) IANA is moving towards a proper database for codepoints, and prefer to actually have all values matched up with their corresponding metadata; I expect that they would not be happy to do something like this. But, of course, we should actually ask instead of guessing... -Ben From nobody Thu Jun 7 14:06:09 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96DA4130F9A for ; Thu, 7 Jun 2018 14:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAURe1RDWwtC for ; Thu, 7 Jun 2018 14:06:02 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 DB9B8130F89 for ; Thu, 7 Jun 2018 14:06:01 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id i18-v6so11376044qtp.12 for ; Thu, 07 Jun 2018 14:06:01 -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 :cc; bh=Uvi4UUYX/OP3/rZaBlSFVqSMvMMkJb91lorMuAzW/tc=; b=J7qGsWnIHHqyT7oIAeFtN2MmCjp3sU2ltB1+lPseIaB5CfVZ2vqZ4eLoNCa4AUW744 LgQZmolWoFR3DY3JLIS29BBHh59wGSvezodcYUuf6PTOF7/Dv+E9+gVOMMlE01ceYb5n TNRHYHUa+9MygRDwwqC4M+CM/rqS1bfpRLMfA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Uvi4UUYX/OP3/rZaBlSFVqSMvMMkJb91lorMuAzW/tc=; b=P3sgOMkRiZLikU0rr9lkiOGmRIwSMIYIc35jSGYVSWzqX23n0GsRyp74Yf8i3uZpeL O8psEhKIE/06lMcTaRQuZjpWrnU/uL9u2U2zqQ30wCz9H245huUCwWEPiF+ZqQfSaC6R xTjxGa/FEihaxY1U4uw+9LCYA6N6R9xTAUPHtdggkAjy3kordvRfYDelEH3f9nZ6+ZeR wmDoG/tQ8vOnOltvONlspFO+eoG5Sz/e5KCf/lyK68LJapAE2PJYrk/SW7nMAhcOIkFl bh4vuKOibVBNL6H/pnJ5kdmZzOqwKoGr6iUYxdAEJOMwU4DGwuO3lvBCk2+MX/lL15L0 llDA== X-Gm-Message-State: APt69E3JNRSLJfMm+EuHY/7/S62ROmkfeS8PxVIbnqtYnIu0NJYsoAhl Ia0Uc4V/68JfnqiEffUPnfWzI+vCjvbUjQreOb22 X-Google-Smtp-Source: ADUXVKLGa/ibg9DsNyo9GhF5Tt2cTT4Wp/6yk9aC+hri9RUPniZCkLSxK17Xk7hDZajFh9Yq4tY/xbAPEBDumEPuiLU= X-Received: by 2002:a0c:9487:: with SMTP id j7-v6mr3276544qvj.41.1528405560717; Thu, 07 Jun 2018 14:06:00 -0700 (PDT) MIME-Version: 1.0 References: <152830634989.6264.3566629916218895862@ietfa.amsl.com> <20180607210040.GA13834@akamai.com> In-Reply-To: <20180607210040.GA13834@akamai.com> From: David Benjamin Date: Thu, 7 Jun 2018 17:05:47 -0400 Message-ID: To: Benjamin Kaduk Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="0000000000008589fa056e13a679" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-grease-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2018 21:06:07 -0000 --0000000000008589fa056e13a679 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 7, 2018 at 5:00 PM Benjamin Kaduk wrote: > On Wed, Jun 06, 2018 at 03:08:28PM -0400, David Benjamin wrote: > > Hi all, > > > > Apologies for the probably record time delay in actually updating this > > thing. I like the graph... apparently -00 was expired for nearly twice as > > long as it was valid? Oops! > > > > Per the discussion from a really really long while ago, I've rebased the > > document atop TLS 1.3 and added values for the many more bits added in > TLS > > 1.3. > > > > Since TLS 1.3 has server-offered extensions, this needed a bit of > > reorganization. For the one-bit PSK KE values, I borrowed the pattern > from > > draft-bishop-httpbis-grease-00. > > > > Let me know if folks have any comments. Additionally, I'm curious what > > folks thoughts are on the following (not incorporated into the document): > > > > 1) "ignore/" is a pretty long ALPN prefix and also might encourage folks > to > > parse out the "ignore/" string. Instead, what do folks think about just > > using two byte strings. Perhaps the same two byte pattern we're currently > > doing? > > > > 2) This is somewhat of a "how much badly I abuse the registries" thing. > :-) > > I have observed one TLS implementation which just transcribed the > registry > > directly into their source code. This was done all the way down to > mapping > > "Reserved for Private Use" to some dedicated symbol. They successfully > > ignored the private use value, but the actual unallocated values for each > > of NamedGroup, HashAlgorithm, and SignatureAlgorithm were unmapped and > > treated as syntax errors! > > > > This was just a single implementation, but it suggests GREASE works > better > > when it's not so obviously allocated in the registry. Of course, not > > recording the values at all is unreasonable as we must avoid allocating > the > > values for real. What do folks think about leaving them out of the table > > but instead adding a note in the registry like: > > > > "The values 0x0A0A, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A, > 0x7A7A, > > 0x8A8A, 0x9A9A, 0xAAAA, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, and 0xFAFA are > used > > by [[this document]] for testing implementation correctness. They should > be > > left permanently unassigned." > > > > An implementor infinitely bad at reading may well still special-case the > > and defeat all these measures, but that was always the case. Rather, the > > goal is to find inexpensive ways to lower the failure probability. It > seems > > inexpensive to me, but I don't know how much trouble it would cause for > > IANA. > > Unfortunately, (my understanding is that) IANA is moving towards a proper > database > for codepoints, and prefer to actually have all values matched up with > their > corresponding metadata; I expect that they would not be happy to do > something > like this. But, of course, we should actually ask instead of guessing... > I suppose the question is what the database is meant to be used for. I can imagine wanting it to be properly queryable so you can transform it into code. GREASE values should not make their way into code. The whole point is to get code used to the fact that unknown values exist. I can also imagine wanting to make it easier to allocate values mechnically. Then, yeah, you want the GREASE values in there. But the allocations need occasional human input anyway (e.g. 26 and 40), so maybe it's fine not to have those in there in a completely structured way? David --0000000000008589fa056e13a679 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 7,= 2018 at 5:00 PM Benjamin Kaduk <bk= aduk@akamai.com> wrote:
On W= ed, Jun 06, 2018 at 03:08:28PM -0400, David Benjamin wrote:
> Hi all,
>
> Apologies for the probably record time delay in actually updating this=
> thing. I like the graph... apparently -00 was expired for nearly twice= as
> long as it was valid? Oops!
>
> Per the discussion from a really really long while ago, I've rebas= ed the
> document atop TLS 1.3 and added values for the many more bits added in= TLS
> 1.3.
>
> Since TLS 1.3 has server-offered extensions, this needed a bit of
> reorganization. For the one-bit PSK KE values, I borrowed the pattern = from
> draft-bishop-httpbis-grease-00.
>
> Let me know if folks have any comments. Additionally, I'm curious = what
> folks thoughts are on the following (not incorporated into the documen= t):
>
> 1) "ignore/" is a pretty long ALPN prefix and also might enc= ourage folks to
> parse out the "ignore/" string. Instead, what do folks think= about just
> using two byte strings. Perhaps the same two byte pattern we're cu= rrently
> doing?
>
> 2) This is somewhat of a "how much badly I abuse the registries&q= uot; thing. :-)
> I have observed one TLS implementation which just transcribed the regi= stry
> directly into their source code. This was done all the way down to map= ping
> "Reserved for Private Use" to some dedicated symbol. They su= ccessfully
> ignored the private use value, but the actual unallocated values for e= ach
> of NamedGroup, HashAlgorithm, and SignatureAlgorithm were unmapped and=
> treated as syntax errors!
>
> This was just a single implementation, but it suggests GREASE works be= tter
> when it's not so obviously allocated in the registry. Of course, n= ot
> recording the values at all is unreasonable as we must avoid allocatin= g the
> values for real. What do folks think about leaving them out of the tab= le
> but instead adding a note in the registry like:
>
> "The values 0x0A0A, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6= A, 0x7A7A,
> 0x8A8A, 0x9A9A, 0xAAAA, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, and 0xFAFA are= used
> by [[this document]] for testing implementation correctness. They shou= ld be
> left permanently unassigned."
>
> An implementor infinitely bad at reading may well still special-case t= he
> and defeat all these measures, but that was always the case. Rather, t= he
> goal is to find inexpensive ways to lower the failure probability. It = seems
> inexpensive to me, but I don't know how much trouble it would caus= e for
> IANA.

Unfortunately, (my understanding is that) IANA is moving towards a proper d= atabase
for codepoints, and prefer to actually have all values matched up with thei= r
corresponding metadata; I expect that they would not be happy to do somethi= ng
like this.=C2=A0 But, of course, we should actually ask instead of guessing= ...

I suppose the question is what the = database is meant to be used for. I can imagine wanting it to be properly q= ueryable so you can transform it into code. GREASE values should not make t= heir way into code. The whole point is to get code used to the fact that un= known values exist.

I can also imagine wanting to = make it easier to allocate values mechnically. Then, yeah, you want the GRE= ASE values in there. But the allocations need occasional human input anyway= (e.g. 26 and 40), so maybe it's fine not to have those in there in a c= ompletely structured way?

David
--0000000000008589fa056e13a679-- From nobody Thu Jun 7 14:51:14 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB46B130DD2 for ; Thu, 7 Jun 2018 14:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.95 X-Spam-Level: X-Spam-Status: No, score=-9.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMSX0d3pRuAP for ; Thu, 7 Jun 2018 14:51:06 -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 C0CAD130DD1 for ; Thu, 7 Jun 2018 14:51:05 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id d130-v6so7588832qkc.2 for ; Thu, 07 Jun 2018 14:51:05 -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 :cc; bh=sWNw3PgBsTqk0IoXrvSNIE+/POLbT1CBQiVW9iivztY=; b=O5/xEJrHqFKKF6DtcqDAiVOccXC4bHZhjQxfysElJJXYGY7Le2oqmErkR1tGOCkJyN zR4C7bLhFSufWkfve/fEqenCw7OPCr1OYBKhSj9WJ+eJ925ado0IaLVf0n55fSQKUMzb wUTVHA9dxdFfglnzgO/hrSqg+ihUP7lfjdO5M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sWNw3PgBsTqk0IoXrvSNIE+/POLbT1CBQiVW9iivztY=; b=IEco5AyTc+5bXyeNy+m0WTTwf/YlTbqJoIXjB0CZ/PlRHADjyXGffTKQFPtEeu4Gcf +yFm77G4TMgDNh0b7Nq2/xP+g/ELYJl7UFUuQ/SFkteDu3066l03acwWX4lCiOfhrMu6 kWfbGkZZndHQjVK4qfArdo/rUvZEMnt6Ndrq4xAEgQ4sRcXFupuuswhBwZ4zHMmyT7Al DUsSgkAZ4vAfdwT9NKAyr9F3jYpy+S+aQ7taPnSfRXiqd48DI/+G+kC9bKAvkww0FipY TzirAv5unUh0nudsw8npOxDFdBJJZ/FqbqYNSvd7e6pmXGENPv/dAQaUhXMYvSU5JkBf yHtQ== X-Gm-Message-State: APt69E3TOK26N/Am9fGDWYKqLIhsCZfqsO6A6tUGZKrk4ZMiIg6lFVzN b5bPCvteqGIzGrtc0Q0xA89Vii35Gtdl+AGgVplD X-Google-Smtp-Source: ADUXVKK1Az5guso9Lmfce2pYUVIbrseIRDBz08X0e83zF/VECmn51n8IH89281eQ0uF2RtgNwawkbbQflrTdUSYipxI= X-Received: by 2002:ae9:dc81:: with SMTP id q123-v6mr3307533qkf.318.1528408264582; Thu, 07 Jun 2018 14:51:04 -0700 (PDT) MIME-Version: 1.0 References: <7604787b-6356-f447-727f-38d376d30677@nist.gov> In-Reply-To: <7604787b-6356-f447-727f-38d376d30677@nist.gov> From: David Benjamin Date: Thu, 7 Jun 2018 17:50:52 -0400 Message-ID: To: "David A. Cooper" Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000af6cfb056e144788" Archived-At: Subject: Re: [TLS] draft-ietf-tls-grease and RFC 7919 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2018 21:51:11 -0000 --000000000000af6cfb056e144788 Content-Type: text/plain; charset="UTF-8" This value would be kind of weird because this part of RFC 7919 is quite complex. But if there's interest, I don't mind adding some. But I think the TLS 1.2 bits of RFC 7919, particularly the rule you refer to, were a mistake and are best ignored. The benefits of that document are unrealizable to a client. This was pointed out here: https://www.ietf.org/mail-archive/web/tls/current/msg18697.html RFC 7919 mistakenly reused the existing DHE cipher suite values rather than defining new ones. There is no way to safely advertise that you support named FFDHE but not legacy server-selected DHE. A client advertising DHE ciphers with an FFDHE group list, when talking to a legacy pre-7919 server, would get back a random DHE group, when picking a different cipher suite would be preferable. This brings the client back to the same problem as before 7919. Section 3.1 attempts to touch on this and advocates a fallback, conditioned on checking the signature, but this is unsafe. The ServerKeyExchange signature does not include the full ClientHello, just the randoms, so an attacker may have just changed the ClientHello to induce a fallback trigger. The rule you refer to in section 4 appears to be so that, were a client to behave in such an undeployable way, post-7919 servers would be fine because they use the existence of *any* [256, 512) code point as an indicator of FFDHE support. That means a client that does not support RFC 7919 cannot include this GREASE value in its rotation. A client which does support RFC 7919 may find allocations valuable. It would not test that behavior (most likely you have a group in common), but it would test that that behavior did not induce a different bug by recommending servers treat unknown code points special. As that link above noted, we just removed DHE ciphers in Chrome altogether. We generally favor ECDHE anyway, but, if we wanted to revive FFDHE, I expect this problem would have been a deal-breaker. This could have been avoided if RFC 7919 allocated its own cipher suites, but it's long published now and with TLS 1.3 nearly done, we may as well now forget about the 1.2 portions of that spec. David On Thu, Jun 7, 2018 at 4:17 PM David A. Cooper wrote: > I would like to suggest that one additional value be added to the list > of GREASE values for named groups. > > Section 2 of RFC 7919 says: > > Codepoints in the "Supported Groups Registry" with a high byte of > 0x01 (that is, between 256 and 511, inclusive) are set aside for > FFDHE groups. > > Section 4 of RFC 7919 says: > > If a compatible TLS server receives a Supported Groups extension from > a client that includes any FFDHE group (i.e., any codepoint between > 256 and 511, inclusive, even if unknown to the server), and if none > of the client-proposed FFDHE groups are known and acceptable to the > server, then the server MUST NOT select an FFDHE cipher suite. > > > So, it would be helpful in testing this requirement of RFC 7919 if there > were one GREASE value for named groups between 261 and 507 (according to > > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8, > > these are the values in the specified range that are currently unassigned). > > Thank you, > > David > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000af6cfb056e144788 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This value would be kind of weird because this part of RFC= 7919 is quite complex. But if there's interest, I don't mind addin= g some.

But I think the TLS 1.2 bits of RFC 7919, partic= ularly the rule you refer to, were a mistake and are best ignored. The bene= fits of that document are unrealizable to a client. This was pointed out he= re:

RFC 7919 mistakenly reused the existing DHE= cipher suite values rather than defining new ones.=C2=A0There is no way to= safely advertise that you support named FFDHE but not legacy server-select= ed DHE. A client advertising DHE ciphers with an FFDHE group list, when tal= king to a legacy pre-7919 server, would get back a random DHE group, when p= icking a different cipher suite would be preferable. This brings the client= back to the same problem as before 7919.

Section 3.1 attempts to touch on this and advocates a fallback, conditione= d on checking the signature, but this is unsafe. The ServerKeyExchange sign= ature does not include the full ClientHello, just the randoms, so an attack= er may have just changed the ClientHello to induce a fallback trigger.

The rule you refer to in section 4 appears to be so th= at, were a client to behave in such an undeployable way, post-7919 servers = would be fine because they use the existence of any [256, 512) code = point as an indicator of FFDHE support.

That means= a client that does not support RFC 7919 cannot include this GREASE value i= n its rotation. A client which does support RFC 7919 may find allocations v= aluable. It would not test that behavior (most likely you have a group in c= ommon), but it would test that that behavior did not induce a different bug= by recommending servers treat unknown code points special.

<= /div>
As that link above noted, we just removed DHE ciphers in Chr= ome altogether. We generally favor ECDHE anyway, but, if we wanted to reviv= e FFDHE, I expect this problem would have been a deal-breaker. This could h= ave been avoided if RFC 7919 allocated its own cipher suites, but it's = long published now and with TLS 1.3 nearly done, we may as well now forget = about the 1.2 portions of that spec.

Dav= id

On Thu, Jun 7, 2018 at 4:17 PM David A. Cooper <david.cooper@nist.gov> wrote:
I would like to suggest that one additional value be a= dded to the list
of GREASE values for named groups.

Section 2 of RFC 7919 says:

=C2=A0=C2=A0=C2=A0 Codepoints in the "Supported Groups Registry" = with a high byte of
=C2=A0=C2=A0=C2=A0 0x01 (that is, between 256 and 511, inclusive) are set a= side for
=C2=A0=C2=A0=C2=A0 FFDHE groups.

Section 4 of RFC 7919 says:

=C2=A0=C2=A0=C2=A0 If a compatible TLS server receives a Supported Groups e= xtension from
=C2=A0=C2=A0=C2=A0 a client that includes any FFDHE group (i.e., any codepo= int between
=C2=A0=C2=A0=C2=A0 256 and 511, inclusive, even if unknown to the server), = and if none
=C2=A0=C2=A0=C2=A0 of the client-proposed FFDHE groups are known and accept= able to the
=C2=A0=C2=A0=C2=A0 server, then the server MUST NOT select an FFDHE cipher = suite.


So, it would be helpful in testing this requirement of RFC 7919 if there were one GREASE value for named groups between 261 and 507 (according to https://www.ian= a.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8,=
these are the values in the specified range that are currently unassigned).=

Thank you,

David

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000af6cfb056e144788-- From nobody Fri Jun 8 07:07:12 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448E8130E9D for ; Fri, 8 Jun 2018 07:07:10 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nerd.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6d_HMQsRaSa for ; Fri, 8 Jun 2018 07:07:07 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 459C3130EAF for ; Fri, 8 Jun 2018 07:07:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1528466820; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Date:From:To:Cc:Message-Id:In-Reply-To:References:Subject:MIME-Version:Content-Type; l=10850; bh=FQZ9JnCY23RPg+371Vyv1PBc0msbHm3EB6PNCkM9h38=; b=Gy3AjC23rJOTK8O0thcKxk2j2AI6WjFLSIaXUTLT5U43MAb4APV2Es47ajHT0QrR hZN0y6Z8wMWWYGJRoJDATdHiZdbZPECk6hAQt1/MD61QVBrjt5z2klIXfDpCaz0f0Wb SIz9OyZKzsipwcrLF3YOqFFyKT3/wkNgYTTpzk7s= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1528466820797879.1357365290569; Fri, 8 Jun 2018 07:07:00 -0700 (PDT) Date: Fri, 08 Jun 2018 10:07:00 -0400 From: R duToit To: "David Benjamin" Cc: "Benjamin Kaduk" , Message-Id: <163dfb8ceb7.fef8d66b166467.2392907059047091602@nerd.ninja> In-Reply-To: References: <152830634989.6264.3566629916218895862@ietfa.amsl.com> <20180607210040.GA13834@akamai.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_537120_446305796.1528466820792" X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-grease-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 08 Jun 2018 14:07:10 -0000 ------=_Part_537120_446305796.1528466820792 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit > GREASE values should not make their way into code. The whole point is to get code used to the fact that unknown values exist. The GREASE mechanism is useful, but it will definitely make its way into code and become ossified itself. Example: https://github.com/salesforce/ja3 --Roelof ---- On Thu, 07 Jun 2018 17:05:47 -0400 David Benjamin <davidben@chromium.org> wrote ---- On Thu, Jun 7, 2018 at 5:00 PM Benjamin Kaduk <bkaduk@akamai.com> wrote: On Wed, Jun 06, 2018 at 03:08:28PM -0400, David Benjamin wrote: > Hi all, > > Apologies for the probably record time delay in actually updating this > thing. I like the graph... apparently -00 was expired for nearly twice as > long as it was valid? Oops! > > Per the discussion from a really really long while ago, I've rebased the > document atop TLS 1.3 and added values for the many more bits added in TLS > 1.3. > > Since TLS 1.3 has server-offered extensions, this needed a bit of > reorganization. For the one-bit PSK KE values, I borrowed the pattern from > draft-bishop-httpbis-grease-00. > > Let me know if folks have any comments. Additionally, I'm curious what > folks thoughts are on the following (not incorporated into the document): > > 1) "ignore/" is a pretty long ALPN prefix and also might encourage folks to > parse out the "ignore/" string. Instead, what do folks think about just > using two byte strings. Perhaps the same two byte pattern we're currently > doing? > > 2) This is somewhat of a "how much badly I abuse the registries" thing. :-) > I have observed one TLS implementation which just transcribed the registry > directly into their source code. This was done all the way down to mapping > "Reserved for Private Use" to some dedicated symbol. They successfully > ignored the private use value, but the actual unallocated values for each > of NamedGroup, HashAlgorithm, and SignatureAlgorithm were unmapped and > treated as syntax errors! > > This was just a single implementation, but it suggests GREASE works better > when it's not so obviously allocated in the registry. Of course, not > recording the values at all is unreasonable as we must avoid allocating the > values for real. What do folks think about leaving them out of the table > but instead adding a note in the registry like: > > "The values 0x0A0A, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A, 0x7A7A, > 0x8A8A, 0x9A9A, 0xAAAA, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, and 0xFAFA are used > by [[this document]] for testing implementation correctness. They should be > left permanently unassigned." > > An implementor infinitely bad at reading may well still special-case the > and defeat all these measures, but that was always the case. Rather, the > goal is to find inexpensive ways to lower the failure probability. It seems > inexpensive to me, but I don't know how much trouble it would cause for > IANA. Unfortunately, (my understanding is that) IANA is moving towards a proper database for codepoints, and prefer to actually have all values matched up with their corresponding metadata; I expect that they would not be happy to do something like this. But, of course, we should actually ask instead of guessing.... I suppose the question is what the database is meant to be used for. I can imagine wanting it to be properly queryable so you can transform it into code. GREASE values should not make their way into code. The whole point is to get code used to the fact that unknown values exist. I can also imagine wanting to make it easier to allocate values mechnically. Then, yeah, you want the GREASE values in there. But the allocations need occasional human input anyway (e.g. 26 and 40), so maybe it's fine not to have those in there in a completely structured way? David _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ------=_Part_537120_446305796.1528466820792 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
> GREASE values should not make their way into c= ode. The whole point is to get code used to the fact that unknown values ex= ist.

The GREASE mechanism is useful, but it w= ill definitely make its way into code and become ossified itself.  

--Roelof
<= /div>


---- On Thu, 07 Jun 2018 17:05:47 -= 0400 David Benjamin <davidben@chromium.org> wrote ----

On Thu, Jun 7, 2018 at 5:00 PM Benjamin Kaduk <bkaduk@akamai.com> wrote:<= br>
On Wed, Jun 06, 2018 at 03:08:28= PM -0400, David Benjamin wrote:
> Hi all,
= >
> Apologies for the probably record time delay in a= ctually updating this
> thing. I like the graph... appare= ntly -00 was expired for nearly twice as
> long as it was= valid? Oops!
>
> Per the discussion f= rom a really really long while ago, I've rebased the
> do= cument atop TLS 1.3 and added values for the many more bits added in TLS
> 1.3.
>
> Since TLS 1= .3 has server-offered extensions, this needed a bit of
> = reorganization. For the one-bit PSK KE values, I borrowed the pattern from<= br>
> draft-bishop-httpbis-grease-00.
>
> Let me know if folks have any comments. Additionally, I'm= curious what
> folks thoughts are on the following (not = incorporated into the document):
>
> 1= ) "ignore/" is a pretty long ALPN prefix and also might encourage folks to<= br>
> parse out the "ignore/" string. Instead, what do folks = think about just
> using two byte strings. Perhaps the sa= me two byte pattern we're currently
> doing?
>
> 2) This is somewhat of a "how much badly I abu= se the registries" thing. :-)
> I have observed one TLS i= mplementation which just transcribed the registry
> direc= tly into their source code. This was done all the way down to mapping
> "Reserved for Private Use" to some dedicated symbol. They su= ccessfully
> ignored the private use value, but the actua= l unallocated values for each
> of NamedGroup, HashAlgori= thm, and SignatureAlgorithm were unmapped and
> treated a= s syntax errors!
>
> This was just a s= ingle implementation, but it suggests GREASE works better
&g= t; when it's not so obviously allocated in the registry. Of course, not
=
> recording the values at all is unreasonable as we must avo= id allocating the
> values for real. What do folks think = about leaving them out of the table
> but instead adding = a note in the registry like:
>
> "The = values 0x0A0A, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A, 0x7A7A,
<= /div>
> 0x8A8A, 0x9A9A, 0xAAAA, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, and= 0xFAFA are used
> by [[this document]] for testing imple= mentation correctness. They should be
> left permanently = unassigned."
>
> An implementor infini= tely bad at reading may well still special-case the
> and= defeat all these measures, but that was always the case. Rather, the
> goal is to find inexpensive ways to lower the failure probab= ility. It seems
> inexpensive to me, but I don't know how= much trouble it would cause for
> IANA.
<= br>
Unfortunately, (my understanding is that) IANA is moving tow= ards a proper database
for codepoints, and prefer to actuall= y have all values matched up with their
corresponding metada= ta; I expect that they would not be happy to do something
li= ke this.  But, of course, we should actually ask instead of guessing..= ..

I suppose the question is what= the database is meant to be used for. I can imagine wanting it to be prope= rly queryable so you can transform it into code. GREASE values should not m= ake their way into code. The whole point is to get code used to the fact th= at unknown values exist.

I can also imagine wa= nting to make it easier to allocate values mechnically. Then, yeah, you wan= t the GREASE values in there. But the allocations need occasional human inp= ut anyway (e.g. 26 and 40), so maybe it's fine not to have those in there i= n a completely structured way?

David
=
_______________________________________________
<= div>TLS mailing list


------=_Part_537120_446305796.1528466820792-- From nobody Fri Jun 8 07:35:30 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE71130ED4 for ; Fri, 8 Jun 2018 07:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.951 X-Spam-Level: X-Spam-Status: No, score=-9.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-pFSamdoNME for ; Fri, 8 Jun 2018 07:35:25 -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 77AFA130ED2 for ; Fri, 8 Jun 2018 07:35:25 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id k86-v6so8849709qkh.13 for ; Fri, 08 Jun 2018 07:35:25 -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 :cc; bh=TQYJ/m0dICaJgbwqv9EqXzpjcMziccw30aZkYRm13wg=; b=izHcPRyMhb/dTStuk1+LJ+nyMbkd142g2BX1erLlu3tBX4wOOAv0kdIdpKWlRtJu4R WdVJjfN5bIbdti6xg/P64p2rk05+tzg+XyTjYFqYUEOcOvomhBxeBJ/EXAP1PebHVB/V YPsg7xQeXpoGrN2XxwS1j/qvcAJr+FAc5V/TI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TQYJ/m0dICaJgbwqv9EqXzpjcMziccw30aZkYRm13wg=; b=e1wVyOMZsXII648zApZzu24TroGqNGX1nPnbk6GIyASdxRrlfj5641R5Mzw7ZCdinP 8fbhWq+tghSEUcdyN6Jhdy+dEJW0wMc6FeVP40f48cqN0a98crLrP8WqBCbOa8ZkFryQ pQiYCbcF/KkyT/KkKRoxT7GrmDc0SWXLT1TGhYkY16OOOgzr9yxP3tuQZE0HwCudj2aX HI0HZupft1mx9j9zwLG0uEasmDK8fca2UfPNqIvt0X8glYBop0orpongKrdYbRCEwRR7 ptrS5H+4hvuB4XQWwulSba01tQcx1iE5RdPTBmpS7fVKTu0CVDDOCVmGa8503teO/nDE RECw== X-Gm-Message-State: APt69E0Qm3j0W6/cFrkpVhgcXnSY0bm7+vb2Hw8SkCgjwonbQ2Q57KzQ mnzYQQVJg7Zb5vtfg42xONQeEfRfwO2fEQxu/nJG X-Google-Smtp-Source: ADUXVKLyoQZeIPym4VOxsqsyYbqBRwQ+uP7fFc8pj4ukTWBDOG9nF0RpkbAyyYLyhXv3A28InjrY+t4JQ4if4ppdejo= X-Received: by 2002:a37:9303:: with SMTP id v3-v6mr2026946qkd.318.1528468524252; Fri, 08 Jun 2018 07:35:24 -0700 (PDT) MIME-Version: 1.0 References: <152830634989.6264.3566629916218895862@ietfa.amsl.com> <20180607210040.GA13834@akamai.com> <163dfb8ceb7.fef8d66b166467.2392907059047091602@nerd.ninja> In-Reply-To: <163dfb8ceb7.fef8d66b166467.2392907059047091602@nerd.ninja> From: David Benjamin Date: Fri, 8 Jun 2018 10:35:11 -0400 Message-ID: To: R duToit Cc: Benjamin Kaduk , tls@ietf.org Content-Type: multipart/alternative; boundary="0000000000007114bd056e224fa4" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-grease-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 08 Jun 2018 14:35:29 -0000 --0000000000007114bd056e224fa4 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 8, 2018 at 10:07 AM R duToit wrote: > > GREASE values should not make their way into code. The whole point is to > get code used to the fact that unknown values exist. > > The GREASE mechanism is useful, but it will definitely make its way into > code and become ossified itself. > Example: https://github.com/salesforce/ja3 > Indeed. GREASE was targeting normal sensible endpoint implementations. The assumption is that our interop problems are merely benign mistakes, and that if something triggers the developer to notice early enough, they will simply fix it. For a normal well-behaving server, there is no reason to special-case GREASE over following the protocol. So the goal is to avoid accidental special-cases, not folks intentionally trying to fixate on things that will obviously not remain stable. Of course, since we first tried this, TLS 1.3 has demonstrated that there are other players in the ecosystem that are rampantly non-compliant in exactly that way, notably various middlewave devices. Those are rather a problem and will need other ideas enforce TLS's long-standing but evidently ignored protocol invariants . I did not propose any new ideas in this document update, as this was just about updating it to match the prior discussion of rebasing atop TLS 1.3. David ---- On Thu, 07 Jun 2018 17:05:47 -0400 *David Benjamin > >* wrote ---- > > On Thu, Jun 7, 2018 at 5:00 PM Benjamin Kaduk wrote: > > On Wed, Jun 06, 2018 at 03:08:28PM -0400, David Benjamin wrote: > > Hi all, > > > > Apologies for the probably record time delay in actually updating this > > thing. I like the graph... apparently -00 was expired for nearly twice as > > long as it was valid? Oops! > > > > Per the discussion from a really really long while ago, I've rebased the > > document atop TLS 1.3 and added values for the many more bits added in > TLS > > 1.3. > > > > Since TLS 1.3 has server-offered extensions, this needed a bit of > > reorganization. For the one-bit PSK KE values, I borrowed the pattern > from > > draft-bishop-httpbis-grease-00. > > > > Let me know if folks have any comments. Additionally, I'm curious what > > folks thoughts are on the following (not incorporated into the document): > > > > 1) "ignore/" is a pretty long ALPN prefix and also might encourage folks > to > > parse out the "ignore/" string. Instead, what do folks think about just > > using two byte strings. Perhaps the same two byte pattern we're currently > > doing? > > > > 2) This is somewhat of a "how much badly I abuse the registries" thing. > :-) > > I have observed one TLS implementation which just transcribed the > registry > > directly into their source code. This was done all the way down to > mapping > > "Reserved for Private Use" to some dedicated symbol. They successfully > > ignored the private use value, but the actual unallocated values for each > > of NamedGroup, HashAlgorithm, and SignatureAlgorithm were unmapped and > > treated as syntax errors! > > > > This was just a single implementation, but it suggests GREASE works > better > > when it's not so obviously allocated in the registry. Of course, not > > recording the values at all is unreasonable as we must avoid allocating > the > > values for real. What do folks think about leaving them out of the table > > but instead adding a note in the registry like: > > > > "The values 0x0A0A, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A, > 0x7A7A, > > 0x8A8A, 0x9A9A, 0xAAAA, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, and 0xFAFA are > used > > by [[this document]] for testing implementation correctness. They should > be > > left permanently unassigned." > > > > An implementor infinitely bad at reading may well still special-case the > > and defeat all these measures, but that was always the case. Rather, the > > goal is to find inexpensive ways to lower the failure probability. It > seems > > inexpensive to me, but I don't know how much trouble it would cause for > > IANA. > > Unfortunately, (my understanding is that) IANA is moving towards a proper > database > for codepoints, and prefer to actually have all values matched up with > their > corresponding metadata; I expect that they would not be happy to do > something > > like this. But, of course, we should actually ask instead of guessing.... > > > I suppose the question is what the database is meant to be used for. I can > imagine wanting it to be properly queryable so you can transform it into > code. GREASE values should not make their way into code. The whole point is > to get code used to the fact that unknown values exist. > > I can also imagine wanting to make it easier to allocate values > mechnically. Then, yeah, you want the GREASE values in there. But the > allocations need occasional human input anyway (e.g. 26 and 40), so maybe > it's fine not to have those in there in a completely structured way? > > David > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --0000000000007114bd056e224fa4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jun 8,= 2018 at 10:07 AM R duToit <r@nerd.ninja> wrote:
>=C2=A0GREASE values should not make the= ir way into code. The whole point is to get code used to the fact that unkn= own values exist.

The GREAS= E mechanism is useful, but it will definitely make its way into code and b= ecome ossified itself. =C2=A0

Indeed. GREASE was tar= geting normal sensible endpoint implementations. The assumption is that our= interop problems are merely benign mistakes, and that if something trigger= s the developer to notice early enough, they will simply fix it. For a norm= al well-behaving server, there is no reason to special-case GREASE over fol= lowing the protocol. So the goal is to avoid accidental special-cases, not = folks intentionally trying to fixate on things that will obviously not rema= in stable.

Of course, since we first tried this, T= LS 1.3 has demonstrated that there are other players in the ecosystem that = are rampantly non-compliant in exactly that way, notably various middlewave= devices. Those are rather a problem and will need other ideas enforce TLS&= #39;s long-standing but evidently ignored protocol invariants= . I did not propose any new ideas in this document update, as this was = just about updating it to match the prior discussion of rebasing atop TLS 1= .3.

David

---- On Thu,= 07 Jun 2018 17:05:47 -0400=C2=A0David Benjamin <davidben@chromium.org> wr= ote ----

=
On Thu, Jun 7, 2018 = at 5:00 PM Benjamin Kaduk <bkaduk@akamai.com> wrote:
On Wed, Jun 06, 2018 at 03:08:28P= M -0400, David Benjamin wrote:
> Hi all,
&= gt;
> Apologies for the probably record time delay in ac= tually updating this
> thing. I like the graph... apparen= tly -00 was expired for nearly twice as
> long as it was = valid? Oops!
>
> Per the discussion fr= om a really really long while ago, I've rebased the
>= document atop TLS 1.3 and added values for the many more bits added in TLS=
> 1.3.
>
> Since TL= S 1.3 has server-offered extensions, this needed a bit of
&g= t; reorganization. For the one-bit PSK KE values, I borrowed the pattern fr= om
> draft-bishop-httpbis-grease-00.
> =
> Let me know if folks have any comments. Additionally, = I'm curious what
> folks thoughts are on the followin= g (not incorporated into the document):
>
= > 1) "ignore/" is a pretty long ALPN prefix and also might en= courage folks to
> parse out the "ignore/" stri= ng. Instead, what do folks think about just
> using two b= yte strings. Perhaps the same two byte pattern we're currently
> doing?
>
> 2) This is some= what of a "how much badly I abuse the registries" thing. :-)
<= /div>
> I have observed one TLS implementation which just transcrib= ed the registry
> directly into their source code. This w= as done all the way down to mapping
> "Reserved for = Private Use" to some dedicated symbol. They successfully
> ignored the private use value, but the actual unallocated values for= each
> of NamedGroup, HashAlgorithm, and SignatureAlgori= thm were unmapped and
> treated as syntax errors!
>
> This was just a single implementation, bu= t it suggests GREASE works better
> when it's not so = obviously allocated in the registry. Of course, not
> rec= ording the values at all is unreasonable as we must avoid allocating the
> values for real. What do folks think about leaving them o= ut of the table
> but instead adding a note in the regist= ry like:
>
> "The values 0x0A0A, = 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A, 0x7A7A,
>= 0x8A8A, 0x9A9A, 0xAAAA, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, and 0xFAFA are use= d
> by [[this document]] for testing implementation corre= ctness. They should be
> left permanently unassigned.&quo= t;
>
> An implementor infinitely bad a= t reading may well still special-case the
> and defeat al= l these measures, but that was always the case. Rather, the
= > goal is to find inexpensive ways to lower the failure probability. It = seems
> inexpensive to me, but I don't know how much = trouble it would cause for
> IANA.

Unfortunately, (my understanding is that) IANA is moving towards a= proper database
for codepoints, and prefer to actually have= all values matched up with their
corresponding metadata; I = expect that they would not be happy to do something
<= /div>
like this.= =C2=A0 But, of course, we should actually ask instead of guessing....

I = suppose the question is what the database is meant to be used for. I can im= agine wanting it to be properly queryable so you can transform it into code= . GREASE values should not make their way into code. The whole point is to = get code used to the fact that unknown values exist.

I can also imagine wanting to make it easier to allocate values mech= nically. Then, yeah, you want the GREASE values in there. But the allocatio= ns need occasional human input anyway (e.g. 26 and 40), so maybe it's f= ine not to have those in there in a completely structured way?

David
=
________________________= _______________________
TLS mailing list
h= ttps://www.ietf.org/mailman/listinfo/tls
<= /div>
--0000000000007114bd056e224fa4-- From nobody Fri Jun 8 18:13:51 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EC0130DCE for ; Fri, 8 Jun 2018 18:13:48 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 pYr8kO2Yl5z0 for ; Fri, 8 Jun 2018 18:13:46 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 5F7181277C8 for ; Fri, 8 Jun 2018 18:13:46 -0700 (PDT) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx66.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fRSRr-00081a-VS for tls@ietf.org; Sat, 09 Jun 2018 03:13:44 +0200 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fRSRl-0005KZ-6G for tls@ietf.org; Fri, 08 Jun 2018 21:13:41 -0400 Received: (qmail 26257 invoked from network); 9 Jun 2018 01:13:33 -0000 Received: from unknown (HELO [192.168.0.104]) (Authenticated-user:_huitema@huitema.net@[172.56.42.97]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 9 Jun 2018 01:13:33 -0000 To: tls@ietf.org References: <152830634989.6264.3566629916218895862@ietfa.amsl.com> <20180607210040.GA13834@akamai.com> <163dfb8ceb7.fef8d66b166467.2392907059047091602@nerd.ninja> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Fri, 8 Jun 2018 18:13:29 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FDB0F60F341857B4434786B9" Content-Language: en-US X-Originating-IP: 168.144.250.245 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5sO6g8i30uqDZZuvbaEKlyF602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO5IcVwV4jjVcAOtIXxgohGFVMZsRZacTbJPGp/MBC6Bxo2/sYV+AW/s7jTD/nqvHCUh5 mNm/WjPqhYqCeBiCKwzwNnO0oYiZjOnC1Xa7kCO2AIOsmfKTx05l1vgtiDJZqfvRa7MR4hgRIg8N 1QlY4G7x1YBTEs55LirRLgpsvCFtid7SQi4NE/job5y2wAN3GZxznd8NXwc/vKJtfZaXo5QAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0Cn4p2u0cbdyGTcIliCOXEyKIRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM/9rUJrEbVA84BZVscMTXpbwyPr6Ygmqufq1En6WLLn AIHlTa0FG0ij7AOlTYklM4KgVlq0fCq5j5BFmf9FzY8/nnXm95a0vRtjH3/UwFOlrehiw2P3D5EI +nblg037uMC3B+q+bUHXAsYFgsNREGhlzTFYPIyr5voE3ggyv83xvYRfyCMB4QZToA5YKb0SaS5E llm5CBzrwBATJ22MAarYDrnzsG5f+caI1dL5Ye/k8E7k+vjbEFIODONvVl7uk81XeCuM9gAbuM3t HWekNFdf6RNsrPZJFtxtX2KLfVwALdfH1yALUGC6BHMPRvkcc+0OvUbAhuBcxhaqUsiJeMQS9R/2 gMGq0KWAzmMf+ibVDq6cyN5oTOsLjetNPyF2Ho+qWKEc9MBxZCWS72/wjopIVAY+3RHRetx4B6Z4 Ei5woFss+n2ffnQxt6aJ7klZab+5U3mWTJPTqb+xVIKqgeO7n3iwosDmKSszPVW9RecIRsxn9uie 2n4+ooHGqAOWILQxL7hrJSk60SF3F6RYOYr2 X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-grease-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 09 Jun 2018 01:13:49 -0000 This is a multi-part message in MIME format. --------------FDB0F60F341857B4434786B9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/8/2018 7:35 AM, David Benjamin wrote: > On Fri, Jun 8, 2018 at 10:07 AM R duToit wrote: > > >=C2=A0GREASE values should not make their way into code. The whole= > point is to get code used to the fact that unknown values exist. > > The GREASE mechanism is useful, but it will definitely make its > way into code and become ossified itself. =C2=A0 > Example: =C2=A0https://github.com/salesforce/ja3 > > > Indeed. GREASE was targeting normal sensible endpoint implementations..= =2E =2E.. and maybe we need a different mechanism to defeat fingerprinting tools like this JA3 project. Maybe applications need to somehow randomize their signatures, so that they are not so easy to recognize. For example, it should be possible to use randomize the order of extensions. And it should also be possible to throw some grease in these sets. Of course, the first ones to develop and use these randomization techniques will most likely be the malware authors that the tools are allegedly trying to track. -- Christian Huitema --------------FDB0F60F341857B4434786B9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 6/8/2018 7:35 AM, David Benjamin wrote:

On Fri, Jun 8, 2018 at 10:07 AM R duToit <r@nerd.ninja> wrote:
> GREASE values should not make their way into code. The whole point is to get code used to the fact that unknown values exist.

The GREASE mechanism is useful, but it will definitely make its way into code and become ossified itself.  

Indeed. GREASE was targeting normal sensible endpoint implementations...

... and maybe we need a different mechanism to defeat fingerprinting tools like this JA3 project. Maybe applications need to somehow randomize their signatures, so that they are not so easy to recognize. For example, it should be possible to use randomize the order of extensions. And it should also be possible to throw some grease in these sets.

Of course, the first ones to develop and use these randomization techniques will most likely be the malware authors that the tools are allegedly trying to track.

-- Christian Huitema
--------------FDB0F60F341857B4434786B9-- From nobody Mon Jun 11 14:25:21 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11AE0130ED8; Mon, 11 Jun 2018 14:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeaBMumI4E8r; Mon, 11 Jun 2018 14:25:16 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010: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 9E3C3130DBE; Mon, 11 Jun 2018 14:25:15 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id y20-v6so32814544lfy.0; Mon, 11 Jun 2018 14:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=mBmEy+WhIC51f/N4gf1F1/Qv4kPGsCl4N2CovpWgwHk=; b=le+ZqsKrtZVCg2UTtyOABKQVeHSqkZdhMv7Tjjstbmlf45f4DI5dV9jvmsDsQkdfjh TZ0EZM5ZmheNLF5g0fgAV1XYfR0V3Pzeu5y6JjMKx48QkcG+rImO6kYo/Lnr662nhIU3 pOnKKO1VHrlzOCdcHPE5rsQR+9c0xvoMfj06XbthnSbTrEQISoX9pllU+2SrgAwyWQ9d eutx6hgC6SY/x6HXQRkZ5ly2ekN7X0YMFgAJecY15JUgbDNX0DIbZBL3SUXFJEjHdTZN erV6mAY9dqMXtQDdXotUxa37xEzqqly71dAAoUqKt/2Wq2EQMftIRUb+907ttZUNKwvL mxRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=mBmEy+WhIC51f/N4gf1F1/Qv4kPGsCl4N2CovpWgwHk=; b=DoPKovsWZFSHg0+9BVsZkqyOGjtXyw5Ku35P0tFNlj5YtIS1befKIlRx1+9ZPZw0T4 lVAWrLyb8/CIs+u8WLfZ7eH0Wsm5DuNckeQFy8EFKbzfYkQCJDx5el0qkvhcTWAQBLMN BzX9/+DlpafIXHnySmzSsxecaWRrfNeskIQOAfYZftSCvoy3ArxPeIKSOoSbcR+U5qqg Uh5WrlNQTNadQXPncfzGJGsmLlNyCO0X25n2dc+zgXs8TBFrI3vyhj2ntpglXF2XoQE8 f5HXFBUekpkGmn5ITLt4qAgkSEDA/B8xx31VVG2VhAsoHsee1AFgGZqAEDXZHcdcY9w3 c2Og== X-Gm-Message-State: APt69E0oJx6d5VDoCXrg3R807UHBnCQXlEFAlyM6c87B/78fjMJTH8wF aEfirgmrTzatU74D2FOsItaXORdFEj4rrUo4YNo= X-Google-Smtp-Source: ADUXVKKAs+FJhjV8bJqC9ksVCTAfsJ6aV0ZJ5kWSU/3yIZTO/M8ZIGX0jK7bhUUzEHVZ9yF62FkHImhTYcQmXV+jrA0= X-Received: by 2002:a19:eb86:: with SMTP id f6-v6mr469019lfk.24.1528752313814; Mon, 11 Jun 2018 14:25:13 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 2002:a2e:5843:0:0:0:0:0 with HTTP; Mon, 11 Jun 2018 14:25:13 -0700 (PDT) From: Daniel Migault Date: Mon, 11 Jun 2018 17:25:13 -0400 X-Google-Sender-Auth: HoDDJYwYmpulX8rvD0osJKWKzyQ Message-ID: To: tls Cc: LURK BoF Content-Type: multipart/alternative; boundary="0000000000009d520e056e6462fb" Archived-At: Subject: [TLS] TLS 1.2 and sha256 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 11 Jun 2018 21:25:19 -0000 --0000000000009d520e056e6462fb Content-Type: text/plain; charset="UTF-8" Hi, TLS 1.2 uses sha256 as the prf hash function. When sha256 will not be considered secured, I am wondering if we can reasonably envision deprecating sha256 for TLS 1.2 or if TLS 1.2 will at that time be deprecated in favor of TLS 1.X X>= 3 ? In other words, I am wondering how much we can assume TLS 1.2 is associated to sha256. Yours, Daniel --0000000000009d520e056e6462fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

TLS 1.2 uses sha256= as the prf hash function. When sha256 will not be considered secured, I am= wondering if we can reasonably envision deprecating sha256 for TLS 1.2 or = if TLS 1.2 will at that time be deprecated in favor of TLS 1.X X>=3D 3 ?=

In other words, I am wondering how much we can as= sume TLS 1.2 is associated to sha256.

Yours, =
Daniel


--0000000000009d520e056e6462fb-- From nobody Mon Jun 11 14:53:20 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB10131057 for ; Mon, 11 Jun 2018 14:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.251 X-Spam-Level: X-Spam-Status: No, score=-9.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71vvbRpfRFmF for ; Mon, 11 Jun 2018 14:53:08 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 838691310BA for ; Mon, 11 Jun 2018 14:53:08 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id p23-v6so21866761qtn.6 for ; Mon, 11 Jun 2018 14:53:08 -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 :cc; bh=rVSvYgk+NRmQuNuecIqLE0ky0olpVdah8AQMy5FzZMM=; b=CYtrjVhwNzjVMWSxXsn3OzHVLkB6ihIXKLfabgObJaUnrJdMDiZu+mfadokvnDrwRx EkP+2JFrGk825mzbP58JcxeqKdyxDauQqY3DtWU2KU+B6wPvk7B8SZABbfTTl6nhEsZN Bajcb6XrMan+P6EbfHZ3O147/1xVXH+1fFSuM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rVSvYgk+NRmQuNuecIqLE0ky0olpVdah8AQMy5FzZMM=; b=fvhEsQRGcKw0UwXVGSJ9j2O7tfZ68DUETjIbSxZKXBe3gDAEifCIMEm5tdtfnR7pPj bZV122QEgstJTw9Ib+PPgA/TzelmkgRPYIugfVWAIeJs4TIZumJ1lwz+6qGfsgImeONK i/8QV2BA6R/MRg8G3TNfUP40kc01uwU87/0mpMZ7WiB7tIOals6QvI1cFJKk0jVIwxzp G7gbF6gg3v7f8RdMWeOPnvutA6cBq8eEob+dUkKjtUdjZA3oyQLzpLjKrUT33npEtMzF PNSxhCzyyRfAWuDiHNjTRLc+RzEQzQLLyIkheUVhmQYyN/b7VRaRZvOv1oMAsiIISGR0 Vw6A== X-Gm-Message-State: APt69E3SHnlN+rr3tis7bY7WTwz5qOrMBnOPbeZLAFQ3DFkybomDlIcT WcfUVR97JaPLYy6hAqCacg0sll8Oy40ylfgQ6hHh X-Google-Smtp-Source: ADUXVKLDfl5g/e1o7RZjw9mc9ld2UdI0mn+hC+O+bKVanyH1vA58/i4+s4AeuzstHeSzkFF6YBMhuNyuXpmbo1wt22k= X-Received: by 2002:ac8:25a5:: with SMTP id e34-v6mr979860qte.318.1528753987433; Mon, 11 Jun 2018 14:53:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Mon, 11 Jun 2018 17:52:55 -0400 Message-ID: To: Daniel Migault Cc: tls , LURK BoF Content-Type: multipart/alternative; boundary="0000000000005f7082056e64c6bf" Archived-At: Subject: Re: [TLS] TLS 1.2 and sha256 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 11 Jun 2018 21:53:17 -0000 --0000000000005f7082056e64c6bf Content-Type: text/plain; charset="UTF-8" In both TLS 1.2 and TLS 1.3, SHA-256 isn't hardcoded per se. It's a function of the cipher suite you negotiate (and also, separately, the signature algorithm you negotiate). That said, in practice, both are pretty solidly dependent on SHA-256. Most options involve it. AES-128-GCM and ChaCha20-Poly1305 are currently paired with SHA-256 while only AES-256-GCM is paired with SHA-384. We could certainly define new cipher suites for either of TLS 1.2 and TLS 1.3 as needed. But defining a new cipher suite for TLS 1.2 doesn't magically deploy it for all existing TLS 1.2 servers. Those servers must deploy new code, at which point updating your TLS library to include it would also pull in TLS 1.3 anyway (or whatever the latest TLS version is by then). So I think there will likely be no point in bothering with TLS 1.2 allocations at that point. More options means more combinatorial complexity for implementations, which means more our rather limited collective resources in this space get even more thinly spread. David On Mon, Jun 11, 2018 at 5:25 PM Daniel Migault wrote: > Hi, > > TLS 1.2 uses sha256 as the prf hash function. When sha256 will not be > considered secured, I am wondering if we can reasonably envision > deprecating sha256 for TLS 1.2 or if TLS 1.2 will at that time be > deprecated in favor of TLS 1.X X>= 3 ? > > In other words, I am wondering how much we can assume TLS 1.2 is > associated to sha256. > > Yours, > Daniel > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000005f7082056e64c6bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In both TLS 1.2 and TLS 1.3, SHA-256 isn't hardco= ded per se. It's a function of the cipher suite you negotiate (and also= , separately, the signature algorithm you negotiate). That said, in practic= e, both are pretty solidly dependent on SHA-256. Most options involve it. A= ES-128-GCM and ChaCha20-Poly1305 are currently paired with SHA-256 while on= ly AES-256-GCM is paired with SHA-384.

We could ce= rtainly define new cipher suites for either of TLS 1.2 and TLS 1.3 as neede= d. But defining a new cipher suite for TLS 1.2 doesn't magically deploy= it for all existing TLS 1.2 servers. Those servers must deploy new code, a= t which point updating your TLS library to include it would also pull in TL= S 1.3 anyway (or whatever the latest TLS version is by then).
So I think there will likely be no point in bothering with TLS = 1.2 allocations at that point. More options means more combinatorial comple= xity for implementations, which means more our rather limited collective re= sources in this space get even more thinly spread.

David

On Mon, Jun 11, 2018 at 5:25 PM Daniel Migault <daniel.migault@ericsson.com> wrote:
Hi,
TLS 1.2 uses sha256 as the prf hash function. When sha256 will= not be considered secured, I am wondering if we can reasonably envision de= precating sha256 for TLS 1.2 or if TLS 1.2 will at that time be deprecated = in favor of TLS 1.X X>=3D 3 ?

In other words, I= am wondering how much we can assume TLS 1.2 is associated to sha256.
<= /div>

Yours,
Daniel


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000005f7082056e64c6bf-- From nobody Mon Jun 11 15:37:01 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6887B130EC3 for ; Mon, 11 Jun 2018 15:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0Oj9ns1bbTj for ; Mon, 11 Jun 2018 15:36:55 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002: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 C08B9128BAC for ; Mon, 11 Jun 2018 15:36:55 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id r19-v6so6864986ywc.10 for ; Mon, 11 Jun 2018 15:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3xoU2YR1vwVK+J0sz7DAeXSg+ktumCmS8BsWpX25iL0=; b=06FBSpK9t1RmG2thSS5KNotBbrRj5N4u42Nqdr6sPkHdZE4D047NH3ZNiBjRMrYbBN +0bkQAc5Oy9IufzjUCjTMOE8d31kr0I3ICyGYEKHXBaB7QaYwyEbmwbY/lktdgGjfNG7 Il988utS349Yvde46WZj6u0tdiOzlZBknWVXa55yneg2SraPq1m4MFRIo1pygbreRg/y 7PSjv7fcrswwaiGLSwPsTm4FFOHUoSzywM2w02b5btD074fUVNMv7TG1IJJ5c7JnBXsn jsDvXSKElMOpihGP4aQfXe5VxSo61wNeUJiZQybxSXtpbaAiqntmy/PpxGJOXgcDrKHF UhTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3xoU2YR1vwVK+J0sz7DAeXSg+ktumCmS8BsWpX25iL0=; b=sk47Ka8HUY+YXl8nO8VsnEPWhXX1mqSMwGL7qOEfz5rQF1wrbh5LK6gju92ybN/ztT YnDyvAVAcMrg2+OcjFlNXsZx/vdl7DChoLou0uxoi/3cYIRQtk+fh+wg+dH5UWb7T9Uu b3oQ0ZXBdKxuRGJxGO/PeR/04tfzrjrVlqpJfF1uKz0/F704C/7rGT1z40s7OMInyI1u 7+pCSnKyRtwnzQ6AjZdEl+B+8OXfJmnM801WykCR6E+fblC9XSFJO7niDhamod3G8Cfb ecw/dgaXyoE+MXcnpt3cPkGpxVurEPeIJI3mdDmLWGGLhvufvvQOA0cyiE6fFD3k41a1 kMxA== X-Gm-Message-State: APt69E1cFfz3+TwAcRKtKVZjDirj5YZ54XaL8xIPgTEu69B7fzDvTpca v1EPHg/lihr85Xq+TawgU5COqD//xhyqSHBxYzyEJg== X-Google-Smtp-Source: ADUXVKIvHIV3ur0hZZmGNrJht18iq9Za+h6efx+gJXjqY6YUlsuzgIi/A2LmCEhmfuxhnp/C3uz+jswt621VBeDO/Pw= X-Received: by 2002:a0d:f885:: with SMTP id i127-v6mr521707ywf.144.1528756614761; Mon, 11 Jun 2018 15:36:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:7bc4:0:0:0:0:0 with HTTP; Mon, 11 Jun 2018 15:36:53 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Mon, 11 Jun 2018 15:36:53 -0700 Message-ID: To: David Benjamin Cc: Daniel Migault , LURK BoF , tls Content-Type: multipart/alternative; boundary="000000000000f8a7da056e6562d9" Archived-At: Subject: Re: [TLS] TLS 1.2 and sha256 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 11 Jun 2018 22:37:00 -0000 --000000000000f8a7da056e6562d9 Content-Type: text/plain; charset="UTF-8" Just to add to this excellent answer ... there is the signature on the certificates used, which is independent of the cipher suite that you negotiate but also commonly uses SHA256. Truly moving from SHA256 would require CAs, Browsers, etc to adopt something new there too. On Mon, Jun 11, 2018 at 2:52 PM, David Benjamin wrote: > In both TLS 1.2 and TLS 1.3, SHA-256 isn't hardcoded per se. It's a > function of the cipher suite you negotiate (and also, separately, the > signature algorithm you negotiate). That said, in practice, both are pretty > solidly dependent on SHA-256. Most options involve it. AES-128-GCM and > ChaCha20-Poly1305 are currently paired with SHA-256 while only AES-256-GCM > is paired with SHA-384. > > We could certainly define new cipher suites for either of TLS 1.2 and TLS > 1.3 as needed. But defining a new cipher suite for TLS 1.2 doesn't > magically deploy it for all existing TLS 1.2 servers. Those servers must > deploy new code, at which point updating your TLS library to include it > would also pull in TLS 1.3 anyway (or whatever the latest TLS version is by > then). > > So I think there will likely be no point in bothering with TLS 1.2 > allocations at that point. More options means more combinatorial complexity > for implementations, which means more our rather limited collective > resources in this space get even more thinly spread. > > David > > On Mon, Jun 11, 2018 at 5:25 PM Daniel Migault < > daniel.migault@ericsson.com> wrote: > >> Hi, >> >> TLS 1.2 uses sha256 as the prf hash function. When sha256 will not be >> considered secured, I am wondering if we can reasonably envision >> deprecating sha256 for TLS 1.2 or if TLS 1.2 will at that time be >> deprecated in favor of TLS 1.X X>= 3 ? >> >> In other words, I am wondering how much we can assume TLS 1.2 is >> associated to sha256. >> >> Yours, >> Daniel >> >> >> _______________________________________________ >> 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 > > -- Colm --000000000000f8a7da056e6562d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to add to this excellent answer =C2=A0... there is th= e signature on the certificates used, which is independent of the cipher su= ite that you negotiate but also commonly uses SHA256. Truly moving from SHA= 256 would require CAs, Browsers, etc to adopt something new there too.
<= div class=3D"gmail_extra">
On Mon, Jun 11, 20= 18 at 2:52 PM, David Benjamin <davidben@chromium.org> wr= ote:
In both TLS 1.= 2 and TLS 1.3, SHA-256 isn't hardcoded per se. It's a function of t= he cipher suite you negotiate (and also, separately, the signature algorith= m you negotiate). That said, in practice, both are pretty solidly dependent= on SHA-256. Most options involve it. AES-128-GCM and ChaCha20-Poly1305 are= currently paired with SHA-256 while only AES-256-GCM is paired with SHA-38= 4.

We could certainly define new cipher suites for= either of TLS 1.2 and TLS 1.3 as needed. But defining a new cipher suite f= or TLS 1.2 doesn't magically deploy it for all existing TLS 1.2 servers= . Those servers must deploy new code, at which point updating your TLS libr= ary to include it would also pull in TLS 1.3 anyway (or whatever the latest= TLS version is by then).

So I think there will li= kely be no point in bothering with TLS 1.2 allocations at that point. More = options means more combinatorial complexity for implementations, which mean= s more our rather limited collective resources in this space get even more = thinly spread.

David

On Mon, Jun = 11, 2018 at 5:25 PM Daniel Migault <daniel.migault@ericsson.com> wrote:
=
Hi,

TLS 1.2 uses sha256 as= the prf hash function. When sha256 will not be considered secured, I am wo= ndering if we can reasonably envision deprecating sha256 for TLS 1.2 or if = TLS 1.2 will at that time be deprecated in favor of TLS 1.X X>=3D 3 ?

In other words, I am wondering how much we can assum= e TLS 1.2 is associated to sha256.

Yours,
Daniel


_______________________________________________
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




--
Colm
--000000000000f8a7da056e6562d9-- From nobody Tue Jun 12 09:28:03 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F266130EEB for ; Tue, 12 Jun 2018 09:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.95 X-Spam-Level: X-Spam-Status: No, score=-9.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dcV2zV2AX3A for ; Tue, 12 Jun 2018 09:27:53 -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 9BCAC12D949 for ; Tue, 12 Jun 2018 09:27:53 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id a195-v6so15432729qkg.3 for ; Tue, 12 Jun 2018 09:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=rmRC5ttJYIgEwqLOzP6SOI6w/NNMNXJmP+hPcIgupbY=; b=Q5Weq38x6pO6cqSZkQ3qaNpKKzDhlUu5CI6SqfeZBh8HmanK+sf/9wy8RCFftg+XtY aYDWmk5iiMW3VpVeeM82RSfgJ6hpnDw/hoKPmDguQnv7iQuVmgc/XI0xQL8FzClGO7/h FdL96dAVtLKeh82mi3tPoODYxzrlVLIZq3XfU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rmRC5ttJYIgEwqLOzP6SOI6w/NNMNXJmP+hPcIgupbY=; b=kx4Jb198sZ7s3l/PVBtBeJILm+p1BA9lYPz9qRvywEP0KINh6CNTkeo3kO1vQqA54H K8EpVlxiSiUPWQ2rIr5J49OY6fhm6+M3MUHHeAs3efpm682hlXaHfMmMEsgWwZ4rKNcD 9EmFd8TcOqgPu0SMMqSrkZk4RczG49MEk2rYUre4DB1OJVH+bHn4PWYiSYWdiyvfAIN3 LIhNg9Dq5ssRisxOStvOQc1xrimt+7hi0dAvCHQxx7LHUAMsuWUyYxX7gA1MNcDo5A+I /pIDilO+eD9ducl94odH2NhZUGIgBV6wT7+YvH3Fefk3p/RPJurXTBUcSkmXIan2DWYE d8dw== X-Gm-Message-State: APt69E0sNZVQbdCov4fvQp7u8dyOrFrHp5NQ8BkjhN73qqMp5qjdCuOh kEJLiQS9IXQtptcIIs0WaUIujqT5lD4jVQlRXyOE3JM= X-Google-Smtp-Source: ADUXVKLM9AccckBJLldH9Zs+Zggy03DoaF1O4LcDcmDL8SvZ0Xp3VpgNMyHzL6Xr4fG2S2FpxJIXlajr94rJ5RbFSOU= X-Received: by 2002:a37:7dc2:: with SMTP id y185-v6mr1163990qkc.232.1528820872290; Tue, 12 Jun 2018 09:27:52 -0700 (PDT) MIME-Version: 1.0 From: David Benjamin Date: Tue, 12 Jun 2018 12:27:39 -0400 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000054091056e7459ce" Archived-At: Subject: [TLS] Enforcing Protocol Invariants X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2018 16:28:01 -0000 --000000000000054091056e7459ce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, Now that TLS 1.3 is about done, perhaps it is time to reflect on the ossification problems. TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may be incrementally rolled out in an existing compliant TLS 1.2 deployment. Yet we had problems. Widespread non-compliant servers broke on the TLS 1.3 ClientHello, so versioning moved to supported_versions. Widespread non-compliant middleboxes attempted to parse someone else=E2=80=99s ServerH= ellos, so the protocol was further hacked to weave through their many defects. I think I can speak for the working group that we do not want to repeat this adventure again. In general, I think the response to ossification is two-fold: 1. It=E2=80=99s already happened, so how do we progress today? 2. How do we avoid more of this tomorrow? The workarounds only answer the first question. For the second, TLS 1.3 has a section which spells out a few protocol invariants . It is all corollaries of existing TLS specification text, but hopefully documenting it explicitly will help. But experience has shown specification text is only necessary, not sufficient. For extensibility problems in servers, we have GREASE . This enforces the key rule in ClientHello processing: ignore unrecognized parameters. GREASE enforces this by filling the ecosystem with them. TLS 1.3=E2=80=99s middleb= ox woes were different. The key rule is: if you did not produce a ClientHello, you cannot assume that you can parse the response. Analogously, we should fill the ecosystem with such responses. We have an idea, but it is more involved than GREASE, so we are very interested in the TLS community=E2=80=99s feedb= ack. In short, we plan to regularly mint new TLS versions (and likely other sensitive parameters such as extensions), roughly every six weeks matching Chrome=E2=80=99s release cycle. Chrome, Google servers, and any other deplo= yment that wishes to participate, would support two (or more) versions of TLS 1.3: the standard stable 0x0304, and a rolling alternate version. Every six weeks, we would randomly pick a new code point. These versions will otherwise be identical to TLS 1.3, save maybe minor details to separate keys and exercise allowed syntax changes. The goal is to pave the way for future versions of TLS by simulating them (=E2=80=9Cdraft negative one=E2= =80=9D). Of course, this scheme has some risk. It grabs code points everywhere. Code points are plentiful, but we do sometimes have collisions (e.g. 26 and 40). The entire point is to serve and maintain TLS=E2=80=99s extensibility, so w= e certainly do not wish to hamper it! Thus we have some safeguards in mind: * We will document every code point we use and what it refers to. (If the volume is fine, we can email them to the list each time.) New allocations can always avoid the lost numbers. At a rate of one every 6 weeks, it will take over 7,000 years to exhaust everything. * We will avoid picking numbers that the IETF is likely to allocate, to reduce the chance of collision. Rolling versions will not start with 0x03, rolling cipher suites or extensions will not be contiguous with existing blocks, etc. * BoringSSL will not enable this by default. We will only enable it where we can shut it back off. On our servers, we of course regularly deploy changes. Chrome is also regularly updated and, moreover, we will gate it on our server-controlled field trials mechanism. We hope that, in practice, only the last several code points will be in use at a time. * Our clients would only support the most recent set of rolling parameters, and our servers the last handful. As each value will be short-lived, the ecosystem is unlikely to rely on them as de facto standards. Conversely, like other extensions, implementations without them will still interoperate fine. We would never offer a rolling parameter without the corresponding stable one. * If this ultimately does not work, we can stop at any time and only have wasted a small portion of code points. * Finally, if the working group is open to it, these values could be summarized in regular documents to reserve them, so that they are ultimately reflected in the registries. A new document every six weeks is probably impractical, but we can batch them up. We are interested in the community=E2=80=99s feedback on this proposal=E2= =80=94anyone who might participate, better safeguards, or thoughts on the mechanism as a whole. We hope it will help the working group evolve its protocols more smoothly in the future. David --000000000000054091056e7459ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Now that TLS 1.3 is = about done, perhaps it is time to reflect on the ossification problems.

TLS is an extensible protocol. TLS 1.3 is backwards-c= ompatible and may be incrementally rolled out in an existing compliant TLS = 1.2 deployment. Yet we had problems. Widespread non-compliant servers broke= on the TLS 1.3 ClientHello, so versioning moved to supported_versions. Wid= espread non-compliant middleboxes attempted to parse someone else=E2=80=99s= ServerHellos, so the protocol was further hacked to weave through their ma= ny defects.

I think I can speak for the working gr= oup that we do not want to repeat this adventure again. In general, I think= the response to ossification is two-fold:

1. It= =E2=80=99s already happened, so how do we progress today?
2. How = do we avoid more of this tomorrow?

The workarounds= only answer the first question. For the second, TLS 1.3 has a section whic= h spells out a few protocol invariants.= It is all corollaries of existing TLS specification text, but hopefully do= cumenting it explicitly will help. But experience has shown specification t= ext is only necessary, not sufficient.

For extensi= bility problems in servers, we have GREASE. This enforces the k= ey rule in ClientHello processing: ignore unrecognized parameters. GREASE e= nforces this by filling the ecosystem with them. TLS 1.3=E2=80=99s middlebo= x woes were different. The key rule is: if you did not produce a ClientHell= o, you cannot assume that you can parse the response. Analogously, we shoul= d fill the ecosystem with such responses. We have an idea, but it is more i= nvolved than GREASE, so we are very interested in the TLS community=E2=80= =99s feedback.

In short, we plan to regularly mint= new TLS versions (and likely other sensitive parameters such as extensions= ), roughly every six weeks matching Chrome=E2=80=99s release cycle. Chrome,= Google servers, and any other deployment that wishes to participate, would= support two (or more) versions of TLS 1.3: the standard stable 0x0304, and= a rolling alternate version. Every six weeks, we would randomly pick a new= code point. These versions will otherwise be identical to TLS 1.3, save ma= ybe minor details to separate keys and exercise allowed syntax changes. The= goal is to pave the way for future versions of TLS by simulating them (=E2= =80=9Cdraft negative one=E2=80=9D).

Of course, thi= s scheme has some risk. It grabs code points everywhere. Code points are pl= entiful, but we do sometimes have collisions (e.g. 26 and 40). The entire p= oint is to serve and maintain TLS=E2=80=99s extensibility, so we certainly = do not wish to hamper it! Thus we have some safeguards in mind:
<= br>
* We will document every code point we use and what it refers= to. (If the volume is fine, we can email them to the list each time.) New = allocations can always avoid the lost numbers. At a rate of one every 6 wee= ks, it will take over 7,000 years to exhaust everything.

* We will avoid picking numbers that the IETF is likely to allocate,= to reduce the chance of collision. Rolling versions will not start with 0x= 03, rolling cipher suites or extensions will not be contiguous with existin= g blocks, etc.

* BoringSSL will not enable this by= default. We will only enable it where we can shut it back off. On our serv= ers, we of course regularly deploy changes. Chrome is also regularly update= d and, moreover, we will gate it on our server-controlled fie= ld trials mechanism. We hope that, in practice, only the last several c= ode points will be in use at a time.

*=C2=A0Our cl= ients would only support the most recent set of rolling parameters, and our= servers the last handful. As each value will be short-lived, the ecosystem= is unlikely to rely on them as de facto standards. Conversely, like other = extensions, implementations without them will still interoperate fine. We w= ould never offer a rolling parameter without the corresponding stable one.<= /div>

*=C2=A0If this ultimately does not work, we can st= op at any time and only have wasted a small portion of code points.

* Finally, if the working group is open to it, these valu= es could be summarized in regular documents to reserve them, so that they a= re ultimately reflected in the registries. A new document every six weeks i= s probably impractical, but we can batch them up.

= We are interested in the community=E2=80=99s feedback on this proposal=E2= =80=94anyone who might participate, better safeguards, or thoughts on the m= echanism as a whole. We hope it will help the working group evolve its prot= ocols more smoothly in the future.

David
--000000000000054091056e7459ce-- From nobody Tue Jun 12 10:41:35 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F34C130F83 for ; Tue, 12 Jun 2018 10:41:31 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THrxyzUdDq-L for ; Tue, 12 Jun 2018 10:41:28 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002: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 0FBF0130F73 for ; Tue, 12 Jun 2018 10:41:28 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id x36-v6so8240773ybi.0 for ; Tue, 12 Jun 2018 10:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=nBIXkIcRVypUDj5saRGSEloXn/7HCspJ7o2g3pBZCoo=; b=ZKjzSjeYkmxyH+8vyJ/XJEA/paqn0QzgsY9Sd9n20Mkxf+6pLzIFFGXDdwMN3Q8oGl HIFk5JYXcU2TcKSnWnctLKQYTHLXznvUf/dXPJHC+uTtXLSECOtRZLxqO4a9EdXVWqOM rfi4r8aqooXSWonQsHaw0G+s1+DC/GTLrWx0UE5V8rwdre+17eQOnor9crmPISACGiBl 9Tl2UDfVoE7wDOKc3+COd7BIp19GBP1ak8KeAA0t/13yAHFqd9nXysT9C8akYCLnsoCx 9JSLVeGtlPXeIS8DKvkfEDCcidw5L2E0Wh80IqS2BA8IFrPIth9GOdz7KyHzXSgtQmca eLtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nBIXkIcRVypUDj5saRGSEloXn/7HCspJ7o2g3pBZCoo=; b=LkmVJF5jL93a99T1o1SdFYJ6YZYdlyrTGq5MThm4yrq8CtzK/EAEoAmyOeFCdCsRoS 5UOKP7p8lOJUdNlQRgx6OAFoSe9Low56fSrfrvMWX7taBpkCTkYSXoTdO5I1UKEtrMwT 64FhtHW+1emVjOjD9hOEYlWiW5CUaxmNdt2t2Ef0Zbr0EKYggA17k8eG6aYz3eIAqKi4 tX1CfsbSRbOSJLQKh7hs99AD9CH/iEqhNhDZp9Vh9YWGWoOvD2jP26KpLql6Kwj3jrOY 6wk+GUpNUqsGN98ZcJUhullVx6pX6kFzzWbZNjtXboknGrCOgsP+MKBHAjPZ7wghlnL8 qhxA== X-Gm-Message-State: APt69E3ABcjO9O0KI9Bp8BeadkxQqRY6cDfj151IhR0sQJisQEwoq/qq pYaSmrs5QhZKUCsteeCmR+kBvM9ebUSOZE6I+xp29/Oe X-Google-Smtp-Source: ADUXVKIh/s3ysIgY4y0i9SBbBLTAbKKtIaf0ujzEJRfP4pbkfa6TbaT2qvKRDWAAGokrQBxChaHRNBXXnMZmAgvF76Q= X-Received: by 2002:a25:888e:: with SMTP id d14-v6mr670305ybl.506.1528825287003; Tue, 12 Jun 2018 10:41:27 -0700 (PDT) MIME-Version: 1.0 From: Christopher Wood Date: Tue, 12 Jun 2018 10:41:15 -0700 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] CH padding extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2018 17:41:32 -0000 Hi folks, In Section 4.2 of the latest TLS 1.3 draft [1], the padding(21) extension is restricted to the CH and no other handshake messages. Another plausible spot for this extension is in the Certificate message. Specifically, although we're encrypting this message, we may not want to reveal its length. Adding a padding extension seems to address that problem. Granted, RFC7685 [2] clearly indicates that this padding is for the CH, and that server "MUST NOT echo the extension." However, I don't think that rules out server-chosen padding for the Certificate. What do others think? Is this worth a change? Best, Chris [1] https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.2 [2] https://tools.ietf.org/html/rfc7685 From nobody Tue Jun 12 10:55:43 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD819130F7F for ; Tue, 12 Jun 2018 10:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=dfZehhH7; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=X0lfcV/5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxWy-KlhHBFe for ; Tue, 12 Jun 2018 10:55:32 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 A9E13130F94 for ; Tue, 12 Jun 2018 10:55:32 -0700 (PDT) Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5CHgenk014849; Tue, 12 Jun 2018 10:55:30 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=facebook; bh=msyoaN3oI8h14ZbbF4M/GxHLoeGjibPyaLRxC1Nv1P4=; b=dfZehhH78jB02+/7trbeUXilaamnoAndy3m0Mvukkj/3wXdw5vAXuht6/5UJCsSqQRwb lVsW/Q9loPgDkKpilEFMTxC/be4djnCzqWWutDbds6PQdbwNsPJaiWz3h6qctRRXuX+/ 2/cHj+i9QYpS7xyc1LnFQrSs9D4eOzdpsjQ= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2jjj2y06qx-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Jun 2018 10:55:30 -0700 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.26) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 12 Jun 2018 13:55:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=msyoaN3oI8h14ZbbF4M/GxHLoeGjibPyaLRxC1Nv1P4=; b=X0lfcV/5pxqcULQZBnN9glVMTmPQcwYl6l3ZNbF5jQuQ5eTKDONWTm4OTiacXw+4N/a6u8ewo+Nrsslol8x2lieUCeYB728Z2zfFEW2mxIHVk9B5xar7BT4wgzw2pwsTclRejQl3btg/6x3iw8TFYjLAhC2BF963wei7jmvCP8c= Received: from MWHPR15MB1504.namprd15.prod.outlook.com (10.173.235.13) by MWHPR15MB1584.namprd15.prod.outlook.com (10.173.235.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.14; Tue, 12 Jun 2018 17:55:26 +0000 Received: from MWHPR15MB1504.namprd15.prod.outlook.com ([fe80::d0b7:5e1e:5350:41d2]) by MWHPR15MB1504.namprd15.prod.outlook.com ([fe80::d0b7:5e1e:5350:41d2%3]) with mapi id 15.20.0841.019; Tue, 12 Jun 2018 17:55:26 +0000 From: Kyle Nekritz To: Christopher Wood , "" Thread-Topic: [TLS] CH padding extension Thread-Index: AQHUAnS4tmF+Dsy0E0SDfsL2VX4VzqRc53Fw Date: Tue, 12 Jun 2018 17:55:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c091:200::b3dd] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1584; 7:aktPlUooCgSLueyQ1+8L+pWdxo1xwKFZRIyZEwFMN/Y1NsL9r5AGfiyEaNn2CZxDILg2YWK2oMw4dQV8ti1t3BsFnl6FV15D2vC/rfY/vEAd7RY7RTzZBBRdnldm//H46yZgQhJxRMQLUotVLBvB093ei97iazPIc3SsKyxs+AfX+u+QYckaOAKh5+L+yPJOuy6OZ3DIc5iC/v4mBPINBOT+Ppd5rGTukc88tUv/hDALMoCzUpNhd+O0fsFqTJbs; 20:MfNmXXDL4/QutvVtIk5q74nps/jyvX9Vu8b4IKb5EsBra8YbfYljjFvDDBBxEXmRP2WTvdxuuHJum+1i04lW9lUSDNOycZjGDOzTV3yzkMluKpk2kR9rJNMR9WyX3AUdvbQBdh5W/PEOU6V8QsrFGZVfnPPakGwzvikxflGnoY0= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1584; x-ms-traffictypediagnostic: MWHPR15MB1584: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(11241501184)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(149027)(150027)(6041310)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:MWHPR15MB1584; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1584; x-forefront-prvs: 07013D7479 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(366004)(376002)(396003)(346002)(189003)(199004)(13464003)(446003)(3280700002)(2906002)(86362001)(486006)(5660300001)(11346002)(3660700001)(6246003)(6116002)(76176011)(7696005)(966005)(105586002)(7736002)(9686003)(68736007)(305945005)(476003)(14454004)(53936002)(229853002)(186003)(39060400002)(575784001)(74316002)(59450400001)(97736004)(102836004)(106356001)(6506007)(478600001)(53546011)(6306002)(25786009)(110136005)(6436002)(8936002)(33656002)(55016002)(5250100002)(316002)(81156014)(8676002)(46003)(99286004)(81166006)(2900100001)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1584; H:MWHPR15MB1504.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: DGxbrTSMSvH3kKWaVo29wRuJYi6UM89UGfF/1/G5LxDbWbZInfPkW7UENK4VBg1CqoUSgEVsf75qMXoHBcdLOyeD+wDPM13y5HV7hX/C5uUq15cA9cZd40uXrCr/7UlpRe6kqXLSROP85InKRLH7elo3xCT2vQZilu0ON7ExZPvlSCUY14N4SOuMk5RYzAyy spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: a3e85d6d-9e9d-40e5-4aa0-08d5d08dadda X-MS-Exchange-CrossTenant-Network-Message-Id: a3e85d6d-9e9d-40e5-4aa0-08d5d08dadda X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2018 17:55:26.6802 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1584 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-12_01:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [TLS] CH padding extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2018 17:55:41 -0000 Since the Certificate message is sent in an encrypted record, the normal re= cord padding mechanism (section 5.4) can be used, rather than sending the p= adding as actual handshake data. -----Original Message----- From: TLS On Behalf Of Christopher Wood Sent: Tuesday, June 12, 2018 1:41 PM To: Subject: [TLS] CH padding extension Hi folks, In Section 4.2 of the latest TLS 1.3 draft [1], the padding(21) extension i= s restricted to the CH and no other handshake messages. Another plausible spot for this extension is in the Certificate message. Sp= ecifically, although we're encrypting this message, we may not want to reve= al its length. Adding a padding extension seems to address that problem. Gr= anted, RFC7685 [2] clearly indicates that this padding is for the CH, and t= hat server "MUST NOT echo the extension." However, I don't think that rules out server-chosen padding for the Certifi= cate. What do others think? Is this worth a change? Best, Chris [1] https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_h= tml_draft-2Dietf-2Dtls-2Dtls13-2D28-23section-2D4.2&d=3DDwICAg&c=3D5VD0RTtN= lTh3ycd41b3MUw&r=3Dl2j4BjkO0Lc3u4CH2z7jPw&m=3DNoLDoqqN97BKYlmPkPtLv4JlT3y32= nA2pmpAcfRDGDc&s=3DULkmSYAHjmTYA-5NcfzbLoiexbGrO9m-LTuTZoMz_T8&e=3D [2] https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_h= tml_rfc7685&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dl2j4BjkO0Lc3u4CH2z7jP= w&m=3DNoLDoqqN97BKYlmPkPtLv4JlT3y32nA2pmpAcfRDGDc&s=3DDCiLNYn2n-dm1n-a96cwN= up4Yrm8jxj66ynWdfUIzOY&e=3D _______________________________________________ TLS mailing list TLS@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_tls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dl2j4BjkO0Lc3u4CH2z7= jPw&m=3DNoLDoqqN97BKYlmPkPtLv4JlT3y32nA2pmpAcfRDGDc&s=3DgqkkU78PTKoxJ2uHr1Y= onppiXHwkRP3SRTPlEnP4iE8&e=3D From nobody Tue Jun 12 11:00:58 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7627130F96 for ; Tue, 12 Jun 2018 11:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U73uEvc_nn9e for ; Tue, 12 Jun 2018 11:00:53 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002: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 6F520130E79 for ; Tue, 12 Jun 2018 11:00:53 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id w13-v6so7813946ywa.5 for ; Tue, 12 Jun 2018 11:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jl5KnomardttOIADxw8lUIcmyOIgk1zjhJIVO1JXUPg=; b=mLQtxGwoK0lnjecwg5uC4vFmxaAprdJfiRYDoz2c894tRa4YFL1ctAnOq20nCvpc7U YRaN9Xy3acWphdoXFtQ+ghp4KJKZx6blcaQbxwESoVRR0Np27esZilmOzdDA4KtNH3av Pev00RE4De7wxdSoGJ/KGDYBXljels0vSKgowaxkGEUNHl4pZzSDUx7q+x2zAZredrzi ZDt2C8bLhU59qakGJHh6i6PIR2cHBPr2JKr6Qbcw7HUCGu/rCZzQqUB2rPs9ub6nQgea 7LrEF8ZXy1QjWhnJzFj0m4bdj8IZFzqzE1pkwrseTwY9+cYap9uIt9V+EqPYu8MKGk2a dXwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jl5KnomardttOIADxw8lUIcmyOIgk1zjhJIVO1JXUPg=; b=PnwKk0RwpbfAF4Uvovti0QKmVPf2hhj3+tieWrTXh1HW+c0KKOaAQSNV7by2KZXXKi efbTvqgBBtfOMQb6Xj7jqJopA/lpxaheT2DvTkGtYIXwsT3eZmMrcB5dnwXa0aYqHmBJ U7nw4woH/BC8d470glnQ6fIQkW72xfW7I0qgPdVt+2gkDUwdOWlojfkjpnbRR4+sdM5K xVd+dWsRt3yUgrL2B8BY9Z4/XVy6dID6lTBqy3CgpSPaldG60OG8xoxeZret6JJriqXZ LA7Q1q0u3atCOPV8vZCbVzJ1G+/Q4oH9km4qdFjwk4IZXJoL40rsBFUQ4cl9jHBSTo5c e5yg== X-Gm-Message-State: APt69E3VSa5wMuEovocVJes8wdJ8Gy01n/CwK23TpUXCRbi1IuJ0365y qXKjqWJLgKPiVFdeFFGGtdePCG8t+7t6D2TWDS0= X-Google-Smtp-Source: ADUXVKJutryL8EHRa9Fy3G1aYtLhlHPcCbDmoklIMvx7nKx0nmXk9jUiQIyAV6qeKOvCx/0K6kgrP91ezfPxWXQw98E= X-Received: by 2002:a81:e82:: with SMTP id 124-v6mr675340ywo.79.1528826452432; Tue, 12 Jun 2018 11:00:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Wood Date: Tue, 12 Jun 2018 11:00:40 -0700 Message-ID: To: Kyle Nekritz Cc: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] CH padding extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2018 18:00:56 -0000 On Tue, Jun 12, 2018 at 10:55 AM Kyle Nekritz wrote: > > Since the Certificate message is sent in an encrypted record, the normal record padding mechanism (section 5.4) can be used, rather than sending the padding as actual handshake data. Of course, and that requires padding on the fly and some way for the sender to know what is the correct amount of padding per Certificate. Plumbing up that API seems non-trivial. In comparison, one could imagine pre-padding wire-encoded Certificate messages a priori using the extension. So I still think restricting padding to CH is a bit extreme. Best, Chris From nobody Tue Jun 12 11:32:36 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E534E130E91 for ; Tue, 12 Jun 2018 11:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.95 X-Spam-Level: X-Spam-Status: No, score=-9.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwFCnBwO54wz for ; Tue, 12 Jun 2018 11:32:30 -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 85763130E90 for ; Tue, 12 Jun 2018 11:32:30 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id j80-v6so15667410qke.9 for ; Tue, 12 Jun 2018 11:32:30 -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 :cc; bh=ysR+ex4TYf7Pn2EjPJpYDWl3Qv/LIvVTbEFBgjoBwIk=; b=j27VsupqlP5kP2IolHsadG470h5uuD+r3haxqwu23H6pqNSyF+9RfX1VwdeekyI+2l OKdpDVkiwkcJbWXypJNwwNDS/7HKBcbgyo7cN93KpHan2bXuEmUiT1qsrWUiL8WI4ym1 Y24uwdOcvGkc9EQzUilDyxaGstIthvjHyf/QI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ysR+ex4TYf7Pn2EjPJpYDWl3Qv/LIvVTbEFBgjoBwIk=; b=Ys3F1s7WmssyFCyUD2uH0K66/yw6Hoo9hMNQdOaXiJ2lJPlfttD+mZ2BYhDzPCuYoO OWrtfZYZqE8xpNI0HcN55eDDtdp+YtSdgS5kObpf9oCUed7+g1uy4mRleUznWChCkMcs HymxofUM7CUGny7vQ1VaVjyRXXyzec8DGGogvKU3GbvVRxNq3M4Gh/Xwkp5rtK1QX8Zc HtvmcciIOP24ZJaep+AQs2G6WZWZg2G8ue7hp83IK4sDMH6blTo1KA3u6NgHTF4IX1We fnRq4nc9+pKyBcxnaEnefPhjGn3yhpGFCDFL0nCfG4ph+Rmj5sM6N1aLelNrR67nC9KW XFQg== X-Gm-Message-State: APt69E30ysKOERpm2MXxBhyWiXHoC2BUvn0Fduy10p4kTXpVtpAocbR8 s1IpEvIHWtY9mnte8Uie4EdKUOLgCZgXtoRRAKh7JhQ= X-Google-Smtp-Source: ADUXVKJvHapaY5tSa82IaUkFP+GRNmsKe7SGngbqfnTza60Cz5Ez0U3cRG2150AM2Sr/ZdaCqkiQIdpCpYDXSIA4X/E= X-Received: by 2002:a37:285e:: with SMTP id o91-v6mr1555901qkh.129.1528828349196; Tue, 12 Jun 2018 11:32:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Tue, 12 Jun 2018 14:32:16 -0400 Message-ID: To: Christopher Wood Cc: Kyle Nekritz , "" Content-Type: multipart/alternative; boundary="000000000000ae2e46056e7616d1" Archived-At: Subject: Re: [TLS] CH padding extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2018 18:32:34 -0000 --000000000000ae2e46056e7616d1 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 12, 2018 at 2:01 PM Christopher Wood < christopherwood07@gmail.com> wrote: > On Tue, Jun 12, 2018 at 10:55 AM Kyle Nekritz wrote: > > > > Since the Certificate message is sent in an encrypted record, the normal > record padding mechanism (section 5.4) can be used, rather than sending the > padding as actual handshake data. > > Of course, and that requires padding on the fly and some way for the > sender to know what is the correct amount of padding per Certificate. > Plumbing up that API seems non-trivial. In comparison, one could > imagine pre-padding wire-encoded Certificate messages a priori using > the extension. So I still think restricting padding to CH is a bit > extreme. > Using the padding extension isn't going to mesh well with the compressed certificates draft. (Compression is perfectly compatible with hiding the length. If all your certificates compress well---they probably do---you can pad based on the distribution of compressed lengths you're trying to mask. Of course, this will leak whether compression happened, but that's not the information that's interesting to hide.) Record-level padding is indeed kind of annoying to plumb properly though. I've always thought the excitement for padding at that layer was somewhat misplaced. I could imagine allowing handshake messages to be punctuated by no-op padding messages, but then it's just one layer to route through to get to the record layer here. I think it's more at higher up the stack where record-level padding really becomes impractical. David --000000000000ae2e46056e7616d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 12= , 2018 at 2:01 PM Christopher Wood <christopherwood07@gmail.com> wrote:
On Tue, Jun 12, 2018 at 10:55 AM Kyle Nekritz <knekritz@fb.com> wrot= e:
>
> Since the Certificate message is sent in an encrypted record, the norm= al record padding mechanism (section 5.4) can be used, rather than sending = the padding as actual handshake data.

Of course, and that requires padding on the fly and some way for the
sender to know what is the correct amount of padding per Certificate.
Plumbing up that API seems non-trivial. In comparison, one could
imagine pre-padding wire-encoded Certificate messages a priori using
the extension. So I still think restricting padding to CH is a bit
extreme.

Using the padding extension is= n't going to mesh well with the compressed certificates draft. (Compres= sion is perfectly compatible with hiding the length. If all your certificat= es compress well---they probably do---you can pad based on the distribution= of compressed lengths you're trying to mask. Of course, this will leak= whether compression happened, but that's not the information that'= s interesting to hide.)

Record-level padd= ing is indeed kind of annoying to plumb properly though. I've always th= ought the excitement for padding at that layer was somewhat misplaced. I co= uld imagine allowing handshake messages to be punctuated by no-op padding m= essages, but then it's just one layer to route through to get to the re= cord layer here. I think it's more at higher up the stack where record-= level padding really becomes impractical.

Da= vid
--000000000000ae2e46056e7616d1-- From nobody Tue Jun 12 11:44:59 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B14C130E91 for ; Tue, 12 Jun 2018 11:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRLv4I0hyXt9 for ; Tue, 12 Jun 2018 11:44:53 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002: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 A0779130E77 for ; Tue, 12 Jun 2018 11:44:53 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id p14-v6so7854850ywm.11 for ; Tue, 12 Jun 2018 11:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=O7L/eZM2dfVosrCV9qOTzrMKSbtTqCoaJzlGN4GEYoU=; b=mcz5++h0CVntM3kkSg1RzS2qB+OQnrNeQrvbTYS51p4UANCgWjUQub2zQ6v5pWpwnB e3VrBDvwrDML/Uy76xR6069w81XtAcYWgR6lyvjU3d4FHaxveNOr+iqPxCtak6JXjlg5 SfuPhQZ3kP7Ivm21a/zKo9fOxVaoOvC2vFQYIBL4l0KxEEgqi0MV5lxtDYtjiXQdJIDW ahxRDPozBn9RTZnQIiv0kXrnK7SXbmxSVhRNLXaZyvwMMlIw8wbI+U+Pl8dzW5ulBiXL IxZgwSmvgz21joShsULkA1CVa7fmIZKFGVIW8mjSwfjOZvsJ5PamELJYOKbc3WNWFVbg /mkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=O7L/eZM2dfVosrCV9qOTzrMKSbtTqCoaJzlGN4GEYoU=; b=CrBRWTdP8qDTYMc7EF8UPA2rdFyzez55DEnWvTOyfd6i7ZVrDUnXtIeQTjNjhNmpnG UySl1DfDtnzKIGZeGdE87xKgVKZhfT7uj09hHpT6VHCqWD3hNdtyuhg4sWLEtAUdmpF2 WlBOKXkNfcj7qjlsNAvD4f5zTza6nEUXZYZ2WRuaJMmf9ri+XOdgqR9qQ+xVd5J6em7a HLt8SYEl4gQ1eKxuESi+jRREamOSNxKWhf9rNPgtiyw0CFXq4pLNkQq1IrOQi65c6+nt 6b4zIMZviAaFdbgIe8JKLScjUdcg65JHCzd60ZZk78wesLFCOOtRsY0D2qXB5cNDdF9S whzw== X-Gm-Message-State: APt69E0wTFUHTZ7jurOvVXix17SnwFx6gXkqAAA1W0qDHOUZWVgZKv8q MwNczx/CECFxOHKg1nkOtMXQt7GJiVE5NplCKpw= X-Google-Smtp-Source: ADUXVKLdtn9yIJLb+S0FO696OPd8xXGKEvGehQP/gUHzC2TZ9ID+ZImUIOb+CA6jCfGO5w519lgGbp4UdspWVPFzHS0= X-Received: by 2002:a0d:e345:: with SMTP id m66-v6mr780904ywe.304.1528829092670; Tue, 12 Jun 2018 11:44:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Wood Date: Tue, 12 Jun 2018 11:44:41 -0700 Message-ID: To: David Benjamin Cc: Kyle Nekritz , "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] CH padding extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2018 18:44:57 -0000 On Tue, Jun 12, 2018 at 11:32 AM David Benjamin wro= te: > > On Tue, Jun 12, 2018 at 2:01 PM Christopher Wood wrote: >> >> On Tue, Jun 12, 2018 at 10:55 AM Kyle Nekritz wrote: >> > >> > Since the Certificate message is sent in an encrypted record, the norm= al record padding mechanism (section 5.4) can be used, rather than sending = the padding as actual handshake data. >> >> Of course, and that requires padding on the fly and some way for the >> sender to know what is the correct amount of padding per Certificate. >> Plumbing up that API seems non-trivial. In comparison, one could >> imagine pre-padding wire-encoded Certificate messages a priori using >> the extension. So I still think restricting padding to CH is a bit >> extreme. > > > Using the padding extension isn't going to mesh well with the compressed = certificates draft. (Compression is perfectly compatible with hiding the le= ngth. If all your certificates compress well---they probably do---you can p= ad based on the distribution of compressed lengths you're trying to mask. O= f course, this will leak whether compression happened, but that's not the i= nformation that's interesting to hide.) Yep, valid point. > > Record-level padding is indeed kind of annoying to plumb properly though.= I've always thought the excitement for padding at that layer was somewhat = misplaced. I could imagine allowing handshake messages to be punctuated by = no-op padding messages, but then it's just one layer to route through to ge= t to the record layer here. I think it's more at higher up the stack where = record-level padding really becomes impractical. To be clear, are you suggesting that adding a padding extension to the Certificate message is impractical? (I wouldn't consider this record-level padding.) Best, Chris From nobody Tue Jun 12 11:48:51 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AC7130E77 for ; Tue, 12 Jun 2018 11:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXoksITgr0B5 for ; Tue, 12 Jun 2018 11:48:47 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 642DD130E5A for ; Tue, 12 Jun 2018 11:48:47 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id s9-v6so8683qtg.2 for ; Tue, 12 Jun 2018 11:48:47 -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 :cc; bh=oycw0txyP1y/IdPnQtZbEdku6Crt6WsDL2BLEM8ciyg=; b=JNFIa5bXq4NN7uhuvi9Zuhfi+Xs93Z41T5OvndhBiQPLT2FnTEy21FJfvZ1X6OHVud L02uFfI/FbLZrNHh6mMR/aLkYxPmQg8ji53z7/GutDxNRWRlvuku+ZvxpvZNg41dof8F ojNiSBEZ7yfR4kVEtzz3RODffgBQWE8u6zgB0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oycw0txyP1y/IdPnQtZbEdku6Crt6WsDL2BLEM8ciyg=; b=NNfv+c6Dh3yNKUYEyaldkH5h1HXY7lpjR5e5jVogds79iNFBQqEIz3ePGg0lexLI/e 1WDG1sIC9iI8oUd7cXftjKs0nVb8UewUzTsFmaBuvBaEhJx/Ao0kTZJJFdUoShZm5OVt tJXhiTw4MgHrDzEZhaUXtcGGH2XLAF1gkrdxERzz41nf1sfN2FYR1ABTOTtu2SZ3XmDt Nhbw6baNL7wsWnAn87QJAeThLqqxoTogStsIss5i7hpmbpIPxRzUTiiMKBnhH23w0/JM bocIMhM7XTl/3JIiSHtYJicqJQIyMEoE1oDMGZvd2pm3vsBW69awO1zfn5irzTmGYQLt qtnQ== X-Gm-Message-State: APt69E0arhUHH6G+C744n1Qx4/t7E8Zj2w27uxGEupdeqytOfMD0HNHO uK1PbnTmFVDGigKiD43CC25+sZTCDzFDySEmFzqyQRU= X-Google-Smtp-Source: ADUXVKIUa2ufZ+7DZDn8UNmzX8nBncqHj4W2LJIF67JWX69ecvtuzDMnvLLWR+oXMlRj33KziuAy6xLu/NP2WU6zMKg= X-Received: by 2002:a0c:ada5:: with SMTP id w34-v6mr1715613qvc.58.1528829326348; Tue, 12 Jun 2018 11:48:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Tue, 12 Jun 2018 14:48:35 -0400 Message-ID: To: Christopher Wood Cc: Kyle Nekritz , "" Content-Type: multipart/alternative; boundary="000000000000ebe5a4056e765020" Archived-At: Subject: Re: [TLS] CH padding extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2018 18:48:50 -0000 --000000000000ebe5a4056e765020 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 12, 2018 at 2:44 PM Christopher Wood < christopherwood07@gmail.com> wrote: > On Tue, Jun 12, 2018 at 11:32 AM David Benjamin > wrote: > > > > On Tue, Jun 12, 2018 at 2:01 PM Christopher Wood < > christopherwood07@gmail.com> wrote: > >> > >> On Tue, Jun 12, 2018 at 10:55 AM Kyle Nekritz wrote: > >> > > >> > Since the Certificate message is sent in an encrypted record, the > normal record padding mechanism (section 5.4) can be used, rather than > sending the padding as actual handshake data. > >> > >> Of course, and that requires padding on the fly and some way for the > >> sender to know what is the correct amount of padding per Certificate. > >> Plumbing up that API seems non-trivial. In comparison, one could > >> imagine pre-padding wire-encoded Certificate messages a priori using > >> the extension. So I still think restricting padding to CH is a bit > >> extreme. > > > > > > Using the padding extension isn't going to mesh well with the compressed > certificates draft. (Compression is perfectly compatible with hiding the > length. If all your certificates compress well---they probably do---you can > pad based on the distribution of compressed lengths you're trying to mask. > Of course, this will leak whether compression happened, but that's not the > information that's interesting to hide.) > > Yep, valid point. > > > > > Record-level padding is indeed kind of annoying to plumb properly > though. I've always thought the excitement for padding at that layer was > somewhat misplaced. I could imagine allowing handshake messages to be > punctuated by no-op padding messages, but then it's just one layer to route > through to get to the record layer here. I think it's more at higher up the > stack where record-level padding really becomes impractical. > > To be clear, are you suggesting that adding a padding extension to the > Certificate message is impractical? (I wouldn't consider this > record-level padding.) > Sorry, that was probably unclear. What I meant was: I agree that record-level padding is pretty difficult to use in general, but this particular instance is probably(?) not too bad, so it seems sufficient to use the existing mechanism rather than make a wire-incompatible change (unsolicited Certificate extensions are forbidden) at this stage. Though I otherwise don't particularly object to jamming the padding extension into more places, the compressed certificates point aside. --000000000000ebe5a4056e765020 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 12= , 2018 at 2:44 PM Christopher Wood <christopherwood07@gmail.com> wrote:
=
On Tue, Jun 12, 2018 at 11:32 AM David= Benjamin <da= vidben@chromium.org> wrote:
>
> On Tue, Jun 12, 2018 at 2:01 PM Christopher Wood <christopherwood07@gmail.com= > wrote:
>>
>> On Tue, Jun 12, 2018 at 10:55 AM Kyle Nekritz <knekritz@fb.com> wrote:
>> >
>> > Since the Certificate message is sent in an encrypted record,= the normal record padding mechanism (section 5.4) can be used, rather than= sending the padding as actual handshake data.
>>
>> Of course, and that requires padding on the fly and some way for t= he
>> sender to know what is the correct amount of padding per Certifica= te.
>> Plumbing up that API seems non-trivial. In comparison, one could >> imagine pre-padding wire-encoded Certificate messages a priori usi= ng
>> the extension. So I still think restricting padding to CH is a bit=
>> extreme.
>
>
> Using the padding extension isn't going to mesh well with the comp= ressed certificates draft. (Compression is perfectly compatible with hiding= the length. If all your certificates compress well---they probably do---yo= u can pad based on the distribution of compressed lengths you're trying= to mask. Of course, this will leak whether compression happened, but that&= #39;s not the information that's interesting to hide.)

Yep, valid point.

>
> Record-level padding is indeed kind of annoying to plumb properly thou= gh. I've always thought the excitement for padding at that layer was so= mewhat misplaced. I could imagine allowing handshake messages to be punctua= ted by no-op padding messages, but then it's just one layer to route th= rough to get to the record layer here. I think it's more at higher up t= he stack where record-level padding really becomes impractical.

To be clear, are you suggesting that adding a padding extension to the
Certificate message is impractical? (I wouldn't consider this
record-level padding.)

Sorry, that was probably unclear. What I = meant was: I agree that record-level padding is pretty difficult to use in = general, but this particular instance is probably(?) not too bad, so it see= ms sufficient to use the existing mechanism rather than make a wire-incompa= tible change (unsolicited Certificate extensions are forbidden) at this sta= ge.

Though I otherwise don't particularly obje= ct to jamming the padding extension into more places, the compressed certif= icates point aside.
--000000000000ebe5a4056e765020-- From nobody Tue Jun 12 12:08:05 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC6D130E7C for ; Tue, 12 Jun 2018 12:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DV5suo7E8jLX for ; Tue, 12 Jun 2018 12:08:01 -0700 (PDT) Received: from mail-pl0-x236.google.com (mail-pl0-x236.google.com [IPv6:2607:f8b0:400e:c01::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 1540F130E77 for ; Tue, 12 Jun 2018 12:08:01 -0700 (PDT) Received: by mail-pl0-x236.google.com with SMTP id c23-v6so16011plz.12 for ; Tue, 12 Jun 2018 12:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=jl8w81GWu6111ibzbNTLMS/jlO3eZLqz2Kzb9N4XhwY=; b=YC/Pzlvza0GTXi30pNT8ytGH47ZhZsqKtDdnJRXaJ9l4dPMcF9fnkeHF9wOa3yWWly NoX8TJgNoi4Omva7hdaAF4mBbdCZBaukGTCDNPJuobs+rFk6R/hisH4+za4cRPPi/YVO MSYKsR957ThWHsoUrUcvwtM3vHXvGiSIsZREJulusE6REnExvSOXWBNBiwqfkH0tPrT8 3dBVPdEVNulBFHRIX+JJGMzlNGopDcXp11P2ZqWLG/dJAgHskMcLz50uzeqWAsUUX22X /+0AS+p9oeEk+OxsSOtG4IR1MWxiMLTslqLCuvh9Q0HiHzobkCiesAf315qrbY52dVxI FQhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=jl8w81GWu6111ibzbNTLMS/jlO3eZLqz2Kzb9N4XhwY=; b=DCM4i1uFqXFSV+RAaYd3adPcCwBUbcT7oTnBIS0guNKJolENe9Knn+GqcU6CVD++0N Z7UzOooy93fiPzFM8ZauN2b/IuEX9WXNJrWZ1Mw8f9gOTvIGicKqMpQ6Lt5MPreR6j/H b99LldCJXW4G3dA0QWAsGq83umt0upoeoT3aQO0Vq33/qx0nCbyTKSTDH3vmwxwDoF8q CSxDgI5SOj3G2ZajeCtrUqzngYE9kotHd9yT/zgI7d7o2O4Lxkg6eAp7YA32c+WrpBCM +VfyYtrWL8z3nCajNz4ErzSmJPDEXK16qXa0yi2NyXay8J6hgTtc5A83HWJ1MDEtxPec scTQ== X-Gm-Message-State: APt69E10qjK0z5u6BZi60ie3Fyj37a8WtVlAd8aCfIPhTtpA7meZhxcs xjuNDnGhmodR4EbtIg0QQ5A= X-Google-Smtp-Source: ADUXVKIv9I4R+h2PE5sB2VQZSukpeXC8MkuQROD9gdpemFOGspm8qCk5upTWSNuug4AgpKqz6gZa+Q== X-Received: by 2002:a17:902:7888:: with SMTP id q8-v6mr1755656pll.79.1528830479727; Tue, 12 Jun 2018 12:07:59 -0700 (PDT) Received: from [2600:1010:b01d:a8c0:1::] ([2600:1010:b01d:a8c0:7544:76d2:9562:4160]) by smtp.gmail.com with ESMTPSA id y18-v6sm965228pfl.122.2018.06.12.12.07.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jun 2018 12:07:59 -0700 (PDT) Date: Tue, 12 Jun 2018 12:07:31 -0700 From: Christopher Wood To: David Benjamin Cc: Kyle Nekritz , "=?utf-8?Q??=" Message-ID: <020e7b24-1015-4b6a-817c-0c12d754875d@Spark> In-Reply-To: References: X-Readdle-Message-ID: 020e7b24-1015-4b6a-817c-0c12d754875d@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5b201a05_625558ec_45b2" Archived-At: Subject: Re: [TLS] CH padding extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2018 19:08:04 -0000 --5b201a05_625558ec_45b2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Got it =E2=80=94 thanks for the clarification=21 I agree with your conclu= sion assuming we do not want to make an incompatible wire format change. = However, if we=E2=80=99re willing to budge on that, I think it=E2=80=99s = worth including. I=E2=80=99m curious to hear what others think. Best, Chris On Jun 12, 2018, 11:48 AM -0700, David Benjamin = , wrote: > > On Tue, Jun 12, 2018 at 2:44 PM Christopher Wood wrote: > > > On Tue, Jun 12, 2018 at 11:32 AM David Benjamin wrote: > > > > > > > > On Tue, Jun 12, 2018 at 2:01 PM Christopher Wood wrote: > > > >> > > > >> On Tue, Jun 12, 2018 at 10:55 AM Kyle Nekritz wrote: > > > >> > > > > >> > Since the Certificate message is sent in an encrypted record, = the normal record padding mechanism (section 5.4) can be used, rather tha= n sending the padding as actual handshake data. > > > >> > > > >> Of course, and that requires padding on the fly and some way for= the > > > >> sender to know what is the correct amount of padding per Certifi= cate. > > > >> Plumbing up that API seems non-trivial. In comparison, one could= > > > >> imagine pre-padding wire-encoded Certificate messages a priori u= sing > > > >> the extension. So I still think restricting padding to CH is a b= it > > > >> extreme. > > > > > > > > > > > > Using the padding extension isn't going to mesh well with the com= pressed certificates draft. (Compression is perfectly compatible with hid= ing the length. If all your certificates compress well---they probably do= ---you can pad based on the distribution of compressed lengths you're try= ing to mask. Of course, this will leak whether compression happened, but = that's not the information that's interesting to hide.) > > > > > > Yep, valid point. > > > > > > > > > > > Record-level padding is indeed kind of annoying to plumb properly= though. I've always thought the excitement for padding at that layer was= somewhat misplaced. I could imagine allowing handshake messages to be pu= nctuated by no-op padding messages, but then it's just one layer to route= through to get to the record layer here. I think it's more at higher up = the stack where record-level padding really becomes impractical. > > > > > > To be clear, are you suggesting that adding a padding extension to = the > > > Certificate message is impractical=3F (I wouldn't consider this > > > record-level padding.) > > > > Sorry, that was probably unclear. What I meant was: I agree that reco= rd-level padding is pretty difficult to use in general, but this particul= ar instance is probably(=3F) not too bad, so it seems sufficient to use t= he existing mechanism rather than make a wire-incompatible change (unsoli= cited Certificate extensions are forbidden) at this stage. > > > > Though I otherwise don't particularly object to jamming the padding e= xtension into more places, the compressed certificates point aside. --5b201a05_625558ec_45b2 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Got it =E2=80=94 thanks for the clar= ification=21 I agree with your conclusion assuming we do not want to make= an incompatible wire format change. However, if we=E2=80=99re willing to= budge on that, I think it=E2=80=99s worth including. I=E2=80=99m curious= to hear what others think.

Best,
Chris
On Jun 12, 2018, 11:48 AM -0700, Da= vid Benjamin <davidben=40chromium.org>, wrote:
On Tue, Jun 12, 2018 at 2:44 PM Christopher Wood <= ;christopherwood07=40gmail.com> wrote:
On Tue, Jun 12, 2018 at 11:3= 2 AM David Benjamin <davidben=40chromium.org> wrote:
>
> On Tue, Jun 12, 2018 at 2:01 PM Christopher Wood <christopher= wood07=40gmail.com> wrote:
>>
>> On Tue, Jun 12, 2018 at 10:55 AM Kyle Nekritz <knekritz=40fb.com&= gt; wrote:
>> >
>> > Since the Certificate message is sent in an encrypted recor= d, the normal record padding mechanism (section 5.4) can be used, rather = than sending the padding as actual handshake data.
>>
>> Of course, and that requires padding on the fly and some way for= the
>> sender to know what is the correct amount of padding per Certifi= cate.
>> Plumbing up that API seems non-trivial. In comparison, one could=
>> imagine pre-padding wire-encoded Certificate messages a priori u= sing
>> the extension. So I still think restricting padding to CH is a b= it
>> extreme.
>
>
> Using the padding extension isn't going to mesh well with the compre= ssed certificates draft. (Compression is perfectly compatible with hiding= the length. If all your certificates compress well---they probably do---= you can pad based on the distribution of compressed lengths you're trying= to mask. Of course, this will leak whether compression happened, but tha= t's not the information that's interesting to hide.)

Yep, valid point.

>
> Record-level padding is indeed kind of annoying to plumb properly th= ough. I've always thought the excitement for padding at that layer was so= mewhat misplaced. I could imagine allowing handshake messages to be punct= uated by no-op padding messages, but then it's just one layer to route th= rough to get to the record layer here. I think it's more at higher up the= stack where record-level padding really becomes impractical.

To be clear, are you suggesting that adding a padding extension to the Certificate message is impractical=3F (I wouldn't consider this
record-level padding.)

Sorry, that was probably unclear. What I meant was: I agree that rec= ord-level padding is pretty difficult to use in general, but this particu= lar instance is probably(=3F) not too bad, so it seems sufficient to use = the existing mechanism rather than make a wire-incompatible change (unsol= icited Certificate extensions are forbidden) at this stage.

Though I otherwise don't particularly object to jamming the padding = extension into more places, the compressed certificates point aside.
--5b201a05_625558ec_45b2-- From nobody Tue Jun 12 12:21:42 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E17130E92 for ; Tue, 12 Jun 2018 12:21:38 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nerd.ninja Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYMiw70YW98c for ; Tue, 12 Jun 2018 12:21:32 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D231130E91 for ; Tue, 12 Jun 2018 12:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1528831290; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Message-Id:References:To; l=11161; bh=BWjYfD45Rf5FwgN3r5UVsAKcqWYjBBTBwP5uOhkI2sg=; b=SEKZR9n3LRwXj/B0MFVZ2mBbX3NSzut9/BE/I1mlSubNK4931IwGT+shquzZN7Uz 7p/nQzJw6SI9fXCXLcBKV6DkGmEIdJ1M2Sb47pM6loF95UEQd/u2oUKjnDU5M/P+Y+v U7sBXZTUH1TTB4F5QOMXUja7zgPZfxfws126AZbA= Received: from roelofs-mbp.lan (dynamic-acs-24-112-242-116.zoominternet.net [24.112.242.116]) by mx.zohomail.com with SMTPS id 1528831290105395.34230972581554; Tue, 12 Jun 2018 12:21:30 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9BCBEBC9-48D0-491A-A05B-3485FF96365A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Roelof duToit In-Reply-To: <020e7b24-1015-4b6a-817c-0c12d754875d@Spark> Date: Tue, 12 Jun 2018 15:21:37 -0400 Cc: David Benjamin , "" Message-Id: <46BFFD29-7823-463E-A90D-7EF59AD93C61@nerd.ninja> References: <020e7b24-1015-4b6a-817c-0c12d754875d@Spark> To: Christopher Wood X-Mailer: Apple Mail (2.3124) X-ZohoMailClient: External Archived-At: Subject: Re: [TLS] CH padding extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2018 19:21:39 -0000 --Apple-Mail=_9BCBEBC9-48D0-491A-A05B-3485FF96365A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 You could use the existing Certificate padding mechanism. Which = mechanism?! The one in this paragraph: For maximum compatibility, all implementations SHOULD be prepared to = handle potentially extraneous certificates and arbitrary orderings from any TLS version, with the exception of the end-entity certificate which MUST be first. I ran an experiment a while ago in which all major browsers (at that = point) accepted an arbitrary X.509 certificate in the Certificate = message. In other words, you could just build a blob that looks like a = DER encoded X.509 certificate and include it in the chain. It is indeed a hack, but in all seriousness, would the client endpoint = stacks even bother to change that behavior? (disclaimer: I have not = checked the latest behavior). --Roelof > On Jun 12, 2018, at 3:07 PM, Christopher Wood = wrote: >=20 > Got it =E2=80=94 thanks for the clarification! I agree with your = conclusion assuming we do not want to make an incompatible wire format = change. However, if we=E2=80=99re willing to budge on that, I think = it=E2=80=99s worth including. I=E2=80=99m curious to hear what others = think. >=20 > Best, > Chris > On Jun 12, 2018, 11:48 AM -0700, David Benjamin = , wrote: >> On Tue, Jun 12, 2018 at 2:44 PM Christopher Wood = > = wrote: >> On Tue, Jun 12, 2018 at 11:32 AM David Benjamin = > wrote: >> > >> > On Tue, Jun 12, 2018 at 2:01 PM Christopher Wood = > = wrote: >> >> >> >> On Tue, Jun 12, 2018 at 10:55 AM Kyle Nekritz > wrote: >> >> > >> >> > Since the Certificate message is sent in an encrypted record, = the normal record padding mechanism (section 5.4) can be used, rather = than sending the padding as actual handshake data. >> >> >> >> Of course, and that requires padding on the fly and some way for = the >> >> sender to know what is the correct amount of padding per = Certificate. >> >> Plumbing up that API seems non-trivial. In comparison, one could >> >> imagine pre-padding wire-encoded Certificate messages a priori = using >> >> the extension. So I still think restricting padding to CH is a bit >> >> extreme. >> > >> > >> > Using the padding extension isn't going to mesh well with the = compressed certificates draft. (Compression is perfectly compatible with = hiding the length. If all your certificates compress well---they = probably do---you can pad based on the distribution of compressed = lengths you're trying to mask. Of course, this will leak whether = compression happened, but that's not the information that's interesting = to hide.) >>=20 >> Yep, valid point. >>=20 >> > >> > Record-level padding is indeed kind of annoying to plumb properly = though. I've always thought the excitement for padding at that layer was = somewhat misplaced. I could imagine allowing handshake messages to be = punctuated by no-op padding messages, but then it's just one layer to = route through to get to the record layer here. I think it's more at = higher up the stack where record-level padding really becomes = impractical. >>=20 >> To be clear, are you suggesting that adding a padding extension to = the >> Certificate message is impractical? (I wouldn't consider this >> record-level padding.) >>=20 >> Sorry, that was probably unclear. What I meant was: I agree that = record-level padding is pretty difficult to use in general, but this = particular instance is probably(?) not too bad, so it seems sufficient = to use the existing mechanism rather than make a wire-incompatible = change (unsolicited Certificate extensions are forbidden) at this stage. >>=20 >> Though I otherwise don't particularly object to jamming the padding = extension into more places, the compressed certificates point aside. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_9BCBEBC9-48D0-491A-A05B-3485FF96365A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
You could use the existing Certificate = padding mechanism.  Which mechanism?!   The one in this = paragraph:

For maximum compatibility, all implementations =
SHOULD be prepared to handle
potentially extraneous certificates and arbitrary orderings from any
TLS version, with the exception of the end-entity certificate which
MUST be first.

I ran an experiment a while ago in which all major browsers = (at that point) accepted an arbitrary X.509 certificate in the = Certificate message.   In other words, you could just build a blob = that looks like a DER encoded X.509 certificate and include it in the = chain.

It is = indeed a hack, but in all seriousness, would the client endpoint stacks = even bother to change that behavior? (disclaimer: I have not checked the = latest behavior).

--Roelof



On Jun 12, 2018, at 3:07 PM, = Christopher Wood <christopherwood07@gmail.com> wrote:

Got it =E2=80=94 thanks for = the clarification! I agree with your conclusion assuming we do not want = to make an incompatible wire format change. However, if we=E2=80=99re = willing to budge on that, I think it=E2=80=99s worth including. I=E2=80=99= m curious to hear what others think.

Best,
Chris
On Jun 12, 2018, 11:48 AM = -0700, David Benjamin <davidben@chromium.org>, wrote:
On Tue, Jun 12, 2018 at 2:44 PM Christopher = Wood <christopherwood07@gmail.com> wrote:
=
On Tue, Jun 12, 2018 = at 11:32 AM David Benjamin <davidben@chromium.org> wrote:
>
> On Tue, Jun 12, 2018 at 2:01 PM Christopher Wood <christopherwood07@gmail.com> wrote:
>>
>> On Tue, Jun 12, 2018 at 10:55 AM Kyle Nekritz <knekritz@fb.com> wrote:
>> >
>> > Since the Certificate message is sent in an encrypted = record, the normal record padding mechanism (section 5.4) can be used, = rather than sending the padding as actual handshake data.
>>
>> Of course, and that requires padding on the fly and some way = for the
>> sender to know what is the correct amount of padding per = Certificate.
>> Plumbing up that API seems non-trivial. In comparison, one = could
>> imagine pre-padding wire-encoded Certificate messages a priori = using
>> the extension. So I still think restricting padding to CH is a = bit
>> extreme.
>
>
> Using the padding extension isn't going to mesh well with the = compressed certificates draft. (Compression is perfectly compatible with = hiding the length. If all your certificates compress well---they = probably do---you can pad based on the distribution of compressed = lengths you're trying to mask. Of course, this will leak whether = compression happened, but that's not the information that's interesting = to hide.)

Yep, valid point.

>
> Record-level padding is indeed kind of annoying to plumb properly = though. I've always thought the excitement for padding at that layer was = somewhat misplaced. I could imagine allowing handshake messages to be = punctuated by no-op padding messages, but then it's just one layer to = route through to get to the record layer here. I think it's more at = higher up the stack where record-level padding really becomes = impractical.

To be clear, are you suggesting that adding a padding extension to = the
Certificate message is impractical? (I wouldn't consider this
record-level padding.)

Sorry, that was probably unclear. What I meant was: I = agree that record-level padding is pretty difficult to use in general, = but this particular instance is probably(?) not too bad, so it seems = sufficient to use the existing mechanism rather than make a = wire-incompatible change (unsolicited Certificate extensions are = forbidden) at this stage.

Though I otherwise don't particularly object to jamming = the padding extension into more places, the compressed certificates = point aside.
_______________________________________________
TLS = mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

= --Apple-Mail=_9BCBEBC9-48D0-491A-A05B-3485FF96365A-- From nobody Tue Jun 12 16:25:23 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626C313100D for ; Tue, 12 Jun 2018 16:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShaTLfP53AIG for ; Tue, 12 Jun 2018 16:25:13 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001: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 74408130F1C for ; Tue, 12 Jun 2018 16:25:13 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id d22-v6so1379033iof.13 for ; Tue, 12 Jun 2018 16:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yI4J008qxFi15rLopRjspzoQeGkdmDL6Zt/AdBSM7R4=; b=swHGSyiGSrCYpLjzNNPYmqQggC34kKpiuG17pDWfDPnqNeX7hopAGfkjie+GRAdmCB ounvGbBFpH3iCSQJKIhPv9s4XesPTVvfVZFuPiXlLAERMidc5Lwj4oSM1p9vDQJ0SOuC kNIYEaTx6VreHzCZTn6TzCHYHuFesKhPaSONjnH/v5cZNdB9fwifQxMNjOtuQz95/cQU 8LPUiioHB5RAVqdRP0tIGrrEAG/Pb1nmxPhh68+wnrJSosgOYzCI843cwrfkHBElZpBB 5XpLRSbnPNWP7gLuAMKGrFdnVccGLfe5ikp4SZJPWIIxdxVeH23ble62nyBLUt+Wx596 auPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yI4J008qxFi15rLopRjspzoQeGkdmDL6Zt/AdBSM7R4=; b=HP0BdxvEHQDZNESJCaLVqo8m+5jG4dYMoXqwnIw0G9G5rKznK+B5BTQrjigMu3XoAd bDMmENT0+U1AWXW7c+r1Tp3PcQflctd3H35+MJdqF0e6sfSGG63ZnQDeOpfXFwKzqnoI BpI52bllpNCEwv5uCb/AK7pdodPHapPheEAvsjxv+cz17xxYxcQA8KC2R2Po7GUZn+Dz QnuVq8iWLPhiEVxIuKKVDffRbqYfQqFALK/VPDlQvFuj/kKlGLHEkbA4e5/VYZ/fQ8I8 xDiiJaEOVtwBnAEyfWCmulr5KlIdy5qlogU7ReAt3DtFxLjRQuBcSzliX2ARsjd6gt5D bXog== X-Gm-Message-State: APt69E3Ucptd3sn8C66BGtO5y//HlqVBz/2tAwtb+ex9r3imjJvkFKis vwuLhktLrDwoxjrtqeN1H9j4kr8Qrgnc7qTm+Ss= X-Google-Smtp-Source: ADUXVKJbn8lhbMQZHOPhMs6hBqZdaGWxU+5RD7JeFbnB1ULXjqzkJKYcwjUybbNIAJ0TNnm+w61kthsExm0QLPDVJSU= X-Received: by 2002:a6b:1502:: with SMTP id 2-v6mr2668721iov.203.1528845912787; Tue, 12 Jun 2018 16:25:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jana Iyengar Date: Tue, 12 Jun 2018 16:25:01 -0700 Message-ID: To: davidben@chromium.org Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="0000000000008c54a9056e7a2d86" Archived-At: Subject: Re: [TLS] Enforcing Protocol Invariants X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2018 23:25:20 -0000 --0000000000008c54a9056e7a2d86 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm emerging from lurking to just say this: I think this is a fantastic idea, and thank you for doing it. FWIW and IMO, you're better off summarizing the codepoints you are using and planning to use on a wiki somewhere instead of in registries, given the timescales and the lifetime of these codepoints. - jana On Tue, Jun 12, 2018 at 9:28 AM David Benjamin wrote: > Hi all, > > Now that TLS 1.3 is about done, perhaps it is time to reflect on the > ossification problems. > > TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may be > incrementally rolled out in an existing compliant TLS 1.2 deployment. Yet > we had problems. Widespread non-compliant servers broke on the TLS 1.3 > ClientHello, so versioning moved to supported_versions. Widespread > non-compliant middleboxes attempted to parse someone else=E2=80=99s Serve= rHellos, > so the protocol was further hacked to weave through their many defects. > > I think I can speak for the working group that we do not want to repeat > this adventure again. In general, I think the response to ossification is > two-fold: > > 1. It=E2=80=99s already happened, so how do we progress today? > 2. How do we avoid more of this tomorrow? > > The workarounds only answer the first question. For the second, TLS 1.3 > has a section which spells out a few protocol invariants > . > It is all corollaries of existing TLS specification text, but hopefully > documenting it explicitly will help. But experience has shown specificati= on > text is only necessary, not sufficient. > > For extensibility problems in servers, we have GREASE > . This enforces the > key rule in ClientHello processing: ignore unrecognized parameters. GREAS= E > enforces this by filling the ecosystem with them. TLS 1.3=E2=80=99s middl= ebox woes > were different. The key rule is: if you did not produce a ClientHello, yo= u > cannot assume that you can parse the response. Analogously, we should fil= l > the ecosystem with such responses. We have an idea, but it is more involv= ed > than GREASE, so we are very interested in the TLS community=E2=80=99s fee= dback. > > In short, we plan to regularly mint new TLS versions (and likely other > sensitive parameters such as extensions), roughly every six weeks matchin= g > Chrome=E2=80=99s release cycle. Chrome, Google servers, and any other dep= loyment > that wishes to participate, would support two (or more) versions of TLS > 1.3: the standard stable 0x0304, and a rolling alternate version. Every s= ix > weeks, we would randomly pick a new code point. These versions will > otherwise be identical to TLS 1.3, save maybe minor details to separate > keys and exercise allowed syntax changes. The goal is to pave the way for > future versions of TLS by simulating them (=E2=80=9Cdraft negative one=E2= =80=9D). > > Of course, this scheme has some risk. It grabs code points everywhere. > Code points are plentiful, but we do sometimes have collisions (e.g. 26 a= nd > 40). The entire point is to serve and maintain TLS=E2=80=99s extensibilit= y, so we > certainly do not wish to hamper it! Thus we have some safeguards in mind: > > * We will document every code point we use and what it refers to. (If the > volume is fine, we can email them to the list each time.) New allocations > can always avoid the lost numbers. At a rate of one every 6 weeks, it wil= l > take over 7,000 years to exhaust everything. > > * We will avoid picking numbers that the IETF is likely to allocate, to > reduce the chance of collision. Rolling versions will not start with 0x03= , > rolling cipher suites or extensions will not be contiguous with existing > blocks, etc. > > * BoringSSL will not enable this by default. We will only enable it where > we can shut it back off. On our servers, we of course regularly deploy > changes. Chrome is also regularly updated and, moreover, we will gate it = on > our server-controlled field trials > mechanism. > We hope that, in practice, only the last several code points will be in u= se > at a time. > > * Our clients would only support the most recent set of rolling > parameters, and our servers the last handful. As each value will be > short-lived, the ecosystem is unlikely to rely on them as de facto > standards. Conversely, like other extensions, implementations without the= m > will still interoperate fine. We would never offer a rolling parameter > without the corresponding stable one. > > * If this ultimately does not work, we can stop at any time and only have > wasted a small portion of code points. > > * Finally, if the working group is open to it, these values could be > summarized in regular documents to reserve them, so that they are > ultimately reflected in the registries. A new document every six weeks is > probably impractical, but we can batch them up. > > We are interested in the community=E2=80=99s feedback on this proposal=E2= =80=94anyone who > might participate, better safeguards, or thoughts on the mechanism as a > whole. We hope it will help the working group evolve its protocols more > smoothly in the future. > > David > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000008c54a9056e7a2d86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm emerging from lurking to just say this: I think th= is is a fantastic idea, and thank you for doing it.
FWIW and IMO, you&#= 39;re better off summarizing the codepoints you are using and planning to u= se on a wiki somewhere instead of in registries, given the timescales and t= he lifetime of these codepoints.

- jana
<= /div>
On Tue, Jun 12, 2018 a= t 9:28 AM David Benjamin <david= ben@chromium.org> wrote:
Hi all,

Now that TLS 1.3 is abo= ut done, perhaps it is time to reflect on the ossification problems.
<= div>
TLS is an extensible protocol. TLS 1.3 is backwards-comp= atible and may be incrementally rolled out in an existing compliant TLS 1.2= deployment. Yet we had problems. Widespread non-compliant servers broke on= the TLS 1.3 ClientHello, so versioning moved to supported_versions. Widesp= read non-compliant middleboxes attempted to parse someone else=E2=80=99s Se= rverHellos, so the protocol was further hacked to weave through their many = defects.

I think I can speak for the working group= that we do not want to repeat this adventure again. In general, I think th= e response to ossification is two-fold:

1. It=E2= =80=99s already happened, so how do we progress today?
2. How do = we avoid more of this tomorrow?

The workarounds on= ly answer the first question. For the second, TLS 1.3 has a section which s= pells out a few protocol invariants. It= is all corollaries of existing TLS specification text, but hopefully docum= enting it explicitly will help. But experience has shown specification text= is only necessary, not sufficient.

For extensibil= ity problems in servers, we have GREASE. This enforces the key = rule in ClientHello processing: ignore unrecognized parameters. GREASE enfo= rces this by filling the ecosystem with them. TLS 1.3=E2=80=99s middlebox w= oes were different. The key rule is: if you did not produce a ClientHello, = you cannot assume that you can parse the response. Analogously, we should f= ill the ecosystem with such responses. We have an idea, but it is more invo= lved than GREASE, so we are very interested in the TLS community=E2=80=99s = feedback.

In short, we plan to regularly mint new = TLS versions (and likely other sensitive parameters such as extensions), ro= ughly every six weeks matching Chrome=E2=80=99s release cycle. Chrome, Goog= le servers, and any other deployment that wishes to participate, would supp= ort two (or more) versions of TLS 1.3: the standard stable 0x0304, and a ro= lling alternate version. Every six weeks, we would randomly pick a new code= point. These versions will otherwise be identical to TLS 1.3, save maybe m= inor details to separate keys and exercise allowed syntax changes. The goal= is to pave the way for future versions of TLS by simulating them (=E2=80= =9Cdraft negative one=E2=80=9D).

Of course, this s= cheme has some risk. It grabs code points everywhere. Code points are plent= iful, but we do sometimes have collisions (e.g. 26 and 40). The entire poin= t is to serve and maintain TLS=E2=80=99s extensibility, so we certainly do = not wish to hamper it! Thus we have some safeguards in mind:

=
* We will document every code point we use and what it refers to= . (If the volume is fine, we can email them to the list each time.) New all= ocations can always avoid the lost numbers. At a rate of one every 6 weeks,= it will take over 7,000 years to exhaust everything.

<= div>* We will avoid picking numbers that the IETF is likely to allocate, to= reduce the chance of collision. Rolling versions will not start with 0x03,= rolling cipher suites or extensions will not be contiguous with existing b= locks, etc.

* BoringSSL will not enable this by de= fault. We will only enable it where we can shut it back off. On our servers= , we of course regularly deploy changes. Chrome is also regularly updated a= nd, moreover, we will gate it on our server-controlled field = trials mechanism. We hope that, in practice, only the last several code= points will be in use at a time.

*=C2=A0Our clien= ts would only support the most recent set of rolling parameters, and our se= rvers the last handful. As each value will be short-lived, the ecosystem is= unlikely to rely on them as de facto standards. Conversely, like other ext= ensions, implementations without them will still interoperate fine. We woul= d never offer a rolling parameter without the corresponding stable one.

*=C2=A0If this ultimately does not work, we can stop = at any time and only have wasted a small portion of code points.
=
* Finally, if the working group is open to it, these values = could be summarized in regular documents to reserve them, so that they are = ultimately reflected in the registries. A new document every six weeks is p= robably impractical, but we can batch them up.

We = are interested in the community=E2=80=99s feedback on this proposal=E2=80= =94anyone who might participate, better safeguards, or thoughts on the mech= anism as a whole. We hope it will help the working group evolve its protoco= ls more smoothly in the future.

D= avid
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000008c54a9056e7a2d86-- From nobody Tue Jun 12 20:50:30 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAC1130DD8 for ; Tue, 12 Jun 2018 20:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhCC2lJCYnVB for ; Tue, 12 Jun 2018 20:50:24 -0700 (PDT) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-dm3nam05olkn080e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe51::80e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735F1130DD2 for ; Tue, 12 Jun 2018 20:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s9XcbKH3oXmcX3v6F3dHwdjkz79iTuZNzDSlkP6SCLQ=; b=oa91c+qBibobf3lcmN9ojgXYz9Z8BC8tQr8yIOAmbZAs3VJglisoCdKjfQ/txnU2s7BHte7n7JWv0f3c7Yu1CcMhuiVJNbuD+dKy/+Nki3Uhj/+9WsDL/cImr7rV9jHP7hvTqaQum5wxQhANUhRIUc0KC3ebGnKZmDh+1c6eMc/mRiFjz5BiE2QYDwziWC2hBFzjmObC05Vz5AMWKno5I/pbXISVH8C/DzGRmUwxcFyhbXplhMCnalBwk9PjjtqFhqMmXwZGF44mdH9X7Nn2ymOFGmegHEfJ0d17rWJUUZIuW0e+lo4HhbBpUftHIT84vau7D2dm+He2mwcCjsUDeA== Received: from DM3NAM05FT019.eop-nam05.prod.protection.outlook.com (10.152.98.52) by DM3NAM05HT112.eop-nam05.prod.protection.outlook.com (10.152.99.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.863.7; Wed, 13 Jun 2018 03:50:22 +0000 Received: from MWHPR18MB1086.namprd18.prod.outlook.com (10.152.98.51) by DM3NAM05FT019.mail.protection.outlook.com (10.152.98.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.863.7 via Frontend Transport; Wed, 13 Jun 2018 03:50:22 +0000 Received: from MWHPR18MB1086.namprd18.prod.outlook.com ([fe80::c38:703:b4b5:be64]) by MWHPR18MB1086.namprd18.prod.outlook.com ([fe80::c38:703:b4b5:be64%8]) with mapi id 15.20.0841.021; Wed, 13 Jun 2018 03:50:22 +0000 From: Yuhong Bao To: David Benjamin , "" Thread-Topic: [TLS] Enforcing Protocol Invariants Thread-Index: AQHUAmpiGRv5NErB2Uyku/LX/tlnAaRdjnTJ Date: Wed, 13 Jun 2018 03:50:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:D4EE84961E6F2C7C151FF12F9A748D3D1DF86ED959483D7AB69B27F41B66819A; UpperCasedChecksum:AB884BA96B8789FD8EFB488EC112E84D74A6839CBA0C38D84151735124F3FCBD; SizeAsReceived:7179; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [vi4KrCcQkePkJgXRqgqYqEPz8fZPp7iOJ9EVAQBxxCH9tpBq6VwvlbDYtyLHqxYr] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM3NAM05HT112; 7:ewAOAv8VlV8A9U99ilda44b+m3x+qYWK1NOXmAFVHs2IBp8yVdMEAAkLRF9ArxXutMYmJNdOL6Kxk9ZVPVBEd9YK80lxUK4lftdgDgEUOSwoj647MHwjhCE5PIAOkrGyG+WJVMFPG+w33MJs0OiZieKtTXIfMu+aYUtWXEgA78DRIEAzT+3G815ghiDyWQpSZ39Gpe5w8tfHOHec0JClciV6YQofZb9KAYR5E8tcFUF4MUjZemnba3hO10LLz6Zt x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125500)(1701031045); SRVR:DM3NAM05HT112; x-ms-traffictypediagnostic: DM3NAM05HT112: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:DM3NAM05HT112; BCL:0; PCL:0; RULEID:; SRVR:DM3NAM05HT112; x-forefront-prvs: 07025866F6 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(189003)(199004)(53754006)(6436002)(110136005)(106356001)(87572001)(104016004)(76176011)(7696005)(105586002)(9686003)(25786009)(83332001)(6306002)(55016002)(99286004)(5660300001)(2900100001)(14454004)(97736004)(82202002)(81156014)(33656002)(8936002)(8676002)(229853002)(20460500001)(74316002)(6506007)(68736007)(6246003)(305945005)(73972006)(3280700002)(3660700001)(11346002)(5250100002)(6346003)(486006)(86362001)(476003)(53546011)(446003)(59450400001)(102836004)(46003)(15852004)(491001); DIR:OUT; SFP:1901; SCL:1; SRVR:DM3NAM05HT112; H:MWHPR18MB1086.namprd18.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:; received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=yuhongbao_386@hotmail.com; x-microsoft-antispam-message-info: v8nKQ2NRf+OSy6SefJm4DjXUw/Lc/BgbYHcfApreTPyG43sdxx4SzdQ+XW781o9P15pYuNbUDBt1PIp0SXOY51gg/thMG+SfYdflS4jWX/wqoK7c3sDy0C6j/LlShe1YxjUXr58wa/fgFL9SJsR+Mfn+IFFpFgwE/UC23TWy7shszfmDkMOYjiMhDewHgiI2 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: bdf02e0b-4d7b-41aa-27c3-08d5d0e0ca4e X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-Network-Message-Id: bdf02e0b-4d7b-41aa-27c3-08d5d0e0ca4e X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2018 03:50:22.7695 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3NAM05HT112 Archived-At: Subject: Re: [TLS] Enforcing Protocol Invariants X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2018 03:50:28 -0000 Personally, I understood when the ClientHello was changed to deal with TLS = version intolerant servers, but disliked the middlebox changes in the Serve= rHello. ________________________________________ From: TLS on behalf of David Benjamin Sent: Tuesday, June 12, 2018 9:27:39 AM To: Subject: [TLS] Enforcing Protocol Invariants Hi all, Now that TLS 1.3 is about done, perhaps it is time to reflect on the ossifi= cation problems. TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may be i= ncrementally rolled out in an existing compliant TLS 1.2 deployment. Yet we= had problems. Widespread non-compliant servers broke on the TLS 1.3 Client= Hello, so versioning moved to supported_versions. Widespread non-compliant = middleboxes attempted to parse someone else=92s ServerHellos, so the protoc= ol was further hacked to weave through their many defects. I think I can speak for the working group that we do not want to repeat thi= s adventure again. In general, I think the response to ossification is two-= fold: 1. It=92s already happened, so how do we progress today? 2. How do we avoid more of this tomorrow? The workarounds only answer the first question. For the second, TLS 1.3 has= a section which spells out a few protocol invariants. It is all corolla= ries of existing TLS specification text, but hopefully documenting it expli= citly will help. But experience has shown specification text is only necess= ary, not sufficient. For extensibility problems in servers, we have GREASE. This enforces the key rule in ClientHello= processing: ignore unrecognized parameters. GREASE enforces this by fillin= g the ecosystem with them. TLS 1.3=92s middlebox woes were different. The k= ey rule is: if you did not produce a ClientHello, you cannot assume that yo= u can parse the response. Analogously, we should fill the ecosystem with su= ch responses. We have an idea, but it is more involved than GREASE, so we a= re very interested in the TLS community=92s feedback. In short, we plan to regularly mint new TLS versions (and likely other sens= itive parameters such as extensions), roughly every six weeks matching Chro= me=92s release cycle. Chrome, Google servers, and any other deployment that= wishes to participate, would support two (or more) versions of TLS 1.3: th= e standard stable 0x0304, and a rolling alternate version. Every six weeks,= we would randomly pick a new code point. These versions will otherwise be = identical to TLS 1.3, save maybe minor details to separate keys and exercis= e allowed syntax changes. The goal is to pave the way for future versions o= f TLS by simulating them (=93draft negative one=94). Of course, this scheme has some risk. It grabs code points everywhere. Code= points are plentiful, but we do sometimes have collisions (e.g. 26 and 40)= . The entire point is to serve and maintain TLS=92s extensibility, so we ce= rtainly do not wish to hamper it! Thus we have some safeguards in mind: * We will document every code point we use and what it refers to. (If the v= olume is fine, we can email them to the list each time.) New allocations ca= n always avoid the lost numbers. At a rate of one every 6 weeks, it will ta= ke over 7,000 years to exhaust everything. * We will avoid picking numbers that the IETF is likely to allocate, to red= uce the chance of collision. Rolling versions will not start with 0x03, rol= ling cipher suites or extensions will not be contiguous with existing block= s, etc. * BoringSSL will not enable this by default. We will only enable it where w= e can shut it back off. On our servers, we of course regularly deploy chang= es. Chrome is also regularly updated and, moreover, we will gate it on our = server-controlled field trials mechanism. We hope that, in practice, only the last several= code points will be in use at a time. * Our clients would only support the most recent set of rolling parameters,= and our servers the last handful. As each value will be short-lived, the e= cosystem is unlikely to rely on them as de facto standards. Conversely, lik= e other extensions, implementations without them will still interoperate fi= ne. We would never offer a rolling parameter without the corresponding stab= le one. * If this ultimately does not work, we can stop at any time and only have w= asted a small portion of code points. * Finally, if the working group is open to it, these values could be summar= ized in regular documents to reserve them, so that they are ultimately refl= ected in the registries. A new document every six weeks is probably impract= ical, but we can batch them up. We are interested in the community=92s feedback on this proposal=97anyone w= ho might participate, better safeguards, or thoughts on the mechanism as a = whole. We hope it will help the working group evolve its protocols more smo= othly in the future. David From nobody Wed Jun 13 06:21:37 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6540B130E22; Wed, 13 Jun 2018 06:21:25 -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 autolearn_force=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 hMDS7JS6R-0E; Wed, 13 Jun 2018 06:21:23 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F42130E1F; Wed, 13 Jun 2018 06:21:22 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C5AB6818BAED; Wed, 13 Jun 2018 13:21:21 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id DF8D97C57; Wed, 13 Jun 2018 13:21:20 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Cc: David Benjamin , Daniel Migault , LURK BoF Date: Wed, 13 Jun 2018 15:21:15 +0200 Message-ID: <2502786.FB2IomL8uD@pintsize.usersys.redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3048220.dCRxH3muN7"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Wed, 13 Jun 2018 13:21:21 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Wed, 13 Jun 2018 13:21:21 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] TLS 1.2 and sha256 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2018 13:21:26 -0000 --nextPart3048220.dCRxH3muN7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 11 June 2018 23:52:55 CEST David Benjamin wrote: > In both TLS 1.2 and TLS 1.3, SHA-256 isn't hardcoded per se. It's a > function of the cipher suite you negotiate (and also, separately, the > signature algorithm you negotiate). That said, in practice, both are pret= ty > solidly dependent on SHA-256. Most options involve it. AES-128-GCM and > ChaCha20-Poly1305 are currently paired with SHA-256 while only AES-256-GCM > is paired with SHA-384. >=20 > We could certainly define new cipher suites for either of TLS 1.2 and TLS > 1.3 as needed. But defining a new cipher suite for TLS 1.2 doesn't > magically deploy it for all existing TLS 1.2 servers. Those servers must > deploy new code, at which point updating your TLS library to include it > would also pull in TLS 1.3 anyway (or whatever the latest TLS version is = by > then). except that introduction of a new ciphersuite is far less intrusive change= =20 that a completely new protocol like TLS 1.3 API/ABI compatibility is also a factor, where the behaviour with session=20 resumption, client certificate based authentication and PSK handling is=20 different between TLS 1.2 and TLS 1.3 > So I think there will likely be no point in bothering with TLS 1.2 > allocations at that point. More options means more combinatorial complexi= ty > for implementations, which means more our rather limited collective > resources in this space get even more thinly spread. ciphersuites are usually defined by their settings, where addition of a new= =20 ciphersuite, which uses already implemented PRF, cipher and key exchange=20 requires only addition of new entry in an array, not complete reworking of= =20 parts of the codebase... > David >=20 > On Mon, Jun 11, 2018 at 5:25 PM Daniel Migault > wrote: > > Hi, > >=20 > > TLS 1.2 uses sha256 as the prf hash function. When sha256 will not be > > considered secured, I am wondering if we can reasonably envision > > deprecating sha256 for TLS 1.2 or if TLS 1.2 will at that time be > > deprecated in favor of TLS 1.X X>=3D 3 ? > >=20 > > In other words, I am wondering how much we can assume TLS 1.2 is > > associated to sha256. > >=20 > > Yours, > > Daniel > >=20 > >=20 > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart3048220.dCRxH3muN7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlshGksACgkQkqjRuAHS 9fWOzg/8Dk2VuWeCwIfDRRjPVVD0goSObXEDuMXP30bz7Zfz8dMcYYgCwB1x42Hn 5jA39w3+ynQ2Df6VRukfBVNuRLOq0f3H8yKTEPFOQj6FkuGdE1qsqx3lCTX49lxV zFfJ7RXJNvyt+rf54nMDb8dbFkq3QviKIh4jHC6KCQVkizR8zGXVSUoJp1S6Kbc+ X/DbZtMqvhnMrcS72Jpid5iU6+Wb472CR5vW/xa1LOPp4x4YNKLmqA3kk8JFxkWq cAjr17tkEZBV1Zw/Xg3m/WLv+tw+0fNw1biroiWohze81KuoII0qvywDIG+YVaeg tl2/l/siVoVqU9nFkaUv+RK2tb/SkRKxvPiBr2oV9EWtUcznwu8X8OeL2GlbrGf2 DRdRD+sTmnK2urylvdP3kWei3Lj8Ud362wlcAh3OL2UY3IcoJjb2jxkYtpDYQxsh GzhiDsa4fKktnUYTZ2ZIAq5sfeUuStjxmoMtN6ii8Y4lxGnGiYEgbN6IL0LzsFK/ bA9s6gboApuhUufNw7t5BEJB42GGm4RuCxYUk89c7NQMLNS/btgWC6ex87AgJYvT qS00zgBqfcjBXnByAF9N56gUxcXoyOT2/l3vpYhdpG9RYAVeareEBiM9jOcsy3ri 8qn30jD/aAKc8dbHDk82Cb4AK0NeO8Omv+YahgnqIt5nV/2jRyY= =EVMO -----END PGP SIGNATURE----- --nextPart3048220.dCRxH3muN7-- From nobody Wed Jun 13 06:41:40 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83C3130EA3 for ; Wed, 13 Jun 2018 06:41:37 -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 autolearn_force=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 QyZaIBc8uuUE for ; Wed, 13 Jun 2018 06:41:33 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BACF9130E37 for ; Wed, 13 Jun 2018 06:41:33 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0DC8940122D5; Wed, 13 Jun 2018 13:41:33 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id A2D2B2026DEF; Wed, 13 Jun 2018 13:41:32 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Wed, 13 Jun 2018 15:41:31 +0200 Message-ID: <2083153.4uq8RWWZBY@pintsize.usersys.redhat.com> In-Reply-To: References: <152830634989.6264.3566629916218895862@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1759980.DnCRIbHJmA"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 13 Jun 2018 13:41:33 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 13 Jun 2018 13:41:33 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-grease-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2018 13:41:38 -0000 --nextPart1759980.DnCRIbHJmA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 6 June 2018 21:08:28 CEST David Benjamin wrote: > 1) "ignore/" is a pretty long ALPN prefix and also might encourage folks = to > parse out the "ignore/" string. Instead, what do folks think about just > using two byte strings. Perhaps the same two byte pattern we're currently > doing? +1, it also tests that the server will not expect an ASCII string in ALPN =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart1759980.DnCRIbHJmA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlshHwsACgkQkqjRuAHS 9fWxtBAAoLBGqjP9c27DLMcvnvcHAEyCbXLIrfhASphDEWivU/xuXKtl26tUYuZp eC8LOKH8HqP9W2GgHB4daqywgTbrY+zBaarKFTq/oqZdx9oHsPnIOdODJ8+4CdZQ j0Cbpe0zOkYUqZQoyhp+2+jhg6593QDaXPkcjONJKb7p5q35uDPQBRnV2mB8V6vR JIW4Yuq+xoW8YkMdR9kl5To3MQT0F2/IDGOrVFhl4GF3B5ZS0hD9nZsXL0SvyBCE SH8+oBr60YGwPVIkj4BWzBubdViSrs/GQaiNjJQYcc3tQl8yRwuMQeypktfv6AZK lqrEfJjoJHmImUjGS5vQP55nJdEerJnRGW/I0O8u0DFi1A8ygZXsAgKaM77mhMmc +LlFQJP/PL5oTEPwtbV3YEzSvhF8GDCgLFKSGV+UfxmRJNzszXuPNnBC9hgQpxuT K2O5zp175JMtaZHoRz+7TOfZ801K0DrWS9jRec+VqMtPeREVluPkg8oCQKyom9jQ HmgKo82VueMotd92cpAsXvI1tgzr+dnLga+kLIzZCVPyY111XewUSj3wUt7PxTMt T4/agC/rSL7/YdBbpU8fo4uHXZwSTaCaG6X5zOiQP8YPyg4VzVPRtUz0GaIcP6q9 deZqe1ykKAy0oXnvNxxE1zbzIgpqYZJDRThxL6y8dGTs8b5eCvw= =peOh -----END PGP SIGNATURE----- --nextPart1759980.DnCRIbHJmA-- From nobody Wed Jun 13 06:46:09 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F51130E37 for ; Wed, 13 Jun 2018 06:46:07 -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 autolearn_force=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 FFZzGIHWczYD for ; Wed, 13 Jun 2018 06:46:06 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30BDA130E29 for ; Wed, 13 Jun 2018 06:46:06 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8BB8287A7C; Wed, 13 Jun 2018 13:46:05 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id E7E4B2166BD6; Wed, 13 Jun 2018 13:46:04 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Wed, 13 Jun 2018 15:46:04 +0200 Message-ID: <27310408.d6V92UL0Mo@pintsize.usersys.redhat.com> In-Reply-To: References: <152830634989.6264.3566629916218895862@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3898990.of6BXPXyhT"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 13 Jun 2018 13:46:05 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 13 Jun 2018 13:46:05 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-grease-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2018 13:46:08 -0000 --nextPart3898990.of6BXPXyhT Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Saturday, 9 June 2018 03:13:29 CEST Christian Huitema wrote: > On 6/8/2018 7:35 AM, David Benjamin wrote: > > On Fri, Jun 8, 2018 at 10:07 AM R duToit wrote: > > > GREASE values should not make their way into code. The whole > > =20 > > point is to get code used to the fact that unknown values exist. > > =20 > > The GREASE mechanism is useful, but it will definitely make its > > way into code and become ossified itself. =20 > > Example: https://github.com/salesforce/ja3 > >=20 > > Indeed. GREASE was targeting normal sensible endpoint implementations... >=20 > ... and maybe we need a different mechanism to defeat fingerprinting > tools like this JA3 project. Maybe applications need to somehow > randomize their signatures, so that they are not so easy to recognize. > For example, it should be possible to use randomize the order of > extensions. And it should also be possible to throw some grease in these > sets. >=20 > Of course, the first ones to develop and use these randomization > techniques will most likely be the malware authors that the tools are > allegedly trying to track. you can probe implementations irrespective of enabled ciphers, just by look= ing=20 at the way they handle errors: https://github.com/WestpointLtd/tls_prober =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart3898990.of6BXPXyhT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlshIBwACgkQkqjRuAHS 9fVVOw/+NDzrHCps2l+E4dJp3FZJmkHCvCia87S8M8ixGbX+OfhELZxoxqFDS28q cUJKPJS6GxKEk5fI2eMPPsZ6Ve5xUEMs9Ba4XOcRJN7tyi+3qR+Np6Bim4wWQ2L7 59dcpFfAEhECsH21zMCxFKjKqj+/5yYbWJ1KJrbRtFpQk+ds+ByJUYg2/i1o39Yw EXmQe1TTr41mLoJhvNvakPjr3rLZ22cTduYano7A9aIevTRtXm67PtmzeV8xoxKR Co/pML1brf+wNJMvx5iWjhWEO8H4mct3sYUeodILGcs9gtKKJZ31NbM4UqwBBkXK HnouvRRYdvx6k3tr4aGyD/CaEdrefBknWJ7KTHbfoL0WZQzUfy0nxpv2SVJkkV0Q OWeTDhfVhyAuxlZarA+E6Cgm74dDtVwOale5Zhl9yCQ6mpJHwRHQaS5edndm2XE8 pFl4Eswht8BIxv5NjX3tOvgChtEr8neJIfpjmu0QryiEd9Hs7gfm1vXKvYhvj9Pi ilp3vDZKtaiFNbuhg1/M0yxDaPIKodOZ2+gozyckQ+VT8eQnW4DwI/Oi0Bg8G3u9 9wgv4hFjV2h/FjF1uMHFJJ16GZihYDy4Xm9yBLvTdKD88SLwYCchqPnoQdVMLxSo zoyxDFo7mLKOdfyT9QoHH7IYcspydjMItJLAnZG0kfLJjC4mbUU= =yHup -----END PGP SIGNATURE----- --nextPart3898990.of6BXPXyhT-- From nobody Wed Jun 13 11:06:18 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3E5130F75 for ; Wed, 13 Jun 2018 11:06:13 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ghedini.me Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-jaLzbrQi2l for ; Wed, 13 Jun 2018 11:06:08 -0700 (PDT) Received: from blastoise.ghedini.me (blastoise.ghedini.me [IPv6:2001:19f0:6c01:a56:5400:1ff:fe4a:5694]) (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 B2617130E06 for ; Wed, 13 Jun 2018 11:06:07 -0700 (PDT) Received: from localhost (unknown [IPv6:2a06:98c0:1000:8200:290d:3270:5009:321a]) by blastoise.ghedini.me (Postfix) with ESMTPSA id E0356DF3B1; Wed, 13 Jun 2018 18:06:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ghedini.me; s=mail; t=1528913165; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=l8jakKUED4MjQkG23jfk3SjN5Lsnqy1CgcwdvFxExQ4=; b=kv7497oX2k9ilC1efjod3L8C78PAryTiOlp9BOV9FDsb/heSI4Y6On0+2lSFeJWmbdjRdu T6pqSezZ/H6pleB83uq3zdX07beIH3U1RL8TUSSQEdxe9ynlzcbpohDxyCPzD9GtKXbSbx Z6zudeqpD4YGDqaGYWdPkbnjUoCKdDM= Date: Wed, 13 Jun 2018 19:06:03 +0100 From: Alessandro Ghedini To: David Benjamin Cc: "" Message-ID: <20180613180603.GA27662@mandy> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) Archived-At: Subject: Re: [TLS] Enforcing Protocol Invariants X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2018 18:06:14 -0000 On Tue, Jun 12, 2018 at 12:27:39PM -0400, David Benjamin wrote: > Hi all, > > Now that TLS 1.3 is about done, perhaps it is time to reflect on the > ossification problems. > > TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may be > incrementally rolled out in an existing compliant TLS 1.2 deployment. Yet > we had problems. Widespread non-compliant servers broke on the TLS 1.3 > ClientHello, so versioning moved to supported_versions. Widespread > non-compliant middleboxes attempted to parse someone else’s ServerHellos, > so the protocol was further hacked to weave through their many defects. > > I think I can speak for the working group that we do not want to repeat > this adventure again. In general, I think the response to ossification is > two-fold: > > 1. It’s already happened, so how do we progress today? > 2. How do we avoid more of this tomorrow? > > The workarounds only answer the first question. For the second, TLS 1.3 has > a section which spells out a few protocol invariants > . > It is all corollaries of existing TLS specification text, but hopefully > documenting it explicitly will help. But experience has shown specification > text is only necessary, not sufficient. > > For extensibility problems in servers, we have GREASE > . This enforces the > key rule in ClientHello processing: ignore unrecognized parameters. GREASE > enforces this by filling the ecosystem with them. TLS 1.3’s middlebox woes > were different. The key rule is: if you did not produce a ClientHello, you > cannot assume that you can parse the response. Analogously, we should fill > the ecosystem with such responses. We have an idea, but it is more involved > than GREASE, so we are very interested in the TLS community’s feedback. > > In short, we plan to regularly mint new TLS versions (and likely other > sensitive parameters such as extensions), roughly every six weeks matching > Chrome’s release cycle. Chrome, Google servers, and any other deployment > that wishes to participate, would support two (or more) versions of TLS > 1.3: the standard stable 0x0304, and a rolling alternate version. Every six > weeks, we would randomly pick a new code point. These versions will > otherwise be identical to TLS 1.3, save maybe minor details to separate > keys and exercise allowed syntax changes. The goal is to pave the way for > future versions of TLS by simulating them (“draft negative one”). > > Of course, this scheme has some risk. It grabs code points everywhere. Code > points are plentiful, but we do sometimes have collisions (e.g. 26 and 40). > The entire point is to serve and maintain TLS’s extensibility, so we > certainly do not wish to hamper it! Thus we have some safeguards in mind: > > * We will document every code point we use and what it refers to. (If the > volume is fine, we can email them to the list each time.) New allocations > can always avoid the lost numbers. At a rate of one every 6 weeks, it will > take over 7,000 years to exhaust everything. > > * We will avoid picking numbers that the IETF is likely to allocate, to > reduce the chance of collision. Rolling versions will not start with 0x03, > rolling cipher suites or extensions will not be contiguous with existing > blocks, etc. > > * BoringSSL will not enable this by default. We will only enable it where > we can shut it back off. On our servers, we of course regularly deploy > changes. Chrome is also regularly updated and, moreover, we will gate it on > our server-controlled field trials > mechanism. We > hope that, in practice, only the last several code points will be in use at > a time. > > * Our clients would only support the most recent set of rolling parameters, > and our servers the last handful. As each value will be short-lived, the > ecosystem is unlikely to rely on them as de facto standards. Conversely, > like other extensions, implementations without them will still interoperate > fine. We would never offer a rolling parameter without the corresponding > stable one. > > * If this ultimately does not work, we can stop at any time and only have > wasted a small portion of code points. > > * Finally, if the working group is open to it, these values could be > summarized in regular documents to reserve them, so that they are > ultimately reflected in the registries. A new document every six weeks is > probably impractical, but we can batch them up. > > We are interested in the community’s feedback on this proposal—anyone who > might participate, better safeguards, or thoughts on the mechanism as a > whole. We hope it will help the working group evolve its protocols more > smoothly in the future. This looks interesting and I very much agree that we should do *somthing* to try to avoid the pain we've seen with deploying TLS 1.3 for future versions. We (Cloudflare) would be happy to help with developing and deploying it, and see how the experiment goes (and maybe even help put a draft together if needed, if that is the form this proposal will take). Cheers From nobody Wed Jun 13 12:15:59 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B0212426A for ; Wed, 13 Jun 2018 12:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwpE6BK0Xwsl for ; Wed, 13 Jun 2018 12:15:55 -0700 (PDT) Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (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 6A566130E87 for ; Wed, 13 Jun 2018 12:15:54 -0700 (PDT) Received: by mail-lf0-x244.google.com with SMTP id i83-v6so5641064lfh.5 for ; Wed, 13 Jun 2018 12:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2ujyfzdpW9Vbgxv0eOwTCza5if5M++x1/rHMevkSLjk=; b=MJwppg6biZa0SjlZ14Y9mSY6FT9xcAi/Br7N13tSJGZJ1LMXY403xMsETQ88YXcGj2 haC13VEhyisdJ1D/UmoE4PFXpIgBsymCyW/pxCEWIsZ8pZjUeuSfqaaWQ2+ZlUwseM0J 0fs0YwRwVutx54SVzGN1V5DYhUaV+Czlr1wNhmy6Jvsn1Ji9YsoMCxNKgyBI/v4B6CXF MmA+NCEU5WVT62TOqlAYUWEzjkrfmrbydBowmOuhJ27rpq5ee9GbKSQjUkHQW503f+94 ubBAQIEEbMsuyBTCM0pwVUpNcc3E9W/aQXVWVbk49gZqq5ZkXABfDsZaPhToSJ2jX8be b3iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=2ujyfzdpW9Vbgxv0eOwTCza5if5M++x1/rHMevkSLjk=; b=W174A/vaoy+jjoNc2H3t2SZ56jcHtpeLrHv95neTGnhWwns7xiR6JoAaKXSZlgyUHr lJ1fMA/6fBm/4xA8fiKbijlgJ670qZ7+Bt8d0Ow+6mAv7nxS98p2EoSqxyCezHTaALe+ 4DZg5UEX+QfqdrKQfn60wOuMCQ6KVzOg2pl4jiFiif9ZC9h06SoD4k3OY5qMO/UauL9m PFoUNLDKgHm4VD6fikf1mJnNOeOhEvlSzhxhcwaMKQDWjU5sI7luSUBksBIx7C7QDsaS TO/ZUG2dNsbbAkx0izFvcA0bnv1kDGNGRSef4itJQEs6VD7yQP0aYqlk8HQcxSeDBXjh 2e1A== X-Gm-Message-State: APt69E1AlUBMR7+Uu5ozVTjQd4S/Yl6ShkoDneQcvoN/ubQcy5MsF2AL YN0JbR0Ev9Qg4KV1+Cq5ahGFaD8sDS/9vqWMuGk= X-Google-Smtp-Source: ADUXVKLkLFSU45CBTd9XXT0LstXjeB27DMsnd1DkbUjWxwdcxH+BBE41BM+qa8jhyhp0YCfQpM6EJ980QOY9Sb8p+gM= X-Received: by 2002:a19:14ca:: with SMTP id 71-v6mr4085300lfu.126.1528917352595; Wed, 13 Jun 2018 12:15:52 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 2002:a2e:2e1a:0:0:0:0:0 with HTTP; Wed, 13 Jun 2018 12:15:51 -0700 (PDT) In-Reply-To: <20180613180603.GA27662@mandy> References: <20180613180603.GA27662@mandy> From: Daniel Migault Date: Wed, 13 Jun 2018 15:15:51 -0400 X-Google-Sender-Auth: C9t9CzaqcvIHUcoi81-__BwK-BY Message-ID: To: Alessandro Ghedini Cc: David Benjamin , "" Content-Type: multipart/alternative; boundary="000000000000b14648056e8acf25" Archived-At: Subject: Re: [TLS] Enforcing Protocol Invariants X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2018 19:15:58 -0000 --000000000000b14648056e8acf25 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I also support something is being done in this direction. I like the idea of taking ephemeral non allocated code points. What is not so clear to me is how GREASE prevents a buggy implementations from behaving correctly for GREASE allocated code points, while remaining buggy for the other (unallocated). code points. Yours, Daniel On Wed, Jun 13, 2018 at 2:06 PM, Alessandro Ghedini wrote: > On Tue, Jun 12, 2018 at 12:27:39PM -0400, David Benjamin wrote: > > Hi all, > > > > Now that TLS 1.3 is about done, perhaps it is time to reflect on the > > ossification problems. > > > > TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may = be > > incrementally rolled out in an existing compliant TLS 1.2 deployment. Y= et > > we had problems. Widespread non-compliant servers broke on the TLS 1.3 > > ClientHello, so versioning moved to supported_versions. Widespread > > non-compliant middleboxes attempted to parse someone else=E2=80=99s Ser= verHellos, > > so the protocol was further hacked to weave through their many defects. > > > > I think I can speak for the working group that we do not want to repeat > > this adventure again. In general, I think the response to ossification = is > > two-fold: > > > > 1. It=E2=80=99s already happened, so how do we progress today? > > 2. How do we avoid more of this tomorrow? > > > > The workarounds only answer the first question. For the second, TLS 1.3 > has > > a section which spells out a few protocol invariants > > tls13.html#rfc.section.9..3>. > > It is all corollaries of existing TLS specification text, but hopefully > > documenting it explicitly will help. But experience has shown > specification > > text is only necessary, not sufficient. > > > > For extensibility problems in servers, we have GREASE > > . This enforces > the > > key rule in ClientHello processing: ignore unrecognized parameters. > GREASE > > enforces this by filling the ecosystem with them. TLS 1.3=E2=80=99s mid= dlebox > woes > > were different. The key rule is: if you did not produce a ClientHello, > you > > cannot assume that you can parse the response. Analogously, we should > fill > > the ecosystem with such responses. We have an idea, but it is more > involved > > than GREASE, so we are very interested in the TLS community=E2=80=99s f= eedback. > > > > In short, we plan to regularly mint new TLS versions (and likely other > > sensitive parameters such as extensions), roughly every six weeks > matching > > Chrome=E2=80=99s release cycle. Chrome, Google servers, and any other d= eployment > > that wishes to participate, would support two (or more) versions of TLS > > 1.3: the standard stable 0x0304, and a rolling alternate version. Every > six > > weeks, we would randomly pick a new code point. These versions will > > otherwise be identical to TLS 1.3, save maybe minor details to separate > > keys and exercise allowed syntax changes. The goal is to pave the way f= or > > future versions of TLS by simulating them (=E2=80=9Cdraft negative one= =E2=80=9D). > > > > Of course, this scheme has some risk. It grabs code points everywhere. > Code > > points are plentiful, but we do sometimes have collisions (e.g. 26 and > 40). > > The entire point is to serve and maintain TLS=E2=80=99s extensibility, = so we > > certainly do not wish to hamper it! Thus we have some safeguards in min= d: > > > > * We will document every code point we use and what it refers to. (If t= he > > volume is fine, we can email them to the list each time.) New allocatio= ns > > can always avoid the lost numbers. At a rate of one every 6 weeks, it > will > > take over 7,000 years to exhaust everything. > > > > * We will avoid picking numbers that the IETF is likely to allocate, to > > reduce the chance of collision. Rolling versions will not start with > 0x03, > > rolling cipher suites or extensions will not be contiguous with existin= g > > blocks, etc. > > > > * BoringSSL will not enable this by default. We will only enable it whe= re > > we can shut it back off. On our servers, we of course regularly deploy > > changes. Chrome is also regularly updated and, moreover, we will gate i= t > on > > our server-controlled field trials > > mechanism. > We > > hope that, in practice, only the last several code points will be in us= e > at > > a time. > > > > * Our clients would only support the most recent set of rolling > parameters, > > and our servers the last handful. As each value will be short-lived, th= e > > ecosystem is unlikely to rely on them as de facto standards. Conversely= , > > like other extensions, implementations without them will still > interoperate > > fine. We would never offer a rolling parameter without the correspondin= g > > stable one. > > > > * If this ultimately does not work, we can stop at any time and only ha= ve > > wasted a small portion of code points. > > > > * Finally, if the working group is open to it, these values could be > > summarized in regular documents to reserve them, so that they are > > ultimately reflected in the registries. A new document every six weeks = is > > probably impractical, but we can batch them up. > > > > We are interested in the community=E2=80=99s feedback on this proposal= =E2=80=94anyone who > > might participate, better safeguards, or thoughts on the mechanism as a > > whole. We hope it will help the working group evolve its protocols more > > smoothly in the future. > > This looks interesting and I very much agree that we should do *somthing* > to > try to avoid the pain we've seen with deploying TLS 1.3 for future > versions. > > We (Cloudflare) would be happy to help with developing and deploying it, > and > see how the experiment goes (and maybe even help put a draft together if > needed, > if that is the form this proposal will take). > > Cheers > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000b14648056e8acf25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I also support something is being done in this direct= ion. I like the idea of taking ephemeral non allocated code points.

What is not so clear to me is how GREASE prevents = a buggy implementations from behaving correctly for GREASE allocated code p= oints, while remaining buggy for the other (unallocated). code points.=C2= =A0
Yours,
Daniel

On Wed, Jun 13, 2018 at 2:0= 6 PM, Alessandro Ghedini <alessandro@ghedini.me> wrote:<= br>
On Tue, Jun 12, 2018 at = 12:27:39PM -0400, David Benjamin wrote:
> Hi all,
>
> Now that TLS 1.3 is about done, perhaps it is time to reflect on the > ossification problems.
>
> TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may= be
> incrementally rolled out in an existing compliant TLS 1.2 deployment. = Yet
> we had problems. Widespread non-compliant servers broke on the TLS 1.3=
> ClientHello, so versioning moved to supported_versions. Widespread
> non-compliant middleboxes attempted to parse someone else=E2=80=99s Se= rverHellos,
> so the protocol was further hacked to weave through their many defects= .
>
> I think I can speak for the working group that we do not want to repea= t
> this adventure again. In general, I think the response to ossification= is
> two-fold:
>
> 1. It=E2=80=99s already happened, so how do we progress today?
> 2. How do we avoid more of this tomorrow?
>
> The workarounds only answer the first question. For the second, TLS 1.= 3 has
> a section which spells out a few protocol invariants
> <https:/= /tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section= .9..3>.
> It is all corollaries of existing TLS specification t= ext, but hopefully
> documenting it explicitly will help. But experience has shown specific= ation
> text is only necessary, not sufficient.
>
> For extensibility problems in servers, we have GREASE
> <https://tools.ietf.org/html/draft-ietf-tls-grease-01>. This enforces the
> key rule in ClientHello processing: ignore unre= cognized parameters. GREASE
> enforces this by filling the ecosystem with them. TLS 1.3=E2=80=99s mi= ddlebox woes
> were different. The key rule is: if you did not produce a ClientHello,= you
> cannot assume that you can parse the response. Analogously, we should = fill
> the ecosystem with such responses. We have an idea, but it is more inv= olved
> than GREASE, so we are very interested in the TLS community=E2=80=99s = feedback.
>
> In short, we plan to regularly mint new TLS versions (and likely other=
> sensitive parameters such as extensions), roughly every six weeks matc= hing
> Chrome=E2=80=99s release cycle. Chrome, Google servers, and any other = deployment
> that wishes to participate, would support two (or more) versions of TL= S
> 1.3: the standard stable 0x0304, and a rolling alternate version. Ever= y six
> weeks, we would randomly pick a new code point. These versions will > otherwise be identical to TLS 1.3, save maybe minor details to separat= e
> keys and exercise allowed syntax changes. The goal is to pave the way = for
> future versions of TLS by simulating them (=E2=80=9Cdraft negative one= =E2=80=9D).
>
> Of course, this scheme has some risk. It grabs code points everywhere.= Code
> points are plentiful, but we do sometimes have collisions (e.g. 26 and= 40).
> The entire point is to serve and maintain TLS=E2=80=99s extensibility,= so we
> certainly do not wish to hamper it! Thus we have some safeguards in mi= nd:
>
> * We will document every code point we use and what it refers to. (If = the
> volume is fine, we can email them to the list each time.) New allocati= ons
> can always avoid the lost numbers. At a rate of one every 6 weeks, it = will
> take over 7,000 years to exhaust everything.
>
> * We will avoid picking numbers that the IETF is likely to allocate, t= o
> reduce the chance of collision. Rolling versions will not start with 0= x03,
> rolling cipher suites or extensions will not be contiguous with existi= ng
> blocks, etc.
>
> * BoringSSL will not enable this by default. We will only enable it wh= ere
> we can shut it back off. On our servers, we of course regularly deploy=
> changes. Chrome is also regularly updated and, moreover, we will gate = it on
> our server-controlled field trials
> <https://textslashplai= n.com/2017/10/18/chrome-field-trials/> mechanism. We
> hope that, in practice, only the last several code po= ints will be in use at
> a time.
>
> * Our clients would only support the most recent set of rolling parame= ters,
> and our servers the last handful. As each value will be short-lived, t= he
> ecosystem is unlikely to rely on them as de facto standards. Conversel= y,
> like other extensions, implementations without them will still interop= erate
> fine. We would never offer a rolling parameter without the correspondi= ng
> stable one.
>
> * If this ultimately does not work, we can stop at any time and only h= ave
> wasted a small portion of code points.
>
> * Finally, if the working group is open to it, these values could be > summarized in regular documents to reserve them, so that they are
> ultimately reflected in the registries. A new document every six weeks= is
> probably impractical, but we can batch them up.
>
> We are interested in the community=E2=80=99s feedback on this proposal= =E2=80=94anyone who
> might participate, better safeguards, or thoughts on the mechanism as = a
> whole. We hope it will help the working group evolve its protocols mor= e
> smoothly in the future.

This looks interesting and I very much agree that we should do *somt= hing* to
try to avoid the pain we've seen with deploying TLS 1.3 for future vers= ions.

We (Cloudflare) would be happy to help with developing and deploying it, an= d
see how the experiment goes (and maybe even help put a draft together if ne= eded,
if that is the form this proposal will take).

Cheers

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

--000000000000b14648056e8acf25-- From nobody Wed Jun 13 12:47:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF2F130E91 for ; Wed, 13 Jun 2018 12:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFss80tIPAsc for ; Wed, 13 Jun 2018 12:47:18 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 8D78F130E87 for ; Wed, 13 Jun 2018 12:47:18 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w5DJlHRe009426 for ; Wed, 13 Jun 2018 20:47:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=Dynk4SaZHBcBg5llAwmYCNTotTwTd2IWKaG72CYRd7o=; b=KxiyDIqpBfYExfbfgfrIk7Hf4m7kNklS6mMLYGbqih0+kD16sHo9Oa6zCF0lIW4M3Wok axIeTbVc8n7Rkrzizv+bGq4WDQd8MpTVIjTIfFNqFGMU1ZMEjt1JlcVB0arxJE8pbqXu 0b3gULOg1/rkq+YLWoyE4EGg3EPJIvTpZ/lLjk+sESKvXtUb2KGdE3eQ4KbIP9OMZ5bE Glsx1FRSzuy1HMiDCrmH3yEi/rHUD2A//34D5chF/n3SHJ4ktt4JT3wBtNm7nb+lmUw8 UVjRNunJ/z12auMyc68QRfganjZhnRg3giB23NraPApHF4A6qwMto4g4SlBbwN/ydlgu WA== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2jjp9ktwfu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 13 Jun 2018 20:47:17 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5DJkEQj014004 for ; Wed, 13 Jun 2018 15:47:13 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint3.akamai.com with ESMTP id 2jjp74kc9s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 13 Jun 2018 15:47:13 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 13 Jun 2018 12:47:12 -0700 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Wed, 13 Jun 2018 14:47:12 -0500 From: "Salz, Rich" To: "tls@ietf.org" Thread-Topic: What does "renegotiation_info" mean? Thread-Index: AQHUA09SuenRYICwtkWJUMgDXynC2A== Date: Wed, 13 Jun 2018 19:47:11 +0000 Message-ID: <949AFB3D-EAF7-423D-A620-ACCA24AFA26B@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.d.1.180523 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.34] Content-Type: multipart/alternative; boundary="_000_949AFB3DEAF7423DA620ACCA24AFA26Bakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-13_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=305 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806130209 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-13_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=232 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806130210 Archived-At: Subject: [TLS] What does "renegotiation_info" mean? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2018 19:47:23 -0000 --_000_949AFB3DEAF7423DA620ACCA24AFA26Bakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgc2VlbXMgdGhhdCB0aGUgc2VtYW50aWNzIG9mIHRoZSAicmVuZWdvdGlhdGlvbl9pbmZvIiBl eHRlbnNpb24gYXJlIHNsaWdodGx5IG11ZGR5LiBRdWFseXMgdW5kZXJzdGFuZHMgaXQgdG8gbWVh biB0aGF0IHRoZSBzZXJ2ZXIgd2lsbCBub3QgcGVyZm9ybSBpbnNlY3VyZSByZW5lZ290aWF0aW9u LCBmdWxsIHN0b3AuIEJ1dCBPcGVuU1NMIGZ1cnRoZXIgdW5kZXJzdGFuZHMgaXQgdG8gbWVhbiB0 aGF0IHRoZSBzZXJ2ZXIgKndpbGwqIHBlcmZvcm0gc2VjdXJlIG5lZ290aWF0aW9uLiBPcGVuU1NM IHRoZXJlZm9yZSBtYWtlcyBpdCBkaWZmaWN1bHQgdG8gc2ltdWx0YW5lb3VzbHkgc2ltdWx0YW5l b3VzbHkgc2F0aXNmeSBib3RoIG9mIFF1YWx5cydzIGV4cGVjdGF0aW9ucywgc2luY2UgZGlzYWJs aW5nIGFsbCByZW5lZ290aWF0aW9uIHdpbGwgY2F1c2UgaXQgbm90IHRvIHNlbmQgdGhlICJyZW5l Z290aWF0aW9uX2luZm8iIGV4dGVuc2lvbi4gUG9wdWxhciBvcGVuIHNvdXJjZSB3ZWIgc2VydmVy cyBpbXBsZW1lbnQgYSB3b3JrYXJvdW5kIHdoaWNoIGFjaGlldmVzIFF1YWx5cydzIGRlc2lyZWQg YmVoYXZpb3IuICBDb21tZW50cz8NCg== --_000_949AFB3DEAF7423DA620ACCA24AFA26Bakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <73090B60C7EB4644B930322770505E20@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwPkl0IHNlZW1zIHRoYXQgdGhlIHNlbWFudGljcyBvZiB0aGUgJnF1 b3Q7cmVuZWdvdGlhdGlvbl9pbmZvJnF1b3Q7IGV4dGVuc2lvbiBhcmUgc2xpZ2h0bHkgbXVkZHku IFF1YWx5cyB1bmRlcnN0YW5kcyBpdCB0byBtZWFuIHRoYXQgdGhlIHNlcnZlciB3aWxsIG5vdCBw ZXJmb3JtIGluc2VjdXJlIHJlbmVnb3RpYXRpb24sIGZ1bGwgc3RvcC4gQnV0IE9wZW5TU0wgZnVy dGhlciB1bmRlcnN0YW5kcyBpdCB0byBtZWFuIHRoYXQgdGhlIHNlcnZlciAqd2lsbCogcGVyZm9y bQ0KIHNlY3VyZSBuZWdvdGlhdGlvbi4gT3BlblNTTCB0aGVyZWZvcmUgbWFrZXMgaXQgZGlmZmlj dWx0IHRvIHNpbXVsdGFuZW91c2x5IHNpbXVsdGFuZW91c2x5IHNhdGlzZnkgYm90aCBvZiBRdWFs eXMncyBleHBlY3RhdGlvbnMsIHNpbmNlIGRpc2FibGluZyBhbGwgcmVuZWdvdGlhdGlvbiB3aWxs IGNhdXNlIGl0IG5vdCB0byBzZW5kIHRoZSAmcXVvdDtyZW5lZ290aWF0aW9uX2luZm8mcXVvdDsg ZXh0ZW5zaW9uLiBQb3B1bGFyIG9wZW4gc291cmNlIHdlYiBzZXJ2ZXJzDQogaW1wbGVtZW50IGEg d29ya2Fyb3VuZCB3aGljaCBhY2hpZXZlcyBRdWFseXMncyBkZXNpcmVkIGJlaGF2aW9yLiZuYnNw OyBDb21tZW50cz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_949AFB3DEAF7423DA620ACCA24AFA26Bakamaicom_-- From nobody Wed Jun 13 13:03:34 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6313130F84 for ; Wed, 13 Jun 2018 13:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mqf8_mjyzpgs for ; Wed, 13 Jun 2018 13:03:30 -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 0C1A1130F82 for ; Wed, 13 Jun 2018 13:03:30 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id l22-v6so3522179oib.4 for ; Wed, 13 Jun 2018 13:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=gauWuvyewFHr7jM3URYnmxdsPdxDDSv2+11tE2a68TI=; b=nA+bMXR6MOhX6ELGu6zR8lwWwTSsouZ1zLtImdrycJ6vN37JUTpj5ehyjLyduVjs5X KjE42iT9V22O9npyq6m5AW+Sl7E2HTH/37T0ytUeQFpfSn9tVspRuWyJvTVXqV/1X+yv EUU8/H0pCMNggJTfyKP06e4GRXqVVOsTQt81lhEJuIOmgt7DX2Qz4lHYfuSa8mKluKud bXavxcFvDpUv0z5MuWDN+zpddG+/2bSzJcqDVErQ3v9T95vT5MJaaB4JUKEiJpRXPVrs hGlrHp18ZkTCRZ8zJhsOgqS5mY2CRTAo94OBQEKE48ypqLCEuKPaRsWwV9Z8Q+U7nu1V 6LZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gauWuvyewFHr7jM3URYnmxdsPdxDDSv2+11tE2a68TI=; b=drN0O+YVUnxgS6pFF8Yzlldj4QFc/PIvQvhO1MJEi6Br/WPveDIednSizdYiMEarAg lrcC2/JAi/CX+SoxRd8datQs8G7957sGe2Rn3VCIMSGoYHKQzytBjVZHUTgsHXwm/n2X Cc49je4ZRIbMDgAt8Jbl787Zr1H1vFDvbqMLxx8bSe0BsE6UN///DC8qdjs/YpUBrbLx VLyZ7qc0UR8CC80qhvNoPPYIcYUmaEmrOZNlN53rhX++baUYl/j2ZB9U/a56xjWPPTFf 5g+fBMFdFVfe+1GbHySAKv7jEjAUgRNTBvG3d/18dqHIiFFaHOA70NuEmGrsBXmWk0dM juog== X-Gm-Message-State: APt69E13MF5AEwU+IVryhKxVRN3Md9076WBKFRv1RnwHJCdV4giToS8q 236MLsUbGEyczpjtbQCDU986MRYAUkgd+kbSNtw= X-Google-Smtp-Source: ADUXVKLXi+Vl3kePvhpEUwKdQhE+6Jk2YAVHQdkNwP250lu/4n9Gj7pnZWsh6htDMLFcgpQbiXaObWroTsOM5Y/fIxE= X-Received: by 2002:aca:51cb:: with SMTP id f194-v6mr5689881oib.110.1528920209347; Wed, 13 Jun 2018 13:03:29 -0700 (PDT) MIME-Version: 1.0 References: <949AFB3D-EAF7-423D-A620-ACCA24AFA26B@akamai.com> In-Reply-To: <949AFB3D-EAF7-423D-A620-ACCA24AFA26B@akamai.com> From: Martin Thomson Date: Wed, 13 Jun 2018 13:03:19 -0700 Message-ID: To: rsalz=40akamai.com@dmarc.ietf.org Cc: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] What does "renegotiation_info" mean? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2018 20:03:32 -0000 Hi Rich, I think that the Qualys interpretation might be safer. That is, you probably should send R-I always. See Karthik's response to my suggestion that it might be OK to omit R-I in some cases: https://mailarchive.ietf.org/arch/msg/tls/TfiUa3M390augtvUoxH2D7L5LGM On Wed, Jun 13, 2018 at 12:47 PM Salz, Rich wrote: > > It seems that the semantics of the "renegotiation_info" extension are sli= ghtly muddy. Qualys understands it to mean that the server will not perform= insecure renegotiation, full stop. But OpenSSL further understands it to m= ean that the server *will* perform secure negotiation. OpenSSL therefore ma= kes it difficult to simultaneously simultaneously satisfy both of Qualys's = expectations, since disabling all renegotiation will cause it not to send t= he "renegotiation_info" extension. Popular open source web servers implemen= t a workaround which achieves Qualys's desired behavior. Comments? > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Jun 13 13:09:55 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A86B130F7C for ; Wed, 13 Jun 2018 13:09:53 -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 autolearn_force=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 CT6tfy9bPUqq for ; Wed, 13 Jun 2018 13:09:51 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0C48130F6F for ; Wed, 13 Jun 2018 13:09:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id AAAB654A06; Wed, 13 Jun 2018 23:09:48 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id V0isNZISgRfx; Wed, 13 Jun 2018 23:09:48 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 054FD27B; Wed, 13 Jun 2018 23:09:45 +0300 (EEST) Date: Wed, 13 Jun 2018 23:09:45 +0300 From: Ilari Liusvaara To: "Salz, Rich" Cc: "tls@ietf.org" Message-ID: <20180613200945.GA23235@LK-Perkele-VII> References: <949AFB3D-EAF7-423D-A620-ACCA24AFA26B@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <949AFB3D-EAF7-423D-A620-ACCA24AFA26B@akamai.com> User-Agent: Mutt/1.10.0 (2018-05-17) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] What does "renegotiation_info" mean? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2018 20:09:54 -0000 On Wed, Jun 13, 2018 at 07:47:11PM +0000, Salz, Rich wrote: > It seems that the semantics of the "renegotiation_info" extension are > slightly muddy. Qualys understands it to mean that the server will > not perform insecure renegotiation, full stop. But OpenSSL further > understands it to mean that the server *will* perform secure > negotiation. OpenSSL therefore makes it difficult to simultaneously > simultaneously satisfy both of Qualys's expectations, since disabling > all renegotiation will cause it not to send the "renegotiation_info" > extension. Popular open source web servers implement a workaround > which achieves Qualys's desired behavior. Comments? Then there are the clients that justifiably immediately abort the handshake if TLS 1.2 server_hello lacks renegotiation_info. This is because unless client then tries to probe for renegoitiation, which it can not in practice do because all the servers that just fail to renegotiate correctly, it can not tell if it is under attack or not. Not responding to renegotiation_info in TLS 1.2 is a security issue, even if there is no renegotiation support. OpenSSL should be fixed to respond to it in TLS 1.0 to 1.2 _regardless_ of if renegotiation is enabled or not. -Ilari From nobody Wed Jun 13 13:11:14 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB3D130F7F for ; Wed, 13 Jun 2018 13:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.951 X-Spam-Level: X-Spam-Status: No, score=-9.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaagF7Mcq7Cs for ; Wed, 13 Jun 2018 13:11:08 -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 C904F130F7E for ; Wed, 13 Jun 2018 13:11:08 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id j80-v6so2301087qke.9 for ; Wed, 13 Jun 2018 13:11:08 -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 :cc; bh=bOutOikE6tiuO8xzbpKhjniASzv0hLplsjcbEFjgOyQ=; b=N1bzh/RTSxn2yTF7Sx4DnCPPOby9Dm85c9NfE4Of64IQLB0dAHRLUHcBNGL73Bx5MG Yy0fJn6LYDJNcIgVERaAABOGTaegOuHzuAnkYuY54xJp17uf4pYMXj+m3l+MI//rfoSN sxuplKGmbmCy8PiKOs6UefTOin+U6+lwN8p6Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bOutOikE6tiuO8xzbpKhjniASzv0hLplsjcbEFjgOyQ=; b=jmKRGEXBC4lIPXc0rnoFyVBQTp+sUQ3Q8g6r66hKIj/u8Hu8NMPyaVB2URld49Z1MT 3b+g790+4TlKmqW+MF1x/NvGyLeAqKgH/SK3ufZZ4Pym9oyVLx9BPFMHrLs6Bc9B82R3 5EtJX+JyYjkAZI9IkdTw+Lh1IQH2c2ouVU7Gq44BDIGcZKpSq5agFeox4nmZCAgExIcD f8FGFvK2ferD8Z9Tu3t76CUtC9Hsgl8rpyCUYCKd7DfxL/wJYfH0+lT9QAo8M6q02O+c RDIUw756GDpAUHxfLJecRw6UbucGLbqApVOxlDYCBRIwdzs2Qk575/xbLuOAGXcndygz 7G/Q== X-Gm-Message-State: APt69E0JrpwEhyB5lg+9awLp972S3632b0KEmPGdT7Mn5us79x8mUyW1 sBC8SGKlqONLtlZX82OBjD17lsFFqlj1wjoZjeY0qzY= X-Google-Smtp-Source: ADUXVKK0tWapXVVxbttBP5c6gSz4WEsk7MkPN4zeMnIZ+PZQogTUigo6nn7FIUlQRbouQDJfp+ExDeDNB3f4pnOErI8= X-Received: by 2002:a37:9303:: with SMTP id v3-v6mr6008058qkd.318.1528920667580; Wed, 13 Jun 2018 13:11:07 -0700 (PDT) MIME-Version: 1.0 References: <949AFB3D-EAF7-423D-A620-ACCA24AFA26B@akamai.com> In-Reply-To: From: David Benjamin Date: Wed, 13 Jun 2018 16:10:55 -0400 Message-ID: To: Martin Thomson Cc: rsalz=40akamai.com@dmarc.ietf.org, "" Content-Type: multipart/alternative; boundary="00000000000048b172056e8b9533" Archived-At: Subject: Re: [TLS] What does "renegotiation_info" mean? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2018 20:11:12 -0000 --00000000000048b172056e8b9533 Content-Type: text/plain; charset="UTF-8" This is BoringSSL's interpretation as well. We don't support renegotiation on the server at all, but our server still implements the renegotiation_info extension in the degenerate case for the initial handshake. It is vacuously true that all renegotiations we'll perform on that connection are secure. :-) I believe the Go TLS stack has the same behavior. On Wed, Jun 13, 2018 at 4:03 PM Martin Thomson wrote: > Hi Rich, > > I think that the Qualys interpretation might be safer. That is, you > probably should send R-I always. See Karthik's response to my > suggestion that it might be OK to omit R-I in some cases: > > https://mailarchive.ietf.org/arch/msg/tls/TfiUa3M390augtvUoxH2D7L5LGM > On Wed, Jun 13, 2018 at 12:47 PM Salz, Rich > wrote: > > > > It seems that the semantics of the "renegotiation_info" extension are > slightly muddy. Qualys understands it to mean that the server will not > perform insecure renegotiation, full stop. But OpenSSL further understands > it to mean that the server *will* perform secure negotiation. OpenSSL > therefore makes it difficult to simultaneously simultaneously satisfy both > of Qualys's expectations, since disabling all renegotiation will cause it > not to send the "renegotiation_info" extension. Popular open source web > servers implement a workaround which achieves Qualys's desired behavior. > Comments? > > > > _______________________________________________ > > 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 > --00000000000048b172056e8b9533 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is BoringSSL's interpretation as well. We don'= ;t support renegotiation on the server at all, but our server still impleme= nts the renegotiation_info extension in the degenerate case for the initial= handshake. It is vacuously true that all renegotiations we'll perform = on that connection are secure. :-)

I believe the Go TLS stack has th= e same behavior.

On Wed,= Jun 13, 2018 at 4:03 PM Martin Thomson <martin.thomson@gmail.com> wrote:
Hi Rich,

I think that the Qualys interpretation might be safer.=C2=A0 That is, you probably should send R-I always. See Karthik's response to my
suggestion that it might be OK to omit R-I in some cases:

https://mailarchive.ietf.org/ar= ch/msg/tls/TfiUa3M390augtvUoxH2D7L5LGM
On Wed, Jun 13, 2018 at 12:47 PM Salz, Rich
<rsalz=3D40akamai.com@dmarc.ietf.org> wrote:
>
> It seems that the semantics of the "renegotiation_info" exte= nsion are slightly muddy. Qualys understands it to mean that the server wil= l not perform insecure renegotiation, full stop. But OpenSSL further unders= tands it to mean that the server *will* perform secure negotiation. OpenSSL= therefore makes it difficult to simultaneously simultaneously satisfy both= of Qualys's expectations, since disabling all renegotiation will cause= it not to send the "renegotiation_info" extension. Popular open = source web servers implement a workaround which achieves Qualys's desir= ed behavior.=C2=A0 Comments?
>
> _______________________________________________
> 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
--00000000000048b172056e8b9533-- From nobody Wed Jun 13 13:30:18 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8D9130E91 for ; Wed, 13 Jun 2018 13:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.251 X-Spam-Level: X-Spam-Status: No, score=-9.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Lj2mi9BCNic for ; Wed, 13 Jun 2018 13:30:12 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 F3F07130E27 for ; Wed, 13 Jun 2018 13:30:11 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id x34-v6so3717706qtk.5 for ; Wed, 13 Jun 2018 13:30:11 -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 :cc; bh=TqzgT82wgMLXgNZCqCG9SWYKUmfjGiVtXMNferMU1Fc=; b=DxtNV10owi1lkWOTe9v63NCpfRvpY9mlO6tSwcpTi8c9hOen5IGiG2MrF3nAdez4Px ryzRe10kkbMxyqe+iQrQjZJURAiX+xt+xovVSY9vJhpkyKVzH+/Qjhk1RGCh1tFEwOQQ ayLoHVB+GwzgZAIP3euyhsmSzXBsu/A5jUpGs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TqzgT82wgMLXgNZCqCG9SWYKUmfjGiVtXMNferMU1Fc=; b=lODr2NvV8vDVSucT96pL7FMJ4k74/u4734xyBCjl3l+8H1kBr7xnaJEaAHhF6IHz41 dNaWHuHeh8k+2wMBEEfwxdWL9t2YMTK2yy9mdL3Mz0wO8QnZ+CWv1iHJEzax2BXGidhk zTJcNbDKzatemlF4yAT51Ac3CWMiONdoeIISWQwrADK24GKvNIa1UThr4iPKzsvq05yw 5jFXwizUVjO9mmYcZwdSSshPC23ViM0z8PKLmPXtO9yB1g5bmNXGSRVUQuKAFucLWt7d Jb9tzOpn/6UuvtDQbAI7KWqfu2Uzeotsc42/vgR/gOc1c9v2d8wztXJepWgPtC33aQR1 kUOQ== X-Gm-Message-State: APt69E0RLoR4Y9BIuJSTrUaxPOrpT1fNivVWfz/UecKPFvuMTjqNaYKk helJFzSayWWt6lOmjba9muIDA4DFu1nL8M3g01aF+hI= X-Google-Smtp-Source: ADUXVKJdDEh03p4JeZaXE9jOgOgoTpw+1OEMjT7KQACWGdczRNW9d5yVDRwed8QdPYSeMTMkGh6d8U5OFH6dptv3PoI= X-Received: by 2002:a0c:ada5:: with SMTP id w34-v6mr6084293qvc.58.1528921810910; Wed, 13 Jun 2018 13:30:10 -0700 (PDT) MIME-Version: 1.0 References: <20180613180603.GA27662@mandy> In-Reply-To: From: David Benjamin Date: Wed, 13 Jun 2018 16:29:59 -0400 Message-ID: To: Daniel Migault Cc: Alessandro Ghedini , "" Content-Type: multipart/alternative; boundary="0000000000006e3a2d056e8bd9fc" Archived-At: Subject: Re: [TLS] Enforcing Protocol Invariants X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2018 20:30:16 -0000 --0000000000006e3a2d056e8bd9fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Are you asking about this new proposal (which still needs an amusing name), or the original GREASE mechanism? The original GREASE mechanism was only targetting ClientHello intolerance in servers. It's true that it uses specific values, and indeed there is nothing stopping buggy implementations from treating them differently. The thought then was ClientHello intolerance in servers is usually just accidental. It takes a certain willful ignorance to forget the default in your switch-case, and then go out of your way to special-case things, rather than recheck the spec as to what you're supposed to do. It was also meant to be lightweight (a one-time implementation cost and a one-time allocation). It's imperfect, but it does seem to help with the problem. This new proposal is targetting ServerHello intolerance problems. Rather than fixing a set of values initially, it regularly rerolls random values over time, with no fixed pattern. It should hopefully be more resilient to this sort of misbehavior. On the flip side, it is more work to maintain and only implementations that update sufficiently frequently can participate, whereas, in theory, anyone could deploy the original GREASE. On Wed, Jun 13, 2018 at 3:15 PM Daniel Migault wrote: > I also support something is being done in this direction. I like the idea > of taking ephemeral non allocated code points. > > What is not so clear to me is how GREASE prevents a buggy implementations > from behaving correctly for GREASE allocated code points, while remaining > buggy for the other (unallocated). code points. > Yours, > Daniel > > On Wed, Jun 13, 2018 at 2:06 PM, Alessandro Ghedini > wrote: > >> On Tue, Jun 12, 2018 at 12:27:39PM -0400, David Benjamin wrote: >> > Hi all, >> > >> > Now that TLS 1.3 is about done, perhaps it is time to reflect on the >> > ossification problems. >> > >> > TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may >> be >> > incrementally rolled out in an existing compliant TLS 1.2 deployment. >> Yet >> > we had problems. Widespread non-compliant servers broke on the TLS 1.3 >> > ClientHello, so versioning moved to supported_versions. Widespread >> > non-compliant middleboxes attempted to parse someone else=E2=80=99s >> ServerHellos, >> > so the protocol was further hacked to weave through their many defects= . >> > >> > I think I can speak for the working group that we do not want to repea= t >> > this adventure again. In general, I think the response to ossification >> is >> > two-fold: >> > >> > 1. It=E2=80=99s already happened, so how do we progress today? >> > 2. How do we avoid more of this tomorrow? >> > >> > The workarounds only answer the first question. For the second, TLS 1.= 3 >> has >> > a section which spells out a few protocol invariants >> > < >> https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section= .9..3 >> >. >> > It is all corollaries of existing TLS specification text, but hopefull= y >> > documenting it explicitly will help. But experience has shown >> specification >> > text is only necessary, not sufficient. >> > >> > For extensibility problems in servers, we have GREASE >> > . This enforces >> the >> > key rule in ClientHello processing: ignore unrecognized parameters. >> GREASE >> > enforces this by filling the ecosystem with them. TLS 1.3=E2=80=99s mi= ddlebox >> woes >> > were different. The key rule is: if you did not produce a ClientHello, >> you >> > cannot assume that you can parse the response. Analogously, we should >> fill >> > the ecosystem with such responses. We have an idea, but it is more >> involved >> > than GREASE, so we are very interested in the TLS community=E2=80=99s = feedback. >> > >> > In short, we plan to regularly mint new TLS versions (and likely other >> > sensitive parameters such as extensions), roughly every six weeks >> matching >> > Chrome=E2=80=99s release cycle. Chrome, Google servers, and any other = deployment >> > that wishes to participate, would support two (or more) versions of TL= S >> > 1.3: the standard stable 0x0304, and a rolling alternate version. Ever= y >> six >> > weeks, we would randomly pick a new code point. These versions will >> > otherwise be identical to TLS 1.3, save maybe minor details to separat= e >> > keys and exercise allowed syntax changes. The goal is to pave the way >> for >> > future versions of TLS by simulating them (=E2=80=9Cdraft negative one= =E2=80=9D). >> > >> > Of course, this scheme has some risk. It grabs code points everywhere. >> Code >> > points are plentiful, but we do sometimes have collisions (e.g. 26 and >> 40). >> > The entire point is to serve and maintain TLS=E2=80=99s extensibility,= so we >> > certainly do not wish to hamper it! Thus we have some safeguards in >> mind: >> > >> > * We will document every code point we use and what it refers to. (If >> the >> > volume is fine, we can email them to the list each time.) New >> allocations >> > can always avoid the lost numbers. At a rate of one every 6 weeks, it >> will >> > take over 7,000 years to exhaust everything. >> > >> > * We will avoid picking numbers that the IETF is likely to allocate, t= o >> > reduce the chance of collision. Rolling versions will not start with >> 0x03, >> > rolling cipher suites or extensions will not be contiguous with existi= ng >> > blocks, etc. >> > >> > * BoringSSL will not enable this by default. We will only enable it >> where >> > we can shut it back off. On our servers, we of course regularly deploy >> > changes. Chrome is also regularly updated and, moreover, we will gate >> it on >> > our server-controlled field trials >> > >> mechanism. We >> > hope that, in practice, only the last several code points will be in >> use at >> > a time. >> > >> > * Our clients would only support the most recent set of rolling >> parameters, >> > and our servers the last handful. As each value will be short-lived, t= he >> > ecosystem is unlikely to rely on them as de facto standards. Conversel= y, >> > like other extensions, implementations without them will still >> interoperate >> > fine. We would never offer a rolling parameter without the correspondi= ng >> > stable one. >> > >> > * If this ultimately does not work, we can stop at any time and only >> have >> > wasted a small portion of code points. >> > >> > * Finally, if the working group is open to it, these values could be >> > summarized in regular documents to reserve them, so that they are >> > ultimately reflected in the registries. A new document every six weeks >> is >> > probably impractical, but we can batch them up. >> > >> > We are interested in the community=E2=80=99s feedback on this proposal= =E2=80=94anyone >> who >> > might participate, better safeguards, or thoughts on the mechanism as = a >> > whole. We hope it will help the working group evolve its protocols mor= e >> > smoothly in the future. >> >> This looks interesting and I very much agree that we should do *somthing= * >> to >> try to avoid the pain we've seen with deploying TLS 1.3 for future >> versions. >> >> We (Cloudflare) would be happy to help with developing and deploying it, >> and >> see how the experiment goes (and maybe even help put a draft together if >> needed, >> if that is the form this proposal will take). >> >> Cheers >> > _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > --0000000000006e3a2d056e8bd9fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Are you asking about this new proposal (which still needs = an amusing name), or the original GREASE mechanism?

The = original GREASE mechanism was only targetting ClientHello intolerance in se= rvers. It's true that it uses specific values, and indeed there is noth= ing stopping buggy implementations from treating them differently. The thou= ght then was ClientHello intolerance in servers is usually just accidental.= It takes a certain willful ignorance to forget the default in your switch-= case, and then go out of your way to special-case things, rather than reche= ck the spec as to what you're supposed to do. It was also meant to be l= ightweight (a one-time implementation cost and a one-time allocation). It&#= 39;s imperfect, but it does seem to help with the problem.

This new proposal is targetting ServerHello intolerance problems. = Rather than fixing a set of values initially, it regularly rerolls random v= alues over time, with no fixed pattern. It should hopefully be more resilie= nt to this sort of misbehavior. On the flip side, it is more work to mainta= in and only implementations that update sufficiently frequently can partici= pate, whereas, in theory, anyone could deploy the original GREASE.

<= div class=3D"gmail_quote">
On Wed, Jun 13, 2018 at 3:15 PM = Daniel Migault <daniel.mi= gault@ericsson.com> wrote:
<= div dir=3D"ltr">
I also support something is being done in this directi= on. I like the idea of taking ephemeral non allocated code points.

What is not so clear to me is how GREASE prevents a= buggy implementations from behaving correctly for GREASE allocated code po= ints, while remaining buggy for the other (unallocated). code points.=C2=A0=
Yours,
Daniel

On Wed, Jun 13, 2018 at 2:06 PM, Alessand= ro Ghedini <alessandro@ghedini.me> wrote:
On Tue, Jun 12, 2018 at 12:27:39PM -0400, David Benjamin w= rote:
> Hi all,
>
> Now that TLS 1.3 is about done, perhaps it is time to reflect on the > ossification problems.
>
> TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may= be
> incrementally rolled out in an existing compliant TLS 1.2 deployment. = Yet
> we had problems. Widespread non-compliant servers broke on the TLS 1.3=
> ClientHello, so versioning moved to supported_versions. Widespread
> non-compliant middleboxes attempted to parse someone else=E2=80=99s Se= rverHellos,
> so the protocol was further hacked to weave through their many defects= .
>
> I think I can speak for the working group that we do not want to repea= t
> this adventure again. In general, I think the response to ossification= is
> two-fold:
>
> 1. It=E2=80=99s already happened, so how do we progress today?
> 2. How do we avoid more of this tomorrow?
>
> The workarounds only answer the first question. For the second, TLS 1.= 3 has
> a section which spells out a few protocol invariants
> <https:/= /tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.9..3&= gt;.
> It is all corollaries of existing TLS specification text, but ho= pefully
> documenting it explicitly will help. But experience has shown specific= ation
> text is only necessary, not sufficient.
>
> For extensibility problems in servers, we have GREASE
> <https://tools.ietf.org/html/draf= t-ietf-tls-grease-01>. This enforces the
> key rule in ClientHello pr= ocessing: ignore unrecognized parameters. GREASE
> enforces this by filling the ecosystem with them. TLS 1.3=E2=80=99s mi= ddlebox woes
> were different. The key rule is: if you did not produce a ClientHello,= you
> cannot assume that you can parse the response. Analogously, we should = fill
> the ecosystem with such responses. We have an idea, but it is more inv= olved
> than GREASE, so we are very interested in the TLS community=E2=80=99s = feedback.
>
> In short, we plan to regularly mint new TLS versions (and likely other=
> sensitive parameters such as extensions), roughly every six weeks matc= hing
> Chrome=E2=80=99s release cycle. Chrome, Google servers, and any other = deployment
> that wishes to participate, would support two (or more) versions of TL= S
> 1.3: the standard stable 0x0304, and a rolling alternate version. Ever= y six
> weeks, we would randomly pick a new code point. These versions will > otherwise be identical to TLS 1.3, save maybe minor details to separat= e
> keys and exercise allowed syntax changes. The goal is to pave the way = for
> future versions of TLS by simulating them (=E2=80=9Cdraft negative one= =E2=80=9D).
>
> Of course, this scheme has some risk. It grabs code points everywhere.= Code
> points are plentiful, but we do sometimes have collisions (e.g. 26 and= 40).
> The entire point is to serve and maintain TLS=E2=80=99s extensibility,= so we
> certainly do not wish to hamper it! Thus we have some safeguards in mi= nd:
>
> * We will document every code point we use and what it refers to. (If = the
> volume is fine, we can email them to the list each time.) New allocati= ons
> can always avoid the lost numbers. At a rate of one every 6 weeks, it = will
> take over 7,000 years to exhaust everything.
>
> * We will avoid picking numbers that the IETF is likely to allocate, t= o
> reduce the chance of collision. Rolling versions will not start with 0= x03,
> rolling cipher suites or extensions will not be contiguous with existi= ng
> blocks, etc.
>
> * BoringSSL will not enable this by default. We will only enable it wh= ere
> we can shut it back off. On our servers, we of course regularly deploy=
> changes. Chrome is also regularly updated and, moreover, we will gate = it on
> our server-controlled field trials
> <https://textslashplai= n.com/2017/10/18/chrome-field-trials/> mechanism. We
> hope that, in practice, only the last several code points will b= e in use at
> a time.
>
> * Our clients would only support the most recent set of rolling parame= ters,
> and our servers the last handful. As each value will be short-lived, t= he
> ecosystem is unlikely to rely on them as de facto standards. Conversel= y,
> like other extensions, implementations without them will still interop= erate
> fine. We would never offer a rolling parameter without the correspondi= ng
> stable one.
>
> * If this ultimately does not work, we can stop at any time and only h= ave
> wasted a small portion of code points.
>
> * Finally, if the working group is open to it, these values could be > summarized in regular documents to reserve them, so that they are
> ultimately reflected in the registries. A new document every six weeks= is
> probably impractical, but we can batch them up.
>
> We are interested in the community=E2=80=99s feedback on this proposal= =E2=80=94anyone who
> might participate, better safeguards, or thoughts on the mechanism as = a
> whole. We hope it will help the working group evolve its protocols mor= e
> smoothly in the future.

This looks interesting and I very much agree that we should do *somt= hing* to
try to avoid the pain we've seen with deploying TLS 1.3 for future vers= ions.

We (Cloudflare) would be happy to help with developing and deploying it, an= d
see how the experiment goes (and maybe even help put a draft together if ne= eded,
if that is the form this proposal will take).

Cheers
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000006e3a2d056e8bd9fc-- From nobody Wed Jun 13 14:05:00 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371AF130DFC for ; Wed, 13 Jun 2018 14:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zh68Kb0Pqlzc for ; Wed, 13 Jun 2018 14:04:57 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002: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 0A4C0130E93 for ; Wed, 13 Jun 2018 14:04:57 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id d123-v6so1440845ybh.9 for ; Wed, 13 Jun 2018 14:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=DC7CTfsu+q79f6buqFF3fQ/up5L0sueTMUQJQLt9v2U=; b=pnht7YDEPubf+obCyzTKSL8lmlHsNgXkCFwyN5HvtUZGVl0lvkVkk7NbHEri4rAHbz k07LaERVgE5NhhyOjv1O734/wXzlL5V543TT0N8vIRm9RlqBmFf1mzJ8sMzgKfi/P/Ey wVhO9RbSrBL2s8HcREFMdrmsL3hUjOfqUAMxl2/Oz1xoiOKXbW1ylyPK+yNWfgOdRqP/ 9dlGuaT0DzHaPTz50FjVooKwzzMfIONLnRJChEqk/nQqJIT1FPz10QjknSh4kCy6V44C t257LOENKL3xJl3hrJcTGGA0+0jLLIDM7S7DfBzaBHLRRJ44U425ma/MA/AWiUhfKGwu k9RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=DC7CTfsu+q79f6buqFF3fQ/up5L0sueTMUQJQLt9v2U=; b=lK/nhse10s5nKe6GvueCMH130P/6XdbwLs0dNZRDxkCErR7AHrvwvXX16VM1zCNsb0 0JjSBDuy1j8r++RUtbnpl35ntyNqM87dSv5Y0VmZIx8IkiugDVy3ZKXpzNyOsW2b3Gp+ f4ouZk1rEAfs6LeE3NUf280R89IHOz0w1Es+QJuVXwfWWSiw2kfLT6fkQddEEEBBsVZr i8BVcFwFxOrS2gokiyZw5fCRpdmu6lUY/hx6ckq7mTRSa6XQxnrBjaIldcPhkmorDd9F ivsXi78YnER4d/qbr4l4HnX/R/a6299xHVeZKG4PtdzD7IV+8QOsjo3B7Y2n46a3mHK+ /BxA== X-Gm-Message-State: APt69E2Bt7XnQN5YA9Hk7IiRgEttxVKiIvN7fgvz4lX2IYoHQmimk9Zc 4ZkZ0bO2c/fpRyPkj3GLf1jwPMTPUl1nF/Sq4xI= X-Google-Smtp-Source: ADUXVKLPZftPScoQ9p1OUBZCvX9zE+hRc7g80le2SmXMyh6CNpY4SWK0OGoQGEXHmhK0eXNeMKtmchSVLNegyjN8uEU= X-Received: by 2002:a25:bc84:: with SMTP id e4-v6mr3305918ybk.5.1528923896102; Wed, 13 Jun 2018 14:04:56 -0700 (PDT) MIME-Version: 1.0 References: <20180613180603.GA27662@mandy> In-Reply-To: <20180613180603.GA27662@mandy> From: Christopher Wood Date: Wed, 13 Jun 2018 14:04:44 -0700 Message-ID: To: alessandro@ghedini.me Cc: David Benjamin , "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Enforcing Protocol Invariants X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2018 21:05:00 -0000 On Wed, Jun 13, 2018 at 11:06 AM Alessandro Ghedini wrote: > > On Tue, Jun 12, 2018 at 12:27:39PM -0400, David Benjamin wrote: > > Hi all, > > > > Now that TLS 1.3 is about done, perhaps it is time to reflect on the > > ossification problems. > > > > TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may = be > > incrementally rolled out in an existing compliant TLS 1.2 deployment. Y= et > > we had problems. Widespread non-compliant servers broke on the TLS 1.3 > > ClientHello, so versioning moved to supported_versions. Widespread > > non-compliant middleboxes attempted to parse someone else=E2=80=99s Ser= verHellos, > > so the protocol was further hacked to weave through their many defects. > > > > I think I can speak for the working group that we do not want to repeat > > this adventure again. In general, I think the response to ossification = is > > two-fold: > > > > 1. It=E2=80=99s already happened, so how do we progress today? > > 2. How do we avoid more of this tomorrow? > > > > The workarounds only answer the first question. For the second, TLS 1.3= has > > a section which spells out a few protocol invariants > > . > > It is all corollaries of existing TLS specification text, but hopefully > > documenting it explicitly will help. But experience has shown specifica= tion > > text is only necessary, not sufficient. > > > > For extensibility problems in servers, we have GREASE > > . This enforces t= he > > key rule in ClientHello processing: ignore unrecognized parameters. GRE= ASE > > enforces this by filling the ecosystem with them. TLS 1.3=E2=80=99s mid= dlebox woes > > were different. The key rule is: if you did not produce a ClientHello, = you > > cannot assume that you can parse the response. Analogously, we should f= ill > > the ecosystem with such responses. We have an idea, but it is more invo= lved > > than GREASE, so we are very interested in the TLS community=E2=80=99s f= eedback. > > > > In short, we plan to regularly mint new TLS versions (and likely other > > sensitive parameters such as extensions), roughly every six weeks match= ing > > Chrome=E2=80=99s release cycle. Chrome, Google servers, and any other d= eployment > > that wishes to participate, would support two (or more) versions of TLS > > 1.3: the standard stable 0x0304, and a rolling alternate version. Every= six > > weeks, we would randomly pick a new code point. These versions will > > otherwise be identical to TLS 1.3, save maybe minor details to separate > > keys and exercise allowed syntax changes. The goal is to pave the way f= or > > future versions of TLS by simulating them (=E2=80=9Cdraft negative one= =E2=80=9D). > > > > Of course, this scheme has some risk. It grabs code points everywhere. = Code > > points are plentiful, but we do sometimes have collisions (e.g. 26 and = 40). > > The entire point is to serve and maintain TLS=E2=80=99s extensibility, = so we > > certainly do not wish to hamper it! Thus we have some safeguards in min= d: > > > > * We will document every code point we use and what it refers to. (If t= he > > volume is fine, we can email them to the list each time.) New allocatio= ns > > can always avoid the lost numbers. At a rate of one every 6 weeks, it w= ill > > take over 7,000 years to exhaust everything. > > > > * We will avoid picking numbers that the IETF is likely to allocate, to > > reduce the chance of collision. Rolling versions will not start with 0x= 03, > > rolling cipher suites or extensions will not be contiguous with existin= g > > blocks, etc. > > > > * BoringSSL will not enable this by default. We will only enable it whe= re > > we can shut it back off. On our servers, we of course regularly deploy > > changes. Chrome is also regularly updated and, moreover, we will gate i= t on > > our server-controlled field trials > > mechanism.= We > > hope that, in practice, only the last several code points will be in us= e at > > a time. > > > > * Our clients would only support the most recent set of rolling paramet= ers, > > and our servers the last handful. As each value will be short-lived, th= e > > ecosystem is unlikely to rely on them as de facto standards. Conversely= , > > like other extensions, implementations without them will still interope= rate > > fine. We would never offer a rolling parameter without the correspondin= g > > stable one. > > > > * If this ultimately does not work, we can stop at any time and only ha= ve > > wasted a small portion of code points. > > > > * Finally, if the working group is open to it, these values could be > > summarized in regular documents to reserve them, so that they are > > ultimately reflected in the registries. A new document every six weeks = is > > probably impractical, but we can batch them up. > > > > We are interested in the community=E2=80=99s feedback on this proposal= =E2=80=94anyone who > > might participate, better safeguards, or thoughts on the mechanism as a > > whole. We hope it will help the working group evolve its protocols more > > smoothly in the future. > > This looks interesting and I very much agree that we should do *somthing*= to > try to avoid the pain we've seen with deploying TLS 1.3 for future versio= ns. > > We (Cloudflare) would be happy to help with developing and deploying it, = and > see how the experiment goes (and maybe even help put a draft together if = needed, > if that is the form this proposal will take). +1 We (Apple) are interested in experimenting with this as well. Would it be possible for participating servers to support multiple random versions simultaneously? That would help address potentially longer release cycles. Best, Chris From nobody Wed Jun 13 14:22:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B1E130F9A for ; Wed, 13 Jun 2018 14:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.951 X-Spam-Level: X-Spam-Status: No, score=-9.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXlUcZG014OF for ; Wed, 13 Jun 2018 14:22:19 -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 0F7C8130F83 for ; Wed, 13 Jun 2018 14:22:19 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id k86-v6so2421738qkh.13 for ; Wed, 13 Jun 2018 14:22:19 -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 :cc; bh=pOBlHPd9+SzUtWVd+BKcIWfOd5G+JOjAUqEwWIqNXF4=; b=D9/5sQWEGFybfybxtIXAAzVXkIdH/cmbGgz1qwF5JjUs4F7FB7ybgga9lxH4VFbfpo Zqwa29FMSFl/iQeiM3zFHW1YBYIx9JnATR/GLh76isuu5LchKgjYDEnE0ghMszhQG87W grKd/49wrNAt3UGDpG3q/X4uz5e6ZlA5GU9+s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pOBlHPd9+SzUtWVd+BKcIWfOd5G+JOjAUqEwWIqNXF4=; b=EckCDDEZx7m+suELHTfg0CXD9VIB2SgueRI7Im+4Y+OmehVCKDq7d3hzhNsBD1tmip YxZ+amSk2wTePR7wpNU4A/GiuwQJqWr/XZ9z0iSHMjDFZbBODfCWghCWxSNeUxH3/Nf0 VPhVAEWz+yLeHP515kpYUzlawgz8fXx1RlM8Ro5+uhoKCqVci48uybxcC/fbkj5qMDtV zHGFeK/o1Wb8RaoJQb5e9XQBXVEmK91+izemEIN94P+3s6m3EoMgLr2cH1wSUt1a4Z8f Y9aRG3SXqbxWSvaF8JCCPR7mOLjtn4SYrBqGjpGRdYgie39Ecra4njJp7FMQvCE0uH41 r48A== X-Gm-Message-State: APt69E270R9h1pwgzmdewqHoee74DkRX0t2wJIEHM0MeXBUkNxCULmIJ UIuDywGBlcJ5nnSoUiDmp9Fu7fqOCT0tCt7fFC0Bm8g= X-Google-Smtp-Source: ADUXVKKJJfmWF7Tugi+b6oezotX2LEIsrx1Z3bTo2gVmI9Qr4QanmOIc8PpLoJZU8r8uRVot2dhE40hezhAap3tIq1I= X-Received: by 2002:a37:a608:: with SMTP id p8-v6mr5789386qke.82.1528924937936; Wed, 13 Jun 2018 14:22:17 -0700 (PDT) MIME-Version: 1.0 References: <20180613180603.GA27662@mandy> In-Reply-To: From: David Benjamin Date: Wed, 13 Jun 2018 17:22:05 -0400 Message-ID: To: Christopher Wood Cc: alessandro@ghedini.me, "" Content-Type: multipart/alternative; boundary="000000000000d0df57056e8c937c" Archived-At: Subject: Re: [TLS] Enforcing Protocol Invariants X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2018 21:22:23 -0000 --000000000000d0df57056e8c937c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 13, 2018 at 5:04 PM Christopher Wood < christopherwood07@gmail.com> wrote: > On Wed, Jun 13, 2018 at 11:06 AM Alessandro Ghedini > wrote: > > > > On Tue, Jun 12, 2018 at 12:27:39PM -0400, David Benjamin wrote: > > > Hi all, > > > > > > Now that TLS 1.3 is about done, perhaps it is time to reflect on the > > > ossification problems. > > > > > > TLS is an extensible protocol. TLS 1.3 is backwards-compatible and ma= y > be > > > incrementally rolled out in an existing compliant TLS 1.2 deployment. > Yet > > > we had problems. Widespread non-compliant servers broke on the TLS 1.= 3 > > > ClientHello, so versioning moved to supported_versions. Widespread > > > non-compliant middleboxes attempted to parse someone else=E2=80=99s > ServerHellos, > > > so the protocol was further hacked to weave through their many defect= s. > > > > > > I think I can speak for the working group that we do not want to repe= at > > > this adventure again. In general, I think the response to ossificatio= n > is > > > two-fold: > > > > > > 1. It=E2=80=99s already happened, so how do we progress today? > > > 2. How do we avoid more of this tomorrow? > > > > > > The workarounds only answer the first question. For the second, TLS > 1.3 has > > > a section which spells out a few protocol invariants > > > < > https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.= 9..3 > >. > > > It is all corollaries of existing TLS specification text, but hopeful= ly > > > documenting it explicitly will help. But experience has shown > specification > > > text is only necessary, not sufficient. > > > > > > For extensibility problems in servers, we have GREASE > > > . This enforces > the > > > key rule in ClientHello processing: ignore unrecognized parameters. > GREASE > > > enforces this by filling the ecosystem with them. TLS 1.3=E2=80=99s m= iddlebox > woes > > > were different. The key rule is: if you did not produce a ClientHello= , > you > > > cannot assume that you can parse the response. Analogously, we should > fill > > > the ecosystem with such responses. We have an idea, but it is more > involved > > > than GREASE, so we are very interested in the TLS community=E2=80=99s= feedback. > > > > > > In short, we plan to regularly mint new TLS versions (and likely othe= r > > > sensitive parameters such as extensions), roughly every six weeks > matching > > > Chrome=E2=80=99s release cycle. Chrome, Google servers, and any other > deployment > > > that wishes to participate, would support two (or more) versions of T= LS > > > 1.3: the standard stable 0x0304, and a rolling alternate version. > Every six > > > weeks, we would randomly pick a new code point. These versions will > > > otherwise be identical to TLS 1.3, save maybe minor details to separa= te > > > keys and exercise allowed syntax changes. The goal is to pave the way > for > > > future versions of TLS by simulating them (=E2=80=9Cdraft negative on= e=E2=80=9D). > > > > > > Of course, this scheme has some risk. It grabs code points everywhere= . > Code > > > points are plentiful, but we do sometimes have collisions (e.g. 26 an= d > 40). > > > The entire point is to serve and maintain TLS=E2=80=99s extensibility= , so we > > > certainly do not wish to hamper it! Thus we have some safeguards in > mind: > > > > > > * We will document every code point we use and what it refers to. (If > the > > > volume is fine, we can email them to the list each time.) New > allocations > > > can always avoid the lost numbers. At a rate of one every 6 weeks, it > will > > > take over 7,000 years to exhaust everything. > > > > > > * We will avoid picking numbers that the IETF is likely to allocate, = to > > > reduce the chance of collision. Rolling versions will not start with > 0x03, > > > rolling cipher suites or extensions will not be contiguous with > existing > > > blocks, etc. > > > > > > * BoringSSL will not enable this by default. We will only enable it > where > > > we can shut it back off. On our servers, we of course regularly deplo= y > > > changes. Chrome is also regularly updated and, moreover, we will gate > it on > > > our server-controlled field trials > > > > mechanism. We > > > hope that, in practice, only the last several code points will be in > use at > > > a time. > > > > > > * Our clients would only support the most recent set of rolling > parameters, > > > and our servers the last handful. As each value will be short-lived, > the > > > ecosystem is unlikely to rely on them as de facto standards. > Conversely, > > > like other extensions, implementations without them will still > interoperate > > > fine. We would never offer a rolling parameter without the > corresponding > > > stable one. > > > > > > * If this ultimately does not work, we can stop at any time and only > have > > > wasted a small portion of code points. > > > > > > * Finally, if the working group is open to it, these values could be > > > summarized in regular documents to reserve them, so that they are > > > ultimately reflected in the registries. A new document every six week= s > is > > > probably impractical, but we can batch them up. > > > > > > We are interested in the community=E2=80=99s feedback on this proposa= l=E2=80=94anyone > who > > > might participate, better safeguards, or thoughts on the mechanism as= a > > > whole. We hope it will help the working group evolve its protocols mo= re > > > smoothly in the future. > > > > This looks interesting and I very much agree that we should do > *somthing* to > > try to avoid the pain we've seen with deploying TLS 1.3 for future > versions. > > > > We (Cloudflare) would be happy to help with developing and deploying it= , > and > > see how the experiment goes (and maybe even help put a draft together i= f > needed, > > if that is the form this proposal will take). > > +1 > > We (Apple) are interested in experimenting with this as well. Would it > be possible for > participating servers to support multiple random versions > simultaneously? That would > help address potentially longer release cycles. That's great to hear (both of you)! Supporting multiple values should be easy. Any participating stack already must support two variants of TLS 1.3, the standard one and this rolling version. Going from two to several is an easy step, on client or server. (For us, this machinery is all a remnant of the middlebox experiments we ran.) We were expecting our servers to support a handful of values anyway to account for our own release cycles. We can experiment with the exact cadence and code point lifetimes based on who all wishes to do this and what works. (At the worst case, mismatch is fine as both sides will just negotiate the standard TLS 1.3. But an individual connection only exercises the ServerHello when both sides match, so we'll want to maximize matches.) David --000000000000d0df57056e8c937c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 13= , 2018 at 5:04 PM Christopher Wood <christopherwood07@gmail.com> wrote:
On Wed, Jun 13, 2018 at 11:06 AM Alessandro Ghedini
<alessandro@g= hedini.me> wrote:
>
> On Tue, Jun 12, 2018 at 12:27:39PM -0400, David Benjamin wrote:
> > Hi all,
> >
> > Now that TLS 1.3 is about done, perhaps it is time to reflect on = the
> > ossification problems.
> >
> > TLS is an extensible protocol. TLS 1.3 is backwards-compatible an= d may be
> > incrementally rolled out in an existing compliant TLS 1.2 deploym= ent. Yet
> > we had problems. Widespread non-compliant servers broke on the TL= S 1.3
> > ClientHello, so versioning moved to supported_versions. Widesprea= d
> > non-compliant middleboxes attempted to parse someone else=E2=80= =99s ServerHellos,
> > so the protocol was further hacked to weave through their many de= fects.
> >
> > I think I can speak for the working group that we do not want to = repeat
> > this adventure again. In general, I think the response to ossific= ation is
> > two-fold:
> >
> > 1. It=E2=80=99s already happened, so how do we progress today? > > 2. How do we avoid more of this tomorrow?
> >
> > The workarounds only answer the first question. For the second, T= LS 1.3 has
> > a section which spells out a few protocol invariants
> > <https://t= lswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.9..3>= ;.
> > It is all corollaries of existing TLS specification text, but hop= efully
> > documenting it explicitly will help. But experience has shown spe= cification
> > text is only necessary, not sufficient.
> >
> > For extensibility problems in servers, we have GREASE
> > <https://tools.ietf.org/html/draft-= ietf-tls-grease-01>. This enforces the
> > key rule in ClientHello processing: ignore unrecognized parameter= s. GREASE
> > enforces this by filling the ecosystem with them. TLS 1.3=E2=80= =99s middlebox woes
> > were different. The key rule is: if you did not produce a ClientH= ello, you
> > cannot assume that you can parse the response. Analogously, we sh= ould fill
> > the ecosystem with such responses. We have an idea, but it is mor= e involved
> > than GREASE, so we are very interested in the TLS community=E2=80= =99s feedback.
> >
> > In short, we plan to regularly mint new TLS versions (and likely = other
> > sensitive parameters such as extensions), roughly every six weeks= matching
> > Chrome=E2=80=99s release cycle. Chrome, Google servers, and any o= ther deployment
> > that wishes to participate, would support two (or more) versions = of TLS
> > 1.3: the standard stable 0x0304, and a rolling alternate version.= Every six
> > weeks, we would randomly pick a new code point. These versions wi= ll
> > otherwise be identical to TLS 1.3, save maybe minor details to se= parate
> > keys and exercise allowed syntax changes. The goal is to pave the= way for
> > future versions of TLS by simulating them (=E2=80=9Cdraft negativ= e one=E2=80=9D).
> >
> > Of course, this scheme has some risk. It grabs code points everyw= here. Code
> > points are plentiful, but we do sometimes have collisions (e.g. 2= 6 and 40).
> > The entire point is to serve and maintain TLS=E2=80=99s extensibi= lity, so we
> > certainly do not wish to hamper it! Thus we have some safeguards = in mind:
> >
> > * We will document every code point we use and what it refers to.= (If the
> > volume is fine, we can email them to the list each time.) New all= ocations
> > can always avoid the lost numbers. At a rate of one every 6 weeks= , it will
> > take over 7,000 years to exhaust everything.
> >
> > * We will avoid picking numbers that the IETF is likely to alloca= te, to
> > reduce the chance of collision. Rolling versions will not start w= ith 0x03,
> > rolling cipher suites or extensions will not be contiguous with e= xisting
> > blocks, etc.
> >
> > * BoringSSL will not enable this by default. We will only enable = it where
> > we can shut it back off. On our servers, we of course regularly d= eploy
> > changes. Chrome is also regularly updated and, moreover, we will = gate it on
> > our server-controlled field trials
> > <https://textslashplain.com/2= 017/10/18/chrome-field-trials/> mechanism. We
> > hope that, in practice, only the last several code points will be= in use at
> > a time.
> >
> > * Our clients would only support the most recent set of rolling p= arameters,
> > and our servers the last handful. As each value will be short-liv= ed, the
> > ecosystem is unlikely to rely on them as de facto standards. Conv= ersely,
> > like other extensions, implementations without them will still in= teroperate
> > fine. We would never offer a rolling parameter without the corres= ponding
> > stable one.
> >
> > * If this ultimately does not work, we can stop at any time and o= nly have
> > wasted a small portion of code points.
> >
> > * Finally, if the working group is open to it, these values could= be
> > summarized in regular documents to reserve them, so that they are=
> > ultimately reflected in the registries. A new document every six = weeks is
> > probably impractical, but we can batch them up.
> >
> > We are interested in the community=E2=80=99s feedback on this pro= posal=E2=80=94anyone who
> > might participate, better safeguards, or thoughts on the mechanis= m as a
> > whole. We hope it will help the working group evolve its protocol= s more
> > smoothly in the future.
>
> This looks interesting and I very much agree that we should do *somthi= ng* to
> try to avoid the pain we've seen with deploying TLS 1.3 for future= versions.
>
> We (Cloudflare) would be happy to help with developing and deploying i= t, and
> see how the experiment goes (and maybe even help put a draft together = if needed,
> if that is the form this proposal will take).

+1

We (Apple) are interested in experimenting with this as well. Would it
be possible for
participating servers to support multiple random versions
simultaneously? That would
help address potentially longer release cycles.

=
That's great to hear (both of you)!

Suppo= rting multiple values should be easy.=C2=A0Any participating stack already = must support two variants of TLS 1.3, the standard one and this rolling ver= sion. Going from two to several is an easy step, on client or server. (For = us, this machinery is all a remnant of the middlebox experiments we ran.) W= e were expecting our servers to support a handful of values anyway to accou= nt for our own release cycles. We can experiment with the exact cadence and= code point lifetimes based on who all wishes to do this and what works.

(At the worst case, mismatch is fine as both sides w= ill just negotiate the standard TLS 1.3.=C2=A0But an individual connection = only exercises the ServerHello when both sides match, so we'll want to = maximize matches.)

David
--000000000000d0df57056e8c937c-- From nobody Wed Jun 13 14:57:21 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23734130E97 for ; Wed, 13 Jun 2018 14:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKtJ1V0_vy_Q for ; Wed, 13 Jun 2018 14:57:17 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 C4F13130E96 for ; Wed, 13 Jun 2018 14:57:17 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5DLvDJ2024725; Wed, 13 Jun 2018 22:57:13 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=67QkNy0HgvDZ+y64RwQ7RpiL9ijQ+0gM7TbBH+u56S4=; b=GRJRrxGYxtohVensw+uArrZ6uIoaBgnJB7eZbkvS5edDWW6u1yj71EjUMs/AhjSCU0ZN gXzNL3ZafBaydDRjyzv34KPJtmGyJrSlrsANOaHd/8qV7mVwFPf6urUZks+alYf69WHs 9JQGFeQ5X4LCmu4R/+M9ftnJcNQsHE7fLoVcet3Awexe+QEjNLxOAwGQfyFAm73dJsDC gJlOq8TDe5Nc83rtJqgSZQX0D0azuZiqvzHmP+pGOD3eQd7q7dQBQ8+Sa9eB4axXndJ6 l8trm5KFcsk0p1p7dKuxcmdQ8XS8WRRa//rVL3QR/a90tYAJrhfx0QKxs0KYc3AlTqZU yA== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2jjp9mb13g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Jun 2018 22:57:13 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5DLuekB030625; Wed, 13 Jun 2018 17:57:12 -0400 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint4.akamai.com with ESMTP id 2jjp74kmt4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 13 Jun 2018 17:57:11 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 13 Jun 2018 14:57:11 -0700 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Wed, 13 Jun 2018 16:57:11 -0500 From: "Salz, Rich" To: David Benjamin , Martin Thomson CC: "" , "rsalz=40akamai.com@dmarc.ietf.org" Thread-Topic: [TLS] What does "renegotiation_info" mean? Thread-Index: AQHUA09SuenRYICwtkWJUMgDXynC2KRe8FiAgAACIID//9qhAA== Date: Wed, 13 Jun 2018 21:57:11 +0000 Message-ID: <1024ECCE-9145-4E9F-B0B7-A70D66DC4C05@akamai.com> References: <949AFB3D-EAF7-423D-A620-ACCA24AFA26B@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.d.1.180523 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.34] Content-Type: multipart/alternative; boundary="_000_1024ECCE91454E9FB0B7A70D66DC4C05akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-13_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=746 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806130234 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-13_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=677 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806130234 Archived-At: Subject: Re: [TLS] What does "renegotiation_info" mean? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2018 21:57:20 -0000 --_000_1024ECCE91454E9FB0B7A70D66DC4C05akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgcmVwbGllczsgSSBwdXQgYSBzdW1tYXJ5IGluIGh0dHBzOi8vZ2l0aHVi LmNvbS9vcGVuc3NsL29wZW5zc2wvaXNzdWVzLzY0ODQgZm9yIE9wZW5TU0wNCg0KKG9vaCwgbG9v aywgSSBnb3QgYSBETUFSQyB3b3JrLWFyb3VuZCA6KQ0KDQo= --_000_1024ECCE91454E9FB0B7A70D66DC4C05akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <1F2C8CE9D667274D8A3AC460169632CC@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoYW5rcyBmb3IgdGhlIHJlcGxpZXM7IEkgcHV0IGEgc3VtbWFyeSBpbiA8YSBo cmVmPSJodHRwczovL2dpdGh1Yi5jb20vb3BlbnNzbC9vcGVuc3NsL2lzc3Vlcy82NDg0Ij4NCmh0 dHBzOi8vZ2l0aHViLmNvbS9vcGVuc3NsL29wZW5zc2wvaXNzdWVzLzY0ODQ8L2E+IGZvciBPcGVu U1NMPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihvb2gsIGxvb2ssIEkgZ290IGEgRE1BUkMgd29y ay1hcm91bmQgOik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1024ECCE91454E9FB0B7A70D66DC4C05akamaicom_-- From nobody Wed Jun 13 17:12:30 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5939A130E60 for ; Wed, 13 Jun 2018 17:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjHhvHGcoX5j for ; Wed, 13 Jun 2018 17:12:25 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010: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 0FD821277D2 for ; Wed, 13 Jun 2018 17:12:25 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id j13-v6so6576831lfb.13 for ; Wed, 13 Jun 2018 17:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=W8Et7n7+1gct5g770Yuq5zLu0pNceDL4icrveVETY5I=; b=mqJUwnxupk3CI4/ZSaq5ycUYU6OlNcgmaZc1gL5Gn/kp5YQCRt5DD5fQ6Rqi4dj9Y/ tACAsE6vAQhKzygDWnLV8OG4xaeQdr7iiGmxMncwpSzen+An4MMS8unpzx1J6JcnTHuv pOwuiarCIBuZBsn07kfn4MARvnItu1QvEwdS0oNCzs0A/W6XdD1pQoAhaj4MScrha2Vc 5sb6XBBn207e7L2BQeOmVY5f7fcEC4WrhV5jNQWUIgI83rlN0UHnKv8gqQvyy+0aVB+F CQInu1oqdOBNqGuuxHKsYa42mESBS+iNMEjPw9whz1we2cE93UInQYAwENiWKnVi7VkJ ou3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=W8Et7n7+1gct5g770Yuq5zLu0pNceDL4icrveVETY5I=; b=rL7BIbDw225ilmD6c84P5zeaJwDodpAAMNA3Osg8nnpTHNdK65GdAu02fV0xKKh0Wl HrlackIqRVfSSupCUsSTcOv+iBH1fIBtdx1v/NgKuovXvlwkhvgRkrV7kEkVt9LumidC B8eb+IvEN+T+P7hbCjH8tcaOtBvHfhqqByMWovXXksOoz4dY5IpEpV9mvtZyJF64Jhlv gPoNRbYOJ3Up9pTcLdlqp912HrFD9Lxd+5L9GN7ZUj58jRixtauTE/ykXJOuh7w2kIVX 9ab0sajDI+Lrp+Ge7ffePeXrhIqXWmzqxvEhp6IzIgA7Itvzoc12Hk58TRvMm5tBwakk mCig== X-Gm-Message-State: APt69E0WZ7K3+VMc/DyaZEdog646ef87GCLthUUF5KalTnI7pTGhubvf G1XqaQ7qB5Va9d0xRvKcKlISJ0OMTduOG735/iA= X-Google-Smtp-Source: ADUXVKJJiMNM/RQM7R7WlBaSgXJe4Cit5zJ8impAF8tGNeiXUIPlY3akzaKbejx6hEq5AqodPM6UHG8lsZL03j3czvY= X-Received: by 2002:a19:4f06:: with SMTP id d6-v6mr4253525lfb.73.1528935143360; Wed, 13 Jun 2018 17:12:23 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 2002:a2e:2e1a:0:0:0:0:0 with HTTP; Wed, 13 Jun 2018 17:12:22 -0700 (PDT) In-Reply-To: References: <20180613180603.GA27662@mandy> From: Daniel Migault Date: Wed, 13 Jun 2018 20:12:22 -0400 X-Google-Sender-Auth: K7955q6axDXH1z6806CUzghOMIU Message-ID: To: David Benjamin Cc: "" Content-Type: multipart/alternative; boundary="0000000000001acbd3056e8ef4ec" Archived-At: Subject: Re: [TLS] Enforcing Protocol Invariants X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2018 00:12:28 -0000 --0000000000001acbd3056e8ef4ec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The two mechanisms address different targets but overall I prefer the design of the new proposal. Yours, Daniel On Wed, Jun 13, 2018 at 4:29 PM, David Benjamin wrote: > Are you asking about this new proposal (which still needs an amusing > name), or the original GREASE mechanism? > > The original GREASE mechanism was only targetting ClientHello intolerance > in servers. It's true that it uses specific values, and indeed there is > nothing stopping buggy implementations from treating them differently. Th= e > thought then was ClientHello intolerance in servers is usually just > accidental. It takes a certain willful ignorance to forget the default in > your switch-case, and then go out of your way to special-case things, > rather than recheck the spec as to what you're supposed to do. It was als= o > meant to be lightweight (a one-time implementation cost and a one-time > allocation). It's imperfect, but it does seem to help with the problem. > > This new proposal is targetting ServerHello intolerance problems. Rather > than fixing a set of values initially, it regularly rerolls random values > over time, with no fixed pattern. It should hopefully be more resilient t= o > this sort of misbehavior. On the flip side, it is more work to maintain a= nd > only implementations that update sufficiently frequently can participate, > whereas, in theory, anyone could deploy the original GREASE. > > On Wed, Jun 13, 2018 at 3:15 PM Daniel Migault < > daniel.migault@ericsson.com> wrote: > >> I also support something is being done in this direction. I like the ide= a >> of taking ephemeral non allocated code points. >> >> What is not so clear to me is how GREASE prevents a buggy implementation= s >> from behaving correctly for GREASE allocated code points, while remainin= g >> buggy for the other (unallocated). code points. >> Yours, >> Daniel >> >> On Wed, Jun 13, 2018 at 2:06 PM, Alessandro Ghedini < >> alessandro@ghedini.me> wrote: >> >>> On Tue, Jun 12, 2018 at 12:27:39PM -0400, David Benjamin wrote: >>> > Hi all, >>> > >>> > Now that TLS 1.3 is about done, perhaps it is time to reflect on the >>> > ossification problems. >>> > >>> > TLS is an extensible protocol. TLS 1.3 is backwards-compatible and ma= y >>> be >>> > incrementally rolled out in an existing compliant TLS 1.2 deployment. >>> Yet >>> > we had problems. Widespread non-compliant servers broke on the TLS 1.= 3 >>> > ClientHello, so versioning moved to supported_versions. Widespread >>> > non-compliant middleboxes attempted to parse someone else=E2=80=99s >>> ServerHellos, >>> > so the protocol was further hacked to weave through their many >>> defects.. >>> >>> > >>> > I think I can speak for the working group that we do not want to repe= at >>> > this adventure again. In general, I think the response to ossificatio= n >>> is >>> > two-fold: >>> > >>> > 1. It=E2=80=99s already happened, so how do we progress today? >>> > 2. How do we avoid more of this tomorrow? >>> > >>> > The workarounds only answer the first question. For the second, TLS >>> 1.3 has >>> > a section which spells out a few protocol invariants >>> > >> tls13.html#rfc.section.9..3>. >>> > It is all corollaries of existing TLS specification text, but hopeful= ly >>> > documenting it explicitly will help. But experience has shown >>> specification >>> > text is only necessary, not sufficient. >>> > >>> > For extensibility problems in servers, we have GREASE >>> > . This enforces >>> the >>> > key rule in ClientHello processing: ignore unrecognized parameters. >>> GREASE >>> > enforces this by filling the ecosystem with them. TLS 1.3=E2=80=99s m= iddlebox >>> woes >>> > were different. The key rule is: if you did not produce a ClientHello= , >>> you >>> > cannot assume that you can parse the response. Analogously, we should >>> fill >>> > the ecosystem with such responses. We have an idea, but it is more >>> involved >>> > than GREASE, so we are very interested in the TLS community=E2=80=99s= feedback. >>> > >>> > In short, we plan to regularly mint new TLS versions (and likely othe= r >>> > sensitive parameters such as extensions), roughly every six weeks >>> matching >>> > Chrome=E2=80=99s release cycle. Chrome, Google servers, and any other >>> deployment >>> > that wishes to participate, would support two (or more) versions of T= LS >>> > 1.3: the standard stable 0x0304, and a rolling alternate version. >>> Every six >>> > weeks, we would randomly pick a new code point. These versions will >>> > otherwise be identical to TLS 1.3, save maybe minor details to separa= te >>> > keys and exercise allowed syntax changes. The goal is to pave the way >>> for >>> > future versions of TLS by simulating them (=E2=80=9Cdraft negative on= e=E2=80=9D). >>> > >>> > Of course, this scheme has some risk. It grabs code points everywhere= . >>> Code >>> > points are plentiful, but we do sometimes have collisions (e.g. 26 an= d >>> 40). >>> > The entire point is to serve and maintain TLS=E2=80=99s extensibility= , so we >>> > certainly do not wish to hamper it! Thus we have some safeguards in >>> mind: >>> > >>> > * We will document every code point we use and what it refers to. (If >>> the >>> > volume is fine, we can email them to the list each time.) New >>> allocations >>> > can always avoid the lost numbers. At a rate of one every 6 weeks, it >>> will >>> > take over 7,000 years to exhaust everything. >>> > >>> > * We will avoid picking numbers that the IETF is likely to allocate, = to >>> > reduce the chance of collision. Rolling versions will not start with >>> 0x03, >>> > rolling cipher suites or extensions will not be contiguous with >>> existing >>> > blocks, etc. >>> > >>> > * BoringSSL will not enable this by default. We will only enable it >>> where >>> > we can shut it back off. On our servers, we of course regularly deplo= y >>> > changes. Chrome is also regularly updated and, moreover, we will gate >>> it on >>> > our server-controlled field trials >>> > >>> mechanism. We >>> > hope that, in practice, only the last several code points will be in >>> use at >>> > a time. >>> > >>> > * Our clients would only support the most recent set of rolling >>> parameters, >>> > and our servers the last handful. As each value will be short-lived, >>> the >>> > ecosystem is unlikely to rely on them as de facto standards. >>> Conversely, >>> > like other extensions, implementations without them will still >>> interoperate >>> > fine. We would never offer a rolling parameter without the >>> corresponding >>> > stable one. >>> > >>> > * If this ultimately does not work, we can stop at any time and only >>> have >>> > wasted a small portion of code points. >>> > >>> > * Finally, if the working group is open to it, these values could be >>> > summarized in regular documents to reserve them, so that they are >>> > ultimately reflected in the registries. A new document every six week= s >>> is >>> > probably impractical, but we can batch them up. >>> > >>> > We are interested in the community=E2=80=99s feedback on this proposa= l=E2=80=94anyone >>> who >>> > might participate, better safeguards, or thoughts on the mechanism as= a >>> > whole. We hope it will help the working group evolve its protocols mo= re >>> > smoothly in the future. >>> >>> This looks interesting and I very much agree that we should do >>> *somthing* to >>> try to avoid the pain we've seen with deploying TLS 1.3 for future >>> versions. >>> >>> We (Cloudflare) would be happy to help with developing and deploying it= , >>> and >>> see how the experiment goes (and maybe even help put a draft together i= f >>> needed, >>> if that is the form this proposal will take). >>> >>> Cheers >>> >> _______________________________________________ >>> 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 > > --0000000000001acbd3056e8ef4ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The two mechanisms address different targets but over= all I prefer the design of the new proposal.
Yours,
Daniel

On Wed, Jun 13, 2018 at 4:29 PM, David Benjamin <davidben@= chromium.org> wrote:
Are you asking about this new proposal (which still needs an amu= sing name), or the original GREASE mechanism?

The origin= al GREASE mechanism was only targetting ClientHello intolerance in servers.= It's true that it uses specific values, and indeed there is nothing st= opping buggy implementations from treating them differently. The thought th= en was ClientHello intolerance in servers is usually just accidental. It ta= kes a certain willful ignorance to forget the default in your switch-case, = and then go out of your way to special-case things, rather than recheck the= spec as to what you're supposed to do. It was also meant to be lightwe= ight (a one-time implementation cost and a one-time allocation). It's i= mperfect, but it does seem to help with the problem.

This new proposal is targetting ServerHello intolerance problems. Rather= than fixing a set of values initially, it regularly rerolls random values = over time, with no fixed pattern. It should hopefully be more resilient to = this sort of misbehavior. On the flip side, it is more work to maintain and= only implementations that update sufficiently frequently can participate, = whereas, in theory, anyone could deploy the original GREASE.

On Wed, Jun 13, 2018 = at 3:15 PM Daniel Migault <daniel.migault@ericsson.com> wrote:
I= also support something is being done in this direction. I like the idea of= taking ephemeral non allocated code points.

What is not so clear to me is how GREASE prevents a buggy implementations= from behaving correctly for GREASE allocated code points, while remaining = buggy for the other (unallocated). code points.=C2=A0
Yours,=
Daniel

On Wed, Jun 13, 2018 at 2:06 PM, Alessandro Ghedini <ale= ssandro@ghedini.me> wrote:
= On Tue, Jun 12, 2018 at 12:27:39PM -0400, David Benj= amin wrote:
> Hi all,
>
> Now that TLS 1.3 is about done, perhaps it is time to reflect on the > ossification problems.
>
> TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may= be
> incrementally rolled out in an existing compliant TLS 1.2 deployment. = Yet
> we had problems. Widespread non-compliant servers broke on the TLS 1.3=
> ClientHello, so versioning moved to supported_versions. Widespread
> non-compliant middleboxes attempted to parse someone else=E2=80=99s Se= rverHellos,
 > so the protocol was further hacked to weave through their many defects= ..

>
> I think I can speak for the working group that we do not want to repea= t
> this adventure again. In general, I think the response to ossification= is
> two-fold:
>
> 1. It=E2=80=99s already happened, so how do we progress today?
> 2. How do we avoid more of this tomorrow?
>
> The workarounds only answer the first question. For the second, TLS 1.= 3 has
> a section which spells out a few protocol invariants
> <https://tlswg.github.io/tls13-spec/draft-i= etf-tls-tls13.html#rfc.section.9..3>.
> It is all corollaries of existing TLS specification text, but ho= pefully
> documenting it explicitly will help. But experience has shown specific= ation
> text is only necessary, not sufficient.
>
> For extensibility problems in servers, we have GREASE
> <https://tools.ietf.org/html/draft-ietf-tls-grease-01>. This enforces the
> key r= ule in ClientHello processing: ignore unrecognized parameters. GREASE
> enforces this by filling the ecosystem with them. TLS 1.3=E2=80=99s mi= ddlebox woes
> were different. The key rule is: if you did not produce a ClientHello,= you
> cannot assume that you can parse the response. Analogously, we should = fill
> the ecosystem with such responses. We have an idea, but it is more inv= olved
> than GREASE, so we are very interested in the TLS community=E2=80=99s = feedback.
>
> In short, we plan to regularly mint new TLS versions (and likely other=
> sensitive parameters such as extensions), roughly every six weeks matc= hing
> Chrome=E2=80=99s release cycle. Chrome, Google servers, and any other = deployment
> that wishes to participate, would support two (or more) versions of TL= S
> 1.3: the standard stable 0x0304, and a rolling alternate version. Ever= y six
> weeks, we would randomly pick a new code point. These versions will > otherwise be identical to TLS 1.3, save maybe minor details to separat= e
> keys and exercise allowed syntax changes. The goal is to pave the way = for
> future versions of TLS by simulating them (=E2=80=9Cdraft negative one= =E2=80=9D).
>
> Of course, this scheme has some risk. It grabs code points everywhere.= Code
> points are plentiful, but we do sometimes have collisions (e.g. 26 and= 40).
> The entire point is to serve and maintain TLS=E2=80=99s extensibility,= so we
> certainly do not wish to hamper it! Thus we have some safeguards in mi= nd:
>
> * We will document every code point we use and what it refers to. (If = the
> volume is fine, we can email them to the list each time.) New allocati= ons
> can always avoid the lost numbers. At a rate of one every 6 weeks, it = will
> take over 7,000 years to exhaust everything.
>
> * We will avoid picking numbers that the IETF is likely to allocate, t= o
> reduce the chance of collision. Rolling versions will not start with 0= x03,
> rolling cipher suites or extensions will not be contiguous with existi= ng
> blocks, etc.
>
> * BoringSSL will not enable this by default. We will only enable it wh= ere
> we can shut it back off. On our servers, we of course regularly deploy=
> changes. Chrome is also regularly updated and, moreover, we will gate = it on
> our server-controlled field trials
> <https://textslashplai= n.com/2017/10/18/chrome-field-trials/> mechanism. We
> hope that, in practice, only the last several code points will b= e in use at
> a time.
>
> * Our clients would only support the most recent set of rolling parame= ters,
> and our servers the last handful. As each value will be short-lived, t= he
> ecosystem is unlikely to rely on them as de facto standards. Conversel= y,
> like other extensions, implementations without them will still interop= erate
> fine. We would never offer a rolling parameter without the correspondi= ng
> stable one.
>
> * If this ultimately does not work, we can stop at any time and only h= ave
> wasted a small portion of code points.
>
> * Finally, if the working group is open to it, these values could be > summarized in regular documents to reserve them, so that they are
> ultimately reflected in the registries. A new document every six weeks= is
> probably impractical, but we can batch them up.
>
> We are interested in the community=E2=80=99s feedback on this proposal= =E2=80=94anyone who
> might participate, better safeguards, or thoughts on the mechanism as = a
> whole. We hope it will help the working group evolve its protocols mor= e
> smoothly in the future.

This looks interesting and I very much agree that we should do *somt= hing* to
try to avoid the pain we've seen with deploying TLS 1.3 for future vers= ions.

We (Cloudflare) would be happy to help with developing and deploying it, an= d
see how the experiment goes (and maybe even help put a draft together if ne= eded,
if that is the form this proposal will take).

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


--0000000000001acbd3056e8ef4ec-- From nobody Wed Jun 13 17:29:00 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726D6130FAC for ; Wed, 13 Jun 2018 17:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=nOkdh1Kz; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=FXFbdk3/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNPDKdFSJsf5 for ; Wed, 13 Jun 2018 17:28:56 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 EC864130F74 for ; Wed, 13 Jun 2018 17:28:55 -0700 (PDT) Received: from pps.filterd (m0148460.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5E0NkSE003547; Wed, 13 Jun 2018 17:28:53 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=Zmy+fr7Css8YXWzqlNgjuTCIJ87r/J1vi3/ZK9MbdBo=; b=nOkdh1KzvYdl5hR0NGS4abalcbQd7mHhjaNJghCxWNGYFnrTgFQnAp2eRtCUH2yJfrV8 nQBzEVInnqG2WxeWG/Z/KVZryopPVcUvpK5eS3hFa3CDoSO1HT2rRgBPPXJYknJGhj1k gDgu3u3TmMlWgntBk0Fr7gF9FcmtA/Qf2WY= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2jkcrer5uf-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Jun 2018 17:28:53 -0700 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 13 Jun 2018 20:28:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Zmy+fr7Css8YXWzqlNgjuTCIJ87r/J1vi3/ZK9MbdBo=; b=FXFbdk3/kgKTsECpNEib4oSAg8HHiaMBOIhoc4cCstOB9HmGhcpFwftr/y3ALmGvJnh51B7zi509rasIs8j21Kf0sZRknpm8oA7cp39svw8z+W6dt83tjucf3jNlD7SyDODQ4SkPFYZgYFwkmvUrXN9gUjXkwzeebSMU9EuV9TQ= Received: from MWHPR15MB1504.namprd15.prod.outlook.com (10.173.235.13) by MWHPR15MB1550.namprd15.prod.outlook.com (10.173.235.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.14; Thu, 14 Jun 2018 00:28:50 +0000 Received: from MWHPR15MB1504.namprd15.prod.outlook.com ([fe80::d0b7:5e1e:5350:41d2]) by MWHPR15MB1504.namprd15.prod.outlook.com ([fe80::d0b7:5e1e:5350:41d2%3]) with mapi id 15.20.0863.016; Thu, 14 Jun 2018 00:28:50 +0000 From: Kyle Nekritz To: David Benjamin , "" Thread-Topic: [TLS] Enforcing Protocol Invariants Thread-Index: AQHUAmp+oLBw1HEpZU66EQxShrOpCaRe31FA Date: Thu, 14 Jun 2018 00:28:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c091:180::1:fb59] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1550; 7:EayQolDXbxD59WMS+0G+OD/fiYJfWgvZ+HMmBN3ZMx8BS8nHnsetB3Nr8SdEIr2cNZ5vTiOw4566kTSYeXsbN4Bz2sOtw6bGrFQT4whu2cZzfB9+26qv18tOjLEGMyMrG3fcubZDvHQ9egz8Kqzrrj8uth8XnhDJm8jxKj6rP4bbXdTmy5fBv9IWCMpm36YAhksCSwrr24ZqY9QYeKzKl4EwG2GtjHWSyzZAl2bk8h/Xi5Q52KMtPnBg/UiqnI39; 20:sfR5GfPhi6/jHH3HhlKA1FA6YQHM3RGNOEFNux3YkBlxALbtR3MmQcP3cTkvf0G5D9BqafeWE9/bcwbB0F1rKLys1Ixvwa8uj4FGD9wt/iN1Z24+qj7D4PpYXD1jR6TMmycsdj3iU+QIkL2BdpFcMoSvObOxP42Kg0TwoI65oI8= x-ms-exchange-antispam-srfa-diagnostics: SOS; X-MS-Office365-Filtering-Correlation-Id: c472e058-978f-4bec-54a0-08d5d18dcd19 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1550; x-ms-traffictypediagnostic: MWHPR15MB1550: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(10436049006162)(788757137089)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(11241501184)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(149027)(150027)(6041310)(20161123560045)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:MWHPR15MB1550; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1550; x-forefront-prvs: 0703B549E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(39380400002)(366004)(39860400002)(53754006)(199004)(189003)(2906002)(575784001)(46003)(86362001)(33656002)(476003)(11346002)(102836004)(486006)(106356001)(59450400001)(186003)(561944003)(6506007)(76176011)(7696005)(105586002)(81156014)(8936002)(81166006)(8676002)(229853002)(7736002)(305945005)(74316002)(14454004)(5660300001)(97736004)(966005)(446003)(6306002)(6436002)(6116002)(5250100002)(68736007)(2900100001)(9686003)(53936002)(53946003)(6246003)(3280700002)(478600001)(3660700001)(25786009)(316002)(55016002)(99286004)(110136005)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1550; H:MWHPR15MB1504.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: afNDHvih0cHHbSuNS7tfaicWsCZ4c4Sq/e08vCVBmCh77MiXQz5kpftLXafwIrF5s4YAvh+sanv4ixlk8abrhHTv/aCTd44Ig6BSd7UsYag/QqBgMGXTXrusRO1WAYmEVVaFwoPdoy1Ek/+d1gDPT/+t0M4KZ28nqbt/JnuOPiluUh6bNxSW47RbmbFoCy9g spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1504162E7DCB6BADB8730D2AAF7D0MWHPR15MB1504namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c472e058-978f-4bec-54a0-08d5d18dcd19 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2018 00:28:50.3145 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1550 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-13_11:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [TLS] Enforcing Protocol Invariants X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2018 00:28:59 -0000 --_000_MWHPR15MB1504162E7DCB6BADB8730D2AAF7D0MWHPR15MB1504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGVyZSBtYXkgYmUgbG93ZXIgb3ZlcmhlYWQgd2F5cyAodGhhdCBkb27igJl0IHJl cXVpcmUgZnJlcXVlbnQgVExTIGxpYnJhcnkgY29kZSBjaGFuZ2VzKSB0byBwcmV2ZW50IG9zc2lm aWNhdGlvbiBvZiB0aGUgU2VydmVySGVsbG8gdXNpbmcgYSBtZWNoYW5pc20gc2ltaWxhciB0byB0 aGUgY2xlYXJ0ZXh0IGNpcGhlciBpbiBxdWljLiBGb3IgZXhhbXBsZSwgYSBjbGllbnQgY291bGQg b2ZmZXIgYW4g4oCcYW50aS1vc3NpZmljYXRpb27igJ0gZXh0ZW5zaW9uIGNvbnRhaW5pbmcgYW4g aWRlbnRpZmllciB0aGF0IGNvcnJlc3BvbmRzIHRvIGEgcGFydGljdWxhciBrZXkuIFRoZSBpZGVu dGlmaWVyLT5rZXkgbWFwcGluZyBjYW4gYmUgZXN0YWJsaXNoZWQgdXNpbmcgYSBjb3VwbGUgb2Yg bWVjaGFuaXNtcywgZGVwZW5kaW5nIG9uIHRoZSBsZXZlbCBvZiBkZWZlbnNlIGRlc2lyZWQgYWdh aW5zdCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBrbm93IGFib3V0IHRoaXMgZXh0ZW5zaW9uOg0KKiBz dGF0aWMgbWFwcGluZyBkZWZpbmVkIGluIFJGQw0KKiBwZXJpb2RpY2FsbHkgdXBkYXRlZCBtYXBw aW5nIHNoYXJlZCBhbW9uZyBpbXBsZW1lbnRhdGlvbnMNCiogbmVnb3RpYXRlZCBvbiBhIHByZXZp b3VzIGNvbm5lY3Rpb24gdG8gdGhlIHNlcnZlciwgc2ltaWxhciB0byBhIFBTSw0KVGhpcyBrZXkg Y2FuIHRoZW4gYmUgdXNlZCB0byDigJxlbmNyeXB04oCdIHRoZSBTZXJ2ZXJIZWxsbyBzdWNoIHRo YXQgaXQgaXMgaW1wb3NzaWJsZSBmb3IgYSBtaWRkbGVib3ggd2l0aG91dCB0aGUga2V5IHRvIHJl YWQgKHRob3VnaCB3b3VsZCBub3QgYWRkIGFjdHVhbCBjb25maWRlbnRpYWxpdHkgYW5kIHdvdWxk IHByb2JhYmx5IGludm9sdmUgYWVhZCBub25jZS1yZXVzZSkuIFRoZXJl4oCZcyBhIGNvdXBsZSBv ZiBvcHRpb25zIHRvIGRvIHRoaXM6DQoqIFNpbXBseSByZXBsYWNlIHRoZSBwbGFpbnRleHQgcmVj b3JkIGxheWVyIGZvciB0aGUgU2VydmVySGVsbG8gd2l0aCBhbiBlbmNyeXB0ZWQgcmVjb3JkIGxh eWVyLCB1c2luZyB0aGlzIGtleSAodGhpcyB3b3VsZCBub3QgYmUgY29tcGF0aWJsZSB3aXRoIGV4 aXN0aW5nIG1pZGRsZWJveGVzIHRoYXQgaGF2ZSBjYXVzZWQgdXMgdHJvdWJsZSkNCiogUHV0IGEg 4oCccmVhbOKAnSBlbmNyeXB0ZWQgU2VydmVySGVsbG8gaW4gYW4gZXh0ZW5zaW9uIGluIHRoZSDi gJxvdXRlcuKAnSBwbGFpbnRleHQgU2VydmVySGVsbG8NCiogU2VuZCBhIGZha2UgU2VydmVySGVs bG8gKHNpbWlsYXIgdG8gaG93IHdlIGVuY2Fwc3VsYXRlIEhlbGxvUmV0cnlSZXF1ZXN0IGluIGEg U2VydmVySGVsbG8pLCBhbmQgdGhlbiBzZW5kIGEgcmVhbCBTZXJ2ZXJIZWxsbyBpbiBhIGZvbGxv d2luZyBlbmNyeXB0ZWQgcmVjb3JkDQpBbGwgb2YgdGhlc2Ugd291bGQgYWxsb3cgYSBzZXJ2ZXIg dG8gZWl0aGVyIHVzZSB0aGlzIG1lY2hhbmlzbSBvciBuZWdvdGlhdGUgc3RhbmRhcmQgVExTIDEu MyAoYW5kIHRoZSBjbGllbnQgdG8gZWFzaWx5IHRlbGwgd2hpY2ggb25lIGlzIGluIHVzZSkuDQoN CldpdGggdGhlIHNtYWxsIGV4Y2VwdGlvbiBvZiBwb3RlbnRpYWxseSB1cGRhdGluZyB0aGUgaWRl bnRpZmllci0+a2V5IG1hcHBpbmcsIHRoaXMgd291bGQgbm90IHJlcXVpcmUgYW55IFRMUyBsaWJy YXJ5IGNoYW5nZXMgKG9uY2UgaW1wbGVtZW50ZWQgaW4gdGhlIGZpcnN0IHBsYWNlKSwgYW5kIEkg YmVsaWV2ZSB3b3VsZCBzdGlsbCBwcm92aWRlIGFsbW9zdCBhbGwgb2YgdGhlIGJlbmVmaXRzLg0K DQpGcm9tOiBUTFMgPHRscy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgRGF2aWQgQmVu amFtaW4NClNlbnQ6IFR1ZXNkYXksIEp1bmUgMTIsIDIwMTggMTI6MjggUE0NClRvOiA8dGxzQGll dGYub3JnPiA8dGxzQGlldGYub3JnPg0KU3ViamVjdDogW1RMU10gRW5mb3JjaW5nIFByb3RvY29s IEludmFyaWFudHMNCg0KSGkgYWxsLA0KDQpOb3cgdGhhdCBUTFMgMS4zIGlzIGFib3V0IGRvbmUs IHBlcmhhcHMgaXQgaXMgdGltZSB0byByZWZsZWN0IG9uIHRoZSBvc3NpZmljYXRpb24gcHJvYmxl bXMuDQoNClRMUyBpcyBhbiBleHRlbnNpYmxlIHByb3RvY29sLiBUTFMgMS4zIGlzIGJhY2t3YXJk cy1jb21wYXRpYmxlIGFuZCBtYXkgYmUgaW5jcmVtZW50YWxseSByb2xsZWQgb3V0IGluIGFuIGV4 aXN0aW5nIGNvbXBsaWFudCBUTFMgMS4yIGRlcGxveW1lbnQuIFlldCB3ZSBoYWQgcHJvYmxlbXMu IFdpZGVzcHJlYWQgbm9uLWNvbXBsaWFudCBzZXJ2ZXJzIGJyb2tlIG9uIHRoZSBUTFMgMS4zIENs aWVudEhlbGxvLCBzbyB2ZXJzaW9uaW5nIG1vdmVkIHRvIHN1cHBvcnRlZF92ZXJzaW9ucy4gV2lk ZXNwcmVhZCBub24tY29tcGxpYW50IG1pZGRsZWJveGVzIGF0dGVtcHRlZCB0byBwYXJzZSBzb21l b25lIGVsc2XigJlzIFNlcnZlckhlbGxvcywgc28gdGhlIHByb3RvY29sIHdhcyBmdXJ0aGVyIGhh Y2tlZCB0byB3ZWF2ZSB0aHJvdWdoIHRoZWlyIG1hbnkgZGVmZWN0cy4NCg0KSSB0aGluayBJIGNh biBzcGVhayBmb3IgdGhlIHdvcmtpbmcgZ3JvdXAgdGhhdCB3ZSBkbyBub3Qgd2FudCB0byByZXBl YXQgdGhpcyBhZHZlbnR1cmUgYWdhaW4uIEluIGdlbmVyYWwsIEkgdGhpbmsgdGhlIHJlc3BvbnNl IHRvIG9zc2lmaWNhdGlvbiBpcyB0d28tZm9sZDoNCg0KMS4gSXTigJlzIGFscmVhZHkgaGFwcGVu ZWQsIHNvIGhvdyBkbyB3ZSBwcm9ncmVzcyB0b2RheT8NCjIuIEhvdyBkbyB3ZSBhdm9pZCBtb3Jl IG9mIHRoaXMgdG9tb3Jyb3c/DQoNClRoZSB3b3JrYXJvdW5kcyBvbmx5IGFuc3dlciB0aGUgZmly c3QgcXVlc3Rpb24uIEZvciB0aGUgc2Vjb25kLCBUTFMgMS4zIGhhcyBhIHNlY3Rpb24gd2hpY2gg c3BlbGxzIG91dCBhIGZldyBwcm90b2NvbCBpbnZhcmlhbnRzPGh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdGxzd2cuZ2l0aHViLmlvX3RsczEzLTJE c3BlY19kcmFmdC0yRGlldGYtMkR0bHMtMkR0bHMxMy5odG1sLTIzcmZjLnNlY3Rpb24uOS4zJmQ9 RHdNRmFRJmM9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZyPWwyajRCamtPMExjM3U0Q0gyejdqUHcm bT1TYVdwbGt4a2J2OU9fWjcxSGRFNkw3MXZ1MmY3b3ZXV2FFUXJQUlJieXdjJnM9RjdJSjlOYWM1 T2ZfR0N2QlZrMF9RaFRwbENKam9ib0JTZW1IbDBwaTFvTSZlPT4uIEl0IGlzIGFsbCBjb3JvbGxh cmllcyBvZiBleGlzdGluZyBUTFMgc3BlY2lmaWNhdGlvbiB0ZXh0LCBidXQgaG9wZWZ1bGx5IGRv Y3VtZW50aW5nIGl0IGV4cGxpY2l0bHkgd2lsbCBoZWxwLiBCdXQgZXhwZXJpZW5jZSBoYXMgc2hv d24gc3BlY2lmaWNhdGlvbiB0ZXh0IGlzIG9ubHkgbmVjZXNzYXJ5LCBub3Qgc3VmZmljaWVudC4N Cg0KRm9yIGV4dGVuc2liaWxpdHkgcHJvYmxlbXMgaW4gc2VydmVycywgd2UgaGF2ZSBHUkVBU0U8 aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29s cy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJEaWV0Zi0yRHRscy0yRGdyZWFzZS0yRDAxJmQ9RHdNRmFR JmM9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZyPWwyajRCamtPMExjM3U0Q0gyejdqUHcmbT1TYVdw bGt4a2J2OU9fWjcxSGRFNkw3MXZ1MmY3b3ZXV2FFUXJQUlJieXdjJnM9dGNBbHUyZkVma0tqTTJs NFdCQ0NSb3NPR1YzRE1BUWNIdmg4UGUzOEs1dyZlPT4uIFRoaXMgZW5mb3JjZXMgdGhlIGtleSBy dWxlIGluIENsaWVudEhlbGxvIHByb2Nlc3Npbmc6IGlnbm9yZSB1bnJlY29nbml6ZWQgcGFyYW1l dGVycy4gR1JFQVNFIGVuZm9yY2VzIHRoaXMgYnkgZmlsbGluZyB0aGUgZWNvc3lzdGVtIHdpdGgg dGhlbS4gVExTIDEuM+KAmXMgbWlkZGxlYm94IHdvZXMgd2VyZSBkaWZmZXJlbnQuIFRoZSBrZXkg cnVsZSBpczogaWYgeW91IGRpZCBub3QgcHJvZHVjZSBhIENsaWVudEhlbGxvLCB5b3UgY2Fubm90 IGFzc3VtZSB0aGF0IHlvdSBjYW4gcGFyc2UgdGhlIHJlc3BvbnNlLiBBbmFsb2dvdXNseSwgd2Ug c2hvdWxkIGZpbGwgdGhlIGVjb3N5c3RlbSB3aXRoIHN1Y2ggcmVzcG9uc2VzLiBXZSBoYXZlIGFu IGlkZWEsIGJ1dCBpdCBpcyBtb3JlIGludm9sdmVkIHRoYW4gR1JFQVNFLCBzbyB3ZSBhcmUgdmVy eSBpbnRlcmVzdGVkIGluIHRoZSBUTFMgY29tbXVuaXR54oCZcyBmZWVkYmFjay4NCg0KSW4gc2hv cnQsIHdlIHBsYW4gdG8gcmVndWxhcmx5IG1pbnQgbmV3IFRMUyB2ZXJzaW9ucyAoYW5kIGxpa2Vs eSBvdGhlciBzZW5zaXRpdmUgcGFyYW1ldGVycyBzdWNoIGFzIGV4dGVuc2lvbnMpLCByb3VnaGx5 IGV2ZXJ5IHNpeCB3ZWVrcyBtYXRjaGluZyBDaHJvbWXigJlzIHJlbGVhc2UgY3ljbGUuIENocm9t ZSwgR29vZ2xlIHNlcnZlcnMsIGFuZCBhbnkgb3RoZXIgZGVwbG95bWVudCB0aGF0IHdpc2hlcyB0 byBwYXJ0aWNpcGF0ZSwgd291bGQgc3VwcG9ydCB0d28gKG9yIG1vcmUpIHZlcnNpb25zIG9mIFRM UyAxLjM6IHRoZSBzdGFuZGFyZCBzdGFibGUgMHgwMzA0LCBhbmQgYSByb2xsaW5nIGFsdGVybmF0 ZSB2ZXJzaW9uLiBFdmVyeSBzaXggd2Vla3MsIHdlIHdvdWxkIHJhbmRvbWx5IHBpY2sgYSBuZXcg Y29kZSBwb2ludC4gVGhlc2UgdmVyc2lvbnMgd2lsbCBvdGhlcndpc2UgYmUgaWRlbnRpY2FsIHRv IFRMUyAxLjMsIHNhdmUgbWF5YmUgbWlub3IgZGV0YWlscyB0byBzZXBhcmF0ZSBrZXlzIGFuZCBl eGVyY2lzZSBhbGxvd2VkIHN5bnRheCBjaGFuZ2VzLiBUaGUgZ29hbCBpcyB0byBwYXZlIHRoZSB3 YXkgZm9yIGZ1dHVyZSB2ZXJzaW9ucyBvZiBUTFMgYnkgc2ltdWxhdGluZyB0aGVtICjigJxkcmFm dCBuZWdhdGl2ZSBvbmXigJ0pLg0KDQpPZiBjb3Vyc2UsIHRoaXMgc2NoZW1lIGhhcyBzb21lIHJp c2suIEl0IGdyYWJzIGNvZGUgcG9pbnRzIGV2ZXJ5d2hlcmUuIENvZGUgcG9pbnRzIGFyZSBwbGVu dGlmdWwsIGJ1dCB3ZSBkbyBzb21ldGltZXMgaGF2ZSBjb2xsaXNpb25zIChlLmcuIDI2IGFuZCA0 MCkuIFRoZSBlbnRpcmUgcG9pbnQgaXMgdG8gc2VydmUgYW5kIG1haW50YWluIFRMU+KAmXMgZXh0 ZW5zaWJpbGl0eSwgc28gd2UgY2VydGFpbmx5IGRvIG5vdCB3aXNoIHRvIGhhbXBlciBpdCEgVGh1 cyB3ZSBoYXZlIHNvbWUgc2FmZWd1YXJkcyBpbiBtaW5kOg0KDQoqIFdlIHdpbGwgZG9jdW1lbnQg ZXZlcnkgY29kZSBwb2ludCB3ZSB1c2UgYW5kIHdoYXQgaXQgcmVmZXJzIHRvLiAoSWYgdGhlIHZv bHVtZSBpcyBmaW5lLCB3ZSBjYW4gZW1haWwgdGhlbSB0byB0aGUgbGlzdCBlYWNoIHRpbWUuKSBO ZXcgYWxsb2NhdGlvbnMgY2FuIGFsd2F5cyBhdm9pZCB0aGUgbG9zdCBudW1iZXJzLiBBdCBhIHJh dGUgb2Ygb25lIGV2ZXJ5IDYgd2Vla3MsIGl0IHdpbGwgdGFrZSBvdmVyIDcsMDAwIHllYXJzIHRv IGV4aGF1c3QgZXZlcnl0aGluZy4NCg0KKiBXZSB3aWxsIGF2b2lkIHBpY2tpbmcgbnVtYmVycyB0 aGF0IHRoZSBJRVRGIGlzIGxpa2VseSB0byBhbGxvY2F0ZSwgdG8gcmVkdWNlIHRoZSBjaGFuY2Ug b2YgY29sbGlzaW9uLiBSb2xsaW5nIHZlcnNpb25zIHdpbGwgbm90IHN0YXJ0IHdpdGggMHgwMywg cm9sbGluZyBjaXBoZXIgc3VpdGVzIG9yIGV4dGVuc2lvbnMgd2lsbCBub3QgYmUgY29udGlndW91 cyB3aXRoIGV4aXN0aW5nIGJsb2NrcywgZXRjLg0KDQoqIEJvcmluZ1NTTCB3aWxsIG5vdCBlbmFi bGUgdGhpcyBieSBkZWZhdWx0LiBXZSB3aWxsIG9ubHkgZW5hYmxlIGl0IHdoZXJlIHdlIGNhbiBz aHV0IGl0IGJhY2sgb2ZmLiBPbiBvdXIgc2VydmVycywgd2Ugb2YgY291cnNlIHJlZ3VsYXJseSBk ZXBsb3kgY2hhbmdlcy4gQ2hyb21lIGlzIGFsc28gcmVndWxhcmx5IHVwZGF0ZWQgYW5kLCBtb3Jl b3Zlciwgd2Ugd2lsbCBnYXRlIGl0IG9uIG91ciBzZXJ2ZXItY29udHJvbGxlZCBmaWVsZCB0cmlh bHM8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190 ZXh0c2xhc2hwbGFpbi5jb21fMjAxN18xMF8xOF9jaHJvbWUtMkRmaWVsZC0yRHRyaWFsc18mZD1E d01GYVEmYz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9bDJqNEJqa08wTGMzdTRDSDJ6N2pQdyZt PVNhV3Bsa3hrYnY5T19aNzFIZEU2TDcxdnUyZjdvdldXYUVRclBSUmJ5d2Mmcz1vd0NKYlhzMUJ6 blRMZHNob1paQTFob19nOXdfbTI3UGxmV3V0M2RNUnBNJmU9PiBtZWNoYW5pc20uIFdlIGhvcGUg dGhhdCwgaW4gcHJhY3RpY2UsIG9ubHkgdGhlIGxhc3Qgc2V2ZXJhbCBjb2RlIHBvaW50cyB3aWxs IGJlIGluIHVzZSBhdCBhIHRpbWUuDQoNCiogT3VyIGNsaWVudHMgd291bGQgb25seSBzdXBwb3J0 IHRoZSBtb3N0IHJlY2VudCBzZXQgb2Ygcm9sbGluZyBwYXJhbWV0ZXJzLCBhbmQgb3VyIHNlcnZl cnMgdGhlIGxhc3QgaGFuZGZ1bC4gQXMgZWFjaCB2YWx1ZSB3aWxsIGJlIHNob3J0LWxpdmVkLCB0 aGUgZWNvc3lzdGVtIGlzIHVubGlrZWx5IHRvIHJlbHkgb24gdGhlbSBhcyBkZSBmYWN0byBzdGFu ZGFyZHMuIENvbnZlcnNlbHksIGxpa2Ugb3RoZXIgZXh0ZW5zaW9ucywgaW1wbGVtZW50YXRpb25z IHdpdGhvdXQgdGhlbSB3aWxsIHN0aWxsIGludGVyb3BlcmF0ZSBmaW5lLiBXZSB3b3VsZCBuZXZl ciBvZmZlciBhIHJvbGxpbmcgcGFyYW1ldGVyIHdpdGhvdXQgdGhlIGNvcnJlc3BvbmRpbmcgc3Rh YmxlIG9uZS4NCg0KKiBJZiB0aGlzIHVsdGltYXRlbHkgZG9lcyBub3Qgd29yaywgd2UgY2FuIHN0 b3AgYXQgYW55IHRpbWUgYW5kIG9ubHkgaGF2ZSB3YXN0ZWQgYSBzbWFsbCBwb3J0aW9uIG9mIGNv ZGUgcG9pbnRzLg0KDQoqIEZpbmFsbHksIGlmIHRoZSB3b3JraW5nIGdyb3VwIGlzIG9wZW4gdG8g aXQsIHRoZXNlIHZhbHVlcyBjb3VsZCBiZSBzdW1tYXJpemVkIGluIHJlZ3VsYXIgZG9jdW1lbnRz IHRvIHJlc2VydmUgdGhlbSwgc28gdGhhdCB0aGV5IGFyZSB1bHRpbWF0ZWx5IHJlZmxlY3RlZCBp biB0aGUgcmVnaXN0cmllcy4gQSBuZXcgZG9jdW1lbnQgZXZlcnkgc2l4IHdlZWtzIGlzIHByb2Jh Ymx5IGltcHJhY3RpY2FsLCBidXQgd2UgY2FuIGJhdGNoIHRoZW0gdXAuDQoNCldlIGFyZSBpbnRl cmVzdGVkIGluIHRoZSBjb21tdW5pdHnigJlzIGZlZWRiYWNrIG9uIHRoaXMgcHJvcG9zYWzigJRh bnlvbmUgd2hvIG1pZ2h0IHBhcnRpY2lwYXRlLCBiZXR0ZXIgc2FmZWd1YXJkcywgb3IgdGhvdWdo dHMgb24gdGhlIG1lY2hhbmlzbSBhcyBhIHdob2xlLiBXZSBob3BlIGl0IHdpbGwgaGVscCB0aGUg d29ya2luZyBncm91cCBldm9sdmUgaXRzIHByb3RvY29scyBtb3JlIHNtb290aGx5IGluIHRoZSBm dXR1cmUuDQoNCkRhdmlkDQoNCg== --_000_MWHPR15MB1504162E7DCB6BADB8730D2AAF7D0MWHPR15MB1504namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+SSB0aGluayB0aGVyZSBtYXkgYmUgbG93ZXIgb3Zl cmhlYWQgd2F5cyAodGhhdCBkb27igJl0IHJlcXVpcmUgZnJlcXVlbnQgVExTIGxpYnJhcnkgY29k ZSBjaGFuZ2VzKSB0byBwcmV2ZW50IG9zc2lmaWNhdGlvbiBvZiB0aGUgU2VydmVySGVsbG8gdXNp bmcgYSBtZWNoYW5pc20gc2ltaWxhciB0byB0aGUgY2xlYXJ0ZXh0IGNpcGhlciBpbiBxdWljLiBG b3IgZXhhbXBsZSwgYSBjbGllbnQgY291bGQgb2ZmZXIgYW4g4oCcYW50aS1vc3NpZmljYXRpb27i gJ0NCmV4dGVuc2lvbiBjb250YWluaW5nIGFuIGlkZW50aWZpZXIgdGhhdCBjb3JyZXNwb25kcyB0 byBhIHBhcnRpY3VsYXIga2V5LiBUaGUgaWRlbnRpZmllci0mZ3Q7a2V5IG1hcHBpbmcgY2FuIGJl IGVzdGFibGlzaGVkIHVzaW5nIGEgY291cGxlIG9mIG1lY2hhbmlzbXMsIGRlcGVuZGluZyBvbiB0 aGUgbGV2ZWwgb2YgZGVmZW5zZSBkZXNpcmVkIGFnYWluc3QgaW1wbGVtZW50YXRpb25zIHRoYXQg a25vdyBhYm91dCB0aGlzIGV4dGVuc2lvbjo8YnI+DQoNCiogc3RhdGljIG1hcHBpbmcgZGVmaW5l ZCBpbiBSRkM8YnI+DQoNCiogcGVyaW9kaWNhbGx5IHVwZGF0ZWQgbWFwcGluZyBzaGFyZWQgYW1v bmcgaW1wbGVtZW50YXRpb25zPGJyPg0KDQoqIG5lZ290aWF0ZWQgb24gYSBwcmV2aW91cyBjb25u ZWN0aW9uIHRvIHRoZSBzZXJ2ZXIsIHNpbWlsYXIgdG8gYSBQU0s8YnI+DQoNClRoaXMga2V5IGNh biB0aGVuIGJlIHVzZWQgdG8g4oCcZW5jcnlwdOKAnSB0aGUgU2VydmVySGVsbG8gc3VjaCB0aGF0 IGl0IGlzIGltcG9zc2libGUgZm9yIGEgbWlkZGxlYm94IHdpdGhvdXQgdGhlIGtleSB0byByZWFk ICh0aG91Z2ggd291bGQgbm90IGFkZCBhY3R1YWwgY29uZmlkZW50aWFsaXR5IGFuZCB3b3VsZCBw cm9iYWJseSBpbnZvbHZlIGFlYWQgbm9uY2UtcmV1c2UpLiBUaGVyZeKAmXMgYSBjb3VwbGUgb2Yg b3B0aW9ucyB0byA8YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjwvYT5kbw0KdGhpczo8L2Rpdj4N CjxkaXY+KiBTaW1wbHkgcmVwbGFjZSB0aGUgcGxhaW50ZXh0IHJlY29yZCBsYXllciBmb3IgdGhl IFNlcnZlckhlbGxvIHdpdGggYW4gZW5jcnlwdGVkIHJlY29yZCBsYXllciwgdXNpbmcgdGhpcyBr ZXkgKHRoaXMgd291bGQgbm90IGJlIGNvbXBhdGlibGUgd2l0aCBleGlzdGluZyBtaWRkbGVib3hl cyB0aGF0IGhhdmUgY2F1c2VkIHVzIHRyb3VibGUpPGJyPg0KDQoqIFB1dCBhIOKAnHJlYWzigJ0g ZW5jcnlwdGVkIFNlcnZlckhlbGxvIGluIGFuIGV4dGVuc2lvbiBpbiB0aGUg4oCcb3V0ZXLigJ0g cGxhaW50ZXh0IFNlcnZlckhlbGxvPC9kaXY+DQo8ZGl2PiogU2VuZCBhIGZha2UgU2VydmVySGVs bG8gKHNpbWlsYXIgdG8gaG93IHdlIGVuY2Fwc3VsYXRlIEhlbGxvUmV0cnlSZXF1ZXN0IGluIGEg U2VydmVySGVsbG8pLCBhbmQgdGhlbiBzZW5kIGEgcmVhbCBTZXJ2ZXJIZWxsbyBpbiBhIGZvbGxv d2luZyBlbmNyeXB0ZWQgcmVjb3JkPC9kaXY+DQo8ZGl2PkFsbCBvZiB0aGVzZSB3b3VsZCBhbGxv dyBhIHNlcnZlciB0byBlaXRoZXIgdXNlIHRoaXMgbWVjaGFuaXNtIG9yIG5lZ290aWF0ZSBzdGFu ZGFyZCBUTFMgMS4zIChhbmQgdGhlIGNsaWVudCB0byBlYXNpbHkgdGVsbCB3aGljaCBvbmUgaXMg aW4gdXNlKS48YnI+DQoNCjxicj4NCg0KV2l0aCB0aGUgc21hbGwgZXhjZXB0aW9uIG9mIHBvdGVu dGlhbGx5IHVwZGF0aW5nIHRoZSBpZGVudGlmaWVyLSZndDtrZXkgbWFwcGluZywgdGhpcyB3b3Vs ZCBub3QgcmVxdWlyZSBhbnkgVExTIGxpYnJhcnkgY2hhbmdlcyAob25jZSBpbXBsZW1lbnRlZCBp biB0aGUgZmlyc3QgcGxhY2UpLCBhbmQgSSBiZWxpZXZlIHdvdWxkIHN0aWxsIHByb3ZpZGUgYWxt b3N0IGFsbCBvZiB0aGUgYmVuZWZpdHMuPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5l dyBSb21hbiIgc2l6ZT0iMyIgY29sb3I9IiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTJwdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGli cmkiPjxiPkZyb206PC9iPiBUTFMgJmx0O3Rscy1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBC ZWhhbGYgT2YgPC9iPkRhdmlkIEJlbmphbWluPGJyPg0KDQo8Yj5TZW50OjwvYj4gVHVlc2RheSwg SnVuZSAxMiwgMjAxOCAxMjoyOCBQTTxicj4NCg0KPGI+VG86PC9iPiAmbHQ7dGxzQGlldGYub3Jn Jmd0OyAmbHQ7dGxzQGlldGYub3JnJmd0Ozxicj4NCg0KPGI+U3ViamVjdDo8L2I+IFtUTFNdIEVu Zm9yY2luZyBQcm90b2NvbCBJbnZhcmlhbnRzPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdDsi PiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBS b21hbiIgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyI+SGkgYWxsLDwvc3Bh bj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0i MyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L2Rp dj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEycHQ7Ij5Ob3cgdGhhdCBUTFMgMS4zIGlzIGFib3V0IGRvbmUsIHBlcmhh cHMgaXQgaXMgdGltZSB0byByZWZsZWN0IG9uIHRoZSBvc3NpZmljYXRpb24gcHJvYmxlbXMuPC9z cGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXpl PSIzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTJwdDsiPlRMUyBpcyBhbiBleHRlbnNpYmxlIHByb3RvY29sLiBUTFMg MS4zIGlzIGJhY2t3YXJkcy1jb21wYXRpYmxlIGFuZCBtYXkgYmUgaW5jcmVtZW50YWxseSByb2xs ZWQgb3V0IGluIGFuIGV4aXN0aW5nIGNvbXBsaWFudCBUTFMgMS4yIGRlcGxveW1lbnQuIFlldCB3 ZSBoYWQgcHJvYmxlbXMuIFdpZGVzcHJlYWQgbm9uLWNvbXBsaWFudA0Kc2VydmVycyBicm9rZSBv biB0aGUgVExTIDEuMyBDbGllbnRIZWxsbywgc28gdmVyc2lvbmluZyBtb3ZlZCB0byBzdXBwb3J0 ZWRfdmVyc2lvbnMuIFdpZGVzcHJlYWQgbm9uLWNvbXBsaWFudCBtaWRkbGVib3hlcyBhdHRlbXB0 ZWQgdG8gcGFyc2Ugc29tZW9uZSBlbHNl4oCZcyBTZXJ2ZXJIZWxsb3MsIHNvIHRoZSBwcm90b2Nv bCB3YXMgZnVydGhlciBoYWNrZWQgdG8gd2VhdmUgdGhyb3VnaCB0aGVpciBtYW55IGRlZmVjdHMu PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBz aXplPSIzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250 PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTJwdDsiPkkgdGhpbmsgSSBjYW4gc3BlYWsgZm9yIHRoZSB3b3Jr aW5nIGdyb3VwIHRoYXQgd2UgZG8gbm90IHdhbnQgdG8gcmVwZWF0IHRoaXMgYWR2ZW50dXJlIGFn YWluLiBJbiBnZW5lcmFsLCBJIHRoaW5rIHRoZSByZXNwb25zZSB0byBvc3NpZmljYXRpb24gaXMg dHdvLWZvbGQ6PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIiBzaXplPSIzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQ7Ij4mbmJzcDs8L3Nw YW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9 IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdDsiPjEuIEl04oCZcyBhbHJlYWR5IGhhcHBl bmVkLCBzbyBob3cgZG8gd2UgcHJvZ3Jlc3MgdG9kYXk/PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEycHQ7Ij4yLiBIb3cgZG8gd2UgYXZvaWQgbW9yZSBvZiB0aGlzIHRvbW9ycm93Pzwv c3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6 ZT0iMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEycHQ7Ij5UaGUgd29ya2Fyb3VuZHMgb25seSBhbnN3ZXIgdGhlIGZp cnN0IHF1ZXN0aW9uLiBGb3IgdGhlIHNlY29uZCwgVExTIDEuMyBoYXMgYSBzZWN0aW9uIHdoaWNo IHNwZWxscyBvdXQgYSBmZXcgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX190bHN3Zy5naXRodWIuaW9fdGxzMTMtMkRzcGVjX2RyYWZ0 LTJEaWV0Zi0yRHRscy0yRHRsczEzLmh0bWwtMjNyZmMuc2VjdGlvbi45LjMmYW1wO2Q9RHdNRmFR JmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9bDJqNEJqa08wTGMzdTRDSDJ6N2pQ dyZhbXA7bT1TYVdwbGt4a2J2OU9fWjcxSGRFNkw3MXZ1MmY3b3ZXV2FFUXJQUlJieXdjJmFtcDtz PUY3SUo5TmFjNU9mX0dDdkJWazBfUWhUcGxDSmpvYm9CU2VtSGwwcGkxb00mYW1wO2U9Ij48Zm9u dCBjb2xvcj0iYmx1ZSI+PHU+cHJvdG9jb2wNCmludmFyaWFudHM8L3U+PC9mb250PjwvYT4uIEl0 IGlzIGFsbCBjb3JvbGxhcmllcyBvZiBleGlzdGluZyBUTFMgc3BlY2lmaWNhdGlvbiB0ZXh0LCBi dXQgaG9wZWZ1bGx5IGRvY3VtZW50aW5nIGl0IGV4cGxpY2l0bHkgd2lsbCBoZWxwLiBCdXQgZXhw ZXJpZW5jZSBoYXMgc2hvd24gc3BlY2lmaWNhdGlvbiB0ZXh0IGlzIG9ubHkgbmVjZXNzYXJ5LCBu b3Qgc3VmZmljaWVudC48L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iIHNpemU9IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdDsiPiZuYnNw Ozwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIg c2l6ZT0iMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyI+Rm9yIGV4dGVuc2liaWxpdHkg cHJvYmxlbXMgaW4gc2VydmVycywgd2UgaGF2ZSA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJh ZnQtMkRpZXRmLTJEdGxzLTJEZ3JlYXNlLTJEMDEmYW1wO2Q9RHdNRmFRJmFtcDtjPTVWRDBSVHRO bFRoM3ljZDQxYjNNVXcmYW1wO3I9bDJqNEJqa08wTGMzdTRDSDJ6N2pQdyZhbXA7bT1TYVdwbGt4 a2J2OU9fWjcxSGRFNkw3MXZ1MmY3b3ZXV2FFUXJQUlJieXdjJmFtcDtzPXRjQWx1MmZFZmtLak0y bDRXQkNDUm9zT0dWM0RNQVFjSHZoOFBlMzhLNXcmYW1wO2U9Ij48Zm9udCBjb2xvcj0iYmx1ZSI+ PHU+R1JFQVNFPC91PjwvZm9udD48L2E+Lg0KVGhpcyBlbmZvcmNlcyB0aGUga2V5IHJ1bGUgaW4g Q2xpZW50SGVsbG8gcHJvY2Vzc2luZzogaWdub3JlIHVucmVjb2duaXplZCBwYXJhbWV0ZXJzLiBH UkVBU0UgZW5mb3JjZXMgdGhpcyBieSBmaWxsaW5nIHRoZSBlY29zeXN0ZW0gd2l0aCB0aGVtLiBU TFMgMS4z4oCZcyBtaWRkbGVib3ggd29lcyB3ZXJlIGRpZmZlcmVudC4gVGhlIGtleSBydWxlIGlz OiBpZiB5b3UgZGlkIG5vdCBwcm9kdWNlIGEgQ2xpZW50SGVsbG8sIHlvdSBjYW5ub3QgYXNzdW1l DQp0aGF0IHlvdSBjYW4gcGFyc2UgdGhlIHJlc3BvbnNlLiBBbmFsb2dvdXNseSwgd2Ugc2hvdWxk IGZpbGwgdGhlIGVjb3N5c3RlbSB3aXRoIHN1Y2ggcmVzcG9uc2VzLiBXZSBoYXZlIGFuIGlkZWEs IGJ1dCBpdCBpcyBtb3JlIGludm9sdmVkIHRoYW4gR1JFQVNFLCBzbyB3ZSBhcmUgdmVyeSBpbnRl cmVzdGVkIGluIHRoZSBUTFMgY29tbXVuaXR54oCZcyBmZWVkYmFjay48L3NwYW4+PC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTJwdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxm b250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMnB0OyI+SW4gc2hvcnQsIHdlIHBsYW4gdG8gcmVndWxhcmx5IG1pbnQgbmV3IFRMUyB2ZXJz aW9ucyAoYW5kIGxpa2VseSBvdGhlciBzZW5zaXRpdmUgcGFyYW1ldGVycyBzdWNoIGFzIGV4dGVu c2lvbnMpLCByb3VnaGx5IGV2ZXJ5IHNpeCB3ZWVrcyBtYXRjaGluZyBDaHJvbWXigJlzIHJlbGVh c2UgY3ljbGUuIENocm9tZSwgR29vZ2xlDQpzZXJ2ZXJzLCBhbmQgYW55IG90aGVyIGRlcGxveW1l bnQgdGhhdCB3aXNoZXMgdG8gcGFydGljaXBhdGUsIHdvdWxkIHN1cHBvcnQgdHdvIChvciBtb3Jl KSB2ZXJzaW9ucyBvZiBUTFMgMS4zOiB0aGUgc3RhbmRhcmQgc3RhYmxlIDB4MDMwNCwgYW5kIGEg cm9sbGluZyBhbHRlcm5hdGUgdmVyc2lvbi4gRXZlcnkgc2l4IHdlZWtzLCB3ZSB3b3VsZCByYW5k b21seSBwaWNrIGEgbmV3IGNvZGUgcG9pbnQuIFRoZXNlIHZlcnNpb25zIHdpbGwgb3RoZXJ3aXNl DQpiZSBpZGVudGljYWwgdG8gVExTIDEuMywgc2F2ZSBtYXliZSBtaW5vciBkZXRhaWxzIHRvIHNl cGFyYXRlIGtleXMgYW5kIGV4ZXJjaXNlIGFsbG93ZWQgc3ludGF4IGNoYW5nZXMuIFRoZSBnb2Fs IGlzIHRvIHBhdmUgdGhlIHdheSBmb3IgZnV0dXJlIHZlcnNpb25zIG9mIFRMUyBieSBzaW11bGF0 aW5nIHRoZW0gKOKAnGRyYWZ0IG5lZ2F0aXZlIG9uZeKAnSkuPC9zcGFuPjwvZm9udD48L2Rpdj4N CjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEycHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJw dDsiPk9mIGNvdXJzZSwgdGhpcyBzY2hlbWUgaGFzIHNvbWUgcmlzay4gSXQgZ3JhYnMgY29kZSBw b2ludHMgZXZlcnl3aGVyZS4gQ29kZSBwb2ludHMgYXJlIHBsZW50aWZ1bCwgYnV0IHdlIGRvIHNv bWV0aW1lcyBoYXZlIGNvbGxpc2lvbnMgKGUuZy4gMjYgYW5kIDQwKS4gVGhlIGVudGlyZSBwb2lu dCBpcyB0byBzZXJ2ZSBhbmQNCm1haW50YWluIFRMU+KAmXMgZXh0ZW5zaWJpbGl0eSwgc28gd2Ug Y2VydGFpbmx5IGRvIG5vdCB3aXNoIHRvIGhhbXBlciBpdCEgVGh1cyB3ZSBoYXZlIHNvbWUgc2Fm ZWd1YXJkcyBpbiBtaW5kOjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRp bWVzIE5ldyBSb21hbiIgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyI+Jm5i c3A7PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFu IiBzaXplPSIzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQ7Ij4qIFdlIHdpbGwgZG9jdW1l bnQgZXZlcnkgY29kZSBwb2ludCB3ZSB1c2UgYW5kIHdoYXQgaXQgcmVmZXJzIHRvLiAoSWYgdGhl IHZvbHVtZSBpcyBmaW5lLCB3ZSBjYW4gZW1haWwgdGhlbSB0byB0aGUgbGlzdCBlYWNoIHRpbWUu KSBOZXcgYWxsb2NhdGlvbnMgY2FuIGFsd2F5cyBhdm9pZCB0aGUgbG9zdCBudW1iZXJzLiBBdA0K YSByYXRlIG9mIG9uZSBldmVyeSA2IHdlZWtzLCBpdCB3aWxsIHRha2Ugb3ZlciA3LDAwMCB5ZWFy cyB0byBleGhhdXN0IGV2ZXJ5dGhpbmcuPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy cHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iIHNpemU9IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdDsiPiogV2Ugd2ls bCBhdm9pZCBwaWNraW5nIG51bWJlcnMgdGhhdCB0aGUgSUVURiBpcyBsaWtlbHkgdG8gYWxsb2Nh dGUsIHRvIHJlZHVjZSB0aGUgY2hhbmNlIG9mIGNvbGxpc2lvbi4gUm9sbGluZyB2ZXJzaW9ucyB3 aWxsIG5vdCBzdGFydCB3aXRoIDB4MDMsIHJvbGxpbmcgY2lwaGVyIHN1aXRlcyBvciBleHRlbnNp b25zIHdpbGwNCm5vdCBiZSBjb250aWd1b3VzIHdpdGggZXhpc3RpbmcgYmxvY2tzLCBldGMuPC9z cGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXpl PSIzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTJwdDsiPiogQm9yaW5nU1NMIHdpbGwgbm90IGVuYWJsZSB0aGlzIGJ5 IGRlZmF1bHQuIFdlIHdpbGwgb25seSBlbmFibGUgaXQgd2hlcmUgd2UgY2FuIHNodXQgaXQgYmFj ayBvZmYuIE9uIG91ciBzZXJ2ZXJzLCB3ZSBvZiBjb3Vyc2UgcmVndWxhcmx5IGRlcGxveSBjaGFu Z2VzLiBDaHJvbWUgaXMgYWxzbyByZWd1bGFybHkgdXBkYXRlZA0KYW5kLCBtb3Jlb3Zlciwgd2Ug d2lsbCBnYXRlIGl0IG9uIG91ciBzZXJ2ZXItY29udHJvbGxlZCA8YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3RleHRzbGFzaHBsYWlu LmNvbV8yMDE3XzEwXzE4X2Nocm9tZS0yRGZpZWxkLTJEdHJpYWxzXyZhbXA7ZD1Ed01GYVEmYW1w O2M9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZhbXA7cj1sMmo0QmprTzBMYzN1NENIMno3alB3JmFt cDttPVNhV3Bsa3hrYnY5T19aNzFIZEU2TDcxdnUyZjdvdldXYUVRclBSUmJ5d2MmYW1wO3M9b3dD SmJYczFCem5UTGRzaG9aWkExaG9fZzl3X20yN1BsZld1dDNkTVJwTSZhbXA7ZT0iPjxmb250IGNv bG9yPSJibHVlIj48dT5maWVsZA0KdHJpYWxzPC91PjwvZm9udD48L2E+IG1lY2hhbmlzbS4gV2Ug aG9wZSB0aGF0LCBpbiBwcmFjdGljZSwgb25seSB0aGUgbGFzdCBzZXZlcmFsIGNvZGUgcG9pbnRz IHdpbGwgYmUgaW4gdXNlIGF0IGEgdGltZS48L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9u dCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTJwdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVz IE5ldyBSb21hbiIgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyI+KiZuYnNw O091ciBjbGllbnRzIHdvdWxkIG9ubHkgc3VwcG9ydCB0aGUgbW9zdCByZWNlbnQgc2V0IG9mIHJv bGxpbmcgcGFyYW1ldGVycywgYW5kIG91ciBzZXJ2ZXJzIHRoZSBsYXN0IGhhbmRmdWwuIEFzIGVh Y2ggdmFsdWUgd2lsbCBiZSBzaG9ydC1saXZlZCwgdGhlIGVjb3N5c3RlbSBpcyB1bmxpa2VseSB0 byByZWx5IG9uIHRoZW0NCmFzIGRlIGZhY3RvIHN0YW5kYXJkcy4gQ29udmVyc2VseSwgbGlrZSBv dGhlciBleHRlbnNpb25zLCBpbXBsZW1lbnRhdGlvbnMgd2l0aG91dCB0aGVtIHdpbGwgc3RpbGwg aW50ZXJvcGVyYXRlIGZpbmUuIFdlIHdvdWxkIG5ldmVyIG9mZmVyIGEgcm9sbGluZyBwYXJhbWV0 ZXIgd2l0aG91dCB0aGUgY29ycmVzcG9uZGluZyBzdGFibGUgb25lLjwvc3Bhbj48L2ZvbnQ+PC9k aXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMnB0OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZv bnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEycHQ7Ij4qJm5ic3A7SWYgdGhpcyB1bHRpbWF0ZWx5IGRvZXMgbm90IHdvcmssIHdlIGNhbiBz dG9wIGF0IGFueSB0aW1lIGFuZCBvbmx5IGhhdmUgd2FzdGVkIGEgc21hbGwgcG9ydGlvbiBvZiBj b2RlIHBvaW50cy48L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iIHNpemU9IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdDsiPiZuYnNwOzwv c3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6 ZT0iMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyI+KiBGaW5hbGx5LCBpZiB0aGUgd29y a2luZyBncm91cCBpcyBvcGVuIHRvIGl0LCB0aGVzZSB2YWx1ZXMgY291bGQgYmUgc3VtbWFyaXpl ZCBpbiByZWd1bGFyIGRvY3VtZW50cyB0byByZXNlcnZlIHRoZW0sIHNvIHRoYXQgdGhleSBhcmUg dWx0aW1hdGVseSByZWZsZWN0ZWQgaW4gdGhlIHJlZ2lzdHJpZXMuIEEgbmV3IGRvY3VtZW50DQpl dmVyeSBzaXggd2Vla3MgaXMgcHJvYmFibHkgaW1wcmFjdGljYWwsIGJ1dCB3ZSBjYW4gYmF0Y2gg dGhlbSB1cC48L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iIHNpemU9IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdDsiPiZuYnNwOzwvc3Bh bj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0i MyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyI+V2UgYXJlIGludGVyZXN0ZWQgaW4gdGhl IGNvbW11bml0eeKAmXMgZmVlZGJhY2sgb24gdGhpcyBwcm9wb3NhbOKAlGFueW9uZSB3aG8gbWln aHQgcGFydGljaXBhdGUsIGJldHRlciBzYWZlZ3VhcmRzLCBvciB0aG91Z2h0cyBvbiB0aGUgbWVj aGFuaXNtIGFzIGEgd2hvbGUuIFdlIGhvcGUgaXQgd2lsbCBoZWxwIHRoZSB3b3JraW5nDQpncm91 cCBldm9sdmUgaXRzIHByb3RvY29scyBtb3JlIHNtb290aGx5IGluIHRoZSBmdXR1cmUuPC9zcGFu PjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIz Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvZGl2 Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTJwdDsiPkRhdmlkPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy cHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPC9zcGFuPjwvZm9udD4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_MWHPR15MB1504162E7DCB6BADB8730D2AAF7D0MWHPR15MB1504namp_-- From nobody Thu Jun 14 07:35:43 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90CB9130DC0 for ; Thu, 14 Jun 2018 07:35:42 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91enExBMrb35 for ; Thu, 14 Jun 2018 07:35:38 -0700 (PDT) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (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 AE33A12777C for ; Thu, 14 Jun 2018 07:35:38 -0700 (PDT) Received: by mail-io0-x241.google.com with SMTP id d185-v6so7367822ioe.0 for ; Thu, 14 Jun 2018 07:35:38 -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 :cc; bh=ElBKfLKNtrQlRdVIG5YDJmE9tHs6iAo/DIWKOaSiVUA=; b=nLgixoiW6KED8wwNhwCK7oEyXhaORN/x1dtYBdRzZB3rGNmwJXnEOGh4teM0UD86gj dLRk63EyCMlLUKghsiOBXvVI07a6Us6atRe3yi7n7QT3GumnKddYP7lGyfMemB/qbe8t /JFK0wVVl5UaSQo0D/TGw2lFaBVwvRSZ5++HQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ElBKfLKNtrQlRdVIG5YDJmE9tHs6iAo/DIWKOaSiVUA=; b=nZoBANs+QEQ6bi3vzNW4Lvz4hXuB+tRYs5Cr9caI+n1x7DnFqGcR0aF7igclGTh9M8 kaYPCHiRxuVPs7uZdsoYf+wg4/odgoCIWpgdg3iooCPTz9sdmHjH0bUinlkQ83QxVHyL ygdt6qSKhCvrCTbH5QsLhfX7FnINDwbuJU2c6BgGf/m0TqIBoq0H6xN88UtZxmndYfTh 3dOy3Jyn+XcMXtB5KjFRFafFCmSGo0E86PuUUsepxl2834VGLyDe//ypsdG0jvqoNX8G sAv75FDyM5BJhlUIRT9mfuBxk3dNIKTAkca/iYbUKEDzR+wjI8CUmOc6pQwerTCStx1w 4/kg== X-Gm-Message-State: APt69E180J9VLQE3HnHZmet7sIJp0c3kZbFMaQJbAbeVEOSXwCHnkKoh Vjjx7BUn4dGv1vwkeBWMSvYvzP2UHQ4= X-Google-Smtp-Source: ADUXVKJ19C5UwLYGrXukyuN2IXUvri4XnKo015pXEl6YSqR7NTxAOXslyr1rpBnBLv1EDMbm8Cr9Iw== X-Received: by 2002:a6b:a282:: with SMTP id l124-v6mr2550901ioe.256.1528986937876; Thu, 14 Jun 2018 07:35:37 -0700 (PDT) Received: from mail-it0-f51.google.com (mail-it0-f51.google.com. [209.85.214.51]) by smtp.gmail.com with ESMTPSA id 16-v6sm2894449itk.17.2018.06.14.07.35.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Jun 2018 07:35:36 -0700 (PDT) Received: by mail-it0-f51.google.com with SMTP id p185-v6so9001339itp.4 for ; Thu, 14 Jun 2018 07:35:36 -0700 (PDT) X-Received: by 2002:a02:8aec:: with SMTP id i41-v6mr1437245jal.33.1528986936423; Thu, 14 Jun 2018 07:35:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Steven Valdez Date: Thu, 14 Jun 2018 10:35:24 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Kyle Nekritz Cc: David Benjamin , "" Content-Type: multipart/alternative; boundary="00000000000036b7d0056e9b03b9" Archived-At: Subject: Re: [TLS] Enforcing Protocol Invariants X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2018 14:35:43 -0000 --00000000000036b7d0056e9b03b9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This scheme probably isn't sufficient by itself, since a middlebox just has to be aware of the anti-ossification extension and can parse the server's response by decrypting it with the known mapping (either from the RFC or fetching the latest updated mapping), and then ossifying on the contents of the 'real' ServerHello. To keep the ServerHello from ossifying, you'll need to change the serialization and codepoints of the ServerHello at each rolling version. On Wed, Jun 13, 2018 at 8:29 PM Kyle Nekritz wrote: > I think there may be lower overhead ways (that don=E2=80=99t require freq= uent TLS > library code changes) to prevent ossification of the ServerHello using a > mechanism similar to the cleartext cipher in quic. For example, a client > could offer an =E2=80=9Canti-ossification=E2=80=9D extension containing a= n identifier that > corresponds to a particular key. The identifier->key mapping can be > established using a couple of mechanisms, depending on the level of defen= se > desired against implementations that know about this extension: > * static mapping defined in RFC > * periodically updated mapping shared among implementations > * negotiated on a previous connection to the server, similar to a PSK > This key can then be used to =E2=80=9Cencrypt=E2=80=9D the ServerHello su= ch that it is > impossible for a middlebox without the key to read (though would not add > actual confidentiality and would probably involve aead nonce-reuse). > There=E2=80=99s a couple of options to do this: > * Simply replace the plaintext record layer for the ServerHello with an > encrypted record layer, using this key (this would not be compatible with > existing middleboxes that have caused us trouble) > * Put a =E2=80=9Creal=E2=80=9D encrypted ServerHello in an extension in t= he =E2=80=9Couter=E2=80=9D > plaintext ServerHello > * Send a fake ServerHello (similar to how we encapsulate HelloRetryReques= t > in a ServerHello), and then send a real ServerHello in a following > encrypted record > All of these would allow a server to either use this mechanism or > negotiate standard TLS 1.3 (and the client to easily tell which one is in > use). > > With the small exception of potentially updating the identifier->key > mapping, this would not require any TLS library changes (once implemented > in the first place), and I believe would still provide almost all of the > benefits. > > *From:* TLS *On Behalf Of *David Benjamin > *Sent:* Tuesday, June 12, 2018 12:28 PM > *To:* > *Subject:* [TLS] Enforcing Protocol Invariants > > Hi all, > > Now that TLS 1.3 is about done, perhaps it is time to reflect on the > ossification problems. > > TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may be > incrementally rolled out in an existing compliant TLS 1.2 deployment. Yet > we had problems. Widespread non-compliant servers broke on the TLS 1.3 > ClientHello, so versioning moved to supported_versions. Widespread > non-compliant middleboxes attempted to parse someone else=E2=80=99s Serve= rHellos, > so the protocol was further hacked to weave through their many defects. > > I think I can speak for the working group that we do not want to repeat > this adventure again. In general, I think the response to ossification is > two-fold: > > 1. It=E2=80=99s already happened, so how do we progress today? > 2. How do we avoid more of this tomorrow? > > The workarounds only answer the first question. For the second, TLS 1.3 > has a section which spells out a few *protocol invariants* > . > It is all corollaries of existing TLS specification text, but hopefully > documenting it explicitly will help. But experience has shown specificati= on > text is only necessary, not sufficient. > > For extensibility problems in servers, we have *GREASE* > . > This enforces the key rule in ClientHello processing: ignore unrecognized > parameters. GREASE enforces this by filling the ecosystem with them. TLS > 1.3=E2=80=99s middlebox woes were different. The key rule is: if you did = not > produce a ClientHello, you cannot assume that you can parse the response. > Analogously, we should fill the ecosystem with such responses. We have an > idea, but it is more involved than GREASE, so we are very interested in t= he > TLS community=E2=80=99s feedback. > > In short, we plan to regularly mint new TLS versions (and likely other > sensitive parameters such as extensions), roughly every six weeks matchin= g > Chrome=E2=80=99s release cycle. Chrome, Google servers, and any other dep= loyment > that wishes to participate, would support two (or more) versions of TLS > 1.3: the standard stable 0x0304, and a rolling alternate version. Every s= ix > weeks, we would randomly pick a new code point. These versions will > otherwise be identical to TLS 1.3, save maybe minor details to separate > keys and exercise allowed syntax changes. The goal is to pave the way for > future versions of TLS by simulating them (=E2=80=9Cdraft negative one=E2= =80=9D). > > Of course, this scheme has some risk. It grabs code points everywhere. > Code points are plentiful, but we do sometimes have collisions (e.g. 26 a= nd > 40). The entire point is to serve and maintain TLS=E2=80=99s extensibilit= y, so we > certainly do not wish to hamper it! Thus we have some safeguards in mind: > > * We will document every code point we use and what it refers to. (If the > volume is fine, we can email them to the list each time.) New allocations > can always avoid the lost numbers. At a rate of one every 6 weeks, it wil= l > take over 7,000 years to exhaust everything. > > * We will avoid picking numbers that the IETF is likely to allocate, to > reduce the chance of collision. Rolling versions will not start with 0x03= , > rolling cipher suites or extensions will not be contiguous with existing > blocks, etc. > > * BoringSSL will not enable this by default. We will only enable it where > we can shut it back off. On our servers, we of course regularly deploy > changes. Chrome is also regularly updated and, moreover, we will gate it = on > our server-controlled *field trials* > > mechanism. We hope that, in practice, only the last several code points > will be in use at a time. > > * Our clients would only support the most recent set of rolling > parameters, and our servers the last handful. As each value will be > short-lived, the ecosystem is unlikely to rely on them as de facto > standards. Conversely, like other extensions, implementations without the= m > will still interoperate fine. We would never offer a rolling parameter > without the corresponding stable one. > > * If this ultimately does not work, we can stop at any time and only have > wasted a small portion of code points. > > * Finally, if the working group is open to it, these values could be > summarized in regular documents to reserve them, so that they are > ultimately reflected in the registries. A new document every six weeks is > probably impractical, but we can batch them up. > > We are interested in the community=E2=80=99s feedback on this proposal=E2= =80=94anyone who > might participate, better safeguards, or thoughts on the mechanism as a > whole. We hope it will help the working group evolve its protocols more > smoothly in the future. > > David > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --00000000000036b7d0056e9b03b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This scheme probably isn't sufficient by itself, = since a middlebox just has to be aware of the anti-ossification extension a= nd can parse the server's response by decrypting it with the known mapp= ing (either from the RFC or fetching the latest updated mapping), and then = ossifying on the contents of the 'real' ServerHello. To keep the Se= rverHello from ossifying, you'll need to change the serialization and c= odepoints of the ServerHello at each rolling version.

On Wed, Jun 13, 2018 at 8:29 PM Kyle Nekr= itz <knekritz@fb.com> wrote:
I think there may be lower overhead ways (that don=E2=80=99t require f= requent TLS library code changes) to prevent ossification of the ServerHell= o using a mechanism similar to the cleartext cipher in quic. For example, a= client could offer an =E2=80=9Canti-ossification=E2=80=9D extension containing an identifier that corresponds to a particular key. Th= e identifier->key mapping can be established using a couple of mechanism= s, depending on the level of defense desired against implementations that k= now about this extension:
* static mapping defined in RFC
* periodically updated mapping shared among implementations
* negotiated on a previous connection to the server, similar to a PSK
This key can then be used to =E2=80=9Cencrypt=E2=80=9D the ServerHello such= that it is impossible for a middlebox without the key to read (though woul= d not add actual confidentiality and would probably involve aead nonce-reus= e). There=E2=80=99s a couple of options to do this:
* Simply replace the plaintext record layer for the ServerHello with a= n encrypted record layer, using this key (this would not be compatible with= existing middleboxes that have caused us trouble)
* Put a =E2=80=9Creal=E2=80=9D encrypted ServerHello in an extension in the= =E2=80=9Couter=E2=80=9D plaintext ServerHello
* Send a fake ServerHello (similar to how we encapsulate HelloRetryReq= uest in a ServerHello), and then send a real ServerHello in a following enc= rypted record
All of these would allow a server to either use this mechanism or nego= tiate standard TLS 1.3 (and the client to easily tell which one is in use).=

With the small exception of potentially updating the identifier->key map= ping, this would not require any TLS library changes (once implemented in t= he first place), and I believe would still provide almost all of the benefi= ts.
=C2=A0
From: TLS <tls-bounces@ietf.org> On Behalf O= f David Benjamin
Sent: Tuesday, June 12, 2018 12:28 PM
To: <tls@ietf.o= rg> <tls@ietf.o= rg>
Subject: [TLS] Enforcing Protocol Invariants
=C2=A0
Hi all,
=C2=A0
Now that TLS 1.3 is about done, perhaps it is time to reflect on the oss= ification problems.
=C2=A0
TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may b= e incrementally rolled out in an existing compliant TLS 1.2 deployment. Yet= we had problems. Widespread non-compliant servers broke on the TLS 1.3 ClientHello, so versioning moved to supported_= versions. Widespread non-compliant middleboxes attempted to parse someone e= lse=E2=80=99s ServerHellos, so the protocol was further hacked to weave thr= ough their many defects.
=C2=A0
I think I can speak for the working group that we do not want to repeat = this adventure again. In general, I think the response to ossification is t= wo-fold:
=C2=A0
1. It=E2=80=99s already happened, so how do we progress today?
2. How do we avoid more of this tomorrow?
=C2=A0
The workarounds only answer the first question. For the second, TLS 1.3 = has a section which spells out a few protocol invariants. It is all corollaries of existing TLS specificat= ion text, but hopefully documenting it explicitly will help. But experience= has shown specification text is only necessary, not sufficient.
=C2=A0
For extensibility problems in servers, we have GREASE. This enforces the key rule in ClientHello processing: ignore unrecognized p= arameters. GREASE enforces this by filling the ecosystem with them. TLS 1.3= =E2=80=99s middlebox woes were different. The key rule is: if you did not p= roduce a ClientHello, you cannot assume that you can parse the response. Analogously, we should fill the ecosystem = with such responses. We have an idea, but it is more involved than GREASE, = so we are very interested in the TLS community=E2=80=99s feedback.
=C2=A0
In short, we plan to regularly mint new TLS versions (and likely other s= ensitive parameters such as extensions), roughly every six weeks matching C= hrome=E2=80=99s release cycle. Chrome, Google servers, and any other deployment that wishes to participate, would support= two (or more) versions of TLS 1.3: the standard stable 0x0304, and a rolli= ng alternate version. Every six weeks, we would randomly pick a new code po= int. These versions will otherwise be identical to TLS 1.3, save maybe minor details to separate keys and exer= cise allowed syntax changes. The goal is to pave the way for future version= s of TLS by simulating them (=E2=80=9Cdraft negative one=E2=80=9D).<= /font>
=C2=A0
Of course, this scheme has some risk. It grabs code points everywhere. C= ode points are plentiful, but we do sometimes have collisions (e.g. 26 and = 40). The entire point is to serve and maintain TLS=E2=80=99s extensibility, so we certainly do not wish to hamper= it! Thus we have some safeguards in mind:
=C2=A0
* We will document every code point we use and what it refers to. (If th= e volume is fine, we can email them to the list each time.) New allocations= can always avoid the lost numbers. At a rate of one every 6 weeks, it will take over 7,000 years to exhaust every= thing.
=C2=A0
* We will avoid picking numbers that the IETF is likely to allocate, to = reduce the chance of collision. Rolling versions will not start with 0x03, = rolling cipher suites or extensions will not be contiguous with existing blocks, etc.
=C2=A0
* BoringSSL will not enable this by default. We will only enable it wher= e we can shut it back off. On our servers, we of course regularly deploy ch= anges. Chrome is also regularly updated and, moreover, we will gate it on our server-controlled field trials mechanism. We hope that, in practice, only the last s= everal code points will be in use at a time.
=C2=A0
*=C2=A0Our clients would only support the most recent set of rolling par= ameters, and our servers the last handful. As each value will be short-live= d, the ecosystem is unlikely to rely on them as de facto standards. Conversely, like other extensions, implementations w= ithout them will still interoperate fine. We would never offer a rolling pa= rameter without the corresponding stable one.
=C2=A0
*=C2=A0If this ultimately does not work, we can stop at any time and onl= y have wasted a small portion of code points.
=C2=A0
* Finally, if the working group is open to it, these values could be sum= marized in regular documents to reserve them, so that they are ultimately r= eflected in the registries. A new document every six weeks is probably impractical, but we can batch them up.
=C2=A0
We are interested in the community=E2=80=99s feedback on this proposal= =E2=80=94anyone who might participate, better safeguards, or thoughts on th= e mechanism as a whole. We hope it will help the working group evolve its protocols more smoothly in the future.
=C2=A0
David
=C2=A0
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
<= /div>
--00000000000036b7d0056e9b03b9-- From nobody Thu Jun 14 10:13:29 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAEA130E54 for ; Thu, 14 Jun 2018 10:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.73 X-Spam-Level: X-Spam-Status: No, score=-0.73 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=ovj9u3Zk; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=AavRQUtI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAQKYOyJEws4 for ; Thu, 14 Jun 2018 10:13:24 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 DB842130E52 for ; Thu, 14 Jun 2018 10:13:23 -0700 (PDT) Received: from pps.filterd (m0109331.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5EHDJ4B016888; Thu, 14 Jun 2018 10:13:21 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=JcKmkdggAst+LwPcZFnPTt3m9vw/yIkEgfZs6I0C40w=; b=ovj9u3ZksyLxw/MepgTSDc2qqDQyjkozeFtuqBG10DzTaWnpoTtumt/DxlIodlRatsMi pKncwWDRqwokc6WxWmv5m0JeM+DOjBDEYIs0nEHetfcKbhl3Ip4NAINPA8uKKVynkhUH t+C+qUc4H09xCTFNtxY8EaEFnnH9IoHd2UI= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2jkvfd80qj-4 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Jun 2018 10:13:21 -0700 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.21) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 14 Jun 2018 10:13:09 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JcKmkdggAst+LwPcZFnPTt3m9vw/yIkEgfZs6I0C40w=; b=AavRQUtIsHthsz2ycymF09k8TcpH9KGkkcyllIb4E205afTZW+MdP1hNPEszAG7MTpxAZAAJu83RWwC6QReqBoPbkSJXpeMrLBSGTxd6LTupzsLwuxnoKLTWmeAVu2afEJj5xeT5V0x8CqFwuJSFbBVR9GtOedR3kbs1w4e73Co= Received: from MWHPR15MB1504.namprd15.prod.outlook.com (10.173.235.13) by MWHPR15MB1645.namprd15.prod.outlook.com (10.175.135.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.16; Thu, 14 Jun 2018 17:13:05 +0000 Received: from MWHPR15MB1504.namprd15.prod.outlook.com ([fe80::d0b7:5e1e:5350:41d2]) by MWHPR15MB1504.namprd15.prod.outlook.com ([fe80::d0b7:5e1e:5350:41d2%3]) with mapi id 15.20.0863.016; Thu, 14 Jun 2018 17:13:05 +0000 From: Kyle Nekritz To: Steven Valdez CC: David Benjamin , "" Thread-Topic: [TLS] Enforcing Protocol Invariants Thread-Index: AQHUAmp+oLBw1HEpZU66EQxShrOpCaRe31FAgAD1tQCAAAf20A== Date: Thu, 14 Jun 2018 17:13:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c091:200::1:45d4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1645; 7:IoLdxL2sB8zg8ej74m4j7dAeyyL27VdlAdRCVqo6g5d3sdVqJYr2rWUi0C6ts5NYshgjIJrWa0FmChBn03NBiCphS6Wpos2iYXHYF/eQlnPg0y3ZscR+WVwZuXz4GiAHbQ9+sctOXjZvV5TcdRj1mxQZfYg3cYDJ/V89D7MG1926WQIgIqdFw+GbXvC9PpG0IXTTevWhEVrjjmFFJ7rH2BAHWTvsu7tfqIljWPOmOj4su+afG1I3V9m4Ia7WmMD7; 20:/G1FsgBPnSZ3QzqGFWnGtXL8JyswwqWHfHjsmyNH+nI21/V5EWIGOQt4gsgzdQAar6c0kMqlLIZOGsWKt8szLRTWXONaziNsiNHVQQQn8w9ZDtq//IBr9HvCbt0M3AEA4vAmUF02nZaA0HAqdh9A3wfZ1DShgT5hLbXpAAP3xUY= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: d1e12749-4125-4e58-9805-08d5d21a17f9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:MWHPR15MB1645; x-ms-traffictypediagnostic: MWHPR15MB1645: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(10436049006162)(788757137089)(67672495146484)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231254)(11241501184)(944501410)(52105095)(93006095)(93001095)(3002001)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:MWHPR15MB1645; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1645; x-forefront-prvs: 0703B549E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(39380400002)(396003)(376002)(366004)(189003)(199004)(53754006)(81156014)(790700001)(6116002)(6916009)(5250100002)(9686003)(6306002)(236005)(54896002)(105586002)(33656002)(19609705001)(6246003)(966005)(478600001)(14454004)(5660300001)(316002)(106356001)(25786009)(53936002)(4326008)(8676002)(8936002)(81166006)(54906003)(7736002)(3280700002)(46003)(6436002)(68736007)(7696005)(76176011)(6506007)(99286004)(186003)(486006)(59450400001)(2906002)(11346002)(606006)(86362001)(102836004)(446003)(74316002)(3660700001)(476003)(97736004)(2900100001)(229853002)(55016002)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1645; H:MWHPR15MB1504.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: tmcXPoG1FprcORAAEUKrA5EMVwBOzknGEewqXRz1txts+83Q0zgMdoSQFcwlnBecgFZj1469YI75qDyzlIS1mnK6ytvS9W23edf+qrL3/nyI3VHGu+qa3QS9qc06/9P7YJWGd5D501rhHlz1ISfXM7F1sQTnuTsqGONazC57l9tdHGmMi7W3HfgUusSYYyrN spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB15049038BE121821DC4E399AAF7D0MWHPR15MB1504namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d1e12749-4125-4e58-9805-08d5d21a17f9 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2018 17:13:05.4267 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1645 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-14_07:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [TLS] Enforcing Protocol Invariants X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2018 17:13:28 -0000 --_000_MWHPR15MB15049038BE121821DC4E399AAF7D0MWHPR15MB1504namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdOKAmXMgZGVmaW5pdGVseSBhIHBvc3NpYmlsaXR5IGlmIHVzaW5nIGEgc2luZ2xlIGtleSB0 aGF0IG5ldmVyIGNoYW5nZXMuIFdpdGggcGVyaW9kaWNhbGx5IHJvbGxpbmcgbmV3IGtleXMsIEni gJltIG5vdCBzdXJlIHRoZSByaXNrIGlzIG11Y2ggZGlmZmVyZW50IHRoYW4gd2l0aCBwZXJpb2Rp Y2FsbHkgcm9sbGluZyBuZXcgdmVyc2lvbnMuIE9zc2lmeWluZyBvbiB1cGRhdGVkIHZlcnNpb25z IG9mIGVpdGhlciByZXF1aXJlcyB0aGUgbWlkZGxlYm94IHRvIHRha2UgYSBoYXJkIGRlcGVuZGVu Y3kgb24gaGF2aW5nIHRoZSB1cGRhdGVkIHZlcnNpb24gYXZhaWxhYmxlLiBVcGRhdGluZyBmb3Ig YXJiaXRyYXJ5IGNoYW5nZXMgaW4gdGhlIHByb3RvY29sIGlzIG1vcmUgY29tcGxleCB0aGFuIGp1 c3QgdXBkYXRpbmcgYSBjb25maWcgZm9yIGFuIGVuY3J5cHRpb24ga2V5LCBidXQgSSBzdXNwZWN0 IHdlIGNvdWxkIGFsc28gcm9sbCBvdXQgYW4gdXBkYXRlZCBrZXkgbWFwcGluZyBtdWNoIGZhc3Rl ciB0aGFuIGEgbmV3IHZlcnNpb24gdGhhdCByZXF1aXJlZCBUTFMgbGlicmFyeSBjb2RlIGNoYW5n ZXMuDQoNClVzaW5nIGEgbmVnb3RpYXRlZCBrZXkgZnJvbSBhIHByZXZpb3VzIGNvbm5lY3Rpb24g Y29tcGxldGVseSBhdm9pZHMgdGhhdCBpc3N1ZSAoZm9yIGV4YW1wbGUgdGhlIHNlcnZlciBzZW5k cyBhbiBlbmNyeXB0ZWQgZXh0ZW5zaW9uIHdpdGggaWRlbnRpZmllciBYIGFuZCBrZXkgWSwgd2hp Y2ggdGhlIGNsaWVudCByZW1lbWJlcnMgZm9yIGZ1dHVyZSBjb25uZWN0aW9ucykuDQoNCkZyb206 IFN0ZXZlbiBWYWxkZXogPHN2YWxkZXpAY2hyb21pdW0ub3JnPg0KU2VudDogVGh1cnNkYXksIEp1 bmUgMTQsIDIwMTggMTA6MzUgQU0NClRvOiBLeWxlIE5la3JpdHogPGtuZWtyaXR6QGZiLmNvbT4N CkNjOiBEYXZpZCBCZW5qYW1pbiA8ZGF2aWRiZW5AY2hyb21pdW0ub3JnPjsgPHRsc0BpZXRmLm9y Zz4gPHRsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVExTXSBFbmZvcmNpbmcgUHJvdG9jb2wg SW52YXJpYW50cw0KDQpUaGlzIHNjaGVtZSBwcm9iYWJseSBpc24ndCBzdWZmaWNpZW50IGJ5IGl0 c2VsZiwgc2luY2UgYSBtaWRkbGVib3gganVzdCBoYXMgdG8gYmUgYXdhcmUgb2YgdGhlIGFudGkt b3NzaWZpY2F0aW9uIGV4dGVuc2lvbiBhbmQgY2FuIHBhcnNlIHRoZSBzZXJ2ZXIncyByZXNwb25z ZSBieSBkZWNyeXB0aW5nIGl0IHdpdGggdGhlIGtub3duIG1hcHBpbmcgKGVpdGhlciBmcm9tIHRo ZSBSRkMgb3IgZmV0Y2hpbmcgdGhlIGxhdGVzdCB1cGRhdGVkIG1hcHBpbmcpLCBhbmQgdGhlbiBv c3NpZnlpbmcgb24gdGhlIGNvbnRlbnRzIG9mIHRoZSAncmVhbCcgU2VydmVySGVsbG8uIFRvIGtl ZXAgdGhlIFNlcnZlckhlbGxvIGZyb20gb3NzaWZ5aW5nLCB5b3UnbGwgbmVlZCB0byBjaGFuZ2Ug dGhlIHNlcmlhbGl6YXRpb24gYW5kIGNvZGVwb2ludHMgb2YgdGhlIFNlcnZlckhlbGxvIGF0IGVh Y2ggcm9sbGluZyB2ZXJzaW9uLg0KDQpPbiBXZWQsIEp1biAxMywgMjAxOCBhdCA4OjI5IFBNIEt5 bGUgTmVrcml0eiA8a25la3JpdHpAZmIuY29tPG1haWx0bzprbmVrcml0ekBmYi5jb20+PiB3cm90 ZToNCkkgdGhpbmsgdGhlcmUgbWF5IGJlIGxvd2VyIG92ZXJoZWFkIHdheXMgKHRoYXQgZG9u4oCZ dCByZXF1aXJlIGZyZXF1ZW50IFRMUyBsaWJyYXJ5IGNvZGUgY2hhbmdlcykgdG8gcHJldmVudCBv c3NpZmljYXRpb24gb2YgdGhlIFNlcnZlckhlbGxvIHVzaW5nIGEgbWVjaGFuaXNtIHNpbWlsYXIg dG8gdGhlIGNsZWFydGV4dCBjaXBoZXIgaW4gcXVpYy4gRm9yIGV4YW1wbGUsIGEgY2xpZW50IGNv dWxkIG9mZmVyIGFuIOKAnGFudGktb3NzaWZpY2F0aW9u4oCdIGV4dGVuc2lvbiBjb250YWluaW5n IGFuIGlkZW50aWZpZXIgdGhhdCBjb3JyZXNwb25kcyB0byBhIHBhcnRpY3VsYXIga2V5LiBUaGUg aWRlbnRpZmllci0+a2V5IG1hcHBpbmcgY2FuIGJlIGVzdGFibGlzaGVkIHVzaW5nIGEgY291cGxl IG9mIG1lY2hhbmlzbXMsIGRlcGVuZGluZyBvbiB0aGUgbGV2ZWwgb2YgZGVmZW5zZSBkZXNpcmVk IGFnYWluc3QgaW1wbGVtZW50YXRpb25zIHRoYXQga25vdyBhYm91dCB0aGlzIGV4dGVuc2lvbjoN Ciogc3RhdGljIG1hcHBpbmcgZGVmaW5lZCBpbiBSRkMNCiogcGVyaW9kaWNhbGx5IHVwZGF0ZWQg bWFwcGluZyBzaGFyZWQgYW1vbmcgaW1wbGVtZW50YXRpb25zDQoqIG5lZ290aWF0ZWQgb24gYSBw cmV2aW91cyBjb25uZWN0aW9uIHRvIHRoZSBzZXJ2ZXIsIHNpbWlsYXIgdG8gYSBQU0sNClRoaXMg a2V5IGNhbiB0aGVuIGJlIHVzZWQgdG8g4oCcZW5jcnlwdOKAnSB0aGUgU2VydmVySGVsbG8gc3Vj aCB0aGF0IGl0IGlzIGltcG9zc2libGUgZm9yIGEgbWlkZGxlYm94IHdpdGhvdXQgdGhlIGtleSB0 byByZWFkICh0aG91Z2ggd291bGQgbm90IGFkZCBhY3R1YWwgY29uZmlkZW50aWFsaXR5IGFuZCB3 b3VsZCBwcm9iYWJseSBpbnZvbHZlIGFlYWQgbm9uY2UtcmV1c2UpLiBUaGVyZeKAmXMgYSBjb3Vw bGUgb2Ygb3B0aW9ucyB0byBkbyB0aGlzOg0KKiBTaW1wbHkgcmVwbGFjZSB0aGUgcGxhaW50ZXh0 IHJlY29yZCBsYXllciBmb3IgdGhlIFNlcnZlckhlbGxvIHdpdGggYW4gZW5jcnlwdGVkIHJlY29y ZCBsYXllciwgdXNpbmcgdGhpcyBrZXkgKHRoaXMgd291bGQgbm90IGJlIGNvbXBhdGlibGUgd2l0 aCBleGlzdGluZyBtaWRkbGVib3hlcyB0aGF0IGhhdmUgY2F1c2VkIHVzIHRyb3VibGUpDQoqIFB1 dCBhIOKAnHJlYWzigJ0gZW5jcnlwdGVkIFNlcnZlckhlbGxvIGluIGFuIGV4dGVuc2lvbiBpbiB0 aGUg4oCcb3V0ZXLigJ0gcGxhaW50ZXh0IFNlcnZlckhlbGxvDQoqIFNlbmQgYSBmYWtlIFNlcnZl ckhlbGxvIChzaW1pbGFyIHRvIGhvdyB3ZSBlbmNhcHN1bGF0ZSBIZWxsb1JldHJ5UmVxdWVzdCBp biBhIFNlcnZlckhlbGxvKSwgYW5kIHRoZW4gc2VuZCBhIHJlYWwgU2VydmVySGVsbG8gaW4gYSBm b2xsb3dpbmcgZW5jcnlwdGVkIHJlY29yZA0KQWxsIG9mIHRoZXNlIHdvdWxkIGFsbG93IGEgc2Vy dmVyIHRvIGVpdGhlciB1c2UgdGhpcyBtZWNoYW5pc20gb3IgbmVnb3RpYXRlIHN0YW5kYXJkIFRM UyAxLjMgKGFuZCB0aGUgY2xpZW50IHRvIGVhc2lseSB0ZWxsIHdoaWNoIG9uZSBpcyBpbiB1c2Up Lg0KDQpXaXRoIHRoZSBzbWFsbCBleGNlcHRpb24gb2YgcG90ZW50aWFsbHkgdXBkYXRpbmcgdGhl IGlkZW50aWZpZXItPmtleSBtYXBwaW5nLCB0aGlzIHdvdWxkIG5vdCByZXF1aXJlIGFueSBUTFMg bGlicmFyeSBjaGFuZ2VzIChvbmNlIGltcGxlbWVudGVkIGluIHRoZSBmaXJzdCBwbGFjZSksIGFu ZCBJIGJlbGlldmUgd291bGQgc3RpbGwgcHJvdmlkZSBhbG1vc3QgYWxsIG9mIHRoZSBiZW5lZml0 cy4NCg0KRnJvbTogVExTIDx0bHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dGxzLWJvdW5jZXNA aWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgRGF2aWQgQmVuamFtaW4NClNlbnQ6IFR1ZXNkYXksIEp1 bmUgMTIsIDIwMTggMTI6MjggUE0NClRvOiA8dGxzQGlldGYub3JnPG1haWx0bzp0bHNAaWV0Zi5v cmc+PiA8dGxzQGlldGYub3JnPG1haWx0bzp0bHNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW1RMU10g RW5mb3JjaW5nIFByb3RvY29sIEludmFyaWFudHMNCg0KSGkgYWxsLA0KDQpOb3cgdGhhdCBUTFMg MS4zIGlzIGFib3V0IGRvbmUsIHBlcmhhcHMgaXQgaXMgdGltZSB0byByZWZsZWN0IG9uIHRoZSBv c3NpZmljYXRpb24gcHJvYmxlbXMuDQoNClRMUyBpcyBhbiBleHRlbnNpYmxlIHByb3RvY29sLiBU TFMgMS4zIGlzIGJhY2t3YXJkcy1jb21wYXRpYmxlIGFuZCBtYXkgYmUgaW5jcmVtZW50YWxseSBy b2xsZWQgb3V0IGluIGFuIGV4aXN0aW5nIGNvbXBsaWFudCBUTFMgMS4yIGRlcGxveW1lbnQuIFll dCB3ZSBoYWQgcHJvYmxlbXMuIFdpZGVzcHJlYWQgbm9uLWNvbXBsaWFudCBzZXJ2ZXJzIGJyb2tl IG9uIHRoZSBUTFMgMS4zIENsaWVudEhlbGxvLCBzbyB2ZXJzaW9uaW5nIG1vdmVkIHRvIHN1cHBv cnRlZF92ZXJzaW9ucy4gV2lkZXNwcmVhZCBub24tY29tcGxpYW50IG1pZGRsZWJveGVzIGF0dGVt cHRlZCB0byBwYXJzZSBzb21lb25lIGVsc2XigJlzIFNlcnZlckhlbGxvcywgc28gdGhlIHByb3Rv Y29sIHdhcyBmdXJ0aGVyIGhhY2tlZCB0byB3ZWF2ZSB0aHJvdWdoIHRoZWlyIG1hbnkgZGVmZWN0 cy4NCg0KSSB0aGluayBJIGNhbiBzcGVhayBmb3IgdGhlIHdvcmtpbmcgZ3JvdXAgdGhhdCB3ZSBk byBub3Qgd2FudCB0byByZXBlYXQgdGhpcyBhZHZlbnR1cmUgYWdhaW4uIEluIGdlbmVyYWwsIEkg dGhpbmsgdGhlIHJlc3BvbnNlIHRvIG9zc2lmaWNhdGlvbiBpcyB0d28tZm9sZDoNCg0KMS4gSXTi gJlzIGFscmVhZHkgaGFwcGVuZWQsIHNvIGhvdyBkbyB3ZSBwcm9ncmVzcyB0b2RheT8NCjIuIEhv dyBkbyB3ZSBhdm9pZCBtb3JlIG9mIHRoaXMgdG9tb3Jyb3c/DQoNClRoZSB3b3JrYXJvdW5kcyBv bmx5IGFuc3dlciB0aGUgZmlyc3QgcXVlc3Rpb24uIEZvciB0aGUgc2Vjb25kLCBUTFMgMS4zIGhh cyBhIHNlY3Rpb24gd2hpY2ggc3BlbGxzIG91dCBhIGZldyBwcm90b2NvbCBpbnZhcmlhbnRzPGh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdGxzd2cu Z2l0aHViLmlvX3RsczEzLTJEc3BlY19kcmFmdC0yRGlldGYtMkR0bHMtMkR0bHMxMy5odG1sLTIz cmZjLnNlY3Rpb24uOS4zJmQ9RHdNRmFRJmM9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZyPWwyajRC amtPMExjM3U0Q0gyejdqUHcmbT1TYVdwbGt4a2J2OU9fWjcxSGRFNkw3MXZ1MmY3b3ZXV2FFUXJQ UlJieXdjJnM9RjdJSjlOYWM1T2ZfR0N2QlZrMF9RaFRwbENKam9ib0JTZW1IbDBwaTFvTSZlPT4u IEl0IGlzIGFsbCBjb3JvbGxhcmllcyBvZiBleGlzdGluZyBUTFMgc3BlY2lmaWNhdGlvbiB0ZXh0 LCBidXQgaG9wZWZ1bGx5IGRvY3VtZW50aW5nIGl0IGV4cGxpY2l0bHkgd2lsbCBoZWxwLiBCdXQg ZXhwZXJpZW5jZSBoYXMgc2hvd24gc3BlY2lmaWNhdGlvbiB0ZXh0IGlzIG9ubHkgbmVjZXNzYXJ5 LCBub3Qgc3VmZmljaWVudC4NCg0KRm9yIGV4dGVuc2liaWxpdHkgcHJvYmxlbXMgaW4gc2VydmVy cywgd2UgaGF2ZSBHUkVBU0U8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJEaWV0Zi0yRHRscy0yRGdy ZWFzZS0yRDAxJmQ9RHdNRmFRJmM9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZyPWwyajRCamtPMExj M3U0Q0gyejdqUHcmbT1TYVdwbGt4a2J2OU9fWjcxSGRFNkw3MXZ1MmY3b3ZXV2FFUXJQUlJieXdj JnM9dGNBbHUyZkVma0tqTTJsNFdCQ0NSb3NPR1YzRE1BUWNIdmg4UGUzOEs1dyZlPT4uIFRoaXMg ZW5mb3JjZXMgdGhlIGtleSBydWxlIGluIENsaWVudEhlbGxvIHByb2Nlc3Npbmc6IGlnbm9yZSB1 bnJlY29nbml6ZWQgcGFyYW1ldGVycy4gR1JFQVNFIGVuZm9yY2VzIHRoaXMgYnkgZmlsbGluZyB0 aGUgZWNvc3lzdGVtIHdpdGggdGhlbS4gVExTIDEuM+KAmXMgbWlkZGxlYm94IHdvZXMgd2VyZSBk aWZmZXJlbnQuIFRoZSBrZXkgcnVsZSBpczogaWYgeW91IGRpZCBub3QgcHJvZHVjZSBhIENsaWVu dEhlbGxvLCB5b3UgY2Fubm90IGFzc3VtZSB0aGF0IHlvdSBjYW4gcGFyc2UgdGhlIHJlc3BvbnNl LiBBbmFsb2dvdXNseSwgd2Ugc2hvdWxkIGZpbGwgdGhlIGVjb3N5c3RlbSB3aXRoIHN1Y2ggcmVz cG9uc2VzLiBXZSBoYXZlIGFuIGlkZWEsIGJ1dCBpdCBpcyBtb3JlIGludm9sdmVkIHRoYW4gR1JF QVNFLCBzbyB3ZSBhcmUgdmVyeSBpbnRlcmVzdGVkIGluIHRoZSBUTFMgY29tbXVuaXR54oCZcyBm ZWVkYmFjay4NCg0KSW4gc2hvcnQsIHdlIHBsYW4gdG8gcmVndWxhcmx5IG1pbnQgbmV3IFRMUyB2 ZXJzaW9ucyAoYW5kIGxpa2VseSBvdGhlciBzZW5zaXRpdmUgcGFyYW1ldGVycyBzdWNoIGFzIGV4 dGVuc2lvbnMpLCByb3VnaGx5IGV2ZXJ5IHNpeCB3ZWVrcyBtYXRjaGluZyBDaHJvbWXigJlzIHJl bGVhc2UgY3ljbGUuIENocm9tZSwgR29vZ2xlIHNlcnZlcnMsIGFuZCBhbnkgb3RoZXIgZGVwbG95 bWVudCB0aGF0IHdpc2hlcyB0byBwYXJ0aWNpcGF0ZSwgd291bGQgc3VwcG9ydCB0d28gKG9yIG1v cmUpIHZlcnNpb25zIG9mIFRMUyAxLjM6IHRoZSBzdGFuZGFyZCBzdGFibGUgMHgwMzA0LCBhbmQg YSByb2xsaW5nIGFsdGVybmF0ZSB2ZXJzaW9uLiBFdmVyeSBzaXggd2Vla3MsIHdlIHdvdWxkIHJh bmRvbWx5IHBpY2sgYSBuZXcgY29kZSBwb2ludC4gVGhlc2UgdmVyc2lvbnMgd2lsbCBvdGhlcndp c2UgYmUgaWRlbnRpY2FsIHRvIFRMUyAxLjMsIHNhdmUgbWF5YmUgbWlub3IgZGV0YWlscyB0byBz ZXBhcmF0ZSBrZXlzIGFuZCBleGVyY2lzZSBhbGxvd2VkIHN5bnRheCBjaGFuZ2VzLiBUaGUgZ29h bCBpcyB0byBwYXZlIHRoZSB3YXkgZm9yIGZ1dHVyZSB2ZXJzaW9ucyBvZiBUTFMgYnkgc2ltdWxh dGluZyB0aGVtICjigJxkcmFmdCBuZWdhdGl2ZSBvbmXigJ0pLg0KDQpPZiBjb3Vyc2UsIHRoaXMg c2NoZW1lIGhhcyBzb21lIHJpc2suIEl0IGdyYWJzIGNvZGUgcG9pbnRzIGV2ZXJ5d2hlcmUuIENv ZGUgcG9pbnRzIGFyZSBwbGVudGlmdWwsIGJ1dCB3ZSBkbyBzb21ldGltZXMgaGF2ZSBjb2xsaXNp b25zIChlLmcuIDI2IGFuZCA0MCkuIFRoZSBlbnRpcmUgcG9pbnQgaXMgdG8gc2VydmUgYW5kIG1h aW50YWluIFRMU+KAmXMgZXh0ZW5zaWJpbGl0eSwgc28gd2UgY2VydGFpbmx5IGRvIG5vdCB3aXNo IHRvIGhhbXBlciBpdCEgVGh1cyB3ZSBoYXZlIHNvbWUgc2FmZWd1YXJkcyBpbiBtaW5kOg0KDQoq IFdlIHdpbGwgZG9jdW1lbnQgZXZlcnkgY29kZSBwb2ludCB3ZSB1c2UgYW5kIHdoYXQgaXQgcmVm ZXJzIHRvLiAoSWYgdGhlIHZvbHVtZSBpcyBmaW5lLCB3ZSBjYW4gZW1haWwgdGhlbSB0byB0aGUg bGlzdCBlYWNoIHRpbWUuKSBOZXcgYWxsb2NhdGlvbnMgY2FuIGFsd2F5cyBhdm9pZCB0aGUgbG9z dCBudW1iZXJzLiBBdCBhIHJhdGUgb2Ygb25lIGV2ZXJ5IDYgd2Vla3MsIGl0IHdpbGwgdGFrZSBv dmVyIDcsMDAwIHllYXJzIHRvIGV4aGF1c3QgZXZlcnl0aGluZy4NCg0KKiBXZSB3aWxsIGF2b2lk IHBpY2tpbmcgbnVtYmVycyB0aGF0IHRoZSBJRVRGIGlzIGxpa2VseSB0byBhbGxvY2F0ZSwgdG8g cmVkdWNlIHRoZSBjaGFuY2Ugb2YgY29sbGlzaW9uLiBSb2xsaW5nIHZlcnNpb25zIHdpbGwgbm90 IHN0YXJ0IHdpdGggMHgwMywgcm9sbGluZyBjaXBoZXIgc3VpdGVzIG9yIGV4dGVuc2lvbnMgd2ls bCBub3QgYmUgY29udGlndW91cyB3aXRoIGV4aXN0aW5nIGJsb2NrcywgZXRjLg0KDQoqIEJvcmlu Z1NTTCB3aWxsIG5vdCBlbmFibGUgdGhpcyBieSBkZWZhdWx0LiBXZSB3aWxsIG9ubHkgZW5hYmxl IGl0IHdoZXJlIHdlIGNhbiBzaHV0IGl0IGJhY2sgb2ZmLiBPbiBvdXIgc2VydmVycywgd2Ugb2Yg Y291cnNlIHJlZ3VsYXJseSBkZXBsb3kgY2hhbmdlcy4gQ2hyb21lIGlzIGFsc28gcmVndWxhcmx5 IHVwZGF0ZWQgYW5kLCBtb3Jlb3Zlciwgd2Ugd2lsbCBnYXRlIGl0IG9uIG91ciBzZXJ2ZXItY29u dHJvbGxlZCBmaWVsZCB0cmlhbHM8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX190ZXh0c2xhc2hwbGFpbi5jb21fMjAxN18xMF8xOF9jaHJvbWUtMkRm aWVsZC0yRHRyaWFsc18mZD1Ed01GYVEmYz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9bDJqNEJq a08wTGMzdTRDSDJ6N2pQdyZtPVNhV3Bsa3hrYnY5T19aNzFIZEU2TDcxdnUyZjdvdldXYUVRclBS UmJ5d2Mmcz1vd0NKYlhzMUJ6blRMZHNob1paQTFob19nOXdfbTI3UGxmV3V0M2RNUnBNJmU9PiBt ZWNoYW5pc20uIFdlIGhvcGUgdGhhdCwgaW4gcHJhY3RpY2UsIG9ubHkgdGhlIGxhc3Qgc2V2ZXJh bCBjb2RlIHBvaW50cyB3aWxsIGJlIGluIHVzZSBhdCBhIHRpbWUuDQoNCiogT3VyIGNsaWVudHMg d291bGQgb25seSBzdXBwb3J0IHRoZSBtb3N0IHJlY2VudCBzZXQgb2Ygcm9sbGluZyBwYXJhbWV0 ZXJzLCBhbmQgb3VyIHNlcnZlcnMgdGhlIGxhc3QgaGFuZGZ1bC4gQXMgZWFjaCB2YWx1ZSB3aWxs IGJlIHNob3J0LWxpdmVkLCB0aGUgZWNvc3lzdGVtIGlzIHVubGlrZWx5IHRvIHJlbHkgb24gdGhl bSBhcyBkZSBmYWN0byBzdGFuZGFyZHMuIENvbnZlcnNlbHksIGxpa2Ugb3RoZXIgZXh0ZW5zaW9u cywgaW1wbGVtZW50YXRpb25zIHdpdGhvdXQgdGhlbSB3aWxsIHN0aWxsIGludGVyb3BlcmF0ZSBm aW5lLiBXZSB3b3VsZCBuZXZlciBvZmZlciBhIHJvbGxpbmcgcGFyYW1ldGVyIHdpdGhvdXQgdGhl IGNvcnJlc3BvbmRpbmcgc3RhYmxlIG9uZS4NCg0KKiBJZiB0aGlzIHVsdGltYXRlbHkgZG9lcyBu b3Qgd29yaywgd2UgY2FuIHN0b3AgYXQgYW55IHRpbWUgYW5kIG9ubHkgaGF2ZSB3YXN0ZWQgYSBz bWFsbCBwb3J0aW9uIG9mIGNvZGUgcG9pbnRzLg0KDQoqIEZpbmFsbHksIGlmIHRoZSB3b3JraW5n IGdyb3VwIGlzIG9wZW4gdG8gaXQsIHRoZXNlIHZhbHVlcyBjb3VsZCBiZSBzdW1tYXJpemVkIGlu IHJlZ3VsYXIgZG9jdW1lbnRzIHRvIHJlc2VydmUgdGhlbSwgc28gdGhhdCB0aGV5IGFyZSB1bHRp bWF0ZWx5IHJlZmxlY3RlZCBpbiB0aGUgcmVnaXN0cmllcy4gQSBuZXcgZG9jdW1lbnQgZXZlcnkg c2l4IHdlZWtzIGlzIHByb2JhYmx5IGltcHJhY3RpY2FsLCBidXQgd2UgY2FuIGJhdGNoIHRoZW0g dXAuDQoNCldlIGFyZSBpbnRlcmVzdGVkIGluIHRoZSBjb21tdW5pdHnigJlzIGZlZWRiYWNrIG9u IHRoaXMgcHJvcG9zYWzigJRhbnlvbmUgd2hvIG1pZ2h0IHBhcnRpY2lwYXRlLCBiZXR0ZXIgc2Fm ZWd1YXJkcywgb3IgdGhvdWdodHMgb24gdGhlIG1lY2hhbmlzbSBhcyBhIHdob2xlLiBXZSBob3Bl IGl0IHdpbGwgaGVscCB0aGUgd29ya2luZyBncm91cCBldm9sdmUgaXRzIHByb3RvY29scyBtb3Jl IHNtb290aGx5IGluIHRoZSBmdXR1cmUuDQoNCkRhdmlkDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5v cmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdGxzPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fdGxzJmQ9RHdNRmFRJmM9NVZEMFJU dE5sVGgzeWNkNDFiM01VdyZyPWwyajRCamtPMExjM3U0Q0gyejdqUHcmbT1BMGZ5eFc1cm1UY3Zi TWlUcDlzcEg5NUJJb1pWX2t6TjNhNVdERkllT01jJnM9LVcwUFJUUXZGVmJDR3JtTzE4X2xIY1Nm Wl9BZE5ZVmpBeW9QTmhHcHp3QSZlPT4NCg== --_000_MWHPR15MB15049038BE121821DC4E399AAF7D0MWHPR15MB1504namp_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5UaGF04oCZcyBkZWZpbml0ZWx5IGEgcG9zc2liaWxpdHkgaWYgdXNpbmcgYSBz aW5nbGUga2V5IHRoYXQgbmV2ZXIgY2hhbmdlcy4gV2l0aCBwZXJpb2RpY2FsbHkgcm9sbGluZyBu ZXcga2V5cywgSeKAmW0gbm90IHN1cmUgdGhlIHJpc2sgaXMgbXVjaCBkaWZmZXJlbnQgdGhhbiB3 aXRoIHBlcmlvZGljYWxseQ0KIHJvbGxpbmcgbmV3IHZlcnNpb25zLiBPc3NpZnlpbmcgb24gdXBk YXRlZCB2ZXJzaW9ucyBvZiBlaXRoZXIgcmVxdWlyZXMgdGhlIG1pZGRsZWJveCB0byB0YWtlIGEg aGFyZCBkZXBlbmRlbmN5IG9uIGhhdmluZyB0aGUgdXBkYXRlZCB2ZXJzaW9uIGF2YWlsYWJsZS4g VXBkYXRpbmcgZm9yIGFyYml0cmFyeSBjaGFuZ2VzIGluIHRoZSBwcm90b2NvbCBpcyBtb3JlIGNv bXBsZXggdGhhbiBqdXN0IHVwZGF0aW5nIGEgY29uZmlnIGZvciBhbiBlbmNyeXB0aW9uDQoga2V5 LCBidXQgSSBzdXNwZWN0IHdlIGNvdWxkIGFsc28gcm9sbCBvdXQgYW4gdXBkYXRlZCBrZXkgbWFw cGluZyBtdWNoIGZhc3RlciB0aGFuIGEgbmV3IHZlcnNpb24gdGhhdCByZXF1aXJlZCBUTFMgbGli cmFyeSBjb2RlIGNoYW5nZXMuPGJyPg0KPGJyPg0KVXNpbmcgYSBuZWdvdGlhdGVkIGtleSBmcm9t IGEgcHJldmlvdXMgY29ubmVjdGlvbiBjb21wbGV0ZWx5IGF2b2lkcyB0aGF0IGlzc3VlIChmb3Ig ZXhhbXBsZSB0aGUgc2VydmVyIHNlbmRzIGFuIGVuY3J5cHRlZCBleHRlbnNpb24gd2l0aCBpZGVu dGlmaWVyIFggYW5kIGtleSBZLCB3aGljaCB0aGUgY2xpZW50IHJlbWVtYmVycyBmb3IgZnV0dXJl IGNvbm5lY3Rpb25zKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gU3RldmVuIFZhbGRleiAmbHQ7c3ZhbGRlekBjaHJvbWl1 bS5vcmcmZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bmUgMTQsIDIwMTggMTA6 MzUgQU08YnI+DQo8Yj5Ubzo8L2I+IEt5bGUgTmVrcml0eiAmbHQ7a25la3JpdHpAZmIuY29tJmd0 Ozxicj4NCjxiPkNjOjwvYj4gRGF2aWQgQmVuamFtaW4gJmx0O2RhdmlkYmVuQGNocm9taXVtLm9y ZyZndDs7ICZsdDt0bHNAaWV0Zi5vcmcmZ3Q7ICZsdDt0bHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbVExTXSBFbmZvcmNpbmcgUHJvdG9jb2wgSW52YXJpYW50czxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHNjaGVtZSBwcm9i YWJseSBpc24ndCBzdWZmaWNpZW50IGJ5IGl0c2VsZiwgc2luY2UgYSBtaWRkbGVib3gganVzdCBo YXMgdG8gYmUgYXdhcmUgb2YgdGhlIGFudGktb3NzaWZpY2F0aW9uIGV4dGVuc2lvbiBhbmQgY2Fu IHBhcnNlIHRoZSBzZXJ2ZXIncyByZXNwb25zZSBieSBkZWNyeXB0aW5nIGl0IHdpdGggdGhlIGtu b3duIG1hcHBpbmcgKGVpdGhlciBmcm9tIHRoZSBSRkMgb3IgZmV0Y2hpbmcgdGhlDQogbGF0ZXN0 IHVwZGF0ZWQgbWFwcGluZyksIGFuZCB0aGVuIG9zc2lmeWluZyBvbiB0aGUgY29udGVudHMgb2Yg dGhlICdyZWFsJyBTZXJ2ZXJIZWxsby4gVG8ga2VlcCB0aGUgU2VydmVySGVsbG8gZnJvbSBvc3Np ZnlpbmcsIHlvdSdsbCBuZWVkIHRvIGNoYW5nZSB0aGUgc2VyaWFsaXphdGlvbiBhbmQgY29kZXBv aW50cyBvZiB0aGUgU2VydmVySGVsbG8gYXQgZWFjaCByb2xsaW5nIHZlcnNpb24uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEp1biAxMywgMjAx OCBhdCA4OjI5IFBNIEt5bGUgTmVrcml0eiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtuZWtyaXR6QGZi LmNvbSI+a25la3JpdHpAZmIuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+SSB0aGluayB0aGVyZSBtYXkgYmUgbG93ZXIgb3ZlcmhlYWQgd2F5cyAodGhh dCBkb27igJl0IHJlcXVpcmUgZnJlcXVlbnQgVExTIGxpYnJhcnkgY29kZSBjaGFuZ2VzKSB0byBw cmV2ZW50IG9zc2lmaWNhdGlvbiBvZiB0aGUgU2VydmVySGVsbG8gdXNpbmcgYSBtZWNoYW5pc20g c2ltaWxhciB0byB0aGUNCiBjbGVhcnRleHQgY2lwaGVyIGluIHF1aWMuIEZvciBleGFtcGxlLCBh IGNsaWVudCBjb3VsZCBvZmZlciBhbiDigJxhbnRpLW9zc2lmaWNhdGlvbuKAnSBleHRlbnNpb24g Y29udGFpbmluZyBhbiBpZGVudGlmaWVyIHRoYXQgY29ycmVzcG9uZHMgdG8gYSBwYXJ0aWN1bGFy IGtleS4gVGhlIGlkZW50aWZpZXItJmd0O2tleSBtYXBwaW5nIGNhbiBiZSBlc3RhYmxpc2hlZCB1 c2luZyBhIGNvdXBsZSBvZiBtZWNoYW5pc21zLCBkZXBlbmRpbmcgb24gdGhlIGxldmVsDQogb2Yg ZGVmZW5zZSBkZXNpcmVkIGFnYWluc3QgaW1wbGVtZW50YXRpb25zIHRoYXQga25vdyBhYm91dCB0 aGlzIGV4dGVuc2lvbjo8YnI+DQoqIHN0YXRpYyBtYXBwaW5nIGRlZmluZWQgaW4gUkZDPGJyPg0K KiBwZXJpb2RpY2FsbHkgdXBkYXRlZCBtYXBwaW5nIHNoYXJlZCBhbW9uZyBpbXBsZW1lbnRhdGlv bnM8YnI+DQoqIG5lZ290aWF0ZWQgb24gYSBwcmV2aW91cyBjb25uZWN0aW9uIHRvIHRoZSBzZXJ2 ZXIsIHNpbWlsYXIgdG8gYSBQU0s8YnI+DQpUaGlzIGtleSBjYW4gdGhlbiBiZSB1c2VkIHRvIOKA nGVuY3J5cHTigJ0gdGhlIFNlcnZlckhlbGxvIHN1Y2ggdGhhdCBpdCBpcyBpbXBvc3NpYmxlIGZv ciBhIG1pZGRsZWJveCB3aXRob3V0IHRoZSBrZXkgdG8gcmVhZCAodGhvdWdoIHdvdWxkIG5vdCBh ZGQgYWN0dWFsIGNvbmZpZGVudGlhbGl0eSBhbmQgd291bGQgcHJvYmFibHkgaW52b2x2ZSBhZWFk IG5vbmNlLXJldXNlKS4gVGhlcmXigJlzIGEgY291cGxlIG9mIG9wdGlvbnMgdG8NCjxhIG5hbWU9 Im1fNzM2NjcyOTcyNDYzMjM3MjgyOF9fTWFpbEVuZENvbXBvc2UiPjwvYT5kbyB0aGlzOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+KiBTaW1wbHkgcmVwbGFjZSB0aGUgcGxhaW50ZXh0IHJlY29yZCBsYXll ciBmb3IgdGhlIFNlcnZlckhlbGxvIHdpdGggYW4gZW5jcnlwdGVkIHJlY29yZCBsYXllciwgdXNp bmcgdGhpcyBrZXkgKHRoaXMgd291bGQgbm90IGJlIGNvbXBhdGlibGUgd2l0aCBleGlzdGluZyBt aWRkbGVib3hlcyB0aGF0DQogaGF2ZSBjYXVzZWQgdXMgdHJvdWJsZSk8YnI+DQoqIFB1dCBhIOKA nHJlYWzigJ0gZW5jcnlwdGVkIFNlcnZlckhlbGxvIGluIGFuIGV4dGVuc2lvbiBpbiB0aGUg4oCc b3V0ZXLigJ0gcGxhaW50ZXh0IFNlcnZlckhlbGxvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4qIFNlbmQg YSBmYWtlIFNlcnZlckhlbGxvIChzaW1pbGFyIHRvIGhvdyB3ZSBlbmNhcHN1bGF0ZSBIZWxsb1Jl dHJ5UmVxdWVzdCBpbiBhIFNlcnZlckhlbGxvKSwgYW5kIHRoZW4gc2VuZCBhIHJlYWwgU2VydmVy SGVsbG8gaW4gYSBmb2xsb3dpbmcgZW5jcnlwdGVkIHJlY29yZDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ QWxsIG9mIHRoZXNlIHdvdWxkIGFsbG93IGEgc2VydmVyIHRvIGVpdGhlciB1c2UgdGhpcyBtZWNo YW5pc20gb3IgbmVnb3RpYXRlIHN0YW5kYXJkIFRMUyAxLjMgKGFuZCB0aGUgY2xpZW50IHRvIGVh c2lseSB0ZWxsIHdoaWNoIG9uZSBpcyBpbiB1c2UpLjxicj4NCjxicj4NCldpdGggdGhlIHNtYWxs IGV4Y2VwdGlvbiBvZiBwb3RlbnRpYWxseSB1cGRhdGluZyB0aGUgaWRlbnRpZmllci0mZ3Q7a2V5 IG1hcHBpbmcsIHRoaXMgd291bGQgbm90IHJlcXVpcmUgYW55IFRMUyBsaWJyYXJ5IGNoYW5nZXMg KG9uY2UgaW1wbGVtZW50ZWQgaW4gdGhlIGZpcnN0IHBsYWNlKSwgYW5kIEkgYmVsaWV2ZSB3b3Vs ZCBzdGlsbCBwcm92aWRlIGFsbW9zdCBhbGwgb2YgdGhlIGJlbmVmaXRzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBUTFMgJmx0Ozxh IGhyZWY9Im1haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRscy1i b3VuY2VzQGlldGYub3JnPC9hPiZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+RGF2aWQgQmVuamFt aW48YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVuZSAxMiwgMjAxOCAxMjoyOCBQTTxicj4N CjxiPlRvOjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzp0bHNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj50bHNAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRsc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnRsc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFtUTFNdIEVuZm9yY2luZyBQcm90b2NvbCBJbnZhcmlhbnRzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5IaSBhbGwsPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk5vdyB0aGF0IFRMUyAxLjMgaXMgYWJvdXQgZG9uZSwgcGVyaGFwcyBpdCBpcyB0aW1l IHRvIHJlZmxlY3Qgb24gdGhlIG9zc2lmaWNhdGlvbiBwcm9ibGVtcy48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VExTIGlzIGFuIGV4dGVuc2libGUgcHJvdG9j b2wuIFRMUyAxLjMgaXMgYmFja3dhcmRzLWNvbXBhdGlibGUgYW5kIG1heSBiZSBpbmNyZW1lbnRh bGx5IHJvbGxlZCBvdXQgaW4gYW4gZXhpc3RpbmcgY29tcGxpYW50IFRMUyAxLjIgZGVwbG95bWVu dC4gWWV0IHdlIGhhZCBwcm9ibGVtcy4gV2lkZXNwcmVhZCBub24tY29tcGxpYW50IHNlcnZlcnMg YnJva2Ugb24gdGhlIFRMUyAxLjMgQ2xpZW50SGVsbG8sIHNvIHZlcnNpb25pbmcNCiBtb3ZlZCB0 byBzdXBwb3J0ZWRfdmVyc2lvbnMuIFdpZGVzcHJlYWQgbm9uLWNvbXBsaWFudCBtaWRkbGVib3hl cyBhdHRlbXB0ZWQgdG8gcGFyc2Ugc29tZW9uZSBlbHNl4oCZcyBTZXJ2ZXJIZWxsb3MsIHNvIHRo ZSBwcm90b2NvbCB3YXMgZnVydGhlciBoYWNrZWQgdG8gd2VhdmUgdGhyb3VnaCB0aGVpciBtYW55 IGRlZmVjdHMuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg dGhpbmsgSSBjYW4gc3BlYWsgZm9yIHRoZSB3b3JraW5nIGdyb3VwIHRoYXQgd2UgZG8gbm90IHdh bnQgdG8gcmVwZWF0IHRoaXMgYWR2ZW50dXJlIGFnYWluLiBJbiBnZW5lcmFsLCBJIHRoaW5rIHRo ZSByZXNwb25zZSB0byBvc3NpZmljYXRpb24gaXMgdHdvLWZvbGQ6PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuIEl04oCZcyBhbHJlYWR5IGhhcHBlbmVkLCBz byBob3cgZG8gd2UgcHJvZ3Jlc3MgdG9kYXk/PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBIb3cgZG8g d2UgYXZvaWQgbW9yZSBvZiB0aGlzIHRvbW9ycm93PzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgd29ya2Fyb3VuZHMgb25seSBhbnN3ZXIgdGhlIGZpcnN0 IHF1ZXN0aW9uLiBGb3IgdGhlIHNlY29uZCwgVExTIDEuMyBoYXMgYSBzZWN0aW9uIHdoaWNoIHNw ZWxscyBvdXQgYSBmZXcNCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fdGxzd2cuZ2l0aHViLmlvX3RsczEzLTJEc3BlY19kcmFmdC0y RGlldGYtMkR0bHMtMkR0bHMxMy5odG1sLTIzcmZjLnNlY3Rpb24uOS4zJmFtcDtkPUR3TUZhUSZh bXA7Yz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JmFtcDtyPWwyajRCamtPMExjM3U0Q0gyejdqUHcm YW1wO209U2FXcGxreGtidjlPX1o3MUhkRTZMNzF2dTJmN292V1dhRVFyUFJSYnl3YyZhbXA7cz1G N0lKOU5hYzVPZl9HQ3ZCVmswX1FoVHBsQ0pqb2JvQlNlbUhsMHBpMW9NJmFtcDtlPSIgdGFyZ2V0 PSJfYmxhbmsiPg0KcHJvdG9jb2wgaW52YXJpYW50czwvYT4uIEl0IGlzIGFsbCBjb3JvbGxhcmll cyBvZiBleGlzdGluZyBUTFMgc3BlY2lmaWNhdGlvbiB0ZXh0LCBidXQgaG9wZWZ1bGx5IGRvY3Vt ZW50aW5nIGl0IGV4cGxpY2l0bHkgd2lsbCBoZWxwLiBCdXQgZXhwZXJpZW5jZSBoYXMgc2hvd24g c3BlY2lmaWNhdGlvbiB0ZXh0IGlzIG9ubHkgbmVjZXNzYXJ5LCBub3Qgc3VmZmljaWVudC48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGV4dGVuc2liaWxp dHkgcHJvYmxlbXMgaW4gc2VydmVycywgd2UgaGF2ZSA8YSBocmVmPSJodHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxf ZHJhZnQtMkRpZXRmLTJEdGxzLTJEZ3JlYXNlLTJEMDEmYW1wO2Q9RHdNRmFRJmFtcDtjPTVWRDBS VHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9bDJqNEJqa08wTGMzdTRDSDJ6N2pQdyZhbXA7bT1TYVdw bGt4a2J2OU9fWjcxSGRFNkw3MXZ1MmY3b3ZXV2FFUXJQUlJieXdjJmFtcDtzPXRjQWx1MmZFZmtL ak0ybDRXQkNDUm9zT0dWM0RNQVFjSHZoOFBlMzhLNXcmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+ DQpHUkVBU0U8L2E+LiBUaGlzIGVuZm9yY2VzIHRoZSBrZXkgcnVsZSBpbiBDbGllbnRIZWxsbyBw cm9jZXNzaW5nOiBpZ25vcmUgdW5yZWNvZ25pemVkIHBhcmFtZXRlcnMuIEdSRUFTRSBlbmZvcmNl cyB0aGlzIGJ5IGZpbGxpbmcgdGhlIGVjb3N5c3RlbSB3aXRoIHRoZW0uIFRMUyAxLjPigJlzIG1p ZGRsZWJveCB3b2VzIHdlcmUgZGlmZmVyZW50LiBUaGUga2V5IHJ1bGUgaXM6IGlmIHlvdSBkaWQg bm90IHByb2R1Y2UgYSBDbGllbnRIZWxsbywgeW91IGNhbm5vdA0KIGFzc3VtZSB0aGF0IHlvdSBj YW4gcGFyc2UgdGhlIHJlc3BvbnNlLiBBbmFsb2dvdXNseSwgd2Ugc2hvdWxkIGZpbGwgdGhlIGVj b3N5c3RlbSB3aXRoIHN1Y2ggcmVzcG9uc2VzLiBXZSBoYXZlIGFuIGlkZWEsIGJ1dCBpdCBpcyBt b3JlIGludm9sdmVkIHRoYW4gR1JFQVNFLCBzbyB3ZSBhcmUgdmVyeSBpbnRlcmVzdGVkIGluIHRo ZSBUTFMgY29tbXVuaXR54oCZcyBmZWVkYmFjay48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SW4gc2hvcnQsIHdlIHBsYW4gdG8gcmVndWxhcmx5IG1pbnQgbmV3 IFRMUyB2ZXJzaW9ucyAoYW5kIGxpa2VseSBvdGhlciBzZW5zaXRpdmUgcGFyYW1ldGVycyBzdWNo IGFzIGV4dGVuc2lvbnMpLCByb3VnaGx5IGV2ZXJ5IHNpeCB3ZWVrcyBtYXRjaGluZyBDaHJvbWXi gJlzIHJlbGVhc2UgY3ljbGUuIENocm9tZSwgR29vZ2xlIHNlcnZlcnMsIGFuZCBhbnkgb3RoZXIg ZGVwbG95bWVudCB0aGF0IHdpc2hlcyB0byBwYXJ0aWNpcGF0ZSwNCiB3b3VsZCBzdXBwb3J0IHR3 byAob3IgbW9yZSkgdmVyc2lvbnMgb2YgVExTIDEuMzogdGhlIHN0YW5kYXJkIHN0YWJsZSAweDAz MDQsIGFuZCBhIHJvbGxpbmcgYWx0ZXJuYXRlIHZlcnNpb24uIEV2ZXJ5IHNpeCB3ZWVrcywgd2Ug d291bGQgcmFuZG9tbHkgcGljayBhIG5ldyBjb2RlIHBvaW50LiBUaGVzZSB2ZXJzaW9ucyB3aWxs IG90aGVyd2lzZSBiZSBpZGVudGljYWwgdG8gVExTIDEuMywgc2F2ZSBtYXliZSBtaW5vciBkZXRh aWxzIHRvIHNlcGFyYXRlDQoga2V5cyBhbmQgZXhlcmNpc2UgYWxsb3dlZCBzeW50YXggY2hhbmdl cy4gVGhlIGdvYWwgaXMgdG8gcGF2ZSB0aGUgd2F5IGZvciBmdXR1cmUgdmVyc2lvbnMgb2YgVExT IGJ5IHNpbXVsYXRpbmcgdGhlbSAo4oCcZHJhZnQgbmVnYXRpdmUgb25l4oCdKS48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T2YgY291cnNlLCB0aGlzIHNjaGVt ZSBoYXMgc29tZSByaXNrLiBJdCBncmFicyBjb2RlIHBvaW50cyBldmVyeXdoZXJlLiBDb2RlIHBv aW50cyBhcmUgcGxlbnRpZnVsLCBidXQgd2UgZG8gc29tZXRpbWVzIGhhdmUgY29sbGlzaW9ucyAo ZS5nLiAyNiBhbmQgNDApLiBUaGUgZW50aXJlIHBvaW50IGlzIHRvIHNlcnZlIGFuZCBtYWludGFp biBUTFPigJlzIGV4dGVuc2liaWxpdHksIHNvIHdlIGNlcnRhaW5seSBkbyBub3QNCiB3aXNoIHRv IGhhbXBlciBpdCEgVGh1cyB3ZSBoYXZlIHNvbWUgc2FmZWd1YXJkcyBpbiBtaW5kOjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIFdlIHdpbGwgZG9jdW1lbnQg ZXZlcnkgY29kZSBwb2ludCB3ZSB1c2UgYW5kIHdoYXQgaXQgcmVmZXJzIHRvLiAoSWYgdGhlIHZv bHVtZSBpcyBmaW5lLCB3ZSBjYW4gZW1haWwgdGhlbSB0byB0aGUgbGlzdCBlYWNoIHRpbWUuKSBO ZXcgYWxsb2NhdGlvbnMgY2FuIGFsd2F5cyBhdm9pZCB0aGUgbG9zdCBudW1iZXJzLiBBdCBhIHJh dGUgb2Ygb25lIGV2ZXJ5IDYgd2Vla3MsIGl0IHdpbGwgdGFrZSBvdmVyIDcsMDAwDQogeWVhcnMg dG8gZXhoYXVzdCBldmVyeXRoaW5nLjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4qIFdlIHdpbGwgYXZvaWQgcGlja2luZyBudW1iZXJzIHRoYXQgdGhlIElFVEYg aXMgbGlrZWx5IHRvIGFsbG9jYXRlLCB0byByZWR1Y2UgdGhlIGNoYW5jZSBvZiBjb2xsaXNpb24u IFJvbGxpbmcgdmVyc2lvbnMgd2lsbCBub3Qgc3RhcnQgd2l0aCAweDAzLCByb2xsaW5nIGNpcGhl ciBzdWl0ZXMgb3IgZXh0ZW5zaW9ucyB3aWxsIG5vdCBiZSBjb250aWd1b3VzIHdpdGggZXhpc3Rp bmcgYmxvY2tzLCBldGMuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiogQm9yaW5nU1NMIHdpbGwgbm90IGVuYWJsZSB0aGlzIGJ5IGRlZmF1bHQuIFdlIHdpbGwg b25seSBlbmFibGUgaXQgd2hlcmUgd2UgY2FuIHNodXQgaXQgYmFjayBvZmYuIE9uIG91ciBzZXJ2 ZXJzLCB3ZSBvZiBjb3Vyc2UgcmVndWxhcmx5IGRlcGxveSBjaGFuZ2VzLiBDaHJvbWUgaXMgYWxz byByZWd1bGFybHkgdXBkYXRlZCBhbmQsIG1vcmVvdmVyLCB3ZSB3aWxsIGdhdGUgaXQgb24gb3Vy IHNlcnZlci1jb250cm9sbGVkDQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3RleHRzbGFzaHBsYWluLmNvbV8yMDE3XzEwXzE4X2No cm9tZS0yRGZpZWxkLTJEdHJpYWxzXyZhbXA7ZD1Ed01GYVEmYW1wO2M9NVZEMFJUdE5sVGgzeWNk NDFiM01VdyZhbXA7cj1sMmo0QmprTzBMYzN1NENIMno3alB3JmFtcDttPVNhV3Bsa3hrYnY5T19a NzFIZEU2TDcxdnUyZjdvdldXYUVRclBSUmJ5d2MmYW1wO3M9b3dDSmJYczFCem5UTGRzaG9aWkEx aG9fZzl3X20yN1BsZld1dDNkTVJwTSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmZpZWxkIHRy aWFsczwvYT4gbWVjaGFuaXNtLiBXZSBob3BlIHRoYXQsIGluIHByYWN0aWNlLCBvbmx5IHRoZSBs YXN0IHNldmVyYWwgY29kZSBwb2ludHMgd2lsbCBiZSBpbiB1c2UgYXQgYSB0aW1lLjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qJm5ic3A7T3VyIGNsaWVudHMg d291bGQgb25seSBzdXBwb3J0IHRoZSBtb3N0IHJlY2VudCBzZXQgb2Ygcm9sbGluZyBwYXJhbWV0 ZXJzLCBhbmQgb3VyIHNlcnZlcnMgdGhlIGxhc3QgaGFuZGZ1bC4gQXMgZWFjaCB2YWx1ZSB3aWxs IGJlIHNob3J0LWxpdmVkLCB0aGUgZWNvc3lzdGVtIGlzIHVubGlrZWx5IHRvIHJlbHkgb24gdGhl bSBhcyBkZSBmYWN0byBzdGFuZGFyZHMuIENvbnZlcnNlbHksIGxpa2Ugb3RoZXIgZXh0ZW5zaW9u cywNCiBpbXBsZW1lbnRhdGlvbnMgd2l0aG91dCB0aGVtIHdpbGwgc3RpbGwgaW50ZXJvcGVyYXRl IGZpbmUuIFdlIHdvdWxkIG5ldmVyIG9mZmVyIGEgcm9sbGluZyBwYXJhbWV0ZXIgd2l0aG91dCB0 aGUgY29ycmVzcG9uZGluZyBzdGFibGUgb25lLjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4qJm5ic3A7SWYgdGhpcyB1bHRpbWF0ZWx5IGRvZXMgbm90IHdvcmss IHdlIGNhbiBzdG9wIGF0IGFueSB0aW1lIGFuZCBvbmx5IGhhdmUgd2FzdGVkIGEgc21hbGwgcG9y dGlvbiBvZiBjb2RlIHBvaW50cy48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+KiBGaW5hbGx5LCBpZiB0aGUgd29ya2luZyBncm91cCBpcyBvcGVuIHRvIGl0LCB0 aGVzZSB2YWx1ZXMgY291bGQgYmUgc3VtbWFyaXplZCBpbiByZWd1bGFyIGRvY3VtZW50cyB0byBy ZXNlcnZlIHRoZW0sIHNvIHRoYXQgdGhleSBhcmUgdWx0aW1hdGVseSByZWZsZWN0ZWQgaW4gdGhl IHJlZ2lzdHJpZXMuIEEgbmV3IGRvY3VtZW50IGV2ZXJ5IHNpeCB3ZWVrcyBpcyBwcm9iYWJseSBp bXByYWN0aWNhbCwgYnV0IHdlDQogY2FuIGJhdGNoIHRoZW0gdXAuPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGFyZSBpbnRlcmVzdGVkIGluIHRoZSBjb21t dW5pdHnigJlzIGZlZWRiYWNrIG9uIHRoaXMgcHJvcG9zYWzigJRhbnlvbmUgd2hvIG1pZ2h0IHBh cnRpY2lwYXRlLCBiZXR0ZXIgc2FmZWd1YXJkcywgb3IgdGhvdWdodHMgb24gdGhlIG1lY2hhbmlz bSBhcyBhIHdob2xlLiBXZSBob3BlIGl0IHdpbGwgaGVscCB0aGUgd29ya2luZyBncm91cCBldm9s dmUgaXRzIHByb3RvY29scyBtb3JlIHNtb290aGx5IGluIHRoZSBmdXR1cmUuPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhdmlkPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NClRMUyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86VExTQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+VExTQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fdGxzJmFtcDtkPUR3TUZhUSZhbXA7 Yz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JmFtcDtyPWwyajRCamtPMExjM3U0Q0gyejdqUHcmYW1w O209QTBmeXhXNXJtVGN2Yk1pVHA5c3BIOTVCSW9aVl9rek4zYTVXREZJZU9NYyZhbXA7cz0tVzBQ UlRRdkZWYkNHcm1PMThfbEhjU2ZaX0FkTllWakF5b1BOaEdwendBJmFtcDtlPSIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_MWHPR15MB15049038BE121821DC4E399AAF7D0MWHPR15MB1504namp_-- From nobody Thu Jun 14 12:46:45 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DAF130EE0 for ; Thu, 14 Jun 2018 12:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIxR9tMsyBbn for ; Thu, 14 Jun 2018 12:46:41 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 73376130E79 for ; Thu, 14 Jun 2018 12:46:41 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id i18-v6so6953546qtp.12 for ; Thu, 14 Jun 2018 12:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=3NJ7UQsEUIj4YqLWqhT4JHYh34BlcQvA53TFyVnPv94=; b=OD1z+OIXIdgdeKYgWEbxzGj08O2kSugAJM8/hxsgUwvmBVnpd7tKHNtVe0lTycJTW5 Uxi6019Kx14IVntCspem/bgIU76/8ubw2wUTdijpf8/bvEiB/mw5DaTxbm0ONsExGFxL VAuArw2L0W0Jmc2Ex9Ho2AjZclYaG3c5lU62k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=3NJ7UQsEUIj4YqLWqhT4JHYh34BlcQvA53TFyVnPv94=; b=hTAOt8NiT9uCQzofsfb+5ISbX0LX55JychBa9dWaLoq7IYpTefivJw2kq4LwBkdwuZ 9Kt2cD6yW35CTsW2QhImu1fAKK27tjrgFAjZ5w7dMGDV1X2GFKus/sLDyyf/QsxQs7Ok FwAT5xn27l78BmSNqDEtH7Z7s458PP93uO7RAR6i1ifAsSa5eO+hFU7liGS1fswZig8G Jkfptb2tC3PEsE0YRsw+1XzRujyvUdnBBNnNy4wrSLhZ1TPgo4Hhkb1GHyRzbtA5Xe6a eZbzdI33A9PRYBAtE9v/UxyiRmmfwlyAS1GW14zpHpbESlx0w3sirQi1LwcWG7kIdFS5 wx8A== X-Gm-Message-State: APt69E0COifeaKiWQed2y66ZjFg7pG6ozN6XJkn2ikhdTgWYxUJIqfo3 cMFBl+fmM032fb4g5rrcuHSIOmWC5wsyCMi2xCe9p84= X-Google-Smtp-Source: ADUXVKKBCDMADyH9Osyk4DbdaNsTNgPRzUH94k6JYG8Rb3ImWPpMAgKx/oKpkZa5uJuU72wpowk1Rp2G6peykaQ7cds= X-Received: by 2002:a0c:8ab1:: with SMTP id 46-v6mr3707744qvv.147.1529005600035; Thu, 14 Jun 2018 12:46:40 -0700 (PDT) MIME-Version: 1.0 From: David Benjamin Date: Thu, 14 Jun 2018 15:46:27 -0400 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000a6ef7e056e9f5b38" Archived-At: Subject: [TLS] Universal PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2018 19:46:44 -0000 --000000000000a6ef7e056e9f5b38 Content-Type: text/plain; charset="UTF-8" Hey all, So TLS 1.2 has a mechanism for PSKs. We attempted to mirror it in TLS 1.3 via the external PSK mechanism, repurposing the resumption flow. But the security proof requires PSKs be associated with a specific hash for key separation. We use distinguishing labels in the key schedule, but if that key is fed into a completely different KDF, analysis must additionally consider interactions between the KDFs. The hash constraint, however, makes it difficult to actually use external PSKs in applications. Usually the TLS stack and its configuration evolves somewhat independently from the calling application. But now the PSK provisioning process must short-circuit part of the TLS parameter negotiation, despite it likely being implemented in a separate library altogether. This is a leaky abstraction. It also complicates server parameter selection. We've found the cleanest algorithm is selecting the cipher suite first, and then ignoring the PSKs that don't match. This is simple and avoids weird behavior if a session is renewed across preference changes. However, this only works for resumption PSK: if the session mismatches, a full handshake is always an option. With external PSKs, the application usually expects the PSK to be mandatory. Finally, some libraries (e.g. OpenSSL) already TLS 1.2 PSK APIs and wish to transparently upgrade to TLS 1.3. The specification does not explicitly say if a TLS 1.2 PSK may be used directly as a TLS 1.3 PSK and I believe some implementations are doing that. However that violates TLS 1.3's key separation assumptions in the same way as mixing hashes: the TLS 1.2 PRF is not the same as HKDF. It's a bit late to completely redo external PSKs in 1.3, but I believe we can fix this in a separate draft. The draft below proposes "universal PSKs" which derive independent hash- and version-specific secrets for TLS 1.3 (and later) as needed. For existing TLS 1.2 PSKs, it includes a compatibility derivation to go from TLS 1.2 PSKs to universal PSKs. (Thanks to Karthikeyan Bhargavan, Matt Caswell, Eric Rescorla, and Victor Vasiliev for discussions which led to this design. Any mistakes in it are mine.) Thoughts? If the WG likes this design, I would suggest: - Most folks who want to use TLS 1.3 with external PSKs should probably design their protocols to provision universal PSKs instead, after it stabilizes. - Folks who want to use TLS 1.3 with existing TLS 1.2 PSKs should use the compatibility derivation in this draft, after it stabilizes. - Folks who want to ship TLS 1.3 before then and have a TLS 1.2 PSK API should not use the 1.2 PSK as a 1.3 PSK. For now, just turn TLS 1.3 off by default if that API is used and, in a future release, use the compatibility derivation after it stabilizes. - If it's not too late to clarify whether TLS 1.3 believes whether PSKs are version-specific, it would be good to do that. David PS: Looking over the draft now, I see I mixed up some of the RFC 4279 and RFC 5246 citations. I'll fixed that in the next iteration. ---------- Forwarded message --------- From: Date: Thu, Jun 14, 2018 at 3:21 PM Subject: New Version Notification for draft-davidben-tls-universal-psk-00.txt To: David Benjamin A new version of I-D, draft-davidben-tls-universal-psk-00.txt has been successfully submitted by David Benjamin and posted to the IETF repository. Name: draft-davidben-tls-universal-psk Revision: 00 Title: Universal PSKs for TLS Document date: 2018-06-14 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-davidben-tls-universal-psk-00.txt Status: https://datatracker.ietf.org/doc/draft-davidben-tls-universal-psk/ Htmlized: https://tools.ietf.org/html/draft-davidben-tls-universal-psk-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-davidben-tls-universal-psk Abstract: This document describes universal PSKs (Pre-Shared Keys) for TLS. Universal PSKs abstract the TLS 1.3 requirement that each PSK can only be used with a single hash function. This allows PSKs to be provisioned without depending on details of the TLS negotiation, which may change as TLS evolves. Additionally, this document describes a compatibility profile for using TLS 1.3 with PSKs provisioned for the TLS 1.2 PSK mechanism. 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 --000000000000a6ef7e056e9f5b38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

So TLS 1.2 has a me= chanism for PSKs. We attempted to mirror it in TLS 1.3 via the external PSK= mechanism, repurposing the resumption flow. But the security proof require= s PSKs be associated with a specific hash for key separation. We use distin= guishing labels in the key schedule, but if that key is fed into a complete= ly different KDF, analysis must additionally consider interactions between = the KDFs.

The hash constraint, however, makes it d= ifficult to actually use external PSKs in applications. Usually the TLS sta= ck and its configuration evolves somewhat independently from the calling ap= plication. But now the PSK provisioning process must short-circuit part of = the TLS parameter negotiation, despite it likely being implemented in a sep= arate library altogether. This is a leaky abstraction.

=
It also complicates server parameter selection. We've found the cl= eanest algorithm is selecting the cipher suite first, and then ignoring the= PSKs that don't match. This is simple and avoids weird behavior if a s= ession is renewed across preference changes. However, this only works for r= esumption PSK: if the session mismatches, a full handshake is always an opt= ion. With external PSKs, the application usually expects the PSK to be mand= atory.

Finally, some libraries (e.g. OpenSSL) alre= ady TLS 1.2 PSK APIs and wish to transparently upgrade to TLS 1.3. The spec= ification does not explicitly say if a TLS 1.2 PSK may be used directly as = a TLS 1.3 PSK and I believe some implementations are doing that. However th= at violates TLS 1.3's key separation assumptions in the same way as mix= ing hashes: the TLS 1.2 PRF is not the same as HKDF.

It's a bit late to completely redo external PSKs in 1.3, but I belie= ve we can fix this in a separate draft. The draft below proposes "univ= ersal PSKs" which derive independent hash- and version-specific secret= s for TLS 1.3 (and later) as needed. For existing TLS 1.2 PSKs, it includes= a compatibility derivation to go from TLS 1.2 PSKs to universal PSKs.

(Thanks to Karthikeyan Bhargavan, Matt Caswell, Eric R= escorla, and Victor Vasiliev for discussions which led to this design. Any = mistakes in it are mine.)

Thoughts? If the WG like= s this design, I would suggest:

- Most folks who w= ant to use TLS 1.3 with external PSKs should probably design their protocol= s to provision universal PSKs instead, after it stabilizes.

<= /div>
- Folks who want to use TLS 1.3 with existing TLS 1.2 PSKs should= use the compatibility derivation in this draft, after it stabilizes.
=

- Folks who want to ship TLS 1.3 before then and have a= TLS 1.2 PSK API should not use the 1.2 PSK as a 1.3 PSK. For now, just tur= n TLS 1.3 off by default if that API is used and, in a future release, use = the compatibility derivation after it stabilizes.

= - If it's not too late to clarify whether TLS 1.3 believes whether PSKs= are version-specific, it would be good to do that.

David

PS: Looking over the draft now, I see I mi= xed up some of the RFC 4279 and RFC 5246 citations. I'll fixed that in = the next iteration.


---------- Forwarded message ---------
From: <internet-drafts@ietf= .org>
Date: Thu, Jun 14, 2018 at 3:21 PM
Subject: New Version = Notification for draft-davidben-tls-universal-psk-00.txt
To: David Benja= min <davidben@g= oogle.com>



A new version of I-D, draft-davidben-tls-universal-psk-00.txt
has been successfully submitted by David Benjamin and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-davidben-tls-universal-= psk
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Universal PSKs for TLS
Document date:=C2=A0 2018-06-14
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-davidben-t= ls-universal-psk-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-davidben-tls-universal-psk/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://tools.ietf.org/html/draft-davidben-tls-universal-psk-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-davidben-tls-universal-ps= k


Abstract:
=C2=A0 =C2=A0This document describes universal PSKs (Pre-Shared Keys) for T= LS.
=C2=A0 =C2=A0Universal PSKs abstract the TLS 1.3 requirement that each PSK = can
=C2=A0 =C2=A0only be used with a single hash function.=C2=A0 This allows PS= Ks to be
=C2=A0 =C2=A0provisioned without depending on details of the TLS negotiatio= n,
=C2=A0 =C2=A0which may change as TLS evolves.=C2=A0 Additionally, this docu= ment
=C2=A0 =C2=A0describes a compatibility profile for using TLS 1.3 with PSKs<= br> =C2=A0 =C2=A0provisioned for the TLS 1.2 PSK mechanism.




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

--000000000000a6ef7e056e9f5b38-- From nobody Fri Jun 15 04:14:21 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81195130DE8 for ; Fri, 15 Jun 2018 04:14:19 -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 autolearn_force=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 XFAhVgR62B0R for ; Fri, 15 Jun 2018 04:14:18 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190BE130DDD for ; Fri, 15 Jun 2018 04:14:18 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2368140122A1; Fri, 15 Jun 2018 11:14:17 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.34.246.36]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8195C2166BB2; Fri, 15 Jun 2018 11:14:16 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Fri, 15 Jun 2018 13:14:09 +0200 Message-ID: <2132206.KQKFhKinhY@pintsize.usersys.redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10927423.CvsMzcAbIB"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Fri, 15 Jun 2018 11:14:17 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Fri, 15 Jun 2018 11:14:17 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] Universal PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2018 11:14:20 -0000 --nextPart10927423.CvsMzcAbIB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 14 June 2018 21:46:27 CEST David Benjamin wrote: > Thoughts? If the WG likes this design, I would suggest: >=20 > - Most folks who want to use TLS 1.3 with external PSKs should probably > design their protocols to provision universal PSKs instead, after it > stabilizes. >=20 > - Folks who want to use TLS 1.3 with existing TLS 1.2 PSKs should use the > compatibility derivation in this draft, after it stabilizes. >=20 > - Folks who want to ship TLS 1.3 before then and have a TLS 1.2 PSK API > should not use the 1.2 PSK as a 1.3 PSK. For now, just turn TLS 1.3 off by > default if that API is used and, in a future release, use the compatibili= ty > derivation after it stabilizes. that's not workable. the reason why implementations chose to use old API to provision TLS 1.3 PS= Ks=20 was to make the upgrade process as smooth as possible, disabling TLS 1.3 is= =20 quite antithetical to that =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart10927423.CvsMzcAbIB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlsjn4EACgkQkqjRuAHS 9fUfxQ/+LYbR2TLHSeVesX6KZKxT8G8sUdLHi9UcyKSIriuHBAnhLd5vRdu2DcMX 8T2gXfJoHbbOv01aCp7vvj08nOLcOk4VUV3rbRRbcNGAz0Vm8dhCe3DbHdJQxRA5 8bm26aAl+X2KUbmPT9TZ7jq0IfhTv1x7Ld7nXt7VUq/bnOvL6s9+somOCiFtFcJP 28IMj9mtcn+MXex6W7qNaavy1V/CcARn/olZbtdWgOKYfy3dhOpr+El9HNKQCGo+ VugkUbhcaJx3Jv/W0jdhdS1ZV+0rqlTd4CrtZbxspuzBE64X5qvs293pT0XnEkMm H91IQeAyiN5qM+/HIlOFZt11gt6Bc/yiAy3e7+cZaYbM4Bgd5LUKgDStDkI8cGn8 haZN2dD3Ly7fwm4K6/uJgEENL9YO0+zV9hZssdRAC7kmr2A5pfbhfXV2zWr867QJ yWNC+hsmH9UREOO57HkrORbQ/stzDHQLe4PpVLKCbKVw3ddMAapgUboJnxCyBFpe XmJfH5RwoLVzaYosd9cDU9pVY13ULeOX8p+k7NnKz1bOSpW5LG3No+3H/ySESDkb 3GV2V7zdBhXQhr2u6GzSrntmNicnT0uQ1l6N/gwEgy4+VMpNUnMAuLYXpGm1+Jgi ErsaNwpPZco8jYBTDdYAXF8Pk/EKcdpZJh3+GIDfAGHpY7CbH6w= =Ivc2 -----END PGP SIGNATURE----- --nextPart10927423.CvsMzcAbIB-- From nobody Fri Jun 15 04:38:01 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415DD130DEA for ; Fri, 15 Jun 2018 04:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 RT2LzU5nVwh0 for ; Fri, 15 Jun 2018 04:37:57 -0700 (PDT) Received: from mail-wm0-f54.google.com (mail-wm0-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 99BB7120049 for ; Fri, 15 Jun 2018 04:37:56 -0700 (PDT) Received: by mail-wm0-f54.google.com with SMTP id j15-v6so3345613wme.0 for ; Fri, 15 Jun 2018 04:37:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=b0CcQbUh+vWZJW/VVSYiTUNAfRBqI5TyN1uAUXWWOWI=; b=ivQoY92Xjr11VIkoLXNm0dgINKp+nujDEaBACwcf+hfgIMPY2MNCz0R/DbywuoLRWb tEob7e11aKVMFuropLFR+U+Y9kawP/MxuWm1UmT+76FiT/VN261xkooWYzloYDgw6wHs P4tKonGBgUvUDU1bftVZShel/UCR4DUboiGI1IvtXb06IkVfqUORDQK8m8BS05Xv4tFl q03PU+uOejODv0gE+F1jDBgw7BYzorLJAbkN0obD8mtfDIYwihses4f5GZZrpF4chHtY bX6NpJeuSTq06HioLwytl0DeFG0WLzdFfKH0r2nsv8XJfL64HgLtivxKWvn+GTsFybeO zAAA== X-Gm-Message-State: APt69E0ohzm46nV9Bt4xSXE9Gk3pjws/C8CT8lw/tAvKBLzwwPj2k4s4 iKGMrvtSX5lDrAnuBp381gI61A== X-Google-Smtp-Source: ADUXVKJvRH2Fk6mW6BDwToZy805YlP0WcXpTJ/5nu65HZvwMnvM01Tfm8nvwYhWZuGuG3kABVtwJzA== X-Received: by 2002:a1c:d2cb:: with SMTP id j194-v6mr916457wmg.129.1529062675017; Fri, 15 Jun 2018 04:37:55 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id e2-v6sm9302747wro.97.2018.06.15.04.37.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 15 Jun 2018 04:37:54 -0700 (PDT) Message-ID: <7e5945f3c6bf9d8168a862f45bc00100cded1802.camel@redhat.com> From: Nikos Mavrogiannopoulos To: David Benjamin , "" Date: Fri, 15 Jun 2018 13:37:53 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.2 (3.28.2-1.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Universal PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2018 11:38:00 -0000 On Thu, 2018-06-14 at 15:46 -0400, David Benjamin wrote: > Hey all, > > So TLS 1.2 has a mechanism for PSKs. We attempted to mirror it in TLS > 1.3 via the external PSK mechanism, repurposing the resumption flow. > But the security proof requires PSKs be associated with a specific > hash for key separation. We use distinguishing labels in the key > schedule, but if that key is fed into a completely different KDF, > analysis must additionally consider interactions between the KDFs. > > The hash constraint, however, makes it difficult to actually use > external PSKs in applications. Usually the TLS stack and its > configuration evolves somewhat independently from the calling > application. But now the PSK provisioning process must short-circuit > part of the TLS parameter negotiation, despite it likely being > implemented in a separate library altogether. This is a leaky > abstraction. > > It also complicates server parameter selection. We've found the > cleanest algorithm is selecting the cipher suite first, and then > ignoring the PSKs that don't match. This is simple and avoids weird > behavior if a session is renewed across preference changes. However, > this only works for resumption PSK: if the session mismatches, a full > handshake is always an option. With external PSKs, the application > usually expects the PSK to be mandatory. > Finally, some libraries (e.g. OpenSSL) already TLS 1.2 PSK APIs and > wish to transparently upgrade to TLS 1.3. The specification does not > explicitly say if a TLS 1.2 PSK may be used directly as a TLS 1.3 PSK > and I believe some implementations are doing that. However that > violates TLS 1.3's key separation assumptions in the same way as > mixing hashes: the TLS 1.2 PRF is not the same as HKDF. I don't think that TLS1.3 has strict key separation assumptions, and they are nowhere spelled out. For example, RSA keys can be used for RSA-PSS or RSA PKCS#1 1.5 signatures or RSA encryption. > It's a bit late to completely redo external PSKs in 1.3, but I > believe we can fix this in a separate draft. The draft below proposes > "universal PSKs" which derive independent hash- and version-specific > secrets for TLS 1.3 (and later) as needed. For existing TLS 1.2 PSKs, > it includes a compatibility derivation to go from TLS 1.2 PSKs to > universal PSKs. > > (Thanks to Karthikeyan Bhargavan, Matt Caswell, Eric Rescorla, and > Victor Vasiliev for discussions which led to this design. Any > mistakes in it are mine.) > > Thoughts? It feels that's this is too little too late. Implementations which support PSKs will switch to TLS1.3 irrespective of this proposal. If this proposal takes on, we will have some implementations which support universal PSKs and others which don't leading to interoperability problems which we wouldn't have otherwise. regards, Nikos From nobody Fri Jun 15 05:00:42 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EE7130EFF for ; Fri, 15 Jun 2018 05:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=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 Z93fhWLXk0Q1 for ; Fri, 15 Jun 2018 05:00:28 -0700 (PDT) Received: from mta.openssl.org (xmpp.openssl.org [IPv6:2001:608:c00:180::1:e6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82A6130EEF for ; Fri, 15 Jun 2018 05:00:20 -0700 (PDT) Received: from [10.59.10.6] (ip-5-84-52-196.southampton.uk.amsterdamresidential.com [196.52.84.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta.openssl.org (Postfix) with ESMTPSA id 9ED44E073E for ; Fri, 15 Jun 2018 12:00:18 +0000 (UTC) To: tls@ietf.org References: <7e5945f3c6bf9d8168a862f45bc00100cded1802.camel@redhat.com> From: Matt Caswell Openpgp: preference=signencrypt Autocrypt: addr=matt@openssl.org; prefer-encrypt=mutual; keydata= xsBNBFGALsIBCADBkh6zfxbewW2KJjaMaishSrpxuiVaUyvWgpe6Moae7JNCW8ayhJbwAtsQ 69SGA4gUkyrR6PBvDMVYEiYqZwXB/3IErStESjcu+gkbmsa0XcwHpkE3iN7I8aU66yMt710n GEmcrR5E4u4NuNoHtnOBKEh+RCLGp5mo6hwbUYUzG3eUI/zi2hLApPpaATXnD3ZkhgtHV3ln 3Z16nUWQAdIVToxYhvVno2EQsqe8Q3ifl2Uf0YpaN19BDBrxM3WPOAKbJk0Ab1bjgEadavrF BCOl9CrbThewRGmkOdxJWaVkERXMShlzUzjJvKOUEUGOxJCmnfQimPQoCdQyVFLgHfRFABEB AAHNH01hdHQgQ2Fzd2VsbCA8bWF0dEBvcGVuc3NsLm9yZz7CwHgEEwECACIFAlPevrwCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJENnE0m0OYESRoD0H/1lEJXfr66rdvskyOi0z U0ARvUXHjbmmYkZ7ETkdXh7Va/Tjn81T3pwmr3F4IcLGNLDz4Eg67xbq/T8rrsEPOx5nV/mR nUT97UmsQuLnR2wLGbRBu24FKM7oX3KQvgIdJWdxHHJsjpGCViE1mIFARAzlN+6p3tPbnQzA NjRy7i/PYU/niGdqVcMhcnZCX5F7YH6w6t0ZmYH3m1QeREnWqfxu7eyHsIvebMgKTI/bMG8Z 7KlLZha9HwrFXQAPIST6sfc1blKJ9INUDM9iK6DR/ulkw7e0hmHLqjWqYs5PzyXeoNnsPXJt 69wiADYqj4KNDIdNp1RoF9qfb1nE+DM6rgbOwE0EUYAuwgEIAM9nUJAEpsVBYwK92PP9Mlo1 /etXp6JgBI68sOCJxTwzBrbTzIlevVQXqW9zdODD6ObKcgGNuG+G6Nwn54P6McRpd2dxor9Y A+yaI0yT6CVnhxsXjwc/vuQ4tBAL6tfuMAXRVIeEVk22cKk4HJB68ImXCCRdyRi9HIE5iTrZ HsHC4sjAsirhlc0o8hU3gqkKh2Ehwa6+U8lzNx06hoFEZxIVRteoz1jzCHImF7EXztEcDIam O8uckVKAuKbJgFGkU3bkvNgWlc8Pgx4tRUNJGC1LE4nYqaSEwee1SpA/VewiDObj97PozCTF zRCUBCnSvaAlTnpA90TnODH7ar+L5aEAEQEAAcLAXwQYAQIACQUCUYAuwgIbDAAKCRDZxNJt DmBEkQs2B/96XB9hyFpX/bhu41YNr7nSA65dDi9d+PkMqvLppickG3VR4xXWywzEJTw6W2DN MyFO6mOtdXWgNdgDF7HKZYvHBr6pyttLAMP7BfWBvU7YY59uKmUSc5vl0NzsaSbx5PDSQEkS ICLI+/hIwuEXOb6Z7gOrX7F1uy83TmHFOOjD2mLl5isUzFhaLVk0fZSY+mCgg3/inbwb8g31 91Ybk2LfXmndaEsdEzMLrT0g6wIgmybz6UdVuVPfSPGly0VWVAG1sNPOCpAuJpNV6+VxrdVi Ax3vQPbx3XzqDFS1ISlnd0qS/7RXwMuFDpVH/BDvzQcoikWnpRY/loPGkSg4TB7a Message-ID: Date: Fri, 15 Jun 2018 13:00:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <7e5945f3c6bf9d8168a862f45bc00100cded1802.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Universal PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2018 12:00:41 -0000 On 15/06/18 12:37, Nikos Mavrogiannopoulos wrote: > It feels that's this is too little too late. Implementations which > support PSKs will switch to TLS1.3 irrespective of this proposal. If > this proposal takes on, we will have some implementations which support > universal PSKs and others which don't leading to interoperability > problems which we wouldn't have otherwise. I'm not sure how many TLS1.3 implementations there are out there that also have TLS1.2 PSK support. OpenSSL is one of them. We have APIs for TLS1.2 PSKs and different APIs for TLS1.3 PSKs. Currently applications using the old APIs can still expect those PSKs to work in TLS1.3. In light of this proposal we are considering removing our TLS1.2 -> TLS1.3 PSK code and instead restricting applications using TLS1.2 PSK APIs to only TLS1.2 until this is resolved (although unfortunately that would mean removing it from our upcoming LTS release). Matt From nobody Fri Jun 15 06:12:05 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8293B130E73 for ; Fri, 15 Jun 2018 06:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.951 X-Spam-Level: X-Spam-Status: No, score=-9.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uj9HQBeFlrMa for ; Fri, 15 Jun 2018 06:12:01 -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 6EB571292F1 for ; Fri, 15 Jun 2018 06:12:01 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id j12-v6so5546094qkk.4 for ; Fri, 15 Jun 2018 06:12:01 -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 :cc; bh=wbnBbXzTse25OgP1aU0Tz4KPX5se0zCuv/NUZzBX0HU=; b=C2xx84+HLvXklmtGjlfjXZkCkL16uf9+6n57pBrdOASmCaI3VjBEOMREd3jJJqTI89 wOBRiPrITvENQunloBM3UtKiOIV4WuKxEh9TCXesbFOdDnf9bgYwIm8p8U4WGLX7Hd67 5ld+IgLs3Ks9cozXtxNEPFxkJVf2CznPGjp0Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wbnBbXzTse25OgP1aU0Tz4KPX5se0zCuv/NUZzBX0HU=; b=qg0Bv765t5XnoPHyCte1V158SWUPGYfKjzjAH8YUCe/AId2m0LKd8qjab/Zzt2lSsC 13YDs1oP7IczQHjjqVPaGq2+LRFp5EYnx5fDuZXBvrUNmZFA9lLt0AF2lFtCE2hAXlB/ phElMUhA6mAyAnFigxmI/95+54M27J7SGCGDo/IgD7BlhnS5mKdfY6e5EDA885/i3q/A 2pP4W8qHhw35vtks/27flFfJOh/gQzTZuB0VB/E6rnVZM92naFygOgqfYuVtKRiWH2AO miKyWjL/gwPNY26K7RiekFcHNl3Thvv4w+tO4JCYIaIKTT0zhPw+jQVtPxzRS1r6okE1 cGTg== X-Gm-Message-State: APt69E00DXYibraWAnSZRi6LCkNkQK+es13QMRbAVbyTbqRwkoEvewq7 0WbkqyUGWtDtWCgqH55XDkuYAXZ65U1VzS/SOP75 X-Google-Smtp-Source: ADUXVKIK/v1aoJRD9DQXfxkoSXU6KbPtsoD18M3Z7OvAzahtTJhkzxGwmtBR7k4/vDw7s/JuSCGuprzzvtkNG/pQTtk= X-Received: by 2002:a37:285e:: with SMTP id o91-v6mr1216566qkh.129.1529068320356; Fri, 15 Jun 2018 06:12:00 -0700 (PDT) MIME-Version: 1.0 References: <2132206.KQKFhKinhY@pintsize.usersys.redhat.com> In-Reply-To: <2132206.KQKFhKinhY@pintsize.usersys.redhat.com> From: David Benjamin Date: Fri, 15 Jun 2018 09:11:48 -0400 Message-ID: To: Hubert Kario Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="00000000000013080a056eadf637" Archived-At: Subject: Re: [TLS] Universal PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2018 13:12:04 -0000 --00000000000013080a056eadf637 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 15, 2018 at 7:14 AM Hubert Kario wrote: > On Thursday, 14 June 2018 21:46:27 CEST David Benjamin wrote: > > Thoughts? If the WG likes this design, I would suggest: > > > > - Most folks who want to use TLS 1.3 with external PSKs should probably > > design their protocols to provision universal PSKs instead, after it > > stabilizes. > > > > - Folks who want to use TLS 1.3 with existing TLS 1.2 PSKs should use the > > compatibility derivation in this draft, after it stabilizes. > > > > - Folks who want to ship TLS 1.3 before then and have a TLS 1.2 PSK API > > should not use the 1.2 PSK as a 1.3 PSK. For now, just turn TLS 1.3 off > by > > default if that API is used and, in a future release, use the > compatibility > > derivation after it stabilizes. > > that's not workable. > > the reason why implementations chose to use old API to provision TLS 1.3 > PSKs > was to make the upgrade process as smooth as possible, disabling TLS 1.3 > is > quite antithetical to that > Indeed. That is why the TLS 1.2 compatibility section exists. :-) So that implementations in that position can reuse TLS 1.2 PSK APIs in TLS 1.3 while honoring the security proof. But, unfortunately, there's a slight timing issue. There's no way some random draft published yesterday will be finalized before TLS 1.3. So implementations with TLS 1.2 PSK APIs would need to either violate the TLS 1.3 security proof or not ship TLS 1.3 until this draft finalizes. Neither seems great, so turning TLS 1.3 for PSK users in the initial TLS 1.3 implementation releases seems a reasonable stopgap approach, until the solution for this issue is finalized, at which point a latter release can enable TLS 1.3 across the board. David --00000000000013080a056eadf637 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jun 15= , 2018 at 7:14 AM Hubert Kario <hka= rio@redhat.com> wrote:
On Th= ursday, 14 June 2018 21:46:27 CEST David Benjamin wrote:
> Thoughts? If the WG likes this design, I would suggest:
>
> - Most folks who want to use TLS 1.3 with external PSKs should probabl= y
> design their protocols to provision universal PSKs instead, after it > stabilizes.
>
> - Folks who want to use TLS 1.3 with existing TLS 1.2 PSKs should use = the
> compatibility derivation in this draft, after it stabilizes.
>
> - Folks who want to ship TLS 1.3 before then and have a TLS 1.2 PSK AP= I
> should not use the 1.2 PSK as a 1.3 PSK. For now, just turn TLS 1.3 of= f by
> default if that API is used and, in a future release, use the compatib= ility
> derivation after it stabilizes.

that's not workable.

the reason why implementations chose to use old API to provision TLS 1.3 PS= Ks
was to make the upgrade process as smooth as possible, disabling TLS 1.3 is=
quite antithetical to that

Indeed. That= is why the TLS 1.2 compatibility section exists. :-) So that implementatio= ns in that position can reuse TLS 1.2 PSK APIs in TLS 1.3 while honoring th= e security proof.

But, unfortunately, there's = a slight timing issue. There's no way some random draft published yeste= rday will be finalized before TLS 1.3. So implementations with TLS 1.2 PSK = APIs would need to either violate the TLS 1.3 security proof or not ship TL= S 1.3 until this draft finalizes.

Neither seems gr= eat, so turning TLS 1.3 for PSK users in the initial TLS 1.3 implementation= releases seems a reasonable stopgap approach, until the solution for this = issue is finalized, at which point a latter release can enable TLS 1.3 acro= ss the board.

David
--00000000000013080a056eadf637-- From nobody Fri Jun 15 07:25:06 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25BE130EEF for ; Fri, 15 Jun 2018 07:25:04 -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_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvaid1wgXvZb for ; Fri, 15 Jun 2018 07:25:03 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 2B9CA130ED9 for ; Fri, 15 Jun 2018 07:25:02 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w5FEM6VX026833; Fri, 15 Jun 2018 15:25:01 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=MUBwwICl1N77+pgVPZ0R0RDaHzjcQ0wXFyYPnpUtL5g=; b=CNclfr/N2PcIDyVyrTSURseNVpdjF9JlVxtmu/va4/l0pIcaJ6rOC1BBosAoXQXQjtlZ yA7wz/VDo5k31FiRl1OyGeox9K3Ot44DvC9WsufLYcAo2SgJ5+0qehSHO5hBLZTFx0Kg n7QQnzk5fvS2wknS2jbF0yVQqM7RCHA64+bf6ZcYOO2kNGvTy5ecqwBl/ITWg8CBaxz1 UhIx2LliDnIqxGobA4BagW0J3peqD8mBS34KuaG4yf1g4KKsgZ2GSao6tcx9jTDiC/bD 2rO8vI3EN50ZGR94rGFgU/X2UVpfjPBA7/wsk/y3JtzCsRXLwzf112ivLVpG3Asbehlj FA== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2jmc2f8fry-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Jun 2018 15:25:01 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5FEKlJ9026183; Fri, 15 Jun 2018 10:25:00 -0400 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint3.akamai.com with ESMTP id 2jjp74sxes-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 15 Jun 2018 10:24:59 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 15 Jun 2018 09:24:58 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Fri, 15 Jun 2018 09:24:59 -0500 From: "Salz, Rich" To: Hubert Kario , "tls@ietf.org" Thread-Topic: [TLS] Universal PSKs Thread-Index: AQHUBBh4BxbQy0Pd9U2EE9VtJVDpdaRhf5aA///yQwA= Date: Fri, 15 Jun 2018 14:24:58 +0000 Message-ID: <7BE4BC91-5324-42A6-8AB7-084439ED9527@akamai.com> References: <2132206.KQKFhKinhY@pintsize.usersys.redhat.com> In-Reply-To: <2132206.KQKFhKinhY@pintsize.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.43.3] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-15_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=787 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806150154 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-15_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=709 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806150155 Archived-At: Subject: Re: [TLS] Universal PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2018 14:25:05 -0000 DQo+ICAgIHRoYXQncyBub3Qgd29ya2FibGUuDQogIA0KSXQncyBub3QgZ3JlYXQsIGhvd2V2ZXIN CiAgDQo+ICAgIHRoZSByZWFzb24gd2h5IGltcGxlbWVudGF0aW9ucyBjaG9zZSB0byB1c2Ugb2xk IEFQSSB0byBwcm92aXNpb24gVExTIDEuMyBQU0tzIA0KICAgIHdhcyB0byBtYWtlIHRoZSB1cGdy YWRlIHByb2Nlc3MgYXMgc21vb3RoIGFzIHBvc3NpYmxlLCBkaXNhYmxpbmcgVExTIDEuMyBpcyAN CiAgICBxdWl0ZSBhbnRpdGhldGljYWwgdG8gdGhhdA0KICANCkRpc2FibGluZyBUTFMgMS4zIGZv ciB0aG9zZSB1c2luZyAxLjIgUFNLJ3MgaXMgdW5saWtlbHkgdG8gYWZmZWN0IG1vc3QgdXNlcywg YW5kIHNlZW1zIHRoZSBvbmx5IHdheSBmb3J3YXJkLg0KDQpEbyB5b3UgaGF2ZSBhbiBhbHRlcm5h dGl2ZSBzb2x1dGlvbj8NCg0K From nobody Fri Jun 15 07:52:47 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0C3130EF6 for ; Fri, 15 Jun 2018 07:52:45 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZ5Ylu5Cd23i for ; Fri, 15 Jun 2018 07:52:43 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c: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 EB9BE130E4F for ; Fri, 15 Jun 2018 07:52:42 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id s187-v6so5823261vke.9 for ; Fri, 15 Jun 2018 07:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wom6CuJ//YRh9XzhhtG32gRZ4mT5LwtciDzs/kRmZmc=; b=UjgajQaMb1APB23wbBu5x0HNNTmI6ko/7sXmoHwu/UFhjF//WBEox1wXvt+bWZP4w+ RPCS35SB2hOVSvz5eFfEy5mlRHhDW9JGol1pERXg3Iu8OsEhT2KeKi1waE3eH5dh8ErT FUvnq1YBxcYXPHtpxAcnUd0QeWA68jvbXyMYwHofgq7cnEwyvZyXX/0fh2KZpxh9yXES CSQQs9e72EKS+tGLS+CJo1dPlPAiiVs1qQ6x7mqFSq+db0qffdkrzFYH2jBMzuGT19BI qQ+eUwLUPAL0sTd1gvm3nkN+ddFaVic/Qyr2fRAtLvAN2JSe8E1Jsy7GZBn6drL3qbcO b+xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Wom6CuJ//YRh9XzhhtG32gRZ4mT5LwtciDzs/kRmZmc=; b=FrfkhmEa+3lNYPXOYzSRC8J/+uLph+t1Os3piGlVairgnmvUfkr3FgyW6oG8sg0sBY MZ1O+vOVNMAeSYEFYXI1pooKlhL0A3Z5oIZCg8Z7inYrQG+KjNPX2u695aC/3EhYLqVO f6QVe6tgyQKc6nLolRfjlQcrahGMkzeHAj+ZobE1pKpMIPdxN97SurMI1jv5trQG9ESJ /3BavSwSKfh2wj9JgYv/Pgdq0EIfTTR8Xviu7jXNmCHDNCjnLdBiICsoPYqPRFPzfH0T Yw/AhgvsYXOfa6lC5tRa+BGuYH5AKMMBjf2cnLBSzURAS283oH6sZEdTYJaAfWmTnKEH ZeSQ== X-Gm-Message-State: APt69E3zcrK9zFFu6NBS/Jt1bx14Z3+ylxiUaQjsaPlshsSBvnWC7KP+ 4LYvhJjzS3JAQGdYTXjfFxvh+p3uCSef7HwZbEiIeQ== X-Google-Smtp-Source: ADUXVKITQChpEjOFRHm/3ajuoJdTnWMKdFwLck8ADLIzsDqvVRngIquEGU2RgVBmZdTrAeucp1yibNYSTf9bK6OFk1A= X-Received: by 2002:a1f:eb44:: with SMTP id j65-v6mr1152779vkh.14.1529074361918; Fri, 15 Jun 2018 07:52:41 -0700 (PDT) MIME-Version: 1.0 References: <2132206.KQKFhKinhY@pintsize.usersys.redhat.com> <7BE4BC91-5324-42A6-8AB7-084439ED9527@akamai.com> In-Reply-To: <7BE4BC91-5324-42A6-8AB7-084439ED9527@akamai.com> From: Jonathan Hoyland Date: Fri, 15 Jun 2018 16:52:30 +0200 Message-ID: To: "Salz, Rich" Cc: Hubert Kario , "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002d67f9056eaf5ed8" Archived-At: Subject: Re: [TLS] Universal PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2018 14:52:46 -0000 --0000000000002d67f9056eaf5ed8 Content-Type: text/plain; charset="UTF-8" Is it not possible to construct a channel binding for whatever underlying protocol was used to agree the PSK and use that as the PSK identity. If the PSK was created in TLS 1.2 then that would be something derived from `tls-unique`. The security of a channel binding is not dependent on it being secret, and thus using it as the PSK identity is safe. Doing this would prove agreement on the KDF used, and would be bound to the handshake by the PSK binders. Assuming that the KDF was something acceptably secure, this would mitigate the risk of collisions between hash outputs, because which hash function was used to produce the PSK would be an agreed value. That would also require no changes to the key schedule, which is perhaps lower risk. This of course assumes that both parties agree that this is how the PSK identity was constructed, so it would probably need an extension. Regards, Jonathan On Fri, 15 Jun 2018 at 15:25 Salz, Rich wrote: > > > that's not workable. > > It's not great, however > > > the reason why implementations chose to use old API to provision TLS > 1.3 PSKs > was to make the upgrade process as smooth as possible, disabling TLS > 1.3 is > quite antithetical to that > > Disabling TLS 1.3 for those using 1.2 PSK's is unlikely to affect most > uses, and seems the only way forward. > > Do you have an alternative solution? > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000002d67f9056eaf5ed8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Is it not possible to construct a channel binding for what= ever underlying protocol was used to agree the PSK and use that as the PSK = identity.=C2=A0
If the PSK was created in TLS 1.2 then that would be so= mething derived from `tls-unique`.=C2=A0

The securit= y of a channel binding is not dependent on it being secret, and thus using = it as the PSK identity is safe.=C2=A0

Doing this w= ould prove agreement on the KDF used, and would be bound to the handshake b= y the PSK binders.=C2=A0
Assuming that the KDF was somethin= g acceptably secure, this would mitigate the risk of collisions between has= h outputs, because which hash function was used to produce the PSK would be= an agreed value.=C2=A0

That would also require no= changes to the key schedule, which is perhaps lower risk.=C2=A0
=
This of course assumes that both parties agree that this is = how the PSK identity was constructed, =C2=A0so it would probably need an ex= tension.=C2=A0

Regards,

J= onathan

On Fri, = 15 Jun 2018 at 15:25 Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.org> wrote:

>=C2=A0 =C2=A0 that's not workable.

It's not great, however

>=C2=A0 =C2=A0 the reason why implementations chose to use old API to pr= ovision TLS 1.3 PSKs
=C2=A0 =C2=A0 was to make the upgrade process as smooth as possible, disabl= ing TLS 1.3 is
=C2=A0 =C2=A0 quite antithetical to that

Disabling TLS 1.3 for those using 1.2 PSK's is unlikely to affect most = uses, and seems the only way forward.

Do you have an alternative solution?

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000002d67f9056eaf5ed8-- From nobody Fri Jun 15 07:57:16 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC92130E4F for ; Fri, 15 Jun 2018 07:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.951 X-Spam-Level: X-Spam-Status: No, score=-9.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kDlql0wMjWW for ; Fri, 15 Jun 2018 07:57:07 -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 27B57130F34 for ; Fri, 15 Jun 2018 07:57:01 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id w23-v6so5744986qkb.8 for ; Fri, 15 Jun 2018 07:57:01 -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 :cc; bh=Jp0gL7HwkLyir0K6JceemyQcHHN3ivD+agUn1E+Ht0g=; b=EVBuNKyrOq4ErEVbheXQWVtN+XX/opfG33ppv3bDnN1r/2013AdMC2744Dcyogm25c kFX0Y8wYhrrPmq8dkTRVqO8ds4QPAb+s95Kww67mQocgxXS2w7KnMahjae5BBvUe4Vnc d515yKlJHBrlWlMe0Xs4tKkiJ+nXn+VzpF8hM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jp0gL7HwkLyir0K6JceemyQcHHN3ivD+agUn1E+Ht0g=; b=YezXKLj2+N6p6nhbgG6AyX+38BXeOYr+ia0QIK2eFAPkX7/arh8FICwY8DSbMPQHKN cqQQ5/S6I+1fmJZuL9g6HC3eIDPdGv36EJCWXHTsAkdASFZbiOan0ghoHUBkVRqlp3vk G0vkA60h3mb7EAjysiJSGo488VVrxm7T7s59Qnb8s5KyzwitEkHB1y280lQlduxAfOdx 58QRkMmRlD9mHQBtuDotKnl4/vjCqEainJeQEshLVwLuRqH0i+1e8o+QbMWFgXbOksnh ZAyeozQLz4fT3ee3JEtCgZD6cEhVOHMs3x7aCClaes1+giwlf0M9s3efw3sZwh1WQbhz +dvw== X-Gm-Message-State: APt69E3pK68TReZhLuyAJOnXBGVwDO8GxW7YztQo5KTT9VOVL/5Vt+YJ dtGhi6ESSzuBDNWP+U+aE9B2WuBWwoDWKTCC0bGkAsE= X-Google-Smtp-Source: ADUXVKLXRHvGlbvftOP9K95BFONG0h3OhZtm0zKexjp3j9vQcc4ZzgkANS4zotreKk1tthWIaZR8naLHH5u26OJAueY= X-Received: by 2002:ae9:c008:: with SMTP id u8-v6mr1659142qkk.85.1529074620097; Fri, 15 Jun 2018 07:57:00 -0700 (PDT) MIME-Version: 1.0 References: <7e5945f3c6bf9d8168a862f45bc00100cded1802.camel@redhat.com> In-Reply-To: <7e5945f3c6bf9d8168a862f45bc00100cded1802.camel@redhat.com> From: David Benjamin Date: Fri, 15 Jun 2018 10:56:48 -0400 Message-ID: To: Nikos Mavrogiannopoulos Cc: "" Content-Type: multipart/alternative; boundary="0000000000009195e1056eaf6d6a" Archived-At: Subject: Re: [TLS] Universal PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2018 14:57:14 -0000 --0000000000009195e1056eaf6d6a Content-Type: text/plain; charset="UTF-8" On Fri, Jun 15, 2018 at 7:37 AM Nikos Mavrogiannopoulos wrote: > On Thu, 2018-06-14 at 15:46 -0400, David Benjamin wrote: > > Hey all, > > > > So TLS 1.2 has a mechanism for PSKs. We attempted to mirror it in TLS > > 1.3 via the external PSK mechanism, repurposing the resumption flow. > > But the security proof requires PSKs be associated with a specific > > hash for key separation. We use distinguishing labels in the key > > schedule, but if that key is fed into a completely different KDF, > > analysis must additionally consider interactions between the KDFs. > > > > The hash constraint, however, makes it difficult to actually use > > external PSKs in applications. Usually the TLS stack and its > > configuration evolves somewhat independently from the calling > > application. But now the PSK provisioning process must short-circuit > > part of the TLS parameter negotiation, despite it likely being > > implemented in a separate library altogether. This is a leaky > > abstraction. > > > > It also complicates server parameter selection. We've found the > > cleanest algorithm is selecting the cipher suite first, and then > > ignoring the PSKs that don't match. This is simple and avoids weird > > behavior if a session is renewed across preference changes. However, > > this only works for resumption PSK: if the session mismatches, a full > > handshake is always an option. With external PSKs, the application > > usually expects the PSK to be mandatory. > > > Finally, some libraries (e.g. OpenSSL) already TLS 1.2 PSK APIs and > > wish to transparently upgrade to TLS 1.3. The specification does not > > explicitly say if a TLS 1.2 PSK may be used directly as a TLS 1.3 PSK > > and I believe some implementations are doing that. However that > > violates TLS 1.3's key separation assumptions in the same way as > > mixing hashes: the TLS 1.2 PRF is not the same as HKDF. > > I don't think that TLS1.3 has strict key separation assumptions, and > they are nowhere spelled out. For example, RSA keys can be used for > RSA-PSS or RSA PKCS#1 1.5 signatures or RSA encryption. > I think it's a little more complex than that. Keys used in multiple ways are affected by interactions between those uses, so formal analysis tends to want to exclude these cases. So, yes, ideally we would separate every key everywhere. But, as Hubert notes elsewhere in the thread, we wish for the TLS 1.3 upgrade to be as smooth as possible, which includes being able to reuse any externally-provisioned keys (RSA, symmetric, or whatever). These two desires are in tension. For stuff like RSA, we don't have easy ways around this. If you have an id-rsaEncryption key---which is common---that's what you've got. So the RFC 4055 and TLS 1.3, for practicality's sake, allow this. For symmetric keys, we have more flexibility in playing games deriving keys with labels. The entire TLS 1.3 key schedule is a tower of this stuff. To that end, TLS 1.3 *does* include a hash-matching requirement for PSKs. However, in doing so, we failed to account for similar practicalities with external PSKs, both with existing TLS 1.2 PSKs and also clean abstractions for new uses. This draft is an attempt to fix this. > > It's a bit late to completely redo external PSKs in 1.3, but I > > believe we can fix this in a separate draft. The draft below proposes > > "universal PSKs" which derive independent hash- and version-specific > > secrets for TLS 1.3 (and later) as needed. For existing TLS 1.2 PSKs, > > it includes a compatibility derivation to go from TLS 1.2 PSKs to > > universal PSKs. > > > > (Thanks to Karthikeyan Bhargavan, Matt Caswell, Eric Rescorla, and > > Victor Vasiliev for discussions which led to this design. Any > > mistakes in it are mine.) > > > > Thoughts? > > It feels that's this is too little too late. Implementations which > support PSKs will switch to TLS1.3 irrespective of this proposal. If > this proposal takes on, we will have some implementations which support > universal PSKs and others which don't leading to interoperability > problems which we wouldn't have otherwise. > Right, I think that's why we should get a quick clarification in the spec that 1.2 PSKs shouldn't be used directly in 1.3 and a fix for this is forthcoming in a later document. (Assuming, of course, we all conclude that is how we want to do this. I chatted with Karthik about some of this when writing the draft, but I certainly may messed things up or misunderstood something!) --0000000000009195e1056eaf6d6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jun 15= , 2018 at 7:37 AM Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
On Thu, 2018-06-14 at 15:46 -0400, David Benjamin wrote= :
> Hey all,
>
> So TLS 1.2 has a mechanism for PSKs. We attempted to mirror it in TLS<= br> > 1.3 via the external PSK mechanism, repurposing the resumption flow. > But the security proof requires PSKs be associated with a specific
> hash for key separation. We use distinguishing labels in the key
> schedule, but if that key is fed into a completely different KDF,
> analysis must additionally consider interactions between the KDFs.
>
> The hash constraint, however, makes it difficult to actually use
> external PSKs in applications. Usually the TLS stack and its
> configuration evolves somewhat independently from the calling
> application. But now the PSK provisioning process must short-circuit > part of the TLS parameter negotiation, despite it likely being
> implemented in a separate library altogether. This is a leaky
> abstraction.
>
> It also complicates server parameter selection. We've found the > cleanest algorithm is selecting the cipher suite first, and then
> ignoring the PSKs that don't match. This is simple and avoids weir= d
> behavior if a session is renewed across preference changes. However, > this only works for resumption PSK: if the session mismatches, a full<= br> > handshake is always an option. With external PSKs, the application
> usually expects the PSK to be mandatory.

> Finally, some libraries (e.g. OpenSSL) already TLS 1.2 PSK APIs and > wish to transparently upgrade to TLS 1.3. The specification does not > explicitly say if a TLS 1.2 PSK may be used directly as a TLS 1.3 PSK<= br> > and I believe some implementations are doing that. However that
> violates TLS 1.3's key separation assumptions in the same way as > mixing hashes: the TLS 1.2 PRF is not the same as HKDF.

I don't think that TLS1.3 has strict key separation assumptions, and they are nowhere spelled out. For example, RSA keys can be used for
RSA-PSS or RSA PKCS#1 1.5 signatures or RSA encryption.

I think it's a little more complex than that. Keys used in mul= tiple ways are affected by interactions between those uses, so formal analy= sis tends to want to exclude these cases. So, yes, ideally we would separat= e every key everywhere. But, as Hubert notes elsewhere in the thread, we wi= sh for the TLS 1.3 upgrade to be as smooth as possible, which includes bein= g able to reuse any externally-provisioned keys (RSA, symmetric, or whateve= r). These two desires are in tension.

For stuff li= ke RSA, we don't have easy ways around this. If you have an id-rsaEncry= ption key---which is common---that's what you've got. So the RFC 40= 55 and TLS 1.3, for practicality's sake, allow this.

For symmetric keys, we have more flexibility in playing games derivi= ng keys with labels. The entire TLS 1.3 key schedule is a tower of this stu= ff. To that end, TLS 1.3 *does* include a hash-matching requirement for PSK= s.

However, in doing so, we failed to account for = similar practicalities with external PSKs, both with existing TLS 1.2 PSKs = and also clean abstractions for new uses. This draft is an attempt to fix t= his.
=C2=A0
> It's a bit late to completely redo external PSKs in 1.3, but I
> believe we can fix this in a separate draft. The draft below proposes<= br> > "universal PSKs" which derive independent hash- and version-= specific
> secrets for TLS 1.3 (and later) as needed. For existing TLS 1.2 PSKs,<= br> > it includes a compatibility derivation to go from TLS 1.2 PSKs to
> universal PSKs.
>
> (Thanks to Karthikeyan Bhargavan, Matt Caswell, Eric Rescorla, and
> Victor Vasiliev for discussions which led to this design. Any
> mistakes in it are mine.)
>
> Thoughts?

It feels that's this is too little too late. Implementations which
support PSKs will switch to TLS1.3 irrespective of this proposal. If
this proposal takes on, we will have some implementations which support
universal PSKs and others which don't leading to interoperability
problems which we wouldn't have otherwise.

Right, I think that's why we should get a quick clarificati= on in the spec that 1.2 PSKs shouldn't be used directly in 1.3 and a fi= x for this is forthcoming in a later document. (Assuming, of course, we all= conclude that is how we want to do this. I chatted with Karthik about some= of this when writing the draft, but I certainly may messed things up or mi= sunderstood something!)=C2=A0
--0000000000009195e1056eaf6d6a-- From nobody Fri Jun 15 08:19:32 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DC6130DC0 for ; Fri, 15 Jun 2018 08:19:29 -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 autolearn_force=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 xUCr08ZM8cQf for ; Fri, 15 Jun 2018 08:19:27 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CB9C130E2C for ; Fri, 15 Jun 2018 08:19:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 1A573548B9; Fri, 15 Jun 2018 18:19:25 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id bDW7n2_Js4Di; Fri, 15 Jun 2018 18:19:24 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 3FFD373; Fri, 15 Jun 2018 18:19:21 +0300 (EEST) Date: Fri, 15 Jun 2018 18:19:20 +0300 From: Ilari Liusvaara To: David Benjamin Cc: Nikos Mavrogiannopoulos , "" Message-ID: <20180615151920.GA18406@LK-Perkele-VII> References: <7e5945f3c6bf9d8168a862f45bc00100cded1802.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Universal PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2018 15:19:30 -0000 On Fri, Jun 15, 2018 at 10:56:48AM -0400, David Benjamin wrote: > On Fri, Jun 15, 2018 at 7:37 AM Nikos Mavrogiannopoulos > wrote: > > I think it's a little more complex than that. Keys used in multiple ways > are affected by interactions between those uses, so formal analysis tends > to want to exclude these cases. So, yes, ideally we would separate every > key everywhere. But, as Hubert notes elsewhere in the thread, we wish for > the TLS 1.3 upgrade to be as smooth as possible, which includes being able > to reuse any externally-provisioned keys (RSA, symmetric, or whatever). > These two desires are in tension. > > For stuff like RSA, we don't have easy ways around this. If you have an > id-rsaEncryption key---which is common---that's what you've got. So the RFC > 4055 and TLS 1.3, for practicality's sake, allow this. I once calculated that it is extremely unlikely that there exists _any_ RSA plaintext that is valid signature (for possibly different messages) as both RSA PKCS#1 v1.5 and RSA-PSS. This is regardless of if such plaintext would be feasible to find or if it was feasible to find one or both of the messages it signs. However, straight out collision might not be realistic model of this. But on the other hand, with hashes collision resistance of both hashes does not imply one can not feasbily find cross-collisions or even cross-second- preimages. -Ilari From nobody Fri Jun 15 08:26:56 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25104130E2C for ; Fri, 15 Jun 2018 08:26:53 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUhd6_XDnUak for ; Fri, 15 Jun 2018 08:26:47 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 AD308130E2D for ; Fri, 15 Jun 2018 08:26:46 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id x18-v6so6633006uaj.9 for ; Fri, 15 Jun 2018 08:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KUHqSbDHp/kGX8XxM9ha+A9I6IlaSCq+aKUDoMCyYz4=; b=KYiPFhIghNKappchB0N3MOTYlguiKbSzl5N6ktQQHqAOUif6aZiVwI7XQCaEFlzkxN hHTD6ZFwt2kGi4BJIYC0LXCd2cOUHYYpFT0ZC+qM8NMx40VfYxNpyoCmeGopBcAXEXVa W19u9YqVVA9ptkimEtX2L6yDjgSX/emu45JycDhJ+hWor37cvFHu/xTeJYcUg/gHr1Cz doArsPCEVc+0oyaWCeqc3bnIZPsWAk/K+O3UtG/u6uv+uHhXTy/lFCJKx/ZIqFj5hQsz KbdVo9V7DZsl1Y1+ByCTlAIsJx9bb5sPCoSys/Uz5iEN60CjyinwYm2M881bNTvllrcG 1sFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KUHqSbDHp/kGX8XxM9ha+A9I6IlaSCq+aKUDoMCyYz4=; b=btIgxDtbP0+PIfl2/rBVqoQzTpO0Nh0vj0pGR4ZuqNgUUN45AY+HNNRlmMYksmeFAx 6O4kxDoT4TlnWGvZkePhj+2wq5fEXbGdV5naBgteYgSBf6tPs/M/N0iahUaz69K8xv40 fHdMOERqRPeQrSGb6izwnoyFd+cuZ7uU3gDO34EWmkTjDgXbZBy1+96fbRzNIJNRTtJv E/+qcDgVSIkyrL7Nco6L/kRAFnP2C/SlilLqS5U6spIRUfw6ncoO1IqUlta3UIvEgwed cW65SvLqleqKvtV4REtnvT/V/+AGdeJdAlcIrcQgrgmE0qjdqFNsHnOBslNcjXOI72Zd uFGA== X-Gm-Message-State: APt69E1NiVfLP/WztrbJC8720WsQJypU5a9f0SSGsKOSXpiR2Hw4DzYZ BdKm+W+hze5U6Ji1Qpd6NhkZUv7kDZiY6jt2oSo= X-Google-Smtp-Source: ADUXVKLcGBBsEK62Gj3+LRb+fBGpxVwEnkOs0BkFYzB6f/z8JrDBr8hz4oQc85pO9KN/dEyP5RNIK8EstXamIgxl/ew= X-Received: by 2002:a9f:3047:: with SMTP id i7-v6mr1501966uab.189.1529076405578; Fri, 15 Jun 2018 08:26:45 -0700 (PDT) MIME-Version: 1.0 References: <7e5945f3c6bf9d8168a862f45bc00100cded1802.camel@redhat.com> In-Reply-To: From: Jonathan Hoyland Date: Fri, 15 Jun 2018 17:26:33 +0200 Message-ID: To: David Benjamin Cc: Nikos Mavrogiannopoulos , "" Content-Type: multipart/alternative; boundary="000000000000fd3013056eafd787" Archived-At: Subject: Re: [TLS] Universal PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2018 15:26:54 -0000 --000000000000fd3013056eafd787 Content-Type: text/plain; charset="UTF-8" Agreement on a channel binding in the identity would prove, amongst other things, agreement on the KDF used to derive the PSK, whereas the TLS handshake proves agreement on the PSK itself, but says nothing about the derivation of it. This way means you don't have to worry about collisions between hash functions, as long as the channel binding is correctly constructed. Because TLS 1.3 doesn't have an explicit interface for accepting channel bindings this isn't the most elegant of solutions, but I think it would at least fix the issue where the KDF used changes between the place where the PSK is generated and where it is used. I'm not sure I understand your point about formal analysis. Formal analysis's main strength is that is can consider all the possible interactions between use cases. Channel bindings are in fact designed for this exact purpose, to securely connect the values established in one protocol to the values used in another. More specifically they prove that the peer in the earlier run is the same actor as in the later run, and further that all values established in _both_ protocols are agreed upon, including which KDF was used in the earlier PSK establishing run. Using this method, you wouldn't take a PSK directly from TLS 1.2, you would transform it before using it in TLS 1.3, by changing the identity. You could also update the key at that point, by putting it through the KDF from TLS. That would give you a new pair that fixes the issue without requiring changes to the TLS key schedule. This ends up being very similar to the draft in terms of code, it merely separates the cases neatly, moving the entire transformation to before the TLS run, meaning the TLS key schedule doesn't need tweaking. You won't have one identity with two potential keys / key derivations, as in the current draft, you would have two distinct pairs, and by accepting the transformed one the server indicates that it understands the transformation. This makes it easier to migrate from one method to the other, because you could offer both keys to servers where you were unsure of support, and would learn about support based on its choice. Regards, Jonathan On Fri, 15 Jun 2018 at 15:57 David Benjamin wrote: > On Fri, Jun 15, 2018 at 7:37 AM Nikos Mavrogiannopoulos > wrote: > >> On Thu, 2018-06-14 at 15:46 -0400, David Benjamin wrote: >> > Hey all, >> > >> > So TLS 1.2 has a mechanism for PSKs. We attempted to mirror it in TLS >> > 1.3 via the external PSK mechanism, repurposing the resumption flow. >> > But the security proof requires PSKs be associated with a specific >> > hash for key separation. We use distinguishing labels in the key >> > schedule, but if that key is fed into a completely different KDF, >> > analysis must additionally consider interactions between the KDFs. >> > >> > The hash constraint, however, makes it difficult to actually use >> > external PSKs in applications. Usually the TLS stack and its >> > configuration evolves somewhat independently from the calling >> > application. But now the PSK provisioning process must short-circuit >> > part of the TLS parameter negotiation, despite it likely being >> > implemented in a separate library altogether. This is a leaky >> > abstraction. >> > >> > It also complicates server parameter selection. We've found the >> > cleanest algorithm is selecting the cipher suite first, and then >> > ignoring the PSKs that don't match. This is simple and avoids weird >> > behavior if a session is renewed across preference changes. However, >> > this only works for resumption PSK: if the session mismatches, a full >> > handshake is always an option. With external PSKs, the application >> > usually expects the PSK to be mandatory. >> >> > Finally, some libraries (e.g. OpenSSL) already TLS 1.2 PSK APIs and >> > wish to transparently upgrade to TLS 1.3. The specification does not >> > explicitly say if a TLS 1.2 PSK may be used directly as a TLS 1.3 PSK >> > and I believe some implementations are doing that. However that >> > violates TLS 1.3's key separation assumptions in the same way as >> > mixing hashes: the TLS 1.2 PRF is not the same as HKDF. >> >> I don't think that TLS1.3 has strict key separation assumptions, and >> they are nowhere spelled out. For example, RSA keys can be used for >> RSA-PSS or RSA PKCS#1 1.5 signatures or RSA encryption. >> > > I think it's a little more complex than that. Keys used in multiple ways > are affected by interactions between those uses, so formal analysis tends > to want to exclude these cases. So, yes, ideally we would separate every > key everywhere. But, as Hubert notes elsewhere in the thread, we wish for > the TLS 1.3 upgrade to be as smooth as possible, which includes being able > to reuse any externally-provisioned keys (RSA, symmetric, or whatever). > These two desires are in tension. > > For stuff like RSA, we don't have easy ways around this. If you have an > id-rsaEncryption key---which is common---that's what you've got. So the RFC > 4055 and TLS 1.3, for practicality's sake, allow this. > > For symmetric keys, we have more flexibility in playing games deriving > keys with labels. The entire TLS 1.3 key schedule is a tower of this stuff. > To that end, TLS 1.3 *does* include a hash-matching requirement for PSKs. > > However, in doing so, we failed to account for similar practicalities with > external PSKs, both with existing TLS 1.2 PSKs and also clean abstractions > for new uses. This draft is an attempt to fix this. > > >> > It's a bit late to completely redo external PSKs in 1.3, but I >> > believe we can fix this in a separate draft. The draft below proposes >> > "universal PSKs" which derive independent hash- and version-specific >> > secrets for TLS 1.3 (and later) as needed. For existing TLS 1.2 PSKs, >> > it includes a compatibility derivation to go from TLS 1.2 PSKs to >> > universal PSKs. >> > >> > (Thanks to Karthikeyan Bhargavan, Matt Caswell, Eric Rescorla, and >> > Victor Vasiliev for discussions which led to this design. Any >> > mistakes in it are mine.) >> > >> > Thoughts? >> >> It feels that's this is too little too late. Implementations which >> support PSKs will switch to TLS1.3 irrespective of this proposal. If >> this proposal takes on, we will have some implementations which support >> universal PSKs and others which don't leading to interoperability >> problems which we wouldn't have otherwise. >> > > Right, I think that's why we should get a quick clarification in the spec > that 1.2 PSKs shouldn't be used directly in 1.3 and a fix for this is > forthcoming in a later document. (Assuming, of course, we all conclude that > is how we want to do this. I chatted with Karthik about some of this when > writing the draft, but I certainly may messed things up or misunderstood > something!) > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000fd3013056eafd787 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agreement on a channel binding in the identity would prove= , amongst other things, agreement on the KDF used to derive the PSK, wherea= s the TLS handshake proves agreement on the PSK itself, but says nothing ab= out the derivation of it.=C2=A0
This way means you don't have to wo= rry about collisions between hash functions, as long as the channel binding= is correctly constructed.=C2=A0

Because TLS 1.3 doe= sn't have an explicit interface for accepting channel bindings this isn= 't the most elegant of solutions, but I think it would at least fix the= issue where the KDF used changes between the place where the PSK is genera= ted and where it is used.=C2=A0

I'm not sure I= understand your point about formal analysis.
Formal analysis'= ;s main strength is that is can consider all the possible interactions betw= een use cases.=C2=A0
Channel bindings are in fact designed for th= is exact purpose, to securely connect the values established in one protoco= l to the values used in another.=C2=A0
More specifically they pro= ve that the peer in the earlier run is the same actor as in the later run, = and further that all values established in _both_ protocols are agreed upon= , including which KDF was used in the earlier PSK establishing run.=C2=A0

Using this method, you wouldn't take a PSK directly f= rom TLS 1.2, you would transform it before using it in TLS 1.3, by changing= the identity.
You could also update the key at that point, by pu= tting it through the KDF from TLS.=C2=A0
That would give you a ne= w <identity, key> pair that fixes the issue without requiring changes= to the TLS key schedule.=C2=A0
This ends up being very similar t= o the draft in terms of code, it merely separates the cases neatly, moving = the entire transformation to before the TLS run, meaning the TLS key schedu= le doesn't need tweaking.=C2=A0

You won't = have one identity with two potential keys / key derivations, as in the curr= ent draft, you would have two distinct <identity, key> pairs, and by = accepting the transformed one the server indicates that it understands the = transformation.=C2=A0
This makes it easier to migrate from one me= thod to the other, because you could offer both keys to servers where you w= ere unsure of support, and would learn about support based on its choice.= =C2=A0

Regards,

Jonathan<= /div>





<= /div>

On F= ri, 15 Jun 2018 at 15:57 David Benjamin <davidben@chromium.org> wrote:
= On Fri, Jun 15, 2018 at 7:37 AM Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
On Thu, 2018-06-14 at 15:46 -0400, David= Benjamin wrote:
> Hey all,
>
> So TLS 1.2 has a mechanism for PSKs. We attempted to mirror it in TLS<= br> > 1.3 via the external PSK mechanism, repurposing the resumption flow. > But the security proof requires PSKs be associated with a specific
> hash for key separation. We use distinguishing labels in the key
> schedule, but if that key is fed into a completely different KDF,
> analysis must additionally consider interactions between the KDFs.
>
> The hash constraint, however, makes it difficult to actually use
> external PSKs in applications. Usually the TLS stack and its
> configuration evolves somewhat independently from the calling
> application. But now the PSK provisioning process must short-circuit > part of the TLS parameter negotiation, despite it likely being
> implemented in a separate library altogether. This is a leaky
> abstraction.
>
> It also complicates server parameter selection. We've found the > cleanest algorithm is selecting the cipher suite first, and then
> ignoring the PSKs that don't match. This is simple and avoids weir= d
> behavior if a session is renewed across preference changes. However, > this only works for resumption PSK: if the session mismatches, a full<= br> > handshake is always an option. With external PSKs, the application
> usually expects the PSK to be mandatory.

> Finally, some libraries (e.g. OpenSSL) already TLS 1.2 PSK APIs and > wish to transparently upgrade to TLS 1.3. The specification does not > explicitly say if a TLS 1.2 PSK may be used directly as a TLS 1.3 PSK<= br> > and I believe some implementations are doing that. However that
> violates TLS 1.3's key separation assumptions in the same way as > mixing hashes: the TLS 1.2 PRF is not the same as HKDF.

I don't think that TLS1.3 has strict key separation assumptions, and they are nowhere spelled out. For example, RSA keys can be used for
RSA-PSS or RSA PKCS#1 1.5 signatures or RSA encryption.

=
I think it's a little more complex than= that. Keys used in multiple ways are affected by interactions between thos= e uses, so formal analysis tends to want to exclude these cases. So, yes, i= deally we would separate every key everywhere. But, as Hubert notes elsewhe= re in the thread, we wish for the TLS 1.3 upgrade to be as smooth as possib= le, which includes being able to reuse any externally-provisioned keys (RSA= , symmetric, or whatever). These two desires are in tension.

=
For stuff like RSA, we don't have easy ways around this. If = you have an id-rsaEncryption key---which is common---that's what you= 9;ve got. So the RFC 4055 and TLS 1.3, for practicality's sake, allow t= his.

For symmetric keys, we have more flexibility = in playing games deriving keys with labels. The entire TLS 1.3 key schedule= is a tower of this stuff. To that end, TLS 1.3 *does* include a hash-match= ing requirement for PSKs.

However, in doing so, we= failed to account for similar practicalities with external PSKs, both with= existing TLS 1.2 PSKs and also clean abstractions for new uses. This draft= is an attempt to fix this.
<= div dir=3D"ltr">
=C2=A0
> It's a bit late to completely redo external PSKs in 1.3, but I
> believe we can fix this in a separate draft. The draft below proposes<= br> > "universal PSKs" which derive independent hash- and version-= specific
> secrets for TLS 1.3 (and later) as needed. For existing TLS 1.2 PSKs,<= br> > it includes a compatibility derivation to go from TLS 1.2 PSKs to
> universal PSKs.
>
> (Thanks to Karthikeyan Bhargavan, Matt Caswell, Eric Rescorla, and
> Victor Vasiliev for discussions which led to this design. Any
> mistakes in it are mine.)
>
> Thoughts?

It feels that's this is too little too late. Implementations which
support PSKs will switch to TLS1.3 irrespective of this proposal. If
this proposal takes on, we will have some implementations which support
universal PSKs and others which don't leading to interoperability
problems which we wouldn't have otherwise.

Right, I think that's why we should = get a quick clarification in the spec that 1.2 PSKs shouldn't be used d= irectly in 1.3 and a fix for this is forthcoming in a later document. (Assu= ming, of course, we all conclude that is how we want to do this. I chatted = with Karthik about some of this when writing the draft, but I certainly may= messed things up or misunderstood something!)=C2=A0
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000fd3013056eafd787-- From nobody Fri Jun 15 09:14:09 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56527130E85 for ; Fri, 15 Jun 2018 09:14:00 -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_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LebqCw3kN0bx for ; Fri, 15 Jun 2018 09:13:57 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 5291B130F37 for ; Fri, 15 Jun 2018 09:13:56 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5FGCI6S002197; Fri, 15 Jun 2018 17:13:54 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=RXG6Blk3lGANYxyO9Da6bKf2Rm9Xjh+ng4yIZFLRCwA=; b=Wp1iD9SS6gXS86hO4XNE1aue5QIv5fXJ2VMZwB3VWv/obVlAcMx7mGkgoUvxiFxkq3ir bLolKrk499VXizrjAGUS/KNjImZ69XpMVqBtZP900IxCDkKOKbhl0Z2dwiFWaz6cd2iL Rj2WAYMtbGaiyoXXxE8simzSD5rB9yQNhT/hPwLntvW3zi7EuppTy6K0PgXLVMfk3fHP MQ/5/P0/V5HpBy88OUv6qbxUju2uexs0Q43NhP/ctH22BXIlz8lxDX5fzpsGqLaExMzZ R04XdzHe0dt7+NEs3erdV/8ajQN1xBTY22ZeRjh9rAn90nRwdKq2kQI87NEPN8Vnu/RV Jg== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2jmfpu05ea-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Jun 2018 17:13:54 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5FGBSUE021593; Fri, 15 Jun 2018 12:13:53 -0400 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2jmdfm0v4a-1; Fri, 15 Jun 2018 12:13:53 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 2F6BD1FC72; Fri, 15 Jun 2018 16:13:53 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1fTrMG-0007QW-I8; Fri, 15 Jun 2018 11:13:52 -0500 Date: Fri, 15 Jun 2018 11:13:52 -0500 From: Benjamin Kaduk To: Jonathan Hoyland Cc: "" Message-ID: <20180615161352.GJ13834@akamai.com> References: <7e5945f3c6bf9d8168a862f45bc00100cded1802.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-15_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=459 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806150173 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-15_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=435 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806150173 Archived-At: Subject: Re: [TLS] Universal PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2018 16:14:08 -0000 On Fri, Jun 15, 2018 at 05:26:33PM +0200, Jonathan Hoyland wrote: > Agreement on a channel binding in the identity would prove, amongst other > things, agreement on the KDF used to derive the PSK, whereas the TLS > handshake proves agreement on the PSK itself, but says nothing about the > derivation of it. > This way means you don't have to worry about collisions between hash > functions, as long as the channel binding is correctly constructed. While this is an interesting way to think about things, it's unclear to me how general it is for framing the problem. That is to say, there is not necessarily a "channel" used to provision what TLS 1.3 calls "external PSKs". My model for them includes an administrator typing a hex string into a configuration file on both ends of the connection, or a manufacturer burning a key into ROM for an IoT device -- what would the "channel" be those cases? (Or do I completely misunderstand what you're trying to do?) -Ben From nobody Fri Jun 15 09:20:54 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34F1130E35 for ; Fri, 15 Jun 2018 09:20:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmYuhGTIf0Kv for ; Fri, 15 Jun 2018 09:20:50 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 977EA130DC0 for ; Fri, 15 Jun 2018 09:20:50 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id 59-v6so6777472uas.5 for ; Fri, 15 Jun 2018 09:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gGD/j6f9fKHzEpaV+Pzhgtrj/ezQMys4J8sqVFVGUmM=; b=iIog+w588LcV+vr9gNm3HwY8Yf+WoDG+bDuKb1Y39PMNQ/MPs8leK4kyYqIxO5a0+2 G2+Otq8QSmEFa+zHIq80sWkeFUVJESDtdIkXjfuqlYBec2ZjLcERxTnDerlozlvUOanB oaW/qDWTq1n85PSqglw6rEZfxapUs2wG9hrhREBwz4ja9rjpq1Bk/9vVWCoDkrjpD3Lk BI83WtnK67aMbMYojfG4Zu53GRAEILzrpByP9FuLu4Ei4MthVJzvgv1bkLBUDxpMN26y JjpAz7vHbtoVIZhoFy75NSJkMJE+7WELaCwq1kE6x/y3uwUU7up8f+LrBZUElQ/Jkhea k0fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gGD/j6f9fKHzEpaV+Pzhgtrj/ezQMys4J8sqVFVGUmM=; b=QMUF78E3OdSWqrIgmUfraq3YCZwh4zkzKauk6t7Wga6MEQzM+PCzIvoS+UfenhDrub 9GXC/donhUS9A4ifavdbwiCmW5XD2FlsSEeWy0JxG2LdvAw4fkIRTqg3PZE4+af5/63d 53skJokrpt3AinUBXg5KFu2Gg/XHOqPe8cpbmHzJRcWT4rBDrcoSo79Z00lrY6QO6Cs/ C+4QSFkOXnhwe3FH7tSshCsKD7pyjuT6xSi3RhXrn0GgxgYA41KiU5KxOrS9weJtvgku 9bG2Pi/MEQaetY6uvzOXwvk7n5PLiY2ceyudC40IDP/6SPL7nVQ55hoAPJsKgV6BvUvO mWCQ== X-Gm-Message-State: APt69E2Ai5cRHcAbgjFYf4Y6/FxE2boZsJsm9AoRQG7Wae1hpv2RCVHh ZxA1UJRGJ8IHCGoIV5Rb/odOohUPY64Gk9zT0kkvHA== X-Google-Smtp-Source: ADUXVKJzKE0mGk77Bq3rsHC+hcMZO6EFaEg3m+LcUIFAJRWOCKh4u/zHSgqvV4n+SVg/dIhStcXK360wnOXJYYYsYYk= X-Received: by 2002:ab0:1b22:: with SMTP id d34-v6mr1565107uai.176.1529079649634; Fri, 15 Jun 2018 09:20:49 -0700 (PDT) MIME-Version: 1.0 References: <7e5945f3c6bf9d8168a862f45bc00100cded1802.camel@redhat.com> <20180615161352.GJ13834@akamai.com> In-Reply-To: <20180615161352.GJ13834@akamai.com> From: Jonathan Hoyland Date: Fri, 15 Jun 2018 17:20:39 +0100 Message-ID: To: Benjamin Kaduk Cc: "" Content-Type: multipart/alternative; boundary="000000000000598ffb056eb099a3" Archived-At: Subject: Re: [TLS] Universal PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2018 16:20:53 -0000 --000000000000598ffb056eb099a3 Content-Type: text/plain; charset="UTF-8" Channel bindings are generally just horribly named. The `channel` in that case would consist solely of the agreed key, and agreement on it would prove that not only was that the key, but also that nothing else was established. Therefore you wouldn't be able to convince one side that it was just a manually entered key, and the other that it was a TLS 1.2 PSK, which is obviously a plausible threat. Regards, Jonathan On Fri, 15 Jun 2018, 17:13 Benjamin Kaduk, wrote: > On Fri, Jun 15, 2018 at 05:26:33PM +0200, Jonathan Hoyland wrote: > > Agreement on a channel binding in the identity would prove, amongst other > > things, agreement on the KDF used to derive the PSK, whereas the TLS > > handshake proves agreement on the PSK itself, but says nothing about the > > derivation of it. > > This way means you don't have to worry about collisions between hash > > functions, as long as the channel binding is correctly constructed. > > While this is an interesting way to think about things, it's unclear to me > how general it is for framing the problem. That is to say, there is not > necessarily a "channel" used to provision what TLS 1.3 calls "external > PSKs". > My model for them includes an administrator typing a hex string into a > configuration > file on both ends of the connection, or a manufacturer burning a key into > ROM > for an IoT device -- what would the "channel" be those cases? (Or do I > completely > misunderstand what you're trying to do?) > > -Ben > --000000000000598ffb056eb099a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Channel bindings are generally just horribly named.

The = `channel` in that case would consist solely of the agreed key, and agreemen= t on it would prove that not only was that the key, but also that nothing e= lse was established.=C2=A0
Therefore you wouldn't be able to = convince one side that it was just a manually entered key, and the other th= at it was a TLS 1.2 PSK, which is obviously a plausible threat.
<= br>
Regards,

Jonathan

On Fri, 15 Jun 2018, 17:13 Benjamin= Kaduk, <bkaduk@akamai.com> = wrote:
On Fri, Jun 15, 2018 at 05:2= 6:33PM +0200, Jonathan Hoyland wrote:
> Agreement on a channel binding in the identity would prove, amongst ot= her
> things, agreement on the KDF used to derive the PSK, whereas the TLS > handshake proves agreement on the PSK itself, but says nothing about t= he
> derivation of it.
> This way means you don't have to worry about collisions between ha= sh
> functions, as long as the channel binding is correctly constructed.
While this is an interesting way to think about things, it's unclear to= me
how general it is for framing the problem.=C2=A0 That is to say, there is n= ot
necessarily a "channel" used to provision what TLS 1.3 calls &quo= t;external PSKs".
My model for them includes an administrator typing a hex string into a conf= iguration
file on both ends of the connection, or a manufacturer burning a key into R= OM
for an IoT device -- what would the "channel" be those cases?=C2= =A0 (Or do I completely
misunderstand what you're trying to do?)

-Ben
--000000000000598ffb056eb099a3-- From ben.personick@iongroup.com Tue Jun 12 13:15:08 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CC4130E8C for ; Tue, 12 Jun 2018 13:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.063 X-Spam-Level: X-Spam-Status: No, score=0.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iontradingcom.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6vOA1OJ_Fwi for ; Tue, 12 Jun 2018 13:15:05 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0046.outbound.protection.outlook.com [104.47.34.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B092D130E27 for ; Tue, 12 Jun 2018 13:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iontradingcom.onmicrosoft.com; s=selector1-iongroup-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KuEdmlvJErfEtLFCKiReM3qpYcbX3FkR+vRIXJelErg=; b=sZ62kNaOY2rq0zPK1JnN0rRBYj311V12OM4IobeRbIDKfyjUKfJKJtyVMFZ/CGx783ItN2b9rzYle5pfIZEYLSD48HPjGsSAnVa/eRytM7StDpsHhSZVlgmDy0oIfxonp7XhUzZSDKD/6kYTi4T89+I1GpzAzQ1N0RaUrRsNgYo= Received: from BN7PR14MB2356.namprd14.prod.outlook.com (20.176.22.33) by BN7PR14MB2417.namprd14.prod.outlook.com (20.176.22.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.17; Tue, 12 Jun 2018 20:15:04 +0000 Received: from BN7PR14MB2356.namprd14.prod.outlook.com ([fe80::a9e2:c89b:1680:bf6a]) by BN7PR14MB2356.namprd14.prod.outlook.com ([fe80::a9e2:c89b:1680:bf6a%4]) with mapi id 15.20.0841.019; Tue, 12 Jun 2018 20:15:04 +0000 From: Ben Personick To: "tls@ietf.org" Thread-Topic: Mail regarding draft-ietf-tls-tls13 Thread-Index: AdQCh415dfE0g1svTxONss1UmLapVw== Date: Tue, 12 Jun 2018 20:15:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ben.personick@iongroup.com; x-originating-ip: [38.108.249.203] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN7PR14MB2417; 7:2iuA08Fq1rW6S2oq2hdAGI4Zpxqqf5gGKZ0FCY0IhCB+GFZr2LSBxTZS68QHOsgnfxPANOuZDyw2XvMjppaLZX8lLplNhtQql786Pt/EH/V7OKrpVJVe6JHY1dcROfmHjEcCPOakVDNLFLYkUfJWaCn39ROvOrzvWa7yuongVkyTA2jCzTMLMdA5JTczAEDXvcVSpn2tL3xReE8VLJoAOieI+NyEytFmtvFqS0AX+vtdnSvu5j6JKr91JjaMWXFC x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN7PR14MB2417; x-ms-traffictypediagnostic: BN7PR14MB2417: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:BN7PR14MB2417; BCL:0; PCL:0; RULEID:; SRVR:BN7PR14MB2417; x-forefront-prvs: 07013D7479 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(39860400002)(39380400002)(396003)(189003)(199004)(5640700003)(55016002)(14454004)(25786009)(7736002)(561944003)(86362001)(74316002)(8676002)(97736004)(1730700003)(81166006)(81156014)(9686003)(6306002)(54896002)(53936002)(6436002)(8936002)(66066001)(105586002)(33656002)(2906002)(3846002)(316002)(102836004)(6916009)(6506007)(476003)(5660300001)(7696005)(26005)(478600001)(186003)(68736007)(44832011)(99286004)(5630700001)(2900100001)(486006)(3660700001)(2501003)(5250100002)(6116002)(790700001)(3280700002)(106356001)(2351001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR14MB2417; H:BN7PR14MB2356.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: iongroup.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: /fSuQ7b+33gAom2T9n2i//5/7xONkAl1XOW/ybKcNpcCJyUDC/xi3KyitdqCjhFTRkf0EJ1bnQN72kQAPekRv2peqj9vDZbsaVpYiw/q/q3Z0s2HJVIwKMv+7wjwatkoFDe49e0l0L5TAV2RH6JopCgYRyQQ9lkrcfekjyNqqE0P68QKW9Zu3KdIclmMlRbF spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN7PR14MB23560D791932A8CB164C592D917F0BN7PR14MB2356namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 47033664-08fc-4dc3-6d59-08d5d0a12f5a X-OriginatorOrg: iongroup.com X-MS-Exchange-CrossTenant-Network-Message-Id: 47033664-08fc-4dc3-6d59-08d5d0a12f5a X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2018 20:15:04.3759 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 768fe7d4-ebee-41a7-9851-d5825ecdd396 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR14MB2417 Archived-At: X-Mailman-Approved-At: Sat, 16 Jun 2018 19:54:43 -0700 Subject: [TLS] Mail regarding draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2018 20:16:57 -0000 --_000_BN7PR14MB23560D791932A8CB164C592D917F0BN7PR14MB2356namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Sirs at the IETF, (My apology for the long email, I did not have time to write a shorter one) We are currently evaluating when to begin offering ECC Certificates based= cypto on our websites. Despite the advantages to doing this in TLS 1.2, there is a lot of push-b= ack to wait until we "have to support it" once the TLS 1.3 draft is publish= ed, and the option to use it becomes available. I have read some articles saying the draft is approved, but on looking it= seems not to be, I am a little unsure why the draft has been stuck in this= seemingly nearly finished but not quite ready state for 3 months. Surely if there were some way I could move this project forward I would, = but I am not an IETF member, so it seems my only option is to politely enqu= ire with you and note that at least some of us are stuck using only RSA cry= pto until such time as this draft gets finished, and provides us with the n= eeded emphasis to push our organizations to implement ECC cert cryptos "in = preparation to support tls 1.3" as it will actually be a standard. I have been pushing for us to begin to proffer ECC certificate based cryp= to for some time, but until TLS 1.3 is finally accepted as a standard we wi= ll continue to see a lot of push-back here, and I suspect this is not uniqu= e to our organization, and is likely partially responsible for strangely th= e slow adoption on the ECDSA cipher support. Do we have any realistic Idea of when this proposal will become approved? Knowing it is happening, will give me the push I need to get us to buy an = implement an ECC Certificate alongside our RSA Cert as we move forward so t= hat we can be "ready for tls 1.3" Thanks, Ben --_000_BN7PR14MB23560D791932A8CB164C592D917F0BN7PR14MB2356namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Sirs at the IETF,

(My apology for the long email, I did not have time to write a short= er one)

  We are currently evaluating when to begin off= ering ECC Certificates based cypto on our websites.

 

  Despite the advantages to doing this in TLS 1= .2, there is a lot of push-back to wait until we “have to support it&= #8221; once the TLS 1.3 draft is published, and the option to use it become= s available.

 

  I have read some articles saying the draft is= approved, but on looking it seems not to be, I am a little unsure why the = draft has been stuck in this seemingly nearly finished but not quite ready = state for 3 months.

 

  Surely if there were some way I could move th= is project forward I would, but I am not an IETF member, so it seems my onl= y option is to politely enquire with you and note that at least some of us = are stuck using only RSA crypto until such time as this draft gets finished, and provides us with the needed emphasis= to push our organizations to implement ECC cert cryptos “in preparat= ion to support tls 1.3” as it will actually be a standard.

 

  I have been pushing for us to begin to proffe= r ECC certificate based crypto for some time, but until TLS 1.3 is finally = accepted as a standard we will continue to see a lot of push-back here, and= I suspect this is not unique to our organization, and is likely partially responsible for strangely the slow adoption on the= ECDSA cipher support.

 

  Do we have any realistic Idea of when this pr= oposal will become approved?

 

 Knowing it is happening, will give me the push= I need to get us to buy an implement an ECC Certificate alongside our RSA = Cert as we move forward so that we can be “ready for tls 1.3”

 

Thanks,

 

Ben

 

 

--_000_BN7PR14MB23560D791932A8CB164C592D917F0BN7PR14MB2356namp_-- From nobody Sat Jun 16 20:04:47 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DF4130DDE for ; Sat, 16 Jun 2018 20:04:45 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qXyP-QJAB7A for ; Sat, 16 Jun 2018 20:04:43 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 B66911277CC for ; Sat, 16 Jun 2018 20:04:43 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id s9-v6so12524206qtg.2 for ; Sat, 16 Jun 2018 20:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=w4cEORejy9D0csc9xKlAlvjEFE/tE7g8iHuCef2GmMQ=; b=UCb9a5Tpr0vqrrIEVpqkHe0ADU1oX/EeVr2C+FbANU37FPNf6FrlpPi0G81zE+0Zc/ 9Z5n1kT3AlAmBWvhWv6Eza8ogPTcnHX5Qc+Bz/mnPnwtBXZVAbPvCbVWrqzvF/ZDYig4 kU4nQKxFVzcjLSc6FG8Yw4PU7lzFwqi9Vz0Cg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=w4cEORejy9D0csc9xKlAlvjEFE/tE7g8iHuCef2GmMQ=; b=igtKNWTbXjQsjXNjRhQJucT+aqBFSO8Bpp/lt+O2QH1T86f9ECg/9pTaG9bmpUXNZK IayJJhefHMT/zOeB4vMWT8gOfeG0+pjfsmxoIAFZA55/TvDXs8cASSKvUPKY1Ca4NRjc BUVtMkR5G8DAawqNxUbxZeiIFMHU1jDroBAPTf9cvwuR0nlhVZLb/+mTJYTR+kkCw5D1 2VhBrmLFmFr2csz0BKr7XkK87KyG0HWLn7/5OVCLCCROSBjpjLlJcJkqD/zy9Dw0j+xp AYfN+9kwBXiKEfjkZ4YgJKmtiKWG2XE8StIBcsgPN0FK5yl65WB7Mf4g+7BMMSx2IWzJ tL7w== X-Gm-Message-State: APt69E08addktwza5B3p8wcqJlY5jDTc0EIE73jSN9YRpYlfmvNhCq0i FPuvhX3dpMpLkrWdP7EueC6yuA== X-Google-Smtp-Source: ADUXVKKT/0r5Cix5wprE3nY2aB1sMCA819pzNasT7QxGd8Uvg4s5QBrFLRB2yetJ0p5T1vgINNIhsw== X-Received: by 2002:ac8:4407:: with SMTP id j7-v6mr6855058qtn.117.1529204682775; Sat, 16 Jun 2018 20:04:42 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.148]) by smtp.gmail.com with ESMTPSA id m70-v6sm9031785qkl.72.2018.06.16.20.04.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Jun 2018 20:04:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Sean Turner In-Reply-To: Date: Sat, 16 Jun 2018 23:04:40 -0400 Cc: "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ben Personick X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 17 Jun 2018 03:04:46 -0000 > On Jun 12, 2018, at 16:15, Ben Personick = wrote: >=20 > I have read some articles saying the draft is approved, but on = looking it seems not to be, I am a little unsure why the draft has been = stuck in this seemingly nearly finished but not quite ready state for 3 = months. The draft has been approved by the IESG. Once a draft is approved it = moves over to the RFC editor (and there=E2=80=99s some IANA review too); = here=E2=80=99s a link to the RFC editorial process [0]; here=E2=80=99s a = link to their publication queue [1]. 3 months is about what I expected = in terms of wait post approval. We=E2=80=99re nearly there. spt [0] https://www.rfc-editor.org/pubprocess/ [1] https://www.rfc-editor.org/current_queue.php= From nobody Sat Jun 16 20:31:48 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3B4128CF3 for ; Sat, 16 Jun 2018 20:31:46 -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 autolearn_force=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 mGnTRNiwCOKb for ; Sat, 16 Jun 2018 20:31:45 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E15128BAC for ; Sat, 16 Jun 2018 20:31:44 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 5C6E57A330D; Sun, 17 Jun 2018 03:31:43 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Viktor Dukhovni In-Reply-To: Date: Sat, 16 Jun 2018 23:31:42 -0400 Cc: "tls@ietf.org" Reply-To: TLS WG Content-Transfer-Encoding: quoted-printable Message-Id: <897AC345-0832-4252-9D96-5A030CBEAD25@dukhovni.org> References: To: Ben Personick X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 17 Jun 2018 03:31:47 -0000 > On Jun 12, 2018, at 4:15 PM, Ben Personick = wrote: >=20 > We are currently evaluating when to begin offering ECC Certificates = based cypto on our websites. > =20 > Despite the advantages to doing this in TLS 1..2, there is a lot of = push-back to wait until we =E2=80=9Chave to support it=E2=80=9D once the = TLS 1.3 draft is published, and the option to use it becomes available. I am puzzled why you feel you have to support ECC certificates with TLS 1.3, and yet not for TLS 1.2? RSA certificates continue to be supported in TLS 1.3, and ECDSA certificates are well supported in TLS 1.2. Are you referring to deploying ECC certificates in your server software, or interoperating with ECC servers in your client software? If the latter, then indeed you should start to support servers that can only present ECDSA, rather than RSA, certificates. And do so with both TLS 1.2 and TLS 1.3, it is not clear why you'd wait for TLS 1.3 to be published. (We can party when it comes out, but that should not IMHO hold up implementations of ECDSA support). --=20 --=20 Viktor. From nobody Mon Jun 18 02:41:53 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9211B130E3B for ; Mon, 18 Jun 2018 02:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 xUl-fbyZAUio for ; Mon, 18 Jun 2018 02:41:29 -0700 (PDT) Received: from mail-wm0-f50.google.com (mail-wm0-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 67401130DCF for ; Mon, 18 Jun 2018 02:41:29 -0700 (PDT) Received: by mail-wm0-f50.google.com with SMTP id p126-v6so12951124wmb.2 for ; Mon, 18 Jun 2018 02:41:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=LkTv9bxBOlbApzUX/CQx/QbUJT9v9gm3humptBW3AMU=; b=LZM62z2KGVej7jrOgmNN3PFTflCuGcyQFHaUZLhRwbBHER7Gcb+hNejUAcf5HtvMGR 3OsgOQ6d3//KTNK3XJjg0/1W0Z7rGNkaaKyC9yuToX7LhE6XQM/RmYenJlsXga1fLrvb NtcGphkWvB1RfH0ZkgLOfb7eAJBWbpgi5Dugjlc0QeCH++2lA8DmmFAu13y2ORt5eBln coB0YI+ZCwRJo0rLo0gerzBJckNEEcZcxqGrZaeqj+eX/R+F0gCukOJEcjT6tWykr1AC stawsw23P4rHI5scJN9xdmdgNaYTPjlyF3zv5oSf4I9L8Dbr86JxjfOvegxf/rCqm8Hi rWag== X-Gm-Message-State: APt69E0CARLfgbMotRSc490+HBSajSGKavXtEdqyu15I4YcGR77zFkBP bqiCDP1jYcdmBlN2K/Um1ex4RBl7fGI= X-Google-Smtp-Source: ADUXVKJtdDGC3rF+swsv0n7jbNjJK3DyLYO/8iAvRkhTNtyRdgwZkwWy4mLiGhtovbSnoVKIvlu1uQ== X-Received: by 2002:a1c:4a9d:: with SMTP id n29-v6mr7389635wmi.46.1529314887579; Mon, 18 Jun 2018 02:41:27 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id a184-v6sm7991953wmf.30.2018.06.18.02.41.26 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 18 Jun 2018 02:41:26 -0700 (PDT) Message-ID: <5461a61b9b22446ef38841c8eda16381b7fa8628.camel@redhat.com> From: Nikos Mavrogiannopoulos To: tls@ietf.org, tls@ietf.org Date: Mon, 18 Jun 2018 11:41:25 +0200 In-Reply-To: <16A9FD3A-7805-4130-8438-39D0D3E7E3AB@rhul.ac.uk> References: <16A9FD3A-7805-4130-8438-39D0D3E7E3AB@rhul.ac.uk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.2 (3.28.2-1.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [TLS] cost of padding removal in TLS1.3 [was: Possible timing attack on TLS 1.3 padding mechanism] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 18 Jun 2018 09:41:41 -0000 On Thu, 2018-03-01 at 21:52 +0000, Paterson, Kenny wrote: > Hi, > > I've been analysing the record protocol spec for TLS 1.3 a bit, > specifically the new padding mechanism. I think there's a possible > timing attack on a naïve implementation of de-padding. Maybe this is > already known to people who've been paying more attention than me! > > Recall that the padding mechanism permits an arbitrary number of 00 > bytes to be added after the plaintext and content type byte, up to > the max record size. This data is then encrypted using whichever AEAD > scheme is specified in the cipher suite. This padding scheme is quite > important for TLS 1.3 because the current AEAD schemes do leak the > length of record plaintexts. There should be no padding oracle style > attack possible because of the integrity guarantees of the AEAD > schemes in use. > > The idea for the timing attack is as follows. > > The natural way to depad (after AEAD decryption) is to remove the 00 > bytes at the end of the plaintext structure one by one, until a non- > 00 byte is encountered. This is then the content type byte. Notice > that the amount of time needed to execute this depadding routine > would be proportional to the number of padding bytes. If there's some > kind of response record for this record, then measuring the time > taken from reception of the target record to the appearance of the > response record can be used to infer information about the amount of > padding, and thereby, the true length of the plaintext (since the > length of the padded plaintext is known from the ciphertext length). Hi, I'd like to get back into that old thread because we've figured out that making the padding removal not depending on the data is quite costly for aes-gcm on a modern processor. Roughly, the record processing time drops by half for large packets comparing to TLS1.2, in effect pushing implementors to make the default padding removal time- variable. Has this performance drop been observed by others? regards, Nikos From nobody Mon Jun 18 02:47:34 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAC8130DCC for ; Mon, 18 Jun 2018 02:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.696 X-Spam-Level: X-Spam-Status: No, score=-2.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.795, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 JK_R4L1JlTXj for ; Mon, 18 Jun 2018 02:47:28 -0700 (PDT) Received: from mail-wr0-f172.google.com (mail-wr0-f172.google.com [209.85.128.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 7A9891277C8 for ; Mon, 18 Jun 2018 02:47:28 -0700 (PDT) Received: by mail-wr0-f172.google.com with SMTP id o12-v6so16079290wrm.12 for ; Mon, 18 Jun 2018 02:47:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=9dGimUyyzBLhxTdwMTYufFAX4sUQtjVekrJDDoXcyEc=; b=SEJoGbUiSYbqRiVOt4qVI9S06oobPJYiA7C0hrPyRoyYDPsK9AnZBZ/Q1yjlntfI6h l9WAx7ontC28URmTnpmcQ58TNqJW92eB1UFKheHUw3R+1lmFa9BKM8V2J9SFBwGGmlee odEf0xA+tWxTikCDTmOPIXauLpwNTLcb1143JrGMNU5KK/H70u099ZN+rViO1NAjocSw e/GWn/cyX7zWDpRxixBjQgyJKnnFIu/MoSjcK3XEKStx7BR/kO2k6umH72QzgQso3hnl XZ/+AEYxHLqC16Bn9S28oJkblNO3402JqAcBhxMMQN+4Wf2bIiJi7c1qF9llGgeGgbNs VJkQ== X-Gm-Message-State: APt69E05Jz5Kou2nhu4s3jDQGj1rMhFamZbpiOLgQhA0fVf9tIJkYlnX Wfh2E+4qIESARjb6HkhIRA0v6H7v26o= X-Google-Smtp-Source: ADUXVKJuvS/pSRdfBY2tjf/PtYSmWu7Op2Ukna3Q8LmSA7FTBxoEm3P7b9Eq4Ojk+xkmtJeVoqrClQ== X-Received: by 2002:adf:ae8b:: with SMTP id y11-v6mr10465926wrc.234.1529315246998; Mon, 18 Jun 2018 02:47:26 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id w67-v6sm7727368wmw.0.2018.06.18.02.47.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 18 Jun 2018 02:47:26 -0700 (PDT) Message-ID: <3a8d1eab6bbf042c396da1085427f49da8d4c2f4.camel@redhat.com> From: Nikos Mavrogiannopoulos To: "Salz, Rich" , "tls@ietf.org" Date: Mon, 18 Jun 2018 11:47:25 +0200 In-Reply-To: <7BE4BC91-5324-42A6-8AB7-084439ED9527@akamai.com> References: <2132206.KQKFhKinhY@pintsize.usersys.redhat.com> <7BE4BC91-5324-42A6-8AB7-084439ED9527@akamai.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.2 (3.28.2-1.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Universal PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 18 Jun 2018 09:47:34 -0000 On Fri, 2018-06-15 at 14:24 +0000, Salz, Rich wrote: > > that's not workable. > > > It's not great, however > > > the reason why implementations chose to use old API to provision > > TLS 1.3 PSKs > > was to make the upgrade process as smooth as possible, disabling > TLS 1.3 is > quite antithetical to that > > Disabling TLS 1.3 for those using 1.2 PSK's is unlikely to affect > most uses, and seems the only way forward. > > Do you have an alternative solution? TLS 1.3 provides a solution. These secrets under TLS1.3 are restricted to using the SHA256 PRF. That's how we have implemented it in gnutls. regards, Nikos From nobody Mon Jun 18 03:03:28 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCFB130DD1 for ; Mon, 18 Jun 2018 03:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 cNeOnJbTNIZW for ; Mon, 18 Jun 2018 03:03:24 -0700 (PDT) Received: from mail-wm0-f44.google.com (mail-wm0-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 5091F1277C8 for ; Mon, 18 Jun 2018 03:03:24 -0700 (PDT) Received: by mail-wm0-f44.google.com with SMTP id p126-v6so13062468wmb.2 for ; Mon, 18 Jun 2018 03:03:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=Em0kAV76apbwIhTWzRJhIYy4j3uMBtE3v6f6FJrlb3Q=; b=Yz+syYPDB6qaft59uf7kJW+dT+EPP5ZWa3xSrHAQREaYd1hzvJzQWCajtI0dbGMiuj BQBD3eHxBxXE51hCAV80NN6oDhMiEnBCi5mBwh4K98YP+kMQwJOC+HCoWdcPOXNTM3PY zpxmq3Yj4VAh8h8HbbQ8Ml8zYyvqWirRzclF5GM9JKpq7nH4+SGz6kZbomOwNXFiK/Xd HvhhgEJBZFaI1JzMDDUPkH7w9Wqux6nmys9vUtDAGBHqcOPzLYqrEJUwcg1j8AnLxbWV IEl9MuKo4o5yGcOhYZN9ENanTT5oGuARD11SpnrK8uYpnfP8FKNkq8kmFNLel1/A9p9k jeyA== X-Gm-Message-State: APt69E2itacKVTLosf7ui2tcFbx+pQCBs4GCGpuuJlKOH+lP3sHZdxT2 NoykR7dYkUqJN2CCFtGNLbI9/A== X-Google-Smtp-Source: ADUXVKJk7ElHJK5ebFiGLBS6hOb3gobXfAa+GPgWyz2QenvrY/Q+dO7IWYpqiMm0r+IAUcYoWBMtjw== X-Received: by 2002:a1c:4405:: with SMTP id r5-v6mr7382663wma.62.1529316202821; Mon, 18 Jun 2018 03:03:22 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id c11-v6sm14784492wrm.65.2018.06.18.03.03.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 18 Jun 2018 03:03:21 -0700 (PDT) Message-ID: <05cdb4e210d6712277de31402ec140da6f64ca26.camel@redhat.com> From: Nikos Mavrogiannopoulos To: David Benjamin , Hubert Kario Cc: tls@ietf.org Date: Mon, 18 Jun 2018 12:03:21 +0200 In-Reply-To: References: <2132206.KQKFhKinhY@pintsize.usersys.redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.2 (3.28.2-1.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Universal PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 18 Jun 2018 10:03:27 -0000 On Fri, 2018-06-15 at 09:11 -0400, David Benjamin wrote: > On Fri, Jun 15, 2018 at 7:14 AM Hubert Kario > wrote: > > On Thursday, 14 June 2018 21:46:27 CEST David Benjamin wrote: > > > Thoughts? If the WG likes this design, I would suggest: > > > > > > - Most folks who want to use TLS 1.3 with external PSKs should > > probably > > > design their protocols to provision universal PSKs instead, after > > it > > > stabilizes. > > > > > > - Folks who want to use TLS 1.3 with existing TLS 1.2 PSKs should > > use the > > > compatibility derivation in this draft, after it stabilizes. > > > > > > - Folks who want to ship TLS 1.3 before then and have a TLS 1.2 > > PSK API > > > should not use the 1.2 PSK as a 1.3 PSK. For now, just turn TLS > > 1.3 off by > > > default if that API is used and, in a future release, use the > > compatibility > > > derivation after it stabilizes. > > > > that's not workable. > > > > the reason why implementations chose to use old API to provision > > TLS 1.3 PSKs > > was to make the upgrade process as smooth as possible, disabling > > TLS 1.3 is > > quite antithetical to that > > Indeed. That is why the TLS 1.2 compatibility section exists. :-) So > that implementations in that position can reuse TLS 1.2 PSK APIs in > TLS 1.3 while honoring the security proof. > > But, unfortunately, there's a slight timing issue. There's no way > some random draft published yesterday will be finalized before TLS > 1.3. So implementations with TLS 1.2 PSK APIs would need to either > violate the TLS 1.3 security proof or not ship TLS 1.3 until this > draft finalizes. Is key separation between TLS1.3 and TLS1.2 something that TLS1.3 provides or intended to provide? As I mentioned in my reply TLS1.3 design goals were very apparent that keys will be re-used from TLS1.2, and this is what is happening today for any kind of keys from RSA to PSKs. I'm not sure I see a new cross-protocol violation here that was not discussed during the TLS1.3 process. regards, Nikos From nobody Mon Jun 18 03:05:45 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1E7130DD1 for ; Mon, 18 Jun 2018 03:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 26q531KRan1X for ; Mon, 18 Jun 2018 03:05:42 -0700 (PDT) Received: from mail-wm0-f51.google.com (mail-wm0-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 4DD891277C8 for ; Mon, 18 Jun 2018 03:05:42 -0700 (PDT) Received: by mail-wm0-f51.google.com with SMTP id o13-v6so12998225wmf.4 for ; Mon, 18 Jun 2018 03:05:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=lzmJOn8JXJwt7p0I4/LGvbCnCWVyxousB1DBHbWPvS4=; b=TKjWIl7FEVPmOu8gV2Ip0Zu+TPF13To46kV6H0bDj5Pkj4vMs0iNw2Cx6TG+wzcuAI BsyeWPOf7nmE5BrD65BWwqq03o91mK6uSq/xs3DZp7i7xJbShf1UVnDq32kevdPo43k7 WbxAzbczPCahjI5BWk69hZ4Hy7v/3xv1Wuj3t7QFqNXrZsLXvd6RLmuyAqkxIxb39mMM sbhHz/EvPI7uSnL0DjFAuObOUk/oDXTyC6LRaB0hstwgp+oZNlmSJYGvTXtbIhmN1Q15 UyK+DRqg1fs0cisDiGkS62thyFCwH01UkfpiRqyo0nTWxbG/s8E+aV3zqiUUxRYqZZVc zGcg== X-Gm-Message-State: APt69E0hdBwa45+0yz8mkBV5EK3BhD9UWm4WwCd0eYGMpn808G8S3o2N VUfpxLPawURp4kVBitCwcbUhkkt/cmU= X-Google-Smtp-Source: ADUXVKLx4hn3THgvQ6zw0hhOlC9H7laM8HhC3GSDIku5h7vTJzbC3iqMMUTgXY7rSL9oXt1sDsZ/Pg== X-Received: by 2002:a1c:852:: with SMTP id 79-v6mr7933158wmi.115.1529316340824; Mon, 18 Jun 2018 03:05:40 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id e81-v6sm9931470wmi.28.2018.06.18.03.05.39 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 18 Jun 2018 03:05:39 -0700 (PDT) Message-ID: From: Nikos Mavrogiannopoulos To: Matt Caswell , tls@ietf.org Date: Mon, 18 Jun 2018 12:05:39 +0200 In-Reply-To: References: <7e5945f3c6bf9d8168a862f45bc00100cded1802.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.2 (3.28.2-1.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Universal PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 18 Jun 2018 10:05:44 -0000 On Fri, 2018-06-15 at 13:00 +0100, Matt Caswell wrote: > > On 15/06/18 12:37, Nikos Mavrogiannopoulos wrote: > > It feels that's this is too little too late. Implementations which > > support PSKs will switch to TLS1.3 irrespective of this proposal. > > If > > this proposal takes on, we will have some implementations which > > support > > universal PSKs and others which don't leading to interoperability > > problems which we wouldn't have otherwise. > > I'm not sure how many TLS1.3 implementations there are out there that > also have TLS1.2 PSK support. OpenSSL is one of them. We have APIs > for TLS1.2 PSKs and different APIs for TLS1.3 PSKs. Currently > applications > using the old APIs can still expect those PSKs to work in TLS1.3. In > light of this proposal we are considering removing our TLS1.2 -> > TLS1.3 > PSK code and instead restricting applications using TLS1.2 PSK APIs > to > only TLS1.2 until this is resolved (although unfortunately that would > mean removing it from our upcoming LTS release). In gnutls [0] we have the same APIs for PSK under TLS1.2 and TLS1.3 and the transition is quite smooth, but in contrast to David's algorithm, we select a PSK before selecting the ciphersuite in order to make that work. The problem I see is that PSKs are restricted to SHA256 KDF and thus AES128 which is somewhat ugly but we can live with it until we provide a better way to mark a specific PRF in our key files. regards, Nikos [0]. https://nikmav.blogspot.com/2018/05/gnutls-and-tls-13.html (PSK key exchange) From nobody Mon Jun 18 04:22:21 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5F8130E96 for ; Mon, 18 Jun 2018 04:22:19 -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 autolearn_force=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 5rV7Q_Rr7f27 for ; Mon, 18 Jun 2018 04:22:12 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F01D124BE5 for ; Mon, 18 Jun 2018 04:22:12 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9045F7DAC3; Mon, 18 Jun 2018 11:22:11 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1DFEF2026D68; Mon, 18 Jun 2018 11:22:10 +0000 (UTC) From: Hubert Kario To: "Salz, Rich" Cc: "tls@ietf.org" Date: Mon, 18 Jun 2018 13:22:04 +0200 Message-ID: <4207179.CySPfdG7iZ@pintsize.usersys.redhat.com> In-Reply-To: <7BE4BC91-5324-42A6-8AB7-084439ED9527@akamai.com> References: <2132206.KQKFhKinhY@pintsize.usersys.redhat.com> <7BE4BC91-5324-42A6-8AB7-084439ED9527@akamai.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2571722.glvm2Kta8V"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Mon, 18 Jun 2018 11:22:11 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Mon, 18 Jun 2018 11:22:11 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] Universal PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 18 Jun 2018 11:22:20 -0000 --nextPart2571722.glvm2Kta8V Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 15 June 2018 16:24:58 CEST Salz, Rich wrote: > > that's not workable. >=20 > =20 > It's not great, however > =20 >=20 > > the reason why implementations chose to use old API to provision TLS > > 1.3 PSKs=20 > > was to make the upgrade process as smooth as possible, disabling TLS > > 1.3 is quite antithetical to that > =20 > Disabling TLS 1.3 for those using 1.2 PSK's is unlikely to affect most us= es, > and seems the only way forward. =20 > Do you have an alternative solution? I don't see a reason to fragment the TLS 1.3 landscape "5 minutes" after th= e=20 release TLS 1.3, even if you consider it small fragmentation. Correct solution was to include it in the TLS 1.3 proper. Now we have a TLS 1.3 draft which says: Prior to accepting PSK key establishment, the server MUST validate the corresponding binder value (see Section 4.2.11.2 below). If this value is not present or does not validate, the server MUST abort the handshake.=20 and a proposed change to it that doesn't say anything about differentiating= =20 between universal binders and regular binders. And forces those new binders= to=20 SHA-256 where previously it was selectable. So, either it is a severe issue and we should rework TLS 1.3 draft, or this= =20 draft needs to be significantly reworked before it will not cause huge=20 interoperability headaches =E2=80=93 signalling extension is the bare minim= um, most=20 likely a new PSK extension is necessary. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart2571722.glvm2Kta8V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlsnldwACgkQkqjRuAHS 9fX12RAAnNBDTFqEN1Korrtfbzm9qpCzJpXXa0kngMec7YYOx0hNLBT3pgTrqtHE DgGh+MgkHc4NnegMiH3SyH0BahpUYufePRosq+XPIRif+nxldPVnDqTPgRxCUdRK jrJ+jSLtL7FQ0vji1PG2H0lY+YQkCwPOUYnl3aHlzgviwNCcBxD0CPq4JfasHjKu CM9151YOk7gabMKQOQL4Sunf+mIR5uSDNOSN5FV4QkUiwraH+E0F6bZndaathI18 kdfcYvP28XXxJodUVOd5rfEW2WW3bYtVn9tpNrxoafwOuDE3Kt0qLBekQvo7pBYI Rs0C3xMFd4Auy0OI2U3byD2dVgCjJ8TgYwevg+qDcxv4wQm60VEZT0tvU24X3EH7 gInlk29gLKyvO1tqMCIJS/E92QNDQTndbCojBcvwdHwMJRbOSDBSAQYKSEYSWxps vJ7LXAEfzwxmTP/bjKra+2v5K8oVp30R4c8RHhlzqLJaT495yrcm3CsUXFb5bTV1 +4/5o5Ua+18PKLcnlGWQie97CGA7CSdB3UPiW+8v7xQ747GmfkXZqjj12RhsnwDQ h2kz2anOtqmdHwscRj5FJMgrTWSV5H05Ya41+nXRAnhkfjmadLXSPUXY+mbMHNgw ydLbn+Y265gZtLZDBjmDNdw4h1J/wCbDexoe3BEHU/ky5SGhdeQ= =rh9D -----END PGP SIGNATURE----- --nextPart2571722.glvm2Kta8V-- From nobody Mon Jun 18 04:56:19 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE3E130EA5 for ; Mon, 18 Jun 2018 04:56:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VVsYn7ln3eb for ; Mon, 18 Jun 2018 04:56:14 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 6E0D6130E96 for ; Mon, 18 Jun 2018 04:56:14 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id z16-v6so10469606uaz.10 for ; Mon, 18 Jun 2018 04:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xim4i6JbvGHULQ6Xyz65HiuwNtVQEneZapTN6Szcjkw=; b=gUaXg190l5hDafjF4Dkdu1+4Vosju2hptCczAa0HClfImc5J1Lcitko57XcWve6yzG GI+oX5gd2LnimjXmKiqbKUMRqbAxy0TxvY468Wg2q8QxkISpyLMQvJd9Y6KK0Vm4/CB7 Fz1RDPRWc+e/7GWg7yW/Oj1dqad/x4baQ3FNI0mLoh+pMxUQHACenlAzmce9tRUt9/d0 hMOHk07Jjl/iELdW2Fkcz84tAvrYHWu2CdXnkJSx5l9nt/uLwXcF5A6IOmjU9NmYpYHT K/D0n1UuaDJGXbWKjMaccZ5yMZ1c7qmQfjHaxuYEFoHb/VKOWOvkjtb3IyJePS/itEjw /adA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xim4i6JbvGHULQ6Xyz65HiuwNtVQEneZapTN6Szcjkw=; b=fPU3/IfbUO9l/CcWiyDlFfppSI2y1pm6i65s7rCbsQzrifoSoAhSbEntrAnLukhC0J ruTgtUcxLgY/+ujzIRM4HMwNo85/vP16asU89LhuVYNl2nq2dh1FW8jFcr2+X0mMPOZp SbuLwvIQZdQolLExbg/eA6n07eoibQ5KOs4DK5ngSaR7L7C5/HmTk1fiAzGeM0kQng2N eIU3+FV1BJ5LqPS6ATOOxktfhEaS6LmCHmV/UIFA2XIHdm+6GKJ4L+6olvGjP4xcGtcZ dDpyP29+H/zoRWrZB0Xx6x5GxCQmHcnarIr7MTBS855UKBiItJcIhE00brKri9YeUj7l Fceg== X-Gm-Message-State: APt69E3WDClTKpe0wBh4xQW4t2vg1mFqqsQVKPA5aWCAoYLDBRpPzCTM 0AOTkEj+DnXbTmer4U3T0bdUF8peE6+tyScrs/8= X-Google-Smtp-Source: ADUXVKL3gNM5+abotS070Uf++Py6KuduD9Ajhqym/fhq+gn9WVxjENOwncsbqn0l6bH95MnzW5Y1wM/Tb3Rivrz/mwY= X-Received: by 2002:ab0:49ce:: with SMTP id f14-v6mr7490146uad.143.1529322973363; Mon, 18 Jun 2018 04:56:13 -0700 (PDT) MIME-Version: 1.0 References: <2132206.KQKFhKinhY@pintsize.usersys.redhat.com> <7BE4BC91-5324-42A6-8AB7-084439ED9527@akamai.com> <4207179.CySPfdG7iZ@pintsize.usersys.redhat.com> In-Reply-To: <4207179.CySPfdG7iZ@pintsize.usersys.redhat.com> From: Jonathan Hoyland Date: Mon, 18 Jun 2018 13:56:01 +0200 Message-ID: To: Hubert Kario Cc: "Salz, Rich" , "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009303dd056ee940f4" Archived-At: Subject: Re: [TLS] Universal PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 18 Jun 2018 11:56:18 -0000 --0000000000009303dd056ee940f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The issue with the current draft is that it leaves a single PSK with two potential interpretations. If the draft also changed the PSK identity value then each PSK would have a single interpretation. If the draft changes the identity then it can also change the PSK key without having to change the manner in which the binder is computed. In that case universal PSKs and regular PSKs do not need to be distinguished, because they are both validated in the same way. A server unaware of universal PSKs would simply see an unrecognised PSK identity. If both the unmodified and the modified PSKs are sent, then it can simply select the unmodified version, ignoring the other. A server that recognises both values can choose which to use. If the modified PSK identity was a channel binding, then the modified version would have stronger security properties, and thus presumably would be preferable. In this case the hash function used for the binder remains selectable. Would that resolve your issue? Regards, Jonathan Hoyland On Mon, 18 Jun 2018 at 12:22 Hubert Kario wrote: > On Friday, 15 June 2018 16:24:58 CEST Salz, Rich wrote: > > > that's not workable. > > > > > > It's not great, however > > > > > > > the reason why implementations chose to use old API to provision T= LS > > > 1.3 PSKs > > > was to make the upgrade process as smooth as possible, disabling T= LS > > > 1.3 is quite antithetical to that > > > > Disabling TLS 1.3 for those using 1.2 PSK's is unlikely to affect most > uses, > > and seems the only way forward. > > > Do you have an alternative solution? > > I don't see a reason to fragment the TLS 1.3 landscape "5 minutes" after > the > release TLS 1.3, even if you consider it small fragmentation. > > Correct solution was to include it in the TLS 1.3 proper. > > Now we have a TLS 1.3 draft which says: > > Prior to accepting PSK key establishment, the server MUST validate > the corresponding binder value (see Section 4.2.11.2 below). If this > value is not present or does not validate, the server MUST abort the > handshake. > > and a proposed change to it that doesn't say anything about > differentiating > between universal binders and regular binders. And forces those new > binders to > SHA-256 where previously it was selectable. > > So, either it is a severe issue and we should rework TLS 1.3 draft, or > this > draft needs to be significantly reworked before it will not cause huge > interoperability headaches =E2=80=93 signalling extension is the bare min= imum, > most > likely a new PSK extension is necessary. > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech > Republic_______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000009303dd056ee940f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The issue with the current draft is that it leaves a = single PSK with two potential interpretations.=C2=A0
If the draft= also changed the PSK identity value then each PSK would have a single inte= rpretation.
If the draft changes the identity then it can also ch= ange the PSK key without having to change the manner in which the binder is= computed.
In that case universal PSKs and regular PSKs do not ne= ed to be distinguished, because they are both validated in the same way.=C2= =A0

A server unaware of universal PSKs would simpl= y see an unrecognised PSK identity.
If both the unmodified and th= e modified PSKs are sent, then it can simply select the unmodified version,= ignoring the other.=C2=A0
A server that recognises both values c= an choose which to use.

If the modified PSK identi= ty was a channel binding, then the modified version would have stronger sec= urity properties, and thus presumably would be preferable.
In thi= s case the hash function used for the binder remains selectable. =C2=A0

Would that resolve your issue?

Regards,

Jonathan Hoyland

On Mon, 18 Jun 2018 at 12:22 Hubert K= ario <hkario@redhat.com> wro= te:
On Friday, 15 June 2018 16:24:5= 8 CEST Salz, Rich wrote:
> >=C2=A0 =C2=A0 that's not workable.
>
>=C2=A0 =C2=A0
> It's not great, however
>=C2=A0 =C2=A0
>
> >=C2=A0 =C2=A0 the reason why implementations chose to use old API = to provision TLS
> >=C2=A0 =C2=A0 1.3 PSKs
> >=C2=A0 =C2=A0 was to make the upgrade process as smooth as possibl= e, disabling TLS
> >=C2=A0 =C2=A0 1.3 is quite antithetical to that
>=C2=A0 =C2=A0
> Disabling TLS 1.3 for those using 1.2 PSK's is unlikely to affect = most uses,
> and seems the only way forward.

> Do you have an alternative solution?

I don't see a reason to fragment the TLS 1.3 landscape "5 minutes&= quot; after the
release TLS 1.3, even if you consider it small fragmentation.

Correct solution was to include it in the TLS 1.3 proper.

Now we have a TLS 1.3 draft which says:

=C2=A0 =C2=A0Prior to accepting PSK key establishment, the server MUST vali= date
=C2=A0 =C2=A0the corresponding binder value (see Section 4.2.11.2 below).= =C2=A0 If this
=C2=A0 =C2=A0value is not present or does not validate, the server MUST abo= rt the
=C2=A0 =C2=A0handshake.

and a proposed change to it that doesn't say anything about differentia= ting
between universal binders and regular binders. And forces those new binders= to
SHA-256 where previously it was selectable.

So, either it is a severe issue and we should rework TLS 1.3 draft, or this=
draft needs to be significantly reworked before it will not cause huge
interoperability headaches =E2=80=93 signalling extension is the bare minim= um, most
likely a new PSK extension is necessary.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic= _______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000009303dd056ee940f4-- From nobody Mon Jun 18 06:18:25 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E91130DE7 for ; Mon, 18 Jun 2018 06:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 F2uDxlKzMdBz for ; Mon, 18 Jun 2018 06:18:22 -0700 (PDT) Received: from mail-wm0-f44.google.com (mail-wm0-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 E3D4E130DE5 for ; Mon, 18 Jun 2018 06:18:21 -0700 (PDT) Received: by mail-wm0-f44.google.com with SMTP id v131-v6so15545553wma.1 for ; Mon, 18 Jun 2018 06:18:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=bbZxhVuupt3WS/vEzwM2MxgNf6Ro+TaSnYz1mdlHY10=; b=ZtFsOKwbqi0wPnvFgEW4WvbVCLXjRHSU1XJy5RSmMubuxvxdLIbcsv6ExQHGyvZdfZ zqZzDmRQotwXkN5f6mffPnFJUriZm2U6leaGtkPpgAA6BhoRazHay2oVCqYUFJp2NNJr OCRCyXojG4zQFYy+TWUgV5CG+OL8nDZqONM4wuvKyI+oSdmpSxB42DBplIrB6YdXYAco PXM3aNxjgZyOmkDYvjcXmbHFWlKSPv2i2McLBt2u/X983VhXcUYUVaOtEcLhZKSe4im7 jrAf1J3o0fOFgq3z/u3+sOKH+0GBTkzABSHq5UlQPdMz32qVQ19/s1/NUTm3LZ9JK3BP dnEg== X-Gm-Message-State: APt69E0Nbpx9SnfoeDTNlhPWz5HbX+GBrpLbgnzjkfWVCJRXCDfuhC84 g9RL07ueHDGwXiVyZyCPPKnZdg== X-Google-Smtp-Source: ADUXVKIjgl7yXEz82xGyQMeMPe8JI9iDQXxly2su08c+m6j+JuFU+Gr4fYfwGX2Un9Tnf3Ot4MF62Q== X-Received: by 2002:a1c:7506:: with SMTP id o6-v6mr8855237wmc.60.1529327900484; Mon, 18 Jun 2018 06:18:20 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id f81-v6sm13672566wmh.32.2018.06.18.06.18.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 18 Jun 2018 06:18:19 -0700 (PDT) Message-ID: From: Nikos Mavrogiannopoulos To: Jonathan Hoyland , Hubert Kario Cc: "tls@ietf.org" Date: Mon, 18 Jun 2018 15:18:19 +0200 In-Reply-To: References: <2132206.KQKFhKinhY@pintsize.usersys.redhat.com> <7BE4BC91-5324-42A6-8AB7-084439ED9527@akamai.com> <4207179.CySPfdG7iZ@pintsize.usersys.redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.2 (3.28.2-1.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Universal PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 18 Jun 2018 13:18:25 -0000 On Mon, 2018-06-18 at 13:56 +0200, Jonathan Hoyland wrote: > The issue with the current draft is that it leaves a single PSK with > two potential interpretations. > If the draft also changed the PSK identity value then each PSK would > have a single interpretation. > If the draft changes the identity then it can also change the PSK key > without having to change the manner in which the binder is computed. > In that case universal PSKs and regular PSKs do not need to be > distinguished, because they are both validated in the same way. > > A server unaware of universal PSKs would simply see an unrecognised > PSK identity. > If both the unmodified and the modified PSKs are sent, then it can > simply select the unmodified version, ignoring the other. > A server that recognises both values can choose which to use. > > If the modified PSK identity was a channel binding, then the modified > version would have stronger security properties, and thus presumably > would be preferable. > In this case the hash function used for the binder remains > selectable. > > Would that resolve your issue? That may not be sufficient. A server which sees an unrecognized PSK may chose to pretend it recognized it to avoid user enumeration attacks similarly to TLS1.2 (optional) behavior. Hence a modified username would cause negotiation failure with such a server. A new extension seems to be necessary to eliminate any interoperability issues with servers that will not follow the universal psk draft. regards, Nikos From nobody Mon Jun 18 06:29:45 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07457130DE7 for ; Mon, 18 Jun 2018 06:11:00 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iontradingcom.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6V5J9j8OlP5l for ; Mon, 18 Jun 2018 06:10:56 -0700 (PDT) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710066.outbound.protection.outlook.com [40.107.71.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB38A126DBF for ; Mon, 18 Jun 2018 06:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iontradingcom.onmicrosoft.com; s=selector1-iongroup-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pJhJr+I8cpewTdBqu4VJrxt7R8QTUXz37HEziAZEWnA=; b=fdlrUmiqckFCySSsEL0zzHwuzP80/EEkYRr2XvdVXNT9nCYBYe6drcwOe887S10B1H/yGi/yMniCAmVjTvx0G5slLRG9ajeANZ8BG+GM6hvF9GZg8CmuGWDgQuyN7SVUCS3EGtjTI+0AKeZDHX4v+wmSblPHRRnhUYfXOZvBKPU= Received: from BN7PR14MB2356.namprd14.prod.outlook.com (20.176.22.33) by BN7PR14MB2418.namprd14.prod.outlook.com (20.176.22.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.19; Mon, 18 Jun 2018 13:10:55 +0000 Received: from BN7PR14MB2356.namprd14.prod.outlook.com ([fe80::ac24:4123:784d:29f7]) by BN7PR14MB2356.namprd14.prod.outlook.com ([fe80::ac24:4123:784d:29f7%3]) with mapi id 15.20.0863.016; Mon, 18 Jun 2018 13:10:55 +0000 From: Ben Personick To: TLS WG Thread-Topic: [TLS] Mail regarding draft-ietf-tls-tls13 Thread-Index: AdQCh415dfE0g1svTxONss1UmLapVwDZCf0AAEaFOTY= Date: Mon, 18 Jun 2018 13:10:55 +0000 Message-ID: References: , <897AC345-0832-4252-9D96-5A030CBEAD25@dukhovni.org> In-Reply-To: <897AC345-0832-4252-9D96-5A030CBEAD25@dukhovni.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ben.personick@iongroup.com; x-originating-ip: [174.203.34.110] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN7PR14MB2418; 7:mNGb8Idd2ZOaFrwmUky5tMW5dyx3pWUOXritR1mC8pZClNBVqVpEF8cL8LOjJGFX8FqgcDGqIgL5boP8X2rpSkov1d77k7mjqiNaswz4ZUlnhdfp3nwGIy5uqXY9xg/gI1QiqSz57xdjHv4HdcGi6ZQ6GrBtk6df5KCYnyx3vOxWj6KH048ZgJIggUJ/khwl6YkU946+VBmfao4VwixpTAUO/vQusKG19d/yWFZBPGdvfp1c4h/nBWD1w+gJB3RL x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 9cf04d2e-f1dd-4528-4b99-08d5d51ced09 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:BN7PR14MB2418; x-ms-traffictypediagnostic: BN7PR14MB2418: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:BN7PR14MB2418; BCL:0; PCL:0; RULEID:; SRVR:BN7PR14MB2418; x-forefront-prvs: 0707248B64 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39860400002)(39380400002)(376002)(366004)(189003)(199004)(486006)(5660300001)(31696002)(6246003)(81166006)(81156014)(2616005)(11346002)(446003)(99286004)(8936002)(54896002)(76176011)(86362001)(7736002)(6512007)(3280700002)(44832011)(186003)(5250100002)(476003)(53936002)(8676002)(3660700001)(6486002)(14454004)(26005)(6916009)(2906002)(229853002)(66066001)(68736007)(36756003)(316002)(6436002)(2900100001)(478600001)(31686004)(25786009)(106356001)(97736004)(3846002)(6116002)(6506007)(105586002)(102836004)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR14MB2418; H:BN7PR14MB2356.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: iongroup.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: o3axErGecm93R96aGArx4RFkn+WTnltlCkYSTnT1IOrb9Qd2FYPJNQQ/dscgvuVAEblVbGtLv2m7hDQyyb65/hZcN9ir8li0jJJsW9y2FyE521HABIZstACWLDkYXDOp8/+XlnMlvhxTj0WM/6maUsMidF+r1lc65uSyHAhmHLyw5NX6razatUj9LCDVHpvC spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_cc5fe1d8b0654f308b7657714aea1949iongroupcom_" MIME-Version: 1.0 X-OriginatorOrg: iongroup.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9cf04d2e-f1dd-4528-4b99-08d5d51ced09 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2018 13:10:55.3371 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 768fe7d4-ebee-41a7-9851-d5825ecdd396 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR14MB2418 Archived-At: X-Mailman-Approved-At: Mon, 18 Jun 2018 06:29:44 -0700 Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 18 Jun 2018 13:11:00 -0000 --_000_cc5fe1d8b0654f308b7657714aea1949iongroupcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Viktor, Thanks for your thoughtful reply. I haven't read the draft itself, only the articals which point to it. There is a common thread circulating, that all support for RSA Certificat= es/Ciphers are dropped in TLS 1.3. As I wrote in the last email, I am aware we can implemenet ECC certs and = ciphers in TLS 1.2, along side RSA certs/ciphers, however there is a consis= tent fear of breaking what already works by moving onto offering both an EC= C and RSA certificate and corrosponding ciphers. If TLS 1.3 does support RSA certs, that removes the drive to begin offeri= ng ecdhe_ecdsa alongside ecdhe_rsa, which essentially moves it back to the = "Do not need to implement pile", which will not tick forward into the "must= implement" pile until it is absolutely required. I was sincerely hoping to be able to use the expected "end of ths RSA Cert"= to move us there in preparation of supporting TLS 1.3 and for once be ahea= d of the curve instead of implemementing what seems to be superiod encrypti= on methods much later. Ben ________________________________ From: Viktor Dukhovni Sent: Saturday, June 16, 2018 11:31 PM To: Ben Personick Cc: tls@ietf.org Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 > On Jun 12, 2018, at 4:15 PM, Ben Personick w= rote: > > We are currently evaluating when to begin offering ECC Certificates based= cypto on our websites. > > Despite the advantages to doing this in TLS 1..2, there is a lot of push-= back to wait until we =93have to support it=94 once the TLS 1.3 draft is pu= blished, and the option to use it becomes available. I am puzzled why you feel you have to support ECC certificates with TLS 1.3, and yet not for TLS 1.2? RSA certificates continue to be supported in TLS 1.3, and ECDSA certificates are well supported in TLS 1.2. Are you referring to deploying ECC certificates in your server software, or interoperating with ECC servers in your client software? If the latter, then indeed you should start to support servers that can only present ECDSA, rather than RSA, certificates. And do so with both TLS 1.2 and TLS 1.3, it is not clear why you'd wait for TLS 1.3 to be published. (We can party when it comes out, but that should not IMHO hold up implementations of ECDSA support). -- -- Viktor. --_000_cc5fe1d8b0654f308b7657714aea1949iongroupcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello Viktor,

  Thanks for your thoughtful reply.

  I haven't read the draft itself, only the articals which point to it= .

  There is a common thread circulating, that all support for RSA Certi= ficates/Ciphers are dropped in TLS 1.3.

  As I wrote in the last email, I am aware we can implemenet ECC certs= and ciphers in TLS 1.2, along side RSA certs/ciphers, however there is a c= onsistent fear of breaking what already works by moving onto offering both = an ECC and RSA certificate and corrosponding ciphers.

  If TLS 1.3 does support RSA certs, that removes the drive to begin o= ffering ecdhe_ecdsa alongside ecdhe_rsa, which essentially moves it back to= the "Do not need to implement pile", which will not tick forward= into the "must implement" pile until it is absolutely required.

I was sincerely hoping to be able to use the expected "end of ths RSA = Cert" to move us there in preparation of supporting TLS 1.3 and for on= ce be ahead of the curve instead of implemementing what seems to be superio= d encryption methods much later.

Ben

From: Vi= ktor Dukhovni <ietf-dane@dukhovni.org>
Sent: Saturday, June 16, 2018 11:31 PM
To: Ben Personick
Cc: tls@ietf.org
Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13



> On Jun 12, 2018, at 4:15 PM, Ben Personick <ben.personick@iongroup.= com> wrote:
>
> We are currently evaluating when to begin offering ECC Certificates ba= sed cypto on our websites.
> 
> Despite the advantages to doing this in TLS 1..2, there is a lot of pu= sh-back to wait until we =93have to support it=94 once the TLS 1.3 draft is= published, and the option to use it becomes available.

I am puzzled why you feel you have to support ECC certificates with
TLS 1.3, and yet not for TLS 1.2?  RSA certificates continue to be
supported in TLS 1.3, and ECDSA certificates are well supported in
TLS 1.2.

Are you referring to deploying ECC certificates in your server
software, or interoperating with ECC servers in your client software?

If the latter, then indeed you should start to support servers that
can only present ECDSA, rather than RSA, certificates.  And do so
with both TLS 1.2 and TLS 1.3, it is not clear why you'd wait for
TLS 1.3 to be published.  (We can party when it comes out, but that should not IMHO hold up implementations of ECDSA support).

--
--
        Viktor.

 --_000_cc5fe1d8b0654f308b7657714aea1949iongroupcom_-- From nobody Mon Jun 18 06:29:51 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06239130DE2 for ; Mon, 18 Jun 2018 06:11: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iontradingcom.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8fMFPe6Ge70 for ; Mon, 18 Jun 2018 06:11:30 -0700 (PDT) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710084.outbound.protection.outlook.com [40.107.71.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F061126DBF for ; Mon, 18 Jun 2018 06:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iontradingcom.onmicrosoft.com; s=selector1-iongroup-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gY1+1DHhBXcWZzg3Vjlwt2kdr51g51lpepZJ+H+CwD4=; b=NV8S4Uoqk6abE6apjjLtrSgU1dq04pEPmV7SwgqI22eKh//vT65hZZ/pP9VLuqgXDsY2xpGSY/xLcU9hQ1EsRiORlbWuN62IlJMxliPvdLmdNkRXYSubIGyJmtxowDeMxR/Ve0mJRCaF5TrfGhz8+xTBPoUgejU0nr1WOmB7VS0= Received: from BN7PR14MB2356.namprd14.prod.outlook.com (20.176.22.33) by BN7SPR01MB7.namprd14.prod.outlook.com (20.176.24.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.19; Mon, 18 Jun 2018 13:11:29 +0000 Received: from BN7PR14MB2356.namprd14.prod.outlook.com ([fe80::ac24:4123:784d:29f7]) by BN7PR14MB2356.namprd14.prod.outlook.com ([fe80::ac24:4123:784d:29f7%3]) with mapi id 15.20.0863.016; Mon, 18 Jun 2018 13:11:29 +0000 From: Ben Personick To: Sean Turner CC: "tls@ietf.org" Thread-Topic: [TLS] Mail regarding draft-ietf-tls-tls13 Thread-Index: AdQCh415dfE0g1svTxONss1UmLapVwDYGEsAAEd8Au8= Date: Mon, 18 Jun 2018 13:11:29 +0000 Message-ID: <9e524863-b758-4052-8419-1d5e0f9482ef@iongroup.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ben.personick@iongroup.com; x-originating-ip: [174.203.34.110] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN7SPR01MB7; 7:I2Tvb8PPcSIokM0rJ9uIYvq83hgS14PpZh8ztgDUTp7VpqDJN1Ed99Cqay99I+mKG0MWT+qpIg9PEvrMMAaRF22bn0TPvS2J7Z/I5+EA0k3+csSN4NufPAchEQBs3eqeGiA6cX2uNfk8BSS072WLiedlBYS8NF2MjlTvLxi7JQ/CvjZy8So9sG6fUb4fsXrZQMDKBMy3qoK83V7qlK+FGIeTAfi3iM/O8LZZDk6j2/3lAnhNV369ZW3nYDXwSM9w x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 739b8ad7-afa1-45db-cae8-08d5d51d0156 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:BN7SPR01MB7; x-ms-traffictypediagnostic: BN7SPR01MB7: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(189930954265078)(219752817060721); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:BN7SPR01MB7; BCL:0; PCL:0; RULEID:; SRVR:BN7SPR01MB7; x-forefront-prvs: 0707248B64 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(376002)(366004)(39380400002)(396003)(51914003)(199004)(189003)(6246003)(31696002)(105586002)(106356001)(54896002)(14454004)(476003)(6306002)(2906002)(25786009)(6512007)(86362001)(575784001)(486006)(6436002)(31686004)(606006)(8676002)(44832011)(81156014)(81166006)(4326008)(8936002)(236005)(229853002)(53936002)(11346002)(2900100001)(97736004)(6486002)(2616005)(7736002)(446003)(316002)(99286004)(66066001)(16799955002)(6916009)(186003)(5660300001)(3846002)(36756003)(6116002)(68736007)(5250100002)(76176011)(478600001)(966005)(6506007)(53546011)(26005)(45080400002)(3280700002)(3660700001)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7SPR01MB7; H:BN7PR14MB2356.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: iongroup.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 2VJJxA80Hy0PqmLlHqgjt2peECtU9/lEHQRY8GhKUuqN5Wr2AFz3tnkE2EFacQ6UehGRD9ywL0jkGcIBHs3FpO2HLOfeZWAJFW9dqvDSyqgLGGvgyGg9cqXwvaFwAnQLwFEGomoKqcSeJb98DjcNCkBqO7cCS5Z+VqeBOKPaq4dUmFoqpxWzj+jF2uomIiY0Tx2EoNX2H+QLUvbkfDg8IuOxV3+IfGA8yEzLrceTNiheNrKE5T4j02/woBHBr37ZbbHLLyCnVxPfKmUlw1y2kLlOvcsZG5dEUda9dtU8c1MPIrDH6FEHsRkFwxfg0ahJoLjGHu9AiafSIO/zws841A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_9e524863b758405284191d5e0f9482efiongroupcom_" MIME-Version: 1.0 X-OriginatorOrg: iongroup.com X-MS-Exchange-CrossTenant-Network-Message-Id: 739b8ad7-afa1-45db-cae8-08d5d51d0156 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2018 13:11:29.4620 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 768fe7d4-ebee-41a7-9851-d5825ecdd396 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7SPR01MB7 Archived-At: X-Mailman-Approved-At: Mon, 18 Jun 2018 06:29:44 -0700 Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 18 Jun 2018 13:11:33 -0000 --_000_9e524863b758405284191d5e0f9482efiongroupcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Sean Thanks for the explination. :) Ben ________________________________ From: Sean Turner Sent: Saturday, June 16, 2018 11:04 PM To: Ben Personick Cc: tls@ietf.org Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 > On Jun 12, 2018, at 16:15, Ben Personick wro= te: > > I have read some articles saying the draft is approved, but on looking = it seems not to be, I am a little unsure why the draft has been stuck in th= is seemingly nearly finished but not quite ready state for 3 months. The draft has been approved by the IESG. Once a draft is approved it moves= over to the RFC editor (and there=92s some IANA review too); here=92s a li= nk to the RFC editorial process [0]; here=92s a link to their publication q= ueue [1]. 3 months is about what I expected in terms of wait post approval= . We=92re nearly there. spt [0] https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.= rfc-editor.org%2Fpubprocess%2F&data=3D02%7C01%7Cben.personick%40iongroup.co= m%7Ca655a0eeead9423fbd0408d5d3ff13d0%7C768fe7d4ebee41a79851d5825ecdd396%7C0= %7C1%7C636648014877571083&sdata=3DP7w%2BqRt4H8tqJaRkG%2FoQJg8%2FJMDABTe6BAc= gx33JWEU%3D&reserved=3D0 [1] https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.= rfc-editor.org%2Fcurrent_queue.php&data=3D02%7C01%7Cben.personick%40iongrou= p.com%7Ca655a0eeead9423fbd0408d5d3ff13d0%7C768fe7d4ebee41a79851d5825ecdd396= %7C0%7C1%7C636648014877571083&sdata=3DIxdHA4%2FTBCy%2BugEOcO37Rx4nDiRXOCSIA= QOLlXtVSmQ%3D&reserved=3D0 --_000_9e524863b758405284191d5e0f9482efiongroupcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello Sean

  Thanks for the explination. :)

Ben

From: Se= an Turner <sean@sn3rd.com>
Sent: Saturday, June 16, 2018 11:04 PM
To: Ben Personick
Cc: tls@ietf.org
Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13



> On Jun 12, 2018, at 16:15, Ben Personick <ben.personick@iongroup.co= m> wrote:
>
>   I have read some articles saying the draft is approved, bu= t on looking it seems not to be, I am a little unsure why the draft has bee= n stuck in this seemingly nearly finished but not quite ready state for 3 m= onths.

The draft has been approved by the IESG.  Once a draft is approved it = moves over to the RFC editor (and there=92s some IANA review too); here=92s= a link to the RFC editorial process [0]; here=92s a link to their publicat= ion queue [1].  3 months is about what I expected in terms of wait post approval.  We=92re nearly there.

spt

[0] https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rfc-= editor.org%2Fpubprocess%2F&data=3D02%7C01%7Cben.personick%40iongroup.co= m%7Ca655a0eeead9423fbd0408d5d3ff13d0%7C768fe7d4ebee41a79851d5825ecdd396%7C0= %7C1%7C636648014877571083&sdata=3DP7w%2BqRt4H8tqJaRkG%2FoQJg8%2FJMDABTe= 6BAcgx33JWEU%3D&reserved=3D0
[1] https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rfc-= editor.org%2Fcurrent_queue.php&data=3D02%7C01%7Cben.personick%40iongrou= p.com%7Ca655a0eeead9423fbd0408d5d3ff13d0%7C768fe7d4ebee41a79851d5825ecdd396= %7C0%7C1%7C636648014877571083&sdata=3DIxdHA4%2FTBCy%2BugEOcO37Rx4nDiRXO= CSIAQOLlXtVSmQ%3D&reserved=3D0
 --_000_9e524863b758405284191d5e0f9482efiongroupcom_-- From nobody Mon Jun 18 06:31:17 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B50130F2C for ; Mon, 18 Jun 2018 06:31:14 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFYPBk6BTaPH for ; Mon, 18 Jun 2018 06:31:12 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0: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 8C9FE130EC6 for ; Mon, 18 Jun 2018 06:31:08 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id o138-v6so9522834vkd.3 for ; Mon, 18 Jun 2018 06:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7W+7XjD1KYNc3hFoYy+BUp9HBx81CxnfAoo4elQL8no=; b=lIl5AyIelaM35fmdIZ3aylS0docGZrQNflr29TDG8SfPpTMI0/s4gqzd6Ey94JjTVq AHOCLUIlA443udx6eiE0+QOaHqrcebefrRx8MZiZ/i39ZhJujjTWlJOi25PRcXo6QdkG 9cK9moBYUyuVSx51hmWRkxydYm5YMPQtryavO/FDYEA9wurBLKYPaAPldUpqkLB1JFyX x/yK8clTXdGAr/H1nK0kET7RITZlwn5fbr4p/hponIod2ZDJL3vgOFaX/zBRmcrnDq6J TeTzK2qfNypXlEYrtAr3w+kFfwOdOaz+ZpqTqwzsHk1ZeQeuxB9V4EBpWonAgKGzgqkr 4otA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7W+7XjD1KYNc3hFoYy+BUp9HBx81CxnfAoo4elQL8no=; b=Eaq63Fe++5kAqClU3QspAjkcaGp91ErId6LbVWYvl9ACuzaEUTDDO1HsPbagmf4CXt axEuU9gLGgg4TxryC1DusyZHuraKdWNB31y/PoelfDOpSKyrpHOWJJ1EQWmHvI7F9xm2 W41s6bPOy8A5ppETEdsp7n4bjnW5Q9SNmg7oXYm+q4g0hlPJ8UimdCRJWTAdnk93Y9Ha 0pjCIYx43t+g7CF3nW+h3BYqjhl0pDCbL/3IUGxVP8kNmKDwzg8t8jGmzd/2glO5Q+s0 bLMVwUS16A8tivjiT2mRgF2TPQFMxczGI8YwrRxvIhXx0zRb30cVA99GefNJfzxY6aMJ k6BQ== X-Gm-Message-State: APt69E0gs1jqoYpiyJhn2uJFd19D9zGIX/j7iTuioCpDsj7ApOH4T7TQ GtsKeit22f7ba1gvfaWb4J6d1b/ZIJ8e5YPsrccZXQ== X-Google-Smtp-Source: ADUXVKLHlV7LovIX5g6rqccj5VRqULijpyOi7+GbSKt9vLxmeznZDyVaq5nZ3bJj5KZlbSEIBwD8saXK9rsl/4ONFic= X-Received: by 2002:a1f:eb44:: with SMTP id j65-v6mr7005747vkh.14.1529328667418; Mon, 18 Jun 2018 06:31:07 -0700 (PDT) MIME-Version: 1.0 References: <2132206.KQKFhKinhY@pintsize.usersys.redhat.com> <7BE4BC91-5324-42A6-8AB7-084439ED9527@akamai.com> <4207179.CySPfdG7iZ@pintsize.usersys.redhat.com> In-Reply-To: From: Jonathan Hoyland Date: Mon, 18 Jun 2018 15:30:55 +0200 Message-ID: To: Nikos Mavrogiannopoulos Cc: Hubert Kario , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f76544056eea93c8" Archived-At: Subject: Re: [TLS] Universal PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 18 Jun 2018 13:31:16 -0000 --000000000000f76544056eea93c8 Content-Type: text/plain; charset="UTF-8" Given that channel bindings are generally the output of a hash transcript there seems to be minimal risk of PSK enumeration. If I send a PSK that the server recognises, alongside one it does not, would a server sometimes pretend to accept the PSK it does not recognise to avoid enumeration attacks? That behaviour would seem strange to me. If it's only the behaviour when all PSKs are unrecognised then this shouldn't be an issue if the unmodified PSK is sent as a less secure fallback option. If all PSKs including the unmodified one are unrecognised then negotiation failure is the correct response. On the other hand, I have no objection in principle to an extension. Regards, Jonathan On Mon, 18 Jun 2018 at 14:18 Nikos Mavrogiannopoulos wrote: > On Mon, 2018-06-18 at 13:56 +0200, Jonathan Hoyland wrote: > > The issue with the current draft is that it leaves a single PSK with > > two potential interpretations. > > If the draft also changed the PSK identity value then each PSK would > > have a single interpretation. > > If the draft changes the identity then it can also change the PSK key > > without having to change the manner in which the binder is computed. > > In that case universal PSKs and regular PSKs do not need to be > > distinguished, because they are both validated in the same way. > > > > A server unaware of universal PSKs would simply see an unrecognised > > PSK identity. > > If both the unmodified and the modified PSKs are sent, then it can > > simply select the unmodified version, ignoring the other. > > A server that recognises both values can choose which to use. > > > > If the modified PSK identity was a channel binding, then the modified > > version would have stronger security properties, and thus presumably > > would be preferable. > > In this case the hash function used for the binder remains > > selectable. > > > > Would that resolve your issue? > > That may not be sufficient. A server which sees an unrecognized PSK may > chose to pretend it recognized it to avoid user enumeration attacks > similarly to TLS1.2 (optional) behavior. Hence a modified username > would cause negotiation failure with such a server. > > A new extension seems to be necessary to eliminate any interoperability > issues with servers that will not follow the universal psk draft. > > regards, > Nikos > > --000000000000f76544056eea93c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Given that channel bindings are generally the output of a = hash transcript there seems to be minimal risk of PSK enumeration.=C2=A0If I send a PSK that the server recognises, alongside one it does not, wo= uld a server sometimes pretend to accept the PSK it does not recognise to a= void enumeration attacks?=C2=A0
That behaviour would seem strange= to me.=C2=A0

If it's only the behaviour when = all PSKs are unrecognised then this shouldn't be an issue if the unmodi= fied PSK is sent as a less secure fallback option.=C2=A0
If all P= SKs including the unmodified one are unrecognised then negotiation failure = is the correct response.=C2=A0

On the other hand, = I have no objection in principle to an extension.

= Regards,

Jonathan

=C2=A0
<= br>



On Mon, 18 Jun 2018 at 14:18 Nikos Mavrogiannopoulos <= nmav@redhat.com> wrote:
=
On Mon, 2018-06-18 at 13:56 +0200, Jonathan = Hoyland wrote:
> The issue with the current draft is that it leaves a single PSK with > two potential interpretations.
> If the draft also changed the PSK identity value then each PSK would > have a single interpretation.
> If the draft changes the identity then it can also change the PSK key<= br> > without having to change the manner in which the binder is computed. > In that case universal PSKs and regular PSKs do not need to be
> distinguished, because they are both validated in the same way.
>
> A server unaware of universal PSKs would simply see an unrecognised > PSK identity.
> If both the unmodified and the modified PSKs are sent, then it can
> simply select the unmodified version, ignoring the other.
> A server that recognises both values can choose which to use.
>
> If the modified PSK identity was a channel binding, then the modified<= br> > version would have stronger security properties, and thus presumably > would be preferable.
> In this case the hash function used for the binder remains
> selectable.=C2=A0
>
> Would that resolve your issue?

That may not be sufficient. A server which sees an unrecognized PSK may
chose to pretend it recognized it to avoid user enumeration attacks
similarly to TLS1.2 (optional) behavior. Hence a modified username
would cause negotiation=C2=A0 failure with such a server.

A new extension seems to be necessary to eliminate any interoperability
issues with servers that will not follow the universal psk draft.

regards,
Nikos

--000000000000f76544056eea93c8-- From nobody Mon Jun 18 08:36:15 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F39130DE1 for ; Mon, 18 Jun 2018 08:36:13 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lxrm4G5UsiH for ; Mon, 18 Jun 2018 08:36:12 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0: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 3F34D12872C for ; Mon, 18 Jun 2018 08:36:12 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id q135-v6so9805283vkh.1 for ; Mon, 18 Jun 2018 08:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eDbQ2ceoRWFgB6o5C2Mg1q606h+WhgPq605oiogjeFg=; b=JlWW7ZsyTaRHBqblGIaRWWNFIc4S8L0JPPEhG8rbQEfS+DZsa+G2c5vXMCNRSZJ7kq LtElVtxna+0d6u9aCnm67F3/nOhIapR3IGGGFEmw/ZIqt/8ZFuoUBEdLlpk0j3J9805a feszUFpeSbuZDSch8uEkmIqFUwdBuAelCwm3WnHSluTZI6ftu4oLKEH0JzyTTeH+qVC2 etqZqqEnUpEn4nobQkztSdjG57mpMQqn3p2CT+qYZfEyeeBxMVppvbKIV7nz/20cTLK5 MIU7yV22yqVUHetGgeV7NPpZAt3xIqrfp/ZB4VyWSHtbIKawZPe7rQD3oT5e3JtN4abo kDng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eDbQ2ceoRWFgB6o5C2Mg1q606h+WhgPq605oiogjeFg=; b=gSRYbcUS8PnPhlpc1u2HhNVvam2YB+QRf8lYXWiHUJDVF568j5lIW82YZE1GDjxedD wOczdaj1iOup/dwu9DVLZj0ZdcyB470iXsfyqc/22p+hFTnhy95gMfmlU5AyTCbmNPVv 1D2HCrpcTL+moXV1vww+eMJVZGabvygHUEu1gVDeiXhskd+yToMykvshbN2KghJi6dwq FLyQxdYQc7iEeSgTWttlsH/SVv4c6Iujx/GDHsnQNFZxYktTswpIhmCdISzoEMjyOcOM dWnstNG0LcXqQ0H5AZQLpEQ1vBxPbnU39NGGv0YQMYu4s6Xa1CVDfVPVobAL/jk1sUDx +giQ== X-Gm-Message-State: APt69E0N/3BZ+1+BLwF806buvlTAP7Xd8oqqZLcnU+7QpRLYQdAcfjj7 KjIAsOu9w+Wszim3XD3x+TDTsIzeyYKMPK3WoGM5jg== X-Google-Smtp-Source: ADUXVKJhh7Ob+NZ9U7+ppYXceAizL0Tkyc1yJuSN3MmftupSVbISzwpQ3pVpRFiw4wcgaA1AYHV2MVWhl71/WeVXQJI= X-Received: by 2002:a1f:2046:: with SMTP id g67-v6mr7872802vkg.43.1529336171244; Mon, 18 Jun 2018 08:36:11 -0700 (PDT) MIME-Version: 1.0 References: <897AC345-0832-4252-9D96-5A030CBEAD25@dukhovni.org> In-Reply-To: From: Tony Arcieri Date: Mon, 18 Jun 2018 08:36:00 -0700 Message-ID: To: ben.personick@iongroup.com Cc: "" Content-Type: multipart/alternative; boundary="0000000000003ab21a056eec530f" Archived-At: Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 18 Jun 2018 15:36:14 -0000 --0000000000003ab21a056eec530f Content-Type: text/plain; charset="UTF-8" On Mon, Jun 18, 2018 at 6:30 AM Ben Personick wrote: > There is a common thread circulating, that all support for RSA > Certificates/Ciphers are dropped in TLS 1.3. > RSA certificates will continue to work in TLS 1.3+. What will not be supported in TLS 1.3+ is RSA key transport / key encipherment (which lacks forward secrecy, among other problems). However, this is a property of how the protocol does key exchange / key agreement and has nothing to do with certificates. -- Tony Arcieri --0000000000003ab21a056eec530f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jun 18= , 2018 at 6:30 AM Ben Personick <ben.personick@iongroup.com> wrote:
There is a common thread circulating, that all support for RSA Certifi= cates/Ciphers are dropped in TLS 1.3.
<= div>
RSA certificates will continue to work in TLS 1.3+.

What will not be supported in TLS 1.3+ is RSA ke= y transport / key encipherment (which lacks forward secrecy, among other pr= oblems). However, this is a property of how the protocol does key exchange = / key agreement and has nothing to do with certificates.

--
Tony Arcieri
--0000000000003ab21a056eec530f-- From nobody Mon Jun 18 09:33:00 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCE3130DF6 for ; Mon, 18 Jun 2018 09:32:58 -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 autolearn_force=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 nFfRIMPyOZgE for ; Mon, 18 Jun 2018 09:32:56 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F90130DE0 for ; Mon, 18 Jun 2018 09:32:56 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id C3F517A330D; Mon, 18 Jun 2018 16:32:54 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Viktor Dukhovni In-Reply-To: Date: Mon, 18 Jun 2018 12:32:54 -0400 Cc: TLS WG Reply-To: TLS WG Content-Transfer-Encoding: quoted-printable Message-Id: <7D370F20-3C5C-4347-9EA3-3F0F61458377@dukhovni.org> References: <897AC345-0832-4252-9D96-5A030CBEAD25@dukhovni.org> To: Ben Personick X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 18 Jun 2018 16:32:59 -0000 > On Jun 18, 2018, at 9:10 AM, Ben Personick = wrote: >=20 > There is a common thread circulating, that all support for RSA = Certificates/Ciphers are dropped in TLS 1.3. This is not the case. > As I wrote in the last email, I am aware we can implemenet ECC certs = and ciphers in TLS 1.2, along side RSA certs/ciphers, however there is a = consistent fear of breaking what already works by moving onto offering = both an ECC and RSA certificate and corrosponding ciphers. You should at least support verifying ECDSA certificates on the client side, some servers your client software might connect to may have only ECDSA certificates. On the server side you can continue to use RSA certificates if you wish. While ECDSA is faster on the server, there are still some clients (perhaps yours among them) that only support RSA, and so you'd need to have both RSA and ECDSA certificates, which is operationally a bit more challenging. --=20 Viktor. From nobody Mon Jun 18 12:46:46 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B297130E32 for ; Mon, 18 Jun 2018 12:46:44 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ceuefq_-NCz for ; Mon, 18 Jun 2018 12:46:43 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 B5E1A130E22 for ; Mon, 18 Jun 2018 12:46:39 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id m21-v6so11506013uan.0 for ; Mon, 18 Jun 2018 12:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fSJ/QfpnpSuF9GphmzTGP4ebxfE6M0Nx1l6LcU/GYqk=; b=F0wxrUMj/ao6QD6cpUhwdUkYdU4IrUBWyW315Jxf/0Nsh2/bwzFG6ID1JiBZksyXKh V3QkYbdOkvK7b8YjfmaJ7OMPtAU0BGddtXz+Xn1e6SI23gmplRpR/iO9f6EhfIYV1I59 fn3hl1Pf9Luhktg6KR/BUqlwjAoW2GZE1nbNlKkxRxQd1x6cvL5mrkLoWTcmnQLPQSV1 CMA4L2leEG8OA7syplsWJ1uk6tIuDZLn32TvYAtRbrlsPicn8Ob2cw8wenebgL3yes02 ajMUg8N4YPbaY3UUWfF9fXPUtDlgVqJW2Ay0B0SZpbwpyjAfv3HJiOYO+Gh17MPawk7c hCsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fSJ/QfpnpSuF9GphmzTGP4ebxfE6M0Nx1l6LcU/GYqk=; b=hfTophQWV7t4QP71ztlyJOXG8p6qoGeTk6tcoRAi2Ome1rG0YQ+u3bIeO3spBbh0i9 e3KWHMkS1QuRzF5/1ZSzfpyjxw6zENao40LJ/0VuIbsZNWwSETzqJytbhI/guua+rQiW YVDtRuaR+mA/YP5Xk+JtotO2DyNF3Cpt1qUt1HrMwntkOHTrMx94kjpIatEWu8K7iH4y cQT5dcpiil48t7MyqGUIybH5Sdxr0GJR/vSIypWaZIDwt/bU1ribja8/vILPTLzOTmm3 apbQXxzYsgTa98rvVeHpdJoh8vCxF844niI0v4I+CVYbZGJFQ2asVHhcEK7YKJl3xRbB zNaw== X-Gm-Message-State: APt69E3TOMRbHFrzbdngTqcfzRf5y+5Qv9QGNgOzwkktmFoS2rQcWtAw E83NwV2qk9zlCJBnFfYF+8ZtZVDDFUbyp8V4mAY= X-Google-Smtp-Source: ADUXVKKKAEjcXZLiHCFhUpT1ZpSnD9z7iOeryv+eCBaK874w8Lxkk1EBLbmjM7fJbY7u2ygcdTBGup0YNdtB3hzuYLs= X-Received: by 2002:a9f:23a1:: with SMTP id 30-v6mr8486214uao.42.1529351198601; Mon, 18 Jun 2018 12:46:38 -0700 (PDT) MIME-Version: 1.0 References: <897AC345-0832-4252-9D96-5A030CBEAD25@dukhovni.org> In-Reply-To: From: Tony Arcieri Date: Mon, 18 Jun 2018 12:46:27 -0700 Message-ID: To: ben.personick@iongroup.com Cc: "" Content-Type: multipart/alternative; boundary="000000000000edf69e056eefd225" Archived-At: Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 18 Jun 2018 19:46:45 -0000 --000000000000edf69e056eefd225 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 18, 2018 at 12:12 PM Ben Personick wrote: > So essentially TLS 1.3 drops support for DH/DHE ciphers on RSA keys, but > willl otherwise work as expected? > DH/DHE ciphers are orthogonal to RSA key transport/encipherment. The latter uses the RSA algorithm for encryption, without any DH(E) algorithm whatsoever, and that is what is no longer supported in TLS 1.3. -- Tony Arcieri --000000000000edf69e056eefd225 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jun 18= , 2018 at 12:12 PM Ben Personick <ben.personick@iongroup.com> wrote:
=C2=A0 So essentially TLS 1.3 drops support for DH/DHE ciphers on RSA = keys, but willl otherwise work as expected?

DH/DHE ciphers are orthogonal to RSA key transport/e= ncipherment. The latter uses the RSA algorithm for encryption, without any = DH(E) algorithm whatsoever, and that is what is no longer supported in TLS = 1.3.

--
Tony Arcieri
--000000000000edf69e056eefd225-- From nobody Mon Jun 18 19:54:49 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54918130E2F for ; Mon, 18 Jun 2018 12:10:09 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iontradingcom.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6g5vsq0QW2I for ; Mon, 18 Jun 2018 12:10:07 -0700 (PDT) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710054.outbound.protection.outlook.com [40.107.71.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCDFE130E29 for ; Mon, 18 Jun 2018 12:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iontradingcom.onmicrosoft.com; s=selector1-iongroup-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/QHNGgxFfjADu6sVrG87RjrF07Q/Vs/R/kkCwio26Sk=; b=F1tn2WXlwI8mAeujypkRF5yQS5wLWSW63RspwAapAnBpVVmfxhxV0UV90Q/ztaGGX2+sfcfANBbIz/ZZTCAwYZnS4FoVxL27tSV0xA5yXv6rrYQHd0JyfGKVzI0rYNXgGI+XIdy5Sh0ZeovLmp56xXQbjxHBfA/IHgWfayZO7+0= Received: from BN7PR14MB2356.namprd14.prod.outlook.com (20.176.22.33) by BN7PR14MB2433.namprd14.prod.outlook.com (20.176.22.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.17; Mon, 18 Jun 2018 19:10:05 +0000 Received: from BN7PR14MB2356.namprd14.prod.outlook.com ([fe80::ac24:4123:784d:29f7]) by BN7PR14MB2356.namprd14.prod.outlook.com ([fe80::ac24:4123:784d:29f7%3]) with mapi id 15.20.0863.016; Mon, 18 Jun 2018 19:10:05 +0000 From: Ben Personick To: TLS WG Thread-Topic: [TLS] Mail regarding draft-ietf-tls-tls13 Thread-Index: AdQCh415dfE0g1svTxONss1UmLapVwDZCf0AAEaFOTYABw3aAAAFfUx5 Date: Mon, 18 Jun 2018 19:10:05 +0000 Message-ID: <5fdded19-da5c-4d23-a0e3-e4e9e905f7aa@iongroup.com> References: <897AC345-0832-4252-9D96-5A030CBEAD25@dukhovni.org> , <7D370F20-3C5C-4347-9EA3-3F0F61458377@dukhovni.org> In-Reply-To: <7D370F20-3C5C-4347-9EA3-3F0F61458377@dukhovni.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ben.personick@iongroup.com; x-originating-ip: [38.108.249.203] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN7PR14MB2433; 7:YSMkay4vIXQTP/A6do4RoULiQ8KFaXRuFFKi7goikw4Fnbx4j65X6/AfhAWEUMOSD72+AoZ17OUOSzJ+NaerpPcMf3igo+jTrnlhsr4IgfQCf9dddXpu7PbO7lvbsTtpp+M6SIvzxlzyl3DQQhkbq1tr0ruXppTVSaYrzSKc/U9aQ8K/WSmY8O1jfWTdKWV8TbzimUhJnX/NiCzUKEgUjPscR/b6hhjyiC5WC6EZVyX1PuawYeKrHYpvq2HPk/Vk x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 3cd5ee97-815c-47ed-7f6e-08d5d54f19dd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:BN7PR14MB2433; x-ms-traffictypediagnostic: BN7PR14MB2433: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21532816269658); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231254)(944501410)(52105095)(93006095)(93001095)(3002001)(149027)(150027)(6041310)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:BN7PR14MB2433; BCL:0; PCL:0; RULEID:; SRVR:BN7PR14MB2433; x-forefront-prvs: 0707248B64 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(39860400002)(396003)(366004)(376002)(346002)(189003)(199004)(3846002)(478600001)(6916009)(6246003)(5660300001)(68736007)(36756003)(25786009)(6116002)(53936002)(14454004)(31686004)(66066001)(2900100001)(105586002)(106356001)(26005)(31696002)(8676002)(54896002)(316002)(6486002)(53546011)(6506007)(6512007)(7736002)(81166006)(76176011)(99286004)(97736004)(6436002)(2906002)(3280700002)(3660700001)(229853002)(446003)(86362001)(476003)(2616005)(486006)(44832011)(11346002)(93886005)(186003)(81156014)(102836004)(5250100002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR14MB2433; H:BN7PR14MB2356.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: iongroup.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: cMcWjqWwEdzS0CHZz8PXieVom33NcecRjD6SBgYkhOqHNrwaTNbpGO67yykZsI5xcloO2QXNTNiIUGNJm7v9lE8gBubFlTVIpmXM7TxI4oEpVza+t/zWMkyXT3u07TYJIhj0AT91EsJ+YBM/e/vC6jGgMWttLnHjzFdYH4VGVXom5WHm26mfKaEHPrRePaEXrTM1SSehTDNb2623GI/00PhcO8Ie58iA/+rSTwP+7QP2Zu05QHHcmAwAtHR9vHfS0c917Epfo1s3qfMd/442yGjbCX2QJ1gWOLkNbml9VHj6HXlRnOz2zMTtTbtA6IGrYe+8A3X2vXnmKlXCu4MxMw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_5fdded19da5c4d23a0e3e4e9e905f7aaiongroupcom_" MIME-Version: 1.0 X-OriginatorOrg: iongroup.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3cd5ee97-815c-47ed-7f6e-08d5d54f19dd X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2018 19:10:05.3841 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 768fe7d4-ebee-41a7-9851-d5825ecdd396 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR14MB2433 Archived-At: X-Mailman-Approved-At: Mon, 18 Jun 2018 19:54:47 -0700 Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 18 Jun 2018 19:10:09 -0000 --_000_5fdded19da5c4d23a0e3e4e9e905f7aaiongroupcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Viktor, I am only concerned with offereing newer , faster, and more secure cipher= suites on our web application, so that as clients have the ability to use = them they can begin to do so. Our LB offers a method to present baoth an RSA and ECC cert at thw aame t= ime, at the cost of buying both each year. I can only support ecdsa_rsa unless I have an ECC certificate to support = ecsda_ecsde ciphers. Since TLS 1.3 will continue to allow ecdsa_rsa ciphers, there will be no = push to move towards offering them, because of various 'reasons'. Ben ________________________________ From: Viktor Dukhovni Sent: Monday, June 18, 2018 12:32 To: Ben Personick Cc: TLS WG Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 > On Jun 18, 2018, at 9:10 AM, Ben Personick w= rote: > > There is a common thread circulating, that all support for RSA Certificat= es/Ciphers are dropped in TLS 1.3. This is not the case. > As I wrote in the last email, I am aware we can implemenet ECC certs and = ciphers in TLS 1.2, along side RSA certs/ciphers, however there is a consis= tent fear of breaking what already works by moving onto offering both an EC= C and RSA certificate and corrosponding ciphers. You should at least support verifying ECDSA certificates on the client side, some servers your client software might connect to may have only ECDSA certificates. On the server side you can continue to use RSA certificates if you wish. While ECDSA is faster on the server, there are still some clients (perhaps yours among them) that only support RSA, and so you'd need to have both RSA and ECDSA certificates, which is operationally a bit more challenging. -- Viktor. --_000_5fdded19da5c4d23a0e3e4e9e905f7aaiongroupcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello Viktor,

  I am only concerned with offereing newer , faster, and more secure c= ipher suites on our web application, so that as clients have the ability to= use them they can begin to do so.

  Our LB offers a method to present baoth an RSA and ECC cert at thw a= ame time, at the cost of buying both each year.

  I can only support ecdsa_rsa unless I have an ECC certificate to sup= port ecsda_ecsde ciphers.

  Since TLS 1.3 will continue to allow ecdsa_rsa ciphers, there will b= e no push to move towards offering them, because of various 'reasons'.

Ben

From: Vi= ktor Dukhovni <ietf-dane@dukhovni.org>
Sent: Monday, June 18, 2018 12:32
To: Ben Personick
Cc: TLS WG
Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13



> On Jun 18, 2018, at 9:10 AM, Ben Personick <ben.personick@iongroup.= com> wrote:
>
> There is a common thread circulating, that all support for RSA Certifi= cates/Ciphers are dropped in TLS 1.3.

This is not the case.

> As I wrote in the last email, I am aware we can implemenet ECC certs a= nd ciphers in TLS 1.2, along side RSA certs/ciphers, however there is a con= sistent fear of breaking what already works by moving onto offering both an= ECC and RSA certificate and corrosponding ciphers.

You should at least support verifying ECDSA certificates on the client
side, some servers your client software might connect to may have only
ECDSA certificates.  On the server side you can continue to use RSA certificates if you wish.  While ECDSA is faster on the server, there<= br> are still some clients (perhaps yours among them) that only support RSA, and so you'd need to have both RSA and ECDSA certificates, which is
operationally a bit more challenging.

--
        Viktor.

 --_000_5fdded19da5c4d23a0e3e4e9e905f7aaiongroupcom_-- From nobody Mon Jun 18 19:54:55 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44188130F01 for ; Mon, 18 Jun 2018 12:12:17 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iontradingcom.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLfUZGj6oMBC for ; Mon, 18 Jun 2018 12:12:11 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0041.outbound.protection.outlook.com [104.47.33.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8E42130F9C for ; Mon, 18 Jun 2018 12:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iontradingcom.onmicrosoft.com; s=selector1-iongroup-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EM/OPuf3gMtRqBW9XXfh6GyjszLcAv1l7xOovR3WkOg=; b=Tpiy1F+aXrTsPt31t6S7Ps3wKW/Z9XbO2WJEt6rnpJz0LWk4Pt2bd22RL6KA0Xuuy4h2kj/Wyq9POGuO9BFqYOPRnFziHCjidUxYHcWoJGJujrGSLQe0rJRRWVyLomGcsUcT6Yb1Do7DlQcezRuuHuSRyZk7aQUy3xw4uqLNUCU= Received: from BN7PR14MB2356.namprd14.prod.outlook.com (20.176.22.33) by BN7PR14MB2131.namprd14.prod.outlook.com (20.176.21.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.19; Mon, 18 Jun 2018 19:12:10 +0000 Received: from BN7PR14MB2356.namprd14.prod.outlook.com ([fe80::ac24:4123:784d:29f7]) by BN7PR14MB2356.namprd14.prod.outlook.com ([fe80::ac24:4123:784d:29f7%3]) with mapi id 15.20.0863.016; Mon, 18 Jun 2018 19:12:10 +0000 From: Ben Personick To: Tony Arcieri CC: "tls@ietf.org" Thread-Topic: [TLS] Mail regarding draft-ietf-tls-tls13 Thread-Index: AdQCh415dfE0g1svTxONss1UmLapVwDZCf0AAEaFOTYABREhAAAHjJzL Date: Mon, 18 Jun 2018 19:12:10 +0000 Message-ID: References: <897AC345-0832-4252-9D96-5A030CBEAD25@dukhovni.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ben.personick@iongroup.com; x-originating-ip: [38.108.249.203] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN7PR14MB2131; 7:HqONKBxuVZsQIW1eEVnTy43UMn5QXXQ5gMT+biICjJfXMI5dIPsQffWt/7AGwjj5ojLqbHzgUNb474AFmQGyxpOBk5sc+trgsD1Yy7v42N2b2ni+FDWGoANyCZt30/hBd7Ey0cMa2nUO5dysUNSyG4WzA4g+d592ABUvz3GFDVCAmI4cokrT7bOZbeVZbduXGgklGM3+5W/fp8uS2+Jv7DvST4XRmaoBhvqaJt2Dpuk6veQ7JqZt/XiYDvSkRS/G x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 7a708103-2602-4500-f111-08d5d54f642c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:BN7PR14MB2131; x-ms-traffictypediagnostic: BN7PR14MB2131: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:BN7PR14MB2131; BCL:0; PCL:0; RULEID:; SRVR:BN7PR14MB2131; x-forefront-prvs: 0707248B64 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(366004)(39380400002)(346002)(39860400002)(189003)(199004)(236005)(3846002)(6116002)(31686004)(5660300001)(53936002)(6246003)(14454004)(229853002)(39060400002)(31696002)(8936002)(81156014)(3280700002)(81166006)(3660700001)(36756003)(1411001)(8676002)(5250100002)(106356001)(105586002)(2906002)(4326008)(7736002)(6486002)(6436002)(478600001)(68736007)(2616005)(2900100001)(6916009)(26005)(6506007)(54896002)(53546011)(25786009)(102836004)(446003)(11346002)(476003)(486006)(93886005)(186003)(44832011)(97736004)(66066001)(316002)(6512007)(99286004)(86362001)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR14MB2131; H:BN7PR14MB2356.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: iongroup.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 0mJMD1Vv5A8OwCHzL/u1QaOaq71vD5KvszgzBbTCKsu/c+MxcYTyuV0HIN+6DtwO2XZfXfe8NNP6/urDw5BJPwrY+acmkRrIFWgBd8cel5CM207NPQdwveja/9jl1lXclwyWPfeCXkkB6HL/zto82PtySyFaJeneBZlgBuDGVKen7+qrtfeTnJwe3rou8zY36HUeznH1hkcoMwQLPlQjqXmTDTCw9pUprya39sAtSmGupvDZOG8C2rXE1LPOwQPapznV154wfrpa9ipFN6s3720EiGZ9MuZOu/bSuNeZyZjl3fKB7IpxFaJv5Nf35YGejH/PJUYZG4ReIxRUNds2rg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_f85f7c5854234e68bea0da717b0f7664iongroupcom_" MIME-Version: 1.0 X-OriginatorOrg: iongroup.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7a708103-2602-4500-f111-08d5d54f642c X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2018 19:12:10.0717 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 768fe7d4-ebee-41a7-9851-d5825ecdd396 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR14MB2131 Archived-At: X-Mailman-Approved-At: Mon, 18 Jun 2018 19:54:47 -0700 Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 18 Jun 2018 19:12:24 -0000 --_000_f85f7c5854234e68bea0da717b0f7664iongroupcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Tony, So essentially TLS 1.3 drops support for DH/DHE ciphers on RSA keys, but = willl otherwise work as expected? Ben ________________________________ From: Tony Arcieri Sent: Monday, June 18, 2018 11:36 To: Ben Personick Cc: Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 On Mon, Jun 18, 2018 at 6:30 AM Ben Personick > wrote: There is a common thread circulating, that all support for RSA Certificates= /Ciphers are dropped in TLS 1.3. RSA certificates will continue to work in TLS 1.3+. What will not be supported in TLS 1.3+ is RSA key transport / key encipherm= ent (which lacks forward secrecy, among other problems). However, this is a= property of how the protocol does key exchange / key agreement and has not= hing to do with certificates. -- Tony Arcieri --_000_f85f7c5854234e68bea0da717b0f7664iongroupcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello Tony,

  So essentially TLS 1.3 drops support for DH/DHE ciphers on RSA keys,= but willl otherwise work as expected?

Ben

From: To= ny Arcieri <bascule@gmail.com>
Sent: Monday, June 18, 2018 11:36
To: Ben Personick
Cc: <tls@ietf.org>
Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13

On Mon, Jun 18, 2018 at 6:30 AM Ben Personick <ben.personick@iongroup.com> w= rote:
There is a common thread circulating, that all support for RSA Certifi= cates/Ciphers are dropped in TLS 1.3.

RSA certificates will continue to work in TLS 1.3+.

What will not be supported in TLS 1.3+ is RSA key transport / key = encipherment (which lacks forward secrecy, among other problems). However, = this is a property of how the protocol does key exchange / key agreement an= d has nothing to do with certificates.

--
Tony Arcieri
--_000_f85f7c5854234e68bea0da717b0f7664iongroupcom_-- From nobody Mon Jun 18 21:04:30 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FC0130F20 for ; Mon, 18 Jun 2018 21:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 g-SEmf8t2YII for ; Mon, 18 Jun 2018 21:04:25 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73281130EB9 for ; Mon, 18 Jun 2018 21:04:25 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 54F677A330D; Tue, 19 Jun 2018 04:04:24 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 19 Jun 2018 00:04:23 -0400 Cc: "tls@ietf.org" Reply-To: TLS WG Content-Transfer-Encoding: quoted-printable Message-Id: <8125DD3B-34F2-49B3-AFEB-B526F44E4147@dukhovni.org> References: <897AC345-0832-4252-9D96-5A030CBEAD25@dukhovni.org> To: Ben Personick X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 19 Jun 2018 04:04:28 -0000 > On Jun 18, 2018, at 3:12 PM, Ben Personick = wrote: >=20 > So essentially TLS 1.3 drops support for DH/DHE ciphers on RSA keys, = but willl otherwise work as expected? No, it drops support for *non* (EC)DHE RSA ciphers, keeping *only* the (EC)DHE RSA ciphers, for specific FFDHE groups (as before) specific ECDHE curves. Note that (IIRC) the TLS 1.3 implementation in OpenSSL 1.1.1 will not include support the TLS 1.3 finite-field DHE groups, and so TLS 1.3 interoperability with OpenSSL *requires* ECDHE support. If your implementation offers TLS 1.3, but offers no ECDHE signature algorithms, the handshake will (IIRC) likely fail. So what's becoming effectively mandatory with TLS 1.3 is ECDHE key agreement, not ECDSA certificates, though TLS 1.3 clients really should also support connections to servers that have ECDSA P-256, P-384, P-521, Ed25519 and Ed448 certificates. But servers can stick with RSA certificates so long as they are willing to do ECDHE key agreement. --=20 Viktor. From nobody Tue Jun 19 03:23:00 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FED130DC7 for ; Tue, 19 Jun 2018 03:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 7i-zfOQ5piMO for ; Tue, 19 Jun 2018 03:22:57 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29E47130DC3 for ; Tue, 19 Jun 2018 03:22:57 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5FA0640201BE; Tue, 19 Jun 2018 10:22:56 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id E0A9F10C1E; Tue, 19 Jun 2018 10:22:55 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Cc: Ben Personick Date: Tue, 19 Jun 2018 12:22:54 +0200 Message-ID: <2775922.pafzB1VNMh@pintsize.usersys.redhat.com> In-Reply-To: <5fdded19-da5c-4d23-a0e3-e4e9e905f7aa@iongroup.com> References: <7D370F20-3C5C-4347-9EA3-3F0F61458377@dukhovni.org> <5fdded19-da5c-4d23-a0e3-e4e9e905f7aa@iongroup.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2094612.6Qmls5AWhV"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Tue, 19 Jun 2018 10:22:56 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Tue, 19 Jun 2018 10:22:56 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 19 Jun 2018 10:22:59 -0000 --nextPart2094612.6Qmls5AWhV Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 18 June 2018 21:10:05 CEST Ben Personick wrote: > I can only support ecdsa_rsa unless I have an ECC certificate to support > ecsda_ecsde ciphers. that is software limitation, not protocol limitation =20 > Since TLS 1.3 will continue to allow ecdsa_rsa ciphers, there will be no > push to move towards offering them, because of various 'reasons'. technically, there are no ecdsa_rsa, ecdhe_rsa or ecdhe_ecdsa ciphers in TL= S=20 1.3, the signature over key exchange is guided by the signature_algorithms= =20 extensions only, cipher suite does not influence it > Ben >=20 > ________________________________ > From: Viktor Dukhovni > Sent: Monday, June 18, 2018 12:32 > To: Ben Personick > Cc: TLS WG > Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 >=20 > > On Jun 18, 2018, at 9:10 AM, Ben Personick > > wrote: > >=20 > > There is a common thread circulating, that all support for RSA > > Certificates/Ciphers are dropped in TLS 1.3. > This is not the case. >=20 > > As I wrote in the last email, I am aware we can implemenet ECC certs and > > ciphers in TLS 1.2, along side RSA certs/ciphers, however there is a > > consistent fear of breaking what already works by moving onto offering > > both an ECC and RSA certificate and corrosponding ciphers. > You should at least support verifying ECDSA certificates on the client > side, some servers your client software might connect to may have only > ECDSA certificates. On the server side you can continue to use RSA > certificates if you wish. While ECDSA is faster on the server, there > are still some clients (perhaps yours among them) that only support RSA, > and so you'd need to have both RSA and ECDSA certificates, which is > operationally a bit more challenging. >=20 > -- > Viktor. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart2094612.6Qmls5AWhV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlso2X4ACgkQkqjRuAHS 9fXcFQ//ZFA/1FBo0o1Iqq38QdYOpu0kMVbEUybW/IqIdSM221JM/4ytn64f1Ydw hZnxkazNtwq19yp1TQg1rDZjOOX1Lyskgb4krccaMng1/QvYPr3OWt2YAvXa6uGC OZRv0I33SjNV5qettAg4FZiucRq49DT0vdJ40x3iFBUWINEAWfU9LB8C72OCFXJJ 4PbMh6zgTcaAxtVPS8baQCCR+BIInP4v1LiBeuzEPKnQfjpira1XgOlloHBv1Jvt x6qaWJMBE0ot8IiYy59pzr107W5RaERI8WQpOSIOm+QPihn1YbjWoy4nSqZEJpH0 X8EfFz+ohcivCsamAT0FRKxj5O1Dl6reAFtixFzdkhmjDocy/qIK7j7zZ2p/MHCd zy+ZUXy1Pu08sjHBVZVT9wXPA1+vF0jPOQC+SkzlU+W3BwAFNf8br7pZmyRnd3Qn MbJfXLR3EH7PjHv+q08Ro6Nvw3cvoTN6MVYI6eKjbbBL2EByhzanedanfAzlwNf6 D06Uh3cM9qrlT7XQWNTEV84cvuIkQAQRC9NeHJpsvKLQRnOD/Qz/hMys5QPASYfo OLh+AufemOGCYaYs6TDWLzYXNYeQa/IcWJ8oJTfqvTWz51lOv2wUAAg+lWlcynY0 ioVOJDeAbfpMwqb9b4fTFVAJDJQZ3dcyzejq+qgjSrH88m/A9yc= =d0DQ -----END PGP SIGNATURE----- --nextPart2094612.6Qmls5AWhV-- From nobody Tue Jun 19 08:06:55 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8928E130EA8 for ; Tue, 19 Jun 2018 08:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlKh8b-qjdlx for ; Tue, 19 Jun 2018 08:06:47 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 75956130E9F for ; Tue, 19 Jun 2018 08:06:47 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w5JF6lcg023264; Tue, 19 Jun 2018 16:06:47 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=Q5QHl2w6XvKUbkc1kRPDyTdrrnX5kGJh7E650rJra5U=; b=mtHySPSZTUt7blnUJ9bo4lizl7PJ4fS+0XOBrLETUC4dgL6Gbn/accCpv38TUurLthmo VOeOP7u8082QQyjsdKnJ+PMtL6ao3imOx1AqporvyksTteOuxgxFJw9VEtENXLKOcVU1 tMe3Ym5K2c8fI087U9Tx7mNhQNJ4P4FJSBrSH2AZZRvtlngg8+GF/TJumWnVx4nxWHyO wnpiygvqc+UijGuDb4CSt7ulj7UIByrvPuVrUrdebOU+AKCpYq0NKNw0dRC9P15h/mj4 F34LsVNlCmKBq+4BwqH2pNHCcQqxNEvjIugz2Kt1Sza1RmuuLIlGvwDw3Uy/mbNFKz8G /g== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2jmt3393mq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 19 Jun 2018 16:06:46 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5JF5Q7T014881; Tue, 19 Jun 2018 11:06:45 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint3.akamai.com with ESMTP id 2jmwwc4vxh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Jun 2018 11:06:45 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 19 Jun 2018 10:06:44 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Tue, 19 Jun 2018 10:06:44 -0500 From: "Salz, Rich" To: Ben Personick , TLS WG Thread-Topic: [TLS] Mail regarding draft-ietf-tls-tls13 Thread-Index: AdQCh415dfE0g1svTxONss1UmLapVwDjhDMAAEaFNIAABw3fAAAFfVSAACFpHgA= Date: Tue, 19 Jun 2018 15:06:44 +0000 Message-ID: <085E5CF6-0879-48DE-A8C5-A3C8F5C48F86@akamai.com> References: <897AC345-0832-4252-9D96-5A030CBEAD25@dukhovni.org> <7D370F20-3C5C-4347-9EA3-3F0F61458377@dukhovni.org> <5fdded19-da5c-4d23-a0e3-e4e9e905f7aa@iongroup.com> In-Reply-To: <5fdded19-da5c-4d23-a0e3-e4e9e905f7aa@iongroup.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.28] Content-Type: multipart/alternative; boundary="_000_085E5CF6087948DEA8C5A3C8F5C48F86akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-19_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=899 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806190169 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-19_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=822 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806190169 Archived-At: Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 19 Jun 2018 15:06:54 -0000 --_000_085E5CF6087948DEA8C5A3C8F5C48F86akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiAgU2luY2UgVExTIDEuMyB3aWxsIGNvbnRpbnVlIHRvIGFsbG93IGVjZHNhX3JzYSBjaXBoZXJz LCB0aGVyZSB3aWxsIGJlIG5vIHB1c2ggdG8gbW92ZSB0b3dhcmRzIG9mZmVyaW5nIHRoZW0sIGJl Y2F1c2Ugb2YgdmFyaW91cyAncmVhc29ucycuDQoNCkkgdGhpbmsgeW91IG1lYW4gRUNESCB3aXRo IFJTQS4gIEJ1dCB5ZXMsIHRoYXTigJlzIGEgY29tbW9uIHNpdHVhdGlvbiwgZmV3IG9yZ2FuaXph dGlvbnMgcGF5IHRvIGFkZCBzZWN1cml0eSB1bnRpbCB0aGV54oCZcmUg4oCcZm9yY2Vk4oCdIHRv IGRvIHNvLiAgWW914oCZcmUgbm90IGFsb25lLg0K --_000_085E5CF6087948DEA8C5A3C8F5C48F86akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLmVtYWlscXVvdGUsIGxpLmVt YWlscXVvdGUsIGRpdi5lbWFpbHF1b3RlDQoJe21zby1zdHlsZS1uYW1lOmVtYWlscXVvdGU7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDoxLjBwdDsNCglib3JkZXI6bm9uZTsNCglw YWRkaW5nOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPiZndDs8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7IFNpbmNlIFRMUyAx LjMgd2lsbCBjb250aW51ZSB0byBhbGxvdyBlY2RzYV9yc2EgY2lwaGVycywgdGhlcmUgd2lsbCBi ZSBubyBwdXNoIHRvIG1vdmUgdG93YXJkcyBvZmZlcmluZyB0aGVtLCBiZWNhdXNlIG9mIHZhcmlv dXMgJ3JlYXNvbnMnLjxicj4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHlvdSBtZWFuIEVDREggd2l0aCBSU0EuJm5ic3A7 IEJ1dCB5ZXMsIHRoYXTigJlzIGEgY29tbW9uIHNpdHVhdGlvbiwgZmV3IG9yZ2FuaXphdGlvbnMg cGF5IHRvIGFkZCBzZWN1cml0eSB1bnRpbCB0aGV54oCZcmUg4oCcZm9yY2Vk4oCdIHRvIGRvIHNv LiZuYnNwOyBZb3XigJlyZSBub3QgYWxvbmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_085E5CF6087948DEA8C5A3C8F5C48F86akamaicom_-- From nobody Tue Jun 19 10:00:55 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1870131147 for ; Tue, 19 Jun 2018 08:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iontradingcom.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koKQdJvg3iqs for ; Tue, 19 Jun 2018 08:17:27 -0700 (PDT) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710088.outbound.protection.outlook.com [40.107.71.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B19F2130E3C for ; Tue, 19 Jun 2018 08:17:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iontradingcom.onmicrosoft.com; s=selector1-iongroup-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s8MVy0v2pUeXKpeL/D328ZvXPqAAqN1BpwTNK7zmhOs=; b=hGA5jsBe3pluOpQFCqc/ViG+hHqKPQcyiXzq5H7qIYM5QyUROGclHZbmkvqdstad3JsGlRBbJ6MLOxWRFCuJFVcKABNcHZKK9pEBB6jF6zs2j0hCtLp9dIvsCOM7J+hsSRxCb8aVtHMEvvYarMM4gU2Vj63G/7wuLNIq8iyi2Vw= Received: from BN7PR14MB2356.namprd14.prod.outlook.com (20.176.22.33) by BN7PR14MB2114.namprd14.prod.outlook.com (20.176.21.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.16; Tue, 19 Jun 2018 15:17:26 +0000 Received: from BN7PR14MB2356.namprd14.prod.outlook.com ([fe80::ac24:4123:784d:29f7]) by BN7PR14MB2356.namprd14.prod.outlook.com ([fe80::ac24:4123:784d:29f7%3]) with mapi id 15.20.0863.016; Tue, 19 Jun 2018 15:17:26 +0000 From: Ben Personick To: "Salz, Rich" , TLS WG Thread-Topic: [TLS] Mail regarding draft-ietf-tls-tls13 Thread-Index: AdQCh415dfE0g1svTxONss1UmLapVwDZCf0AAEaFOTYABw3aAAAFfUx5ACnK6wAAAAMfcA== Date: Tue, 19 Jun 2018 15:17:26 +0000 Message-ID: References: <897AC345-0832-4252-9D96-5A030CBEAD25@dukhovni.org> <7D370F20-3C5C-4347-9EA3-3F0F61458377@dukhovni.org> <5fdded19-da5c-4d23-a0e3-e4e9e905f7aa@iongroup.com> <085E5CF6-0879-48DE-A8C5-A3C8F5C48F86@akamai.com> In-Reply-To: <085E5CF6-0879-48DE-A8C5-A3C8F5C48F86@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ben.personick@iongroup.com; x-originating-ip: [38.108.249.203] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN7PR14MB2114; 7:iksaL0bDGDSKh5wq67M8+mNHUKhTkiegS0brFjF1vF/Wu04VeNf+bG+xebQPCSa7u374GYcEut6h1+6aTFkoUYr1S7gFDWf9gZSwri4h/XrG9TDcXHOTyZhBqryoXWnCRr/NQ5JoZiWuVfw1RhABPM7DzWKQTjnWKrP6iHfaZRu7gYHHnvXXUsVNNhKB4uyV2b4bxh9fHy1fEk11/Ahz3lwr55Z+lgr/yZaAWqs1mp/GEP4Lt5a94Ke5M1gSyvO3 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 5947481d-8789-427e-9735-08d5d5f7c403 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:BN7PR14MB2114; x-ms-traffictypediagnostic: BN7PR14MB2114: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231254)(944501410)(52105095)(93006095)(93001095)(3002001)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:BN7PR14MB2114; BCL:0; PCL:0; RULEID:; SRVR:BN7PR14MB2114; x-forefront-prvs: 07083FF734 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39380400002)(376002)(346002)(366004)(396003)(199004)(189003)(5250100002)(81156014)(8936002)(81166006)(5660300001)(76176011)(6436002)(6246003)(110136005)(7696005)(316002)(25786009)(93886005)(2900100001)(54896002)(6116002)(68736007)(790700001)(9686003)(9326002)(6306002)(2906002)(86362001)(3846002)(186003)(53936002)(6506007)(74316002)(229853002)(106356001)(99286004)(14454004)(26005)(97736004)(44832011)(53546011)(3660700001)(476003)(59450400001)(8676002)(55016002)(486006)(105586002)(446003)(11346002)(3280700002)(478600001)(66066001)(7736002)(102836004)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR14MB2114; H:BN7PR14MB2356.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: iongroup.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: TMVpqdaiQ19+uLTKD/yI1yHgbvwT+kcNUr753GTh0XQgEWHppriHm9FgGQQ8h64iGMWC1rmpNLoPz4XI+QND9YTp0tK4NcwKheekno2pQgQFoMDL/uWph+XtJM6ZhzLSj8qMh7n7XAoEdaYjF1GJYUzL498wU2dk43VsdNekqnOpsJZVDeQNOLZBAS/hOTc5Y9UgdSG3BXfhovO4cjjZ5jjWOXYN2VKM+Fr6ctJa681ldO/uwe/WjnH2bWiks5qD36lwKuaB3ZZh7qnXRoSD+93DzF7x+EO+inZ6hU6zcTy0C0N7OMwy+IOnr/j18wzK4ZmH/iIZrCDI8pVyhih84Q== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN7PR14MB2356778AD43FDB1ED5F229D591700BN7PR14MB2356namp_" MIME-Version: 1.0 X-OriginatorOrg: iongroup.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5947481d-8789-427e-9735-08d5d5f7c403 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2018 15:17:26.3751 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 768fe7d4-ebee-41a7-9851-d5825ecdd396 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR14MB2114 Archived-At: X-Mailman-Approved-At: Tue, 19 Jun 2018 10:00:53 -0700 Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 19 Jun 2018 15:17:40 -0000 --_000_BN7PR14MB2356778AD43FDB1ED5F229D591700BN7PR14MB2356namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmljaCwNCiAgWWVzLCBJIG1lYW50IEVDREhFX0VDRFNBIGFuZCBFQ0RIRV9SU0EgYXJlIGJv dGggc3VwcG9ydGVkIGluIFRMUyAxLjMsIEnigJlkIGJlZW4gbGVhZCB0byBiZWxpZXZlIHRoYXQg YWxsIFJTQSBiYXNlZCBjaXBoZXJzIHdlcmUgbm90IHN1cHBvcnRlZC4NCg0KIEhhdmluZyBzZWVt IHNvbWUgZnVydGhlciByZXNwb25zZXMsIGl0IGFwcGVhcnMgaXQgaXMgb25seSB0aGUgTk9OIEVD REhFIFJTQSBCYXNlZCBjaXBoZXJzIHdoaWNoIGFyZSBoYXZpbmcgc3VwcG9ydCBkcm9wcGVkIGlu IFRMUyAxLjMNCg0KICBJZSBhbGwgTm9uLUVsbGlwdGljIEN1cnZlIERpZmZpZSBIZWxsbWFuIGNp cGhlcnMgKCBlZyBBRVMtMjU2IHcvbyBESCwgd2l0aCBESCBvciBFREgvREhFLCBidXQgbm90IEVD REhFX1JTQSkNCg0KICBBbmQgeWVhaCwgaXTigJlzIGJlZW4gbXkgZXhwZXJpZW5jZSBldmVyeXdo ZXJlLCBidXQgSSB3YXMgcHJldHR5IHB1bXBlZCB1cCB0byBoYXZlIGEgYmV0dGVyIHJlYXNvbiB0 byBwdXNoIHRvIHN0YXJ0IGltcGxlbWVudGluZyBFQ0RIRV9FQ0RTQSBDaXBoZXJzIGluIGFkZGl0 aW9uIHRvIG91ciBleGlzdGluZyBDaXBoZXJzLg0KQmVuDQpGcm9tOiBTYWx6LCBSaWNoIFttYWls dG86cnNhbHpAYWthbWFpLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEp1bmUgMTksIDIwMTggMTE6MDcg QU0NClRvOiBCZW4gUGVyc29uaWNrIDxiZW4ucGVyc29uaWNrQGlvbmdyb3VwLmNvbT47IFRMUyBX RyA8dGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUTFNdIE1haWwgcmVnYXJkaW5nIGRyYWZ0 LWlldGYtdGxzLXRsczEzDQoNCj4gIFNpbmNlIFRMUyAxLjMgd2lsbCBjb250aW51ZSB0byBhbGxv dyBlY2RzYV9yc2EgY2lwaGVycywgdGhlcmUgd2lsbCBiZSBubyBwdXNoIHRvIG1vdmUgdG93YXJk cyBvZmZlcmluZyB0aGVtLCBiZWNhdXNlIG9mIHZhcmlvdXMgJ3JlYXNvbnMnLg0KSSB0aGluayB5 b3UgbWVhbiBFQ0RIIHdpdGggUlNBLiAgQnV0IHllcywgdGhhdOKAmXMgYSBjb21tb24gc2l0dWF0 aW9uLCBmZXcgb3JnYW5pemF0aW9ucyBwYXkgdG8gYWRkIHNlY3VyaXR5IHVudGlsIHRoZXnigJly ZSDigJxmb3JjZWTigJ0gdG8gZG8gc28uICBZb3XigJlyZSBub3QgYWxvbmUuDQo= --_000_BN7PR14MB2356778AD43FDB1ED5F229D591700BN7PR14MB2356namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLmVtYWlscXVvdGUsIGxpLmVt YWlscXVvdGUsIGRpdi5lbWFpbHF1b3RlDQoJe21zby1zdHlsZS1uYW1lOmVtYWlscXVvdGU7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDoxLjBwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5IaSBSaWNoLDwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyBZZXMsIEkgbWVh bnQgRUNESEVfRUNEU0EgYW5kIEVDREhFX1JTQSBhcmUgYm90aCBzdXBwb3J0ZWQgaW4gVExTIDEu MywgSeKAmWQgYmVlbiBsZWFkIHRvIGJlbGlldmUgdGhhdCBhbGwgUlNBIGJhc2VkIGNpcGhlcnMg d2VyZSBub3Qgc3VwcG9ydGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7SGF2aW5nIHNlZW0gc29tZSBmdXJ0aGVyIHJlc3BvbnNlcywgaXQgYXBwZWFycyBpdCBp cyBvbmx5IHRoZSBOT04gRUNESEUgUlNBIEJhc2VkIGNpcGhlcnMgd2hpY2ggYXJlIGhhdmluZyBz dXBwb3J0IGRyb3BwZWQgaW4gVExTIDEuMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7IEllIGFsbCBOb24tRWxsaXB0aWMgQ3VydmUgRGlmZmllIEhlbGxtYW4gY2lw aGVycyAoIGVnIEFFUy0yNTYgdy9vIERILCB3aXRoIERIIG9yIEVESC9ESEUsIGJ1dCBub3QgRUNE SEVfUlNBKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7IEFuZCB5 ZWFoLCBpdOKAmXMgYmVlbiBteSBleHBlcmllbmNlIGV2ZXJ5d2hlcmUsIGJ1dCBJIHdhcyBwcmV0 dHkgcHVtcGVkIHVwIHRvIGhhdmUgYSBiZXR0ZXIgcmVhc29uIHRvIHB1c2ggdG8gc3RhcnQgaW1w bGVtZW50aW5nIEVDREhFX0VDRFNBIENpcGhlcnMgaW4gYWRkaXRpb24gdG8gb3VyIGV4aXN0aW5n IENpcGhlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5CZW48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+RnJvbTo8L2I+IFNhbHosIFJpY2ggW21haWx0bzpyc2FsekBha2FtYWkuY29t XSA8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVuZSAxOSwgMjAxOCAxMTowNyBBTTxicj4N CjxiPlRvOjwvYj4gQmVuIFBlcnNvbmljayAmbHQ7YmVuLnBlcnNvbmlja0Bpb25ncm91cC5jb20m Z3Q7OyBUTFMgV0cgJmx0O3Rsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtUTFNdIE1haWwgcmVnYXJkaW5nIGRyYWZ0LWlldGYtdGxzLXRsczEzPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPiZuYnNwOyBTaW5jZSBUTFMgMS4zIHdpbGwgY29udGludWUgdG8gYWxsb3cgZWNkc2FfcnNh IGNpcGhlcnMsIHRoZXJlIHdpbGwgYmUgbm8gcHVzaCB0byBtb3ZlIHRvd2FyZHMgb2ZmZXJpbmcg dGhlbSwgYmVjYXVzZSBvZiB2YXJpb3VzICdyZWFzb25zJy48L3NwYW4+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB5b3UgbWVhbiBFQ0RIIHdpdGgg UlNBLiZuYnNwOyBCdXQgeWVzLCB0aGF04oCZcyBhIGNvbW1vbiBzaXR1YXRpb24sIGZldyBvcmdh bml6YXRpb25zIHBheSB0byBhZGQgc2VjdXJpdHkgdW50aWwgdGhleeKAmXJlIOKAnGZvcmNlZOKA nSB0byBkbyBzby4mbmJzcDsgWW914oCZcmUgbm90IGFsb25lLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN7PR14MB2356778AD43FDB1ED5F229D591700BN7PR14MB2356namp_-- From nobody Tue Jun 19 10:07:23 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576AD13118F for ; Tue, 19 Jun 2018 10:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Jdw8soov4job for ; Tue, 19 Jun 2018 10:07:18 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B94EA131185 for ; Tue, 19 Jun 2018 10:07:18 -0700 (PDT) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id DE7387A3309; Tue, 19 Jun 2018 17:07:17 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Viktor Dukhovni In-Reply-To: Date: Tue, 19 Jun 2018 13:07:17 -0400 Cc: TLS WG Reply-To: TLS WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <897AC345-0832-4252-9D96-5A030CBEAD25@dukhovni.org> <7D370F20-3C5C-4347-9EA3-3F0F61458377@dukhovni.org> <5fdded19-da5c-4d23-a0e3-e4e9e905f7aa@iongroup.com> <085E5CF6-0879-48DE-A8C5-A3C8F5C48F86@akamai.com> To: Ben Personick X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 19 Jun 2018 17:07:21 -0000 > On Jun 19, 2018, at 11:17 AM, Ben Personick = wrote: >=20 > Yes, I meant ECDHE_ECDSA and ECDHE_RSA are both supported in TLS = 1.3, I=E2=80=99d been lead to believe that all RSA based ciphers were = not supported. > =20 > Having seem some further responses, it appears it is only the NON = ECDHE RSA Based ciphers which are having support dropped in TLS 1.3 I may have been too cryptic. When I wrote (EC)DHE I meant both DHE and = ECDHE. However, some (early) implementations may only support ECDHE with TLS = 1.3. IIRC, OpenSSL 1.1.1 does not yet support the TLS 1.3 DHE groups. So interoperability if you only support DHE may be problematic. --=20 Viktor. From nobody Tue Jun 19 16:07:06 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C873130FE4 for ; Tue, 19 Jun 2018 16:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 VzZycwWRsGZJ for ; Tue, 19 Jun 2018 16:06:57 -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 DFF49130E35 for ; Tue, 19 Jun 2018 16:06:44 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (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 419NrL0ZLGzHQ; Wed, 20 Jun 2018 01:06:42 +0200 (CEST) X-purgate-ID: 152705::1529449602-0000081F-D6E48E2D/0/0 X-purgate-size: 1598 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 mail07.wdf.sap.corp (Postfix) with ESMTP id 419NrJ6DPZzGpc5; Wed, 20 Jun 2018 01:06:40 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id C4A0D409C; Wed, 20 Jun 2018 01:06:40 +0200 (CEST) In-Reply-To: References: To: Ben Personick Date: Wed, 20 Jun 2018 01:06:40 +0200 (CEST) CC: "tls@ietf.org" Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20180619230640.C4A0D409C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 19 Jun 2018 23:07:04 -0000 Ben Personick wrote: > > (My apology for the long email, I did not have time to write a shorter one) > We are currently evaluating when to begin offering ECC Certificates > based cypto on our websites. > > Despite the advantages to doing this in TLS 1.2, there is a lot of > push-back to wait until we "have to support it" once the TLS 1.3 draft > is published, and the option to use it becomes available. Honestly, why would you want to do this? ECC/RSA Dual Cert setups a cryptographically a bad idea, and a real nuisance for interoperability. Elliptic Curve Crypto, when used with the design-flawed ECDSA digital signature algorithm, might leak the private key within a few thousand TLS full handshakes to a mere passive observer. Support for EdDSA is somewhere between thin and non-existent still. And for programmatic TLS clients, which take security serious, and do not come with hundreds of public CA certificates preconfigured as trusted, a sudden change of the TLS server certificate when rearranging TLS cipher suites or when the underlying TLS implementation starts include support for ECDSA certificates, can easily result in a sudden unexpected loss of interop (missing trust). Testing that you have the required trust properly configured for *BOTH* TLS server certs is a royal pita, and _preparing_ for a TLS client software update that adds support for ECDSA cipher suites is pretty much impossible to test (unless you already have that implementation, but that is not what I meant with preparing). -Martin From nobody Wed Jun 20 02:48:33 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D0313106A for ; Wed, 20 Jun 2018 02:48:31 -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 autolearn_force=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 MXfp8NbXp-XR for ; Wed, 20 Jun 2018 02:48:28 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02EC3131067 for ; Wed, 20 Jun 2018 02:48:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id EF2C35496C; Wed, 20 Jun 2018 12:48:25 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id QzOI_ePgBtmp; Wed, 20 Jun 2018 12:48:25 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 3CA5772; Wed, 20 Jun 2018 12:48:23 +0300 (EEST) Date: Wed, 20 Jun 2018 12:48:08 +0300 From: Ilari Liusvaara To: Ben Personick Cc: TLS WG Message-ID: <20180620094808.GA23612@LK-Perkele-VII> References: <897AC345-0832-4252-9D96-5A030CBEAD25@dukhovni.org> <7D370F20-3C5C-4347-9EA3-3F0F61458377@dukhovni.org> <5fdded19-da5c-4d23-a0e3-e4e9e905f7aa@iongroup.com> <085E5CF6-0879-48DE-A8C5-A3C8F5C48F86@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 20 Jun 2018 09:48:31 -0000 On Tue, Jun 19, 2018 at 03:17:26PM +0000, Ben Personick wrote: > Hi Rich, > Yes, I meant ECDHE_ECDSA and ECDHE_RSA are both supported in TLS 1.3, I’d been lead to believe that all RSA based ciphers were not supported. > > Having seem some further responses, it appears it is only the NON ECDHE RSA Based ciphers which are having support dropped in TLS 1.3 > > Ie all Non-Elliptic Curve Diffie Hellman ciphers ( eg AES-256 w/o DH, with DH or EDH/DHE, but not ECDHE_RSA) > > And yeah, it’s been my experience everywhere, but I was pretty pumped up to have a better reason to push to start implementing ECDHE_ECDSA Ciphers in addition to our existing Ciphers. I made a list of all supported cryptographic algorithms in base TLS 1.3: - Algorithms marked with [W] are widely supported. - If preshared keys are used, no signatures are used (ligtens load at cost of poor scalability). - If preshared keys are used, those may be combined with asymmetric key exchange (or may be used alone, giving very light but poorly scalable key exchange). - There are no-protocol level constraints on mixing and matching algorithms of different kinds (except symmetric cipher and handshake hash). The server might tweak relative preferences to try avoid wide mismatches in strength, but MUST enable full cartesian product. - Most work in TLS 1.2 too, if supported: - The negotiation for classical Diffie-Hellman is broken in TLS 1.2, leading many clients to just disable classical Diffie-Hellman (1.3 fixes this issue). - Classical Diffie-Hellman can only be combined with RSA signatures (others can be combined with all signature types). Asymmetric key exchanges: - Elliptic-curve Diffie-Hellman using NIST P-256 curve[W] - Elliptic-curve Diffie-Hellman ECDH using NIST P-384 curve[W] - X25519 key exchange (a.k.a. Curve25519)[W] - Elliptic-curve Diffie-Hellman ECDH using NIST P-521 curve - X448 key exchange - Diffie-Hellman with p=Pe(2048, 560316) - Diffie-Hellman with p=Pe(3072, 2625351) - Diffie-Hellman with p=Pe(4096, 5736041) - Diffie-Hellman with p=Pe(6144, 15705020) - Diffie-Hellman with p=Pe(8192, 10965728) Where: Pe(n,x) = 2^n-2^(n-64)+{[2^(n-130)*e]+x}*2^64-1 (a n-bit prime) Signature algorithms: - RSA-PSS using SHA-256 (using generic RSA or RSA-PSS keys)[W] - RSA-PSS using SHA-384 (using generic RSA or RSA-PSS keys)[W] - RSA-PSS using SHA-512 (using generic RSA or RSA-PSS keys)[W] - ECDSA usign NIST P-256 curve and SHA-256[W] - ECDSA usign NIST P-384 curve and SHA-384[W] - ECDSA usign NIST P-521 curve and SHA-512[W] - RSA PKCS#1v1.5 using SHA-256 (certificate signing only)[W] - RSA PKCS#1v1.5 using SHA-384 (certificate signing only)[W] - RSA PKCS#1v1.5 using SHA-512 (certificate signing only)[W] - Ed25519 - Ed448 Symmetric algorithms: - 128-bit AES in GCM mode with SHA-256 handshake hash.[W] - 256-bit AES in GCM mode with SHA-384 handshake hash.[W] - 256-bit Chacha20 and Poly1305 with SHA-256 handshake hash.[W] - 128-bit AES in CCM mode with SHA-256 handshake hash. - 128-bit AES in CCM(64-bit tag) mode with SHA-256 handshake hash. -Ilari From nobody Wed Jun 20 03:00:19 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD0D130DEB for ; Wed, 20 Jun 2018 03:00:18 -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 autolearn_force=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 pbe_kXNhM1Nw for ; Wed, 20 Jun 2018 03:00:15 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95D7C130DD0 for ; Wed, 20 Jun 2018 03:00:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id F3A8B4EF6E; Wed, 20 Jun 2018 13:00:13 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id fs9nOgkpg79o; Wed, 20 Jun 2018 13:00:13 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 4CFF772; Wed, 20 Jun 2018 13:00:11 +0300 (EEST) Date: Wed, 20 Jun 2018 12:59:56 +0300 From: Ilari Liusvaara To: Nikos Mavrogiannopoulos Cc: "tls@ietf.org" Message-ID: <20180620095956.GB23612@LK-Perkele-VII> References: <2132206.KQKFhKinhY@pintsize.usersys.redhat.com> <7BE4BC91-5324-42A6-8AB7-084439ED9527@akamai.com> <3a8d1eab6bbf042c396da1085427f49da8d4c2f4.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3a8d1eab6bbf042c396da1085427f49da8d4c2f4.camel@redhat.com> User-Agent: Mutt/1.10.0 (2018-05-17) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Universal PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 20 Jun 2018 10:00:18 -0000 On Mon, Jun 18, 2018 at 11:47:25AM +0200, Nikos Mavrogiannopoulos wrote: > On Fri, 2018-06-15 at 14:24 +0000, Salz, Rich wrote: > > > that's not workable. > > > > > > It's not great, however > > > > > the reason why implementations chose to use old API to provision > > > TLS 1.3 PSKs > > > > was to make the upgrade process as smooth as possible, disabling > > TLS 1.3 is > > quite antithetical to that > > > > Disabling TLS 1.3 for those using 1.2 PSK's is unlikely to affect > > most uses, and seems the only way forward. > > > > Do you have an alternative solution? > > TLS 1.3 provides a solution. These secrets under TLS1.3 are restricted > to using the SHA256 PRF. That's how we have implemented it in gnutls. One thing to be careful with here is interoperability. In fact, with using PSKs across protocol versions and hashes in all sorts of ways the specifications say they should not, that is the prinicpal worry I have, above security implications. Specifically, one has PSK usable for TLS 1.2 and 1.3: Is that PSK the same for both protocols or is there something like universal-PSK (which causes the effective PSK not to be the same) going on? I tried to cook up attacks against using PSKs across protocol versions and and hashes. Everything I could come up with stopped at literially the first hash encountered, unless at least one of: - The hash has some pathological properties. - The hash has some other properties that cast serious doubt on its security. - The hash is outright broken (which breaks TLS 1.2 and TLS 1.3 anyway). - The ciphersuite on TLS 1.2 side uses non-conventional PRF. - PSK has insufficient entropy and is vulernable to brute-force. Of course, formally proving anything like this is extremely hard at best, and most probably impossible (the pathological hashes alone would already cause extreme trouble, or outright block any proof). And given the usefulness of proofs in finding various (subtle) mistakes, there could still be severe problems. -Ilari From nobody Wed Jun 20 17:02:20 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8FA131185 for ; Tue, 19 Jun 2018 10:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iontradingcom.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SIeOEa_ErXq for ; Tue, 19 Jun 2018 10:10:45 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0087.outbound.protection.outlook.com [104.47.32.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 C8D9A130DE3 for ; Tue, 19 Jun 2018 10:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iontradingcom.onmicrosoft.com; s=selector1-iongroup-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=H576XFz7oiBnPHASbyTaRepHfnr9Hi+71nyHEW+R0fY=; b=lWkON3R35grPZcFOCKGY2wg3cZxvMayf8hUm0QaxKxi7tjdg2AI5iGO7E7ii+RHVvQd626xpesUB7jzRYqi4uvcIlApetaEUOFc1hv1bQUpwx6IVj+MiFGnEmxD1R23aSGgF+jD0yz6YBV2/vCM4Y0fz8HjoxiRodfjCgDH+7VA= Received: from BN7PR14MB2356.namprd14.prod.outlook.com (20.176.22.33) by BN7PR14MB2259.namprd14.prod.outlook.com (20.176.20.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.17; Tue, 19 Jun 2018 17:10:44 +0000 Received: from BN7PR14MB2356.namprd14.prod.outlook.com ([fe80::ac24:4123:784d:29f7]) by BN7PR14MB2356.namprd14.prod.outlook.com ([fe80::ac24:4123:784d:29f7%3]) with mapi id 15.20.0863.016; Tue, 19 Jun 2018 17:10:44 +0000 From: Ben Personick To: TLS WG Thread-Topic: [TLS] Mail regarding draft-ietf-tls-tls13 Thread-Index: AdQCh415dfE0g1svTxONss1UmLapVwDZCf0AAEaFOTYABw3aAAAFfUx5ACnK6wAAAAMfcAAEMq6AAAAe2Bo= Date: Tue, 19 Jun 2018 17:10:44 +0000 Message-ID: References: <897AC345-0832-4252-9D96-5A030CBEAD25@dukhovni.org> <7D370F20-3C5C-4347-9EA3-3F0F61458377@dukhovni.org> <5fdded19-da5c-4d23-a0e3-e4e9e905f7aa@iongroup.com> <085E5CF6-0879-48DE-A8C5-A3C8F5C48F86@akamai.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ben.personick@iongroup.com; x-originating-ip: [38.108.249.203] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN7PR14MB2259; 7:yR4Dh/E4kV+9CxwJAy6x2W+82oURZFccej4X6FdbRAiHl40SMGzRbML0SIoc0S0m50yjLh/hApfixabJVLvtBTWtVwhWNSeQYCpOAfQnEnboHMo9SJX+tNLs8/KoLtyXVUbneAGkVdvapicndb/LfJ6yU5Fvj2nXlAfgQJyRqnyBLeW8VanWKTghZyLKKO2OeH/QFH0cVBf0ZaY5X5xmmNfY5K42MzdiNdMPmRPiHzuP6PXB7W69ETz0TYMlZudj x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ccb5b1d6-c01d-4f8a-1e70-08d5d60797ce x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:BN7PR14MB2259; x-ms-traffictypediagnostic: BN7PR14MB2259: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231254)(944501410)(52105095)(3002001)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:BN7PR14MB2259; BCL:0; PCL:0; RULEID:; SRVR:BN7PR14MB2259; x-forefront-prvs: 07083FF734 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39380400002)(346002)(376002)(366004)(396003)(189003)(199004)(8936002)(2906002)(2900100001)(2616005)(6436002)(8676002)(476003)(11346002)(3660700001)(6246003)(81166006)(53936002)(97736004)(446003)(66066001)(36756003)(31696002)(81156014)(25786009)(6512007)(86362001)(3280700002)(54896002)(316002)(76176011)(93886005)(105586002)(486006)(5660300001)(229853002)(6116002)(6916009)(106356001)(102836004)(6506007)(59450400001)(478600001)(3846002)(186003)(99286004)(26005)(7736002)(5250100002)(14454004)(68736007)(6486002)(31686004)(53546011)(44832011); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR14MB2259; H:BN7PR14MB2356.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: iongroup.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ar1noD262t5KuwhMqoGi0C8OU5tgJal+toPB75fFqJyuLE5sG5Vjp5sUlhcBGc4tY9+IA2Gb71fElDT7yJmNU2tqLR6T/I5LMaBnHqPAfHw0YWXs3zx/aRZZ9BXQ5k60sY/RWjofR/MnFfZf604RUs8YjsHu2sUojiBQJeuTFralRf4q951RfuuJYKTdV6jWogDoPAZp0VPtpJE5qeAnxw0O7ATGMVz0edgyVS0TH8i30dQI7h8oUaAqCLsqhFpvPzWoXc25O0FNItMW/N2EisC2QUbpq2QBJKwSxNjYJxAPlrQxIn9VHXcFhu74aqJBsOmjWFFJGN0BIIGKXhPYZA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_cccd915dbf8d43ecb99929c436c9b522iongroupcom_" MIME-Version: 1.0 X-OriginatorOrg: iongroup.com X-MS-Exchange-CrossTenant-Network-Message-Id: ccb5b1d6-c01d-4f8a-1e70-08d5d60797ce X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2018 17:10:44.1838 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 768fe7d4-ebee-41a7-9851-d5825ecdd396 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR14MB2259 Archived-At: X-Mailman-Approved-At: Wed, 20 Jun 2018 17:02:19 -0700 Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 19 Jun 2018 17:10:49 -0000 --_000_cccd915dbf8d43ecb99929c436c9b522iongroupcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Victor, We've never supported DHE, and are skipping it to ECDHE as DHE is conside= red by our security scans to be too insecure (as our LB's implementation is= capped at 1024 bit ephemerals) ________________________________ From: Viktor Dukhovni Sent: Tuesday, June 19, 2018 1:07 PM To: Ben Personick Cc: TLS WG Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 > On Jun 19, 2018, at 11:17 AM, Ben Personick = wrote: > > Yes, I meant ECDHE_ECDSA and ECDHE_RSA are both supported in TLS 1.3, I= =92d been lead to believe that all RSA based ciphers were not supported. > > Having seem some further responses, it appears it is only the NON ECDHE = RSA Based ciphers which are having support dropped in TLS 1.3 I may have been too cryptic. When I wrote (EC)DHE I meant both DHE and ECD= HE. However, some (early) implementations may only support ECDHE with TLS 1.3. IIRC, OpenSSL 1.1.1 does not yet support the TLS 1.3 DHE groups. So interoperability if you only support DHE may be problematic. -- Viktor. --_000_cccd915dbf8d43ecb99929c436c9b522iongroupcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Victor,

  We've never supported DHE, and are skipping it to ECDHE as DHE is co= nsidered by our security scans to be too insecure (as our LB's implementati= on is capped at 1024 bit ephemerals)

From: Vi= ktor Dukhovni <ietf-dane@dukhovni.org>
Sent: Tuesday, June 19, 2018 1:07 PM
To: Ben Personick
Cc: TLS WG
Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13



> On Jun 19, 2018, at 11:17 AM, Ben Personick <ben.personick@iongroup= .com> wrote:
>
>   Yes, I meant ECDHE_ECDSA and ECDHE_RSA are both supported = in TLS 1.3, I=92d been lead to believe that all RSA based ciphers were not = supported.
> 
>  Having seem some further responses, it appears it is only the NO= N ECDHE RSA Based ciphers which are having support dropped in TLS 1.3

I may have been too cryptic.  When I wrote (EC)DHE I meant both DHE an= d ECDHE.
However, some (early) implementations may only support ECDHE with TLS 1.3.<= br> IIRC, OpenSSL 1.1.1 does not yet support the TLS 1.3 DHE groups.  So interoperability if you only support DHE may be problematic.

--
        Viktor.

 --_000_cccd915dbf8d43ecb99929c436c9b522iongroupcom_-- From nobody Fri Jun 22 15:30:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E241130F0D; Fri, 22 Jun 2018 15:30:16 -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 autolearn_force=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 VsmvuNLUzDFg; Fri, 22 Jun 2018 15:30:14 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A67CD130EFF; Fri, 22 Jun 2018 15:30:14 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 765D8B80197; Fri, 22 Jun 2018 15:30:12 -0700 (PDT) To: lscorco@nsa.gov, tim@dierks.org, ekr@rtfm.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: ekr@rtfm.com, iesg@ietf.org, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180622223012.765D8B80197@rfc-editor.org> Date: Fri, 22 Jun 2018 15:30:12 -0700 (PDT) Archived-At: Subject: [TLS] [Errata Rejected] RFC5246 (4382) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 22 Jun 2018 22:30:17 -0000 The following errata report has been rejected for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid4382 -------------------------------------- Status: Rejected Type: Technical Reported by: Laura Corcoran Date Reported: 2015-05-29 Rejected by: EKR (IESG) Section: 4.3 Original Text ------------- In the following example, Datum is defined to be three consecutive bytes that the protocol does not interpret, while Data is three consecutive Datum, consuming a total of nine bytes. opaque Datum[3]; /* three uninterpreted bytes */ Datum Data[9]; /* 3 consecutive 3 byte vectors */ Corrected Text -------------- In the following example, Datum is defined to be three consecutive bytes that the protocol does not interpret, while Data is three consecutive Datum, consuming a total of nine bytes. opaque Datum[3]; /* three uninterpreted bytes */ Datum Data[3]; /* 3 consecutive 3 byte vectors */ Notes ----- The 9 in "Datum Data[9]" should be a 3 because Datum is a data type that consumes 3 bytes, so as written the Data vector is 27 bytes long. To make it a 9 byte vector the 9 must change to a 3. --VERIFIER NOTES-- This is not correct. The value here is the number of bytes, not the count of items. -------------------------------------- RFC5246 (draft-ietf-tls-rfc4346-bis-10) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.2 Publication Date : August 2008 Author(s) : T. Dierks, E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Mon Jun 25 21:20:43 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BCD130F5F for ; Mon, 25 Jun 2018 21:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VP38RG8ZuuvD for ; Mon, 25 Jun 2018 21:20:38 -0700 (PDT) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (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 116381277BB for ; Mon, 25 Jun 2018 21:20:38 -0700 (PDT) Received: by mail-qk0-x243.google.com with SMTP id b129-v6so8810628qke.7 for ; Mon, 25 Jun 2018 21:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GNqW5Eq0EOZuMq01hiLrUqhNJk821YP4IKitZO5UIV4=; b=WJ8YuBJ0H3u22k2iy19TL1cCAlL+MW+4HJA+rOj8UZI9UnOrZm7NK8Ydp17gRDKkZR NSPPEq9BMHB5BXSSccMcQArHZh9ZQpUhFKi7JQIAetf/CpuvGPKq6UX/A92v9a3Xcwse 0Xv1tsZa+nX0cjSrXTp4IjPOTnQ/DbqKbSxD+4socHoSv9SRseWeohkbNN7mlMP1eGr7 4U77zaPEGYeLlvjUFCplRADGpZDw5COZI6ygkBaYXc4LlTstmYNNR5OXNq56wMQiRFej Q40zZTtqATGsSI/ytDmU2FHFkkPVXiGEObo1fu7Kx3sxbdDDrPX3mY3ljzwNXnHvVPdb nGPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GNqW5Eq0EOZuMq01hiLrUqhNJk821YP4IKitZO5UIV4=; b=sARoT0gsWY0AI/oqh+0IRLrtPl0/NuVa5NgjN1d/PIoed1oCq3KbvOH9x1BS1txIFP i3cSH8kcC4kFNsK0UdqMH4oDCuUOKfpkIyGD3uVLpJI6B5vfiibEnKFsl5LgXlmmbJro 3+YE8c3FvH91dzF6Y2B8GZRadVQPP5gR9jf1l1mm4tBA6J3jbmYQoIe8WU1K7UHAgAAu KoLcimMjEK54YzWbrvABQlzC/7UedV8jvIrAqWYt/E0S5wWN8o1askMKKMPYTypAlUcJ qTd/EhNqGjL4k8MEJI87ch62IiF6L/B1U6yd+TUl0mJzIWD5vj1PMTqiuLH9YCksBSJf dEdA== X-Gm-Message-State: APt69E3v4PgqCm1elFFBtK304UGsB4R13oN/1++VUOrMRWZJYfUqpU/T MD6DYVuBKgNFelHx4p9hznL5xu3vJYeE9CGjrUokAg== X-Google-Smtp-Source: ADUXVKLDFgu1cZwcaTIUscDUMgcMPwWgOlnRzHeRXVc7RNBl1RoESG1xs2aNPKqoXN/+UfkzRGJhAGx4LPPb+yask+w= X-Received: by 2002:a37:7742:: with SMTP id s63-v6mr12606945qkc.97.1529986836927; Mon, 25 Jun 2018 21:20:36 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:35b4:0:0:0:0:0 with HTTP; Mon, 25 Jun 2018 21:20:16 -0700 (PDT) In-Reply-To: References: <20180604203947.GW13834@akamai.com> From: Joseph Salowey Date: Mon, 25 Jun 2018 21:20:16 -0700 Message-ID: To: Paul Wouters Cc: Benjamin Kaduk , "" Content-Type: multipart/alternative; boundary="000000000000ed338b056f83d148" Archived-At: Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2018 04:20:41 -0000 --000000000000ed338b056f83d148 Content-Type: text/plain; charset="UTF-8" Hi Folks, There has been some discussion with a small group of folks on github - https://github.com/tlswg/dnssec-chain-extension/pull/19. I want to make sure there is consensus in the working group to take on the pinning work and see if there is consensus for modifications in the revision. Please respond to the following questions on the list by July 10, 2018. 1. Do you support the working group taking on future work on a pinning mechanism (based on the modifications or another approach)? 2. Do you support the reserved bytes in the revision for a future pinning mechanism? 3. Do you support the proof of denial of existence text in the revision? 4. Do you support the new and improved security considerations? Thanks, Joe On Tue, Jun 5, 2018 at 6:51 AM, Paul Wouters wrote: > On Mon, 4 Jun 2018, Benjamin Kaduk wrote: > > Hi Ben, > > I've taken a stab at putting together some security considerations text for >> draft-ietf-tls-dnssec-chain-extension that reflects my understanding of >> the >> current state of affairs. It's in a pull request at >> https://github.com/tlswg/dnssec-chain-extension/pull/19 , along with >> Viktor's >> commit to update the text about the actual DNS records involved (which as >> far as I can tell seems to improve the technical accuracy of the text), >> and >> also inserting a variable-length array that's reserved for future attempts >> to mitigate the (now-)documented security considerations. >> > > Thanks for writing the proposed text. The new opaque Reserved field > along with the denial of existence changes you propose addresses all > my concerns. > > One corner case that might be worth mentioning with the proposed DoE text > is the odd corner case of hitting a server with a Host header for which > it is not configured. You will hit the "default vhost" but you have no > appropriate extension data to populate for that hostname. So either the > server will return the (cached) TLSA/DoA data of the 'wrong' hostname, > or it could just omit the extension. I'd mostly like to say something to > prevent an implementation of forgetting this corner case and causing > some vulnerability in their code later on by pointing to bogus memory or > crashing on dereferencing a NULL. > > Some nits: > > If the server supports this extension it performs the appropriate > DNS queries, > > In my PR I had changed this into "obtains the appropriate DNS RRsets", > because I envision that TLS servers might not do DNS lookups themselves, > but just read this via a file or other method. Eg a cron job that > regenerates these hourly for all the hosted domains. It also reduces > some fear that all TLS servers suddenly could need to link against > a DNSSEC library. They don't if they can just reload a blob from disk > regularly to serve up. > > Similarly: > > it will need to rebuild > > is better written as "it will need rebuilt data" > > > "authenticates the chain" > > That should probably be "validate the chain", but the document has more > mixups of validate vs authenticate. In my PR request I had not corrected > them in an effort to keep the diff as small as possible. > > I had modified the examples slightly, so the NSEC example would show a > simpler NSEC chain (from www to zzz) instead of the one wrapping around > from www to the zone apex. The example quoted is the wrong NSEC record > (the one from apex to www.example.com does not show that the > _443._tcp.www.example.com does not exist, you need the one from > www.example.com to the apex at the end of the zone) > > I'm not sure what you mean with: > > validated negative TTL > > I guess you mean to say the shortest TTL of any data in the chain? But > sometimes the negative cache time is larger then the TTL (eg if TTL = 0) > Since this is just generic DNS handling, I would probably just write > something like "up to the appropriate lifetime" and leave it out of > this document. > > denial of existence RRset > > Technically that should be "RRsets" since you usually will need more then > one RRset to prove this (to disprove existence of the wildcard record) > > - DNSSEC authentication chain extension from a server, SHOULD > use this > + DNSSEC authentication chain extension from a server, uses > this > > I'm not sure why the SHOULD was removed here? Since it is describing TLS > client behaviour the "uses this" confuses me as I dont know if that > means MAY, SHOULD or MUST. > > + Specifically, the relevant DANE records are included > + in the TLS handshake transcript hash, so both sides > + possess identical records; > > I'm not sure why you suggest to add this text. A TLS client might still > have cached a valid TLSA records from a previous connection 1 second > ago and might decide to not use this information at all. Also, it seems > to suggest that the transscript hash protects this data, but it is > "protection" using the webpki or proof of lack of MITM, but the data > does not need this protecting as it is protected by DNSSEC signatures. > > + the client remains responsible > + for actually performing the domain name validation of > + the DANE records. > > Well, if it just fired up a previous TLS connection, perhaps it will be > content with the same pubkey used and skip re-validating this data? I > guess we sort of say the same thing due to the lack of a MUST ? > > + The Reserved field is reserved for future updates to this > + document; in particular it is hoped that the issues discussed > + in can be addressed. > + Implementations of this specification MUST send a zero-length > vector > > Perhaps that last line can be clarified a bit: > > Implementation not implementing any updates to this document > MUST send a zero-length vector > > This sentence does not parse: > > "whether or not to the exclusion" > > This text is a little confusing to me: > > + certified by the DNS key hierarchy, that the > + server does not support DANE authentication > > The TLS server itself might support "DANE authentication", but there is > simply no data. Perhaps say that the server's configured hostname does > not support DANE authentication? > > Thanks again for the write up! > > Paul > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000ed338b056f83d148 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Jun 5, 2018 at = 6:51 AM, Paul Wouters <paul@nohats.ca> wrote:
On Mon, 4 Jun 2018, Benjamin Kaduk wrote:

Hi Ben,

I've taken a stab at putting together some security considerations text= for
draft-ietf-tls-dnssec-chain-extension that reflects my understanding o= f the
current state of affairs.=C2=A0 It's in a pull request at
https://github.com/tlswg/dnssec-chain-ex= tension/pull/19 , along with Viktor's
commit to update the text about the actual DNS records involved (which as far as I can tell seems to improve the technical accuracy of the text), and=
also inserting a variable-length array that's reserved for future attem= pts
to mitigate the (now-)documented security considerations.

 Thanks for writing the proposed text. The new opaque Reserved field
along with the denial of existence changes you propose addresses all
my concerns.

One corner case that might be worth mentioning with the proposed DoE text is the odd corner case of hitting a server with a Host header for which
it is not configured. You will hit the "default vhost" but you ha= ve no
appropriate extension data to populate for that hostname. So either the
server will return the (cached) TLSA/DoA data of the 'wrong' hostna= me,
or it could just omit the extension. I'd mostly like to say something t= o
prevent an implementation of forgetting this corner case and causing
some vulnerability in their code later on by pointing to bogus memory or crashing on dereferencing a NULL.

Some nits:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 If the server supports this extension it perfor= ms the appropriate DNS queries,

In my PR I had changed this into "obtains the appropriate DNS RRsets&q= uot;,
because I envision that TLS servers might not do DNS lookups themselves, but just read this via a file or other method. Eg a cron job that
regenerates these hourly for all the hosted domains. It also reduces
some fear that all TLS servers suddenly could need to link against
a DNSSEC library. They don't if they can just reload a blob from disk regularly to serve up.

Similarly:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 it will need to rebuild

is better written as "it will need rebuilt data"


=C2=A0 =C2=A0 =C2=A0 =C2=A0 "authenticates the chain"

That should probably be "validate the chain", but the document ha= s more
mixups of validate vs authenticate. In my PR request I had not corrected them in an effort to keep the diff as small as possible.

I had modified the examples slightly, so the NSEC example would show a
simpler NSEC chain (from www to zzz) instead of the one wrapping around
from www to the zone apex. The example quoted is the wrong NSEC record
(the one from apex to www.example.com does not show that the
_443._tcp.www.example.com does not exist, you need the one from
www= .example.com to the apex at the end of the zone)

I'm not sure what you mean with:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 validated negative TTL

I guess you mean to say the shortest TTL of any data in the chain? But
sometimes the negative cache time is larger then the TTL (eg if TTL =3D 0)<= br> Since this is just generic DNS handling, I would probably just write
something like "up to the appropriate lifetime" and leave it out = of
this document.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 denial of existence RRset

Technically that should be "RRsets" since you usually will need m= ore then
one RRset to prove this (to disprove existence of the wildcard record)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 -=C2=A0 =C2=A0 =C2=A0 DNSSEC authentication cha= in extension from a server, SHOULD use this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 DNSSEC authentication cha= in extension from a server, uses this

I'm not sure why the SHOULD was removed here? Since it is describing TL= S
client behaviour the "uses this" confuses me as I dont know if th= at
means MAY, SHOULD or MUST.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 + Specifically, the relevant DANE records are i= ncluded
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + in the TLS handshake transcript hash, so both= sides
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + possess identical records;

I'm not sure why you suggest to add this text. A TLS client might still=
have cached a valid TLSA records from a previous connection 1 second
ago and might decide to not use this information at all. Also, it seems
to suggest that the transscript hash protects this data, but it is
"protection" using the webpki or proof of lack of MITM, but the d= ata
does not need this protecting as it is protected by DNSSEC signatures.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 + the client remains responsible
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + for actually performing the domain name valid= ation of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + the DANE records.

Well, if it just fired up a previous TLS connection, perhaps it will be
content with the same pubkey used and skip re-validating this data? I
guess we sort of say the same thing due to the lack of a MUST ?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 + The Reserved field is reserved for future upd= ates to this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + document; in particular it is hoped that the = issues discussed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + in <xref target=3D"increasing-trust&q= uot; /> can be addressed.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + Implementations of this specification MUST se= nd a zero-length vector

Perhaps that last line can be clarified a bit:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Implementation not implementing any updates to = this document
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST send a zero-length vector

This sentence does not parse:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "whether or not to the exclusion"

This text is a little confusing to me:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 + certified by the DNS key hierarchy, that the<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 + server does not support DANE authentication
The TLS server itself might support "DANE authentication", but th= ere is
simply no data.=C2=A0 Perhaps say that the server's configured hostname= does
not support DANE authentication?

Thanks again for the write up!

Paul


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

--000000000000ed338b056f83d148-- From nobody Tue Jun 26 05:29:06 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95CB2130DDB for ; Tue, 26 Jun 2018 05:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 fDtcMV3rQEJg for ; Tue, 26 Jun 2018 05:29:02 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9EAF130DD6 for ; Tue, 26 Jun 2018 05:29:02 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D3574B80C41; Tue, 26 Jun 2018 05:28:58 -0700 (PDT) To: tim@dierks.org, ekr@rtfm.com, kaduk@mit.edu, ekr@rtfm.com, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: eugene.adell@gmail.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180626122858.D3574B80C41@rfc-editor.org> Date: Tue, 26 Jun 2018 05:28:58 -0700 (PDT) Archived-At: Subject: [TLS] [Technical Errata Reported] RFC5246 (5409) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2018 12:29:05 -0000 The following errata report has been submitted for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5409 -------------------------------------- Type: Technical Reported by: Eugene Adell Section: Appendix A.5 Original Text ------------- Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are reserved to avoid collision with Fortezza-based cipher suites in SSL 3. Corrected Text -------------- Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are reserved to avoid collision with Fortezza-based cipher suites in SSL 3. The cipher suite value { 0x00, 0x1E } firstly also assigned to Fortezza has been released and has since been be reassigned. Notes ----- RFC 2712 (Addition of Kerberos Cipher Suites to Transport Layer Security) in its Draft 01 version introduces three new cipher suites colliding with the three Fortezza ones. The Draft 02 version partially corrects that, by moving the Kerberos cipher suites values by two. This omission of the third cipher suite has never been corrected, and this remains in the same state in the final RFC 2712, RFC 2246 and its successors including this one. Changing the first Kerberos cipher suite value, or moving all of them, would now not make any sense. Enhancing the note as suggested is probably enough to mention how one Fortezza cipher suite disappeared. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5246 (draft-ietf-tls-rfc4346-bis-10) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.2 Publication Date : August 2008 Author(s) : T. Dierks, E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Jun 26 06:13:12 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE3B130DEA for ; Tue, 26 Jun 2018 06:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPIxBKV40d8z for ; Tue, 26 Jun 2018 06:13:04 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 C6286130DDC for ; Tue, 26 Jun 2018 06:13:03 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id r18-v6so4880646ual.13 for ; Tue, 26 Jun 2018 06:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=oIX/3p4kpmS//K+pIRAaAHQLhGOpnOP3VSNbYTErW4s=; b=RkUe3Rv+dSJLk9fiEHxLZmYH8KUzrIde8/FcJazUobxohZZtdXhwHpSbfG5N5rZbTz 0k9hrdEWhiraYr/vO6qXdu7dtrBqoMPx7sPY2qNHg8auF9JmWLkKh+BZkryyf+tcyO76 zfMb+ve3CVh1sNM8hhCYF+75WoP4docd56gl3tB4HOnI6XcgpVJJefgF4jI+mvmYbjHd C7eNFxmDs9N3OiQkivNB5ETMkvXq/P2V3MiKM1ARA0gXFgmv2BTc0ccZ2WQcsm+y274o +RXISBuVE41zB3DKqgb1RRnt1ZZPhCgnatIef4XFHYbJCP/dDtkNED4zz0VJ/42ynnDR NomA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=oIX/3p4kpmS//K+pIRAaAHQLhGOpnOP3VSNbYTErW4s=; b=YwbxXw9FblUGj7UaaxbXmRuZZJW/AWTIQRtbfKUxrjwTk2dHY3qsYGvkvmVcOnu9pJ c/oxuoYkx42vQNh84mkT014uX+g7fpUek/DNDnWTM0qw53anw8iUoxs3peIAVCpN9AFk vY8raX+ZUtjFYd7Id+26lkTKufO/wYELhdFjJDgj7sv39AHdN836dl0PBWRbq0g4GVM6 45hXxjI3WDAZerlyH6zSQKGkBsrTjcWJhvv/XvjZWgYmgRQ3txToHADekWU8UVHIfUO5 xsxMIxdafCuSrN7kPNNoTxDU8DYEJ3X/1sR7JQW51tKCaZsVg7olyllA8rmo5GF0dgIz iA1w== X-Gm-Message-State: APt69E0n5QPxlkiKAPHm8BHuucNbigOmlhdz1adjz4+2ubGq7enuEIzx BCmRAbYK8NHGMAtzGevDZZgo1+UmLej/Pf0tvDBylg== X-Google-Smtp-Source: AAOMgpcoffCzwOHCvaXcfTX+PgOqHgIZjUlCh96pfrV6By5wG8t3K3839p2bQP5LgN60Q/M4TGyEzhPZSr0s8SPUgCM= X-Received: by 2002:ab0:7024:: with SMTP id u4-v6mr914782ual.133.1530018782516; Tue, 26 Jun 2018 06:13:02 -0700 (PDT) MIME-Version: 1.0 References: <152993630059.6328.10244287867966594513.idtracker@ietfa.amsl.com> In-Reply-To: <152993630059.6328.10244287867966594513.idtracker@ietfa.amsl.com> From: Jonathan Hoyland Date: Tue, 26 Jun 2018 14:12:50 +0100 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000081bce056f8b429d" Archived-At: Subject: [TLS] Fwd: New Version Notification for draft-hoyland-tls-layered-exported-authenticator-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2018 13:13:11 -0000 --000000000000081bce056f8b429d Content-Type: text/plain; charset="UTF-8" Hi everyone, The draft below details an extension for Exported Authenticators (EAs) that allows multiple EAs sent in the same TLS session to be linked into an authentication chain using backward references. This gives a form of joint authentication between EAs. This means that not only does an EA provide authentication of the certificate it contains, an EA using this extension also authenticates all previous EAs in its chain. In short, if the last EA in the chain is authentic then all the EAs in that chain are authentic. (Or alternatively, if any EA in a chain is authentic, then all prior EAs are authentic.) This could be used for things like securely updating pinned keys. If this mechanism were in use it would require an attacker who was trying to maliciously update the pinned key to compromise both the pinned certificate's LTK and acquire an improperly issued certificate from the PKI. This would require compromising two separate administrative domains. Other use cases and a description of the mechanism appear in the draft. I'd really appreciate any feedback on the design, use cases, and the draft in general. Thanks, Jonathan Hoyland ---------- Forwarded message --------- From: Date: Mon, 25 Jun 2018 at 15:18 Subject: New Version Notification for draft-hoyland-tls-layered-exported-authenticator-00.txt To: Jonathan Hoyland A new version of I-D, draft-hoyland-tls-layered-exported-authenticator-00.txt has been successfully submitted by Jonathan Hoyland and posted to the IETF repository. Name: draft-hoyland-tls-layered-exported-authenticator Revision: 00 Title: Layered Exported Authenticators in TLS Document date: 2018-06-25 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-hoyland-tls-layered-exported-authenticator-00.txt Status: https://datatracker.ietf.org/doc/draft-hoyland-tls-layered-exported-authenticator/ Htmlized: https://tools.ietf.org/html/draft-hoyland-tls-layered-exported-authenticator-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-hoyland-tls-layered-exported-authenticator Abstract: This document describes an extension that allows for Exported Authenticators (EAs) to authenticate each other. The extension includes a reference to a previous EA. An EA containing this extension constitues an attestation of the authenticity of the referenced EA. 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 --000000000000081bce056f8b429d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

The draft below details an= extension for Exported Authenticators (EAs) that allows multiple EAs sent = in the same TLS session to be linked into an authentication chain using bac= kward references.=C2=A0
This gives a form of joint authentication= between EAs.=C2=A0

This means that not only does = an EA provide authentication of the certificate it contains, an EA using th= is extension also authenticates all previous EAs in its chain.
In= short, if the last EA in the chain is authentic then all the EAs in that c= hain are authentic. (Or alternatively, if any EA in a chain is authentic, t= hen all prior EAs are authentic.)

This could be us= ed for things like securely updating pinned keys.=C2=A0
If this m= echanism were in use it would require an attacker who was trying to malicio= usly update the pinned key to compromise both the pinned certificate's = LTK and acquire an improperly issued certificate from the PKI.=C2=A0
<= div>This would require compromising two separate administrative domains.=C2= =A0

Other use cases and a description of the mechanism appear in the= draft.=C2=A0

I'd really appreciate any feedba= ck on the design, use cases, and the draft in general.=C2=A0

=
Thanks,

Jonathan Hoyland

---------- Forwarded message ---------=
From: <internet-drafts@= ietf.org>
Date: Mon, 25 Jun 2018 at 15:18
Subject: New Version= Notification for draft-hoyland-tls-layered-exported-authenticator-00.txtTo: Jonathan Hoyland <jo= nathan.hoyland@gmail.com>



A new version of I-D, draft-hoyland-tls-layered-exported-authenticator-00.t= xt
has been successfully submitted by Jonathan Hoyland and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hoyland-tls-layered-exp= orted-authenticator
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Layered Exported Authenticators in= TLS
Document date:=C2=A0 2018-06-25
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/= draft-hoyland-tls-layered-exported-authenticator-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-hoyland-tls-l= ayered-exported-authenticator/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-hoyland-tls-layered-export= ed-authenticator-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-hoyland-t= ls-layered-exported-authenticator


Abstract:
=C2=A0 =C2=A0This document describes an extension that allows for Exported<= br> =C2=A0 =C2=A0Authenticators (EAs) to authenticate each other.=C2=A0 The ext= ension
=C2=A0 =C2=A0includes a reference to a previous EA.=C2=A0 An EA containing = this
=C2=A0 =C2=A0extension constitues an attestation of the authenticity of the=
=C2=A0 =C2=A0referenced EA.




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

--000000000000081bce056f8b429d-- From nobody Tue Jun 26 06:21:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC4A13102A for ; Tue, 26 Jun 2018 06:21: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndAhL5vMv_Kz for ; Tue, 26 Jun 2018 06:21:16 -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 EE70D130DDC for ; Tue, 26 Jun 2018 06:21:15 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id u62-v6so6914018qkf.9 for ; Tue, 26 Jun 2018 06:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7pOKbzDKedWawjUz8PoxA4xfxWZTl3OUumCLInIN4/U=; b=MfGVhrJAzlbQFQyLPMoG/z19Huq1JrBfZKn7U6PrLOK7e1ef3GSb6Ju7+OrWMfcSue 0LzTtBJWM/RNbqXOKcDyekXTdgs1EF1MEjCb2kajeyLds5VD/T2dM10jiOArRGOKg9Yo vYvQHy0RhM/+8uNylF2320u28M9H5XXWfpruo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7pOKbzDKedWawjUz8PoxA4xfxWZTl3OUumCLInIN4/U=; b=fUNOM0d2boGisSfUEh5aR1UqeT9w5EZrlxnJBpgtWCEd1Wa++utZmLgQoFimtFawHH x6ae18xddgK4o8d4lbSgO1DmcVjqX9GVawS2Yh9mDXqrv3gjSyqrSevd0guqhu7xoT6j WEV8Dt9Bw1bHhypIQ1fndGACEt2k3zyrD95CRGmHkfdi/CMyxsysz/Ts1bFc64Ij5Vmi SgTgqXMUXserdc+4NkGw3QAzBNORG7kk6+ke6PHJbg/vydwNUu6hQh7rJtDBDXTFrkNc Zv0RyRccRLFF/YMO2XBSJohBa416GmGa/xX6oYINrNKtI9FF1r3NOmL/D49fJsyInI6g 4nTQ== X-Gm-Message-State: APt69E3EIAzQIvar+5rpf4spzu5nWdP9QalWA2kvvyHz3Y9otOybIx1G f3110UqZCsFoDq6vZ2q4tFEo2Q== X-Google-Smtp-Source: AAOMgpfh85r7zXoVE+lj+yLENw5hed4mFwrfdlch5FJhCCSA9AHmGFAucAn/CFL5l7r3FQV+hqql1w== X-Received: by 2002:a37:4946:: with SMTP id w67-v6mr1292745qka.394.1530019275010; Tue, 26 Jun 2018 06:21:15 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.148]) by smtp.gmail.com with ESMTPSA id o10-v6sm1236362qkl.94.2018.06.26.06.21.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jun 2018 06:21:14 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Sean Turner In-Reply-To: <20180626122858.D3574B80C41@rfc-editor.org> Date: Tue, 26 Jun 2018 09:21:12 -0400 Cc: Tim Dierks , Eric Rescorla , Joe Salowey , eugene.adell@gmail.com, TLS WG Content-Transfer-Encoding: quoted-printable Message-Id: <45C8098C-A6D3-4E7B-BC3C-858C069D8B1D@sn3rd.com> References: <20180626122858.D3574B80C41@rfc-editor.org> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (5409) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2018 13:21:23 -0000 First, I think this is editorial. After all these years, I=E2=80=99m = not really sure it=E2=80=99s an interop problem. Second, if I were making this I would have placed the errata against = RFC2712 where the values were assigned. It=E2=80=99s not really = TLS1.2=E2=80=99s place to clear this up. spt > On Jun 26, 2018, at 08:28, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC5246, > "The Transport Layer Security (TLS) Protocol Version 1.2". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5409 >=20 > -------------------------------------- > Type: Technical > Reported by: Eugene Adell >=20 > Section: Appendix A.5 >=20 > Original Text > ------------- > Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are > reserved to avoid collision with Fortezza-based cipher suites in > SSL 3. >=20 > Corrected Text > -------------- > Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are > reserved to avoid collision with Fortezza-based cipher suites in > SSL 3. The cipher suite value { 0x00, 0x1E } firstly also assigned = to > Fortezza has been released and has since been be reassigned.=20 >=20 > Notes > ----- > RFC 2712 (Addition of Kerberos Cipher Suites to Transport Layer = Security) in its Draft 01 version introduces three new cipher suites = colliding with the three Fortezza ones. The Draft 02 version partially = corrects that, by moving the Kerberos cipher suites values by two. > This omission of the third cipher suite has never been corrected, and = this remains in the same state in the final RFC 2712, RFC 2246 and its = successors including this one. >=20 > Changing the first Kerberos cipher suite value, or moving all of them, = would now not make any sense. Enhancing the note as suggested is = probably enough to mention how one Fortezza cipher suite disappeared. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5246 (draft-ietf-tls-rfc4346-bis-10) > -------------------------------------- > Title : The Transport Layer Security (TLS) Protocol = Version 1.2 > Publication Date : August 2008 > Author(s) : T. Dierks, E. Rescorla > Category : PROPOSED STANDARD > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG From nobody Tue Jun 26 09:18:55 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF35A124D68 for ; Tue, 26 Jun 2018 09:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 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, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=2.599] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzWDRw_s1OKZ for ; Tue, 26 Jun 2018 09:18:53 -0700 (PDT) Received: from homiemail-a132.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15AC2131053 for ; Tue, 26 Jun 2018 09:18:53 -0700 (PDT) Received: from homiemail-a132.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a132.g.dreamhost.com (Postfix) with ESMTP id 7F1DA30002BA4; Tue, 26 Jun 2018 09:18:51 -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=H6KcYfWXe8iUxB XeNVQa582VQPA=; b=Qc7OBQL/u01CoGxEyjAP85YAq3PpxD1OyyCXjv114kvzAU hkWgJjB3q34iRXM3O3uEL+ORdEugslEJEMbsIbltOJZm3O9KT+kwffSNJj2QG8KQ 8gd8BNgzIUX9BWrqyjxUZOFiIz0LixpNqD4+AmKDsE8bV0+UgCQG8hgM9MYTM= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a132.g.dreamhost.com (Postfix) with ESMTPSA id 0E00F30002B9B; Tue, 26 Jun 2018 09:18:50 -0700 (PDT) Date: Tue, 26 Jun 2018 11:18:49 -0500 From: Nico Williams To: Joseph Salowey Cc: Paul Wouters , "" , Benjamin Kaduk Message-ID: <20180626161847.GA30804@localhost> References: <20180604203947.GW13834@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2018 16:18:54 -0000 On Mon, Jun 25, 2018 at 09:20:16PM -0700, Joseph Salowey wrote: > 1. Do you support the working group taking on future work on a pinning > mechanism (based on the modifications or another approach)? Yes with a caveat: I don't much care whether pinning work gets done as an individual submission, as a TLS WG work item, or some other WG's work item. > 2. Do you support the reserved bytes in the revision for a future pinning > mechanism? Yes. I prefer just the two bytes we asked for, but I'm also happy with the optional up-to-255-byte hole. I'm not at all interested in more complex holes. > 3. Do you support the proof of denial of existence text in the revision? Yes. > 4. Do you support the new and improved security considerations? Yes. Nico -- From nobody Tue Jun 26 20:30:32 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D98130F24 for ; Tue, 26 Jun 2018 20:30:30 -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 autolearn_force=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 LZ-F2kJZxbz1 for ; Tue, 26 Jun 2018 20:30:28 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 8DA92130E7A for ; Tue, 26 Jun 2018 20:30:28 -0700 (PDT) X-AuditID: 1209190c-219ff70000003fb4-34-5b3304d3828c Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 20.B4.16308.3D4033B5; Tue, 26 Jun 2018 23:30:27 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w5R3UP1c017900; Tue, 26 Jun 2018 23:30:26 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w5R3UKJo022366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Jun 2018 23:30:22 -0400 Date: Tue, 26 Jun 2018 22:30:20 -0500 From: Benjamin Kaduk To: =?iso-8859-1?Q?Eug=E8ne?= Adell Cc: Sean Turner , Tim Dierks , Eric Rescorla , Joe Salowey , TLS WG Message-ID: <20180627033020.GT79565@kduck.kaduk.org> References: <20180626122858.D3574B80C41@rfc-editor.org> <45C8098C-A6D3-4E7B-BC3C-858C069D8B1D@sn3rd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBKsWRmVeSWpSXmKPExsUixG6nrnuZxTjaYPZRYYsVr8+xW9w885fV Ytum/ewWV1Y1Mlv83jOP3eLT+S5GBzaPX2sWs3nsnHWX3WPJkp9MHpMftzF7HN+1gd3j4EHG ALYoLpuU1JzMstQifbsEroydO/cwFjxQrji07gpzA+Nu6S5GTg4JAROJ25+msXUxcnEICSxm kpiy6SwzhLORUeL3zt1QzlUmiWNLFjGDtLAIqEqsXLGREcRmE1CRaOi+DBYXEbCRePJ3M1gD s8BiRoljr/YzgSSEBcwlTm48DNbAC7Tv3865rHArTq2byAaREJQ4OfMJC4jNLKAu8WfeJaBJ HEC2tMTyfxwQYXmJ5q2zwZZxCgRK/N85BcwWFVCW2Nt3iH0Co+AsJJNmIZk0C2HSLCSTFjCy rGKUTcmt0s1NzMwpTk3WLU5OzMtLLdI11MvNLNFLTSndxAiKFE5Jnh2MZ954HWIU4GBU4uE1 cDKKFmJNLCuuzD3EKMnBpCTKu7IcKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE99hbw2gh3pTE yqrUonyYlDQHi5I4b/YixmghgfTEktTs1NSC1CKYrAwHh5IErywwIQgJFqWmp1akZeaUIKSZ ODhBhvMADWdnAqrhLS5IzC3OTIfIn2LU5fjzfuokZiGWvPy8VClx3o3MQEUCIEUZpXlwc0AJ TiJ7f80rRnGgt4R5d4FU8QCTI9ykV0BLmICWuLYbgSwpSURISTUwBr8SXeouNvdE/u1mg533 dnAdtdh4TOre3ohTnYnPDaawtivcPbP7pb+R0kWp1Vc/TlfxNOT8qrryWHfwq4+n9haxSr4O ejp749nblcXdN+d+8FxWeu1GRPqSXx+j6k84Ffb9cFH/eEjGdN5LnxMdj1X/nDhZf1yKVVDR v4Cn8MeUkKMC5mqnpiixFGckGmoxFxUnAgBLhcy5SwMAAA== Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (5409) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 27 Jun 2018 03:30:31 -0000 I don't really think this is a useful erratum against 5246; the note there is providing an explanation for why certain values are not used (and should not be used). But, now, and even at the time 5246 was published, 0x001e *is* used, and there's no reason to mention it in this context. One could perhaps argue that 2712 should have noted that a value was being reused (or have not reused the value at all), and an errata report against 2712 to add a new appendix section might be reasonable. So, absent additional considerations, I plan to reject this report. -Ben On Tue, Jun 26, 2018 at 04:01:35PM +0200, Eugène Adell wrote: > Hello, > > I had some doubts whether it was technical or editorial, and I have looked > at some accepted errata to choose (maybe not the best method) . I thought > it was technical, because one cipher suite was replaced by another one, and > the note already existing gives their numbers, which is a technical > information. > > Although the "mistake" first appears in RFC2712 draft 01, RFC2246 final > release was published before the final RFC2712. > RFC2246 is obsoleted but mentions Fortezza, which RFC2712 doesn't. RFC5246 > being the only non obsoleted child of RFC2246 mentionning the Fortezza > group, it looked more natural to suggest the errata at this place instead > of RFC2712 which is fully dedicated to Kerberos. > > > best regards > Eugène > > > > Le mar. 26 juin 2018 à 15:21, Sean Turner a écrit : > > > First, I think this is editorial. After all these years, I’m not really > > sure it’s an interop problem. > > > > Second, if I were making this I would have placed the errata against > > RFC2712 where the values were assigned. It’s not really TLS1.2’s place to > > clear this up. > > > > spt > > > > > On Jun 26, 2018, at 08:28, RFC Errata System > > wrote: > > > > > > The following errata report has been submitted for RFC5246, > > > "The Transport Layer Security (TLS) Protocol Version 1.2". > > > > > > -------------------------------------- > > > You may review the report below and at: > > > http://www.rfc-editor.org/errata/eid5409 > > > > > > -------------------------------------- > > > Type: Technical > > > Reported by: Eugene Adell > > > > > > Section: Appendix A.5 > > > > > > Original Text > > > ------------- > > > Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are > > > reserved to avoid collision with Fortezza-based cipher suites in > > > SSL 3. > > > > > > Corrected Text > > > -------------- > > > Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are > > > reserved to avoid collision with Fortezza-based cipher suites in > > > SSL 3. The cipher suite value { 0x00, 0x1E } firstly also assigned to > > > Fortezza has been released and has since been be reassigned. > > > > > > Notes > > > ----- > > > RFC 2712 (Addition of Kerberos Cipher Suites to Transport Layer > > Security) in its Draft 01 version introduces three new cipher suites > > colliding with the three Fortezza ones. The Draft 02 version partially > > corrects that, by moving the Kerberos cipher suites values by two. > > > This omission of the third cipher suite has never been corrected, and > > this remains in the same state in the final RFC 2712, RFC 2246 and its > > successors including this one. > > > > > > Changing the first Kerberos cipher suite value, or moving all of them, > > would now not make any sense. Enhancing the note as suggested is probably > > enough to mention how one Fortezza cipher suite disappeared. > > > > > > Instructions: > > > ------------- > > > This erratum is currently posted as "Reported". If necessary, please > > > use "Reply All" to discuss whether it should be verified or > > > rejected. When a decision is reached, the verifying party > > > can log in to change the status and edit the report, if necessary. > > > > > > -------------------------------------- > > > RFC5246 (draft-ietf-tls-rfc4346-bis-10) > > > -------------------------------------- > > > Title : The Transport Layer Security (TLS) Protocol > > Version 1.2 > > > Publication Date : August 2008 > > > Author(s) : T. Dierks, E. Rescorla > > > Category : PROPOSED STANDARD > > > Source : Transport Layer Security > > > Area : Security > > > Stream : IETF > > > Verifying Party : IESG > > > > From nobody Wed Jun 27 09:27:17 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1127D130E8C for ; Wed, 27 Jun 2018 09:27: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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obapm-F7cxbe for ; Wed, 27 Jun 2018 09:27:13 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 2E6D1130E99 for ; Wed, 27 Jun 2018 09:27:11 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41G7bZ4Vvrz5Bk; Wed, 27 Jun 2018 18:27:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1530116826; bh=NJNGyZjHLrNsXqedBNIArE1lRzncyNc7H+VxOLTWlus=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=QHVhfKOFqwB5ew89DOY1HBTVAoPpLRcGYggCQbnK7/Qlz7RLQpJV9yjMAhtURDxU9 qxeETPUiK8imiDjNsITXHLuY+/b4PeAA0gS2JmnUihGSAJuf+O+CiYBtlosnNh2NB+ N68XAAtwTkSvhTHA0RpOY1NY3opIQoJgnI6jT5OY= 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 Rm61Z0_WzDvW; Wed, 27 Jun 2018 18:27:05 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 27 Jun 2018 18:27:04 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8B0394FB768; Wed, 27 Jun 2018 12:27:03 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8B0394FB768 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 845174215A41; Wed, 27 Jun 2018 12:27:03 -0400 (EDT) Date: Wed, 27 Jun 2018 12:27:03 -0400 (EDT) From: Paul Wouters To: Joseph Salowey cc: Benjamin Kaduk , "" In-Reply-To: Message-ID: References: <20180604203947.GW13834@akamai.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 27 Jun 2018 16:27:16 -0000 On Mon, 25 Jun 2018, Joseph Salowey wrote: > There has been some discussion with a small group of folks on github - https://github.com/tlswg/dnssec-chain-extension/pull/19.  >  I want to make sure there is consensus in the working group to take on the pinning work and see if there is consensus for > modifications in the revision.  Please respond to the following questions on the list by July 10, 2018.  > > 1.  Do you support the working group taking on future work on a pinning mechanism (based on the modifications or another > approach)? Yes I support taking on the work to do the extension pinning. Just to ensure people are not confused, this is not about pinning of TLS(A) data. > 2.  Do you support the reserved bytes in the revision for a future pinning mechanism? Yes I support both this proposal of reserved bytes or the previous the two byte reservation. I have no strong preference. I do not support using a second TLS extension to pin the first, or the use of a TLS Extensions block, which is also basically two extensions interacting with each other. > 3.  Do you support the proof of denial of existence text in the revision? Yes I support this text, provided the error in the example.com example is fixed (it is using the wrong NSEC record, see Viktor's or my PR for the fix) > 4.  Do you support the new and improved security considerations?  Yes I support the changes. Do note that this part confuses me a little bit: but under the assumptions of this specification, there may not be a reliable way to obtain such DNS records. where "such" refers to Denial of Existence records. Since your change also has: + Following the TLSA or denial of existence RRset, + the subsequent RRsets MUST contain the full set of DNS records needed to authenticate the TLSA record set or denial of existence response via the server's trust anchor. I think the "there may not be a reliable way to obtain such DNS records." can be removed? Paul From nobody Wed Jun 27 09:56:20 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7767130E95 for ; Wed, 27 Jun 2018 09:56:16 -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 autolearn_force=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 UQTJ0Mak_8bh for ; Wed, 27 Jun 2018 09:56:14 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75B5130EA6 for ; Wed, 27 Jun 2018 09:56:14 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 7188B2963A0 for ; Wed, 27 Jun 2018 12:56:13 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 27 Jun 2018 12:56:12 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: TLS WG Message-Id: References: <20180604203947.GW13834@akamai.com> To: "" X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 27 Jun 2018 16:56:18 -0000 > On Jun 26, 2018, at 12:20 AM, Joseph Salowey wrote: >=20 > Hi Folks, >=20 > There has been some discussion with a small group of folks on github - = https://github.com/tlswg/dnssec-chain-extension/pull/19. I want to = make sure there is consensus in the working group to take on the pinning = work and see if there is consensus for modifications in the revision. = Please respond to the following questions on the list by July 10, 2018.=20= >=20 > 1. Do you support the working group taking on future work on a = pinning mechanism (based on the modifications or another approach)? Yes. > 2. Do you support the reserved bytes in the revision for a future = pinning mechanism? Yes, no strong feelings whether it is exactly 2 bytes or an = opaque<0..255> to be defined as part of 1. With either exactly 2 bytes, or an empty = opaque, the server signals that its operator does not (yet?) support unilateral client-side pinning. No to turning this into an extension block. > 3. Do you support the proof of denial of existence text in the = revision? Yes, with minor error corrections, where appropriate (perhaps after the next I-D revision, easier perhaps to read a complete snapshot than a pull request, and tools.ietf.org can also show diffs). > 4. Do you support the new and improved security considerations? Yes. We can word-smith any minor blemishes when the next I-D version comes out. --=20 Viktor. From eugene.adell@gmail.com Wed Jun 27 01:08:48 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBACB130F73 for ; Wed, 27 Jun 2018 01:08:48 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhNUG_Qev3P3 for ; Wed, 27 Jun 2018 01:08:45 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 26CCA130E8D for ; Wed, 27 Jun 2018 01:08:45 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id p1-v6so1020500wrs.9 for ; Wed, 27 Jun 2018 01:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W4dGMK00hQUhnIsPkAA2EZ1P/eeZa4ZM4600EnRcQjg=; b=NDjCI8reEmzRG/iexNADwz38RY2LaiOu1BPvbN7XYCqqj9mzIz6ptrhd5Lb9YvJTXB GFFacvQvYBun+vKCar4KOBYierpy/YFMlkRBTLowQC9TYrGfUts676u6I/XTiA9qN+Cg w8+YfWn3WF7LsqRZSl/NdQpDIg6PiRJQvaUGvFzZ3XikMctj1Bu82VXWNCcv6Jrhm51P flIhjW8JhI9shTnsU1BYTsfphedEcAoGwKl+FXyhxOCYZHIS/X2W9qrs5a4JxGFkAV1c w8bfI78lpKnquIRq8sUbGnob5l7if3lyxMqOpC3BaITBFd0h2KJ3mAmUZbfJxXSV2xh2 iqgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W4dGMK00hQUhnIsPkAA2EZ1P/eeZa4ZM4600EnRcQjg=; b=kJWBiWwmm5pLqWcZl/EN2WZ36v2oGQCHXEWChpeV4kZ16UF3xaK28ZMYh1rtrRc4QW GBObEvavQQtcqJZDRRe0A9AnwWZMO/k7oKAOuVEz+KQaUgwZpSHXoYQvKglaW5NaIj8L QDlLUCPD/MLdisXbFL2M2OAh9OeIUYCpQglqOu50ppWEWuOILLz+vEhJvi86ca8vYc+y 1BlMM4h6LqFHyWDHIRAd8Aq0AOlgsoF2Q8f4t5GdsvhYkSsqtJB6jcQfjYXbytfBY+bH qdQ/4Iok4YupuwXeGW8Be0RnGXc2WmOOrHHIYhxyci5s+j81MXO6GS6fvT9qBmrmalky ObLw== X-Gm-Message-State: APt69E1b40Zbf3XVUVhh/vT4aIzVWMKNwamJD/9iaEWjzJ7grbv6fkjB R+uiYgZFEFlmtULFQp0zLs/KZASWNr2sa24w+24= X-Google-Smtp-Source: AAOMgpdGW/t7k4Ni2RFkCTMP2uJQeP51h6JX+o3WS6NvIPtugNycvjHvttn6Cg4ippPvHy5PUaEoaHBH0kqTJ1oAPOk= X-Received: by 2002:adf:e881:: with SMTP id d1-v6mr968103wrm.43.1530086923659; Wed, 27 Jun 2018 01:08:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a5d:4711:0:0:0:0:0 with HTTP; Wed, 27 Jun 2018 01:08:43 -0700 (PDT) In-Reply-To: <20180627033020.GT79565@kduck.kaduk.org> References: <20180626122858.D3574B80C41@rfc-editor.org> <45C8098C-A6D3-4E7B-BC3C-858C069D8B1D@sn3rd.com> <20180627033020.GT79565@kduck.kaduk.org> From: =?UTF-8?Q?Eug=C3=A8ne_Adell?= Date: Wed, 27 Jun 2018 10:08:43 +0200 Message-ID: To: Benjamin Kaduk Cc: Sean Turner , Tim Dierks , Eric Rescorla , Joe Salowey , TLS WG Content-Type: multipart/alternative; boundary="0000000000008f6cba056f9b1ff6" Archived-At: X-Mailman-Approved-At: Fri, 29 Jun 2018 13:40:23 -0700 Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (5409) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 27 Jun 2018 15:15:26 -0000 --0000000000008f6cba056f9b1ff6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >From what you both are saying, it looks legitimate to document about this cipher which disappeared. But not here. As suggested I will post another editorial errata for RFC2712, in an appendix form. Eugene. 2018-06-27 5:30 GMT+02:00 Benjamin Kaduk : > I don't really think this is a useful erratum against 5246; the note ther= e > is providing an explanation for why certain values are not used (and shou= ld > not be used). But, now, and even at the time 5246 was published, 0x001e > *is* used, and there's no reason to mention it in this context. One coul= d > perhaps argue that 2712 should have noted that a value was being reused (= or > have not reused the value at all), and an errata report against 2712 to a= dd > a new appendix section might be reasonable. > > So, absent additional considerations, I plan to reject this report. > > -Ben > > On Tue, Jun 26, 2018 at 04:01:35PM +0200, Eug=C3=A8ne Adell wrote: > > Hello, > > > > I had some doubts whether it was technical or editorial, and I have > looked > > at some accepted errata to choose (maybe not the best method) . I thoug= ht > > it was technical, because one cipher suite was replaced by another one, > and > > the note already existing gives their numbers, which is a technical > > information. > > > > Although the "mistake" first appears in RFC2712 draft 01, RFC2246 final > > release was published before the final RFC2712. > > RFC2246 is obsoleted but mentions Fortezza, which RFC2712 doesn't. > RFC5246 > > being the only non obsoleted child of RFC2246 mentionning the Fortezza > > group, it looked more natural to suggest the errata at this place inste= ad > > of RFC2712 which is fully dedicated to Kerberos. > > > > > > best regards > > Eug=C3=A8ne > > > > > > > > Le mar. 26 juin 2018 =C3=A0 15:21, Sean Turner a =C3= =A9crit : > > > > > First, I think this is editorial. After all these years, I=E2=80=99m= not > really > > > sure it=E2=80=99s an interop problem. > > > > > > Second, if I were making this I would have placed the errata against > > > RFC2712 where the values were assigned. It=E2=80=99s not really TLS1= .2=E2=80=99s > place to > > > clear this up. > > > > > > spt > > > > > > > On Jun 26, 2018, at 08:28, RFC Errata System < > rfc-editor@rfc-editor.org> > > > wrote: > > > > > > > > The following errata report has been submitted for RFC5246, > > > > "The Transport Layer Security (TLS) Protocol Version 1.2". > > > > > > > > -------------------------------------- > > > > You may review the report below and at: > > > > http://www.rfc-editor.org/errata/eid5409 > > > > > > > > -------------------------------------- > > > > Type: Technical > > > > Reported by: Eugene Adell > > > > > > > > Section: Appendix A.5 > > > > > > > > Original Text > > > > ------------- > > > > Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } a= re > > > > reserved to avoid collision with Fortezza-based cipher suites in > > > > SSL 3. > > > > > > > > Corrected Text > > > > -------------- > > > > Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } a= re > > > > reserved to avoid collision with Fortezza-based cipher suites in > > > > SSL 3. The cipher suite value { 0x00, 0x1E } firstly also assigne= d > to > > > > Fortezza has been released and has since been be reassigned. > > > > > > > > Notes > > > > ----- > > > > RFC 2712 (Addition of Kerberos Cipher Suites to Transport Layer > > > Security) in its Draft 01 version introduces three new cipher suites > > > colliding with the three Fortezza ones. The Draft 02 version partiall= y > > > corrects that, by moving the Kerberos cipher suites values by two. > > > > This omission of the third cipher suite has never been corrected, a= nd > > > this remains in the same state in the final RFC 2712, RFC 2246 and it= s > > > successors including this one. > > > > > > > > Changing the first Kerberos cipher suite value, or moving all of > them, > > > would now not make any sense. Enhancing the note as suggested is > probably > > > enough to mention how one Fortezza cipher suite disappeared. > > > > > > > > Instructions: > > > > ------------- > > > > This erratum is currently posted as "Reported". If necessary, pleas= e > > > > use "Reply All" to discuss whether it should be verified or > > > > rejected. When a decision is reached, the verifying party > > > > can log in to change the status and edit the report, if necessary. > > > > > > > > -------------------------------------- > > > > RFC5246 (draft-ietf-tls-rfc4346-bis-10) > > > > -------------------------------------- > > > > Title : The Transport Layer Security (TLS) Protocol > > > Version 1.2 > > > > Publication Date : August 2008 > > > > Author(s) : T. Dierks, E. Rescorla > > > > Category : PROPOSED STANDARD > > > > Source : Transport Layer Security > > > > Area : Security > > > > Stream : IETF > > > > Verifying Party : IESG > > > > > > > --0000000000008f6cba056f9b1ff6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

From what you both are saying, it look= s legitimate to document about this cipher which disappeared. But not here.=
As suggested I will post another editorial errata for RFC271= 2, in an appendix form.

Eugene.

2018-06-27 5:30 = GMT+02:00 Benjamin Kaduk <kaduk@mit.edu>:
I don't really think this is a useful erratum against 524= 6; the note there
is providing an explanation for why certain values are not used (and should=
not be used).=C2=A0 But, now, and even at the time 5246 was published, 0x00= 1e
*is* used, and there's no reason to mention it in this context.=C2=A0 O= ne could
perhaps argue that 2712 should have noted that a value was being reused (or=
have not reused the value at all), and an errata report against 2712 to add=
a new appendix section might be reasonable.

So, absent additional considerations, I plan to reject this report.

-Ben

On Tue, Jun 26, 2018 at 04:01:35PM +0200, Eug=C3=A8ne Adell wrote:
> Hello,
>
> I had some doubts whether it was technical or editorial, and I have lo= oked
> at some accepted errata to choose (maybe not the best method) . I thou= ght
> it was technical, because one cipher suite was replaced by another one= , and
> the note already existing gives their numbers, which is a technical > information.
>
> Although the "mistake" first appears in RFC2712 draft 01, RF= C2246 final
> release was published before the final RFC2712.
> RFC2246 is obsoleted but mentions Fortezza, which RFC2712 doesn't.= RFC5246
> being the only non obsoleted child of RFC2246 mentionning the Fortezza=
> group, it looked more natural to suggest the errata at this place inst= ead
> of RFC2712 which is fully dedicated to Kerberos.
>
>
> best regards
> Eug=C3=A8ne
>
>
>
> Le mar. 26 juin 2018 =C3=A0 15:21, Sean Turner <sean@sn3rd.com> a =C3=A9crit :
>
> > First, I think this is editorial.=C2=A0 After all these years, I= =E2=80=99m not really
> > sure it=E2=80=99s an interop problem.
> >
> > Second, if I were making this I would have placed the errata agai= nst
> > RFC2712 where the values were assigned.=C2=A0 It=E2=80=99s not re= ally TLS1.2=E2=80=99s place to
> > clear this up.
> >
> > spt
> >
> > > On Jun 26, 2018, at 08:28, RFC Errata System <rfc-editor@rfc-editor.org>
> > wrote:
> > >
> > > The following errata report has been submitted for RFC5246,<= br> > > > "The Transport Layer Security (TLS) Protocol Version 1.= 2".
> > >
> > > --------------------------------------
> > > You may review the report below and at:
> > > http://www.rfc-editor.org/errata/eid5409=
> > >
> > > --------------------------------------
> > > Type: Technical
> > > Reported by: Eugene Adell <eugene.adell@gmail.com>
> > >
> > > Section: Appendix A.5
> > >
> > > Original Text
> > > -------------
> > >=C2=A0 =C2=A0Note: The cipher suite values { 0x00, 0x1C } and= { 0x00, 0x1D } are
> > >=C2=A0 =C2=A0reserved to avoid collision with Fortezza-based = cipher suites in
> > >=C2=A0 =C2=A0SSL 3.
> > >
> > > Corrected Text
> > > --------------
> > >=C2=A0 =C2=A0Note: The cipher suite values { 0x00, 0x1C } and= { 0x00, 0x1D } are
> > >=C2=A0 =C2=A0reserved to avoid collision with Fortezza-based = cipher suites in
> > >=C2=A0 =C2=A0SSL 3. The cipher suite value { 0x00, 0x1E } fir= stly also assigned to
> > >=C2=A0 =C2=A0Fortezza has been released and has since been be= reassigned.
> > >
> > > Notes
> > > -----
> > > RFC 2712 (Addition of Kerberos Cipher Suites to Transport La= yer
> > Security) in its Draft 01 version introduces three new cipher sui= tes
> > colliding with the three Fortezza ones. The Draft 02 version part= ially
> > corrects that, by moving the Kerberos cipher suites values by two= .
> > > This omission of the third cipher suite has never been corre= cted, and
> > this remains in the same state in the final RFC 2712, RFC 2246 an= d its
> > successors including this one.
> > >
> > > Changing the first Kerberos cipher suite value, or moving al= l of them,
> > would now not make any sense. Enhancing the note as suggested is = probably
> > enough to mention how one Fortezza cipher suite disappeared.
> > >
> > > Instructions:
> > > -------------
> > > This erratum is currently posted as "Reported". If= necessary, please
> > > use "Reply All" to discuss whether it should be ve= rified or
> > > rejected. When a decision is reached, the verifying party > > > can log in to change the status and edit the report, if nece= ssary.
> > >
> > > --------------------------------------
> > > RFC5246 (draft-ietf-tls-rfc4346-bis-10)
> > > --------------------------------------
> > > Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : The Transport Layer Security (TLS) Protocol
> > Version 1.2
> > > Publication Date=C2=A0 =C2=A0 : August 2008
> > > Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: T. Dierk= s, E. Rescorla
> > > Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED= STANDARD
> > > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Tra= nsport Layer Security
> > > Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = : Security
> > > Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IET= F
> > > Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
> >
> >

--0000000000008f6cba056f9b1ff6--