From nobody Tue Jul 1 01:36:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BAA1A005E for ; Tue, 1 Jul 2014 01:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.746 X-Spam-Level: X-Spam-Status: No, score=-0.746 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, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueM4hzgiV9Me for ; Tue, 1 Jul 2014 01:36:51 -0700 (PDT) Received: from smtp-01-out.s.azet.sk (smtp-06-out.s.azet.sk [91.235.53.31]) by ietfa.amsl.com (Postfix) with ESMTP id A73F71A001D for ; Tue, 1 Jul 2014 01:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=azet.sk; s=azet; t=1404203808; bh=fB1NMV4vm7YTYvVI8oynwzgfSFEUvLx7TKfnx3Bvceo=; h=Date:From:To:Subject:References:In-Reply-To:From; b=hTn1tbBKG28L0KllRGUEXqEiz9whg3amuHdthMwE0pumwaVyffisFpRZ3f3fW9AxB KQ70DL1UThMZj5TYX/gC16ARkis7BBT+QkWUMGvzlM3kOAMkWUGoI5JTM8lbnp/3Iy opR6zSWiFP7F06H4fjl7/pSPUyeOAmFnadt273kI= X-Virus-Scanned: by AntiSpam at azet.sk Received: from [0.0.0.0] (unknown [77.109.139.87]) (Authenticated sender: fedor.brunner@azet.sk) by smtp.azet.sk (Postfix) with ESMTPA id 69AA47D for ; Tue, 1 Jul 2014 10:36:40 +0200 (CEST) X-SenderID: Sendmail Sender-ID Filter v1.0.0 smtp.azet.sk 69AA47D Authentication-Results: smtp.azet.sk; sender-id=fail (NotPermitted) header.from=fedor.brunner@azet.sk; auth=pass (PLAIN); spf=fail (NotPermitted) smtp.mfrom=fedor.brunner@azet.sk Message-ID: <53B27315.4010407@azet.sk> Date: Tue, 01 Jul 2014 10:36:37 +0200 From: Fedor Brunner MIME-Version: 1.0 To: tls@ietf.org References: <53B1B77C.2060201@cs.bris.ac.uk> <53B1D49D.10404@nthpermutation.com> In-Reply-To: <53B1D49D.10404@nthpermutation.com> X-Enigmail-Version: 1.6+git0.20140323 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/np9bkiNh5Kr6t2cql04QohljvbI Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jul 2014 08:36:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 30.06.2014 23:20, Michael StJohns wrote: > On 6/30/2014 3:16 PM, Nigel Smart wrote: >> What's the difference between defining a cryptographic protocol >> (i.e. TLS 1.3) which could have lots of problems/be cracked/have >> a back door; and defining a cryptographic algorithm which could >> have lots of problems/be cracked/have a back door? Experience >> shows us that defining cryptographic protocols (key >> agreement/secure channels) is more prone to problems than >> defining cryptographic primtives (AES, ECC). > > If the math is insecure then the cryptographic standard is insecure > as is everything that depends on it. > Because some algorithms have been published as cryptographic standard doesn't mean the algorithm is without a backdoor. For example: 1. ANSI X3.92, NIST SP 800-67 and ISO/IEC 18033-3, DES cipher The key was shortened to 56-bit https://web.archive.org/web/20140423082937/http://cryptome.org/0001/nsa-meyer.htm 2. ANSI X9.82 NIST SP 800-90A, ISO/IEC 18031:2005, Dual_EC_DRBG https://projectbullrun.org/dual-ec/vulnerability.html https://eprint.iacr.org/2006/117 D.J.Bernstein writes: In the past decade NIST has been rushing so many cryptographic standards out the door that the quality of review has obviously been compromised. http://blog.cr.yp.to/20140411-nist.html Because of possible backdoors some companies are moving away from NIST cryptographic standards https://blog.silentcircle.com/nncs/ Also Adam Langley thinks that NIST continually pick algorithms that aren't suited to software implementations. https://www.imperialviolet.org/2012/10/21/nist.html > If the cryptographic standard is insecure then the cryptographic > protocols are insecure (but hopefully you can plug in something > else - e.g. DES vs AES). > > If the cryptographic protocol is insecure then the applications > are insecure (but hopefully you can plug in something else e.g. > TLS1.0 vs TLS1.1 vs TLS1.2 vs ??). > > Oh yeah - if the implementation is insecure, it doesn't really > matter whether or not you got everything else right. > > So the difference is really about what depends on the protocol vs > the standard vs the math, and you get more dependencies the closer > you are to the math. > > I tend to agree with you about the problems with defining crypto > protocols, but at least they are*protocols* which is somewhat > within the IETF's scope of expertise. They're also a lot easier > for the non-crypto-math people to get their heads around. Crafting > a cryptographic protocol is still a specialty expertise though. At > least TLS13 will have *lots* of eyes on it. Given the huge set of > plugin cryptography in TLS, hopefully at least some of it will be > secure enough. > > Mike > > > > _______________________________________________ TLS mailing list > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJTsnMVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4QkVFQ0NBRDcyNzU1RTk2RTQwMzlEQjc2 RTE3NDA5NTQwNTY2M0FEAAoJEG4XQJVAVmOtXMIQAKD9hmWHVflit4tAukqaJ9tz FHUoTAThAwnf1DxjkacVfddiX7Q42DUAsPruadc1xmdiux35foz9oGFLo1rVqLNZ XFCvoMzkLK9IvXyf/RiE4vtfXBQSx+bgKLQlRa/TlkC5vqC0U8NMgiSqT41M6xd3 u5ar2O0S9VrEFLXzxPwIQEphn9x+ixu2gJAsu0c7EWshpY1M0a8acSSxk1AQqRJm KmN+TIYMsOpnJShTmulB5EoHoszEzH1bfzFl5wcK15RFPEhsWf2Bps0q+V1E5mX3 RWIyT2Xctbj6ISMcpbd7sAh3eC9Sdf8pmDzhBd5qvwzMPip+tkIbQsH0BZYdfvCb PaXj3LqeXIpQVMYDdjIR9M77AmREkw0JucZXBpeY4ncOYESu/JvgiOwJW1cmhgaq DsSJFBDBsTB6yPpCfrOHaIB0hKZ81qBAAJihE15E3pBTI9FDExnOYMXCUHtjJIfH qNLLmHcjAjceTcUSrwzdOoHfVO0mWRqd8tmuGaQNiK1o4AmThzXM5HuPoRZwZJqN a63tvtaNl2DQGjBhk+26YhsrzzOLo4QZpDay6+3mUSvXEKcp2497Ng9lRztjsVh6 ZJbPGn8SKCTg166xrH2FQdfJ0Ay4BVDWZavPPxVIFA2HAiqf8WpieuaicuaRf5df wERmz00efrw6ar4+9rMp =Rmfy -----END PGP SIGNATURE----- From nobody Tue Jul 1 07:36:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5412E1B2805 for ; Tue, 1 Jul 2014 07:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frU70KqCcWd4 for ; Tue, 1 Jul 2014 07:36:13 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 000181B2804 for ; Tue, 1 Jul 2014 07:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1404225373; x=1435761373; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=bYCZJCrVEaUXTAhxUB+04v4R5pS/0MGQARyw7r6smqc=; b=tT/2ozGewPuU/usStuGqkcxh1JY4UtXuAcLgrdShQVWG/Le7FEaus1to bvEFwpNlr1EBusznOGv8MF6uMfLEPKv9vKZu4nliq/Bo704eut6RY8hr7 R8QcNWEu1nCc23T24A9iLq6bpAP3v3FdX0oe4uH5BRPSufrsVaJwZQJg/ E=; X-IronPort-AV: E=Sophos;i="5.01,581,1399982400"; d="scan'208";a="261455026" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 02 Jul 2014 02:36:08 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.9]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Wed, 2 Jul 2014 02:36:08 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, Thread-Index: Ac+VOctlducJCFxkRkONHcPFxq3oJQ== Date: Tue, 1 Jul 2014 14:36:07 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738DED183A@uxcn10-tdc06.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EHQOBNKNOyOk_PwHy73JRSq_4CE Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Jul 2014 14:36:17 -0000 Fedor Brunner writes:=0A= =0A= >Also Adam Langley thinks that NIST continually pick algorithms that aren't= =0A= >suited to software implementations.=0A= >https://www.imperialviolet.org/2012/10/21/nist.html=0A= =0A= Another problem with the NIST standards is that, once you go beyond basics= =0A= like AES, SHA-2, and so on, you have a neverending stream of oddball modes = and=0A= mechanisms that no standard protocol ever uses, or arguably needs. However= =0A= since it's specified by NIST, standards groups, who are often heavily stack= ed=0A= with US contributors, feel the need to force them into all manner of standa= rds=0A= because they feel they need USG approval for them. =0A= =0A= This applies particularly to things like TLS, less so for protocols like SS= H=0A= (if I had a penny for every time I've heard "we can't do because there's no NIST-approved way to do it" or "w= e=0A= need to do because that's what the NIST standa= rd=0A= says"...). In other words while the SSH effort is driven by purely technic= al=0A= considerations, things like TLS are driven by a combination of technical=0A= considerations and "what NIST has standardised so we can get it FIPS certif= ied=0A= for our USG customers".=0A= =0A= This dual technical+political approach is not a good way to design a standa= rd.=0A= =0A= Peter.= From nobody Tue Jul 1 11:08:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56EE1B2871 for ; Tue, 1 Jul 2014 11:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-81n8TlvcCs for ; Tue, 1 Jul 2014 11:07:52 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E2161B2864 for ; Tue, 1 Jul 2014 11:07:32 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id a108so3591148qge.18 for ; Tue, 01 Jul 2014 11:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=vhBJLZsDLRhk9x9aPPFP6P42ibma292zxS2PcNRIBMY=; b=aEUHgWs9zyNY61GdkU4VxZCb/zrf1RV3rujIA5YLmwqb5kCcSI5yUj+MwL1lpombYV 03SNIAV3lpTPDSekAlRTnSePP8Q/BE6NLa3j9E64YnvVLOXGRG4CV0rrExj/iOUcrJvo ofWQnxnH7GIAPp/ABMGR3kl2L9vbhS0peSd8a+7Lv8aBWS/NxFEE7JMTpVvKVhduzvbQ QElIxmB4KTLqP2jdlT2bniwRKYNxu1kKbcldiIlOWFTsA9StwWoUzEKZSEt9z65UJ22D 24LEC4jgKdMhJ+onBxsYtN7r+/QdimCG6cEHgROEG/7VLhe8rdan16qSbKzmjii/tc1o jrKQ== MIME-Version: 1.0 X-Received: by 10.140.108.99 with SMTP id i90mr59068807qgf.56.1404238051636; Tue, 01 Jul 2014 11:07:31 -0700 (PDT) Received: by 10.140.27.173 with HTTP; Tue, 1 Jul 2014 11:07:31 -0700 (PDT) Received: by 10.140.27.173 with HTTP; Tue, 1 Jul 2014 11:07:31 -0700 (PDT) In-Reply-To: References: <20140701061655.10456.83525.idtracker@ietfa.amsl.com> <85fa7c63d21043fdb438d959479f56a4@BL2PR03MB482.namprd03.prod.outlook.com> Date: Tue, 1 Jul 2014 11:07:31 -0700 Message-ID: From: Watson Ladd To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a11390c9c3f7c2304fd25a61b Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xIyp0KzdV5D4-8cLJD3axhA4nzw Subject: Re: [TLS] [Cfrg] FW: New Version Notification for draft-black-numscurves-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 18:08:03 -0000 --001a11390c9c3f7c2304fd25a61b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Jul 1, 2014 10:13 AM, "Brian LaMacchia" wrote: > > Dear CFRG members, > > I would like to draw your attention to the Internet-Draft draft-black-numscurves-00.txt, https://datatracker.ietf.org/doc/draft-black-numscurves/, which has just been submitted by Ben Black and the co-authors of [1]. This I-D contains the specification for the NUMS curves that Patrick Longa presented at the CFRG Spring 2014 Interim Meeting and which are implemented in the just-released Microsoft Research ECCLib (see my message at http://www.ietf.org/mail-archive/web/cfrg/current/msg04602.html for that announcement). For the reasons described both in the paper and the presentation at the Interim Meeting, I believe that it would be best for the CFRG to standardize a family of both Weierstrass and twisted Edwards curves generated through publicly verifiable means in order to meet the broad needs of the IETF. > > With the submission of this I-D and the release of MSR's open source implementation, I believe the feedback received at the Interim Meeting concerning the proposed NUMS curves has been successfully addressed and I encourage the CFRG to have a more detailed and thoughtful discussion of the various curve candidates that have been proposed. The needs of the entire IETF in this space, starting with the TLS WG, seem like a very ripe topic for discussion at IETF-90 in Toronto. Is there any technical difference between 19 and 189 other then a slight change in square root calculations? > > --bal > > [1] Joppe W. Bos, Craig Costello, Patrick Longa and Michael Naehrig, =E2=80=9CSelecting Elliptic Curves for Cryptography: An Efficiency and Secu= rity Analysis=E2=80=9D, Cryptology ePrint Archive: Report 2014/130. Available at= : http://eprint.iacr.org/2014/130 > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, June 30, 2014 11:17 PM > To: Joppe W.Bos; Craig Costello; Benjamin Black; Craig Costello; Joppe W. Bos; Patrick Longa Pierola; Michael Naehrig; Patrick Longa Pierola; Benjamin Black; Michael Naehrig > Subject: New Version Notification for draft-black-numscurves-00.txt > > > A new version of I-D, draft-black-numscurves-00.txt has been successfully submitted by Benjamin Black and posted to the IETF repository. > > Name: draft-black-numscurves > Revision: 00 > Title: Elliptic Curve Cryptography (ECC) Nothing Up My Sleeve (NUMS) Curves and Curve Generation > Document date: 2014-06-30 > Group: Individual Submission > Pages: 13 > URL: http://www.ietf.org/internet-drafts/draft-black-numscurves-00.txt > Status: https://datatracker.ietf.org/doc/draft-black-numscurves/ > Htmlized: http://tools.ietf.org/html/draft-black-numscurves-00 > > > Abstract: > This memo describes a family of deterministically generated Nothing > Up My Sleeve (NUMS) elliptic curves over prime fields offering high > practical security in cryptographic applications, including Transport > Layer Security (TLS) and X.509 certificates. The domain parameters > are defined for both classical Weierstrass curves, for compatibility > with existing applications, and modern twisted Edwards curves, > allowing further efficiency improvements for a given security level. > > > > > 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 > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --001a11390c9c3f7c2304fd25a61b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jul 1, 2014 10:13 AM, "Brian LaMacchia" <bal@microsoft.com> wrote:
>
> Dear CFRG members,
>
> I would like to draw your attention to the Internet-Draft draft-black-= numscurves-00.txt, https://datatracker.ietf.org/doc/draft-black-numscurves/, = which has just been submitted by Ben Black and the co-authors of [1]. =C2= =A0This I-D contains the specification for the NUMS curves that Patrick Lon= ga presented at the CFRG Spring 2014 Interim Meeting and which are implemen= ted in the just-released Microsoft Research ECCLib =C2=A0(see my message at= http://www.ietf.org/mail-archive/web/cfrg/current/msg04602.html for t= hat announcement). =C2=A0 For the reasons described both in the paper and t= he presentation at the Interim Meeting, I believe that it would be best for= the CFRG to standardize a family of both Weierstrass and twisted Edwards c= urves generated through publicly verifiable means in order to meet the broa= d needs of the IETF.
>
> With the submission of this I-D and the release of MSR's open sour= ce implementation, I believe the feedback received at the Interim Meeting c= oncerning the proposed NUMS curves has been successfully addressed and I en= courage the CFRG to have a more detailed and thoughtful discussion of the v= arious curve candidates that have been proposed. =C2=A0 The needs of the en= tire IETF in this space, starting with the TLS WG, seem like a very ripe to= pic for discussion at IETF-90 in Toronto.

Is there any technical difference between 19 and 189 other t= hen a slight change in square root calculations?

>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --bal=
>
> [1] Joppe W. Bos, Craig Costello, Patrick Longa and Michael Naehrig, = =E2=80=9CSelecting Elliptic Curves for Cryptography: An Efficiency and Secu= rity Analysis=E2=80=9D, Cryptology ePrint Archive: Report 2014/130. Availab= le at: http://eprint.iacr.org/2= 014/130
>
>
> -----Original Message-----
> From: internet-drafts@ietf= .org [mailto:internet-draft= s@ietf.org]
> Sent: Monday, June 30, 2014 11:17 PM
> To: Joppe W.Bos; Craig Costello; Benjamin Black; Craig Costello; Joppe= W. Bos; Patrick Longa Pierola; Michael Naehrig; Patrick Longa Pierola; Ben= jamin Black; Michael Naehrig
> Subject: New Version Notification for draft-black-numscurves-00.txt >
>
> A new version of I-D, draft-black-numscurves-00.txt has been successfu= lly submitted by Benjamin Black and posted to the IETF repository.
>
> Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-black-numscurves
> Revision: =C2=A0 =C2=A0 =C2=A0 00
> Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Elliptic Curve Cryptography (= ECC) Nothing Up My Sleeve (NUMS) Curves and Curve Generation
> Document date: =C2=A02014-06-30
> Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
> Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A013
> URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ietf.org/i= nternet-drafts/draft-black-numscurves-00.txt
> Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.org/doc/draft-b= lack-numscurves/
> Htmlized: =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/html/draft-black-numscurves= -00
>
>
> Abstract:
> =C2=A0 =C2=A0This memo describes a family of deterministically generat= ed Nothing
> =C2=A0 =C2=A0Up My Sleeve (NUMS) elliptic curves over prime fields off= ering high
> =C2=A0 =C2=A0practical security in cryptographic applications, includi= ng Transport
> =C2=A0 =C2=A0Layer Security (TLS) and X.509 certificates. =C2=A0The do= main parameters
> =C2=A0 =C2=A0are defined for both classical Weierstrass curves, for co= mpatibility
> =C2=A0 =C2=A0with existing applications, and modern twisted Edwards cu= rves,
> =C2=A0 =C2=A0allowing further efficiency improvements for a given secu= rity level.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.= org/mailman/listinfo/cfrg

--001a11390c9c3f7c2304fd25a61b-- From nobody Tue Jul 1 12:51:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6561B27FB for ; Tue, 1 Jul 2014 12:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.133 X-Spam-Level: * X-Spam-Status: No, score=1.133 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0dbX0egu3dv for ; Tue, 1 Jul 2014 12:51:22 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.150.11]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AF0B1A05E5 for ; Tue, 1 Jul 2014 12:51:22 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id A619C8699291C; Tue, 1 Jul 2014 14:51:21 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 6B2FD8698DA68 for ; Tue, 1 Jul 2014 14:50:59 -0500 (CDT) Received: from [173.73.128.252] (port=50970 helo=[192.168.1.10]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X244w-0006tk-Mz for tls@ietf.org; Tue, 01 Jul 2014 14:50:58 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <53E5AD5C-05C9-4C23-92CB-D119D02D49E8@ieca.com> Date: Tue, 1 Jul 2014 15:50:55 -0400 To: "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 173.73.128.252 X-Exim-ID: 1X244w-0006tk-Mz X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.10]) [173.73.128.252]:50970 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IAoRFK2c1k1eoN_RBzAY1FQwO-M Subject: [TLS] adopting draft-bmoeller-tls-downgrade-scsv X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 19:51:23 -0000 At the London meeting the chairs took an action item to consult with our = AD about either adopting draft-moeller-tls-downgrade-scsv or changing = the charter to explicitly allow adoption. Stephen has indicated that we = can adopt the draft without modifications to the charter. Therefore, = we=92d like Bodo to submit the draft as a WG draft and we=92ll initiate = a WGLC shortly thereafter. spt {for the chairs}= From nobody Tue Jul 1 13:37:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418201A03EB; Tue, 1 Jul 2014 13:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5agYVb_6dx7; Tue, 1 Jul 2014 13:37:40 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C5A1A03AE; Tue, 1 Jul 2014 13:37:40 -0700 (PDT) Received: from BL2PR03MB242.namprd03.prod.outlook.com (10.255.231.18) by BL2PR03MB242.namprd03.prod.outlook.com (10.255.231.18) with Microsoft SMTP Server (TLS) id 15.0.980.8; Tue, 1 Jul 2014 20:37:38 +0000 Received: from BL2PR03MB242.namprd03.prod.outlook.com ([169.254.8.229]) by BL2PR03MB242.namprd03.prod.outlook.com ([169.254.8.229]) with mapi id 15.00.0980.000; Tue, 1 Jul 2014 20:37:38 +0000 From: Brian LaMacchia To: Watson Ladd , "tls@ietf.org" Thread-Topic: [TLS] [Cfrg] FW: New Version Notification for draft-black-numscurves-00.txt Thread-Index: AQHPlPQS8iucwSAq3kaIp2YBJZ3TZ5uLaySggAAANrCAABlkgIAAKERQ Date: Tue, 1 Jul 2014 20:37:37 +0000 Message-ID: References: <20140701061655.10456.83525.idtracker@ietfa.amsl.com> <85fa7c63d21043fdb438d959479f56a4@BL2PR03MB482.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02596AB7DA x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(51704005)(199002)(189002)(83322001)(81342001)(19580395003)(19580405001)(77096002)(2656002)(105586002)(87936001)(95666004)(99286002)(76576001)(81542001)(85306003)(4396001)(93886003)(74316001)(85852003)(83072002)(106356001)(54356999)(64706001)(77982001)(76176999)(50986999)(79102001)(80022001)(106116001)(86612001)(76482001)(86362001)(92566001)(33646001)(20776003)(101416001)(107046002)(99396002)(31966008)(74662001)(21056001)(74502001)(46102001)(108616002)(42262001)(3826002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB242; H:BL2PR03MB242.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/d3QTjqrrL4G6gznzdQkzJHtlNA8 Cc: "cfrg@ietf.org" Subject: Re: [TLS] [Cfrg] FW: New Version Notification for draft-black-numscurves-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 20:37:42 -0000 PkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgV2F0 c29uIExhZGQNCj5TZW50OiBUdWVzZGF5LCBKdWx5IDAxLCAyMDE0IDExOjA4IEFNDQo+VG86IHRs c0BpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbVExTXSBbQ2ZyZ10gRlc6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtYmxhY2stbnVtc2N1cnZlcy0wMC50eHQNCj4NCj5JcyB0aGVy ZSBhbnkgdGVjaG5pY2FsIGRpZmZlcmVuY2UgYmV0d2VlbiAxOSBhbmQgMTg5IG90aGVyIHRoZW4g YSBzbGlnaHQgY2hhbmdlIGluIHNxdWFyZSByb290IGNhbGN1bGF0aW9ucz8gDQoNClllcywgdGhl cmUgaXMuICBGb3IgdGhlIE5VTVMgY3VydmUsIGZvciBlYWNoIHNlY3VyaXR5IGxldmVsIHdlDQpz dGFydGVkIHdpdGggdGhlIGxhcmdlc3QgcHJpbWUgc21hbGxlciB0aGFuIDJeKHNlY3VyaXR5IGxl dmVsKQ0KY29uZ3J1ZW50IHRvIDMgbW9kIDQsIHdoaWNoIGlzIHdoeSB3ZSB1c2UgcCA9IDJeMjU2 IC0gMTg5LiAgQXMNCnlvdSBwb2ludCBvdXQsIGNob29zaW5nIGEgcHJpbWUgY29uZ3J1ZW50IHRv IDMgbW9kIDQgc2ltcGxpZmllcw0KdGhlIHNxdWFyZSByb290IGNhbGN1bGF0aW9ucywgYnV0IGl0 IGFsc28gbWVhbnMgdGhhdCBmb3IgdGhlDQp0d2lzdGVkIEVkd2FyZHMgY3VydmVzIHdlIGNhbiBm aW5kIG9wdGltYWwgY29mYWN0b3JzIG9mICg0LDQpIGZvcg0KdGhlIGN1cnZlIGFuZCBpdHMgdHdp c3QuICBXZSBkbyBub3QgZXhwZWN0IHRvIHNlZSBzaWduaWZpY2FudA0KcGVyZm9ybWFuY2UgZGlm ZmVyZW5jZXMgYmV0d2VlbiBtb2R1bGFyIG9wZXJhdGlvbnMgaW1wbGVtZW50ZWQNCndpdGggcCA9 IDJeMjU2IC0xODkgYW5kIHAgPSAyXjI1NSAtIDE5ICh0aGUgcHJpbWUgZm9yDQpDdXJ2ZTI1NTE5 KS4NCiANCkFuIGFkdmFudGFnZSBvZiB0aGUgTlVNUyBjb25zdHJ1Y3Rpb24gYXBwcm9hY2ggaXMg dGhhdCB3ZSBhcmUNCmFibGUgdG8gZGV0ZXJtaW5pc3RpY2FsbHkgY2hvb3NlIGJvdGggYSBzaG9y dCBXZWllcnN0cmFzcyBhbmQgYQ0KdHdpc3RlZCBFZHdhcmRzIGN1cnZlIG92ZXIgdGhlIHNhbWUg cHJpbWUgZm9yIHRoZSBzYW1lIHNlY3VyaXR5DQpsZXZlbC4gIEl0IHNlZW1zIHRvIG1lIHRoYXQg b25lIG9mIHRoZSBxdWVzdGlvbnMgdGhlIENGUkcgbmVlZHMNCnRvIGNvbnNpZGVyIGlzIHRoZSBy ZWxhdGl2ZSBtZXJpdHMgb2YgdGhlIHR3byBjdXJ2ZSB0eXBlcy4gIEl0J3MNCm5vdCBjbGVhciB0 byBtZSB3aGV0aGVyIHRoZSBwZXJmb3JtYW5jZSBpbXByb3ZlbWVudHMgcG9zc2libGUNCnVzaW5n IHR3aXN0ZWQgRWR3YXJkcyBjdXJ2ZXMgb3V0d2VpZ2ggdGhlIGFkZGl0aW9uYWwgY29tcGxleGl0 eQ0Kb2YgbW92aW5nIGV4aXN0aW5nIGNvZGViYXNlcyBmcm9tIHNob3J0IFdlaWVyc3RyYXNzIGN1 cnZlcy4NCg0KCQkJCQktLWJhbA0KDQo= From nobody Tue Jul 1 13:47:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F5B1A064E for ; Tue, 1 Jul 2014 13:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pm_SXyL7dvXe for ; Tue, 1 Jul 2014 13:47:31 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83DB01A03AE for ; Tue, 1 Jul 2014 13:47:31 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id q108so3841564qgd.7 for ; Tue, 01 Jul 2014 13:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=cT6pwsC9mqRxDgDKEgPYB/kFW8DG7FmgQL3dyneZ95c=; b=FgizD3bh3UBg40w7Coyyc1CfhSFgOAMjc5GhNkdTWK88l6Xq0MWOs00t8/q6Tjw3kn /QGq5h6nezGkdojcBHST2f6XCWb8SFzkXMyQ+gumYDtzhArS6rCZg3ApfpEV+IXJA7ZL +RK0h8AOGHpDlm84xzRwpuAWuoPjh6Q3kaBPaGYQi2UsM/8wjY81eUb6UpAKo5Tt9tEx FNRGGM5UE4fPGWdFHNRtThz5+0U8ADk18mDpupe56KMe2rYQrttX4yKrgrEF/NKgtDHJ UZttEXriwXaLrGreu5ScMvdR7aH4HPABFNdRxLGtCzXM5JCHVCR/Vde3tH/mTJb5aaiA qFlw== MIME-Version: 1.0 X-Received: by 10.224.167.7 with SMTP id o7mr76320381qay.53.1404247650650; Tue, 01 Jul 2014 13:47:30 -0700 (PDT) Received: by 10.140.27.173 with HTTP; Tue, 1 Jul 2014 13:47:30 -0700 (PDT) Received: by 10.140.27.173 with HTTP; Tue, 1 Jul 2014 13:47:30 -0700 (PDT) In-Reply-To: References: <20140701061655.10456.83525.idtracker@ietfa.amsl.com> <85fa7c63d21043fdb438d959479f56a4@BL2PR03MB482.namprd03.prod.outlook.com> Date: Tue, 1 Jul 2014 13:47:30 -0700 Message-ID: From: Watson Ladd To: tls@ietf.org Content-Type: multipart/alternative; boundary=089e0153852064d05704fd27e233 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jbymYcU0z3wH_YKnf8J2rh6gg2s Subject: Re: [TLS] [Cfrg] FW: New Version Notification for draft-black-numscurves-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 20:47:33 -0000 --089e0153852064d05704fd27e233 Content-Type: text/plain; charset=UTF-8 On Jul 1, 2014 1:37 PM, "Brian LaMacchia" wrote: > > >From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Watson Ladd > >Sent: Tuesday, July 01, 2014 11:08 AM > >To: tls@ietf.org > >Subject: Re: [TLS] [Cfrg] FW: New Version Notification for draft-black-numscurves-00.txt > > > >Is there any technical difference between 19 and 189 other then a slight change in square root calculations? > > Yes, there is. For the NUMS curve, for each security level we > started with the largest prime smaller than 2^(security level) > congruent to 3 mod 4, which is why we use p = 2^256 - 189. As > you point out, choosing a prime congruent to 3 mod 4 simplifies > the square root calculations, but it also means that for the > twisted Edwards curves we can find optimal cofactors of (4,4) for > the curve and its twist. We do not expect to see significant > performance differences between modular operations implemented > with p = 2^256 -189 and p = 2^255 - 19 (the prime for > Curve25519). That extra bit (256 vs 255) forces an extra word to be used: I think I ment 255 minus whatever it was. > > An advantage of the NUMS construction approach is that we are > able to deterministically choose both a short Weierstrass and a > twisted Edwards curve over the same prime for the same security > level. It seems to me that one of the questions the CFRG needs > to consider is the relative merits of the two curve types. It's > not clear to me whether the performance improvements possible > using twisted Edwards curves outweigh the additional complexity > of moving existing codebases from short Weierstrass curves. I can cook up a short Weierstrass prime for the 25519 prime: the curve operations aren't that large in code size anyway. > > --bal > --089e0153852064d05704fd27e233 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jul 1, 2014 1:37 PM, "Brian LaMacchia" <bal@microsoft.com> wrote:
>
> >From: TLS [mailto:tls-boun= ces@ietf.org] On Behalf Of Watson Ladd
> >Sent: Tuesday, July 01, 2014 11:08 AM
> >To: tls@ietf.org
> >Subject: Re: [TLS] [Cfrg] FW: New Version Notification for draft-b= lack-numscurves-00.txt
> >
> >Is there any technical difference between 19 and 189 other then a = slight change in square root calculations?
>
> Yes, there is. =C2=A0For the NUMS curve, for each security level we > started with the largest prime smaller than 2^(security level)
> congruent to 3 mod 4, which is why we use p =3D 2^256 - 189. =C2=A0As<= br> > you point out, choosing a prime congruent to 3 mod 4 simplifies
> the square root calculations, but it also means that for the
> twisted Edwards curves we can find optimal cofactors of (4,4) for
> the curve and its twist. =C2=A0We do not expect to see significant
> performance differences between modular operations implemented
> with p =3D 2^256 -189 and p =3D 2^255 - 19 (the prime for
> Curve25519).

That extra bit (256 vs 255) forces an extra word to be used:= I think I ment 255 minus whatever it was.
>
> An advantage of the NUMS construction approach is that we are
> able to deterministically choose both a short Weierstrass and a
> twisted Edwards curve over the same prime for the same security
> level. =C2=A0It seems to me that one of the questions the CFRG needs > to consider is the relative merits of the two curve types. =C2=A0It= 9;s
> not clear to me whether the performance improvements possible
> using twisted Edwards curves outweigh the additional complexity
> of moving existing codebases from short Weierstrass curves.

I can cook up a short Weierstrass prime for the 25519 prime:= the curve operations aren't that large in code size anyway.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --bal=
>

--089e0153852064d05704fd27e233-- From nobody Tue Jul 1 15:09:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4D91A041C for ; Tue, 1 Jul 2014 15:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mu3yf5ebU1Ru for ; Tue, 1 Jul 2014 15:09:49 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 20FC71A00DB for ; Tue, 1 Jul 2014 15:09:48 -0700 (PDT) Received: from [192.168.13.159] (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 8D925F984 for ; Tue, 1 Jul 2014 18:09:43 -0400 (EDT) Message-ID: <53B331A5.2040908@fifthhorseman.net> Date: Tue, 01 Jul 2014 18:09:41 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0 MIME-Version: 1.0 To: IETF TLS WG X-Enigmail-Version: 1.6+git0.20140323 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NP7HMslag5Uj8txuo5IJ5cdbBfCI8PxIE" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/v7xEd3n652Uh4OOoTMFCXbFOSxs Subject: [TLS] proposal to encrypt ContentType for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 22:09:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NP7HMslag5Uj8txuo5IJ5cdbBfCI8PxIE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable hey folks-- i just opened a pull request to propose that the TLS ContentType (when actually using a proper cipher) should itself be encrypted, rather than in the clear: https://github.com/tlswg/tls13-spec/pull/51 As the main commit in this request says: > Move Content Type inside encryption >=20 > Previous versions of TLS have left the Content Type in the clear > without justifying the exposure of this piece of information. > =20 > This change moves the Content Type inside the encryption to protect= > its confidentiality. > =20 > For backward compatibility during the initial handshake negotiation= , > we need to keep the type field at its original location on the wire= > for cleartext packets. This means redefining the NULL_NULL case to= > not simply be an pseudo-cipher that implements the identity > transformation, but to explicitly state it as sending the TLSPlaint= ext > struct directly over the wire. I'd be interested in feedback on this suggestion. Having the content-type encrypted would mean that TLS alerts, handshakes, and application data would be indistinguishable from one another to an observer, once a ChangeCipherSpec had taken place. This also opens the way to consider the creation of other content types (e.g. "padded application data") without having to decide whether the exposure of a novel ContentType to an observer is itself a risk. If this change is made, it's also relatively easy to just drop the TLS version field for each encrypted TLS record layer fragment. All the best, --dkg --NP7HMslag5Uj8txuo5IJ5cdbBfCI8PxIE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTszGlXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcwesP/RDr3dWWqo67IvuZ45Uu+GuL 7tgUIVSmhcv4Jfad/oYBdgMSz3Ruq9lH4p8cPhL8qGrRKTcvAix3gzRLpN7YmWFo fG6o7iaM5gdTSNTLMalnru2poXtQfbcjMjNV2HKNCjShcqFR3eCPvvtEAT7E3STi BorF1OLGLmvQGPxggyM4lurhJqgDhAMWqPDlIOCZZg+R2XBTABzjz0YHijBLO1xu 8+TpltfsTZo6LLuGTtFLuQq4iW1xZTstwH10ZUD3Xu4nZHWz76khxlfXlXw1lttp xBuGvh90tW0VBGDskAbaURUuUoWqhCjT5KxT6mWEYsfF5nb12vrIyVg6s0sMiV1D Zj4iFZIqzq4uTWGlfU4yTvXhPNRjQ63DnxGiK+4bp0L5BWmkADqMM69rcG2y/F9K 9Tdjg1riF5U0jg9JlJEkqLzDf07Le7M2xcAypgDRrjscoYeiOlvlDAWJux9O33cD /0UmVthme1vX8jnjTEnLnJ8rf1jb8NAa98/Sl122KjnXp7ER8sUJRViPkG3P38BH sj9FOp46UaIUpM4MWpoGrxG4CTtfkYGKWwXlUWG06A5y1M21Cj8ZiNwbb+SwEZFT wpKdrmBNkOyJWemR9lz8g95ZjsLxi4ONHE2IkTGtp+69ydX/Lc/fKAZ8dLZvNe92 I7CyUBB2hYqg75rXd7iY =Nb5y -----END PGP SIGNATURE----- --NP7HMslag5Uj8txuo5IJ5cdbBfCI8PxIE-- From nobody Tue Jul 1 15:31:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C061A03FD for ; Tue, 1 Jul 2014 15:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_74=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PC-1RdXGcpuD for ; Tue, 1 Jul 2014 15:31:26 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752331A0ABA for ; Tue, 1 Jul 2014 15:31:26 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so8601945wib.7 for ; Tue, 01 Jul 2014 15:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rST06LKp5ghXjpmmjpEExD1pWFHH5EafbnhvdxnLtMY=; b=nwFfF0Dff5ylzGcEb3MfFg44an14T7EuqnuBoFjWuUJg+aY2yof2/tQ8AIcJ0+YXw8 NwsXMdIJ27XFQWwwl0py/Fm01dNJF57ATxleD9ZajkitYaHD8SJ8oAN2Bzj4OpYYtjCN gEvrOkCUsY+ouAAzLL7KkLDDEabVGRrDMblRUmI/tvbUIOuMEuDi2VXq2Vm8fqV+FoqN lG8W+C6DDpNSysjXP3eHtQHhF4GFNuNzmACcE9fuVEWa81ICzA9hwMJ4jm5Q03fpk2aS 7OGzSfhNHvozyp19qh0syBWUFSqHQtLNHAat9z531v6ZFyRMv6YigxEMzL3sEgkena6N EXQA== MIME-Version: 1.0 X-Received: by 10.180.107.138 with SMTP id hc10mr15554694wib.47.1404253884993; Tue, 01 Jul 2014 15:31:24 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Tue, 1 Jul 2014 15:31:24 -0700 (PDT) In-Reply-To: <53B331A5.2040908@fifthhorseman.net> References: <53B331A5.2040908@fifthhorseman.net> Date: Tue, 1 Jul 2014 15:31:24 -0700 Message-ID: From: Martin Thomson To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Z1Fa8OJuhym5EvMS-1FL9iGFn4g Cc: IETF TLS WG Subject: Re: [TLS] proposal to encrypt ContentType for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 22:31:27 -0000 On 1 July 2014 15:09, Daniel Kahn Gillmor wrote: > If this change is made, it's also relatively easy to just drop the TLS > version field for each encrypted TLS record layer fragment. I'd like to see that happen. I think that the bit that causes me a little concern is that content type shifts around, with a special case. If you have a special case like that, then there isn't much of a difference between moving it while under encryption to moving it always (other than the need to keep ClientHello clean. But that doesn't seem like the right answer either. It's more disruptive, but if the definition of the AEAD cipher were to encompass the entire struct, then you could define NULL_NULL in a way that placed content type in the old location. I don't know if that is any better, though it would probably be the way I'd structure software that processed the record layer. Then you have a different structure in place of TLSCipherText on which the construction depends on the cipher. NULL_NULL can define something that looks like legacy TLS: ContentType, Version, Payload.length, Payload.data. Ciphersuite constructions can define something like this: Payload.length, Nonce, Encrypted { ContentType, Payload.data }; with variance discouraged, but possible. From nobody Wed Jul 2 04:45:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69441B282D for ; Wed, 2 Jul 2014 04:45:44 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDgUHJa9ZNti for ; Wed, 2 Jul 2014 04:45:43 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29F241B28DC for ; Wed, 2 Jul 2014 04:45:43 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id wm4so11915214obc.7 for ; Wed, 02 Jul 2014 04:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getjive.com; s=mail; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=+6m+uLWSX6kMM+QLuj4FZhjlpFNUU2ZR/sXLM0VC98k=; b=lAYZTE/r9je49nTEW3hTtYItvrX7cRkoyZ2Bwa3pe62FhMUkVFY6TGFL7sBHCgMV1n g6DOT9Qp3WzU8qHtYpTcGrofKYHMpaKgjiZiLqjd/DYJA8IOlcBHThwOLAH9Wm0iPPpw cR4UHiY0gD/xRvlK5pXTrW/M3APfY3p2X3C3Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type; bh=+6m+uLWSX6kMM+QLuj4FZhjlpFNUU2ZR/sXLM0VC98k=; b=j/1/cw7BAMg+iaOixdoojlCTdRE+DzONXcQIRPwwH0biM+THDt/f7uffg//eh+Y0OC uNwLxNWfI3lkY/cbfaNRYuIhmdO0ioAtPN0kC7HZxRHB0BLOFsh8oj8oEPI0XpkkKLrt m/YHj9lxbyYFiy84lWkNEhkV5LyuDTLbJLTOjU3hwYRh6GdTLHvD3hIfbfaGOMXeZXui b01HLmT75akMxy047NfhwdUMHV1abz2rHPrqG2YC05usiheCnVJIiQfz5ASHa43BycaE gkhYiwacg1U90/3FadP1lfPCTEuWBJ/H5kDk/lg1NgtiXGRhzYCDDJD1sb77soZmIeCO hIzA== X-Gm-Message-State: ALoCoQknIRgQ1B8xAxwkCEnH2+GZN/KNYuRa7PPHEsJaM7WjSW+WeNkLIQZbm8JYJAllfH33k4Rb X-Received: by 10.60.45.130 with SMTP id n2mr56455651oem.12.1404301542530; Wed, 02 Jul 2014 04:45:42 -0700 (PDT) Received: from jivecommunications.com ([199.87.120.126]) by mx.google.com with ESMTPSA id rt4sm48967611obb.12.2014.07.02.04.45.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 04:45:41 -0700 (PDT) Message-ID: <53B3F0E5.6040004@getjive.com> Date: Wed, 02 Jul 2014 05:45:41 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="laQqA4IJIFbcnBiNsBhfHC56FiO2eiCU6" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fwreiKn2tGisjYnrX8BQU-fY_CQ Subject: [TLS] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 11:45:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --laQqA4IJIFbcnBiNsBhfHC56FiO2eiCU6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Following discussions with Martin Thomson and Magnus Westerlund, we prepared this draft that aims to fix some issues in RFC 5764. The discussion in this mailing-list should be about updating the IANA TLS ContentType Registry. Discussions about the STUN Methods Registry should stay in the TRAM mailing-list, and the RFC 5764 modifications should stay in the AVTCORE mailing-list. Thanks. URL: http://www.ietf.org/internet-drafts/draft-petithuguenin-avtcore-rfc5764-m= ux-fixes-00.txt Status: https://datatracker.ietf.org/doc/draft-petithuguenin-avtcore-rfc5764-mux-= fixes/ Htmlized: http://tools.ietf.org/html/draft-petithuguenin-avtcore-rfc5764-mux-fixes-= 00 --=20 Marc Petit-Huguenin Developer | Jive Communications, Inc. Jive.com | marcph@getjive.com --laQqA4IJIFbcnBiNsBhfHC56FiO2eiCU6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTs/DlAAoJEMUNRP98lsiXsJEH/3I1I6HOB5fIVtWdinjxoUWh KMZT+KddrQ9kdaAJjlv+1SPyUzb7glH1jHC9IAFybM6YAruRNyCZR3fQXiQz28mQ 2BLP4nSAdRsXX8sXFgzSZvkxcLf37/HHDWGuVRgr/HrkwqhBsv7Z+THOYboNZ9q+ 44jTwRspUxBPdkL62sHIOghgBjrnwuTNuOIrGyjNWQ2MmImLqDLFqyxo5d/odV1s soyW5yiTuKzX8Y0OpDPWna/QiZUPo8M//9htBRVfwFZIrAktZhyGuwawW1ES+x94 I7KbDGt7XuSn0jRLjBFjgK7O3p8devQh6LoaSycrieVfmQyDC/3KxZWF76/mPeE= =gYSg -----END PGP SIGNATURE----- --laQqA4IJIFbcnBiNsBhfHC56FiO2eiCU6-- From nobody Wed Jul 2 10:08:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DAB1B298C for ; Wed, 2 Jul 2014 10:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNZoNYvyZIBo for ; Wed, 2 Jul 2014 10:08:52 -0700 (PDT) Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E8481A05C3 for ; Wed, 2 Jul 2014 10:08:52 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u57so11762184wes.33 for ; Wed, 02 Jul 2014 10:08:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=J9TGNna+wczTdwqGKHnGGBkGvpp7BrGQPfU6IrnU5w4=; b=GB39MzT5mhnyRvc9N+WWniC/W9h848vJp3Bv3jCAjP71l5xPJpvIOBImmronyDKgbC 0akEABdiunjVSSOb8JF/8zSE5/a9N2croJzWFIPMapAIThPVAPuDm4/4gB7vYnvEt1cH 734h7nAOYNE0Qoi7vRdklAiPqTwwHQWKEpBnucRuda95rBsHSAAW15E3n30uy/6Md7ab rkZ3ZNwitHBgz5TkVDhu1qvyTIGQIEvzC1pkSZs6an6HF6yJE0nWi0jrsoWkUavLBtA0 BL2+xpI/WyzSNWiLL0wlioG/EHkuxFvCfwVaBr4IkCJkaAnvxbf3n+1Q5tPtEE0LTMRc ZyOw== X-Gm-Message-State: ALoCoQkGoesBfyerfhhUwGznt+48wYK+l5ikqPvf8hL5whYejU/oIgNNKDVyHntxxko389RAADs0 X-Received: by 10.180.107.99 with SMTP id hb3mr5686405wib.8.1404320931012; Wed, 02 Jul 2014 10:08:51 -0700 (PDT) Received: from [192.168.69.71] ([81.57.85.198]) by mx.google.com with ESMTPSA id m3sm57170413wik.7.2014.07.02.10.08.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 10:08:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "henry.story@bblfish.net" In-Reply-To: Date: Wed, 2 Jul 2014 19:08:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <881AE87B-2120-4D41-AEAB-1E9B9EC26AE6@bblfish.net> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> To: Martin Thomson X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tMDk-7yKoxxrh0LP7spbicmDOv0 Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 17:08:55 -0000 On 9 Jun 2014, at 20:17, Martin Thomson = wrote: > On 9 June 2014 00:34, Nikos Mavrogiannopoulos wrote: >> Could somebody elaborate on what is that issue and why does it need = to >> be solved? (it is not even mentioned in the TLS 1.3 charter) As = someone >> who follows the mailing list that proposal comes out of the blue with = no >> context whatsoever. >=20 >=20 > I think that this has been covered in the thread, but piecemeal: >=20 > * Renegotiation is a major source of security issues, both of the "we > screwed the TLS design up" sort and of the "my application didn't > realize that these things could change" sort. There is a clear desire > to remove features that enable either sort of problem. >=20 > * Renegotiation is just more protocol complexity. Removing it > potentially makes implementations simpler. >=20 > I think that either might be sufficient justification for removing the = feature. >=20 > However, a number of use cases depend on renegotiation to achieve > their ends. Of these, we have identified: >=20 > * mid-session client authentication, which uses renegotiation seems to > only be used in HTTP As you know, but others may have missed, this is proving to be very = useful to create distributed authentication, which can be used for distributed=20= access control, which is what is needed to create a distributed secure = social web, which is the best answer to problems Snowden revealed - which are = inevitable when centralised services amass huge amounts of data on a huge number of = individuals. In the WebID authentication over TLS spec as specified currently a = server SHOULD=20 use this renegotiation in order to provide a sensible user experience. http://www.w3.org/2005/Incubator/webid/spec/ The client side certificate features of TLS would be useless without = reneg, because a server would always have to ask for the identity of the user, even if = the user only asks for public resources. So given that there is a feature in TLS that is in fact useful to = increase communication security by increasing secure p2p interaction on the most = used protocol in the world ( HTTP ), I think we need to make absolutely sure that the removal of this feature is not going to remove the ability to do this = distributed authentication. Otherwise one could argue that removal of this feature = could be used to increase the surveillance state we are allready in (by = removing a key feature that would enaple secure p2p communication). So I know there is http://tools.ietf.org/html/draft-thomson-tls-care-00 that could be deployed in conjunction with a "WWW-Authenticate: = Certificate" HTTP headers=20 to allow a client to ask the server that it be authenticated. [1] But is draft-thomson-tls-care going to be part of TLS1.3?=20 Are we absolutely sure this will work? I'd say that one should not allow removal of TLS client renegotaiton = unless one can be very clear that this is so. [1] = http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1039.html >=20 > * very long-lived connections, which require renegotiation to re-key > occasionally >=20 > The former we have decided to solve in HTTP. As a side note, we just > decided to forbid renegotiation in HTTP/2. >=20 > The latter can be addressed by my proposal, or any of a number of = mechanisms. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls Social Web Architect http://bblfish.net/ From nobody Wed Jul 2 10:48:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE671B2875 for ; Wed, 2 Jul 2014 10:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XnaBvo0lrmH for ; Wed, 2 Jul 2014 10:48:11 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40C121B2870 for ; Wed, 2 Jul 2014 10:48:11 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id n15so10085878wiw.10 for ; Wed, 02 Jul 2014 10:48:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=r78tRCjWBhCcuP4Wxa56doy4zBmbrw19Ri9fI9Wt5/4=; b=TrE3PhAPlOmGcS3TmDOlS4asOm90/uKZYSSfORHZdm2FebV68S+/2EEDQP7de3hh16 EzTuI+jTop/pS+RLeYwRs+DKTietxluZAaDkPVErv5yrW2u8al9CSDVcWugINVEgWabw wAn/iPejc0+1+hmlH5+zTaRFApIVWpEkQNty2ivrgQcr90zo3S/MZJ79TmqoxKHgH1gV Kabuh33MO7+ELuHah3vz3JCWhgr9QlYwOpUt7B49GSNCsO0CHN9sIkmIOBpFxWtAB9zz 29P/XtLI6GG26I5aYUweEWPDNu91jqdVaMjaptX7q0GG+dtuiwxPUEgVtqgjfAn6des/ hONg== X-Gm-Message-State: ALoCoQmigGiqnHLGz6og9Obdn1q5xX23aR/bW9sPzt2k4JOXpwipVHkfSPOkITM/rfNWbzRDRcBG X-Received: by 10.180.84.168 with SMTP id a8mr44664484wiz.36.1404323289845; Wed, 02 Jul 2014 10:48:09 -0700 (PDT) Received: from [192.168.69.71] ([81.57.85.198]) by mx.google.com with ESMTPSA id cz8sm56450361wjc.11.2014.07.02.10.48.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 10:48:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "henry.story@bblfish.net" In-Reply-To: <53A0AB7E.4050706@fifthhorseman.net> Date: Wed, 2 Jul 2014 19:48:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0632D1D0-4941-4CC2-8392-08F079F15D52@bblfish.net> References: <20140606223045.3B5AF1AD46@ld9781.wdf.sap.corp> <1402299260.2427.2.camel@dhcp-2-127.brq.redhat.com> <1402388399.2369.5.camel@dhcp-2-127.brq.redhat.com> <1402476304.2305.8.camel@dhcp-2-127.brq.redhat.com> <1402648977.6191.36.camel@dhcp-2-127.brq.redhat.com> <1402990596.2335.18.camel@dhcp-2-127.brq.redhat.com> <53A0AB7E.4050706@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gMOfmD-ptOgbRLg_oebbP0FCJhM Cc: "tls@ietf.org" Subject: Re: [TLS] Proposed text for removing renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 17:48:15 -0000 On 17 Jun 2014, at 22:56, Daniel Kahn Gillmor = wrote: >=20 > But I suspect most application developers who use TLS don't understand > that the authentication state or cryptographic protections of the > connection may change mid-stream. Of the minority that does = understand > that this state may change, i suspect that many of them don't actually > handle the situation well (if at all). >=20 > if we want to avoid this on the implementation side, do we need more > guidance to implementers of TLS stacks? or guidance for > application-layer users of those stacks? or both? Take this as someone who has come from Java land and has recently moved = to Scala-land. In Java in 1995 the aim was to make APIs very easy to use, for = developers used to thinking in single threaded manners. But currently with the deployment = of multi-core cpus ( Eg. Sun Microsystems T5 with 16 cores and 8 threads = per core for a total of 128 threads, which in an 8 socket system can lead to=20= 1024 thread system ) and the growth of web apis, functional programming = languages=20 such as Scala are coming to the fore. Very good libraries are being = developped there such as the actor framework at https://akka.io/ with very good marketing for concepts such as reactive programming ( = http://www.reactivemanifesto.org/ ) and Reactive Streams ( http://spray.io/scaladays2014/ ) which is making = it much easier to code such mid-stream changes, and to think about these = issues. In the past few years of programming in this space I have learned more = than I had in the previous 10 years of programming. In short: programming has = become=20 enjoyable again, and in great part due to the development of these = frameworks. I just thought I'd mention that, as what may have been difficult 10 = years ago, has perhaps now become easy. So such implementor guidance should take = into account these changes. All the best, Henry Story PS. a bit of background on me: = http://www.australianscience.com.au/interviews/henry-story-a-social-web-ar= chitect/ Social Web Architect http://bblfish.net/ From nobody Wed Jul 2 11:05:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 367301B29E1 for ; Wed, 2 Jul 2014 11:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OPe3ym619C0 for ; Wed, 2 Jul 2014 11:05:22 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AB801A03DE for ; Wed, 2 Jul 2014 11:05:22 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id r20so985294wiv.4 for ; Wed, 02 Jul 2014 11:05:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=OGVXG7ZPK8nDiyPVtdDOHni4ElcP8n/R6DQALgPNgys=; b=AUHkkXmgwhJ1wsaCP9OLXUpXyZqUfF7fVQIL6MnbTeu6yGAWN2x1zRJTR2FSnk/Rsi sk2STtEf0audN698sUP9JWpTfUYVMZktE+FHJ58sO+uqx6HoWBPoWYvbSR1rldquKxix qpqOqYV7/5F3CoCGVlyxKA/UK8mP7dkvNCqCx4us9eOrJCrfk95ZBkcKWRwfC0LaVvi7 RVBJrIcux9DIgzbYYgh+iyOr3Qe2+73sYAhKgk+LGbHMIIrVW1FvXVQIeGRWqqrvoxUO 7jlAWkLrhbszXw9AWbb75naWR28gLDESIaqqv6yCs4tsunoc/oztT/dLkti8cHVAA/gM FiVg== X-Gm-Message-State: ALoCoQk1AtdVq3/dsidNJTRFf7Ip4qQO3jIbtXEmpeEEte+qquIe5RxvbZNle7EnlMFMyBuVrwHt X-Received: by 10.180.13.230 with SMTP id k6mr45240223wic.1.1404324321055; Wed, 02 Jul 2014 11:05:21 -0700 (PDT) Received: from [192.168.69.71] ([81.57.85.198]) by mx.google.com with ESMTPSA id ej2sm56526453wjd.21.2014.07.02.11.05.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 11:05:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "henry.story@bblfish.net" In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738DECC45F@uxcn10-tdc06.UoA.auckland.ac.nz> Date: Wed, 2 Jul 2014 20:05:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5D6D2D4C-27A6-4A20-ACED-067A065DE59E@bblfish.net> References: <9A043F3CF02CD34C8E74AC1594475C738DECC45F@uxcn10-tdc06.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SiDfKDlyNOddba9TVq-18QH_tzA Cc: "" Subject: Re: [TLS] Renegotiation: trying to summarize X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Jul 2014 18:05:24 -0000 On 21 Jun 2014, at 02:16, Peter Gutmann = wrote: > Martin Thomson writes: >=20 >> 1. Remove renegotiation entirely >>=20 >> Brian Smith proposed this. Arguments for are its beautiful = simplicity and >> the fact that it ensures that you limit the time that a single = session (and >> the corresponding keys) live. >=20 > Another argument strongly in favour of removing it is that in all the > applications where I've seen a requirement for renegotiation (e.g. in = industry > standards that use TLS), in approximately, oh, 100% of them it was due = to some > misguided perception that it'd do... well, no-one could really explain = it, but > the capability was there so we may as well add a clause requiring it. Now that you have seen the spec on WebID Authenction over TLS=20 http://www.w3.org/2005/Incubator/webid/spec/ where we have a number of implementations for ( e.g. =20 https://github.com/read-write-web/rww-play ) would you still say that renegotiation is done for some msiguided = perception of what it is doing? And of course the follow up question would be why? > In some cases the requirement was so clearly ridiculous (infrequent = reporting > from SCADA systems where you'd need to renegotiate on each message) = that > implementers chose to ignore it, but in other cases it wasn't easy to = convince > people that it was pointless, particularly when some standards = committee had > decided that you had to do it. >=20 > I'm strongly in favour of removing it, it's mostly pointless, it's = been the > cause of the first real flaw in the SSL/TLS protocol design (rather = than an > implementation issue), and it really messes things up when other = standards > groups decide they need to mandate it without knowing why. If you remove it without making efficient crytpographically secure distributed client authentication feasible then you have in my view decreased security on the web, or at least closed a door that would allow us to escape the surveillance state ( by states or large private players ) because you'll have reduced the ability to communicate in a peer to peer manner securely. ( efficient Distributed authentication is key to that ).=20 >=20 > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls Social Web Architect http://bblfish.net/ From nobody Wed Jul 2 11:19:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46311A03CF for ; Wed, 2 Jul 2014 11:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id he67dYkHRP91 for ; Wed, 2 Jul 2014 11:19:07 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 996541A03BC for ; Wed, 2 Jul 2014 11:19:07 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id y10so11593004wgg.17 for ; Wed, 02 Jul 2014 11:19:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Xe2g90/dCwl9W6nsF2F5a0TfU8y0NC2coBuRkoEX0Og=; b=euLfign5FoBWsQHJfQ8lKxqgyabRDowhCGsBOtnH1ubxPDyVOYst5kPBaFYzjm3ISr teHvvZPaSOifqcLpcW9fUgSDkPq9t6e1DJiX9I+yh+NwnRLCcv/NHeoIWNoeSNdgCMLy z2jUyfycmb2+BZuaxEwjetlriDnAIiI1CO/DDMHW75CKfo0e5vJiiLjVEnb6vMhbODTd OO97vxDatzcYWRuNdoC+Pm1sbKBfHo0i8inGGRJDB2CE9PyXhiylQ3WIYTV9aXyuk+n9 24FA4CKTNfxRA1JlosdralE3XHk2eQ5STW1qqkwnn+SgUlwsr/x1PswW0y8SjEEquyBp fR1Q== X-Gm-Message-State: ALoCoQnjp6LZgHhKBog3PNA1dyKW74ehocyzBBN8DvbaBa+RypoACRw4mSC9OJtftrEaXVTrsmXk X-Received: by 10.194.62.167 with SMTP id z7mr4566517wjr.112.1404325145967; Wed, 02 Jul 2014 11:19:05 -0700 (PDT) Received: from [192.168.69.71] ([81.57.85.198]) by mx.google.com with ESMTPSA id n2sm54268253wjf.40.2014.07.02.11.19.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 11:19:02 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: "henry.story@bblfish.net" In-Reply-To: <6B247363-E6E2-4A81-92D8-FE2F02C14227@gmail.com> Date: Wed, 2 Jul 2014 20:19:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <05FE6B2C-A3B5-4E11-ADC3-5A588DE11C3C@bblfish.net> References: <44DA5A30-015D-40F3-90CA-F15076891BBC@cisco.com> <53AB192F.2040001@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C71854BEF192@USMBX1.msg.corp.akamai.com> <6B247363-E6E2-4A81-92D8-FE2F02C14227@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pq0wclpms_v6nW1HKXyfonmZ4EI Cc: "" Subject: Re: [TLS] Call for Consensus on removal of renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 18:19:10 -0000 On 25 Jun 2014, at 22:47, Yoav Nir wrote: >=20 > On Jun 25, 2014, at 11:42 PM, Salz, Rich wrote: >=20 >>> Nothing. But that would require changing those applications. >>=20 >> Wouldn't they already have to change in order to use TLS 1.3? Or = would the underlying library switch to it, and then not do the magic = rekey calls? >=20 > An application running on something like Apache can replace the = OpenSSL library, and instantly get upgraded from supporting only SSLv3 = and TLS 1.0 to support TLS 1.2 and AES-GCM and ECDHE. >=20 > If that application ever ran enough traffic that renegotiation for = rekeying was needed, upgrading to the next OpenSSL that includes TLS 1.3 = would not be as smooth. >=20 > BTW: This discussion is totally missing the other use of renegotiation = - to move from server-authenticated to mutually-authenticated. Unless = that need is addressed (by some mechanism), I can=92t support removing = renegotiation. +1 I am surprised that even though this was seriously discussed in the = previous threads, it was not put forward as an option in the straw poll. Removing renegotiation MUST = Be conditional on the ability to write servers that allow the client to move from anonymous to TLS = Certificate based authentication when needed. And it has to be baked into TLS1.3 and not part of some = optional spec. Perhaps something like = http://tools.ietf.org/html/draft-thomson-tls-care-00 will do. But one = needs to make sure that you don't make a protocol such as WebID+TLS go from = implementable to non-implementable. ( see http://webid.info/ ) Henry Social Web Architect http://bblfish.net/ From nobody Thu Jul 3 03:41:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162771B283A for ; Thu, 3 Jul 2014 03:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fBji-dzlnin for ; Thu, 3 Jul 2014 03:41:47 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16D21B282B for ; Thu, 3 Jul 2014 03:41:46 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id n12so13301wgh.19 for ; Thu, 03 Jul 2014 03:41:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:date:message-id:cc:to:mime-version; bh=jTOJ4XFDDL44wRVUZoZp+yL1VzUXnsZwm54IlsbdbNQ=; b=GDvo77YyvzAMclWS52zxLeC3FcKfEn3UbtKhZvpw7b21c2c8B8ek3XBPBsf7dOc4Rk VGVqF1YlcSHT9OlKTOuGPgV+Tqxykg1NKqa9NbY9rEKYOTFglw93P1NC41Kr5GFTMp6w 6NxRYMy5wpbD5N9TJaaN7KezDghm3uZYxYbLkenjWYeWmmaztOY5NbsN2a8ngvq7/tyK 9oyVkiJEH0sj6fgvYK8XCvLJ9kNifJ8iCYPN7pnPOuNqP3kCi+q2u+ruXVsU+2Xnj6OP Ssj9qeN4qqSI3u2ybzS+4TkkVB3nQ6LSmCxUqh3j6H2XVLqivhb0a7ZGsK2SGFvEQ2Dp 8C8g== X-Gm-Message-State: ALoCoQnxoSbbK90ORQAGsgLBocHHfkitaj/OMbROXTq3rMo6dOCWyDvHTh4e2xaZMXDjjh5aTr7i X-Received: by 10.194.90.228 with SMTP id bz4mr4056294wjb.65.1404384105540; Thu, 03 Jul 2014 03:41:45 -0700 (PDT) Received: from [192.168.69.71] ([81.57.85.198]) by mx.google.com with ESMTPSA id i3sm65658267wiz.13.2014.07.03.03.41.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Jul 2014 03:41:44 -0700 (PDT) From: "henry.story@bblfish.net" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Jul 2014 12:41:41 +0200 Message-Id: <53ECF780-97CB-4899-B1A9-5A1D97020588@bblfish.net> To: "" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IzQaptpjIaSuXO95EDUWIyBrqpA Cc: Tim Berners-Lee , HTTP Working Group Subject: [TLS] advanced uses of TLS-renegotiation & draft-thomson specs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2014 10:41:50 -0000 Hi, since this group is considering removal of TLS-renegotiation I thought = I should put some time in gathering together a few notes on what I have learnt in = using it to implement WebID over TLS [1] over the past 5 years, noting that I = have learnt the most in implementations in Scala over the past 2 years [2]. The key requirements for us are that=20 a) a user can authenticate to a server with just a point and click = operation in a cryptographically secure manner that is controlled by the = chrome of the browser ( to avoid any phishing or other attacks ) b) that the same server be able to serve resources that are public as = well as secured resources on the same TLS port c) that the creation of identity be totally distributed, with the = creation of identities of close to 0 cost, and such that it ties seamlessly = into the web=20 of data (enabling trust to be established through a web of linked = profiles).=20 This is what the WebID+TLS protocols offers. How does renegotiation come into the picture? We want to authenticate = the user only if the resource he is requesting requires authentication. As shown in = the Authentication=20 Sequence of WebID over TLS [3] we have the following steps: 1.1) a client connects to a server that authenticates itself using = either CA certificates or in the close future I hope DANE via DNSSEC, or other things = still to be invented.... 1.2) the client then sends the request to the server eg: GET /people/henry/foaf HTTP/1.1 1.3) a guard checks the access control rules on the resource = /people/henry/foaf 1.4) if the guard discovers that the resource is protected and that = identification is required it starts a TLS renegotiation ( in Play [2] this is done via a call to the method of the = RequestHeader def certs(required:Boolean): Future[Seq[Certificate]]=20 ) 1.5) if a certificate with a WebID in place of the X509 SAN is = returned it can=20 verify the WebID=20 1.6) Then it can check its access control rules and serve up the = resource or return an error page ( a 401 or something like that ). With the draft-thomson-cant [4] we have the following sequence 2.1) client connects to server as above 2.2) client makes a request for a resource as above 2.3) the server returns a 401 with a "WWW-Authenticate: = ClientCertificate" header 2.4) the client opens a new connection requesting client = authentication and sends a=20 certificate draft-thomson-cant [4] says "A client can use the 'ClientCertificate' challenge as a trigger to = open a new connection and to use client authentication on that connection. The client can use the mechanism in [I-D.thomson-tls-care] to prompt the server to request a client certificate, to avoid the problem where the server doesn't know to make this request." -------------- If TLS renegotiation is removed then UNLESS thomson-TLS-care is part = of TLS-1.3 then client=20 authenticated connection won=92t work. THEREFORE something = thomson-TLS-care this MUST be part of the new TLS-1.3 spec!!! -------------- Still assuming thomson-TLS-care is adopted as part of TLS-1.3 there = are a number of further scenarios: 2.4.1) The client sends a certificate and this is accepted ( public = private key verification procedure ) 2.4.1.1) and the public key determines the identity of the user who is = then able to access the requested resource 2.4.1.2) or the resource is authorised for a number of WebIDs so = additional WebID verification is required 2.4.1.2.1) the WebID is verified 2.4.1.2.1.1) the WebID is authorised for the request method on the = resource and so the action is allowed ( a document is returned) 2.4.1.2.1.2) the WebID is not authorised and a 401 is returned, with = some explanation ( would be nice if this were machine readable - RDF for = example )=20 2.4.1.2.2) The WebID is not verified so a 401 is returned with some = explanation ( in machine readable format would be nice) such as - the remote server is down - the remote server was up, but did not contain the relevant = information - the WebID is an http WebID and not an HTTPS WebID and so security = is not strong enough - the remote WebID profile server is not trusted for some reason 2.4.2) the client sends a certificate and this is not accepted=20 The question here is whether the TLS signals that describe failure = are sophisticated enough so that the chrome can give the user a good explanation as to why the secure connection = could not be accomplished I suppose the main issue would be if the public key cryptography = did not succeed or if the certificate was somehow=20 not parseable. All other cases it seems to me could be dealt with at the HTTP = layer e.g.: - certificate issuer not trusted ( though WebID authentication = does not need that ) - certificate out of date - certificate extensions not understood That is the server could open a connection and flag it as faulty, = so that the HTTP layer could then provide explanations, and other means of authenticating. But we still have a problem. Currently TLS-renegotiation allows the = server to specify what Certificate Authority Distinguished Names it will accept certificates from. This should allow the browser to = filter certificates from certain CAs when presenting them to the user. draft-thomson-cant [4] needs to offer the same functionality at the HTTP = layer. IE to cover current cases of TLS-Authentication the server needs = to specify at the HTTP layer in the 401 WWW-Authenticate: = ClientCertificate header what Distinguished Names it accepts. Because it = is a web protocol, it might as well add the option to identifying = issuers not by DN but rather by WebID [6], as specified in a Issuer = Alternative Name field of the X509 certificate. If that list is too long = one could even imagine the "WWW-Authenticate: ClientCertificate" header = containing a field pointing to a list of accepted CAs. But as shown by the WebID protocol there is no need for Certificate = Authorities when using client side certificates. So there should be a = way for the HTTP response from the server to specify that it will accept = any WebID enabled certificate ( Ie a certificate with a WebID in the = Subject Alternative Name field of the X509 ) =20 In my work on deploying WebID I have come to the conclusion that due to = JavaScript weaknesses in the browser ( e.g.: the limitation of CORS = security to identifying JS only by its origin ) most of the requests for = remote resources will need to go through a proxy on the users personal = server that will be able to make these requests. The advantage is that = we won't need to wait for browser vendors to implement this. Server to = server communication will be able to implement this to great advantage = immediately. This means that one will also need to consider that for a = period of time there will be clients that understand the = "WWW-Authenticate: ClientCertificate" headers that co-exist with one's = that don't. So a server will want to offer a number of authentication = options. That's as much I can think of right now. Hope that helps, Henry Story =20 [1] The full set of specs for WebID is here: http://www.w3.org/2005/Incubator/webid/spec/ with curl examples=20 https://github.com/read-write-web/rww-play/wiki/Curl-Interactions [2] especially in rww-play https://github.com/read-write-web/rww-play =20 where I had to patch Play to allow Client side renegotiation=20 https://github.com/bblfish/Play20 This patch has not been pushed into Play yet, because=20 1) as the patch was written it requires the request for = renegotiation to be made in the same JVM as the one holding onto the TLS request. = Their current implementation is based on netty.=20 2) They are moving to a fully actor based framework using akka ( = http://akka.io )=20 and an http framework based on that http://spray.io/ which makes = it easy to build all these connections as message passing between actors that can = then reside on=20 different machines, solving (1) above in a much more elegant = fashion. This type of programming even makes it easy to send messages across layers. [3] = http://www.w3.org/2005/Incubator/webid/spec/tls/#the-webid-authentication-= protocol [4] http://tools.ietf.org/html/draft-thomson-httpbis-cant-00 [5] http://tools.ietf.org/html/draft-thomson-tls-care-00 [6] http://www.w3.org/2005/Incubator/webid/spec/identity/ Social Web Architect http://bblfish.net/ From nobody Thu Jul 3 07:54:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2E21A0162 for ; Thu, 3 Jul 2014 07:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kb3GjjZpTO9X for ; Thu, 3 Jul 2014 07:54:44 -0700 (PDT) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 513EF1A00F8 for ; Thu, 3 Jul 2014 07:54:44 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w62so370292wes.38 for ; Thu, 03 Jul 2014 07:54:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=FX24DUatI1O8wE4VGFe8C4RO9VumIjxHBoavwApR9dk=; b=GEH6Qj/dmmcpWN+yIqMHEymbSyswk3JG2OLCagewXcwaZQoW9TrJFbYzsfhBE4K2JH +xxWJniYVFIt2T8NP8+GOyJTbnWhVpN9qU4cw4mzAl4fDSDz0vNmZRk/JipxAwmbx4m+ x5Q6P0yY1AXDFI8TT2TZAQsX/BxHI/QcKoZe1KOchzPnKHVbUXpAdriykKWQ3fSLLPAN VJShpv3H5cSrUQXsnby9WfOSxNEn/aCcodoMmLbeEGKUGTbXgUoNMwZHDvt/Lbq37RWS xVbYhVfXAClXt70zQ0LKAFwr3SFjcgq/rTbGvlBfPOCwrDwc8tevIw68KQwAsvYPsFpJ h+6w== X-Gm-Message-State: ALoCoQmSDvnFx9lsIe7U/qWMeoDhwGzTa93VwD1XFMA+Lxhan3x50OlwwZl1n3HPubhs2yqTMxbV X-Received: by 10.194.110.10 with SMTP id hw10mr5469577wjb.81.1404399280286; Thu, 03 Jul 2014 07:54:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.57.202 with HTTP; Thu, 3 Jul 2014 07:54:00 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:d111:1560:5df9:5c3d] From: Eric Rescorla Date: Thu, 3 Jul 2014 07:54:00 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e010d870c39a49f04fd4b30e1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/x9a-XxO4ax3meclLNOU3IuHoyCM Subject: [TLS] Pull request for 1RTT Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 14:54:47 -0000 --089e010d870c39a49f04fd4b30e1 Content-Type: text/plain; charset=UTF-8 I've just put up a pull request that makes the first cut changes from the consensus from Denver for 1-RTT handshake without SNI protection. As we discussed, I'm leaving the door open for SNI protection, but since these are separable work items, and this is already a fairly signficant change I wanted to get the 1-RTT stuff down first. The PR can be found at: https://github.com/tlswg/tls13-spec/pull/52 It's still kind of rough and there are a bunch of open issues (and most likely several mistakes) but I think it's clear what direction it's going in. I wanted to explicitly called out some known open issues in the draft, both so I can get feedback/discussion on these and so that people know they haven't been forgotten: - Based on the mailing list and interim discussion and a bunch of private conversations, I wrote this up as requiring named DHE groups (and assuming we will want named ECDHE groups). This makes things quite a bit simpler and seemed like a good idea anyway. I recognize that I'm a bit ahead of the list consensus here, but my sense is that this was the emerging consensus. If there are major objections to this change, I can rework things otherwise, but I believe it will make things more confusing. - I have partly removed dh_rsa and dh_dss because they get in the way of having a common handshake pattern and nobody seemed to want them. Assuming nobody screams I will do a separate PR to remove them entirely. - We need to take care that we don't introduce a downgrade issue in the 2-RTT flow (Figure 2) where the server tells the client he has sent an incorrect CKE. There are some open issues noted in the draft about how to do this exactly. Comments welcome. - MT convinced me that the client should be able to make multiple ClientKeyExchange offers for different parameter sets, so I did that. - The EarlyData mechanism is a bit overgeneral as opposed to an explicit ClientKeyExchange extension, but it seems like it's going to be useful when we do SNI encryption and 0-RTT. - I haven't assumed we are going to incorporate ECDHE, but that seems like it's likely coming. Similarly, I expect to incorporate the triple handshake fix separately. - I haven't added any support for the server-offered extensions that were proposed in Denver. That seems separable. I intend to merge this into the draft on Friday. As should be clear from the draft and the comments above, there are still open issues to resolve, so even when it's merged in some of this is obviously provisional. With that said, if there's stuff that looks clearly wrong or there is an open issue that isn't properly identified, please let me know. Thanks, -Ekr P.S. Thanks to all the people who helped with earlier versions of this, in particular Wan-Teh Chang Daniel, Kahn Gillmor, Andy Lutomirski, Andrei Popov, Tom Ritter, Rich Salz, and Martin Thomson. --089e010d870c39a49f04fd4b30e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've just put up a pull request that makes the fi= rst cut changes from
the consensus from Denver for 1-RTT handshak= e without SNI
protection. As we discussed, I'm leaving the do= or open for SNI
protection, but since these are separable work items, and this is
already a fairly signficant change I wanted to get the 1-RTT stuff
down first.

The PR can be found at:


It's still kind of rough and there are a bunch of open issues (an= d
most likely several mistakes) but I think it's clear what directio= n
it's going in.

I wanted to explici= tly called out some known open issues in the draft,
both so I can= get feedback/discussion on these and so that people know
they haven't been forgotten:

- Based on t= he mailing list and interim discussion and a bunch of
=C2=A0 priv= ate conversations, I wrote this up as requiring named DHE groups
=C2=A0 (and assuming we will want named ECDHE groups). This makes things
=C2=A0 quite a bit simpler and seemed like a good idea anyway. I recog= nize
=C2=A0 that I'm a bit ahead of the list consensus here, = but my sense is
=C2=A0 that this was the emerging consensus. =C2= =A0If there are major objections
=C2=A0 to this change, I can rework things otherwise, but I believe it= will
=C2=A0 make things more confusing.

- I have partly removed dh_rsa and dh_dss because they get in the way
=C2=A0 of having a common handshake pattern and nobody seemed to want
=
=C2=A0 them. Assuming nobody screams I will do a separate PR to remove= them
=C2=A0 entirely.

- We need to take= care that we don't introduce a downgrade issue in
=C2=A0 the 2-RTT flow (Figure 2) where the server tells the client he = has
=C2=A0 sent an incorrect CKE. There are some open issues note= d in the draft
=C2=A0 about how to do this exactly. Comments welc= ome.

- MT convinced me that the client should be able to make mul= tiple
=C2=A0 ClientKeyExchange offers for different parameter set= s, so I did
=C2=A0 that.

- The EarlyData= mechanism is a bit overgeneral as opposed to an
=C2=A0 explicit ClientKeyExchange extension, but it seems like it'= s going
=C2=A0 to be useful when we do SNI encryption and 0-RTT.<= /div>

- I haven't assumed we are going to incorporat= e ECDHE, but that
=C2=A0 seems like it's likely coming. Similarly, I expect to incor= porate
=C2=A0 the triple handshake fix separately.

=
- I haven't added any support for the server-offered extensi= ons
=C2=A0 that were proposed in Denver. That seems separable.
<= br>
I intend to merge this into the draft on Friday. As should be= clear
from the draft and the comments above, there are still ope= n issues to
resolve, so even when it's merged in some of this is obviously
provisional. With that said, if there's stuff that looks clearly= wrong
or there is an open issue that isn't properly identifi= ed, please let
me know.

Thanks,
-Ekr
P.S. Thanks to all the people who helped with earlier versions = of
this, in particular Wan-Teh Chang Daniel, Kahn Gillmor, Andy
Lutomirski, Andrei Popov, Tom Ritter, Rich Salz, and Martin
= Thomson.
=C2=A0
--089e010d870c39a49f04fd4b30e1-- From nobody Thu Jul 3 19:29:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221E71A0428 for ; Thu, 3 Jul 2014 19:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6L9e9c9uscv for ; Thu, 3 Jul 2014 19:29:14 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A901A0A97 for ; Thu, 3 Jul 2014 19:29:13 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id n15so3109013wiw.11 for ; Thu, 03 Jul 2014 19:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=22yIAXQdMQOOFioxVjVvLFIxrqPBdnZXAe3FBL0Xgg0=; b=tloBHdFWPQhlY0bcaYvADURFoLkB01ycOhOmsH6KU42p78B8hH+KbOjN+Pm9WoaJBg 7rUipPdjDsn8V5QYObESD7hr6hreoAeF1x3F5HU6qMT6PIo7grLdSVzgjCdsnrfDxLca QOcPtb5hfykPBZ9hK3RTbu/BSM0v2tv9O1UWh7yNbdF5lDduSARgko7Unt2uFOQO4vrB NPm+2d1ueWazmpY8HSgMVVuP5Yyp4W3ZWLZGUWY7vQ4kZexHVFzklUQvTRbrS6afImm/ i++wL+FQMBxyRe4TAABpDSvz7evqF/c8YcsdAWGweIHRPJYPkjdC9FC9k9pijMXcuvW/ WKCw== MIME-Version: 1.0 X-Received: by 10.194.200.3 with SMTP id jo3mr389127wjc.110.1404440952538; Thu, 03 Jul 2014 19:29:12 -0700 (PDT) Received: by 10.194.21.69 with HTTP; Thu, 3 Jul 2014 19:29:12 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Jul 2014 19:29:12 -0700 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Q0oJqAjmZx1sYhKNXaRB6cSHZ_8 Cc: "tls@ietf.org" Subject: Re: [TLS] Pull request for 1RTT Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 02:29:16 -0000 On Thu, Jul 3, 2014 at 7:54 AM, Eric Rescorla wrote: > I've just put up a pull request that makes the first cut changes from > the consensus from Denver for 1-RTT handshake without SNI > protection. As we discussed, I'm leaving the door open for SNI > protection, but since these are separable work items, and this is > already a fairly signficant change I wanted to get the 1-RTT stuff > down first. > > The PR can be found at: > > https://github.com/tlswg/tls13-spec/pull/52 > > It's still kind of rough and there are a bunch of open issues (and > most likely several mistakes) but I think it's clear what direction > it's going in. > > I wanted to explicitly called out some known open issues in the draft, > both so I can get feedback/discussion on these and so that people know > they haven't been forgotten: > > - Based on the mailing list and interim discussion and a bunch of > private conversations, I wrote this up as requiring named DHE groups > (and assuming we will want named ECDHE groups). This makes things > quite a bit simpler and seemed like a good idea anyway. I recognize > that I'm a bit ahead of the list consensus here, but my sense is > that this was the emerging consensus. If there are major objections > to this change, I can rework things otherwise, but I believe it will > make things more confusing. > > - I have partly removed dh_rsa and dh_dss because they get in the way > of having a common handshake pattern and nobody seemed to want > them. Assuming nobody screams I will do a separate PR to remove them > entirely. > > - We need to take care that we don't introduce a downgrade issue in > the 2-RTT flow (Figure 2) where the server tells the client he has > sent an incorrect CKE. There are some open issues noted in the draft > about how to do this exactly. Comments welcome. > > - MT convinced me that the client should be able to make multiple > ClientKeyExchange offers for different parameter sets, so I did > that. So I don't why a client would change their Client Hello in response to a Server Hello, and hence why there can be a downgrade. The client says "here are my capabilities, and some early guesses as to what you want to see" If those guesses are incorrect, there is no need for another Hello: the server already knows what the client wants to tell it, and the client knows what the server would see. There is no state machine issue, because the server knows if it got the data or not, and the client will know if the negotiated curve and suite were among the guesses. Another misfeature is the Finished message ordering: it slows down one side or another. If we fix Triple Handshake the right way, it's safe to send data before receiving the other Finished message. > > - The EarlyData mechanism is a bit overgeneral as opposed to an > explicit ClientKeyExchange extension, but it seems like it's going > to be useful when we do SNI encryption and 0-RTT. Are we ever going to be able to turn it off? Clients initially will use only it for compatibility. Servers will develop bugs because clients all use it. Lather, rinse, reiterate. Sincerely, Watson Ladd From nobody Thu Jul 3 21:01:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB2B1A0522 for ; Thu, 3 Jul 2014 21:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLBNgl7ibUnb for ; Thu, 3 Jul 2014 21:01:00 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B8A51B2B82 for ; Thu, 3 Jul 2014 21:00:59 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id q58so1079713wes.30 for ; Thu, 03 Jul 2014 21:00:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=EaJDx21lJefZti4aNNw6STITUTgIcRCrjlJLcNPC30A=; b=mzmB1vJBboCcL3rgfDkYchLSjpIYagyWx7I7yYunj53PUTy6m145a3dP5U5y4nxZR5 4UeBnWrd2rUE+OFVsrESPUDp0gr7R8zfWk3eu6uIgeseesnUF414LWSd1oWMSrcgh8+i ClfG0a3t3cxTs2z7xmnvNWMKGYO08jiiqdjR8gjbWsFLUPLxWPnRFtIzq1CQ2qixBq7N nVnWIzRGBq1dUi0jG3sZHn4sUUGS8Adz+0400rRHqs5276AMa+3kGravsi0JFbQQd22R 22DhJGOsUP0SQOfjsjxQfYBDotlWTkJwJls6Q+VwkKSK8Yu1W3l+olZ2q8Jn96ZLVvUw YdCQ== X-Gm-Message-State: ALoCoQliygJ5l+nYG2b9CfeCXv2YIU+l3J3ilTRcibvbkynEf8sUhJXwOL+v1dTjAgd4CF2aP9S2 X-Received: by 10.194.238.6 with SMTP id vg6mr9053273wjc.24.1404446457664; Thu, 03 Jul 2014 21:00:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.57.202 with HTTP; Thu, 3 Jul 2014 21:00:17 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: From: Eric Rescorla Date: Thu, 3 Jul 2014 21:00:17 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=089e013d0b54372e3704fd562ce9 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/62r9jZrVulRKxasH_TFS9wuIvJ4 Cc: "tls@ietf.org" Subject: Re: [TLS] Pull request for 1RTT Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 04:01:08 -0000 --089e013d0b54372e3704fd562ce9 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 3, 2014 at 7:29 PM, Watson Ladd wrote: > On Thu, Jul 3, 2014 at 7:54 AM, Eric Rescorla wrote: > > I've just put up a pull request that makes the first cut changes from > > the consensus from Denver for 1-RTT handshake without SNI > > protection. As we discussed, I'm leaving the door open for SNI > > protection, but since these are separable work items, and this is > > already a fairly signficant change I wanted to get the 1-RTT stuff > > down first. > > > > The PR can be found at: > > > > https://github.com/tlswg/tls13-spec/pull/52 > > > > It's still kind of rough and there are a bunch of open issues (and > > most likely several mistakes) but I think it's clear what direction > > it's going in. > > > > I wanted to explicitly called out some known open issues in the draft, > > both so I can get feedback/discussion on these and so that people know > > they haven't been forgotten: > > > > - Based on the mailing list and interim discussion and a bunch of > > private conversations, I wrote this up as requiring named DHE groups > > (and assuming we will want named ECDHE groups). This makes things > > quite a bit simpler and seemed like a good idea anyway. I recognize > > that I'm a bit ahead of the list consensus here, but my sense is > > that this was the emerging consensus. If there are major objections > > to this change, I can rework things otherwise, but I believe it will > > make things more confusing. > > > > - I have partly removed dh_rsa and dh_dss because they get in the way > > of having a common handshake pattern and nobody seemed to want > > them. Assuming nobody screams I will do a separate PR to remove them > > entirely. > > > > - We need to take care that we don't introduce a downgrade issue in > > the 2-RTT flow (Figure 2) where the server tells the client he has > > sent an incorrect CKE. There are some open issues noted in the draft > > about how to do this exactly. Comments welcome. > > > > - MT convinced me that the client should be able to make multiple > > ClientKeyExchange offers for different parameter sets, so I did > > that. > > So I don't why a client would change their Client Hello in response to > a Server Hello, and hence > why there can be a downgrade. > The client says "here are my capabilities, and some early guesses as > to what you want to see" > If those guesses are incorrect, there is no need for another Hello: > the server already knows what > the client wants to tell it, and the client knows what the server would > see. > > There is no state machine issue, because the server knows if it got > the data or not, and > the client will know if the negotiated curve and suite were among the > guesses. > I'm not saying that the client should change it's ClientHello, but since there are two messages, it could in principle do so, right? The draft currently requires that the client not do so, in S 7.4.1.2: When a client first connects to a server, it is required to send the ClientHello as its first message. The client can also send a ClientHello in response to a HelloRequest or on its own initiative in order to renegotiate the security parameters in an existing connection. Finally, the client will send a ClientHello when the server has responded to its ClientHello with a ServerHello that selects cryptographic parameters that don't match the client's ClientKeyExchange. In that case, the client MUST send the same ClientHello (without modification) along with the new ClientKeyExchange. Does that seem problematic to you? > Another misfeature is the Finished message ordering: it slows down one > side or another. > If we fix Triple Handshake the right way, it's safe to send data > before receiving the other > Finished message. I'm not following your analysis here as to why this slows things down: 1. The client can't safely send data before it receives the server's Certificate and CertificateVerify, since that's the first thing that authenticates the server. These messages are sent in the same flight as the Finished, so will arrive at more or less the same time. 2. If the server doesn't want client authentication for the data, it can send data as soon as it receives the client's first flight. If not, then it needs to wait for the client's Certificate and CertificateVerify, which again is sent with the client's Finished. [0] Why does the Finished slow things down in this case? What am I missing? > > - The EarlyData mechanism is a bit overgeneral as opposed to an > > explicit ClientKeyExchange extension, but it seems like it's going > > to be useful when we do SNI encryption and 0-RTT. > > Are we ever going to be able to turn it off? Clients initially will > use only it for compatibility. Servers will develop bugs > because clients all use it. Lather, rinse, reiterate. > Obviously, that's a potential problem, but it also seems pretty clear that any extra data has to go in an extension for compatibility. Best, -Ekr [0] DKG points out that the rules might be relaxable if the server wants authentication for the client's data but might be willing to send some data, such as a banner message, without client auth, but let's deal with that later. --089e013d0b54372e3704fd562ce9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Jul 3, 2014 at 7:29 PM, Watson Ladd <<= a href=3D"mailto:watsonbladd@gmail.com" target=3D"_blank">watsonbladd@gmail= .com> wrote:
On Thu, Jul 3, 2014 at 7= :54 AM, Eric Rescorla <ekr@rtfm.com&= gt; wrote:
> I've just put up a pull request that makes the first cut changes f= rom
> the consensus from Denver for 1-RTT handshake without SNI
> protection. As we discussed, I'm leaving the door open for SNI
> protection, but since these are separable work items, and this is
> already a fairly signficant change I wanted to get the 1-RTT stuff
> down first.
>
> The PR can be found at:
>
> =C2=A0 https://github.com/tlswg/tls13-spec/pull/52
>
> It's still kind of rough and there are a bunch of open issues (and=
> most likely several mistakes) but I think it's clear what directio= n
> it's going in.
>
> I wanted to explicitly called out some known open issues in the draft,=
> both so I can get feedback/discussion on these and so that people know=
> they haven't been forgotten:
>
> - Based on the mailing list and interim discussion and a bunch of
> =C2=A0 private conversations, I wrote this up as requiring named DHE g= roups
> =C2=A0 (and assuming we will want named ECDHE groups). This makes thin= gs
> =C2=A0 quite a bit simpler and seemed like a good idea anyway. I recog= nize
> =C2=A0 that I'm a bit ahead of the list consensus here, but my sen= se is
> =C2=A0 that this was the emerging consensus. =C2=A0If there are major = objections
> =C2=A0 to this change, I can rework things otherwise, but I believe it= will
> =C2=A0 make things more confusing.
>
> - I have partly removed dh_rsa and dh_dss because they get in the way<= br> > =C2=A0 of having a common handshake pattern and nobody seemed to want<= br> > =C2=A0 them. Assuming nobody screams I will do a separate PR to remove= them
> =C2=A0 entirely.
>
> - We need to take care that we don't introduce a downgrade issue i= n
> =C2=A0 the 2-RTT flow (Figure 2) where the server tells the client he = has
> =C2=A0 sent an incorrect CKE. There are some open issues noted in the = draft
> =C2=A0 about how to do this exactly. Comments welcome.
>
> - MT convinced me that the client should be able to make multiple
> =C2=A0 ClientKeyExchange offers for different parameter sets, so I did=
> =C2=A0 that.

So I don't why a client would change their Client Hello in = response to
a Server Hello, and hence
why there can be a downgrade.
The client says "here are my capabilities, and some early guesses as to what you want to see"
If those guesses are incorrect, there is no need for another Hello:
the server already knows what
the client wants to tell it, and the client knows what the server would see= .

There is no state machine issue, because the server knows if it got
the data or not, and
the client will know if the negotiated curve and suite were among the guess= es.

I'm not saying that the client = should change it's ClientHello, but since there
are two messa= ges, it could in principle do so, right?

The draft currently requires that the client not do so,= in S 7.4.1.2:

=C2=A0 =C2=A0 =C2=A0 When a client first connects to a server, it is requi= red to send
=C2=A0 =C2=A0 =C2=A0 the ClientHello as its first message. =C2=A0The c= lient can also send a
=C2=A0 =C2=A0 =C2=A0 ClientHello in respons= e to a HelloRequest or on its own initiative
=C2=A0 =C2=A0 =C2=A0= in order to renegotiate the security parameters in an existing
=C2=A0 =C2=A0 =C2=A0 connection. =C2=A0Finally, the client will send a= ClientHello when the
=C2=A0 =C2=A0 =C2=A0 server has responded t= o its ClientHello with a ServerHello that
=C2=A0 =C2=A0 =C2=A0 se= lects cryptographic parameters that don't match the client's
=C2=A0 =C2=A0 =C2=A0 ClientKeyExchange. =C2=A0In that case, the client= MUST send the same
=C2=A0 =C2=A0 =C2=A0 ClientHello (without mod= ification) along with the new
=C2=A0 =C2=A0 =C2=A0 ClientKeyExcha= nge.

Does that seem problematic to you?

=C2=A0
Another misfeature is the Finished message ordering: it slows down one
side or another.
If we fix Triple Handshake the right way, it's safe to send data
before receiving the other
Finished message.

I'm not following you= r analysis here as to why this slows things down:

= 1. The client can't safely send data before it receives the server'= s
Certificate and CertificateVerify, since that's the first thing th= at
authenticates the server. These messages are sent in the same = flight as the
Finished, so will arrive at more or less the same t= ime.

2. If the server doesn't want client authentication= for the data, it can
send data as soon as it receives the client= 's first flight. If not, then it
needs to wait for the client= 's Certificate and CertificateVerify, which
again is sent with the client's Finished. [0]

=
Why does the Finished slow things down in this case? What am I
missing?

=C2=A0
> - The EarlyData mechanism is a bit overgeneral as opposed to an
> =C2=A0 explicit ClientKeyExchange extension, but it seems like it'= s going
> =C2=A0 to be useful when we do SNI encryption and 0-RTT.

Are we ever going to be able to turn it off? Clients initially will use only it for compatibility. Servers will develop bugs
because clients all use it. Lather, rinse, reiterate.
=
Obviously, that's a potential problem, but it also seems= pretty clear
that any extra data has to go in an extension for c= ompatibility.

Best,
-Ekr


[0] DKG points out that the rules might be relaxable if the
server wants authentication for the client's data but might be willing=
to send some data, such as a banner message, without client
= auth, but let's deal with that later.

<= /div> --089e013d0b54372e3704fd562ce9-- From nobody Thu Jul 3 21:42:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85141B2BCB for ; Thu, 3 Jul 2014 21:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNWpLi2Mqt-Y for ; Thu, 3 Jul 2014 21:42:03 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9071B2BD4 for ; Thu, 3 Jul 2014 21:41:58 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u57so1099786wes.5 for ; Thu, 03 Jul 2014 21:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JSfYKJZWtjAYvVwwVHMn1NJLaeKgvMjYC5hpz/dvvFU=; b=KL0uF/U7tR8x8BZWpQrBDLDH4poQ4MJKcHU1i+4RUffIDuFqIIEXXr5YNkqhrsoacU 00+hDbE+gBvjhojsZGxWCtoYDT1CrtJzRLeQkstFBp7uja2HQFaB3u2beyoj/90SemC5 s2RCW08mv/s+Lu38wqZ2nGARNF65YMvomxqJQQHPNPK753K75Nk6FP8R2KKpzoUKgtBT 6qhr7GQqXBdaDrY5MwDiCgRCqLpPReENI1BUfJkzlf98WeaVzz4bj++yvuJGy6la3lHJ 4LpFiPgRqEke8lirCdBwpP8EyPZc4zK8d/fJdEdnONH87PFqFL7ZIsx5jSylCCNUEhFm +UWQ== MIME-Version: 1.0 X-Received: by 10.181.13.80 with SMTP id ew16mr15050251wid.51.1404448916720; Thu, 03 Jul 2014 21:41:56 -0700 (PDT) Received: by 10.194.21.69 with HTTP; Thu, 3 Jul 2014 21:41:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Jul 2014 21:41:56 -0700 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_p2NGYW4Q_DqMmEotfkw9Fh4DEY Cc: "tls@ietf.org" Subject: Re: [TLS] Pull request for 1RTT Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 04:42:05 -0000 On Thu, Jul 3, 2014 at 9:00 PM, Eric Rescorla wrote: > > > > On Thu, Jul 3, 2014 at 7:29 PM, Watson Ladd wrote: >> >> On Thu, Jul 3, 2014 at 7:54 AM, Eric Rescorla wrote: >> > I've just put up a pull request that makes the first cut changes from >> > the consensus from Denver for 1-RTT handshake without SNI >> > protection. As we discussed, I'm leaving the door open for SNI >> > protection, but since these are separable work items, and this is >> > already a fairly signficant change I wanted to get the 1-RTT stuff >> > down first. >> > >> > The PR can be found at: >> > >> > https://github.com/tlswg/tls13-spec/pull/52 >> > >> > It's still kind of rough and there are a bunch of open issues (and >> > most likely several mistakes) but I think it's clear what direction >> > it's going in. >> > >> > I wanted to explicitly called out some known open issues in the draft, >> > both so I can get feedback/discussion on these and so that people know >> > they haven't been forgotten: >> > >> > - Based on the mailing list and interim discussion and a bunch of >> > private conversations, I wrote this up as requiring named DHE groups >> > (and assuming we will want named ECDHE groups). This makes things >> > quite a bit simpler and seemed like a good idea anyway. I recognize >> > that I'm a bit ahead of the list consensus here, but my sense is >> > that this was the emerging consensus. If there are major objections >> > to this change, I can rework things otherwise, but I believe it will >> > make things more confusing. >> > >> > - I have partly removed dh_rsa and dh_dss because they get in the way >> > of having a common handshake pattern and nobody seemed to want >> > them. Assuming nobody screams I will do a separate PR to remove them >> > entirely. >> > >> > - We need to take care that we don't introduce a downgrade issue in >> > the 2-RTT flow (Figure 2) where the server tells the client he has >> > sent an incorrect CKE. There are some open issues noted in the draft >> > about how to do this exactly. Comments welcome. >> > >> > - MT convinced me that the client should be able to make multiple >> > ClientKeyExchange offers for different parameter sets, so I did >> > that. >> >> So I don't why a client would change their Client Hello in response to >> a Server Hello, and hence >> why there can be a downgrade. >> The client says "here are my capabilities, and some early guesses as >> to what you want to see" >> If those guesses are incorrect, there is no need for another Hello: >> the server already knows what >> the client wants to tell it, and the client knows what the server would >> see. >> >> There is no state machine issue, because the server knows if it got >> the data or not, and >> the client will know if the negotiated curve and suite were among the >> guesses. > > > I'm not saying that the client should change it's ClientHello, but since > there > are two messages, it could in principle do so, right? > > The draft currently requires that the client not do so, in S 7.4.1.2: > > When a client first connects to a server, it is required to send > the ClientHello as its first message. The client can also send a > ClientHello in response to a HelloRequest or on its own initiative > in order to renegotiate the security parameters in an existing > connection. Finally, the client will send a ClientHello when the > server has responded to its ClientHello with a ServerHello that > selects cryptographic parameters that don't match the client's > ClientKeyExchange. In that case, the client MUST send the same > ClientHello (without modification) along with the new > ClientKeyExchange. > > Does that seem problematic to you? Why send two messages when one will do? In particular the server can send a Server Key Exchange, and a Certificate, CertificateVerify message in response to the Client Hello. Once the client receives this, it's ready to send data after its CKE and such messages. Restarting the protocol the way we have now introduces another round trip. In fact, it might be worth ditching the current client psyc approach in favor of this one: less complex, backwards compatibility by signalling an extension, and gets client authentication in one round trip also. This of course assumes a minor change to the protocol's calculation of keys, and makes 0-RTT more of a jump. > > >> >> Another misfeature is the Finished message ordering: it slows down one >> side or another. >> If we fix Triple Handshake the right way, it's safe to send data >> before receiving the other >> Finished message. > > > I'm not following your analysis here as to why this slows things down: > > 1. The client can't safely send data before it receives the server's > Certificate and CertificateVerify, since that's the first thing that > authenticates the server. These messages are sent in the same flight as the > Finished, so will arrive at more or less the same time. > > 2. If the server doesn't want client authentication for the data, it can > send data as soon as it receives the client's first flight. If not, then it > needs to wait for the client's Certificate and CertificateVerify, which > again is sent with the client's Finished. [0] > > Why does the Finished slow things down in this case? What am I > missing? I was a bit confused about what exactly Finished protects, and why we need to wait for it. > > >> >> > - The EarlyData mechanism is a bit overgeneral as opposed to an >> > explicit ClientKeyExchange extension, but it seems like it's going >> > to be useful when we do SNI encryption and 0-RTT. >> >> Are we ever going to be able to turn it off? Clients initially will >> use only it for compatibility. Servers will develop bugs >> because clients all use it. Lather, rinse, reiterate. > > > Obviously, that's a potential problem, but it also seems pretty clear > that any extra data has to go in an extension for compatibility. Have you read the hello-pading draft? Or heard people complain about Java interop with things not RC4? Vendors are not adequately testing their ability to deal with legal but unused corners of the spec, and virtually none of them are doing adversarial fuzzing. Sincerely, Watson Ladd > > Best, > -Ekr > > > [0] DKG points out that the rules might be relaxable if the > server wants authentication for the client's data but might be willing > to send some data, such as a banner message, without client > auth, but let's deal with that later. > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Jul 3 22:28:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E9A1B2BE1 for ; Thu, 3 Jul 2014 22:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tj_NoWRX5iJ5 for ; Thu, 3 Jul 2014 22:28:34 -0700 (PDT) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78A11B2BDB for ; Thu, 3 Jul 2014 22:28:33 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id q59so1145062wes.12 for ; Thu, 03 Jul 2014 22:28:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Vk41VW5Huy945QcJTnYRVYK/qwsqqC0fLkUIx0zC76c=; b=YwFGWTVxnhJJlxhUkmQi1BgN3ku4gbqDgpqzhx6k2+URE/3Bh/BHl/4r9pn5XS7JNh mTYDh4Q5jNfjJTkc7NFfZiEE/epaHNkMuSO500WJjqYRDV5Ce6M9V3viIMwqyUxpiDqx ofjdBqWWtvMRtJdfu1NaPZEKxYf9z9YM9m7meWqWcdtuUEMrYpleRo3wxwqrO5bciWah PTDAaBbF7dkhE6Kiap79otmwBEjclHp4DAnmHRnsAoLUBdos1nB4woA2+u9rGY8Ha3ga qXOMWCQGle0UF/si8eMPS9YyLuAq6eWxLCUFOlappRsYsjHIzGvNs7GSPqOTnSxNr/pu 8QvQ== X-Gm-Message-State: ALoCoQmQzB0D7V7fhgNMz9iu+AU/l0GXfdwxjRgtVm/oY5EKzKDcd8Rc6FnNsYl8yKJozRBgs8OI X-Received: by 10.194.1.164 with SMTP id 4mr9563272wjn.17.1404451712548; Thu, 03 Jul 2014 22:28:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.57.202 with HTTP; Thu, 3 Jul 2014 22:27:52 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: From: Eric Rescorla Date: Thu, 3 Jul 2014 22:27:52 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=047d7b3a81766e6f0c04fd5765ec Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_yvM8zj0mR_1l2R0R-gUuY4KeDA Cc: "tls@ietf.org" Subject: Re: [TLS] Pull request for 1RTT Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 05:28:35 -0000 --047d7b3a81766e6f0c04fd5765ec Content-Type: text/plain; charset=UTF-8 On Thu, Jul 3, 2014 at 9:41 PM, Watson Ladd wrote: > On Thu, Jul 3, 2014 at 9:00 PM, Eric Rescorla wrote: > > Why send two messages when one will do? In particular the server can > send a Server Key Exchange, > and a Certificate, CertificateVerify message in response to the Client > Hello. > I assume you intend the ServerHello here as well, since you need that for the cipher suite, etc.? > Once the client receives this, it's ready to send data after its CKE > and such messages. > > Restarting the protocol the way we have now introduces another round trip. > Ah, I understand what you are suggesting. Certainly something like this is possible, but the general sense of the discussion at the Interim was that people wanted the "wrong group" handshake to look like a missed guess/correction followed by the "right group" handshake, in the interest of simplicity. Note also that if we have a relatively small number of groups (which seems like a good idea in any case) then the vast majority of handshakes can complete in 1-RTT because the client guesses right (e.g., they send P256 and 25519 and the server supports one or both.) Another difficulty is that it in the flow you are suggesting, you don't protect the server's first flight, which includes: - The server's extensions response (and request if we add DKG/Ritter's 'type B extensions'). - The server's certificate (relevant if using SNI encryption and for passive protection for P2P applications). In some cases, an attacker can elicit these, so protection is just passive, and in others he cannot, in which case protection is also active. Best, -Ekr --047d7b3a81766e6f0c04fd5765ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 3, 2014 at 9:41 PM, Watson Ladd <watsonbladd@gmail.com>= wrote:
On Thu, Jul 3, 2014 at 9= :00 PM, Eric Rescorla <ekr@rtfm.com&= gt; wrote:

Why send two messages when one will do? In particular the serve= r can
send a Server Key Exchange,
and a Certificate, CertificateVerify message in response to the Client Hell= o.

I assume you intend the ServerHello = here as well, since you need that for the
cipher suite, etc.?

=C2=A0
Once the client receives this, it's ready to send data after its CKE and such messages.

Restarting the protocol the way we have now introduces another round trip.<= br>

Ah, I understand what you are suggestin= g.

Certainly something like this is possible, but = the general sense of the
discussion at the Interim was that people wanted the "wrong group= "
handshake to look like a missed guess/correction followed = by the "right
group" handshake, in the interest of simp= licity. Note also that if we
have a relatively small number of groups (which seems like a good idea=
in any case) then the vast majority of handshakes can complete i= n 1-RTT
because the client guesses right (e.g., they send P256 an= d 25519 and
the server supports one or both.)

Another dif= ficulty is that it in the flow you are suggesting, you don't protect
the server's first flight, which includes:

- The server's extensions response (and request if we add DK= G/Ritter's
=C2=A0 =C2=A0'type B extensions').

- The server's certificate (relevant if using SNI enc= ryption and for
=C2=A0 =C2=A0passive protection for P2P applications).
=

In some cases, an attacker can elicit these, so protect= ion is just
passive, and in others he cannot, in which case prote= ction is also
active.

Best,
-Ekr

--047d7b3a81766e6f0c04fd5765ec-- From nobody Fri Jul 4 07:59:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9291D1A0173 for ; Fri, 4 Jul 2014 07:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKWB1VL3kB9c for ; Fri, 4 Jul 2014 07:59:48 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C2791A0165 for ; Fri, 4 Jul 2014 07:59:48 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 8B13D1A0091; Fri, 4 Jul 2014 16:59:45 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rtHwQfZhyalO; Fri, 4 Jul 2014 16:59:37 +0200 (CEST) Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id 0946D1A008F; Fri, 4 Jul 2014 16:59:37 +0200 (CEST) Received: from [10.53.40.204] (port=53667 helo=mail-essen-01.secunet.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1X34xe-0002tb-52; Fri, 04 Jul 2014 16:59:38 +0200 Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 4 Jul 2014 16:59:37 +0200 Message-ID: <53B6C159.7010002@secunet.com> Date: Fri, 4 Jul 2014 16:59:37 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alyssa Rowan , References: <53AC97B8.2080909@nthpermutation.com> <53AD134E.9010903@akr.io> In-Reply-To: <53AD134E.9010903@akr.io> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.76] Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6Wi2eah6pZdtJ8nY28tTsGE56Ps Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2014 14:59:49 -0000 Alyssa Rowan wrote on 27.06.2014 08:46: > Brainpool has already generated a set of 'random' primes, but random primes are extremely slow to implement - and > in the case of Brainpool, the 256-bit curve has extremely unfortunate lack of twist security, so any implementation > that tries to skip validation is in really big trouble. Why should anyone try to skip validation? In order to improve performance by less than 1%? -- Johannes From nobody Fri Jul 4 08:15:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63FA11B2A6F for ; Fri, 4 Jul 2014 08:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cttJOYUI0XhK for ; Fri, 4 Jul 2014 08:15:33 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935301B29F8 for ; Fri, 4 Jul 2014 08:15:33 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so795026wgg.9 for ; Fri, 04 Jul 2014 08:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=51skg31XKp+UcgGpgArbdy1MdKr59LCoIh64D/od0LU=; b=eed67uR26YiFhZKki6kV7A6zAsFCx1sFfL/S8rBg9XN0X5ZU9Abwi1Uo9AeJ+ALKFx tE1EAMh7ddrHl0BmAiXEA38gKq5eU2UDCO2MsAD3jGM7Gp46ziGBbRorSeyd+ZV4+iqa ZfRqgDLvWKAQtzm98UPIczLhScdvH9MW8ccvPf97VMmmUd0i3iyZ/NyMyJUxmKNHCKYC DZEB+T1FTDMuIxVsVNKhudsqC2PknCuv0rNNMnoHqblt0mj7+mujXM2GCt/l+3jz+Ubu jCqQKWcBJY0TargQUQ7AUPqxQKv5tOXSsNOMp1nJmrp/YrKI/YiSwCYP26hYf3ztdTic BKsw== MIME-Version: 1.0 X-Received: by 10.194.48.103 with SMTP id k7mr12879787wjn.68.1404486932203; Fri, 04 Jul 2014 08:15:32 -0700 (PDT) Received: by 10.194.21.69 with HTTP; Fri, 4 Jul 2014 08:15:32 -0700 (PDT) In-Reply-To: <53B6C159.7010002@secunet.com> References: <53AC97B8.2080909@nthpermutation.com> <53AD134E.9010903@akr.io> <53B6C159.7010002@secunet.com> Date: Fri, 4 Jul 2014 08:15:32 -0700 Message-ID: From: Watson Ladd To: Johannes Merkle Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3yPLsVVwmed7StYilEWPrZYEDIk Cc: "tls@ietf.org" Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2014 15:15:35 -0000 On Fri, Jul 4, 2014 at 7:59 AM, Johannes Merkle wrote: > Alyssa Rowan wrote on 27.06.2014 08:46: >> Brainpool has already generated a set of 'random' primes, but random primes are extremely slow to implement - and >> in the case of Brainpool, the 256-bit curve has extremely unfortunate lack of twist security, so any implementation >> that tries to skip validation is in really big trouble. > > Why should anyone try to skip validation? In order to improve performance by less than 1%? Implementations frequently expose an API where validation is separate from group operations, and people just forget to make the call sometimes. Furthermore, with anything other than a compressed format it's not just twist security, but any security that failure of point validation harms. I send point on a curve with smooth order, and extract the key. I send point on curve with small order, and dictate the key, etc. Twist security matters for Joyce-Briers ladders only, as far as I know on Weierstrass curves. Other formulas use the y coordinates. Sincerely, Watson Ladd > > > -- > Johannes > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Jul 4 11:12:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E972F1B2DC7 for ; Fri, 4 Jul 2014 11:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66I4d4flw554 for ; Fri, 4 Jul 2014 11:12:13 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99CC71B2DBA for ; Fri, 4 Jul 2014 11:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=271; q=dns/txt; s=iport; t=1404497533; x=1405707133; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=R0VW9oHbeETdtS5jzWQDUGXKCbPxcme4ZFOrht9sZoU=; b=lxsJcytgMs0dtPmuwOCDGbiTQyIxTq7xb6g4xtqsEPI94kx9sgx1Vjtf yCx0HjWaJI9NOI7F8rkVRa38srTC97DEO18/U9cYFSTCGrVmJ+tv8sHMz 3Jhnw4yasoq71WMVgHhntcYoWbMA75H2erc7sXR2a7kqSWArTA4eEix8H w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAMnttlOtJV2Z/2dsb2JhbABagw6BLMc3FnWECjpRAT5CJwSIVaAhqjsXklaBFgWadpQMg0OCMA X-IronPort-AV: E=Sophos;i="5.01,602,1400025600"; d="scan'208";a="58385628" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP; 04 Jul 2014 18:12:13 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s64ICC6Z018015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 4 Jul 2014 18:12:13 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 13:12:12 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Consensus on accepting draft-gillmor-tls-negotiated-dl-dhe-02 Thread-Index: AQHPl7N6+C6bDqer+E6rYuFXi8pblw== Date: Fri, 4 Jul 2014 18:12:12 +0000 Message-ID: <11A08850-989A-41DC-A6EB-9C9EDDDFE192@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.57] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vF4-jYqWBuEGO_4OFA6xIgTWYbw Subject: [TLS] Consensus on accepting draft-gillmor-tls-negotiated-dl-dhe-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2014 18:12:15 -0000 The call on the list shows that there is consensus to accept draft-gillmor-= tls-negotiated-dl-dhe-02 as a working group item. The author should submi= t a new draft with the filename of draft-ietf-tls-negotiated-dl-dhe-00. =20 Thanks, Joe (For the chairs) = From nobody Fri Jul 4 14:09:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FF71A049F for ; Fri, 4 Jul 2014 14:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHK-jnNjLGfa for ; Fri, 4 Jul 2014 14:09:13 -0700 (PDT) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:96]) by ietfa.amsl.com (Postfix) with ESMTP id BC51F1A0463 for ; Fri, 4 Jul 2014 14:09:13 -0700 (PDT) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta09.emeryville.ca.mail.comcast.net with comcast id NM2D1o0021Y3wxoA9M9DKc; Fri, 04 Jul 2014 21:09:13 +0000 Received: from [192.168.1.145] ([71.202.164.227]) by omta15.emeryville.ca.mail.comcast.net with comcast id NM9B1o00M4uhcbK8bM9CkQ; Fri, 04 Jul 2014 21:09:12 +0000 Message-ID: <53B717F7.9010109@brainhub.org> Date: Fri, 04 Jul 2014 14:09:11 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <53AC97B8.2080909@nthpermutation.com> <53AD134E.9010903@akr.io> <53B6C159.7010002@secunet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1404508153; bh=oEmXb6v3J1awECbwtBFsJKQ2CPRexGsDyIM95+DVfi4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qROWYh0CDON+NpzvcbQHEklIUz1vNs0MXJTHBbvje7WzgRZ6IouqE93SQL9xs39uU Yq9ns+iVU/V1K7f2mZZ2FZ24T1APUO8uQrgBGlqa8K+BNsZAlMKJLpOcsFTt1tepDk 2DaVJxys+Me0OLL2pIo16TaNAJrKL5ONov8/bn+geww4h/Vaq6Bm12kJlQ2DjBB6nM moNjqdC2Pi79dFoO35jBAUGEi2hIfNCoU7FcNCfm48w/zc742Nu6pM7P7TSoOtPcun WDVX2eMJF9VTTNmfnPfxnlv78Qp9ZGEqG97mqCLiJ7YQi/mpCm65pQc18tyUwHyWCn XoLRXN9umvGoA== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pUiXT8pZ7aLBG997jUIuLEz2k9Y Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2014 21:09:15 -0000 On 07/04/2014 08:15 AM, Watson Ladd wrote: > On Fri, Jul 4, 2014 at 7:59 AM, Johannes Merkle > wrote: >> Alyssa Rowan wrote on 27.06.2014 08:46: >>> Brainpool has already generated a set of 'random' primes, but random primes are extremely slow to implement - and >>> in the case of Brainpool, the 256-bit curve has extremely unfortunate lack of twist security, so any implementation >>> that tries to skip validation is in really big trouble. >> Why should anyone try to skip validation? In order to improve performance by less than 1%? > Implementations frequently expose an API where validation is separate > from group operations, and people > just forget to make the call sometimes. However, point validation, or validation of an element in a DH group (http://tools.ietf.org/html/rfc6989#section-2.2) is a common requirement for a crypto implementation. FIPS 140-2 crypto module algorithm validation includes point validation testing (http://csrc.nist.gov/groups/STM/cavp/documents/dss2/ecdsa2vs.pdf requires tests from Section A.4.2 of ANSI X9.62) An implementation that doesn't do required EC point checks may have other flaws at higher levels. Replacing a low-level crypto primitive with a stronger one does not necessarily make the entire stack secure. Some may argue that this obscures the results of a security audit. In reality all we are talking about is plugging (x,y) in the curve equation and checking that the two sides match. As was pointed out, when compression is used, this check is "forced". > Furthermore, with anything other than a compressed format it's not > just twist security, but any security that failure of point validation > harms. > I send point on a curve with smooth order, and extract the key. I send > point on curve with small order, and dictate the key, etc. It would be good to list what does twist security mean for TLS. http://safecurves.cr.yp.to/twist.html references the paper that uses an ElGamal decryption oracle. The attack will reveal the decryption scalar. How does this translate to TLS? I assume we are talking about ECDH only. Regarding dictating the key, it seems that a (corrupt) peer can always limit his private key to a small value and thus dictate the shared secret to be close to another peer's public key. > > Twist security matters for Joyce-Briers ladders only, as far as I know > on Weierstrass curves. Other formulas use the y coordinates. > > Sincerely, > Watson Ladd >> >> -- >> Johannes >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > From nobody Fri Jul 4 17:12:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57BF61A0145 for ; Fri, 4 Jul 2014 17:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFPAnTq3DVKt for ; Fri, 4 Jul 2014 17:12:37 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868B21A0092 for ; Fri, 4 Jul 2014 17:12:36 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id cc10so13559770wib.0 for ; Fri, 04 Jul 2014 17:12:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qMU58h7niSy9aZzWtoWSC4m+arQqVBTAFXHUE0Q8L3k=; b=iTNwwK/On8dD7mVQXDyG6W8aDV1cINYjDq7U4vNqXwMsf6aMqY5mWA2F0OxvyYHmaG bPp2j0t/eEAfUqopxWacVGJrRyAi5u1vU/BzSQgoHxy7dlZwW7ODIQcPCTKZBpd1uWDG Kb7CycR6bcv+DReaEKQwBJzGhM0lIxLuXSWVRzcw/iJvd1EkEqTGgetJMIFL72kg5cjl eJ/+W9ZzyTr13fcbK0Qt7nKAevXj/4mWGQe9kGreJ2UkGWjglQRBW5r/mdzppcDiLpom UwEMp2trG24ykEzA+zKY17pqbVMJ34n1bUFez3qtZI3eAAK0mcjeKMWcz9lAba7Rizq4 09AQ== X-Gm-Message-State: ALoCoQk02xhEWIyTmvDyLekAw+heotWa/m4/r0l+/5SGTicqYZRZVKH07v2FSnKGcOQ1vND8jk5S X-Received: by 10.180.76.20 with SMTP id g20mr20122729wiw.7.1404519155200; Fri, 04 Jul 2014 17:12:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.57.202 with HTTP; Fri, 4 Jul 2014 17:11:55 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <53B331A5.2040908@fifthhorseman.net> References: <53B331A5.2040908@fifthhorseman.net> From: Eric Rescorla Date: Fri, 4 Jul 2014 17:11:55 -0700 Message-ID: To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=f46d04343946538e8104fd671983 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qlQdj91l-H4QfhI7NlEeU1dexR8 Cc: IETF TLS WG Subject: Re: [TLS] proposal to encrypt ContentType for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 00:12:39 -0000 --f46d04343946538e8104fd671983 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 1, 2014 at 3:09 PM, Daniel Kahn Gillmor wrote: > hey folks-- > > i just opened a pull request to propose that the TLS ContentType (when > actually using a proper cipher) should itself be encrypted, rather than > in the clear: > > https://github.com/tlswg/tls13-spec/pull/51 > > As the main commit in this request says: > > > Move Content Type inside encryption > > > > Previous versions of TLS have left the Content Type in the clear > > without justifying the exposure of this piece of information. > > > > This change moves the Content Type inside the encryption to protect > > its confidentiality. > > > > For backward compatibility during the initial handshake negotiation, > > we need to keep the type field at its original location on the wire > > for cleartext packets. This means redefining the NULL_NULL case to > > not simply be an pseudo-cipher that implements the identity > > transformation, but to explicitly state it as sending the > TLSPlaintext > > struct directly over the wire. > > I'd be interested in feedback on this suggestion. > > Having the content-type encrypted would mean that TLS alerts, > handshakes, and application data would be indistinguishable from one > another to an observer, once a ChangeCipherSpec had taken place. > > This also opens the way to consider the creation of other content types > (e.g. "padded application data") without having to decide whether the > exposure of a novel ContentType to an observer is itself a risk. > > If this change is made, it's also relatively easy to just drop the TLS > version field for each encrypted TLS record layer fragment. > This seems like an idea with a fair bit of merit, but if I understand correctly, it's going to result in a stream of data which cannot be parsed into TLS records by existing network elements. I'm concerned about how this is going to interact with various elements which process the ciphertext. For instance: - Protocol enforcement devices which expect to see a stream of records. - RFC 5764 elements which multiplex STUN, SRTP, and DTLS and use the first byte for this purpose. I think we can fix the second category by requiring explicit opt-in for this feature, either by an extension or by it being TLS 1.3 (though we would still need to define how to demux), but the first category seems potentially more problematic. It seems like it might be worth doing some experiments to see what the impact on success rates is. [0] -Ekr [0] If this turns out to be a problem, there is an ugly but workable solution, which is to have all TLSCiphertext records start with an application_data type byte, regardless of their content. This would of course expand packets by one byte. > All the best, > > --dkg > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --f46d04343946538e8104fd671983 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 1, 2014 at 3:09 PM, Daniel Kahn Gillmor &= lt;dkg@fifthhors= eman.net> wrote:
hey folks--

i just opened a pull request to propose that the TLS ContentType (when
actually using a proper cipher) should itself be encrypted, rather than
in the clear:

=C2=A0https://github.com/tlswg/tls13-spec/pull/51

As the main commit in this request says:

> =C2=A0 =C2=A0 Move Content Type inside encryption
>
> =C2=A0 =C2=A0 Previous versions of TLS have left the Content Type in t= he clear
> =C2=A0 =C2=A0 without justifying the exposure of this piece of informa= tion.
>
> =C2=A0 =C2=A0 This change moves the Content Type inside the encryption= to protect
> =C2=A0 =C2=A0 its confidentiality.
>
> =C2=A0 =C2=A0 For backward compatibility during the initial handshake = negotiation,
> =C2=A0 =C2=A0 we need to keep the type field at its original location = on the wire
> =C2=A0 =C2=A0 for cleartext packets. =C2=A0This means redefining the N= ULL_NULL case to
> =C2=A0 =C2=A0 not simply be an pseudo-cipher that implements the ident= ity
> =C2=A0 =C2=A0 transformation, but to explicitly state it as sending th= e TLSPlaintext
> =C2=A0 =C2=A0 struct directly over the wire.

I'd be interested in feedback on this suggestion.

Having the content-type encrypted would mean that TLS alerts,
handshakes, and application data would be indistinguishable from one
another to an observer, once a ChangeCipherSpec had taken place.

This also opens the way to consider the creation of other content types
(e.g. "padded application data") without having to decide whether= the
exposure of a novel ContentType to an observer is itself a risk.

If this change is made, it's also relatively easy to just drop the TLS<= br> version field for each encrypted TLS record layer fragment.

This seems like an idea with a fair bit of merit, but = if I understand
correctly, it's going to result in a stream o= f data which cannot be
parsed into TLS records by existing network elements.
I'= m concerned about how this is going to interact with various
elem= ents which process the ciphertext. For instance:

- Protocol enforcement devices which expect to see a stream of records.
- RFC 5764 elements which multiplex STUN, SRTP, and DTLS and
=C2=A0 use the first byte for this purpose.

I t= hink we can fix the second category by requiring explicit opt-in for
this feature, either by an extension or by it being TLS 1.3 (though
we would still need to define how to demux), but the first category=
seems potentially more problematic. It seems like it might be wo= rth
doing some experiments to see what the impact on success rates
is. [0]

-Ekr

[0] If th= is turns out to be a problem, there is an ugly but workable
solution, which is to have all TLSCiphertext records start with
an application_data type byte, regardless of their content. This
=
would of course expand packets by one byte.

= =C2=A0
All the best,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --dkg


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


--f46d04343946538e8104fd671983-- From nobody Fri Jul 4 17:38:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742C71A029F for ; Fri, 4 Jul 2014 17:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFtA8hGuaM2y for ; Fri, 4 Jul 2014 17:38:18 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9088F1A019A for ; Fri, 4 Jul 2014 17:38:18 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u57so2116755wes.3 for ; Fri, 04 Jul 2014 17:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CMbmG2n5etWILd3nHcwyyluMm/BIx967H3vJF9VOi8U=; b=H/joVZfD2xnhGglb7AskN/caV2xIzRGeoOcP6D1/qf50G6pzHBC0Wm6PEe4rMIVGaU QaLcH26VQwU04I7Rz1JRIW1g6ivLDCpZOUNnqsmxxDRDinPanWn8QxvRZgwW+yQstUaN OReL+SzgA1Kumb7yRMddsIoiQogEWa9NySwdMcZ+N3w2zFPbK96PZrSea5qFtETciQZQ OfIEQMtt28zsnJHCPd4KyLu1gesyzunaHk7fGHDgGEvNoi5AJ2Cc7V0l7Eh7YWikY9+n +oRADLBiUTIlGveRqZLNPf1RUlS4J/nDQc6rgBxD1ojXLshRrNWXtraclspYhl9tRFLh ZErg== MIME-Version: 1.0 X-Received: by 10.194.120.129 with SMTP id lc1mr15506215wjb.16.1404520696783; Fri, 04 Jul 2014 17:38:16 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Fri, 4 Jul 2014 17:38:16 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Fri, 4 Jul 2014 17:38:16 -0700 (PDT) In-Reply-To: References: <53B331A5.2040908@fifthhorseman.net> Date: Fri, 4 Jul 2014 17:38:16 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: multipart/alternative; boundary=089e01227b12362c4e04fd6775b8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ey61WMlj6Tp-MgZ0AuXXg3QKvtw Cc: tls@ietf.org Subject: Re: [TLS] proposal to encrypt ContentType for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 00:38:20 -0000 --089e01227b12362c4e04fd6775b8 Content-Type: text/plain; charset=UTF-8 On Jul 4, 2014 5:12 PM, "Eric Rescorla" wrote: > - Protocol enforcement devices which expect to see a stream of records. > - RFC 5764 elements which multiplex STUN, SRTP, and DTLS and > use the first byte for this purpose. If we want to lose the redundant version number, then these problems need to be solved. Agree that an update to dtls-srtp should be easy, but the former is potentially troublesome. An experiment could be expensive, do we know what is likely here? --089e01227b12362c4e04fd6775b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jul 4, 2014 5:12 PM, "Eric Rescorla" <ekr@rtfm.com> wrote:
> - Protocol enforcement devices which expect to see a stream of records= .
> - RFC 5764 elements which multiplex STUN, SRTP, and DTLS and
> =C2=A0 use the first byte for this purpose.

If we want to lose the redundant version number, then these = problems need to be solved. Agree that an update to dtls-srtp should be eas= y, but the former is potentially troublesome. An experiment could be expens= ive, do we know what is likely here?

--089e01227b12362c4e04fd6775b8-- From nobody Fri Jul 4 18:19:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11231A0011 for ; Fri, 4 Jul 2014 18:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jIV2FIpZSRa for ; Fri, 4 Jul 2014 18:19:19 -0700 (PDT) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D0B31A00FE for ; Fri, 4 Jul 2014 18:19:19 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id vb8so2409888obc.11 for ; Fri, 04 Jul 2014 18:19:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=agmlHhHJB65/gnAymlM17Vc9FlMr7MZZUCz9MRsA0ZQ=; b=LYYNYRWGInsVR5hYey17IJSGC1GSfOb35Amgrc9+YnHGqBaFp8d7qg/WUsIYxGCsKb AoRYBkWrqW047EWTLJMHkzsumjQeC3H8YRq9Mi9rsw6jX9UXlIFcLWMQcKHqmAbpHEy3 4lC/LxPeUzIG8xfNR7DFIu5KqiiRB8SGavYZ42jrnKdXppaMGcODa0vllHck1G2rK4pf eFB2EKBADsw2mZUNLU/KHKkUkK9NUs94PnhDZ47UoiqqkRM5onbmNEijgBA8TjUOCdYE Ti2++GkK/faDr5zJ1erO5yFiH/xqxHwZv44zv/k+KlYp03Q9+mf4Q2FziA9vg4xbDLv7 Kp1g== X-Gm-Message-State: ALoCoQlAjtRI0W0IIpK1B956Wn4b37kLlGFmz1X1ddoporBGAQKzIs3NZpe52MCIJBnU8Y49uJ+j MIME-Version: 1.0 X-Received: by 10.60.45.130 with SMTP id n2mr15921764oem.12.1404523158778; Fri, 04 Jul 2014 18:19:18 -0700 (PDT) Received: by 10.76.10.198 with HTTP; Fri, 4 Jul 2014 18:19:18 -0700 (PDT) In-Reply-To: References: <53B331A5.2040908@fifthhorseman.net> Date: Fri, 4 Jul 2014 18:19:18 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bIgLCuzhYJaSLwchOs6JN3WeTiQ Cc: IETF TLS WG Subject: Re: [TLS] proposal to encrypt ContentType for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 01:19:20 -0000 On Fri, Jul 4, 2014 at 5:11 PM, Eric Rescorla wrote: > This seems like an idea with a fair bit of merit, but if I understand > correctly, it's going to result in a stream of data which cannot be > parsed into TLS records by existing network elements. I don't think that it does. As long as the length field remains unencrypted, it's possible or a stream processor to figure out where each record starts and end. Processors already need to do this as new record types can always be introduced. -- Colm From nobody Fri Jul 4 20:30:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A101A0303 for ; Fri, 4 Jul 2014 20:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGQn_KjqLn0P for ; Fri, 4 Jul 2014 20:30:51 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 758601A01C8 for ; Fri, 4 Jul 2014 20:30:51 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id m15so1158534wgh.19 for ; Fri, 04 Jul 2014 20:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q5p3FgobTao7aNyOxXUIYEARtocPzlqOC4vrzfc5FqE=; b=tcc3MiD/xuXA8cfRjUfCDKc/opYtfg228XnLotp7RSdCbhpY4Wzk3cIVdRAvGW7Ptq znc1mnXqjbkE2VH5AJ9axkG95SgEe+aksdyATFpvY9tOFjt4ZGxWRbULVH3ckqNZy8n8 LysUIoFF850yHlVEMEejMDG95mCO3d7Ary373xHRi/kSG0Md5/dgrKOZAl840FZJrlR/ ok2MK0+YzEnEtijEWeprXugBwihjjjBnE8M3UzP1JkzbWHs9gES42LBS+fruVs1ExnKl tx5kg2VoR/MlNx17NeY2+8obUbhSVLhr8Wg7IV1oe5AFRJ6vjGOS2l+wzJlWgNUtkItD Y0EQ== MIME-Version: 1.0 X-Received: by 10.180.86.225 with SMTP id s1mr6707023wiz.36.1404531049928; Fri, 04 Jul 2014 20:30:49 -0700 (PDT) Received: by 10.194.21.69 with HTTP; Fri, 4 Jul 2014 20:30:49 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Jul 2014 20:30:49 -0700 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kXPrTyvOEBnr8I6d13Vd4Bng2Gc Cc: "tls@ietf.org" Subject: Re: [TLS] Pull request for 1RTT Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 03:30:53 -0000 On Thu, Jul 3, 2014 at 10:27 PM, Eric Rescorla wrote: > On Thu, Jul 3, 2014 at 9:41 PM, Watson Ladd wrote: >> >> On Thu, Jul 3, 2014 at 9:00 PM, Eric Rescorla wrote: >> >> Why send two messages when one will do? In particular the server can >> send a Server Key Exchange, >> and a Certificate, CertificateVerify message in response to the Client >> Hello. > > > I assume you intend the ServerHello here as well, since you need that for > the > cipher suite, etc.? > > >> >> Once the client receives this, it's ready to send data after its CKE >> and such messages. >> >> Restarting the protocol the way we have now introduces another round trip. > > > Ah, I understand what you are suggesting. > > Certainly something like this is possible, but the general sense of the > discussion at the Interim was that people wanted the "wrong group" > handshake to look like a missed guess/correction followed by the "right > group" handshake, in the interest of simplicity. Note also that if we > have a relatively small number of groups (which seems like a good idea > in any case) then the vast majority of handshakes can complete in 1-RTT > because the client guesses right (e.g., they send P256 and 25519 and > the server supports one or both.) True: the client can take a guess. > > Another difficulty is that it in the flow you are suggesting, you don't > protect > the server's first flight, which includes: > > - The server's extensions response (and request if we add DKG/Ritter's > 'type B extensions'). > > - The server's certificate (relevant if using SNI encryption and for > passive protection for P2P applications). Unless I'm missing something you aren't either: the Change Cipher Spec would come before the Certificate and Certificate Verification to protect these two. But yes, this does require guessing of server parameters, so once we need to do that, might as well guess more. (It seems a bit weird to me to design the protocol one feature request at a time: that way lies Perl 6. Also, I don't recall having seen 'type B extensions': what was the rationale? How was the answer going to come back?) Sincerely, Watson Ladd > > In some cases, an attacker can elicit these, so protection is just > passive, and in others he cannot, in which case protection is also > active. > > Best, > -Ekr > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Jul 4 21:52:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FCE1A02F7; Fri, 4 Jul 2014 21:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihY2dQYPITgq; Fri, 4 Jul 2014 21:52:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4977B1A02F8; Fri, 4 Jul 2014 21:52:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140705045246.3379.84590.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 21:52:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6cUBgC0WrUoXW_Ua1E9iX0u_aDY Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-downgrade-scsv-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 04:52:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks Authors : Bodo Moeller Adam Langley Filename : draft-ietf-tls-downgrade-scsv-00.txt Pages : 11 Date : 2014-07-04 Abstract: This document defines a Signaling Cipher Suite Value (SCSV) that prevents protocol downgrade attacks on the Transport Layer Security (TLS) protocol. It updates RFC 2246, RFC 4346, and RFC 5246. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 5 05:47:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791FB1A0505 for ; Sat, 5 Jul 2014 05:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjB38MQFSOvQ for ; Sat, 5 Jul 2014 05:47:50 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F141A04F1 for ; Sat, 5 Jul 2014 05:47:50 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id hy10so2365121vcb.17 for ; Sat, 05 Jul 2014 05:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=IZxo+4cdpMSC2+Vn0AJGLjBWtNbY8Sq+u7iWlRaIqAw=; b=KuJXwcfKWRP5uafD0++sDELvMb9bK0mmrmEqe2VPJtXfUO14NR71089OCJ+vVKayFr 30x7v9bizYjUYh5jmjP7WINwP48g/mu+qUsXLFgAcDWXUDTEfMoijFRySkHopG6DV39R M1xY2XEMgspVKmHJteIX8Y5qvbTyT9339iCJQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=IZxo+4cdpMSC2+Vn0AJGLjBWtNbY8Sq+u7iWlRaIqAw=; b=F65tbOjwz3pCoHTP60JUeoKZ055nl7Vq9uOz697zghRD/E6LpJaviNDgLnLku20O/9 1wvvrEPvxJ2txDfzfCIez9upYoHZ2BJnQkSKg8QrjJ0lMezYefG+9khkrqy387/wWPu9 NC5ac4uSmzEhu+PYn8ifcqavh21AntPfKJFvUaFSmUh/quIhTggx2wExUGFLNT27d9Nm NW/GdCaxACdt+1cuoLfyvjIbq+3LWXxvd5bDzPb7FHbqWDYti2pyQE8bV6bw1d9eaGCg /qzEMbWVsDec0cFsuZz86pqh1c8qyEKoFgfzjXqSLae6V/hzhm+16ueBZHhxHFP1yzYo 2pgQ== X-Gm-Message-State: ALoCoQl2ygCsIMN4V746HBhWkeexnSbSLZE8+fLYzBBro1VRM57IDBcZNtR3I+ppsPYVkuQiDjLo X-Received: by 10.58.153.4 with SMTP id vc4mr14558367veb.19.1404564469642; Sat, 05 Jul 2014 05:47:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.108.164 with HTTP; Sat, 5 Jul 2014 05:47:29 -0700 (PDT) From: Tom Ritter Date: Sat, 5 Jul 2014 08:47:29 -0400 Message-ID: To: Watson Ladd Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uOvyjruM2ISNWaPdihmR4nzSPnw Cc: "tls@ietf.org" Subject: [TLS] 'Type B' Extensions (was Re: Pull request for 1RTT Handshake) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 12:47:51 -0000 On 4 July 2014 23:30, Watson Ladd wrote: > Also, I don't recall having seen > 'type B extensions': what was the rationale? How was the answer going > to come back?) They've not been mentioned before because they haven't really been presented for discussion. They're buried in here: http://www.ietf.org/proceedings/interim/2014/05/15/tls/slides/slides-interim-2014-tls-1-4.pdf and they're not that important right now, in comparison to other changes like 1RTT and eSNI. The idea was that since we're going to be encrypting half the handshake starting with a Server-> Client message, we could make extensions that are protected entirely against a passive adversary by making them 'Server Offers, Client Accepts'. Some of the extensions we have could work that way, some could not. -tom From nobody Sun Jul 6 13:54:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B538C1A0AA3 for ; Sun, 6 Jul 2014 13:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bH7oQH5SW-w for ; Sun, 6 Jul 2014 13:54:07 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47CC91A0AA2 for ; Sun, 6 Jul 2014 13:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1360; q=dns/txt; s=iport; t=1404680047; x=1405889647; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=VTk0MrUnGAnk09bIImPrpuN+3n22/ZOc/KnPGSF72og=; b=mACKTuIScXYqwLQQxjuQlDyTLO/uimTvPcpiPDUUP0/CePim/M2BdSf/ MHFOqWpyyve6P2lZhpBz1pn7GvNfmw9zAkDq9lp/AFlmQ00BGw+4XY6Ch bm9P2ElbNoI7sRo04GTBpbBI2HMMNbE9kVyUw39hmK1iRRNkuEESY+qjg 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFAMS2uVOtJV2Q/2dsb2JhbABagw5SWsVZgWAWdYQKOiwlAT5CJwQciDkNoGeoTReSVoEWBZp2lAyDQ4Iw X-IronPort-AV: E=Sophos;i="5.01,613,1400025600"; d="scan'208";a="338073788" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-6.cisco.com with ESMTP; 06 Jul 2014 20:54:06 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s66Ks6UI032002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 6 Jul 2014 20:54:06 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Sun, 6 Jul 2014 15:54:06 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Draft agenda for interim and IETF-90 Thread-Index: AQHPmVxsoGyJ9CJsPUuTWJi/aDX7Xg== Date: Sun, 6 Jul 2014 20:54:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.49] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_vXOiEg249NZwIdsm8cW6zAeuLk Subject: [TLS] Draft agenda for interim and IETF-90 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 06 Jul 2014 20:54:08 -0000 The draft agenda for the Interim and TLS sessions at IETF-90 has been uploa= ded and is copied below. =20 Cheers, Joe Sunday July 20, 2014 (TLS Interim Meeting) Mozilla Toronto [1] Toronto, ON, Canada ------ 10:00 - 10:15 Administrivia (Chairs) 10:15 - 11:45 1RTT Handshake Flow (EKR) 11:45 - 13:00 Lunch 13:00 - 14:00 Renegotiation/rekey/client auth (MT) 14:00 - 14:30 Content Type Encryption (DKG) 14:30 - 14:45 Break 14:45 - 15:30 SNI encryption (DKG) 15:30 - 16:00 [Unassigned] Monday July 21, 2014 (IETF 90 TLS Meeting - Session 1) Fairmont Royal York - Ontario C Toronto, ON, Canada ------ 15:20 - 15:35 Blue sheets/scribes/etc. (chairs) 15:35 - 15:45 WG Document Status (chairs) 15:45 - 16:00 ECC to Standards Track/MTI (all) 16:15 - 16:35 ChaCha/Poly1305 (AGL) 16:35 - 16:50 SCSV/Downgrade (AGL) Thursday July 24, 2014 (IETF 90 TLS Meting - Session 2) Fairmont Royal York - Ontario C --------=20 17:30 - 17:35 Blue sheets/scribes/etc. (chairs) 17:35 - 18:00 New curves: =20 Report from CFRG (CFRG Chairs) Discussion 18:00 - 18:15 Named Curves (DKG) 18:15 - 18:30 AOB [1] Mozilla Toronto http://www.mozilla.org/en-US/contact/spaces/toronto/ 366 Adelaide St W, Suite 500 Toronto, ON M5V 1R9 Canada= From nobody Mon Jul 7 05:49:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FAB1B284A for ; Mon, 7 Jul 2014 05:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.352 X-Spam-Level: X-Spam-Status: No, score=-1.352 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sxqofCejpNm for ; Mon, 7 Jul 2014 05:49:04 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A971B1B2845 for ; Mon, 7 Jul 2014 05:49:04 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id BCC9F1A0091; Mon, 7 Jul 2014 14:48:58 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pXtIXdh_Odvb; Mon, 7 Jul 2014 14:48:53 +0200 (CEST) Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id 7EAC21A0066; Mon, 7 Jul 2014 14:48:53 +0200 (CEST) Received: from [10.53.40.204] (port=50437 helo=mail-essen-01.secunet.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1X48Lm-00028y-PF; Mon, 07 Jul 2014 14:48:54 +0200 Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 7 Jul 2014 14:48:54 +0200 Message-ID: <53BA9735.5040903@secunet.com> Date: Mon, 7 Jul 2014 14:48:53 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Watson Ladd References: <53AC97B8.2080909@nthpermutation.com> <53AD134E.9010903@akr.io> <53B6C159.7010002@secunet.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.76] Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zJbuEKfQ0de0FmCwuv3EK_0n9oc Cc: "tls@ietf.org" Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2014 12:49:07 -0000 Watson Ladd wrote on 04.07.2014 17:15: > Twist security matters for Joyce-Briers ladders only, as far as I know > on Weierstrass curves. Other formulas use the y coordinates. Exactly, and as DJB points out, the Joyce-Briers ladder "requires 19 field operations per bit, many more field operations than standard addition chains for short Weierstrass curves" [1]. Therefore, "twist security" is irrelevant for Weierstrass curves unless someone decides to implement the Joyce-Briers ladder despite of its inferior performance. I was objecting to Alyssa's statement "in the case of Brainpool, the 256-bit curve has extremely unfortunate lack of twist security", which, IMHO, grossly exaggerates the importance of twist security. Lack of "twist security" is an issue for Weierstrass curves only in circumstances where implementors choose an unusual technique and screw up one essential part. [1] http://safecurves.cr.yp.to/ladder.html -- Johannes From nobody Mon Jul 7 05:56:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D101A000D for ; Mon, 7 Jul 2014 05:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSVcYopRtRlQ for ; Mon, 7 Jul 2014 05:56:30 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02F11A0008 for ; Mon, 7 Jul 2014 05:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1404737790; x=1436273790; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=zZWV26+UgHARfrfuKxy4YbKJ78MK6L0eCucs8gX8spM=; b=b4ogRQzgXnTsqMiWp9x+RFIxlilfTyAYA1QUYLdV3ChG164uCS8qWzOT 77/B39jt7s6ObQdfmmu1CU0NpO3gZ0xZ1tUilyQacQoWRg3m3QTgb0Rkt 172abZJTLFDzZr17u5cExd2ATc0d66MSeEtYRAnwByN1J+7q4Qv703OrH 8=; X-IronPort-AV: E=Sophos;i="5.01,618,1399982400"; d="scan'208";a="262383196" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 08 Jul 2014 00:56:28 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.9]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Tue, 8 Jul 2014 00:56:28 +1200 From: Peter Gutmann To: "" Thread-Topic: Revising RFC 6090 Thread-Index: Ac+Z4t0O/NqhptzLQySy2lHk4UaFzA== Date: Mon, 7 Jul 2014 12:56:26 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738DED4B19@uxcn10-tdc06.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_l2D_nLu-xJUaObKUM2IFYQqpoQ Subject: Re: [TLS] Revising RFC 6090 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2014 12:56:35 -0000 Paul Hoffman writes:=0A= =0A= >This seems like a good time to revisit RFC 6090 to incorporate the errata = and=0A= >to start to consider what else can be added to the document.=0A= =0A= Speaking of ECC drafts, I've posted an updated version of my ECC ciphersuit= es=0A= draft, now with the Brainpool curves added:=0A= =0A= http://tools.ietf.org/html/draft-gutmann-tls-eccsuites-06=0A= =0A= Peter.= From nobody Mon Jul 7 06:14:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689CF1A0016 for ; Mon, 7 Jul 2014 06:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydFxcZWbw6lJ for ; Mon, 7 Jul 2014 06:14:15 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA671A000F for ; Mon, 7 Jul 2014 06:14:14 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: <53B6C159.7010002@secunet.com> References: <53AC97B8.2080909@nthpermutation.com> <53AD134E.9010903@akr.io> <53B6C159.7010002@secunet.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Alyssa Rowan Date: Mon, 07 Jul 2014 14:14:10 +0100 To: tls@ietf.org Message-ID: <3ba0acce-d784-423b-9d6f-fccda1f183aa@email.android.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0zExTZPOwq4AfT3faIcblbIKuoY Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2014 13:14:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Well, yes - combined with an unusual ladder choice (which one might choose for constant-time, albeit not the best choice now) and a critical but easily-overlooked omission. I appreciate there's not much we can do about implementers screwing up badly - but if we do have two primitives of about equal value and one fails catastrophically to a simple mistake that another does not, then as a matter of defence in depth, I'd generally prefer the more resilient one? So it is with Brainpool: its twist security is poof (by pure chance) so such a mistake would be more hazardous than is typical. How likely that mistake would be is another matter, and I accept your point there that it'd be a rare decision and hopefully would be noticed in any review. I still don't think Brainpool's fast enough to drive adoption, next to competition like 25519 and the Microsoft curves. On 4 July 2014 15:59:37 BST, Johannes Merkle wrote: >> in the case of Brainpool, the 256-bit curve has extremely unfortunate lack of twist security, so any implementation that tries to skip validation is in really big trouble. >Why should anyone try to skip validation? In order to improve performance by less than 1%? - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI3BAEBCgAhBQJTup0iGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t68NkP/0qjbLVNew9lCT1tUGTvsPvUsJS/WqY8JWsMfQTQJQR0mpgICIwJ /QQ3Ocawx0Ume/WyEVo8uKOAhI/svhLEpHulQMxnq0C/RJZQXFLjRxd9E9w2jayZ ZbU/BKw3BWdRG1oWJx6SvTNdYlcsvqhuIPbUXodG/ALrboVKDqMymfo6qSmk7kdV T9v+jYqpST40Vkn3oqjGwn1nA6rqOAe2p9ouIWvaiC8hVu1R9VW5utHSSfFeBIFY Uh9rLnaNoUh9UK4JUCWguql7qRWwjCwy1ZAfzPQ3Iy9pVS8oWJfQ2WQfwcLo5OSr iilV2D1Wrk6w7C3F1LH4dsj2bTmEm2ccXTy3jVWq3AUXqlWbxOHIFtsI2V853VFR qTvwcKb6K2ITqrbxCnSdBwhxu0GN2nxeekB8wa26xXuyfKd9JR3YzPnB/LCIOfS8 x4PBmm5/c/9uvif9x4+rGY6xRiu1uAQOfKgwr4QzzOKLe7km8pQ98gyoiqqrl9CJ czld1JooEi8Vb3+MbGfFTmpB9KjCLsCzjdXiBylSy+k0pelVPF3em22e2aOS7uxI qwi+/vmO9aNVdYdU/0pQ3GTayGouci7is+JTm4qpt2MQSLQfI7N4xzeAIQuTiKXv FIn+5c9gLVsZQTAbR4VPoJC20SlQ+eb4pYOLnfA17xRcZTO+6uAAgh1n =l0jv -----END PGP SIGNATURE----- From nobody Mon Jul 7 07:53:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D150C1A01E1 for ; Mon, 7 Jul 2014 07:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4k4C1UgChT9 for ; Mon, 7 Jul 2014 07:53:28 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D55B1A01F1 for ; Mon, 7 Jul 2014 07:53:28 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id C597B1A0099 for ; Mon, 7 Jul 2014 16:53:24 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6ZPtFdTfJeyC for ; Mon, 7 Jul 2014 16:53:16 +0200 (CEST) Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id 43E751A0096 for ; Mon, 7 Jul 2014 16:53:16 +0200 (CEST) Received: from [10.53.40.204] (port=60893 helo=mail-essen-01.secunet.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1X4AI9-0005h3-Eo for ; Mon, 07 Jul 2014 16:53:17 +0200 Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 7 Jul 2014 16:53:17 +0200 Message-ID: <53BAB45C.7040603@secunet.com> Date: Mon, 7 Jul 2014 16:53:16 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: References: <53AC88F2.7020405@cs.bris.ac.uk> In-Reply-To: <53AC88F2.7020405@cs.bris.ac.uk> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.208.1.76] Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RKkDDzly-BEy-zcZExsAmqFFBPo Subject: Re: [TLS] [Cfrg] FW: Schnorr Signatures X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2014 14:53:32 -0000 Nigel Smart wrote on 26.06.2014 22:56: > With Schnorr you dont send the x-coord of R. What you send is > half the hash value e > e=Hash(R||Message) > So if using SHA-256 you send 128 bits of e over. Actually, the Schnorr signature is defined as using the full hash value, but it has been repeatedly proposed (originally by Schnorr himself) to use a half-length hash function (and that could be truncated SHA-256). However, as you pointed out in [1], the security proofs you mentioned do not work with reduced hash length h=b AND standard group order g = 2^(2b) for security level b. Your proof in the generic model [1] requires h=2*b and the proof of Pointcheval and Stern in the Random oracle model [2] needs g=2^(3b). Thus, when using half-length hash values you sacrifice provable security. [1] Gregory Neven, Nigel P. Smart, and Bogdan Warinschi. Hash function requirements for schnorr signatures. J. Mathematical Cryptology, 3(1):69–87, 2009 [2] David Pointcheval and Jacques Stern. Security arguments for digital signatures and blind signatures. Journal of Cryptology, 13(3):361–396, March 2000. -- Johannes From nobody Mon Jul 7 08:01:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68161A0208 for ; Mon, 7 Jul 2014 08:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4OimLcPCmwT for ; Mon, 7 Jul 2014 08:01:05 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74C501A01E1 for ; Mon, 7 Jul 2014 08:01:05 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u57so4560126wes.19 for ; Mon, 07 Jul 2014 08:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=9PGr9ciCJUoEBAjNyiV64OjhCF97PPxHYuLhdH5g84s=; b=Jbp5Ehv1zq2cayOKJuzagdPx14p+rw1JgTnaHR3o5AWmrdzuKCdYKcbLUUAiDIQUsb XKNZDoSdCgiXgBfcYnY371TJ+FiwCObbwkiref5YVYPW9z0oHguIOAv9FWUlTb7DsjHx +8E2REg/0+PmafyKJRuHSgGVVuxDTxTx5mNfLKO2kW+OfdwWj7iYEMOhYPeFmUMECAC+ 0zHkEoLe6ft+Lp13YHe2Y1u60uB5n3kSIyrVx++PVYGl9f/m9+D1Q+L4jNzItzcgXx08 XILa8DX8zKQFhdPG3Fl7gU/7q0U/cO9XCRRrdMuB0+dKeTFhnD5ZObjjRtugVGXp9VZo 0IzA== MIME-Version: 1.0 X-Received: by 10.194.219.70 with SMTP id pm6mr32575862wjc.53.1404745263391; Mon, 07 Jul 2014 08:01:03 -0700 (PDT) Received: by 10.194.21.69 with HTTP; Mon, 7 Jul 2014 08:01:03 -0700 (PDT) Received: by 10.194.21.69 with HTTP; Mon, 7 Jul 2014 08:01:03 -0700 (PDT) In-Reply-To: <53BAB45C.7040603@secunet.com> References: <53AC88F2.7020405@cs.bris.ac.uk> <53BAB45C.7040603@secunet.com> Date: Mon, 7 Jul 2014 08:01:03 -0700 Message-ID: From: Watson Ladd To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a11c1b31c6ca99804fd9bbe2b Archived-At: http://mailarchive.ietf.org/arch/msg/tls/s_Ug2e-I6wDdrHChA2WTk8IRyOo Subject: Re: [TLS] [Cfrg] FW: Schnorr Signatures X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2014 15:01:07 -0000 --001a11c1b31c6ca99804fd9bbe2b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Jul 7, 2014 7:53 AM, "Johannes Merkle" wrote: > > Nigel Smart wrote on 26.06.2014 22:56: > > With Schnorr you dont send the x-coord of R. What you send is > > half the hash value e > > e=3DHash(R||Message) > > So if using SHA-256 you send 128 bits of e over. > > Actually, the Schnorr signature is defined as using the full hash value, but it has been repeatedly proposed (originally > by Schnorr himself) to use a half-length hash function (and that could be truncated SHA-256). > > However, as you pointed out in [1], the security proofs you mentioned do not work with reduced hash length h=3Db AND > standard group order g =3D 2^(2b) for security level b. Your proof in the generic model [1] requires h=3D2*b and the proof > of Pointcheval and Stern in the Random oracle model [2] needs g=3D2^(3b). Thus, when using half-length hash values you > sacrifice provable security. While the Pointcheval and Stern result is not tight, no one has made attacks that do better. The most compact and performant variant sends R and S. R is the size of a group element, S the size of order of the group. This way the length of what is to be transmitted does not depend on the hash used. > > > [1] Gregory Neven, Nigel P. Smart, and Bogdan Warinschi. Hash function requirements for schnorr > signatures. J. Mathematical Cryptology, 3(1):69=E2=80=9387, 2009 > > [2] David Pointcheval and Jacques Stern. Security arguments for digital signatures and blind signatures. > Journal of Cryptology, 13(3):361=E2=80=93396, March 2000. > > > -- > Johannes > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --001a11c1b31c6ca99804fd9bbe2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jul 7, 2014 7:53 AM, "Johannes Merkle" <johannes.merkle@secunet.com> wrote:
>
> Nigel Smart wrote on 26.06.2014 22:56:
> > With Schnorr you dont send the x-coord of R. What you send is
> > half the hash value e
> > =C2=A0 =C2=A0 e=3DHash(R||Message)
> > So if using SHA-256 you send 128 bits of e over.
>
> Actually, the Schnorr signature is defined as using the full hash valu= e, but it has been repeatedly proposed (originally
> by Schnorr himself) to use a half-length hash function (and that could= be truncated SHA-256).
>
> However, as you pointed out in [1], the security proofs you mentioned = do not work with reduced hash length h=3Db AND
> standard group order g =3D 2^(2b) for security level b. Your proof in = the generic model [1] requires h=3D2*b and the proof
> of Pointcheval and Stern in the Random oracle model [2] needs g=3D2^(3= b). Thus, when using half-length hash values you
> sacrifice provable security.

While the Pointcheval and Stern result is not tight, no one = has made attacks that do better.

The most compact and performant variant sends R and S. R is = the size of a group element, S the size of order of the group. This way the= length of what is to be transmitted does not depend on the hash used.
>
>
> [1] Gregory Neven, Nigel P. Smart, and Bogdan Warinschi. Hash function= requirements for schnorr
> signatures. J. Mathematical Cryptology, 3(1):69=E2=80=9387, 2009
>
> [2] David Pointcheval and Jacques Stern. Security arguments for digita= l signatures and blind signatures.
> Journal of Cryptology, 13(3):361=E2=80=93396, March 2000.
>
>
> --
> Johannes
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

--001a11c1b31c6ca99804fd9bbe2b-- From nobody Mon Jul 7 09:00:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D156D1A033C for ; Mon, 7 Jul 2014 09:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZ1R5jLns9T6 for ; Mon, 7 Jul 2014 09:00:20 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63A81A0305 for ; Mon, 7 Jul 2014 09:00:18 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 3B7AE1A0096; Mon, 7 Jul 2014 18:00:16 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Tn8f57H3tJ1q; Mon, 7 Jul 2014 18:00:07 +0200 (CEST) Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id 7A3E31A0097; Mon, 7 Jul 2014 18:00:04 +0200 (CEST) Received: from [10.53.40.204] (port=36950 helo=mail-essen-01.secunet.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1X4BKn-0007a7-NJ; Mon, 07 Jul 2014 18:00:05 +0200 Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 7 Jul 2014 18:00:05 +0200 Message-ID: <53BAC405.1000000@secunet.com> Date: Mon, 7 Jul 2014 18:00:05 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alyssa Rowan , References: <53AC97B8.2080909@nthpermutation.com> <53AD134E.9010903@akr.io> <53B6C159.7010002@secunet.com> <3ba0acce-d784-423b-9d6f-fccda1f183aa@email.android.com> In-Reply-To: <3ba0acce-d784-423b-9d6f-fccda1f183aa@email.android.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.76] Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oQ2YhPvXTXhyq7txIK1wlLFcj_k Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2014 16:00:23 -0000 Alyssa Rowan wrote on 07.07.2014 15:14: > Well, yes - combined with an unusual ladder choice (which one might choose for constant-time, albeit not the best > choice now) and a critical but easily-overlooked omission. > > I appreciate there's not much we can do about implementers screwing up badly - but if we do have two primitives of > about equal value and one fails catastrophically to a simple mistake that another does not, then as a matter of > defence in depth, I'd generally prefer the more resilient one? > > So it is with Brainpool: its twist security is poof (by pure chance) so such a mistake would be more hazardous than > is typical. How likely that mistake would be is another matter, and I accept your point there that it'd be a rare > decision and hopefully would be noticed in any review. > > I still don't think Brainpool's fast enough to drive adoption, next to competition like 25519 and the Microsoft > curves. In this discussion, it is important to focus on the most essential arguments. "Twist security" is not among them, as it only applies to very special cases and poor implementations. Montgomery and Edwards curves have other potential problems due the non-trivial co-factor, so there is always something a sloppy implementor can screw up. Computational performance is a valid argument, and where performance is your main criteria, your may go for special primes and non-Weierstrass curves; but there are sufficient circumstances, where performance is not the principal criteria. IMHO, it is wise to maintain curves with different properties to accommodate different demands. -- Johannes From nobody Mon Jul 7 09:06:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C461A02FE for ; Mon, 7 Jul 2014 09:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGu6fFekwALX for ; Mon, 7 Jul 2014 09:06:49 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0F971A033D for ; Mon, 7 Jul 2014 09:06:48 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s67G6h6Q021192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Jul 2014 18:06:43 +0200 (MEST) In-Reply-To: To: Eric Rescorla Date: Mon, 7 Jul 2014 18:06:43 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140707160643.98F421AD93@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5cWfoXoJXcIJDKJBz3MoHVEEfgg Cc: IETF TLS WG Subject: Re: [TLS] proposal to encrypt ContentType for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 16:06:51 -0000 Eric Rescorla wrote: [ Charset UTF-8 unsupported, converting... ] > Daniel Kahn Gillmor > wrote: >> >> i just opened a pull request to propose that the TLS ContentType (when >> actually using a proper cipher) should itself be encrypted, rather than >> in the clear: >> >> If this change is made, it's also relatively easy to just drop the TLS >> version field for each encrypted TLS record layer fragment. This version field is sometimes helpful for debugging, and using the same formatting of the record contents (clear vs. decrypted) means less code complexity. > > This seems like an idea with a fair bit of merit, but if I understand > correctly, it's going to result in a stream of data which cannot be > parsed into TLS records by existing network elements. > I'm concerned about how this is going to interact with various > elements which process the ciphertext. There are also going to be problems with implementations where the records are read from network in their entirety before being passed to and processed by the TLS implementation, and where that network i/o state machine is currently using the record type to indicate to higher layers whether the handshake is still ongoing. It's also helpful to see in wireshark traces whether a connection was terminated by a TLS alert, or whether it may have been interrupted by some middlebox or other networking problem. What would be the purpose/benefit of this in case that renegotiation gets dropped? Such a change at the record layer would reliably preculde that we ever ship TLSv1.3, because a 2 years ago I've switched to doing all network i/o outside of the TLS stack and parsing the records above TLS so that we can arbitrarily mix non-blocking I/O with precise application- defined network timeouts. -Martin From nobody Mon Jul 7 09:08:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44EF41A035A for ; Mon, 7 Jul 2014 09:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GNlN9Cfyrda for ; Mon, 7 Jul 2014 09:08:36 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7025E1A0357 for ; Mon, 7 Jul 2014 09:08:36 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s67G8L51027064; Mon, 7 Jul 2014 12:08:33 -0400 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: "Blumenthal, Uri - 0668 - MITLL" In-Reply-To: <53BAC405.1000000@secunet.com> Date: Mon, 7 Jul 2014 12:08:12 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <53AC97B8.2080909@nthpermutation.com> <53AD134E.9010903@akr.io> <53B6C159.7010002@secunet.com> <3ba0acce-d784-423b-9d6f-fccda1f183aa@email.android.com> <53BAC405.1000000@secunet.com> To: Johannes Merkle X-Mailer: Apple Mail (2.1510) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-07_02:2014-07-07,2014-07-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407070182 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GbolVVgw3bVeW3u4ot21ShyL5Bg Cc: tls@ietf.org Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2014 16:08:38 -0000 On Jul 7, 2014, at 12:00 , Johannes Merkle = wrote: > Alyssa Rowan wrote on 07.07.2014 15:14: >> ......I appreciate there's not much we can do about implementers = screwing up badly - but if we do have two primitives of about equal = value and one fails catastrophically to a simple mistake that another = does not, then as a matter of defense in depth, I'd generally prefer the = more resilient one?..... > In this discussion, it is important to focus on the most essential = arguments. "Twist security" is not among them, as it only applies to = very special cases and poor implementations. Montgomery and Edwards = curves have other potential problems due the non-trivial co-factor, so = there is always something a sloppy implementor can screw up. >=20 > Computational performance is a valid argument, and where performance = is your main criteria, your may go for special primes and = non-Weierstrass curves; but there are sufficient circumstances, where = performance is not the principal criteria. IMHO, it is wise to maintain = curves with different properties to accommodate different demands. +1 From nobody Mon Jul 7 09:10:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83871A0342 for ; Mon, 7 Jul 2014 09:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxJqFSIOpCNp for ; Mon, 7 Jul 2014 09:10:23 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A44351A02F1 for ; Mon, 7 Jul 2014 09:10:18 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id D069E1A0097; Mon, 7 Jul 2014 18:10:15 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8nCvd4WxGqnv; Mon, 7 Jul 2014 18:10:10 +0200 (CEST) Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id C0B3E1A0066; Mon, 7 Jul 2014 18:10:10 +0200 (CEST) Received: from [10.53.40.204] (port=15219 helo=mail-essen-01.secunet.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1X4BUa-0007o3-1y; Mon, 07 Jul 2014 18:10:12 +0200 Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 7 Jul 2014 18:10:11 +0200 Message-ID: <53BAC663.2090401@secunet.com> Date: Mon, 7 Jul 2014 18:10:11 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Watson Ladd , References: <53AC88F2.7020405@cs.bris.ac.uk> <53BAB45C.7040603@secunet.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.76] Archived-At: http://mailarchive.ietf.org/arch/msg/tls/H2KLZrXO5F4DqcQtS-2VqNj3xrE Subject: Re: [TLS] [Cfrg] FW: Schnorr Signatures X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2014 16:10:27 -0000 Watson Ladd wrote on 07.07.2014 17:01: > > On Jul 7, 2014 7:53 AM, "Johannes Merkle" > wrote: >> >> Nigel Smart wrote on 26.06.2014 22:56: >> > With Schnorr you dont send the x-coord of R. What you send is >> > half the hash value e >> > e=Hash(R||Message) >> > So if using SHA-256 you send 128 bits of e over. >> >> Actually, the Schnorr signature is defined as using the full hash value, but it has been repeatedly proposed (originally >> by Schnorr himself) to use a half-length hash function (and that could be truncated SHA-256). >> >> However, as you pointed out in [1], the security proofs you mentioned do not work with reduced hash length h=b AND >> standard group order g = 2^(2b) for security level b. Your proof in the generic model [1] requires h=2*b and the proof >> of Pointcheval and Stern in the Random oracle model [2] needs g=2^(3b). Thus, when using half-length hash values you >> sacrifice provable security. > > While the Pointcheval and Stern result is not tight, no one has made attacks that do better. I didn't mean to imply that loosing the security proof makes the scheme insecure. But we have the choice (for 128 bit security level): 1. Use the provably secure version with signature length of 64 byte 2. Use an optimized version without security proof giving signature length of 48 byte. > > The most compact and performant variant sends R and S. R is the size of a group element, S the size of order of the > group. This way the length of what is to be transmitted does not depend on the hash used. Hmmm, by Hasse's theorem and for moderate co-factors, the size of the group roughly equals the size of the group elements. Thus, this variant has about the same signature length as the original version (64 byte for 128 bit security). Or do I miss something? -- Johannes From nobody Mon Jul 7 10:30:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B401A0377 for ; Mon, 7 Jul 2014 10:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjtIkiOFDjj4 for ; Mon, 7 Jul 2014 10:30:03 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED12E1A040D for ; Mon, 7 Jul 2014 10:30:02 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id c11so3129793lbj.17 for ; Mon, 07 Jul 2014 10:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=2N68rG3s28IXjzB76Qh88sc0JerITpo7Brwng2+uFqU=; b=Abme7LBY37PFOddm6a1fGIjtcNhDYR8v0mHuTDdsFBqJNq9IG1XtS7Ni5pg2mNwLPr pQK6cpZvnhssGLUbob264w8lhq6n6I1b0f03zAjK0Wgu4OUqAZZ/omd2PAfVWw2GyrSO 6NzaMQ8sl/C2P2kKqZgc5uh00Hq7Ql0uL20GIp/8f+GUakk8YDx8nGUqLyYA1EPnzX+o aKuaXIZYb8eH9h2MQi+Z4tKUL0BdUelMNfcKTGA6QImvDSILynP1nC6L9i93AWX36BIn U8S/VfijgVGdoEF2aiaqhRRw6GOxFamQgDveH/wOxzSIwzAJOLKo6Dx/WLVlt9B55HW+ pXbQ== MIME-Version: 1.0 X-Received: by 10.112.143.8 with SMTP id sa8mr2320902lbb.89.1404754201213; Mon, 07 Jul 2014 10:30:01 -0700 (PDT) Received: by 10.112.29.173 with HTTP; Mon, 7 Jul 2014 10:30:01 -0700 (PDT) Date: Mon, 7 Jul 2014 19:30:01 +0200 Message-ID: From: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jOatM4mZ8FeZlK4GWZB4K6utkaE Subject: Re: [TLS] draft-gutmann-tls-eccsuites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2014 17:30:04 -0000 Hi Peter et al. On Mon, Jul 7, 2014 at 2:56 PM, Peter Gutmann w= rote: > Speaking of ECC drafts, I've posted an updated version of my ECC ciphersu= ites > draft, now with the Brainpool curves added: > > http://tools.ietf.org/html/draft-gutmann-tls-eccsuites-06 Hmm... >From the above draft section 2: | If no additional Chinese-menu ECC suites are used, implementations | SHOULD NOT send the Supported Elliptic Curves or Supported Point | Formats extensions since these parameters are fully specified by the | suite choice. Have you considered the following note in RFC 4492 section 5.1? | NOTE: A server participating in an ECDHE-ECDSA key exchange may use diffe= rent | curves for (i) the ECDSA key in its certificate, and (ii) the ephemeral ECDH key in the | ServerKeyExchange message. The server must consider the extensions in both cases. As I read the above, your suites would default to imply extra restrictions on the possible server certificates, as you would be restricted to only the same curve as in the suite (eg you wouldn't be able to use a SECP521 cert with TLS_ECDHE_ECDSA_P384_SHA384_WITH_AES_256_GCM_SHA384, as the server wouldn't know if the client was capable of verifying the cert). The server can probably safely assume that the client supports certificates for all the curves in the client hello suites, but this doesn't help with certs using curves not in the list of suites in the draft. Or is the intent of the draft that the server just should select a cert and hope for the best? Anyway, the intended ECDSA certificate policy ought to be made explicit in the draft. /grubba -- Henrik Grubbstr=C3=B6m grubba@grubba.= org Roxen Internet Software AB grubba@roxen.com From nobody Mon Jul 7 10:50:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530601B281E for ; Mon, 7 Jul 2014 10:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTcvHcdihy3i for ; Mon, 7 Jul 2014 10:50:19 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52CDB1A0AA0 for ; Mon, 7 Jul 2014 10:50:19 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id DDBEC33D1D6; Mon, 7 Jul 2014 17:50:18 +0000 (UTC) Sender: geoffk@localhost.localdomain To: mrex@sap.com References: <20140707160643.98F421AD93@ld9781.wdf.sap.corp> From: Geoffrey Keating Date: 07 Jul 2014 10:50:18 -0700 In-Reply-To: <20140707160643.98F421AD93@ld9781.wdf.sap.corp> Message-ID: Lines: 23 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SYP5mMXjVju_Zo8EAS9G1cJ1h8U Cc: IETF TLS WG Subject: Re: [TLS] proposal to encrypt ContentType for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 17:50:22 -0000 mrex@sap.com (Martin Rex) writes: > Eric Rescorla wrote: > [ Charset UTF-8 unsupported, converting... ] > > Daniel Kahn Gillmor > wrote: > >> > >> i just opened a pull request to propose that the TLS ContentType (when > >> actually using a proper cipher) should itself be encrypted, rather than > >> in the clear: > >> > >> If this change is made, it's also relatively easy to just drop the TLS > >> version field for each encrypted TLS record layer fragment. > > This version field is sometimes helpful for debugging, and > using the same formatting of the record contents (clear vs. decrypted) > means less code complexity. I'd be happy with dropping the version field for everything beyond the first ServerHello. That should help a bit with code complexity---ClientHello is already quite special and for ServerHello it will be the second and third bytes sent on the connection so can be handled as an exception ("read the first three bytes, process version number, stuff byte 0 back into the queue"). From nobody Mon Jul 7 13:30:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4201B28E3 for ; Mon, 7 Jul 2014 13:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5llo98vSiQqH for ; Mon, 7 Jul 2014 13:30:03 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49C031B28F3 for ; Mon, 7 Jul 2014 13:30:03 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id l18so2305812wgh.30 for ; Mon, 07 Jul 2014 13:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hcyBhTgBLmJ301wsSiLXOqK49Qse06/bVdH1zeSxy4s=; b=MT81n0K5ayyu8wlEvbyq3AAS9VDRBbq+LXfXDVHg4YVem5aHgmA2kMdDUY/GAa7prw VS7PB4I757av9Al+7jFlXZveR1ViCmKIZel+9vc1uckbDn3+VStJTSB0eFLd/bRxKk+b zDI0zXn0mxYBQY0ah1bixr0OTG1YQEtTdbwU3tI59+L1Qi5L0aA7AuLaDJhcZqDd40Dh FWVuhm2IEad8r4JxAcmj/51N5hdmHLzw8Tfu7lilCH/pN9EMD0IGG+q3sIK3ifmGezw6 Zyz/hN2gbIbyQMp1eIOAMlkjotLSdIeavl40X54wpp03aJc33Ibgc+zid1zYoPpzTfIg AnIQ== X-Received: by 10.180.75.75 with SMTP id a11mr77146601wiw.3.1404765001885; Mon, 07 Jul 2014 13:30:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.38.82 with HTTP; Mon, 7 Jul 2014 13:29:41 -0700 (PDT) In-Reply-To: <53B331A5.2040908@fifthhorseman.net> References: <53B331A5.2040908@fifthhorseman.net> From: Fabrice Gautier Date: Mon, 7 Jul 2014 13:29:41 -0700 Message-ID: To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hxYua4IjWzOjz6POXzX6ieWq9d0 Cc: IETF TLS WG Subject: Re: [TLS] proposal to encrypt ContentType for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 20:30:12 -0000 If I'm reading this properly, there would be two types of records on the wire: TLSCiphertext and TLSPlaintext. However, I don't see a very reliable, documented way to distinguish between the two on the wire. I assume that the intention is to distinguish based on the state of the TLS handshake. i.e.: the record until the first CCS (included) are TLSPlaintext records, the ones after that are TLSCiphertext records. I can see a couple scenario where this could be a problem: - In some case, the piece of code that does the parsing has no knowledge of the state of the TLS handshake (this is similar to Martin Rex objection, I think) - In DTLS, records maybe dropped, received out of order, received multiple times, etc, so TLSPlaintext and TLSCiphertext records aybe intermixed, without a clear switchover point. This would make efficient DTLS difficult. In practice, I note that, if the ProtocolVersion field stays, it would be fairly easy to disambiguate TLSCiphertext from TLSPlaintext based on the first byte, as long as the first byte of the version stays 0x3, and 0x3 is never a valid ContentType. Except in situations where the first byte is already overloaded (i.e.: RFC 5764). If the ProtocolVersion field is also removed, then there will be ambiguity between a TLSPlaintext record and a TLSCiphertext of a specific size. If the record format needs to change, I suggest allocating a new reserved ContentType to indicate TLS 1.3 records of all type, and have the actual content type in the encrypted portion. I guess that the resulting implementations would not be that different from what implementations have to do today to support SSL2 ClientHello records on the server side. (In that case you can tell SSL2 records because the first byte is 0x80 for SSL2) In any case, whatever the final TLS 1.3 record format(s) look like, I hope someone spend some time explaining how an implementer is supposed to reliably distinguish between the various types of records (SSL2, TLS 1.2, TLS 1.3) in both the TLS and DTLS scenarios. On Tue, Jul 1, 2014 at 3:09 PM, Daniel Kahn Gillmor wrote: > hey folks-- > > i just opened a pull request to propose that the TLS ContentType (when > actually using a proper cipher) should itself be encrypted, rather than > in the clear: > > https://github.com/tlswg/tls13-spec/pull/51 > > As the main commit in this request says: > >> Move Content Type inside encryption >> >> Previous versions of TLS have left the Content Type in the clear >> without justifying the exposure of this piece of information. >> >> This change moves the Content Type inside the encryption to protect >> its confidentiality. >> >> For backward compatibility during the initial handshake negotiation, >> we need to keep the type field at its original location on the wire >> for cleartext packets. This means redefining the NULL_NULL case to >> not simply be an pseudo-cipher that implements the identity >> transformation, but to explicitly state it as sending the TLSPlaintext >> struct directly over the wire. > > I'd be interested in feedback on this suggestion. > > Having the content-type encrypted would mean that TLS alerts, > handshakes, and application data would be indistinguishable from one > another to an observer, once a ChangeCipherSpec had taken place. > > This also opens the way to consider the creation of other content types > (e.g. "padded application data") without having to decide whether the > exposure of a novel ContentType to an observer is itself a risk. > > If this change is made, it's also relatively easy to just drop the TLS > version field for each encrypted TLS record layer fragment. > > All the best, > > --dkg > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Mon Jul 7 14:01:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DDC1B28D3 for ; Mon, 7 Jul 2014 14:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdXR1fcfMD8V for ; Mon, 7 Jul 2014 14:01:36 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA8A1A0456 for ; Mon, 7 Jul 2014 14:01:36 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id n12so3225445wgh.25 for ; Mon, 07 Jul 2014 14:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dJ7ilpX7o47+OGRuFvYGy7LXaSolpiIQZHu3vu0PrZc=; b=RatV4ODYH/fstVyBJsuastE82Wr0x8qtNaLwGnw1oTqopV4vQDBUqFBNqfiCHV9r9B dDiH4uqGZkDpTBVpKHarMWbyRsCFdJdOvgGtsIXr36eI6Z61n+u2M1/i4bN9N1WWthSg QNj4LiIvczuCswDHdhcqms1fY+BfQGCFqJdXozs7untNa5ye9u20wdgj5Jq3N3fqYElY 92rSgQ1RAL6M3OPP4KQuuCH21Ds+8clQ/rM1PF4Oa5WnqNyl8ETv3YtEmrMc+nYNfiz8 Aswj4Lti8pB7SKWWhOnm/rJpxfjLpogOj7Z4X0WUDloi1Zttb637oI9FqWx3NGXMGHI8 CbuQ== MIME-Version: 1.0 X-Received: by 10.180.210.239 with SMTP id mx15mr939944wic.65.1404766894794; Mon, 07 Jul 2014 14:01:34 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Mon, 7 Jul 2014 14:01:34 -0700 (PDT) In-Reply-To: References: <53B331A5.2040908@fifthhorseman.net> Date: Mon, 7 Jul 2014 14:01:34 -0700 Message-ID: From: Martin Thomson To: Fabrice Gautier Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ycx8AetJpQphB_NAq0vKo4HQnGM Cc: IETF TLS WG Subject: Re: [TLS] proposal to encrypt ContentType for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 21:01:37 -0000 On 7 July 2014 13:29, Fabrice Gautier wrote: > If I'm reading this properly, there would be two types of records on > the wire: TLSCiphertext and TLSPlaintext. > However, I don't see a very reliable, documented way to distinguish > between the two on the wire. TLSPlaintext records appear before a ChangeCipherSpec and TLSCiphertext records appears afterwards. That is pretty unambiguous. Yes, this does mean that it's going to be self-evident in individual frames, interpreted individually, which is exactly Martin Rex's objection. > - In DTLS, records maybe dropped, received out of order, received > multiple times, etc, so TLSPlaintext and TLSCiphertext records aybe > intermixed, without a clear switchover point. This would make > efficient DTLS difficult. Doesn't the explicit sequence number in DTLS do that job adequately? Yes, you don't know until you get the packet containing CCS (or a retransmit thereof), but there's a fairly narrow range of values where it could appear. From nobody Mon Jul 7 15:41:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925C21B28A5 for ; Mon, 7 Jul 2014 15:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVlieZIQkZH2 for ; Mon, 7 Jul 2014 15:41:42 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 200981B281C for ; Mon, 7 Jul 2014 15:41:41 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hi2so219091wib.0 for ; Mon, 07 Jul 2014 15:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CppT5t9V10Dqg/2BGauqE8XcmKeqMsks091AYUtW7h8=; b=PByFCJAaLm9PeQgspDi4862y8PETyzXmQzJvVYp3xy16BvCfz8lOlIapO9jD0DSBdx KFM2Srk6TpApRHukLO4hs9HT4soXtKwbyGZ2g4D1hTKM1SUOfC+QbLYHpJgzeugd4Xsg 36yMIpzWLswvsrvJyX3t6TH81B8+In+jjYITbhsZ7QscsbSvLXfS6hiVzvXC2WVxw8Cp q3gEhBV95BwzrNuEu+evblej7Rc8PVukkxp1fnP9D3d+Fg79fmezOxKCK2o1w96r3TMX 4xc2aBIE0GEk+9oZ4+1Jtb/eLYPpt+RDlGmteKeAO4bmPlarDcWVBN/taomCCceeT40S vXlQ== X-Received: by 10.194.110.161 with SMTP id ib1mr26718wjb.129.1404772900681; Mon, 07 Jul 2014 15:41:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.38.82 with HTTP; Mon, 7 Jul 2014 15:41:20 -0700 (PDT) In-Reply-To: References: <53B331A5.2040908@fifthhorseman.net> From: Fabrice Gautier Date: Mon, 7 Jul 2014 15:41:20 -0700 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rIhSAxkw6V7VoUvP1lcJF97HIIw Cc: IETF TLS WG Subject: Re: [TLS] proposal to encrypt ContentType for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 22:41:43 -0000 On Mon, Jul 7, 2014 at 2:01 PM, Martin Thomson wrote: > On 7 July 2014 13:29, Fabrice Gautier wrote: >> If I'm reading this properly, there would be two types of records on >> the wire: TLSCiphertext and TLSPlaintext. >> However, I don't see a very reliable, documented way to distinguish >> between the two on the wire. > > TLSPlaintext records appear before a ChangeCipherSpec and > TLSCiphertext records appears afterwards. That is pretty unambiguous. > > Yes, this does mean that it's going to be self-evident in individual > frames, interpreted individually, which is exactly Martin Rex's > objection. > >> - In DTLS, records maybe dropped, received out of order, received >> multiple times, etc, so TLSPlaintext and TLSCiphertext records aybe >> intermixed, without a clear switchover point. This would make >> efficient DTLS difficult. > > Doesn't the explicit sequence number in DTLS do that job adequately? > Yes, you don't know until you get the packet containing CCS (or a > retransmit thereof), but there's a fairly narrow range of values where > it could appear. How do you reliably get the sequence number out of the records, if you don't know which format is that record in ? By extension of the current proposal, I am assuming the DTLS records on the wire would look like this before CCS: type (1 byte) | version (2 bytes) | epoch (2 bytes) | seq_num (6 bytes) | length (2 bytes) | xxx... and after CCS, records would look like: version | epoch | seq_num | length | xxx... or like this if version is removed: epoch | seq_num | length | xxx.. In practice the actual values of type, version and epoch mean that the value of the first byte will disambiguate the format in (almost) all cases, but that ought to be documented in the RFC. From nobody Mon Jul 7 15:55:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE591B28C8 for ; Mon, 7 Jul 2014 15:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OF_Tid3SEzHj for ; Mon, 7 Jul 2014 15:55:21 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB4E1B28A5 for ; Mon, 7 Jul 2014 15:55:20 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id n15so25916wiw.4 for ; Mon, 07 Jul 2014 15:55:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mxYXkMJXNixz9NvULHNTImxWnvAZ7vXWasZaElSrrVo=; b=tik4OkztSM2cqFyJIZXq9LFFc8LE11KEkTPtoPLKO+Nz4zB4Vs3XxHORH5+Z0OdgAI L0EpyP9HCUph5dr4zBOmOiepx1sQ+lsTE/iyz6j0oGwqP5kYz6VC+jdQAgGhAKR31EG9 6WppYJPLa/FOrlV4nb8AEy5l4VEvUyAz/VteomHc3c2luY4ZxlrDh/e9Z2+TGG3kY/Bb 1FPCn3i1R8XF+fetan4j7fMt7vJs3HFqbf7dOMpbRux9Z03oC9olyP7eKLilpdx3z2sb NzkX4ywNMhtvi0uPOtbQ1PS2xmed9feZc1pLHWB33xxjGdHbO0J9n1hPXX9dEEVbhJHl CxLQ== MIME-Version: 1.0 X-Received: by 10.180.212.68 with SMTP id ni4mr39856492wic.64.1404773719545; Mon, 07 Jul 2014 15:55:19 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Mon, 7 Jul 2014 15:55:19 -0700 (PDT) In-Reply-To: References: <53B331A5.2040908@fifthhorseman.net> Date: Mon, 7 Jul 2014 15:55:19 -0700 Message-ID: From: Martin Thomson To: Fabrice Gautier Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KNrInot_Y6oPEhd676R3P5qdkEA Cc: IETF TLS WG Subject: Re: [TLS] proposal to encrypt ContentType for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 22:55:22 -0000 On 7 July 2014 15:41, Fabrice Gautier wrote: >> Doesn't the explicit sequence number in DTLS do that job adequately? >> Yes, you don't know until you get the packet containing CCS (or a >> retransmit thereof), but there's a fairly narrow range of values where >> it could appear. > > How do you reliably get the sequence number out of the records, if you > don't know which format is that record in ? The epoch number is initially zero and is incremented each time a ChangeCipherSpec message is sent. The overlap between the epoch you are likely to encounter (0x0001) and the content type/upper byte of version is zero. After that, it's all version-free and there is no ambiguity at all. Which also leads me to conclude that DTLS-SRTP might be OK here, if we constrain the epoch. From nobody Mon Jul 7 18:12:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDB41B29B2 for ; Mon, 7 Jul 2014 18:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PhIqcZ_Hall for ; Mon, 7 Jul 2014 18:10:47 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46B041B29A8 for ; Mon, 7 Jul 2014 18:10:47 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id z12so3437232wgg.16 for ; Mon, 07 Jul 2014 18:10:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=5o4+/dvmI3NAXHx2KUV1QqLNZj9Ksp8kh/+6Ufa75yI=; b=VhMeNHiRq2LowLIu+9tyaLd+oXG6oC0Czot+SSoK0EKLqcs2QmOs78l68+4Hr2aw9D PuaQomgbpedrvbzz1vZRKF2HdGchTWmzZF5DiOqRJJmyOlj+lnSDdMnsCh4OJZ4VzODj +NG29zKxBrrElXC3tmcyYX/EGreIDk12Eg5jZalBd2GRp5pX7KwCHI/pdJ0arzgo0G5u TivVFwfRMhECH+KoS0Y3ogCEbYWX+nGnHIIL7dntG7qVZEWeDw/9RWQx1RO/s1noC1qo Xgyi6ywRaYNkNUluIOEHIiizNiF2EEVTHViAC6RkUv+s1FmIP6Wypu4H2Xjt2/6abCSI DxRQ== X-Gm-Message-State: ALoCoQl92+4TUJoP2HnYNeLMVoCI9DKDo69vGyNTliWOtqAZyT2bA3oq8aI9GNbiWqiNJNF/kjc/ X-Received: by 10.195.13.102 with SMTP id ex6mr34946254wjd.48.1404781845690; Mon, 07 Jul 2014 18:10:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.57.202 with HTTP; Mon, 7 Jul 2014 18:10:05 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:6d14:37a9:d6cd:280d] From: Eric Rescorla Date: Mon, 7 Jul 2014 18:10:05 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7bd91696e6543504fda44285 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5z6iERbbUx4QGVa5EbVdSrilyyE Subject: [TLS] Submission of draft-ietf-tls-tls13-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2014 01:11:14 -0000 X-List-Received-Date: Tue, 08 Jul 2014 01:11:14 -0000 --047d7bd91696e6543504fda44285 Content-Type: text/plain; charset=UTF-8 Folks, I have just submitted draft-02 of TLS 1.3. You can find it at: http://tools.ietf.org/html/draft-ietf-tls-tls13-02 (when it goes up). This is obviously a WIP, but it would be good to get people's review so we can improve it and discuss in Toronto. Here is a list of the major changes: - Increment version number - Reworked handshake to provide 1-RTT mode. - Remove custom DHE groups - Removed support for compression. - Removed support for static RSA key exchange - Removed support for static DH key exchange - Removed support for non-AEAD ciphers Note that not all the changes here have had WG consensus declarations, but they reflect my sense of the WG discussion. If you find something that you think is wrong, please raise those topics on the list. For editorial or minor issues, it's easier if you file an issue or send me a pull request. As always, the current state is on Github at: Repo: https://github.com/tlswg/tls13-spec Editor's draft: https://tlswg.github.io/tls13-spec/ As noted above, this is still a WIP, so expect to see more pull requests proposed resolutions, and issues raised between now and Toronto. Thanks, -Ekr --047d7bd91696e6543504fda44285 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks,

I have just submitted= draft-02 of TLS 1.3. You can find it at:

=C2=A0 <= a href=3D"http://tools.ietf.org/html/draft-ietf-tls-tls13-02">http://tools.= ietf.org/html/draft-ietf-tls-tls13-02

(when it goes up).

This is obv= iously a WIP, but it would be good to get people's review
so = we can improve it and discuss in Toronto.

Here is = a list of the major changes:

- Increment version number
- Reworked handsha= ke to provide 1-RTT mode.
- Remove custom DHE groups
- = Removed support for compression.
- Removed support for static RSA= key exchange
- Removed support for static DH key exchange
- Removed suppo= rt for non-AEAD ciphers


Note that n= ot all the changes here have had WG consensus declarations,
but they reflect my sense of the WG discussion.

If you find something that you think is wrong, please r= aise those
topics on the list.

For edito= rial or minor issues, it's easier if you file an issue or
send me a pull request. =C2=A0As always, the current state is on Github at:=

Repo: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://github.com/tlswg/tls13-spe= c


As noted above, this is still a WIP, so = expect to see more pull requests
proposed resolutions, and issues= raised between now and Toronto.

Thanks,
-Ekr

--047d7bd91696e6543504fda44285-- From nobody Tue Jul 8 04:55:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0581B280E for ; Tue, 8 Jul 2014 04:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMtnQYv2VNDc for ; Tue, 8 Jul 2014 04:55:34 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 962A91B2810 for ; Tue, 8 Jul 2014 04:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1404820534; x=1436356534; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=dG/436z/qDG3mb8uyME2lX6Tn0T2s2p73TZrbJYfSi4=; b=k8rcZHNfECAWaa4WciObzhxGMDg/Z04EetWZglB813Sd+uHlGe/ZteUE iTrnxI5xxXZwbX/MzbpVSyiPBO4qoeqiIKEBK0DAQKEnpQMELJV3Kqt5p U3HiU+DOUuPkcDH9QggESweWCf38ylImUoc30SQTKT6O6ds+mhppTFtF3 0=; X-IronPort-AV: E=Sophos;i="5.01,625,1399982400"; d="scan'208";a="262568374" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 08 Jul 2014 23:55:32 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.9]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Tue, 8 Jul 2014 23:55:31 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] draft-gutmann-tls-eccsuites Thread-Index: Ac+ao4SLCSsYr4f8TkevRphBmdYRTQ== Date: Tue, 8 Jul 2014 11:55:31 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738DED552A@uxcn10-tdc06.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fkSJVnDRyYiytklG8aPIo-qn-A4 Subject: Re: [TLS] draft-gutmann-tls-eccsuites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2014 11:55:41 -0000 Henrik Grubbstr=F6m writes:=0A= =0A= >Have you considered the following note in RFC 4492 section 5.1?=0A= >=0A= >| NOTE: A server participating in an ECDHE-ECDSA key exchange may use diff= erent=0A= >| curves for (i) the ECDSA key in its certificate, and (ii) the ephemeral = ECDH key in the=0A= >| ServerKeyExchange message. The server must consider the extensions in bo= th cases.=0A= >=0A= >As I read the above, your suites would default to imply extra restrictions= on=0A= >the possible server certificates, as you would be restricted to only the s= ame=0A= >curve as in the suite (eg you wouldn't be able to use a SECP521 cert with= =0A= >TLS_ECDHE_ECDSA_P384_SHA384_WITH_AES_256_GCM_SHA384, as the server wouldn'= t=0A= >know if the client was capable of verifying the cert).=0A= =0A= Yep, and that's a feature, not a bug. The ambiguity over what's what is on= e=0A= of the (numerous) problems with the current use of ECC in TLS, the eccsuite= s=0A= draft nails it down to a single, unambiguous choice (currently this is done= =0A= implicitly by implementations following set of de facto "profiles" as=0A= described in the draft, but the draft makes this explicit).=0A= =0A= (It could also be argued that using a P256 cert with a P521 curve, or vice= =0A= versa, or some similar combination doesn't make much sense, why authenticat= e a=0A= 521-bit keyex with only a 256-bit signature?).=0A= =0A= >Or is the intent of the draft that the server just should select a cert an= d=0A= >hope for the best?=0A= =0A= The intent is that the security of the curve used for keyex match the curve= =0A= used in the cert, and that there's just a single unambiguous choice for tha= t.=0A= =0A= Peter.=0A= From nobody Tue Jul 8 05:58:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A3C1B2837 for ; Tue, 8 Jul 2014 05:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0Abr6oHZLuK for ; Tue, 8 Jul 2014 05:58:32 -0700 (PDT) Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) by ietfa.amsl.com (Postfix) with ESMTP id 814BA1B2830 for ; Tue, 8 Jul 2014 05:58:32 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s68CwSo7001406; Tue, 8 Jul 2014 08:58:29 -0400 Date: Tue, 8 Jul 2014 08:58:27 -0400 (EDT) From: Hubert Kario To: Peter Gutmann Message-ID: <2138402117.7478111.1404824307081.JavaMail.zimbra@redhat.com> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738DED552A@uxcn10-tdc06.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C738DED552A@uxcn10-tdc06.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF30 (Linux)/8.0.6_GA_5922) Thread-Topic: [TLS] draft-gutmann-tls-eccsuites Thread-Index: Ac+ao4SLCSsYr4f8TkevRphBmdYRTRgjEoXB Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_hf1Lmnxffz255iiBA94-0TdTPw Cc: tls Subject: Re: [TLS] draft-gutmann-tls-eccsuites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2014 12:58:35 -0000 ----- Original Message ----- > From: "Peter Gutmann" > To: "" > Sent: Tuesday, July 8, 2014 1:55:31 PM > Subject: Re: [TLS] draft-gutmann-tls-eccsuites >=20 > Henrik Grubbstr=C3=B6m writes: >=20 > >Have you considered the following note in RFC 4492 section 5.1? > > > >| NOTE: A server participating in an ECDHE-ECDSA key exchange may use > >| different > >| curves for (i) the ECDSA key in its certificate, and (ii) the ephemera= l > >| ECDH key in the > >| ServerKeyExchange message. The server must consider the extensions in = both > >| cases. > > > >As I read the above, your suites would default to imply extra restrictio= ns > >on > >the possible server certificates, as you would be restricted to only the > >same > >curve as in the suite (eg you wouldn't be able to use a SECP521 cert wit= h > >TLS_ECDHE_ECDSA_P384_SHA384_WITH_AES_256_GCM_SHA384, as the server would= n't > >know if the client was capable of verifying the cert). >=20 > (It could also be argued that using a P256 cert with a P521 curve, or vic= e > versa, or some similar combination doesn't make much sense Currently there are no P256 root CA certs in Mozilla trust store. That woul= d force all users to use P384 leaf certificates, and by extension the AES-256= GCM, which is unsupported by NSS (and unlikely to be actually needed by vast majority of users). >, why authenticate a > 521-bit keyex with only a 256-bit signature?). long term offline vs short term mitm attack. Or in other words, breaking the 256 bit signature will compromise the authentication part of the connec= tion, breaking the 521 bit keyex will compromise the confidentiality. Unrelated to the above: The draft specifies few TLS1.1-and-lower compatible cipher suites, e.g.: TLS_ECDHE_ECDSA_P256_SHA256_WITH_AES_128_CBC_SHA My understanding is that you can't use anything but concatenation of MD5|SH= A1 for signing the key exchange with TLS1.1-and-lower. Am I missing something or does it apply only the hash used for digital signatures in certificates? --=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hkario@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic From nobody Tue Jul 8 07:42:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902FC1B2ADE for ; Tue, 8 Jul 2014 07:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cMO9zSKvXdI for ; Tue, 8 Jul 2014 07:42:12 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE89D1A00F6 for ; Tue, 8 Jul 2014 07:42:11 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id id10so5513316vcb.38 for ; Tue, 08 Jul 2014 07:42:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=T9zT47I86vAVmp40Jlog0q2zx2yI8xo9mDtR+Jbcipw=; b=vzo6UzK88u7s3D3KHLw+iYJ/BgZNj+70QHF9jtxFiXP2kp5YbCgNHD7gtZqC2eCm2X eU2boJS8UbIpvkRoxB5QYGcDVukYxRHF0SXYnX3Nd2P31lqdWGOPShV0UOqfX6dsed88 9/nVW2bf1ka0vj2saqcb2hUCTjwB1Ch1T0KfgQElqgtk3LhVNXPwOn6BEAFdgdt4zmGz jLdbhCFL32OH/ZZCoCi/tFHtDoXLjx/1NohG0wY/L/bXogPxtH8qD0zuYt6LYN2B1iz6 Sk3H46qWtN2vEboga9GNbGicB18z/oL3x8sms1fLMCzesFKXbeyvzmERL2RPVUQQvZ8G 7VYA== MIME-Version: 1.0 X-Received: by 10.58.69.76 with SMTP id c12mr1971740veu.35.1404830530981; Tue, 08 Jul 2014 07:42:10 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.221.11.8 with HTTP; Tue, 8 Jul 2014 07:42:10 -0700 (PDT) Date: Tue, 8 Jul 2014 10:42:10 -0400 X-Google-Sender-Auth: 5vfhPx6uOAcyCK1IlxaUJuT9EbY Message-ID: From: Erik Nygren To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7b3a9bcec4d46f04fdaf985c Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bOG0GMrRgGOsZZMXdelNU46bQAY Subject: [TLS] Service Binding DNS Records (draft-nygren-service-bindings-00) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 14:42:13 -0000 --047d7b3a9bcec4d46f04fdaf985c Content-Type: text/plain; charset=UTF-8 Following some discussion in both the TLS and HTTPBIS working groups at past meetings (including in the TLS interim), it became clear that there was a need for a mechanism more flexible and powerful than SRV records for communicating parameters for establishing a connection to clients. In the TLS 1.3 world, one specific use-case is to bootstrap any handshake encryption via the DNS. One of the major browser concerns is limiting the number of DNS lookups that need to be performed before establishing a connection, especially when multiple records that may only exist a small fraction of the time need to be hunted for. This proposal attempts to limit that while also enabling future flexibility. In particular, I believe this proposal also makes DANE/TLSA much more operationally viable for HTTPS use-cases. Regarding the concern that the adoption rate for new record types is slow, this is explicitly an additional mechanism for now (such that clients should fall back to A/AAAA address records and such when unavailable), especially as the security functionality enabled in the first version is primarily opportunistic. Feedback is most welcome and I'm happy to discuss more in Toronto. This does not yet have a working group home yet, especially as it spans the interests of a number of WGs. There are also plenty of open issues, and I'd like to land on the concepts before getting into final details of encoding: http://tools.ietf.org/html/draft-nygren-service-bindings-00 ---------- Forwarded message ---------- From: Date: Fri, Jul 4, 2014 at 12:39 AM Subject: I-D Action: draft-nygren-service-bindings-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Service Binding DNS Records (DNS B) Author : Erik Nygren Filename : draft-nygren-service-bindings-00.txt Pages : 16 Date : 2014-07-03 Abstract: This document describes a DNS "B" RR which binds together information needed to establish connection to a service across multiple protocol layers, including the location of the server, the application-level protocol, and security bootstrap information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-nygren-service-bindings/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-nygren-service-bindings-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --047d7b3a9bcec4d46f04fdaf985c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
3D""
Following some discussion in both the TLS and HTTPBIS working groups at past=20 meetings (including in the TLS interim), it became clear that there was a n= eed for a mechanism more=20 flexible and powerful than SRV records for communicating parameters for est= ablishing a connection to clients.=C2=A0 In the TLS 1.3 world, one specific= use-case is to bootstrap any handshake encryption via the DNS.

One of=20 the major browser concerns is limiting the number of DNS lookups that=20 need to be performed before establishing a connection, especially when=20 multiple records that may only exist a small fraction of the time need=20 to be hunted for.=C2=A0 This proposal attempts to limit that while also=20 enabling future flexibility.=C2=A0 In particular, I believe this proposal a= lso makes DANE/TLSA much more operationally viable for HTTPS use-cases.=C2= =A0 Regarding the concern=20 that the adoption rate for new record types is slow, this is explicitly=20 an additional mechanism for now (such that clients should fall back to=20 A/AAAA address records and such when unavailable), especially as the securi= ty functionality enabled in the first version is primarily opportunistic.
Feedback is most welcome and I'm=20 happy to discuss more in Toronto.=C2=A0 This does not yet have a working=20 group home yet, especially as it spans the interests of a number of=20 WGs.=C2=A0 There are also plenty of open issues, and I'd like to land o= n the=20 concepts before getting into final details of encoding:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=20 http://tools.ietf.org/html/draft-nygren-service-bindings-00<= /a>


---------- Forwarded message ----= ------
From: <internet-drafts@ietf.org>
= Date: Fri, Jul 4, 2014 at 12:39 AM
Subject: I-D Action: draft-nygren-ser= vice-bindings-00.txt
To: i-d-announce@ietf.org
<= br>

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Serv= ice Binding DNS Records (DNS B)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Erik= Nygren
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-nyg= ren-service-bindings-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 16 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2014-07-03

Abstract:
=C2=A0 =C2=A0This document describes a DNS "B" RR which binds tog= ether information
=C2=A0 =C2=A0needed to establish connection to a service across multiple pr= otocol
=C2=A0 =C2=A0layers, including the location of the server, the application-= level
=C2=A0 =C2=A0protocol, and security bootstrap information.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-nygren-service-bi= ndings/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-nygren-service-bindings-00<= /a>


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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--047d7b3a9bcec4d46f04fdaf985c-- From nobody Tue Jul 8 08:16:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92491B2B1C for ; Tue, 8 Jul 2014 08:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vCY45wn90wz for ; Tue, 8 Jul 2014 08:16:26 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 651321B2B17 for ; Tue, 8 Jul 2014 08:16:25 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s68FGEgC005344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Jul 2014 17:16:14 +0200 (MEST) In-Reply-To: <2138402117.7478111.1404824307081.JavaMail.zimbra@redhat.com> To: Hubert Kario Date: Tue, 8 Jul 2014 17:16:14 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140708151614.335231AD94@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7Ltf95IYp589PCkFaaO6IX-jQMc Cc: tls Subject: Re: [TLS] draft-gutmann-tls-eccsuites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 15:16:28 -0000 Hubert Kario wrote: > > Unrelated to the above: > The draft specifies few TLS1.1-and-lower compatible cipher suites, e.g.: > TLS_ECDHE_ECDSA_P256_SHA256_WITH_AES_128_CBC_SHA > My understanding is that you can't use anything but concatenation of MD5|SHA1 > for signing the key exchange with TLS1.1-and-lower. Am I missing something > or does it apply only the hash used for digital signatures in certificates? The concatenation of MD5|SHA1 applies only to RSA-signatures (in digitally signed PKCS#1 v1.5 (block type 2?)) in TLSv1.1 and earlier. For (EC)DSA, it is traditionally SHA1-only (r+s integers). But there is a general rule about acceptable hash algorithms for use with (EC)DSA keypairs, and the key parameters are normally chosen in a fashion that implies a minimum length of the hash output (either SHA-1 or one of the SHA-2 algorithms). rfc4492 says that the hash could be something other than SHA-1, which I would read as use the minimum hash length as implied by the (EC)DSA key parameters. -Martin From nobody Tue Jul 8 09:21:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A462A1B2B9B; Tue, 8 Jul 2014 09:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsTHhXtrIyUT; Tue, 8 Jul 2014 09:21:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C76341B2B94; Tue, 8 Jul 2014 09:21:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140708162121.32253.46823.idtracker@ietfa.amsl.com> Date: Tue, 08 Jul 2014 09:21:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HKpq3xF7C7p2IKSeRdJvmUzJfGs Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-tls13-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 16:21:23 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : The Transport Layer Security (TLS) Protocol Version 1.3 Author(s) : T. Dierks, et al Filename : draft-ietf-tls-tls13 Pages : 91 Date : 2014-07-08 This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. A URL for this Internet-Draft is: https://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tls-tls13"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-07-08092121.I-D@ietf.org> --NextPart-- From nobody Tue Jul 8 10:33:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C2A1B2B70 for ; Tue, 8 Jul 2014 10:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1Yf75Ckd534 for ; Tue, 8 Jul 2014 10:33:00 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [67.18.125.13]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E97D1A0344 for ; Tue, 8 Jul 2014 10:33:00 -0700 (PDT) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id 5634DE7E0496F; Tue, 8 Jul 2014 12:32:59 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway06.websitewelcome.com (Postfix) with ESMTP id 38033E7DECAC3 for ; Tue, 8 Jul 2014 12:31:31 -0500 (CDT) Received: from [96.231.228.7] (port=51403 helo=192.168.1.8) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X4ZER-0001PH-H7 for tls@ietf.org; Tue, 08 Jul 2014 12:31:07 -0500 From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <092E1669-94AE-4739-A1BA-D3BC71125441@ieca.com> Date: Tue, 8 Jul 2014 13:31:04 -0400 To: "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.228.7 X-Exim-ID: 1X4ZER-0001PH-H7 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.8) [96.231.228.7]:51403 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 8 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/i1LYig8MQf0CyQsbBiKt_iR9htU Subject: [TLS] TLS Interim: Remote Participation Details X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2014 17:33:01 -0000 All, Here=E2=80=99s the TLS WG=E2=80=99s interim remote participation = details. If you have any questions please let me know off-list. I=E2=80=99= ll also try to remember to resend this Saturday evening before the = meeting in case anybody misses this message. The interim meeting is scheduled for: 2014-07-20 from 10am-4pm Please note that this is EDT =3D Eastern Daylight Time =3D UTC=E2=88=9204:= 00 All participants are bound by the note well: http://www.ietf.org/about/note-well.html The proceedings (agenda, minutes, proceedings) can be found here (look = for the 2014-07-20 tls row): https://www.ietf.org/meeting/interim/proceedings.html =20 There are no slides uploaded yet but they will be as soon as we get them = (hint for those presenting). For those participating remotely, a TLS jabber room is available as well = as a Webex session; details follow: 1) Jabber tls@jabber.ietf.org Will will draft a jabber scribe to make sure remote questions/comments = are channeled into the room. The scribe will likely not provide a = complete transcription of the conversations at the interim but will make = sure remote participants are at a minimum kept abreast of what = topic/slide is being discussed and will relay comments/questions to = those in attendance.=20 NOTE: The jabber room logs are archived. 2) Webex NOTE: If you are not speaking please *MUTE* your phone to minimize the = chance for disruptions during the call. NOTE: Webex has a chat facility too, but it=E2=80=99s probably best to = use the tis@jabber.ietf.org room instead. IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such = recordings may be subject to discovery in the event of litigation. Topic: TLS Date: Sunday, July 20, 2014 Time: 10:00 am, Eastern Daylight Time (Toronto, GMT-04:00) Meeting Number: 645 014 286 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?MTID=3Dmed3f98512f86e36b552e86ec21e0831a= 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?MTID=3Dmccae0b711419bf5c19538944860fa41d= ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:645 014 286 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support=E2=80=9D. To add this meeting to your calendar program (for example Microsoft = Outlook), click this link: https://ietf.webex.com/ietf/j.php?MTID=3Dm4818ab1848b2f2859d945bdf5d7ea6f2= The playback of UCF (Universal Communications Format) rich media files = requires appropriate players. To view this type of rich media files in the = meeting, please check whether you have the players installed on your computer by = going to https://ietf.webex.com/ietf/systemdiagnosis.php. spt {for the chairs}= From nobody Tue Jul 8 10:35:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8871C1A0367 for ; Tue, 8 Jul 2014 10:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.143 X-Spam-Level: * X-Spam-Status: No, score=1.143 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcSKDyvVgFPy for ; Tue, 8 Jul 2014 10:35:38 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [67.18.124.3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2CD1A0368 for ; Tue, 8 Jul 2014 10:35:38 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 2443BEC3E835E; Tue, 8 Jul 2014 12:34:16 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 7E1FCEC3E46A7 for ; Tue, 8 Jul 2014 12:34:04 -0500 (CDT) Received: from [96.231.228.7] (port=51455 helo=192.168.1.8) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X4ZHF-00067W-Q4 for tls@ietf.org; Tue, 08 Jul 2014 12:34:02 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <18CE1767-E490-4144-9BC6-8BC6D23AE8A2@ieca.com> Date: Tue, 8 Jul 2014 13:33:59 -0400 To: "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.228.7 X-Exim-ID: 1X4ZHF-00067W-Q4 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.8) [96.231.228.7]:51455 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 9 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6ex741HxSYjBFF_z5Kd-SOUCrUE Subject: [TLS] doodle: headcout for interim X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 08 Jul 2014 17:35:39 -0000 Hi! The chairs would like to get head count for for the TLS WG=92s interim = meeting in Toronto [1]. Please complete the following doodle poll by = this Friday (11-July-2014) so that we know you=92re planning on = attending the meeting in-person: http://doodle.com/yi2whfwkngc3hg4n [1] = https://mailarchive.ietf.org/arch/msg/ietf-announce/TIEsbhHxTXoHmPKLh2rRB5= A4QPA) spt {for the chairs}= From nobody Fri Jul 11 18:14:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A11A1A00F2; Fri, 11 Jul 2014 18:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CG201BRE-Y9m; Fri, 11 Jul 2014 18:14:11 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 44C111A00EA; Fri, 11 Jul 2014 18:14:07 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4959618001B; Fri, 11 Jul 2014 18:13:29 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140712011329.4959618001B@rfc-editor.org> Date: Fri, 11 Jul 2014 18:13:29 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UZStxFvJJoEBdw5ulvQRTAycfjQ Cc: drafts-update-ref@iana.org, tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] RFC 7301 on Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 01:14:25 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7301 Title: Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension Author: S. Friedl, A. Popov, A. Langley, E. Stephan Status: Standards Track Stream: IETF Date: July 2014 Mailbox: sfriedl@cisco.com, andreipo@microsoft.com, agl@google.com, emile.stephan@orange.com Pages: 9 Characters: 17439 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tls-applayerprotoneg-05.txt URL: http://www.rfc-editor.org/rfc/rfc7301.txt This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. This document is a product of the Transport Layer Security Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Jul 11 18:49:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275AD1B27AB for ; Fri, 11 Jul 2014 18:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-L7bkUFBnq0 for ; Fri, 11 Jul 2014 18:49:30 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (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 6A8C31A0190 for ; Fri, 11 Jul 2014 18:49:30 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 357F91DFE6; Sat, 12 Jul 2014 01:49:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1405129769; bh=0JpBaLK3D94w96PEijaH9cfY66bLwl31237woxDC5Jo=; h=From:To:Subject:Date:From; b=ph/21qgsKXqolNT4MZHJKE0y5xnmBN1yd2zYbS0JgVt/TPFGH7G0K1TlP1iJMawiZ 4uwMF8JdKANj732Z67i1CJCZt2eibaxr9Oaz0LNkSrUg/nRIMnpMN2TcJ+6mvUOxNX TFouKdJ1Q1SYNnZe8CCbS0ua1atKuW9BdyT3VT4c= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 554BB6002D; Sat, 12 Jul 2014 01:36:53 +0000 (UTC) From: James Cloos To: cfrg@irtf.org, tls@ietf.org User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 11 Jul 2014 21:36:53 -0400 Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140712:cfrg@irtf.org::ZqQLepdbwgqFozmb:000yJE9v X-Hashcash: 1:30:140712:tls@ietf.org::ICdn1RQwSVqZOZTV:0000aY1Zg Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nt4dbjvgjgWRhxvznwpWSlPMHZ4 Subject: [TLS] TLV vs Compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2014 01:49:32 -0000 My understanding is that tls with compression is vulnerable due to allowing unauthenticated initiators, which permits an oracle attack. If so, does it follow that a tls-like protocol, which enables compression only when symetric key negotiation uses temporal secrets (ie, the pfs concept), when mutual authentication is done, and only for application-level data, would be safe from compression-specific attacks? Or posed differently, if an application knows that the tls socket uses pfs and is mutually authenticated, is it ever safe for *it* to compress the data it sends over said socket? And for sockets which are only half-authenticated, can it be secure for the side which authenticated its peer to compress its own outgoing data? -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Fri Jul 11 19:56:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CBE1B27AB for ; Fri, 11 Jul 2014 19:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skPBcKn08PLX for ; Fri, 11 Jul 2014 19:56:25 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32FA01A0190 for ; Fri, 11 Jul 2014 19:56:25 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ho1so111013wib.16 for ; Fri, 11 Jul 2014 19:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m8OrsSYk656zlmiLXoqGhW9scu8qd8jN5LHkYkytBAY=; b=Iz3nRjARMMu0WMQgxlSpnRrDOKxmB+3KngzG+si08rT0aoUEAipjkxYR1ubPFTEytd vVCIej2nN4U/PumR8x0f/I4AcCB6OCETnNEPYktl4ftrCsi5hT/9zXLimHtwGwi8QjQC lgT2Nv+Hey/Io26YPgvZqmnbQbbtZh0LemKvUa31R52UUPnTBrYVl8c0/9yFKlIhhyHr tIpdZsjSifTt30A5v6lUYR9S08ocQG+ANqaIxW8Jrw2fcGnn2oUc5rRyB5UiqYic1w11 RDo77QGy3qQBEW0aKb31oLd+dzpYUPDYxKaPDI5bCTNvrRRtu9KMJy8nL9EfbN4KV5UP hRtQ== MIME-Version: 1.0 X-Received: by 10.194.91.228 with SMTP id ch4mr3567628wjb.59.1405133783802; Fri, 11 Jul 2014 19:56:23 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Fri, 11 Jul 2014 19:56:23 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 Jul 2014 19:56:23 -0700 Message-ID: From: Martin Thomson To: James Cloos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yPY64FR21g38a9j0oeY0-lC8OIs Cc: cfrg@irtf.org, "tls@ietf.org" Subject: Re: [TLS] TLV vs Compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2014 02:56:27 -0000 On 11 July 2014 18:36, James Cloos wrote: > Or posed differently, if an application knows that the tls socket uses > pfs and is mutually authenticated, is it ever safe for *it* to compress > the data it sends over said socket? Tying this to authentication works only to the extent that the authenticated actor is solely responsible for content. The concern is largely based on where the data comes from. Attacks shared so far [CRIME/BEAST] rely on compression that includes a mix of attacker controlled content and content the attacker wants to learn about. If you can guarantee single origin, then the length of an encrypted packet can reveal information, but it's pretty low in signal. An attack might still be able to attack low entropy secrets that use compression techniques that don't suit this use. Besides, guaranteeing that data is free from attacker influence is not that easy to do. The only technique that I think stands any chance here is to avoid generic compression, and rely on content-aware compression mechanisms that can be adjusted to deal with cases where content is controlled by mutually distrustful actors. Look here to the decisions made in HPACK, which is far worse than the state of the art in terms of compression efficiency at best. And HPACK will rarely reach optimum compression in practice due to the need for numerous safeguards against these sorts of attacks. From nobody Sun Jul 13 09:42:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5757D1B2AA1 for ; Sun, 13 Jul 2014 09:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gU_HNpsn7g8p for ; Sun, 13 Jul 2014 09:42:47 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id AA7421B2AA5 for ; Sun, 13 Jul 2014 09:42:47 -0700 (PDT) Received: from [192.168.12.134] (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 4D90BF984 for ; Sun, 13 Jul 2014 12:42:45 -0400 (EDT) Message-ID: <53C2B705.10209@fifthhorseman.net> Date: Sun, 13 Jul 2014 12:42:45 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0 MIME-Version: 1.0 To: IETF TLS WG References: <20140707160643.98F421AD93@ld9781.wdf.sap.corp> In-Reply-To: <20140707160643.98F421AD93@ld9781.wdf.sap.corp> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vo37eKowKtKIamNPbfE5mf2mdpDXaAIJg" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/H6W6CfovaQqczQImuqxZXj8H3UI Subject: Re: [TLS] proposal to encrypt ContentType for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 16:42:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vo37eKowKtKIamNPbfE5mf2mdpDXaAIJg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/07/2014 12:06 PM, Martin Rex wrote: > This version field is sometimes helpful for debugging, and > using the same formatting of the record contents (clear vs. decrypted) > means less code complexity. cleartext traffic or the NULL cipher is also helpful for debugging, but that doesn't mean we should leak it in the TLS protocol. The code complexity involved for the endpoints requires no extra state (TLS engines already know whether they're in NULL_WITH_NULL_NULL or not), and a amall change to the way the packets are handled in either case. > There are also going to be problems with implementations where the > records are read from network in their entirety before being passed to > and processed by the TLS implementation, and where that network i/o > state machine is currently using the record type to indicate to > higher layers whether the handshake is still ongoing. It's also > helpful to see in wireshark traces whether a connection was > terminated by a TLS alert, or whether it may have been interrupted > by some middlebox or other networking problem. >=20 > What would be the purpose/benefit of this in case that renegotiation > gets dropped? It hides TLS alerts from an observer, for one. If any attack is mounted which depends on observing which traffic creates a TLS alert, that attack would be more difficult. it also hides the possibility of an outside attacker observing a secondary CCS, which could indicate a change of keying material. Having the record types encrypted means that things like re-keying or mid-stream client authentication (both of which are currently contemplated even if we get rid of renegotiation) then an encrypted content-type will obscure that activity from a network observer= =2E > Such a change at the record layer would reliably preculde that we > ever ship TLSv1.3, because a 2 years ago I've switched to doing > all network i/o outside of the TLS stack and parsing the records above = TLS > so that we can arbitrarily mix non-blocking I/O with precise applicatio= n- > defined network timeouts. Above you called the engine you were using a "network i/o state machine" -- if the machinery actually has state, it should still be able to parse the length of each record, and can keep track of whether a CCS has been seen or not, so it should be able to continue parsing each record as it comes in. The fact that network-facing code won't know with certainty when a handshake completes and when application data starts flowing seems like a feature, not a bug, if we want to protect the communication. --dkg --vo37eKowKtKIamNPbfE5mf2mdpDXaAIJg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJTwrcFXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcnTwQAMrezvCTVgDYeNkc1xsYt4e6 BT5CDAJzb3fv5ZBPkKFXJXHZ1tmdKOS00GNNls9o1oCnpgdY/0XsafCU6bmUqqSF b4LBCvQeXUppWlttxCnVIugtK0nkPUv/+SvPdDw9g7wa7g+4nUKIcpIo13jhSa5k Gyj+Ghv1KpWccMzJpumZLotO8NN41C2QI0JlOMQQuqU3B6JN3ZrwMOqtMbbxsZBk p33y/DRum00f6Pk7CLWxDvAM/XuBy3jSHvs5BDhclHQi5J0adAeM2D+JSKL/i1lZ JaaJraer3fcj33siHfL60HwpbR2pqcU7MArPtD7sejoNdUjImY0At4lvgmlFayWq k8mGYugCyiIo1xW5nSdFZz4J2RVcpWS2uNQP3EZlT+b3KHO7o7z2FFWeFFMJckvH jOLwmJLqVQgqKjfuziH7BnhGEU/x8aa7FZsrQxSUyqD5N+ZS+x4cUqs+Cq4ugash HOcsX80c+i9X2ftfY/Z4oYTjbPXKJkDGIGiu0jYyZZFDpThcbxLCp/2pln2wlel/ 16kFYvoBc/NE3ztkegrNl76uTvMr1sROn58Da0525kn/yn4FjyOED6FdnN1f4+NY /GfbtQ+tBTnnV1x+7BzHjSEivjdISzc1S9bASTuFYO8gstlgv6I5KhCGj0kZUVj0 DfIuGFGPP/5Q5fJsfiqX =ylK0 -----END PGP SIGNATURE----- --vo37eKowKtKIamNPbfE5mf2mdpDXaAIJg-- From nobody Mon Jul 14 07:13:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6BF1A049C for ; Mon, 14 Jul 2014 07:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8GftaMoIV5E for ; Mon, 14 Jul 2014 07:13:04 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F061A04A1 for ; Mon, 14 Jul 2014 07:13:02 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s6EECvKM001363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Jul 2014 16:12:57 +0200 (MEST) In-Reply-To: <53C2B705.10209@fifthhorseman.net> To: Daniel Kahn Gillmor Date: Mon, 14 Jul 2014 16:12:57 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140714141257.9C2441ADA7@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tAHsbzjvqShrIXhR3CmXSUbOJ-M Cc: IETF TLS WG Subject: Re: [TLS] proposal to encrypt ContentType for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 14:13:06 -0000 Daniel Kahn Gillmor wrote: > > cleartext traffic or the NULL cipher is also helpful for debugging, but > that doesn't mean we should leak it in the TLS protocol. The code > complexity involved for the endpoints requires no extra state (TLS > engines already know whether they're in NULL_WITH_NULL_NULL or not), and > a small change to the way the packets are handled in either case. A TLS records contents and handshake message parser does *NOT* need to know or care which TLS cipher suite is currently used at the record layer, only the record layer needs to know that. > > It hides TLS alerts from an observer, for one. > [...] > an encrypted content-type will obscure that activity from a network observer. As you write yourself, this isn't hiding, but merely obscuring. GSS-API doesn't have or use any such obscuring. Does IPsec have anything like this (or need it, or miss it)? > > Above you called the engine you were using a "network i/o state machine" > -- if the machinery actually has state, it should still be able to parse > the length of each record, and can keep track of whether a CCS has been > seen or not, so it should be able to continue parsing each record as it > comes in. > > The fact that network-facing code won't know with certainty when a > handshake completes and when application data starts flowing seems like > a feature, not a bug, if we want to protect the communication. I definitely see it as a feature. The bug here would be an unnecessary difference to existing TLS protocol versions. For a TLS implementation with blocking network I/O and API semantics it doesn't really matter whether the handshake can be recognized on the wire. For non-blocking APIs, where network I/O is seperated from the TLS protocol implementation, the difference would be significant and needlessly complex. Drop-in replacement of only the TLS stack will be impossible. -Martin From nobody Mon Jul 14 07:30:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1358C1A063A for ; Mon, 14 Jul 2014 07:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0iUmiDfUVN5 for ; Mon, 14 Jul 2014 07:30:23 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id B4DCC1A05C0 for ; Mon, 14 Jul 2014 07:30:23 -0700 (PDT) Received: from [10.70.10.130] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id BC32CF984; Mon, 14 Jul 2014 10:30:20 -0400 (EDT) Message-ID: <53C3E973.4070504@fifthhorseman.net> Date: Mon, 14 Jul 2014 10:30:11 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0 MIME-Version: 1.0 To: mrex@sap.com References: <20140714141257.9C2441ADA7@ld9781.wdf.sap.corp> In-Reply-To: <20140714141257.9C2441ADA7@ld9781.wdf.sap.corp> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Kqw0CEelS4gpooNWft35bPEm9VHARL6fQ" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lBkpyr05EtEjxF6SWawUmcTeC5g Cc: IETF TLS WG Subject: Re: [TLS] proposal to encrypt ContentType for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 14:30:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Kqw0CEelS4gpooNWft35bPEm9VHARL6fQ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/14/2014 10:12 AM, Martin Rex wrote: > Daniel Kahn Gillmor wrote: [...] >> The fact that network-facing code won't know with certainty when a >> handshake completes and when application data starts flowing seems lik= e >> a feature, not a bug, if we want to protect the communication. >=20 > I definitely see it as a feature. I'm glad to hear it :) > The bug here would be an unnecessary difference to existing TLS protoco= l versions. [...] > Drop-in replacement of only the TLS stack will be impossible. Yes, I'm suggesting that for people in the unusual situation of having moved their network i/o state machine entirely outside of their TLS stack, they'll want to update their network i/o state machines first (to understand the new traffic patterns), before upgrading their TLS stacks to support TLS 1.3. It seems entirely possible that this will be the case anyway, given the new handshake flows proposed for TLS 1.3. I don't think this is a good reason to avoid the improvement. Regards, --dkg --Kqw0CEelS4gpooNWft35bPEm9VHARL6fQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJTw+lzXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcEfYQAJQ5sQKi6Q0oK5XQleAQS2wk HeE8CsGVX+4dtLarbuZB+yBTgRTW8CozRP7SVSPSFk4XkhtAFNuG7wM8YyES+BFG wwel0eRjnx5xH7GDPMdUZNuQBEShaG55BqRwSw6M0o7qPzFVxaq824CrU92xXF4B huWMTsmf6F0FjtdGpX4sNAuYXjxi6eg1iMef2Bnd3JKVnyDJRar5u6wFtJUkW9ro /G/qaprHXslFHZ4xsSnfhrdSTdyvhKBaRThzJP8QswML7m/U5iJIlKdBcV1JbAzP EPURvLfpXamD84u8k+E4apA6VW3MBnUjA+Ju9D57fkD0mLWywszQogu/Jgoq3SHz sxBSeJWRv/HjwBPG6ejA0+DOJiUJmuGdm1izGYGXpNMjLklicDm74BIVgWobX0fa xvti9v+bjlIcOpMB5O3qffKYZhX8IjGhk8Gocy0K7WB+X1p3zJTyTqYS7VqcxSRc Vy6lVe3dMprN/pbSGeJg4TF0z6Fp/KPoDfkCFjOC0a6da/TOD0fafjq4sa+ImtqD fYuAa5VfFXbPczZs8enC85Y7ONSEE47HRTrA44uXUbrPQJTLDjU53oRMBQLeAbLs WHLpieDVLI+OtQtdr5ZtnVS7Pdb7ZEtgWV5/DmWfifUh7Of+jRZdz35NIi9Gh2ab R+gfRahkrcS9her/EzIQ =sxc5 -----END PGP SIGNATURE----- --Kqw0CEelS4gpooNWft35bPEm9VHARL6fQ-- From nobody Mon Jul 14 09:10:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7451A0AC2 for ; Mon, 14 Jul 2014 09:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3gWZTmAM2Mo for ; Mon, 14 Jul 2014 09:10:04 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C0881A0AB6 for ; Mon, 14 Jul 2014 09:10:04 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s6EGA0St012075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Jul 2014 18:10:00 +0200 (MEST) In-Reply-To: <53C3E973.4070504@fifthhorseman.net> To: Daniel Kahn Gillmor Date: Mon, 14 Jul 2014 18:10:00 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140714161000.B229C1ADA7@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tx7oqRlWRXS9ViXSGFnP20HQfHc Cc: IETF TLS WG Subject: Re: [TLS] proposal to encrypt ContentType for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 16:10:08 -0000 Daniel Kahn Gillmor wrote: > On 07/14/2014 10:12 AM, Martin Rex wrote: >> Daniel Kahn Gillmor wrote: >>> The fact that network-facing code won't know with certainty when a >>> handshake completes and when application data starts flowing seems like >>> a feature, not a bug, if we want to protect the communication. >> >> I definitely see it as a feature. > > I'm glad to hear it :) Ooops, my hands wrote the opposite of what my mind was thinking of. I meant to say that it is a feature of TLS to be able to distinguish handshake phase from application data phase on the outside. > >> The bug here would be an unnecessary difference to existing TLS protocol versions. > [...] > > Drop-in replacement of only the TLS stack will be impossible. > > Yes, I'm suggesting that for people in the unusual situation of having > moved their network i/o state machine entirely outside of their TLS > stack, they'll want to update their network i/o state machines first (to > understand the new traffic patterns), before upgrading their TLS stacks > to support TLS 1.3. That is not ususual at all. It is actually the most reasonable approach if you want to do network I/O with arbitrary mixtures of non-blocking and application-specified timeouts. Microsoft's SChannel SSP AFAIK has always been transport-free. In addition to non-blocking, I also implemented server-side "TLS extension SNI" purely at the application layer, the server-side of the SSL stack doesn't care about it. > > It seems entirely possible that this will be the case anyway, given the > new handshake flows proposed for TLS 1.3. > > I don't think this is a good reason to avoid the improvement. The more bogus and backwards-incompatible changes go into TLSv1.3, the more unlikely it will be that we will ever support it. -Martin From nobody Mon Jul 14 09:21:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC6E1A0AEE for ; Mon, 14 Jul 2014 09:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzlawBXa3adK for ; Mon, 14 Jul 2014 09:21:53 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4351A0AEB for ; Mon, 14 Jul 2014 09:21:52 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id f73so1700122yha.24 for ; Mon, 14 Jul 2014 09:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sG/iiu+yo2+AKS91Fj5UjjmW9x0s8eQNhvKGJeJPi/w=; b=GzON6bR0Z4uRKwTJ4votbReWxXcsjvvpZ2jYk4IiDQW0KCP6YdQwAw3ErZgEQ+mBnR nj6vwf2ngVefyZF81Y+st43GxHfOCsM584IiOpEFOAKWXYUDD5wvKwVOoZYXq3H9KJYc WpsWrTppoLzr/zf3S5QQhoENTVpulsUqWl4SifHGSE3DOxMqG9FHP0DAY1bsdNTv4kcM fVqncxGh4Yz/aW/v07TjbBYPU8nTz6ljIJLTpy1T77uPWhUc/ZeAbb8rZ+urMn0tpDGk fPSxaeldNqnGV0KO79El4qE7aLeQE8VjVW9nH6KxnUW1XBJaI3z9iXdOEpEfDP04XnI4 jPXQ== MIME-Version: 1.0 X-Received: by 10.236.25.234 with SMTP id z70mr31069462yhz.107.1405354912150; Mon, 14 Jul 2014 09:21:52 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Mon, 14 Jul 2014 09:21:52 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Mon, 14 Jul 2014 09:21:52 -0700 (PDT) In-Reply-To: <20140714161000.B229C1ADA7@ld9781.wdf.sap.corp> References: <53C3E973.4070504@fifthhorseman.net> <20140714161000.B229C1ADA7@ld9781.wdf.sap.corp> Date: Mon, 14 Jul 2014 09:21:52 -0700 Message-ID: From: Watson Ladd To: mrex@sap.com Content-Type: multipart/alternative; boundary=089e0149be7a527a4304fe29b05d Archived-At: http://mailarchive.ietf.org/arch/msg/tls/w_eqWA3xOQ8lYk2YwzHtlVdJNx4 Cc: tls@ietf.org Subject: Re: [TLS] proposal to encrypt ContentType for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 16:21:55 -0000 --089e0149be7a527a4304fe29b05d Content-Type: text/plain; charset=UTF-8 On Jul 14, 2014 9:10 AM, "Martin Rex" wrote: > > Daniel Kahn Gillmor wrote: > > > On 07/14/2014 10:12 AM, Martin Rex wrote: > >> Daniel Kahn Gillmor wrote: > >>> The fact that network-facing code won't know with certainty when a > >>> handshake completes and when application data starts flowing seems like > >>> a feature, not a bug, if we want to protect the communication. > >> > >> I definitely see it as a feature. > > > > I'm glad to hear it :) > > Ooops, my hands wrote the opposite of what my mind was thinking of. > > I meant to say that it is a feature of TLS to be able to distinguish > handshake phase from application data phase on the outside. > > > > > >> The bug here would be an unnecessary difference to existing TLS protocol versions. > > [...] > > > Drop-in replacement of only the TLS stack will be impossible. > > > > Yes, I'm suggesting that for people in the unusual situation of having > > moved their network i/o state machine entirely outside of their TLS > > stack, they'll want to update their network i/o state machines first (to > > understand the new traffic patterns), before upgrading their TLS stacks > > to support TLS 1.3. > > > That is not ususual at all. It is actually the most reasonable approach > if you want to do network I/O with arbitrary mixtures of non-blocking > and application-specified timeouts. Microsoft's SChannel SSP AFAIK has > always been transport-free. In addition to non-blocking, I also > implemented server-side "TLS extension SNI" purely at the application > layer, the server-side of the SSL stack doesn't care about it. No, it isn't. There is no reason that a TLS implementation cannot accept bytes from the network layer and indicate when it is ready to send on a message, instead of accepting records. Sincerely, Watson Ladd > > > > > > It seems entirely possible that this will be the case anyway, given the > > new handshake flows proposed for TLS 1.3. > > > > I don't think this is a good reason to avoid the improvement. > > > The more bogus and backwards-incompatible changes go into TLSv1.3, > the more unlikely it will be that we will ever support it. > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --089e0149be7a527a4304fe29b05d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jul 14, 2014 9:10 AM, "Martin Rex" <mrex@sap.com> wrote:
>
> Daniel Kahn Gillmor wrote:
>
> > On 07/14/2014 10:12 AM, Martin Rex wrote:
> >> Daniel Kahn Gillmor wrote:
> >>> The fact that network-facing code won't know with cer= tainty when a
> >>> handshake completes and when application data starts flow= ing seems like
> >>> a feature, not a bug, if we want to protect the communica= tion.
> >>
> >> I definitely see it as a feature.
> >
> > I'm glad to hear it :)
>
> Ooops, my hands wrote the opposite of what my mind was thinking of. >
> I meant to say that it is a feature of TLS to be able to distinguish > handshake phase from application data phase on the outside.
>
>
> >
> >> The bug here would be an unnecessary difference to existing T= LS protocol versions.
> > =C2=A0[...]
> > > Drop-in replacement of only the TLS stack will be impossible= .
> >
> > Yes, I'm suggesting that for people in the unusual situation = of having
> > moved their network i/o state machine entirely outside of their T= LS
> > stack, they'll want to update their network i/o state machine= s first (to
> > understand the new traffic patterns), before upgrading their TLS = stacks
> > to support TLS 1.3.
>
>
> That is not ususual at all. =C2=A0It is actually the most reasonable a= pproach
> if you want to do network I/O with arbitrary mixtures of non-blocking<= br> > and application-specified timeouts. =C2=A0 Microsoft's SChannel SS= P AFAIK has
> always been transport-free. =C2=A0In addition to non-blocking, I also<= br> > implemented server-side "TLS extension SNI" purely at the ap= plication
> layer, the server-side of the SSL stack doesn't care about it.

No, it isn't. There is no reason that a TLS implementati= on cannot accept bytes from the network layer and indicate when it is ready= to send on a message, instead of accepting records.

Sincerely,
Watson Ladd
>
>
> >
> > It seems entirely possible that this will be the case anyway, giv= en the
> > new handshake flows proposed for TLS 1.3.
> >
> > I don't think this is a good reason to avoid the improvement.=
>
>
> The more bogus and backwards-incompatible changes go into TLSv1.3,
> the more unlikely it will be that we will ever support it.
>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

--089e0149be7a527a4304fe29b05d-- From nobody Mon Jul 14 10:16:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A911A0AE6 for ; Mon, 14 Jul 2014 10:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKQNHOytbVz5 for ; Mon, 14 Jul 2014 10:16:37 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3221A0AE3 for ; Mon, 14 Jul 2014 10:16:37 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id dc16so3436927qab.22 for ; Mon, 14 Jul 2014 10:16:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=y/ZcXGqou0USA4MezQFuDFnv3qCqz4FwY2KwEYitMCk=; b=ecriEfYmhP2Ps/S2MzVERKuExgAe5M+mfrm+NUCzfRDHrIaE+cDsi403ZeRSJ9ikZP qXMk7/swY+QRG6Abfx8Y2ukrcoVrRbwt7B2ECRpHKiTpQLSd1L7Defd1Im6pUrRpf1Ep zle+tfKhk/+oZCWydxOtVYidCbLlTq0ZtjMN5PU4lLk+TtkMy0VEQ/fCw5zg5PODjneU TEBOjLMWtDGeWZoNg3bBMfLu9297t+TgGUHrxqzlwR0tCrvH07/TibtGhj3ZfuoJFCX3 uje8ifrrftPN3zL6tlSKnA7mt2PARAvtHlnoiThqwGKX/UE3T/3hwrnylYho6oz1f2tA Xssg== X-Gm-Message-State: ALoCoQnPOiqIHwFo+7FtMmNZ17E4XSHnDLhLSiHeZmD901Q1v7jDHU27gAJ3RoEQU2FgOkbzVkCh X-Received: by 10.229.38.1 with SMTP id z1mr27198941qcd.18.1405358195315; Mon, 14 Jul 2014 10:16:35 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:390:d81:350c:1e85:a7c? ([2601:a:2a00:390:d81:350c:1e85:a7c]) by mx.google.com with ESMTPSA id j1sm21343741qaa.11.2014.07.14.10.16.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jul 2014 10:16:34 -0700 (PDT) Message-ID: <53C41080.9050204@nthpermutation.com> Date: Mon, 14 Jul 2014 13:16:48 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "tls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UipCH2vlHe0S3HtE6OEXkxmlmmM Subject: [TLS] 1rtt thoughts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2014 17:16:39 -0000 The current 1rtt draft uses a ClientHello with a ClientKeyExchange embedded in an EarlyData extension of the hello to get around the problem of pre-TLS1.3 handshake message ordering. That solves the problem mostly, but at the cost of yet another tweak to message formats and slightly more complexity in processing. Instead, how about simply sending the ClientKeyExchange first and then the ClientHello (same TCP/UDP send call, just a different record order)? A TLS1.2 server receiving things in this order discards the ClientKeyExchange with an out of sequence error, and then starts the handshake normally with the receipt of the ClientHello. The TLS1.3 client detects the error report and resends the ClientKeyExchange in the appropriate TLS1.2 order. For Finished message processing, the ClientKeyExchange record is included in the hash/mac in its normal location, regardless of when it was received. Mike From nobody Mon Jul 14 10:27:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DB61A0B07 for ; Mon, 14 Jul 2014 10:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PPpvV3Rd4r1 for ; Mon, 14 Jul 2014 10:27:37 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C42081A05C3 for ; Mon, 14 Jul 2014 10:27:36 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id l4so1149714lbv.16 for ; Mon, 14 Jul 2014 10:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=046+3U8uyhQdZTmArQHHP8RTQHlEPo7MsPzqUECs9h4=; b=XEO/G909HytYqq9QjpFQZxr92J6SJ94OzLsEGKOahSrHAl1rsY7fSwerxqjnNj+vc0 yJ9HyKbtVwPa4KQphcdgxWenXkVBw2Oc32QFSlrino0r6wBLXMILLPdzgJdrBiMxEjya ZuUEsSwok2aRiU0O9lN/jOn6Rv0waX/00NyKaqdRVXyGCWvdXbP4R/2osx3m+vI6hiBU OybdMFdDA4P1DCBwUQ+GvMguK0u8Z+XnTu9P6bhaHyD1JqIw9hYxNsaZjyFlz1C3oa0B nZ0QBZ+VIMhdcZ+UsZNuaE7hwEEe68nYu7hlsOMkQWhJscFVQ5g6R/G3E3GRDCKeX9pc KQkw== MIME-Version: 1.0 X-Received: by 10.152.37.135 with SMTP id y7mr14827705laj.18.1405358855155; Mon, 14 Jul 2014 10:27:35 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.32.196 with HTTP; Mon, 14 Jul 2014 10:27:35 -0700 (PDT) In-Reply-To: <53C41080.9050204@nthpermutation.com> References: <53C41080.9050204@nthpermutation.com> Date: Mon, 14 Jul 2014 10:27:35 -0700 X-Google-Sender-Auth: NOXtlWpvB3J-ibln7cYqJM9jlfM Message-ID: From: Adam Langley To: Michael StJohns Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YL24unX5VB4Ei5kapDNuT2K1e84 Cc: "tls@ietf.org" Subject: Re: [TLS] 1rtt thoughts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2014 17:27:39 -0000 On Mon, Jul 14, 2014 at 10:16 AM, Michael StJohns wrote: > A > TLS1.2 server receiving things in this order discards the ClientKeyExchange > with an out of sequence error, and then starts the handshake normally with > the receipt of the ClientHello. I've never encountered a TLS 1.2 implementation that will discard an unexpected handshake message like that as opposed to sending a fatal alert (maybe) and closing the connection. We could refine TLS 1.2 processing, of course, but if you were expecting that to be backwards compatible with existing code then I fear it won't work. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Mon Jul 14 10:49:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CADA1A0B14 for ; Mon, 14 Jul 2014 10:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVGtGq0MFwGV for ; Mon, 14 Jul 2014 10:49:50 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FF0D1A0AF9 for ; Mon, 14 Jul 2014 10:49:49 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id n12so4387949wgh.33 for ; Mon, 14 Jul 2014 10:49:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bjhgIKUedYW55bkbljoYUOXuohuvxQ3H/XMJ6OOs42A=; b=Vn7oE6RGgznIiJFChBEADGHOxj2o6S8qIMMB2ZBi4HszSyG5UHTFwqZLycnvvJad9y CfsMAUIKjL516PFErcFqrh/ifl9aDi97zk/G/RXAp2urprBiF2zzNv6WXfqcEnlys2Xe 6LQloFty+KXdqhcDsc3mePXfJPxoycAtDHqhlRBDwmsG92ET0bHqfhCAtHg9QynlrxUX RcpCm8/GS4cu/XHBLMI23D1dxZsam72sSUiI/pUHlUFHfMmC4MJwD69+tUh9u8xWEbV6 CcGlmUg3GXycaILhFvJOMPG8MZwf9J2d1NBpt1TNI/v+sCTyR7OlhhF5Wo5EA9wFE8Hb 1pzw== X-Gm-Message-State: ALoCoQmGZVk8mhUa9+bG1X0EQT2nh6G2B8X0ldbMAo7QdLuK7txE4QwVxqItPT9wpOVEVcxbVLpB X-Received: by 10.180.75.47 with SMTP id z15mr25589631wiv.80.1405360188290; Mon, 14 Jul 2014 10:49:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Mon, 14 Jul 2014 10:49:08 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:2849:f520:57d7:53d0] In-Reply-To: References: <53C41080.9050204@nthpermutation.com> From: Eric Rescorla Date: Mon, 14 Jul 2014 10:49:08 -0700 Message-ID: To: Adam Langley Content-Type: multipart/alternative; boundary=f46d04389517ce0f0d04fe2aea32 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KnsmAUlrwWU9W1rRw-eIcc87OLQ Cc: "tls@ietf.org" Subject: Re: [TLS] 1rtt thoughts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2014 17:49:51 -0000 --f46d04389517ce0f0d04fe2aea32 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 14, 2014 at 10:27 AM, Adam Langley wrote: > On Mon, Jul 14, 2014 at 10:16 AM, Michael StJohns > wrote: > > A > > TLS1.2 server receiving things in this order discards the > ClientKeyExchange > > with an out of sequence error, and then starts the handshake normally > with > > the receipt of the ClientHello. > > I've never encountered a TLS 1.2 implementation that will discard an > unexpected handshake message like that as opposed to sending a fatal > alert (maybe) and closing the connection. > Indeed, it's required by TLS. -Ekr > We could refine TLS 1.2 processing, of course, but if you were > expecting that to be backwards compatible with existing code then I > fear it won't work. > > Cheers > > AGL > > -- > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d04389517ce0f0d04fe2aea32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Jul 14, 2014 at 10:27 AM, Adam Langley &l= t;agl@imperialv= iolet.org> wrote:
On Mon, Jul 14, 2014 at 10:1= 6 AM, Michael StJohns
<msj@nthpermutation.com>= ; wrote:
> A
> TLS1.2 server receiving things in this order discards the ClientKeyExc= hange
> with an out of sequence error, and then starts the handshake normally = with
> the receipt of the ClientHello.

I've never encountered a TLS 1.2 implementation that will discard= an
unexpected handshake message like that as opposed to sending a fatal
alert (maybe) and closing the connection.

Indeed, it's required by TLS.

-Ekr
=C2=A0
We could refine TLS 1.2 processing, of course, but if you were
expecting that to be backwards compatible with existing code then I
fear it won't work.



Cheers

AGL

--
Adam Langley agl@imperialviolet.o= rg https:/= /www.imperialviolet.org

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

--f46d04389517ce0f0d04fe2aea32-- From nobody Mon Jul 14 10:51:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15541A8BB7 for ; Mon, 14 Jul 2014 10:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmRta5QL_7VW for ; Mon, 14 Jul 2014 10:51:33 -0700 (PDT) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0BE81A854D for ; Mon, 14 Jul 2014 10:51:33 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id wp4so2607132obc.15 for ; Mon, 14 Jul 2014 10:51:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iHSmabkMCRr8jEk30ceRJkCG6ZbKm8MDg/kJqmKOzX4=; b=NgAtjo0lTHzbnItRJRU8CJDQSOB6AbUxCK2ftldjInQacTReF8WLMWYETWljvfe/PQ 6HNL/+JeZq7JuYSDFlIKAX/RY24FclqCbedmFMOZIGUp5wo+WYkPST5FOMFggY7A0nKz n0Lp+2VawJSrFtjmqOijAa+dZE8RF1qIQIyUf7gJAwE81qRO/Tlq4AHg+2PkJe+j3eGi iWzT00sCOwv+GOuPbvIPZs2LBQBztzzqnWmEtWGi1x6ZLflvN6kWw/7QzptqOVMS1geu 99FAmPDx81JXtrLXgDrCsFuhoFU5GQaCQ+GfiY7UFxwUIlR0LRWC+Lgp71ZGSYBo98xk SOKA== X-Gm-Message-State: ALoCoQkiDP3NoedblGxcU1yClwCCXCmNn/nBNIoYOWvMgukZ86jDPLelcjn7lz80MmIquR8hctIr MIME-Version: 1.0 X-Received: by 10.60.145.196 with SMTP id sw4mr5001484oeb.72.1405360293244; Mon, 14 Jul 2014 10:51:33 -0700 (PDT) Received: by 10.76.10.198 with HTTP; Mon, 14 Jul 2014 10:51:33 -0700 (PDT) In-Reply-To: <20140714161000.B229C1ADA7@ld9781.wdf.sap.corp> References: <53C3E973.4070504@fifthhorseman.net> <20140714161000.B229C1ADA7@ld9781.wdf.sap.corp> Date: Mon, 14 Jul 2014 10:51:33 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WFs-T2PTSpdN1M_7nMzAWuGTAEk Cc: IETF TLS WG Subject: Re: [TLS] proposal to encrypt ContentType for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 17:51:35 -0000 On Mon, Jul 14, 2014 at 9:10 AM, Martin Rex wrote: > I meant to say that it is a feature of TLS to be able to distinguish > handshake phase from application data phase on the outside. During the week of heartbleed, I wrote a silly kernel module that does this. I've just put it on GitHub for reference: https://github.com/colmmacc/nf_conntrack_tls I wouldn't recommend actually using the module, as it was an emergency temporary measure borne out of necessity and in general; moving input processing risks to the kernel is an especially bad idea. But I've uploaded it as an example of where having the record type in the plain did help; it allows a middle-layer to do sufficient protocol validation to protect against a record-level flaw in the application's record processing (such as Heartbleed). Even having done that, this still seems like a mis-feature; especially considering how bad leaking the alert type has been over the years. -- Colm From nobody Mon Jul 14 13:06:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2530C1A8BB2 for ; Mon, 14 Jul 2014 13:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XU46-K1X8bXI for ; Mon, 14 Jul 2014 13:06:39 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5B971ABB90 for ; Mon, 14 Jul 2014 13:06:38 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id r5so3203059qcx.41 for ; Mon, 14 Jul 2014 13:06:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=abbn7CxL/PbfzzH4egOk2nihFJZV1Wz4JWssEmtDE9w=; b=EzRoRjUVGY5oEsSjb2LzUZybM/bAtp7ra9H9GKsHc+N5aEgPkBE8lQk7t1mT5HNWaD mNnpCiFbZftb2aoZy4jMWHmrf67cEmCvuj89WgN1f1WaThjkimf1soBd4O7OyNODHsDx N6T7aUFGkEsHaSLF8QdYtcFYfV3PUxfy/KBtXUaDKYOPbaoh02OTG+hY96GlTjjkBFJ5 IP0RFSX/CwPtRwOWUlZpyRUEgfG6sc7z/xyWYD49iCJbHXTpxDyGv8qvh84tqqpWiDbz nZETegGvmQShyMvcH/y7IKZSjunIrLRv/hIbdqgIWNj8JBwIWd1fWYbcmBakgr10KN8i oncA== X-Gm-Message-State: ALoCoQkxMf7ci/a+vRE77dYU4jhb/QEEr2CUYR2Ux5ryquX364llAtIt+l7snldiBz42GXQg6rrH X-Received: by 10.224.49.71 with SMTP id u7mr25066137qaf.58.1405368398012; Mon, 14 Jul 2014 13:06:38 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:390:d81:350c:1e85:a7c? ([2601:a:2a00:390:d81:350c:1e85:a7c]) by mx.google.com with ESMTPSA id r10sm22011294qar.40.2014.07.14.13.06.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jul 2014 13:06:37 -0700 (PDT) Message-ID: <53C4385A.7030007@nthpermutation.com> Date: Mon, 14 Jul 2014 16:06:50 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Eric Rescorla , Adam Langley References: <53C41080.9050204@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040306000404070301000007" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/enaY3MpFnyt_-QwEdv7jQtiF880 Cc: "tls@ietf.org" Subject: Re: [TLS] 1rtt thoughts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2014 20:06:41 -0000 This is a multi-part message in MIME format. --------------040306000404070301000007 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 7/14/2014 1:49 PM, Eric Rescorla wrote: > > > > On Mon, Jul 14, 2014 at 10:27 AM, Adam Langley > wrote: > > On Mon, Jul 14, 2014 at 10:16 AM, Michael StJohns > > wrote: > > A > > TLS1.2 server receiving things in this order discards the > ClientKeyExchange > > with an out of sequence error, and then starts the handshake > normally with > > the receipt of the ClientHello. > > I've never encountered a TLS 1.2 implementation that will discard an > unexpected handshake message like that as opposed to sending a fatal > alert (maybe) and closing the connection. > > > Indeed, it's required by TLS. Umm... Part of the problem I have at times in discussions about TLS is the confusion between what happens as part of the transport connection and what happens as part of the TLS connection. I think of TLS as a record connection over a bearer transport service. They interact, but not strongly, and usually not without intervention from the client or server application. The TLS thing (server, message processor, etc) attached to the server side of the transport connection snarfs up individual TLS records one by one and processes them according to its current state. While you're both correct that TLS requires the "connection" to be closed in the event of a fatal error (and here I'm referring to 7.2.2 of RFC5246), the context of the word "connection" in that section doesn't appear to be same as closing the "transport" (see just above that where the two different terms are used). It appears to only refer to closing the current TLS connection. Nothing in section 7.2.2 suggests either the requirement to close the transport, nor the requirement to discard pending data in the transport connection. I'm not arguing that implementations don't do exactly that though - I don't actually know. if you're arguing that the standard says to close the transport and discard the pending TLS records, can you point me at that section? I also can't find anything that says that a new connection can't be opened on the same transport connection after a fatal close. So I would suggest that even with 7.2.2 you get this as an error case between a 1rtt TLS1.3 client and a 1.2 server: Client Server ClientKeyExchange -----> ClientHello ----> [Server notices data waiting on the transport Server begins a connection state Server receives and processes unexpected ClientKeyExchange Server sends a fatal alert and discards the connection state] <--------------- Error Alert (unexpected_message) (plus close_notify??) [Client receives the error alert checks for type and discards it as expected] [Server notices data waiting on the transport Server begins a connection state Server Receives and processes ClientHello Server sends its part of a TLS1.2 handshake] <--------------- ServerHello, ServerKeyExchange etc [Client receives the Server Side messages and processes them... Client resends the ClientKeyExchange that was ignored above] ClientKeyExchange ------> etc ---> ............................. Continue through the normal connection process. From the server's side this looks like two different connections. From the client side, it's just negotiating to the right suite. Mike > > -Ekr > > We could refine TLS 1.2 processing, of course, but if you were > expecting that to be backwards compatible with existing code then I > fear it won't work. > > > > > Cheers > > AGL > > -- > Adam Langley agl@imperialviolet.org > https://www.imperialviolet.org > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --------------040306000404070301000007 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 7/14/2014 1:49 PM, Eric Rescorla wrote:



On Mon, Jul 14, 2014 at 10:27 AM, Adam Langley <agl@imperialviolet.org> wrote:
On Mon, Jul 14, 2014 at 10:16 AM, Michael StJohns
<msj@nthpermutation.com> wrote:
> A
> TLS1.2 server receiving things in this order discards the ClientKeyExchange
> with an out of sequence error, and then starts the handshake normally with
> the receipt of the ClientHello.

I've never encountered a TLS 1.2 implementation that will discard an
unexpected handshake message like that as opposed to sending a fatal
alert (maybe) and closing the connection.

Indeed, it's required by TLS.

Umm...

Part of the problem I have at times in discussions about TLS is the confusion between what happens as part of the transport connection and what happens as part of the TLS connection.  I think of TLS as a record connection over a bearer transport service.  They interact, but not strongly, and usually not without intervention from the client or server application.  The TLS thing (server, message processor, etc) attached to the server side of the transport connection snarfs up individual TLS records one by one and processes them according to its current state. 

While you're both correct that TLS requires the "connection" to be closed in the event of a fatal error  (and here I'm referring to 7.2.2 of RFC5246), the context of the word "connection" in that section doesn't appear to be same as closing the "transport" (see just above that where the two different terms are used).   It appears to only refer to closing the current TLS connection.

Nothing in section 7.2.2 suggests either the requirement to close the transport, nor the requirement to discard pending data in the transport connection.  I'm not arguing that implementations don't do exactly that though - I don't actually know.   if you're arguing that the standard says to close the transport and discard the pending TLS records, can you point me at that section? 

I also can't find anything that says that a new connection can't be opened on the same transport connection after a fatal close.

So I would suggest that even with 7.2.2 you get this as an error case between a 1rtt TLS1.3 client and a 1.2 server:

Client                                                      Server
ClientKeyExchange ----->
ClientHello ---->
                                                           [Server notices data waiting on the transport
                                                            Server begins a connection state
                                                            Server receives and processes unexpected ClientKeyExchange
                                                            Server sends a fatal alert and discards the connection state]
                                       <--------------- Error Alert (unexpected_message) (plus close_notify??)
 [Client receives the error alert
   checks for type and discards it as expected]
                                                           [Server notices data waiting on the transport
                                                            Server begins a connection state
                                                            Server Receives and processes ClientHello
                                                            Server sends its part of a TLS1.2 handshake]
                                        <--------------- ServerHello, ServerKeyExchange etc
[Client receives the Server Side messages and processes
  them...
 Client resends the ClientKeyExchange that was ignored above]
ClientKeyExchange  ------>
etc --->
 .............................  Continue through the normal connection process.



From the server's side this looks like two different connections.  From the client side, it's just negotiating to the right suite.

Mike



-Ekr
 
We could refine TLS 1.2 processing, of course, but if you were
expecting that to be backwards compatible with existing code then I
fear it won't work.



Cheers

AGL

--
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org

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


--------------040306000404070301000007-- From nobody Mon Jul 14 13:19:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A50C1A0AF1 for ; Mon, 14 Jul 2014 13:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1rAt-y2MQzO for ; Mon, 14 Jul 2014 13:19:35 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2E061A0AA2 for ; Mon, 14 Jul 2014 13:19:34 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so3207952wiv.13 for ; Mon, 14 Jul 2014 13:19:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gEjSqwmEkLqa4JfOeEroN1aBqdtb6SlVH8xGP1IInzQ=; b=QckrgW//IEadIYZoieUJPVivn3HusYowylNyLspOAU/RHo1paZf5ioA8+xAcZxLZIS 0+aQt6OSuGzQcqnI92DB/P7vmdyYCnWg/nf4BFBAvd8oOcCXckYYbBvbzsCgyCpO8qSz hcSC+/o+emtn7oec2gDNGOAQCozVJCwgtauUCOz9byPc8ducCnwNdq2O8NBJauu6ZQJZ QfLgiK9QQER1qeUnovW9nII5i3ixLrkIrvZvKrgj7rJz3mJgDkmuy7kz35wNSoULLoH1 vXMfDuG5ius7SajyXwENIWV4GG8G1TUhYeMdrYXqpp9g5ICby+fK9Pf6/zaK38QvW6RP 9tWA== X-Gm-Message-State: ALoCoQnEEPAiNVqlewxagFo6qj2ngG7hJJcc5+0b3ZUySBa7oxK0PrimrHpz99OhiBNYkju3Abl/ X-Received: by 10.180.89.143 with SMTP id bo15mr265877wib.78.1405369173311; Mon, 14 Jul 2014 13:19:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Mon, 14 Jul 2014 13:18:53 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:2849:f520:57d7:53d0] In-Reply-To: <53C4385A.7030007@nthpermutation.com> References: <53C41080.9050204@nthpermutation.com> <53C4385A.7030007@nthpermutation.com> From: Eric Rescorla Date: Mon, 14 Jul 2014 13:18:53 -0700 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=e89a8f3bab875a9af104fe2d0228 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CGyxwvbQ50G72O3TKzkgdnn8qms Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] 1rtt thoughts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2014 20:19:37 -0000 --e89a8f3bab875a9af104fe2d0228 Content-Type: text/plain; charset=UTF-8 A large fraction of existing TLS servers will respond to this situation by generating a fatal alert and closing the connection.That makes this approach a nonstarter. Given that, whether it is possible for a compliant TLS server to behave differently seems like a largely academic question. -Ekr On Mon, Jul 14, 2014 at 1:06 PM, Michael StJohns wrote: > On 7/14/2014 1:49 PM, Eric Rescorla wrote: > > > > > On Mon, Jul 14, 2014 at 10:27 AM, Adam Langley > wrote: > >> On Mon, Jul 14, 2014 at 10:16 AM, Michael StJohns >> wrote: >> > A >> > TLS1.2 server receiving things in this order discards the >> ClientKeyExchange >> > with an out of sequence error, and then starts the handshake normally >> with >> > the receipt of the ClientHello. >> >> I've never encountered a TLS 1.2 implementation that will discard an >> unexpected handshake message like that as opposed to sending a fatal >> alert (maybe) and closing the connection. >> > > Indeed, it's required by TLS. > > > Umm... > > Part of the problem I have at times in discussions about TLS is the > confusion between what happens as part of the transport connection and what > happens as part of the TLS connection. I think of TLS as a record > connection over a bearer transport service. They interact, but not > strongly, and usually not without intervention from the client or server > application. The TLS thing (server, message processor, etc) attached to > the server side of the transport connection snarfs up individual TLS > records one by one and processes them according to its current state. > > While you're both correct that TLS requires the "connection" to be closed > in the event of a fatal error (and here I'm referring to 7.2.2 of > RFC5246), the context of the word "connection" in that section doesn't > appear to be same as closing the "transport" (see just above that where the > two different terms are used). It appears to only refer to closing the > current TLS connection. > I > Nothing in section 7.2.2 suggests either the requirement to close the > transport, nor the requirement to discard pending data in the transport > connection. I'm not arguing that implementations don't do exactly that > though - I don't actually know. if you're arguing that the standard says > to close the transport and discard the pending TLS records, can you point > me at that section? > > I also can't find anything that says that a new connection can't be opened > on the same transport connection after a fatal close. > > So I would suggest that even with 7.2.2 you get this as an error case > between a 1rtt TLS1.3 client and a 1.2 server: > > Client Server > ClientKeyExchange -----> > ClientHello ----> > [Server notices > data waiting on the transport > Server begins > a connection state > Server > receives and processes unexpected ClientKeyExchange > Server sends a > fatal alert and discards the connection state] > <--------------- Error Alert > (unexpected_message) (plus close_notify??) > [Client receives the error alert > checks for type and discards it as expected] > [Server notices > data waiting on the transport > Server begins > a connection state > Server > Receives and processes ClientHello > Server sends > its part of a TLS1.2 handshake] > <--------------- ServerHello, > ServerKeyExchange etc > [Client receives the Server Side messages and processes > them... > Client resends the ClientKeyExchange that was ignored above] > ClientKeyExchange ------> > etc ---> > ............................. Continue through the normal connection > process. > > > > From the server's side this looks like two different connections. From > the client side, it's just negotiating to the right suite. > > Mike > > > > > -Ekr > > >> We could refine TLS 1.2 processing, of course, but if you were >> expecting that to be backwards compatible with existing code then I >> fear it won't work. >> > > > >> Cheers >> >> AGL >> >> -- >> Adam Langley agl@imperialviolet.org https://www.imperialviolet.org >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > --e89a8f3bab875a9af104fe2d0228 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A large fraction of existing TLS servers will respond= to this situation by
generating a fatal alert and closing th= e connection.That makes this
approach a nonstarter.
Given that, whether it is possible for a compliant TLS server to= behave
differently seems like a largely academic question.
=

-Ekr


On Mon, Ju= l 14, 2014 at 1:06 PM, Michael StJohns <msj@nthpermutation.com>= ; wrote:
=20 =20 =20
On 7/14/2014 1:49 PM, Eric Rescorla wrote:



On Mon, Jul 14, 2014 at 10:27 AM, Adam Langley <agl@imperialviolet.org> wrote:
On Mon, Jul 14, 2014 at 10:16 AM, Michael StJohns
<msj@nthpermutation.com> wrote:
> A
> TLS1.2 server receiving things in this order discards the ClientKeyExchange
> with an out of sequence error, and then starts the handshake normally with
> the receipt of the ClientHello.

I've never encountered a TLS 1.2 implementation that will discard an
unexpected handshake message like that as opposed to sending a fatal
alert (maybe) and closing the connection.

Indeed, it's required by TLS.

Umm...

Part of the problem I have at times in discussions about TLS is the confusion between what happens as part of the transport connection and what happens as part of the TLS connection.=C2=A0 I think of TLS as= a record connection over a bearer transport service.=C2=A0 They interact, but not strongly, and usually not without intervention from the client or server application.=C2=A0 The TLS thing (server, message processor, etc) attached to the server side of the transport connection snarfs up individual TLS records one by one and processes them according to its current state.=C2=A0

While you're both correct that TLS requires the "connection&qu= ot; to be closed in the event of a fatal error=C2=A0 (and here I'm referring = to 7.2.2 of RFC5246), the context of the word "connection" in th= at section doesn't appear to be same as closing the "transport&qu= ot; (see just above that where the two different terms are used).=C2=A0=C2=A0 It appears to only refer to closing the current TLS connection.
I
Nothing in section 7.2.2 suggests either the requirement to close the transport, nor the requirement to discard pending data in the transport connection.=C2=A0 I'm not arguing that implementations do= n't do exactly that though - I don't actually know.=C2=A0=C2=A0 if you'= ;re arguing that the standard says to close the transport and discard the pending TLS records, can you point me at that section?=C2=A0

I also can't find anything that says that a new connection can'= t be opened on the same transport connection after a fatal close.

So I would suggest that even with 7.2.2 you get this as an error case between a 1rtt TLS1.3 client and a 1.2 server:

Client=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Server
ClientKeyExchange ----->
ClientHello ---->
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [Server notices data waiting on the transport
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Server begins a connection state
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Server receives and processes unexpected ClientKeyExchange
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Server sends a fatal alert and discards the connection state]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 <--------------- Error Alert (unexpected_message) (plus close_notify??)
=C2=A0[Client receives the error alert
=C2=A0=C2=A0 checks for type and discards it as expected]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [Server notices data waiting on the transport
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Server begins a connection state
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Server Receives and processes ClientHello
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Server sends its part of a TLS1.2 handshake]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 <--------------- ServerHello, ServerKeyExchange etc
[Client receives the Server Side messages and processes
=C2=A0 them...
=C2=A0Client resends the ClientKeyExchange that was ignored above]
ClientKeyExchange=C2=A0 ------>
etc --->
=C2=A0.............................=C2=A0 Continue through the normal connection process.



From the server's side this looks like two different connections.= =C2=A0 From the client side, it's just negotiating to the right suite.

Mike




-Ekr
=C2=A0
We could refine TLS 1.2 processing, of course, but if you were
expecting that to be backwards compatible with existing code then I
fear it won't work.



Cheers

AGL

--
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org

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



--e89a8f3bab875a9af104fe2d0228-- From nobody Mon Jul 14 14:22:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100D01A0118 for ; Mon, 14 Jul 2014 14:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZadwVT6NPwPN for ; Mon, 14 Jul 2014 14:22:27 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 55C7C1A010F for ; Mon, 14 Jul 2014 14:22:26 -0700 (PDT) Received: from [10.70.10.130] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id AA619F984 for ; Mon, 14 Jul 2014 17:22:23 -0400 (EDT) Message-ID: <53C44A03.4070603@fifthhorseman.net> Date: Mon, 14 Jul 2014 17:22:11 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0 MIME-Version: 1.0 To: "tls@ietf.org" References: <53C41080.9050204@nthpermutation.com> <53C4385A.7030007@nthpermutation.com> In-Reply-To: <53C4385A.7030007@nthpermutation.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rvkXDhewj461Hom9MjplinGb2v01PAbt6" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2337-3SPtKNwGZSq7LZXOQ-oMOo Subject: Re: [TLS] 1rtt thoughts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2014 21:22:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rvkXDhewj461Hom9MjplinGb2v01PAbt6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/14/2014 04:06 PM, Michael StJohns wrote: > From the server's side this looks like two different connections. From > the client side, it's just negotiating to the right suite. I'm not sure what toolkit presents this as two different connections on the server side. This closure and reopening smells very much like problems we fixed with insecure renegotiation only a few years ago. A TLS toolkit capable of keeping the underlying transport open while restarting a new TLS session would need to be very clear about how it presents such a transition to the upper-layer logic, if we don't want another round of prefix-injection attacks. I recognize that this is an API question more than a protocol question, and therefore at the edge of scope for the WG. But we've seen enough problematic APIs that cause applications to lose the security guarantees that the protocol is supposed to provide that i can't help thinking we should take these concerns seriously. --dkg --rvkXDhewj461Hom9MjplinGb2v01PAbt6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJTxEoDXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc3SUQAI8upuGFJL8XSkq+CDbWzOON WT0rnO14FySl3LJCebRRbTyrZdlnciuIOG30IEd9LiGHz0CXMkGF0w90FuXh7Z28 V0H7CVU3064qEUbWmqYnB7xgfLHgtwpYYXRINE+sdryXIKf9/52sRlhY4m5k2miV 1iRQSyx4jG8xxCTFA0oM4vWEpm3yqGzyd/Ri1rSxRVZ9eFGOEo4kkSGHOLD3bacX BJCwNhf2fFhgwFugWqWbZiZFimM5OObi4azoN6jly1dZPlkUk46FjKEL0CWCuwtN r/0GgrkTqoVj0AFU1ZCv7aCK86mGNUcBKDHOR8NsfL27euaKdwkKc2JvALq2qEDG RkV4XKpwXC34KHi+2Mz18l3A0GWJ22nLthVxFOvBGTixdJpEIb6NEVfoT+ssKUhj uLppWJ+JrJSvhGCpAafiYHSUm+M0Rto4YKhd0ozuzfzTksmXvppTM+OH1VF10e2W BpvRjbj2ol/ncjuXDnY2q3mS1EJxeFsF517+6bRqRfm1jMOR9Ra41P3qOIw/bG8a sYYo/jcAxbKYguzDEBlKtEtDGmEiwHNsJ1J5vfW63SzPXjX4nkg3plcZVxsVuaFA CtYoqOm3D3lEpkPZJSSO8L7MiXdZoQf6AmO2KbioS29GVTmhBCKAzowrQXJfS/qo y6L/qc7xk1kwqRxhB3rO =NpNK -----END PGP SIGNATURE----- --rvkXDhewj461Hom9MjplinGb2v01PAbt6-- From nobody Tue Jul 15 06:46:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DD41A03DE; Tue, 15 Jul 2014 06:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.447 X-Spam-Level: X-Spam-Status: No, score=-1.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, T_HK_NAME_DR=0.01, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfFfpAoBkqaz; Tue, 15 Jul 2014 06:46:35 -0700 (PDT) Received: from bohuslav.ifi.uzh.ch (bohuslav.ifi.uzh.ch [130.60.155.10]) by ietfa.amsl.com (Postfix) with ESMTP id 048731A03CE; Tue, 15 Jul 2014 06:46:33 -0700 (PDT) Received: from authenticated sender schmitt by bohuslav.ifi.uzh.ch (postfix) with ESMTPSA id SA; <794C07FC6D> Message-ID: <53C530B7.8040605@ifi.uzh.ch> Date: Tue, 15 Jul 2014 15:46:31 +0200 From: "Dr. Corinna Schmitt" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sean Turner , ietf-secretariat@ietf.org, "TLS@ietf.org (tls@ietf.org)" References: <8B2FFA4C-9BBF-4E7E-B0E4-032139FF0EB5@ieca.com> In-Reply-To: <8B2FFA4C-9BBF-4E7E-B0E4-032139FF0EB5@ieca.com> Content-Type: multipart/alternative; boundary="------------070109020803020900010203" X-Virus-Scanned: clamav-milter 0.97.8 at bohuslav X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zTq1VyBKLBLSjMkLGVK4hc-omkA Subject: [TLS] interim meeting anoucement - Location? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2014 13:46:37 -0000 This is a multi-part message in MIME format. --------------070109020803020900010203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear Sean, Sunday is arriving soon. So where do we meet? I cannot find detailed information. I just found the remote participant information. Regards, Corinna Am 23.06.14 04:27, schrieb Sean Turner: > WG Members, > > Per the doodle results, the TLS WG will hold an interim > meeting prior to the IETF from 10am-4pm on Sunday > July 20. > > The most likely location will be the Mozilla offices in Toronto. > > The chairs will post details with an agenda and a final location > closer to the meeting. > > spt for the chairs > [For the chairs] > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- --------------070109020803020900010203 Content-Type: multipart/related; boundary="------------030601090803000404080003" --------------030601090803000404080003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear Sean,

Sunday is arriving soon. So where do we meet?
I cannot find detailed information. I just found the remote participant information.

Regards,
Corinna

Am 23.06.14 04:27, schrieb Sean Turner:
WG Members,

Per the doodle results, the TLS WG will hold an interim
meeting prior to the IETF from 10am-4pm on Sunday
July 20.

The most likely location will be the Mozilla offices in Toronto.

The chairs will post details with an agenda and a final location
closer to the meeting.

spt for the chairs
[For the chairs]

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


--
--------------030601090803000404080003 Content-Type: image/png; x-mac-type="0"; x-mac-creator="0"; name="visitenkarte.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="visitenkarte.png" iVBORw0KGgoAAAANSUhEUgAAASgAAACgCAIAAAAw8WZPAAAAAXNSR0IArs4c6QAAAARnQU1B AACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAA buNJREFUeF7t3Qe8FtXRP3CT901i2htTTVeTGE035Z+YZkxijFFjQcVKVXrvvffee6/Se+9I R0CahSqCgtJBQKTl/9099y4P9yIiEOXq83zwus8+Z8+ePTtzZs7Mb2Y+9p///OeKd/uMGTNm 5cqVWq1atWr//v3v1jz9e3oGPnIzcOWVV/7ud7/z2DfeeON9993n67tMAcZ7p8/s2bMfeeSR q666Skd14s/o0aOdTH/SM5CegSwzMHny5MAjWAbXYRnMcg7muuKsvz333HOuvPXWW59++ul9 +/ad4/r0T+kZSM9A9hnAdTjopptuwp9nnZ+zMB5mu/nmm8/Nr+m5Ts9AegbedQYIMNKLGMze MivjVa1alax866233rXTdIP0DKRn4HxmIOifWXjqDMbDdRqdOnXqZPqTnoH0DFyKGcBNmLNP nz40z1QuPc14NEx86bc0412KCU/3kZ6BaAYC4/k0adKEYEt4L4PxKKP2dUEaphkvTTLpGbhU M5AwHs4i2Ii3wHsZjJdq/bxgxsvk7XPovWkl9lK90HQ/OWMGUhlvx44d1157bRBvEeNxQdxx xx0Ju7wnxjtx4sTJEyeSa/fs2b1mzZrp06YPHzp02JAh/jmYOmUyifrGG28kzU6eyBmzlh5l egYucgZSGQ/9ly1btk2bNhmMh+vw3oUxXrhq586dkyZNatyoYY1q1apXq1anVq0G9eo1rFu3 ob/16tWrU6d61arVq1WvX6/+6FGjt219NVx1kY+Uvjw9A5f/DGRhvJdffpnQixiP4INNSbV1 no/EI+hsBl2/ffuOnj17li9XrmrlKhivaZMmXTt3fnrwoKlTpsyeNXvO7NnTp00bNnRoj27d WjRv3rhhw+pVq5cuWbpTx46bN28K7KerSGymP+kZ+DDOQBbGQ/CMKYsWLboiMWa+J4kXGGb0 qFHlypatVrVqy+YtunbpsnDBgtkzZo4bOzb7Jm/evGecX75sWa+ePTWuXatW2dKl+/fre/jw YY2PH08z3oeR6NLPlGLVTJgiIMuuCP9LZZVzSzwsovGunTsbN2pUsUKF5k2bDujf74Xnn8c8 zg8cMLBCuXKv79hhzhM5dvTo2y2bN2/YoMHxY8e12bhhw/BhQ1s0bVa1cuWaNWps2rgxrXam SfTDOgPZJV5Ak12RP39+3r3zZzwtX968mW5Zr27dNq3bLFiwYPOmTXv37Hb+hRdeaFCvfptW rVu1aJnwkoO5s+c4o/3gQQN9XfbssmeXLiX9Onbo0KhRw9IlSzr+b8i9YPi55IbU49aY4yfi 5enSKclRT8czPD5pj86HiAuzMx49k7Z5RRbLCgY4h8Tz6ytbtpQpXTrs5ba8vMWZwQMHkn57 du/R47/vvPPfd92FLZ0/cuTI4UOHHIwaOfLef//7zjvuaNWyha99+vRt3qz59te2b33llT69 e7do1qxYkaKB984x4cnSENqkPs/5X3VJXijGyzKYLF8v6C6RvvD228defOGFtWvWHHrzzfPZ aV/QjdIXva8zkJ3xgn3lCiDOLADqs77y2JryH5EKNnXNmzXr3Knj/v37aJj169WbMX0GY+bK 5cunTJ78VMGCRQsXLl60qM3bcyuemzljhqt6dutWMH/+J/PntxvkynDJvr372rZp88zcuW+8 /kbMe81Lliix5eWXw9Yxu63l2LHjSxYvNs6DBw8ans+xt48tXrSI8ebNN98860Rqc/To0WZN m+Z54vF169ZdQjrW1fLlyx95ODeJ/fbbb7u7UZHhe/fuveC7RPrC88/f8+9/f+H//u/zn//c nDlz0ur3+8of/7WbXSzjRULm5Ek806RxEzZJTNK5c+eXXnypdMlSFM6li5doMGHcuP59+w3q 379mjeq7du3EVBs2rHfjwQMGdOvSuX/v3jWrVX/z4MG9+/Y9u2RJm9athw8btmDe/Igze/Zs 3bKVHeORw4dTN4cZwu3kyTffPPSrm276whe+sHbN2iBe9u8/8LOf/vSLX/wipgpSOhB9+DU8 LSfHN77+dfGIvXr0SG2TCMxwSTI1CdtEfcVdht6yCFhnmjZpqtsfXn/9gQMHjr711r3/vucr X/7y2rXR2MJVZ3QV95X6ZrPcMQy+YIEC+rzt73+rVq3qhg0bLoyHQ1cXdu1/jfbesePsmsI7 jTx5rZdwkBc8S8mFyajO0VXyrpOHfW8Sz2Vjx4whslq3arV169Y1q1a3atmyc8eOc2bNInwi Ujt5EkNWrVK1ZvXq+fPmxZlUphnTp1PMGjdswOJSrXLlgvny7969J2KJN97ApdOnTp01c2bb 1m22b9/eoV077r4e3bpHhH6md+HUyVOHDh36xc9//vnPfU6fmYy3/yc//jH58NJLEeNl/3jg 48feHjt6NA5n7EkaBHF61kvCSfvC1F+1T7ZeCR/a5TZv3oKEj9ofP/HTn/7ks5/97OZYYqcS U1ATMroNojzlTJYx/PmPf/z85z+/efPm6PwF4dSzdHjBhBUT9wljiN7FRXzi53jHLXagyH37 9x858lbGHTMfIPWeYcYgLvbu3Xfs2LGLGE7GpfFDnX6lnvQ99RnGGAZ//Ngxo0rOvJPmleW9 nC/jRZR36hQzZrkyZVq1aLFkyeIN69e3b9vu9dffGDVixBtv7Iyf5MT+ffuKFylSqkSJ8mXL 3H7bbfx4M6ZNw0779u3Ndd99LCj8B84vmB+JuPBZtHDRYw8/XKRQ4SOHDlO0WjVv7vL16zdk ed/uTnH91S9vuuqqLwSp4rP/wIGf/exnX/rSlzZu2Lh39+4qVau0bNmCCM11/3333ntP/379 XMU52aN791q1a7GjEstFixV1d+dPHD9OSyxUqBDLELZp367dnf/61x3//CdPo02pBtOmTS1W tOjAAf1LlSzlV2cGDhjwQK5ct/7lFiYi82u0NarXGPL009aXEiVKkKsUxNy5czdu0mTcuHGF Cxfu0rmLnr2fiRMnPvXUU8xXpihsDnfseB2Q4K4777rvnnt5Vg4dPvzKK6+UKF7i29/+1he+ 8H+PPfaYTa+Rv1e20X79uvXlypUrUqRI2TJlFi9afDFsE+xSR986+p6IMkvjt98+ijTfiRxx Ea/Sr3716+B/Mn6zWqVKlddefTXLuvP6668/kvvhv9zyl02bIt/vxQzJteSEV/PSSy8VLVLE HSN6OG/W03j1qlVVqlTdtXMX/rnrzjvZJ+2ngEN2vrHzrK/swiVeWHL43+rWrt2zRw/W/0kT Jgzo15/EM61+Oha74Xbv2tm+bZsmjRsVL1KU0Js0aSK6rFK58p7du/kMKlUoX71K5SqVKs5N 2b34SbfPPbdy8qRJWzZvfnrQ4LatW9uVvSfG44hH/V/60hc/9alPfe5zn/vaV79KYSMJly5Z ao/32//3/3y1GwQMd/DUk0/pnF3nq1/56qc++ckVK1bQb50nTn/60586sINFA40bN3aMl/wl 5Ht07/Hxj30Md/36l78qXqyYHkYMH+Gnf99993MrVlxzzTWf/cxn3Vr7W//ylzGjR/vp61// OsuTSb/9H7f72r170HVPbtu69ZY//9mZL171RQNwULRoUUP97ne+S2aSeKT67f/4x6HDkVHq PVGY9rNmzvrSF7/YpHHjMqVKXfPda6ZNm5Zlrc0i6rN8zUIiDerXDyr6WT/n1hpcsn79+rxP PHFg//7kQbL0w/b2veuus0JFciymMWTg8VetXJml5cL5C0y+peTc488+zuxEbzdeIF++l154 ccf2HTVq1CRCAg4k++esklCzMaNGf/5zn31126vWi+98+9tbt24bOWK4YdsdnPWVXTjjedp9 e/dWrVyJL47DAJXXrlmT6HtlyytBbQsikfb49KBBxYoUQXwMJ+PHje3SqXPRwkU2b9zUskWL B+6/P+/jjzdt1IhBJfVNWOybN23WsWOHl1560Z6Q2aZyxYpbtkTG0sTEgmAPHz70q1/+8qpo j5epah7YHyQe3WzrK1u9wv/5n//B2mYk1/33h30dLedvf/3rlZ/6FPfFiuXLceP1P/gByCjx 9bGPfezRRx5hSkXuv/rVr55fu3b5s8u+/73vfeMb39i9a1e7tm01+OY3vwlzQw0mD3XYrGmz iHliNZXW/Yn//d+HHngAb6Own//sZ/afkDomgXB2U+179+q9Yd26r3z5K9ddey0pF15tgwYN /PTYo4/ywcycMfNb3/qmUS1auNBk/u63/w83mh/KxQVAeXTuWur3ju2vOc6fL999993rYNu2 baR0o0aNyA2moA4dOljsKlWsNH78eL+aPQxWoWLFCRMmWEb7+/Tt1759+759+qD13/z611On Th0zekzXLl3r16/ft29feweT7EldK+1VyxYtrarI9403XgdB7Na1K5EFR/HG66+b3s9+5jPl ypazGw+i4PChw927dStXrvzokSMJ/0YNG331K1955OFHwoZWhzOmT0PKq1etHjpsWLeu3WrX qt2nV6+XN7/M4/W1r32NimFuF8xfULlSJauz9/j2sbcZGgy1d+/e8+fPN+zWrVozmLOu165d u3//fnQMQrJevegBJ0+afOjNQ7ZCn/70p5944gnaVvfu3V/dts19bRkqVKjYuWMncqxbNMJy NlCJjhxeXLJDmThhwnXXXkOhe+CBB1CLm9Kzvvud79h9XGLGi5aiyZOrVanct3dvE2pZmj9v Xs/uPRgVkiXZxBFfdWvXKl2iBN4rWCA/bHTtGjWeeOzxhfPnFy1cqFTxElTNxx99ZN68eanj 8wLwkvfXrk1b74+QbNywkYmM22RoAIHxfnnTTV+86iq6QZiIAwcO/uynP2Nc2bRxE7fEtddc 861vfSvMY4Xy5RE3kJq3/feY8RZRKU+cuOOfd2AnXPf44499/OMfR08jRowgJ6+++ms/+P73 se6nr7ySyFm/bl37du31QNsM96pZvYavhEm+vHkxcMJ4D+bK5cEt2L/+1a8w3sYYCeDTqVMn 7b1dmqQDil+w1Wh5+23/+N///d+pk6eElsyYH7viiqcHD3Z8y5//5BZWorO+v3eVfq7CeD/+ 0Y3r173k2GMa1fbXXnvwgQdKly6NDRhvmIK+fvXX/3LLn8uXL2/GVj73HDpmMKtUsSLSIf// 9te/0R2KFyuKmH584423/f3v3pdrv//97wPhMiA98fjjjzz88E0///mePXtoB48/9pjO/3n7 7XT4z332s3nz5OFM+v3NN1tWSpUs8fWvX61zQsbg0bHjm37xi2rVql1//fVDhwxF93g7f778 mD+T8aYbxuqVq+jhN97ww6pVqnztq18Z0H+A4V199dWYbf78BT/+0Y95s/7+178ZCRv7d77z bbxqOaMrff6zn9X5jTfeYCbDJYTkvGeeiVaW+Hk5kO1Hrv7a14x85IgRX/7SlxYvXITrvPpy 5cv36dW7Vo2aP/3xT9q2aQvnGI04/jAH7tu7J1CjiaXu6Wr2rJkF8hf49je/2aNHjxGB8V6+ 1IxnUlq2bNmsSZNpU6fOnjWrQL78hZ58avOm6DanF+Z4E2jBo4K21rhp0+FDhloL8z6RZ+6c udAtlhOYsjq1a82de4ahXCe4ZdCAAVga3VAz3Kh+3bpvHz29u4j2eIcOeWfUuUQPsdx+77rv mcRXXtmC8a757ncxD1+iDpECcqcVZzDelVdivIgfOnZ03j7zuuuuu/GHN9iU2gqSk7RBK6tF vXevXkOGDLEussdoSVC4yt2ZdpiUCEYnTTrl3rJH4sWM58W8GUnjq64KyoYP6f31q6/+7ne/ S9H9zGc+E7TrsOdElJ/8xCdmTJseWt59190f//jHRg4fbtfxpz/+0TpCfl4s470UMR440c2/ +x3z1be+8Y3q1asRgN/51rc2rN/wk5/8JISE/b9f/waxejSbAjveb3/725jtnnvuKVuGsh19 /n3nXcC3DpB4sVjBxsl2sLSeG274oZf1oxtvLFKoEBFHsg0aOJA2sW7dehTyg+99nwCc/8w8 rLt7d4SsoBQdPHDA5W7kq/UrX958NpA//clPpkyaFJ7XX+IUBa9ZvcpiUalSJWd+8Yufe4/0 +R//6Edert3NH3//B+fnzpn9/eu+x8LHrNWhfdRnty5db/7dzQ6KFStaqlQpBz/76U+s4wcP HJw0cSK59K1vftMBU/uNN9yw6rmVa9aspoksXby4QH6mwLzhkd3rB9ddZ80KLOeVEQx5Hn+c HiHsJrTBeFh9x47t48aOY2nXDDE4c4kZz51wfO1aNQkBhIXErZED+/c/cvjIGVvJmPEG9OvH X3fLH/8oIqFVq1b0GS9m5PARsNF33XFH7vvvb1Cv7jPPnFY1g5pK139m9pxXX3112bPP2gKx x9SqWdNXUiJZ5smKe/59D7q3CmK5I2+9xQNBdPzpD384fPgI1RTjURR37dplwKVLl4kYr3v3 LIxHInmvn/zkJzEbQ5GWtsX/8z8f/8Pv/0DHCNO6d89ef1u1aqkHARaBJmgsDvCbd+a8NXLK pMmB8fhYvFpbxM9+9jMzZ8586+hRQ/VQeZ54gnS1M7zlT382gYm1wDvWAxsS4TNr1syvfvWr FNpNmzYee/voJWG8SNWMTbhUuHz58nF+WpuEokTaY9++r732Ggq2uGjw29/8Bh0XLlS40FOF xo8bT6ZhvHvvucci69djb79929/+1qhBzHiPPVayZElbod/+9rd0H4IRw8yZNfuGH/7Q47Rr 165bt+5Urx9eHzEeje5HN9zw+o7tkyZOuuGH16OKTMY7aHnq1DFikvzYLm9eKr3BkDxZGG/t mtUYj2LpjtScXj17zJ8/z8xDbjA7sf1qz8/pdbNzSOM1NrbNWDdN4FtH3ipSuIi1wBnXDh40 GF8xoowbN55YmzB+PDObBZqoF7x23XXXLlm0mJvXJ7x9HwqdJZ5QDZYwBGrPXLBgweBAThiP Yd80/uJnP7eg6Pa/wnicdZUqVOzfty/RRJR5+LlxxrIzlJ9Tp6KtUes2jz/yCFNPoSefZLKz DbUXomHmfeLx+++55+EHHyhVongWVRNOSle8eeXLlitbqvTLmzaNGDacO962J7lFsO7QDEkP VGtl/fGPf+yAAAxKmhWBpkcR4rjz9amnCvm1U4cOGA95OZ4XbywjGnr8CV/pmfNj/yEevuvO aP/2zW9886+33oqSbM8MqWmTyLjCrBKuMvV/+P3v//ynPzn585/93F2gwx3f8c/bI9Pf0bf/ cdttvtqxMI1SuV1Cif30p690I8SdPIiDCRMm2ohrHGm2n/50tHVsEhmT7F5wL15lbcs6t++q ZcYNXEXaXPWF/6tRowat8qc/+TGf/ltHjtx9513snLiOZ4V8u+GGG/51xx3aWIOsoZ733nvv bdSwodEOHjTI17qxnCeBWYft8ZYsWfLQgw8SmJw6P/zh9XCGzlAR1730Em7MlStXv379vYXF ixfT3J5f+/zY0WO+8bWrX3t1m/0IzblunXp8sJH0OHnKevrLm36h/x98/3vDhgy1xuknvMEw /kzjynN01zKly7iEUIpcVnNm2w6w6onq5DtlD/vHP/7x8MMP79u3n6pJrLmWfmg5sI1kFi5e vDgWcS0VhsXBIBs2aGjHMWrkKHa1a7/73WJFi8nR/OUvfXHJokVI9Jvf+EaFCuXJTLLOpvHv f/ubBciON4iWQAPJMaqmVFvr+/Xrd813vst6BJjlzMZNZ4ccX6BxxS3ZAJh9Md7G9etNk72s dTSb5fTU3j17atWoQdvs368/QUdjHD923LgxY7t37fbEo4/16tnLDpjUpnNnIayYc9bPmTnr 1a1bEcrkiROrValii5jaLIwe7z36yKM0qN/f/DtK7MQJE6MZOXmS6YLW7n1gJC3tCiypqJCk kujCcsXOHhlFTv0H0gUNiRikT4Y+Ga8xmLn+/e9+h23sNo8fP0am5c2Td9SokWHSeRSQoAW1 RPHiwYPPKmMppQVYF/XDfkhJ++Mf/mBxpXlqsPWVLV48gYYWkwcJkpPZ84FcD+jt3nvu7dun L/Jykt7VsH59BEFeZZvb8+O8k6dsd2vWqFmmTBnvi0IY6AWJoHVCb8yoUXjg5z//ueelyJFv brRi+YqKFSsxhjVv3gwcp1evXjNmzAz384y2RowrWo6MzSFt2rTlzrELbdq0KdXLbNNrSpcq jb6Z3CxPFDANoAvsAL3KLp0716hZ004s2SzR9umBQ4cMiZTPgwebNWuGl8Lz+mvRsR/zRiwT 4ydMwPyWLZYSYkqfNiMeiOOX8QPgnvT2pnhTV65cpQOLSPv2Hdgdhg0bzt5o9SS6Vz5na7Ky YsWK7dq2a9q0mS+nTp4YNmxo5cqV586d26RJ02ARwUulSpVs2aI5FjJ7xhC2nYnCmbxBJ9nh 2Jm4o5cvX4ZaQD4YKfiHdu7cddYXd+GMN2rkCM9pO2TG+/XpQzcI+JIsH9qzrVqgVK+qZ4/u S5csYSgfO2Yswg3nWVCQfhbGMzKq4+yZszp16EiVJbgtwEwj2ZuFTuyUCJlwHCGLjx9PlqXw Nfzk48WEg6AuZsdYnnFh7BqJrzrt9c6Yej6tlMspk4Fb4saZ3Ub++miNDOexPVMNs0TcQ4aV KBpqpgNdJ8k4Q4vw9UK57mTq06VOTnIXB5Re3kJrfGaD03OV2syDhDiSM06mTGY0pbGqknxQ aXwy4yniB8qYRi/Fw3oXqSSYiiXIJKSM9kmz5InCGV1mecbk/SYHJzIHGRxd2T/ZZyk1f0Jq e2/8bAve6YfKmMNMensnxPyFM97oUSObNGw4aOCANatXYyFCL9ipsjLe668PHjjA4rRg3ryh Q4dWLF/e1q5e3ToWcraKFcuWPb92DRGRnfEisjtxgnmDJ501zBJr09+hfcSrZ9wiepWR3yKF QDOwIGG9DCQb+zair5nH0fnIG5wZphS3cybTaXoiK946/JTKAKk3DbfMaKCnTIdK8s7sdkDG f/Ob3/zPxz8ePGkp98q4NpXlkmdMHuFs7/t8zp3hBs4YZ+QGP33ezpxxclkmHj1pk9F7ZsvM Z8zwFWUAieKOwin/S+YhzHP0Y+bf1DPJcWr7cDJz6s71aPFbzHiEjDd4+sKMyYxXtvCM8WsO RynPknqD0/fNPJs8Vvxc5+tKT52qcNMwK9kf5mIYb0STBg1sABg/+vbuQ1PasX171oX51Enb 6B7du61du2bJ4iV0D1av4sWK534oN92M089+w1aYNynVgR5GqSsrIhvM1MmT165ebXfets3Z GO98aO+cbc4hTM4qbcKUZZ+45GTWu8XtOSHs3Ig7bqjwdBc98EvWQdhRx+p5+vM+zcDFMN4o sqtf374vb9o8fOgwaiToY3Z6YlRo3KD++LFjJk2YaBNFarEWCH+gNDLiUbvpkFx8z8zNsseL hJgOqZqCD2wbJowf53bAIqkSL2gyWT6xKHv3JSqs08m1Z7kkFqRZnyhDrGUsDUGlJCoTXora x4tw6gt0jl4wfuzYZUuXXjzW8ZKTRliUz2fSLvmtP7IdXjjjzZo1i0fO7o6Jn1zCVCReNhTv qZ2vvzH06aeZJWV5GD9u3HPPrWCoFezHz8bzvmTxInFmAVR9pg4ZEf3uXbsF+DVt3Hj5smep alUqVZaeLGmGUN566whQKLACRJx/0f9ff8NW0xJ+Pm/Utg0yo0XzFnrI3p6tr3jRYpCWYJ8Z N7UTO3Vq5vTpDRvU50WwdWbCejh3boYZXgoGJCsFW47gpuyyI3V1OJ+xpdt8uGfgwhnvpRdf tGGjZLKckntVK1WGLcimap7avXNnm9atGJHZLZk07QnFH4wYPnzqlEnMaM/MmQPCUrlChSyq Jqai+SyYP09L1iHBdazD3AlgRwnjOXj22We5azm+v/+979/wwxt++hPW8p+wPmfdB57tHWoD z816TgPs0L79GZfEu8ED+w/w7TA3c9QGPSwe1X969+x19113Pf/883//298pzLkffIiVuU2r Vjf/9ndQS4zXwXvx4aab9NNd5AxcIOPZtRAIsGAd2rWN4NETJ/bt1WvksGEg3ll4jx8PQgUQ wVatXp3anTq0nzVj+qwZM8SniwmaOmnStMmTy5YqlYrVjLekkcmLnXfixEmECfNuuzZtuCX4 W1IZD1CLP5S/FSry+ut/wOuNi8ZPiNCG4RPUp3DM4JYchzMEJgt7rvtzrVq5KiiHqXKJD5SR nRvQEpN6vl+fvgBQrOr/uO0f856ZB3ixcOHC3j17Yjnu6V/8/BfBX3+RLyZ9+Yd7Bi6Q8QKN Mkvy0tDWGC25E3r16EmyZaE5+h/n2/wFCwYNGkQWsX/CxYEOtG/Tlpth3JgxrNhdO3cJ+Npk rh2/+MKLTRs3nT59OifysqXPRpCxevXejhDrGa0i5nz7bcIQcAyUjDMN1/3zn/90hhWUX5GM 1fTwkUP82pHR9QDZvA+wYMaM6Ry7RiKGCMNjpNdf3xFQzgsWzHeeXxV4JUBPOHO576iRTViA ZkcgL+VvwRpvu+22alWr0YS5vAsXKgTnTYCDlYJZ7ty1K0H0fbipJ/10FzwDF8V406dOg9Vi q+QlB03gN0wiwRMRQeJhMHEMUPDQJ3yRi+3rnn8eAA9Kk1bmQxcNEi/1s2fvXszTulVLTmeQ P7Z4PsNEiMVSMXrqcAlNVYwCkMRS1ov//IfqG8D+jnfv3oU3YAi2bttmt/blL38ZWpIL+9NX fgrAh5aoZfC589sKSvDVBzrp0KHDv/zlLwU6XHvtNeGk2KJFcTwbvzAMDe824QZ8LNo92l/u 3MlRy88bocMu+IWkL/xozMCFM575sQsSWQdrv3DBQqSPjnUnxiR8jsrRc+zY9ldf4zSHwo/5 oQ/XeWAVYTUCTMMxYRLhvk+eDFfF/44GnyZLyboXX6SsVixfAWIzizh1iX7hG/9yyy0YI8lH OGDAAF/hVLS3KED04UlGIJLQpg4CS0YZ64ULBSx+/H8+PmvGTKoj5gTvgquIIi3mz+eWxHga 61zyeVApfYK8ZFkgsn+9rFwFHw0yznlPeeGMFywNZAvjXpVKlbgHunfp2kUIXdu2Hdu3jw/a AUbyH1SqUKFzhw7du3QRU2eb17VTpy6dOrVs1kxcpgP/BA3Vr1vHgWtdqLEDpk6XQ8oBKHVo 115wQ3auCxIPCAhL/O63v2MFDWwwcOBAZ4SWOBa7ASKMozIZ79uEHkSSn/D2vffe94lPfILH AtzUJaVKlEwYiWYKF0sGBldHk0YRUDOEJuS895we8WU2AxfOeIHoyROM0axxYzF1AszBncFZ alStWrJYcdgUdsiSJYqTV+wiUoxxxLVo1hSXVqxQ3p4NrlrqB9wovV+F8uVEo8vCAjztwJap fNmyMtuKCxbhDvgXAo5SZy+IRKBHGHAIY3HWCc9AtWKSggUKOmNrx/KZMJ4wEPbPkOKFQBYV ivHIW+nMXAKV5nyYFPKQpcSFIdhPUJIGHirNeJcZDefI4VwU4wXeY9IUEsrMwJjO9gjNLEpN zPi0KVMdkCQTxk9wnsSgjjKW3HfPPYLBxRAJNxRiSLUTAFq3Th0ijspXl+WzY0cxfngAZzYS zFi/PvuHG2X18J44CZ4pegM/PFmwIMuJVWDXrt3YyW7QSeGYrqI3iuYWBRMkHsZjBQ3xYIHx /vcT/wtC2bB+FAPONBJyfjLb4NjAeHzfacbLkdR9GQ/6Yhkv5r1TjRs1Jgrq1a3HrMevBRVF HEWwzMaN+bKLFC4s8teBXH033nCj8BPmeDEX4tA3btwApSnEi+4HPoYnwcapdrff9neARior BmYtlEkhOx4FMzCifupTnxRl873rrrWRu1702HXXiR9l5Rdf97Uog8DDbiTQTiiKZAc8H1/5 ylfiCL0Mxrvrrjvxm+Xg2aXP/t///Z9jO7q77767RrXqkaj88Y9lTAlRtqJX/Er8piXeZUzP OWZol4DxdCHEA2JDkIHkFrAsQoDhbhkwJ44bB8zRo2vXIYMHyXriQIRbrH+W+MY3vl63Vi0h RXJptmjalK+MRte+TRueCciPAX37yWUiaqNkyRJCE95pd4dp+bgF2tA2JbqQSuhrX/uquFtG mqJFikoJwV5SoEAB2YfkPhAwwhopPYGgSRKPNkniiQoVqC+oxC369O4jJyet9cpPXVmyRMk3 3zwoQwTx+EKcwkyGGFbNd9pq5pgXnh7o5TEDl4DxgpWFIle2dJnmzZsjX3Aqhkr1Ejq1b1+m ZKmunbrI605vnD51CiVT2pnyZcpiBtksbJzq162HY/3jKO/TsydoGBu9/EhqLURxbjHRv9Nc SQYvLdTpj+Pt2wW5eCoBLMRvCKySzUGzYGt9fcfrYGU0yeNxrBAOZF8NAU1hy2ozKdAJPEAM DCeBzjkJPCNbi2eEGk1jGi8P0s3Zo7gEjBcmIOK9ba8KJcRLHHpt2rQWB2R3JIpRRL1/XNJQ woKgBQLLsCBHC1w1kWV/JcUFBJYNGKEnmR+/vA2eXNROnluvS6wpWQ7CeLJ8AuI5nEwc3Emb yDNxZs3opJPgHkhtmbPfeXr0l8EMXDLGC2HUZAtZx1ApE96A/v1BsZIb0DzlgChfpsyTBQqo RpLniTyMnPIOLJgXGet95JKQb4cuV61K1Tq1a2/bGqUGuwymKD2E9Axc+hm4ZIyXyD3cItIH DlNFBF4v6BNGS0Dn3Xv2+NuwXv0QF8MKKlWE8jcRimXaNJ43fMiAoaIQeFeI/730j5vuMT0D l8cMXGLGS0DJ9k7SYJJd0kKxpjSoX89XyWSLFy0yacL4qZMnVShXntuAVGzauBEHoH8ay/YX cmCmue7yII/0KP5bM3CJGc8wQxR9YB6aJy8f/zhnQ/Wq1TgY+MS5B2r4r3JlTvOqVSqrSaIc lwwuIuoyWC4leP+/9dzpftMz8IHOwKVnvNTHSQwSUJ2SK4p2le5TZJ0SsIIS4EXomcrHnbZb XE4JET7Q95K++Yd8Bv67jJeksnkn82OmiEvnHfiQ01n68bLMwH+X8dLTnZ6B9AycdQbSjJcm jPQMfAAzkGa8D2DS07dMz0Ca8dI0kJ6BD2AGPpKMF2w+mZ/zmfX31PhdO0y9eXbkZzgTRWOk ZD4+V5+Z+Zsv7SDf9SnSDS5mBnI242VHY57PXCDULBe+61WXFqgZYOXJJwvvqScQygBHjBRV s36XD7R3AjJVGyCN4X63Cbssfs/BjGfoEpCJJFDDxUeKlMT/fu5k95oJVgLR7tipk7ydIhIC DPqdPn5dvWZNz569xDGcu+V5vlIDWLN6jVwZ3bt1X71qZZY+fVVnr3jxElteeeW8bnfqpIrN hvf88y8YQMoacbqkxHkOLN3sfZuBHMx4KEwAqwKOii0LxpPWUshcVAg6qFyZJXgcJEIgZIuQ 4EwyCFnJfvXrX//gB98XOBsQaoFkIx0vviTjZCxNVFFWhW9BnE43yKLkwHGYxDNOuntSR+WM WhnRANSjEkAo0k8JVaWJw02TSkO+CtuXSDcpc5tUPgoqaBhYUnbHVxVdRB7iPceyYsvYLWGh XqU5DWWHo/7T4IT3javO40Y5m/EmTpz46U9/pkOHjmKO7vxXVEoS9jr1kYjBKNleZmklxA0L qoghupdmQq22lzdvUhA8cNHevXtCEuhUPsSD5OquXTvXrn1exs5Enkj+Jy1nKr85Vv8tFLIy 87hFbbTdu/YEvTF5F9JVSMJ7y5/+BCAu6yGJnSDsDr75piSBcoS2adNGVC9MuQhj5cdSxyMD m7sEXtW/TG6ORQkKXAxh9YraWVNCugqRh4Lyk6Lt50EP6Sbv0wzkbMZTAfiqL1wV6qdLMi0a XeoHRRQ6deoo64TUg+o0pJZN10w9a/wp5C9hIQc4UCDS9773vWu+e43KktgMyrRixQq9evZU JlL6sxUrlovKFeCLGYoUKdy9e/e//vWvxKZKLC6H9q5Vq5a6hJLJ537oIdyC4nPdd79q7IqD Fi9WLMTmxlLq5JEjb/38pz8V6r569ZrTYvP48c6dOunwW9/6drkypQ3v61+7OveDD6ru4kYy d5LkkkpJhJEvTx55QQUZlyhWTP4YgcUwd5s2bVLYUZZeqXu///3vKT4uf+GggYOUQZUlTVpR 9d+tGmmZ9z5x1Xnc5sPAeKHcHBnw6KOPUgiVDZMB6ZOf/MQd/7yjR48eGC8p3aORDLyf/MQn 1CVPpJCDfn37OVm3Tl3JNr/whf+rXKmiSPZrr/nu16++WtXyBfPnhwy5KJtodfBArlwSY197 zTWqr7BnPPrIw5/8xCeFIFavVv3jH/+YMoCkaL06dWfOnKXqqqroI4ZnVPQOeqngep1IAwMr HmSsYoNXfvJTTxV8UuXuaVOnafCpT35SNaUuXbpKgla7dm3Z5tVzJ6uxk+f62BVXVK9eQ5Jf Bd+HDx9uYPJ/eljppG6++feSO+XJk2fK5CmVKlV2F0XGW7RoIaY+bXc5D454n5p8mBjvP2qs KyA+/5l5aj5ffbWK25EOqSxoQnC+ivdD06rUZzBeJAVOPProI6ovBKVOaW+UunHDevJHnukg lDCeXCxKN6qy4kCKNCextxzvbx48IKyesMWBG+NkSnZofnVepRZK41VXXdWkcZQGNxJ48Rpw 7NjbzCo33vBD7KcT8vbJgk/qYf++DLy4pGxqNrwYB+Cr7S6HmtxnNrHKEjnTrl27r3z5SwKv rA62uPICW2vcpWfPnn4lLV3L2uRY9hqrg7ymqXd/nygrfZtzzsCHgfGYWBAWmlZ73gIvhYQg 9x/dcOOBffsz9MlTGVusQJfIXXhuJCIzjSKqnP/5z3+Wy8zJwk899aMf3Sj3EsZTuzyD8fr1 y2S8ufKOKccZGO+mm26SEwnj/eRHP4qDel/A8HL4CryQRRffyu1px2XnmZB+YoORWub+++77 8he/+NILL+bO/fBvf/tbwjncDuMRtspq40kGmEJPPRUYz4LiV0kTv/XNb0iJv2nTxm9945tN mzSWoA3jqVTuV1U+pc1evSra48ntfc13viNxcHjYNC9cPjPwYWC8efPmI6xhQ4dR6iRaJ0/y 5817w/U/3LN7DyqP0hYpdRJ/NGPHJxBQuaRjEY3LOX/0aJlSpSXefHnzywTSH/7w+7/+9dZX trwsXyCKPyvjqeXgvLydzCSB8X584402cljl61+/WqVbumgkA48fW7Vq5Re/+MWmKRLPSfUk QreyHhqMjEw1alT/3Oc+F1JWR4zXurXx2E8eOXLkhz+8PmE8i4JfW7Vs+c1vfF0WpsB4zZo2 SWU8aRaxuiVAyy1btmhQpnSa8S4fjssYSc5mPDsi4uuvf/ubRJ0sCtgAsSK4B+6//+qvfVUq aHn7ZNGcOmVqEDiB94TCf+ELX7jh+uvt3277+9+nTJqocAIr4q9/9evb/n7b5z73WXwlv5hU gY89+kjgBNYUN1q0cFHY49kKOkmgsce4S+7cD3FoOOAAkM+ziZj6GjVtGnPlyvWnP/5R+9o1 a4YBUDTfOnpU1m2bwwceeMBmjFDl+mCTNE7M9uCDD1WrUkXCqOBOOHT4kAd5/NFHidNvf/tb IUVvwwYNlHRWHWXd+nWf+fSnpfpUJ8xdOnXqHD1dr16Ob/nzLSqHSvL7y5t+oe6KwkZvvnno sqO+j/CAcjDjRX7t1avLly//1JNP2iMxLXJhoTx03LdvX5aSw4cPod1ixUvIlptpVMwogrdk yRKZJvLlzVumTJmQoX3pkiWly5QhWzjBfN2/b7/k1gMHDoom6NSpRYsWlStXzsZJ/s9y5crL FoOJevfu3ahRY0qgBBb16tU/fOiwnLlVqlRRBkwy3BbNmxmXHNgMnqHPsMezFRQK7KcCBQr2 6N6dwyNTFK9ma3niiTzdu3aTSLtq1ap6s+1knlGDRQJCObVlpqEvsr5UrVKN319hzWrVqqki ZmDlK1ScN3++rrgWWrVspX9Zfd1UGaZiRYs1atgoLpT77jiYjzAvvK+PnoMZLwvwKoim4DtP jsNBIu7iqWVXzJr8L0tXiWxMlZOOQ82jjM5jX3y4Y3KQfTazDCD49pOTKWPOejK6XVzMPdtd Mu6LiVNulzGwgBA4PciUeyWmnfeVvtI3e4cZyMGM54kCICP5JM8YzoSv72RUOPdVSedJJ6kd huPkLllud8avmbfJMv/Z736Wx3mHu5zrdpmPnPrUqe3TjHCZzEDOZrzMScyE88d5ls49s7Ek OXviwFAUNsiZiA1SOzpxdgY+U5ZGl4QJvbC3G+RbKt8GGXthvSVXpfYQS9ywZFxst9lHFeT5 eRpPo3m+yAfLyZfnYMYLalXMJxnFzVNddmd9KciCnVAi97MSDaZl6oTw0HOis6WSLzY4gxmh yQ4dCkBKn5DS9+jRt0DMLmA3hR/Azdhgjx59O1Bwklz0+LsFKZxDpgW7bpZBBlY0d5eWdJN5 i5Ljv8MKmDHUeInxXJd2ADmotxzMeIYu/bsqPw5e27Zt5MiRGStuCj1loUgvm9Fvfpy7OnlJ QcI4M3bM2LJlynAqRILr5MlevXoqmB54+9CbB2vWqLEmNpkmOiFoJQxXEhWhKkP//v1nz5rZ qWOnpNlZNcwst05t075t29WrVrmcfaV69erlyparUaPmwhicfVaqSgafNIjQ1plNiTWrABvp nrgsWXhMZiR2I3lMzd5Zx5mI3NN3jKYoQ7s++zD8GkmwE6Bt3bt1MxWhWap+Hs6E/ScLsLLy qswT6HGb00tA/MoybhIdXerV4TJhzhzMeN4fFOWwYcMcrF29mjkxxazwH2rMGV8zzQwd2rdX F8VPQeVKbcNEmdRIQQ4lixd/KNcDwavO38BTFy5MPvsP7GeHJD/DGX48BlI2RgX9UpvFq39W m0pQa8MnlSKV5gRDcRICUywSg+2Lz78AL5baONFmk5PPPPPMCy9EjrvsHzRdpnTpBPzN3aLP uXPnrl+/HtLgrFOUejI1BiI5HwaQxZATfuUyZUNOFqPs42FP5tv0yM8tXx6gQhmTQPU9ccac ZJmfy4RhLtUwcjbjATEHZti6ZUsokrx27RoHEF4onS9B4T4FjJT88ZxDnh4CzIXspPcM5G55 htKEhLT245l//ON2QOdDh4CJT1HzlLYtVrjIizFBk5PFihThxHPVwAEDXeK+Rw4dIiGbNWuu OBmfOAwXMSUdfdPGjV0yccIEjgTgSb3Fmt6pdevWqT0GWaLw2PbtO/r169+sWTM98+D79O7Z S4F1qLckGogDoGbNmkYCitm7V2+IcEU2ZSilD/MouESue9VdDB7MTb0xGG6xF9DhilhzpZBy XO2G91SBAkHi+bRs0Tx1+bBqqJ7rcaZMnkT2zJgxs0uXLk0aN546dVrTpk1HjBjBf6j8k3ir nj17jBo5yvysX7/hjTdeBwQ1FRz3oS6Np2ioEsaYsaIlxowZy5uiTevWrT2vmoRmHgZ9/Ljx O19/49FHHgHdduHE8RN4VlauWKGUd9u2bT2Xik5eh/cFgkPfBtCrV68e2PdpCXipqP4y6CeH M16PHhxxFDz0V6N6dZuZmjWqL126lMyZO2f22jWrVSnqipQ6d/YWoftR8MO5c8+cPiNQ4YRx 413F+6wi9IplyytUqICybRTDm27epInqYoMHDrRjaVCvXtu2bZC4gs9g1oLcSpUsaWnX26hR o/jxlPJbv2FDsaJFpk6Z3LJ5c5KTgrdi+Yry5crjk9Dh2tVrli97dvCgwfh/1apV4pjokGTm ooULJ0+ajDQXLlx0/733GXO8LpzikYO6tr/DLerAvPzylnJlyr7x+uuulX57wfwF4h6sC5gN 0UNI099g06wOHdp3oAh07NABt4wfPz7XffeFrMH4X83QLS9vCeuOvwL5pPQGDADIVtUMB5ol K8uDDzwAzlr4qULLly2/9S9/GTd2bNHCRejVVjRTQWxWr1YtWo969hTN6NdHcudetHixsocW l7x58ryyZYvGvKkrn1u5bcuWObNnqZgtOmnDunWtW7cSh4Eb8z7++I7XtoOzzZhuwO29Jrgf RUsVG9W5laVooUKehVj+UNpgcjrjdcc5EydN4j1HuC+9+MJDDzyABIXwwDELz1F+CCwLir9P r17oA61079o1YTyiaVG8fVK62RIuvGD9+nW+hl2HIipCSJX1e27Fii5xmQegUChKQkybIUOe dgv4LMoVE0uNaAe42r0wXpvWrYiRpwoWhFp+5OFH4mJjERR7z569cG21a9dRBX41aRzXW+cc VzJJjaTFixZFEql58xXLl6cwXjWi28Ixa0a0WACg7Nq5U6Q5BrMXjW8XgXKQOEf53j17H3zg wU6dO4uHsvRUqVgxCDq3c5UDXcHQIPqE8dxu7uzZvpooSb7bt2urHwjPRvUbOFmnZk2kryq9 Y8vX4oULYdAUuLeiQc84CbNqVmnXVA9fmzVpGuEQSpZc/uwy/JzQlqXNSzG2DRs2KBplzHTR EsWKLlqw0AriwmiJqV5j+fJloVvIoeHDhls+OnboGJaMJKLyMpBVl2YIOZ3xeii57sVs2bwZ HYPzI3cUbBexbdurVStXUbeoV4+ezZs2xVpjRo/REouKQI/kXUQoTYT8OOjTp09c46Hl889H dTAD4ylstH7dOu3xtj5Rw/Rp05FmYDzhORivdu1aGI8hVJsMxpscM17/ARaC5cuXr1m7lh2V ukipU5hFvomhQ4ay06xa+Zy7h1tPGDcOPwcLCjVvxbJlWRiPNJg5Yzp5VblSZbqfZPj169XT Zt/+/YSneHYYmvnz52G8fHnzzJkzd8WKFQBlFcqWjRjv1KmK5cqJMAyP3LF9h4DwDh86ZFC8 RTnFjNeOVCf6LEmmgPoAc1eubFk6uQr1JDPgTq0aNaSrSBhPKv6pU6d4Cp24iq2rdMkStsTl SpdW/dNJJRCB4BYvXkJXN59DBj89bep0ANfiRYsuWbS4Tq1a2hi5NWXF8mUe31cQ9rHxy/Jy K5YvB/j24bOw5GzG69ShA7LzhtauXmWZP3L4kIrQY8eOmzNn9tZXtqrCZ9OCRqtbpNeuLVu2 7IwZM/55++30yUB2djIVCY2pU9lRtmx5GcosWBRjxjtRvUoVYT5UtVtvuQW5d+3WbdLESRiV MjZt2lS6mQiAu++6i/Ylao5eR1oWK1x4wrixlDEaoOKbtCb/mBDYcWzkShYvMWH8BMTtdkgz ADi7dOo8dtQosbyRfjVt2t9uvXXZ0qUx451EjuwiMN842bpgVJUrVcLSipm5+7atVLjZQn7b t21H4tE2d+/ehR/69+s/b94zIoawa/v27QcPHqTEvP1neK6tW7fBqhmzqaDaPfPMPHFStqYl ihWn1EGWkdgUh9o1a5gBxQynTJla+MknBUlAfs+bO4eSSQCSe+Da5u3BXLlEA5oiMln/BrZw wULMbxMrWMmiYAJ6dO9mxZk/f/6/77rTRprMr1O7Di0gz+OP7XzjdcqzXZyWdolUaOuXfhg8 Bw0Y4OmETRbMn4+4jhnvQ6Vy5mDG8yps53CUA+YTlISyrNYtmregpciqYLPEQgDfGCwco0aN FlBDY6RrhU0XKUT+MGYKnGOnmz17Djt4+IlWNnPGTK9cLDnCcvLZZ5996aV13j5SYyBhGGRI wIrdunbDdSLfhPkISF+37qUgEl2Ojok4VhDCSqcvvvCiMtQDBgw01Fdf3Yaw3IcNEwNoMHjg IMF77CUqchqAreabhw5ZGt4+dgxSFFc7iSXQqBxJrvUULVu2tDti15HsqEWLlhs2bIRWpTC3 atXKGYKCqta5c5cRw4YdOhhbjOJ93Yb1G8RGNW3SFOLUyfA4OjQDwiNog0L4bWbNgOAmSw8r CFMHcaeCvFgkthn9WCMYThTTtsS8tG4dY4n2Otm69ZWxY8dQHQ8ePEA7ZXbasH4dZcE4hw0d ynwiSNLwbJLhV60pONBusFu3bpCufsVqfBI0BTrLwAH9CUD7z2gVjLyCaca7NFruxfZyNhzj acRjlhUlC0IyZq0zai/7GsRgGFZG+0x3Q3J5oN3wyeKxSAFyngZwRs0yP8mFp3vIhJVmsdpn ONDjeyV3yfII2Xs7x5nEMJh9HlIGkzF7wcmS2jLJCpM5RWdBlqZ6F7Iv52cdW+pkJpdk91KE 7FUXSy6X2fU5W+JdZpOZHk56Bs53BnI244WlMDyDv/+NdfG8nEjvgOTM/hKMMAMReib67Hxf 17u1o6clYiQW25dOUMT5qoMwjKc6gqWE40QipaoM7zbSj/rvOZjxImTgsSi5nWc4cvhIAApe SlIL4XMAlJlozOzE4tY+4dbnRUoxgIad8xwpn0Of59XbmY3CTlL/zDkh7V8MXr2Ans5ySUaw VZxEmCE3mvaTMqYd0f2xY8cxYvxconwjS+alueWHupcczHgBlGxbz5gmHlQmr8R+EA4CBWec jMD4Z5yMfsgkkYTQkwszcsyePMkAGNIohJkKxJCx0mceMJ8wHjCuhPMZvUUwwwBFPM1FbJvA GdBtsgwi3+R2qaPN6OJsMUEBpZ3cInNIp/tnfhRcW6tWTaCZZc8uCyDIlIfKGH/2543Dfc/F 7R6Njy6a6qpVx4we/eqrrzVu2Ei0LjOmK3kO1LiHs6lZs4Zmad5710UjBzOeoUNISIk3e/Zs tjKZS84EQJ6BwwxaEBRI9l0+MRkLh+NhLlIrKyDFjRs2nC4WHRN+zF0Z3fCYAXIxq0iORBSk dp6p8sX6WCa78kZwasGy6DbcNwnbTa6dMGHCypUrU7six7MPO+PNRewSc2PMj107dwFzEboO xsUgmfJ2U0N44+CjTANSKmDVc51VdOtH5l9wNu51YLfXXnuVvZEbAGhG6he99ezenbN029at 7psYjd+V+D7KDXIw43nfDOuSWCZEiWgGDRhYpWrV3r37HH377aefHgLhIWPCqBEjYa840y3M cICcXc2aN2fdrlql6jPPzMUwjPi0MokkeAIgs6Smrle3Hm8SdPLokchr6759e1u0bFGrVm2+ JmEQfG4w+ERcseLF//WvO3E+vziQNN8G1JVkDbyCL7zwYrt27bnRIdpwV5hoRvmypcsEGyZX Ne+WA64tcrtJk6Zt2rR9Ye3zd999N+Al2z1HWeUqVYYNG+7K0aPHcJPobeTIUXXq1DVgcBl4 EYiZkLrChx+iQrnyQQ8MH+tRl85denTvsWPH6zzgnpcj0Ug4SPRPUXRrDhjhFJ4XkitSHUMs YmYPiYQ3G+pMJD0DAwG7hK98DOXKlnFt8utHmaPO89lzNuNhKlnDYrmBlE/xDpUvWxbFYwzw rkKFCtG7+HaLFi4Mc8hxDOj477vvHj92HLAvyCVvFXyTNZs/2n6Ok7pr5058g8CNWKhK5SpL Fi/hXwawhF8BziBDZKpdumQpkQKECc4CRgzvAh8t1R9S1icHF6xww/r1YankJuKnKl2ylFCA RMh07tTZ7dQ/AVXhsufyMmYAK5UPeL2xE5TzyBEjXFizeg1eNU5zmaQrV66M1qGN9UnMQoE8 PWhw6VIljYTHMkhX4+Gdc2DwHGikK6aSahrcxIVgJc57XoPx+Dz4ADe84YSYrE3AAIQYn57L 9cbDKdxB4plEVjds0PD5taejoghtqVy6du2q/arnVsLKOjBmrsjZs2afW2s9T9L8cDfL2YyH Vp59NgPn4cVDPwyPBSBHMEhHvbp16J8L5y/o1qWLkyWLF/NVPAHUv8zNI0cMf/Pgm+XLlFa9 AJoR40lSBPW7bNmzUBra8+pOmzKldq0oHK5i+fJJqAuEIfRJ7ty5582dC5gClmkSixQqTGpF AMW4aoIIicGDBgYEI7h9iPSJfcCRrLMdhbDhLyaCpkyZ0qFdO7gtTAuo7VeLBeCVWz/84EO2 jlKhLVq0MGStxYEtmjXXpnKFiuDaoGc4n8pK3YwYYOWqgOR6bfv2jh07YoaNGzcEMKSFwNLj oG+fvqCVXNjQBWRUtapVwFwAXPwEMSOeIEgt0ljaX0tA4EN/HYen8DW4+PbvP2AAAGh0yxAa 4om6dumapFT7cHPORT5dzmY82wxbi0TDGdCvX8h4CQMFMIUa1r30EjgFxsMMJYsVI5QwHigW /iRVYD6gojAevnLV9OnTevXoQRSgS19VCALdYE4gScqWKqWyl5PPrXgOdtGODriJXgrKGKCP gPwEkRgCE8qiiCKHPj0kpHZu0gT8MuCeMwwzjjEerVI8IY6dNjWKbNq2bWvZMmVF2UgyLawB OLNK5UrSh23dtk3RH1wEo+zXls1bIHxISLAsWiGciicNMwAUTrp6HMe2ZDHmez2hGo2hUSPA SAc0zxnTpoO/gNFE4M+KFa0drVtGz2t9oW068AjgY8IvILaC7HKSug5ikkx1OLCQlS9bThAQ /Tlgr23zwMqTh71I6vwQX56DGc+6Kw4I2M/mR6wXzSpCSxYtKmyMQkX+UNIYJKOok3btAK+e zJ9fcQ9qJ+Ai/oTWlTzTV0GiwJODBw/Ony+/JNBUTUod0rH8Q3VCZgLv2klWqlDRBgnErHSp UsTUww/lxqgLFiwsXqz42jVr8z2RBy4Z9kpyS4AskmrihImdOnTUj3BvgwkEjSswqruDO9tb zpg+TdkgLI3oGWkMHnga4llsgQgAjya2TVwfM73dncD5WKlr4MFJb2OzaxXWoDxQIHR/NS5S uPBo4Q6t2xCSJCSkuPNw4bZ/IP+lSpSkb7OFkI1AniJ94dGo3/aQ1atWE0aQdBVYK5C+kZtq wFGg6nHjxi1cYCzP2OtaDlh9NbMdtYKYeboAqGp84SXyY3xImS8HM17AFqlZ1a9fX2YMUdi+ KpwgqjJKanDq1Lxn5gpPhVoUFcZ2ggPZJ2logkRffPFFOx+bHNs8+5nVq1d16NCBGAQRtPvC J6QKsbNl88u6xRiWfVYNbZCySBlCxoZQYBty7NWrN7aBzHQM2ElRpPFKaiAsdeXKVZhEEKBq dcEHsHvXbtB7Ymfzps1GawtHAut8/vwFbdu2U3VMG/BuDYgOGE7PhVvkcdEJeKf+RXB7cBuz lSufAxPt06c3QRfkUtAAlyxaRFZ369ZVnmmTYz2KvJHHjsFG4gpD0obMpwaDU5PYrP8Vylc0 5kmTJodOEmZLpfloqnfvxmYqNwgFZGSKZmzYcA6MYJ59dslS97XrE5KX2s+HlHEu9rFyMOMl pJboP6mQwiABsvwUnjb5KRycFQOZ5WTYRGX/pE5flkQSoXEqyDO6XYqPQ6g7AcKtl9ptAhk9 Y/DvkMbi9NPFZBB4JvsgA7onOZ/l0UClGVTDr+dgmHMgRWP80BkOj3DmYmnzQ319zma8nPtq zLtNXefOnXfv2nlmIsH3+5nYReWcjtj2PME37/cAP5z3SzPeB/Zes8irD2QciWs+QtsdT8uo 9+8lpBnv/Zvr9J3SM5DMQJrx0sSQnoEPYAbSjPcBTHr6lukZSDNemgbSM/ABzECa8T6ASU/f Mj0DacZL00B6Bj6AGUgz3gcw6elbpmcgzXhpGkjPwAcwA2nG+wAmPX3L9AykGS9NA+kZ+ABm IM14H8Ckp2+ZnoEczHhxmscMMH5I7hhCb97rS4WZDLMQgIuOU+H277W3828f7hINOyOO4fSl IVDg3J8kniCjcQhNCBkv40+YkPiJMrJZJ8EZyU9JCEVSFDI1ju7MsImMyQkhF8ktUoeadBs1 eIfohIxHzoyWOOszhnGeT3xD8qbC857njL3b1L4fv+doxjsugaRMOwoehPcktDQqzfMeP+Lo JIOQux9QWIidIL04LewJGUfE1L1T6EBCxO/xbqebG3AIKfQ3yTLkZyvHoWgw70hGgR/kL1Ip QfomyQX90YnAQtmZMugvypwbLUzCC50PS5IDl8R3PPHWkWjqhCbs2bM7JErcs3uvZ08YSdj7 jtdff3Xbq8IRpb2QXdRESQkTzU9mHIObRj9l1pR3awUbBPueIywoZHPzV4LAqBTz2RbKI6rP HDoUErqde3rdyPOLAIwm8JwgbzdSP1C5lQt+X5f2whzMeN6KkiCFCxcpX768mjvmRSEuQdln ov5Px6Elj5p6gAIkhhg3Zkwo6dy8aZP1L70Ueli6eHHd2nVioZqZqTqOxQ5SMdBxdJz5axLz FjFPyoqeiKZIIsWfRFxYo5VFkU9JHGo476/g1Hx58qKSs5Kdk35Sk0z6oxrVqklmMWTw4Pnz 5rujNCoSioWrYu49JEGLHBOK9QiWlQRNLgwJHUJ2DPHjhQsXln9T7LmvIoNKlyotq8XmzS+H B1RJS+2X2nXqlChRQj4YZ6Q2Gz92rIygoorDg8ho5hYh2UT4KLckv2DqY2al1xMnhSM3adRY foCe3Xsk61d007ipg0mTJgmxdZyljkKsz2Smr86czEOHolJ7wurDTSPxHmVJy3jvyd39pNRu wwb1w7u7tFx0Ab3lbMYLOeeIK7m3vH605aVaBRFEyE0kdlu0NbKTalptGhOuio3zcS7naJmX EkKWPqm+oguPH1ezTra8kKlOqhW14MK6G9ggfFSl079mqhxbm8PqLhDbT/v37Uu4S/0gvzqJ evQfsu6RTqFlLO2itV8AePWqVTrG6YZcK/+SxJsPP/RQKKyV5Y0GaabmkdQS+MqodCv1g1QU 0YAXLmwYF5TMYOAZM2vXrOUWEq5MnKh82Fi50qSZqVi+whtv7JR/dvLEqFyZgXhezC+4XslI SdNCD+5ltP6akwH9+jspnp1AM11uahyRgD1yBMWHUuYmXz9SV+jBGwlBydnVPyeV1FMQk9Q1 53oIExjl84z0jKiQ4N69+6gbo0eNxn6+xm9nj+eVsjp5F5HUlUj32DGZF4sWLqTCkZ/27tsb K9sIIJreAwf2hzGEN67iZ4P69dKMdwHLxBmXmE35C6QeMbOWZNXhlFaUXESevFo1a6urLNeY 1H0Ki1etVk3qFOWOK1WsJNlJqxYtJUeRztkbVU1WZjuqZs8ePWlRsnFpQ0qowuU91aldS+eq z+lNTgdZfVSQrFatuvSYbVq1/sMf/oA4QqJOmQUlcZHQWvE3SVz69elrRVfRynIg54ocKtu3 vybZniRIJJWsE15/RGsxN0pRERjPZ9SIEf379lXQTycJC4WfgiClK6q8l5o8V5EwCSw0UNFS TdbQ2EdmJDUDpSSUr0VWmKaNm4Q8ufILyq0iA0WD+g0krUDrMlyE0sqknPRHFqkgE5yRu1Yi I6wlHYb0FmHOlYyVRUJ9eckpLAFS11A0ypevgLFNmhTD7qgs4e7dewIDJ0MKfbq7BIcmPzCh rKS4i1yVf0lqDPM5YcLEAf0HFCxYUBHZpc8+a3klq/M8kWf9upeGPP10hQoVpcawQjVp3ERi JSl0S5coIfWTZlKqCuo/8tYRiVUVnY5qa0s3HKeiqVSpcolixcx/SO59scR30dfnbIknKdgT jz/x5JNPNmsSZbZq07pNvz59LN5UUDm/VCr2RjGVcseoTQlLqY1e3rzl3rvvlgTJu5w+daqc JbNnziI6MJu/UdHWoUPkyUOyVE2aiaRjRJAstxUrlKdrPVXgSbLIvkKbGtVrWEddSNkjHCSH xhV66N2zR8F8+W0nsJZ8gZhZs2NH30aO8rXIfSLlHiZKDANy+6mwafwouE6t2mR1tSqVSYNA H74qE42BQ+72TZs216xZK17Io0IRDtq1aZsnTx6FKQsWKFi/Xn2XHIlqJ0RqcMkSJf/fb35D vURrmPmlFyMt2pDGjBqFQ3AsQmzbuo1nlKEoqJdlS5ci2SI+jzvv2qWzTDAOqH/9+kVZKnCm CntPFsj/zNw5tpSFCz2Fc0yC/bAMn1RN+UtlH5UwSh7BaJwnT3quSZMmWhnDE/krd8uTBQvK oSYHXKsWzTdt3HDHP26nvCycPx/34u2e3bpT/vv37xfeoIQuMhpa7yxnJtYyKjna448+Kukb SViiaFF7UfMvMWmp4sXVpldfVvFtSdaktLHLxefyXHl98jgaUprxLmrdiFZf5Ua7dpN6VeYv mpIcRCqJSuq65eXNqEeWS6RJF6JxeT1jxoxWAN3uR6lXKopMW7Z2gwYOkM6ImiR7LD3KCrp5 40aqqWoMC+fPsxVR1TH3Q7mbNm1WuFAhRRLpdWQdBpOtCK0bg0xbJFggTYmrH3n4YTk7EZbz XraRyDOp6KQslI8+/EjtWrXUHmgoU1hmfRUXSs2E2hy0bdO2atVqhC1VU1KjIB+sDldccYWF IFAMc0iF8hVcHudgjxp0aNe+b99+iHhklIEvSr9ZrVpV2fgIfyPctHGT7KOSiNKyQs5pOyvF n4MUOnb8mOxpshjGtZ2lEjtcoVyUri/6Lb5X9WpVg248beq0wYOj1NG1atRcv36DdKO7d+4k ssuWKW3XJ0116HDNmjVkjgMZqCRfDCc9nUfo27t3xM+ZezNZp3DF5s2baMKG59WYW3J42dJn B/bvp8w19Vj604h1T5zUZt2LL9FuHnzgAVkGZVKTetAW14pmybPHw3gjRgwnAx+4PxfhLJep h2VzkiLR17pxweeN6zeEEtNpxrtYxkNDiMacyq4Z8md6YWafUkfJrFq5UmQ76drVrlob/IAC vKeqFSsxYsppOX7cWGqkjF00N/obxtOPVJxv7NxZQzmO+fMaNWgwYfw4RPnmm4cOxkVV9UO9 JLJY0uSx9tW2SlXUtavXlCxRwg4K71GfnJcXjG4TLrH8Y0V0tmr1qsM0uSgzV/RJrClKk2um 7rG0fOq8/uWWW9wl2HAYFSWcJaAsGWHfZdl+Ji46Gz6SF6JCB1jOoqNz+iHpLb2f3KHO+5XU tdAQtr7Wr1sXe4RryZMK5ctZODz+sbeP4l5LQxBKfu3bu0+oEe9DZ+vff4CDMqVKrd+wgagk 1mybCRP6BR4IzVavWa0EswNSS20TBzpT+hxTydUZKdjRJ8PIVKZUaZk5ZWcsX6YsPqGTV65Y ycj79O5F37ZQhpkk8IcNifIUW0qsj8yqllEagc3qgf0HPG+ZUiWlVLXAUV9NjvRNqtWSvQS4 bYOnsxOJ52dZtGlPG1cuiu3ihVPuV6nUbc/oHl6YysNegL2HN03BkHOWQvj4Y4/LZCklprIK FmbWDUqLNyd565hRo627pCWZwDxDqWNIWPfii6+/sZNiJnlk3dq1WR3Z+qKq3IMGIg70pLFc sfrPlzcvC2SDevWdl41PyXXcpZ/evXrTyuyC6I0SUBIINDELBIlE3EkFL5Ulug6Gh4gxZsyU 4jJhJAdVK1UKxqFEPjiOWsfqn61agXz5KYoeH/V36tB+aqzU0cQ8e9KPgsaFnnrKgIsULqLW NLovUbwEg1CdWrVw7zNz5lIWlExo37YtUrRm2Z3KqDtz5ozQA6lu6iQvpKiTyXaMZL6Huutf /6Lu1qheTRZ3/dDeLXOutQzhwCWLF4WEtj169AwSL8seD08/v/Z59lL8Zj3yq+LYD+TKRQex ajxZoGB0bfcexKORFC9aTIp+Sqkq87LQSwFM0bXBk5rNg5PVrFk8D9RL2RatHfJk57rv/pjx mq5eufLAwQMVypbDqHazkhRbGW1D9J+WeBfJeiet0CNGjLQuBlMEFUj9ILttTIi1qKCUfsV3 hg8fMXnylI0bqX6bvWDrPdcTQqRKIeVZs2exgqgr8NZbR5Xz3r9/H3cg4tCnv7qVqdZ+Q4ER Ak25Dx2+eehNQ6d5yodp48SAqdkLz6+VSRZXUJ+wmeyuVFbjkQyXuT961LhKOCmEaJJ3H+wl EmwmcxHl+Vy1yvbpbPQRmf/ci3mDP0AaX5TnqVhuULAkogaT9KMZ48eQIUNtdwMvrVmzdsTI kbt2RuXEJH72UDNnzjIhhBLzCTvTM1G6segT7fcOHpRp0/RqRvvVP51NNls7KJZh02WG5cx+ bsUK+gLiHjt2rLoRJs2qpzG3xGvbtgX5lvrx1XThEzMZKxEnvaOQXt4uMVS091pf3vwyFXfi xEkyoCqDYdiS1StJz/eowAMlxcbPezRLVlJjsAQsW7bMhFhq2V3pI5HJ9OhR6wV92DFXkzdI nblYmrtE1+dg40qqNMiyssZrWkoKyxRpEq5Krj2zslesAmUa9MJFqQt2SjcZtofkzFnzYZ7R PsW5Fw0ghR5Dsyxn3tHwdmbyzOT9JeNMJYxkAIHtU0abJQ3m6WycyeVZKIOim/I4mbXHYqUx Ow0lg8nuToi4OqWj1JZZJjx7t6nzmepeP+sYkrechU4uEeNcbDc5m/Eu9unT16dn4AOagRzM eBbLZPRBOwoC6lLOZOYtguk/rLJZbhCt2SnFYrNInowLM4Esrk0VO6niNFEss8jYLG0iQGnS W1yJ/Ayxlu3howk5w5OWkez9vc5SIo6S580+1Umb0HmQOUGSx6PIQKWeqUecgYzNuCS+PExd xtPFVplU8Z78FCpsJhpH7IS/pDTwXmfq/NrnZMY7fpxxcssWxRG2ej0HDhxUEOHSTrqXGpAT sQUyep1gK1lqptIJbTDsKjOoTZVwu59Dh8LXBJpoJ7bjte0xnOKg3SZkhjH7avuhyMGGjRtY U5JLbOE2bNjI4geWoQ3XCD+4j32XF+Z2Nqs2OTjQ3mzbtlc3bFivOOtZnz1GyBzne1SyyxgS pMj5kUdGK0NVOMVGLjx7BAw6cCAq457Sizb2xgyOYRjhjRheJuNFLGQ36CnswWxVudftM5l4 wzzYHJoFM2OEoddQKzce+UZmEvMMPrpp8+bDbx6KqDae54ALDcgyW2VTcekX3/c0U+fdOAcz nilmqCxQoACsCazjunUvhepwyaoZjkmEQAepP6WKytS5ymJrdgksCNe58wiCAZBlLwJ2pIC5 tOGLZ0EN/b999K08jz/OPZg5jKikEeM7uytfBXplZgRe4dTmxEdMjgEs9PB8XGndYI6+fZQR r06dOmXKlKlapTLjQblyZSFu6tevhzIxKkc8MynPHuMNFEjevHlq166lxhBTx1nsMXFNJYUs QXaAeEKxsWha4k+4Y/T3zD1laj/hF2WG2HK13LtnjzEbQ2ob/WGApwoW7NGtW+jfje6+8061 BMMtNN7+2nYGZC+rR7fuVpAWzZt5BP4DDIMhlWoyh0yj/EChZxeqjlKkUCHNmG2xPb8O2IqZ dIlnZyKGEIAo0nLRosWKGbHfqj2YEMB5c8EH0DBnM556yEyall44abYvrlXIzEgURNrYKedB +EFEYmo+xueDaKK3EpePVXkHXDPWTML6Gq+cQb+JpYSWjGBPFSjA4a6BGIg+vftwWwErhVcb tB1m6wL58sVglIhW+KYfffhhjuCEppVibtUy8inrMwYiRmOAseKWcEmtWrWA9AMnJO8/0C4X Ip+BS/Ati2tykjfZsRKtHhlqhA09/HRW8tEtaczUHiBabkO0sg1akAio0C3RQTQlAtOsRDOT oSJGz6gSYJ5HH2vXJipbCQ4CjRlVoowrwifzAOf5+COPdOvcOQyGizXXvfc+M3t2Mg9gesEd J5ri6FtH98NVxvg1dcswlRqd4cIgVONhHyxetCgfaXTy2DFOF04Lx1FVtvETeGUxeVRbs0oV r4mnbu2aNdtffY3v4aww1w+At855y5zNeKRHcKBXr16DLbtA/ny1atYCwmShZmeP5EyFCtxK bx48wDmrUhwX9sJ4DSYh8SpGpUEFig+KzYwZylYtdQbtOetaLxicivvBSbKOeAp8kvAqMATg RQSJOHWKpZ6rmi+R6zkm8ij+BU1wJXNeE1YJbXFgQDBpYJ3u3r370qVLUjknNIM+4zcH91WC jz+NX85JhcSqVKqs8BjAGvs7lGapUqVZ+XftysB2ZhHvboHTVN4MHhdAFsLKs4tRgLHi4Nqz ew9NwTKUcL4DZQBVBQuPQEo3atBQnc0O7TOcjZwf0KfJUqGN9U5XADrd4yqZ3Bgtm7ckIWdn egWxfdmyZUBPpkyZZM6jQcbhHcFJyNOdN29eJQq5ExJG5QUh3HhKleNzkqfE2+TM4OLHaSbc JDhP4sGaQagErDaVRNG11Mm83FgujCeHM16PHqWjaoktOUxfevGFwk89ZTvUqWMnPiLeapAO OgxZBPFQIF9e72zunLla8sMiRE68ShUqzJsXvdRkpz5s+PA5szNAIZzOMGj2TlGlxZgqufgq la/A+5QQh57xGJcgwIqTsKMLFixQjxaAJuqWpH3r6EMPPIDhjYpqRMKAGloa/nXHHevXrder oIGBAweWKF4c80TdZm6QOAA5fMkiG6rRI0ciUGUrLS7aAEz97re/LV+uLJFjm9S/Xz8162hx RERQIHm0Bw0cZCsVhwedNAlPPPYYqlUxE4DOP15paiGOov268OlBg1yVaoYB++IfD/w/bOgw /jF4zgQXpta5KuoJ42kD0wyGCnwXqk+bDY44LLFg3rzQCdfl7X//O7CBn1q2bOV2XkeRIoWB 4/bt248DKedQRDz+bhQumTFt2q233NKlSxfaKfyDMwKXbv7tb82VZRFWRl1eJ7naoXA9CICO Pv9w880BqHR58lsyqhzPeDVr1qRu2QhZv4MONnTokJHDh9uPzZsblapE0JDQ9WrXpmpGK3GL FlMnTwKVUBQOzYnKCeQO0QurlS9/vmLFiou7EdngQBktQBNUy6VrpiLGq1AhqJq+gkrnzZMX TkW19IIFCgBM5H7oIVqQJRk+m/pkli3DDz34IIe4S4gaVIWRoF4QKPBkYm/k66cyhSUgiCxA DRU2HSQxaQplUi89jnEK/rXkI7hAo6HzZXE5eB+AG9hIkPxAf0ailDRmo2F6EIoiafn4o4/x Pnv8m37xC0IvuvXxEyJqBw8aDORx/3331YCfbtvWQz2cOzcfOgBa8WLFAn4a4yUSz1chObly 5YJxIzltPufMmQPdakkqWqQIHGmIh8J4ue6/H07aMfgIaCUtkWlEYGGIRQwf8U1hJxkdT5qM Dx2wCVFeQGHtUe0dDI+4BoUNwDfAIC1FMFN26tdvkDfPE8xI4cEv50/OZjwY6UBePiB5ETWw uAwcOGrkCLssaAdfMQ8oE5Cetw5WInATjIvwQRDEEUNZWOnhLQirunXrQUELlmFJGzNmTFQV uUGDu+++O6hA9CUlvyPTYhy1ybo4bNhwberUqY2qFi9eMnDAwN59ehcrVgzFJOEFkPIQzy5n PEiWc2AL28UQFuRDAQY7jqg/7KxOnoRTiwo4xyFnoQ2lC/W3Ugx5bCQbx40dg3UTksXqNjm+ Ghi8OAlJ4kER6M0eD60LHfAroCblmTRjtCDxdFi0cJFhQ6OtVwhTMkVMGsWLl6BtstzQZgd4 qN69WTUee/QxS4aW1i97vNB5vB7tJ6ysbqVKlbIAqWXta+/evXLnzq2ZWdKG/blkyZK0DA9I /qsNGEYOj0JHTZ5C1I99e/hqd0fERQcvvqASPXEdxjl92nT6vP02DdPX2lHQUwb0lApqHtwr dcN8ebJfzma8Xj17jB0zOrwnaK9Qu9yajbZodHQzWigwJ+t8zWrVAb5QFZ3Ei8EDUIt4EjmG lxQ6oaAmqmY4s3XrKxbXcEwpgg+0ZcowK2T60yiNtosJ9YDVU958Dd2CUJIVjRo2omjZaFnR O3ToWKhQIbApVGi9V9O4VKmS6DW6JCreesomqljRIqxEemCTJFHhpMlnazwiwyp0SyBJ+z2B diSAzuG5Q4qHLHu8iPH2G3aFsMezKgm9o28XyC+uZy5IKv4sVbIUiZF6LVmHSZInip9iUbfO 0f7NBzbVGpekWkiaUfYE4yRfgSotYck8AH2VK1OO7AJ8hSZjLnYX4ExbNc8IrWpmPKOY+qAw W3GaNW4irI51F9SOUs1oqWB14UKFCepXX32VZdhCCZ7qwWkxwLelS5acMSPCml6ezJY6qhzM eKj21ddeQ0+BYmDWoxQpJ07s2LH9jTeiRADIl34Cx4iWvTZaH20zorC4CPjkKVMIIpEjYTqC LXPH9h0Qj8G6Gc6Tb9Sz8NUL1qe/Wd6rbqNbZ35sooiUMKqQQGn16jWsKThWz4gG2jNE6MQS ZpWvhpdCLicobzwHBuVyEQDMKoLiUGSgaY3Jeaq1Y3XJp02bTrsL9snsBBebUt8Kj+9XEl4k m8gJC5PIJmZAV3GgGXMiJTws76idYWJn9ZMbKc4e1gVTDU1JPmahJLalCP4afzSz3oVY2PAh vYULG6ox0DPtt6M68ps3G4ApJV1BQ4NETXowBpZbQXfhwe0bx0+YCIubOQ+bpk6dRp671/r1 68yJZchPOcF/npONKymJseL3Gn+SXVMqeDL8mqwxWX5KKCMxsaTSUyoqJfSTnbhDgo/TFBZG kvIJYwsnU4+zf40vyoBrZHo6znVJ0ttZB5Y6pAyBlg3BmsxYlgFn0daS6T091TGiIPtjvtM8 pK7xqccZbJn5JKlskzxdWALOMXWnW0bzl0auZCfS9Jn0DKRnIEe7E876+s4qtc4io86mkATn +RkyJEYYhjOpP1EUQuN3IqHkkosZZJo+P8QzkIP3eGd9K1QSWxf/zmHXOvrWW7bmGcn54n18 0FEDa7HCrX3+ed5bEKegv9m6MKPbAs6YPoPrwh4yoBbfifF0yJDDCmLbmJofNhmwQdrC2WVd /sa3DzHpf7CPlrMZL2Xbdhqn//TTTwe7c8xOpzcGSWOmF5462MuQC1Azlr3Qnj2aoa9xo4YM bsAuTI6YBO6EV4oFnJlUtGW3rl1eBLOMWSqDac/cQ+pHFgYG1WRfl+w6kjFI4yPj0OkGHywV pO/+vs9ADma8iGdi0xk8brAQbHt1Gx/xsCFDnh78tLBxDm7cAZEo5Jm5TBuNiTt2wt17MN1e TgXJMzmvubm279jBssdCPf+ZeTiNKRwaA8SRI5v7wWfylKmSJsGOuTDOWxzJPKZCljfH7nLo 8GEeYSbQ3Xt261b2LrbNKINDDBzzZsNcGwOMr6RMI4YNjwXv0Q8+19z7TnbpG+ZgxkOv0FLl ypWHHfEiBw4YwIErzaOTeZ/IU7VqFeikyBfUrBlJVbx4cRlQgI/gvzZu2sixK5vlX2+9Fe+1 bNni9zf/XoIGPi7/eCCkypk4YeL9997L7ydjUpfOnSQO4Em//fbbpUtp2iTKJxkJq1P/ASuT GdYRcJkERDxyNWrWBONgKBejoPOKFStyeERcFzOexpzCXTp37t2zl5Qt0Plc2AaZ1jk/aqyY UxnPuNHrUwUKBlAIoAmpFXLxQ7s3b9rMDqxSpUpbt2yRlgfWkRe7dKmSXNIA7zKIyP8FMMX3 ChIpb7E2OpHoVnJleaxs88TCgXqSk9WqVMVpoDAEY+sYnl+2dGnJ0oOWSAWV/8cBNNOi2Fk8 Y9p0OZdopFHeruPHuKrlUwqN9QBXEVUFOHUK0AMUAwBaqiwyMGwm05+PzgzkVMYLMoQjWDiJ FNHgVLBUgb4BxKLceBE8ql4E4GzcGD6LqQOhO1mhbNk5c2djHjpnzHivUB2rx4xH3EmJi9Pk gcM2sqqCwsAHSwoowSOAYuu4BwBrGXXCvcSqdI0DYVq3ar1s6VLgKeBdQa7u2L5dlBxaQthp U6P86j4ghe3btAnHVocA/JXzC8Y6zXgfHZYLT5qDGS+ghwkxsEOSqnSJkiG3PugwQL0DYGWM B7m7dPESMqpl8xYeWA5Glkk4SRfWrVP3tde22+5RQbUXgikAh2pKTI0fO44SmPeJJwCa2rRt K/BHviqRYJrhyZUrngvTh/F0G/FzhQoyTwtKCGhMEq91XIRAHjuBambZjhRqXjhpcN9rKSWZ A7E/bLBpxkszHvDTtddee8Wtt96KQMPyHD6X1T7EYEDpJaWVLBkKmdTq2LEjbbN71279+/WX MNOAYflBpaLkykuXCleV6hz1V6lUUeQBqcX0Iic09K3AH8hJqGKX4C6cIMEjeKRiA5C44FGY Z+zo0WvWrpXpmX1EgmqAr9mz59jgMZPA4LvR3XfdBbIklTpjZteu3aZOnRKCaOSulKFdRoOn nx7CCkqiijETmtCrZ69JEybojVjmV0gzXprxcgbjeU+AjIIjxYABXkbrwslTjPhEDd8A6HME vNyxg1gTSCLOUkESRkvbQtZOqHzmRJdjV1vEkLpD5E6IA1Aoz0n7QDGjYbkRJKql9ObYLAKI viqkJToOFWrs0BYtWoh7FZojHl24YOFCv8aZRU6wrEBy+mzdGoEYiTtgaE5C5wUZgTtu377D lvKjRnbp583BqqaXl0jj+PgMGGL4NXm8VIdbuCq5PGkTqCGLkE8AK2d12WVpn3ptfIvTSbJS 73jmsC8vVSLNEu/PDORsxnt/5ih9l/QMXPIZyMGMd56wzOxTFm9YMyK7L4eNaxCA7wRAy/KY voZ3ltRDPjtNnAk6Df0HFeCsKNN33WSee5CXnC4/9B3mYMbzbpYtWy6vUcI8iQUoOcj+/jQW GGoPFkfuvR6Fk3+gL9l4hNvZN77TKGBKhYTbpkaPGYO2wWVgYqK0lpkg7ezP66HUalQ55OWX N6uywJcYb1Zfj/JhZkOZAuLYKvOvvNMy5LxtsL1uFi39A525nH3zHMx4iKBZ0yZRfoTMj/JU IcW/g7h2+elPwJSFp4XknD51GmMMt4GkfdH5zEC7ZDoyY/ZOB3R7zxmiJlPmRMaSk6nZrDM2 mUnLhEwDh5y5zTu9I+W3UEU5yOHTci8TZcrkw7UYJeTL3JfCo6m5lfp0MppED5gZER9+4tnv 3r0HV6dEZkp/GKp8M+r1hV8Dj4Vj7scK5cpivDNHmHoHNdNHuC87kDXLD2pNhoLVOZv8P7jR 52zGU3VNcishycePvQ2DIv+U5Hxy4xQvXkzCPLZEpsXVa9ZESTgkxoyqdUcVt9XiYsEXcCAB GQKKQJfHjqmJB4epJDrz4yG5igUl7NoVYTJPnFAfWGQ6OSFHy062yrhouISqfnIlAlabJi5D o0TOZoPRj58UFla7izMd54SMmu7omKFVOjC5H6XE4pZg3pT1QGIyFxJlADeJjUeGwlWrVovp VoKPTz+OSY9YRfrAkOCAT9+v7iKdCd8GDKrjUAuJKVU6CZnzpE6RlcSA9+7Z7Xk5UdTc4TUJ 1SfNlXEaAyeK3oTnO3mQBfiNndJym65169dp76TBw52q1KM3hm+w1aefHhzVOr8Myhp/cOxz 4XfO2YwHrSIBifLWXTt3ARC55Za/cLUpaHjLLbeEBGFAm9Wj/MT1uRMgUVCpnLZ8dzhBklaV 2WSMlRcE/cFh+lUmr/vuuUeZO7Qr8xxwCWkg52yUDnDrVkWbpd9CjqNHjxoSZ/gy8T169ChX tpwkKMDZfHTWAv4JiLCyZctyl1euVNG9otSA+/Yjbn6IRQsXkFdr1z7fpGkT2VflIDEGGACZ nsmoqHH8oXzCl0n1JSFn+bJlIcsgUSdMGO8nydQsHIBplStXIb2hdv7yl7/ECQ5fhBZQh10e Md6RO+64Q+Yy2ZnuvfdeTPXs0iUywEoPY7TyC4HLSFgGOOrCjRvWgwpUr1ZdAb1Vq1YpQKmu rdybUVKTOnXAXC09JnbihPGm4p577sH55kHVctrs5bBJvnDy/+CufEfGy58/P8JN1TYutyk2 NimGZJImpmhTXG1y/vB3m0y5vgkjnAZvqZmVfuHCRSFXCroPBcf9BNglozMyIhlyP/jgnNmz nh48qG3r1nLOyeEhPzSwGFHTplWrXj16Eq0YMs9jjxFTZGZAqBBxvPa41LF0Q/37RlXCBeMp m4r96GalS5biMDR1SjHjH7FIdlM6DBMLU0ogG4l8hFguPEX4SUag4XFwEymsN6kyn3/hBWxg n+avx1RqPGR0pWRKOEsiEbkyqamjkC9PHntXEDlZUlaufE6dR8147WU3mjZlqjLikXq5b7+R h6TLBw7sl2aTDJ8xY6YM0PJhmgQ7OreQH0ViMnVhZROcOWM6AFDPnlFv1jWLVFrVvGDOzc54 NKCbbrrpiqpVqwL+XuaMR7ysWPEcCIsCvDRJ9U0RLoUQWIwWJKnrvLlzPYJ4BVlxwrMIsSPi qIING9SXT5LWhIvgXYQSYUiJruCtmzRuBEs5eOBAVYXJrihT6vLl7dq0AcvEWoIhZJgO2fIk DnJ56Pm1ba/Cdnbu2Im0UcnZmTgZbv0AZONFV80U89t0yfnpDFEmJ6SD9u3bcf1TFKFqMG3o DbmHxKwYT0QFvVcaNfEWBq9SsfNMMmQUw4m9Wf26Uf4yCq+MmrVq1yarqakGuWH9Biq3NOna k2x8/ThfAV05wmTgVrs43ItOThrj/HnPPEMaW18sBDLf1qsjT/spD+i83mbNmCFTU7euUW8k /JLFZ2S/vmAS/GhemJ3xFLumpFwhg2/RokUvc8aT2hUpSAlesVx52zDYMcv2kbeOUNuwnxgc ATgegUBApgwDTtLTGFRgo6mp2M+mS+o7mqS48pLFi8u3aeNmyS+YL7/U1IhVSnBKJjYr/ORT UgOKbn/iscfJKM1syeS9kkIzlCUI9nr64fBhQ/2VcJrEK1tabfG3jTBUAnCJVJz6sUwApilR 4BKiiXFFmrAKRNCu3YapK3FG3bp09atr6caGR+IRxX169ZZkNrw2m668efJs2fKyXK6ygHk0 WDn1ekg8GjV0uASb4pjIbUH0+EfPAZ0zsP8AS0OZ0qVkE/NVOQcrl9mZPWumNcjKMmTQYJEZ AjU8ZqMG9a1fJJ7UzoI8BF65pEXLlhL+Ofhoss3FP3V2xgscd0VAjl3mjCcv+nPLlrEcEHFY TpSd1OLibiz79jlq7lj7baLwGIrv1bM3/VBouaXdvmh4DKSOFu+2bUNx+qqVq7ZqFSGbyTGp pnUrSK9gwYKRyDp1Cn+iYDOO1iWTtSHs3iNKV96vbx85p7Foz+7dataoKREtD4fErOqJlyhW nJa4bes2iE28JOxdks98efJaDkaNGvXE4483btzIMCSEJPEwHouFyKahQ4fRgXfu3GV7ZgXB xpLwYlTWlyaNGotdAlUjOYkgkRlgop6XJJRJmtosV6xtWMECBUl+T6rAyNKlz9oysP2SY0aL c+gyZUqXkb1X2maZKsUZCi+kJ9u7UoNpBzQFYVDuiJNZj9q0aknM6g3oVLSUxzd7xi+TvI3i 5bYBuXiWeH96yM54xB2hd4WXdPPNN1svE9673KYYKdOR6E5WcTF1NnUkwPoNG3x1nkyzq0G1 dkchpSSDJFMe6cQJwOgXWeTi2CI2TFXv4t4OImL9RKa/3XvYF0kbPUdugxMnXCjVioOouDYi PfLWGzsjNKb5YZthtECpLIohyTnepvup0SF1vN5wkZa4RVJkmzSWHssERlq1ehWZaTCYnPSL IKbHjslFaYemE4MJedfd2rVUSrfWf1zL6Di9kYWGePdePDg902aS0SXq8ODBuKzfgWich9/y q0+cJ+aE/wkLJMPDa2Ud4WkwFXL1unVczTxqSWzqwSDdSD+GZ0rDjLH6CunwK65Oavq9P8T6 YbpLFsbzpq666ip/I8aTzJxp7rJlvGBbT/xRiVcqOWC0nD49Y2uXnAzaUXioxHCf5WSYlHM3 S9pkX7pwvs1bq1atK1aoGDaZqb2lKhFZ5jal2RkJocP55Eapw07tOXUkyeSkOvdSM9CkdpLl eVMHnDEJmR7CZE6yDObDxBLvz7NkIZuE1yLGw3+0TRj/8CYuN4l37gkK/rdIvr2/nyj38/Hj FHVxQ2SCeSNC3wXe9f6OMH23y2EGUhkvldEixvMRrHnfffflUMYLw34nDOR/a/ZjKGQiyoKa +n6P4b/1bOl+L9kMpDJeqmqZwXgIiKWFvSXHSbxLNkPpjtIz8F+YgYTxmFEEnYeqmj6nGc8p 9pYs0ehn3aikT6ZnID0D72kGbEmYMJPd3BmM5wvrlp8lin1PnaYbp2cgPQPnmAGyDlvhvdQ2 pyVeOEvuPfLII1xAmDA9m+kZSM/AxcwAbrKvo2GmyrqsqmbqDYDI2Dldk2a/i5n39LUf5RmA Z7jxxhs56pJ93bkkXvIblnMNZx9rJ6OLvR8P7Ed5HtPPnp6Bc89A7FuabadGZ7zyyiuFH2RR L8+L8ZJGPA0MnsQl9lXqPv1Jz0B6Bs46A5REbILr8N5ZpVwq4/1/9BckHFTJneYAAAAASUVO RK5CYII= --------------030601090803000404080003-- --------------070109020803020900010203-- From SRS0=w9SU=4K=acm.org=bmoeller@srs.kundenserver.de Tue Jul 15 07:46:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBE01B28F2 for ; Tue, 15 Jul 2014 07:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_2e7d26v-5T for ; Tue, 15 Jul 2014 07:46:25 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4FB21B287F for ; Tue, 15 Jul 2014 07:43:59 -0700 (PDT) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0M9Xn5-1XHBlC2mhL-00D0rT; Tue, 15 Jul 2014 16:43:58 +0200 Received: by mail-oa0-f50.google.com with SMTP id g18so6045300oah.9 for ; Tue, 15 Jul 2014 07:43:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.60.4 with SMTP id d4mr26848200obr.4.1405435436616; Tue, 15 Jul 2014 07:43:56 -0700 (PDT) Received: by 10.60.15.133 with HTTP; Tue, 15 Jul 2014 07:43:56 -0700 (PDT) In-Reply-To: <53C530B7.8040605@ifi.uzh.ch> References: <8B2FFA4C-9BBF-4E7E-B0E4-032139FF0EB5@ieca.com> <53C530B7.8040605@ifi.uzh.ch> Date: Tue, 15 Jul 2014 16:43:56 +0200 Message-ID: From: Bodo Moeller To: "Dr. Corinna Schmitt" Content-Type: multipart/alternative; boundary=089e0158ac86f455b704fe3c6f47 X-Provags-ID: V02:K0:u7JoP0ebECaMTqFSrdSEv1nAQbgoDIGVmNaYZJ1r92Z ibGi8ehtY3YYLssOPHsaqQ0YF7ID6HT2Ule5UE8OxydUDs43RY 4cfdsVArBFX7ae/TtJ7Zx7wRpanV2jhQFq47t7wSQN/eg1Yd0L pIY4jahowe7b+dWxb2tUB0W18yzN1mKw45unS6OnUXkz6ffr6r fNyXI82JnbI//aDWCExZcDgxsHtLp3dwYGV2zxtqyW/AJN7FGM dHvCEBNlDU9ZNM9rvgvEETJWiFvhNZkuPlHjVvyknf+vTizXd+ dgR2lE4Llo7q5hla/5yay1Rgi611Blqju4M1riadI+czI91ECe hi01XqiKh+zfRhJLHXKBlbtuaVecIiGIh9I5f2dLcHdsJ9P0BZ mqF2szxpMY7TFSZzNXKnETtvmcYQ77WTmLwDsh47/AUJBYiBbM YUVqH Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WYFxQxfGu0ZcTpt3GQitXp5VaIM Cc: "tls@ietf.org" Subject: Re: [TLS] interim meeting anoucement - Location? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2014 14:50:40 -0000 --089e0158ac86f455b704fe3c6f47 Content-Type: text/plain; charset=UTF-8 Dr. Corinna Schmitt : > > Sunday is arriving soon. So where do we meet? > See "Draft agenda for interim and IETF-90" posted by Joe about a week ago for further details. Bodo --089e0158ac86f455b704fe3c6f47 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dr. = Corinna Schmitt <schmitt@ifi.uzh.ch>:
=20 =20 =20

Sunday is arriving soon. So where do we meet?

See "Draft agenda for interim and IETF-90&quo= t; posted by Joe about a week ago for further details.

Bodo
--089e0158ac86f455b704fe3c6f47-- From nobody Tue Jul 15 11:37:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF021AD6B0 for ; Tue, 15 Jul 2014 11:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJwz56HFhGkZ for ; Tue, 15 Jul 2014 11:37:30 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5AA1B278E for ; Tue, 15 Jul 2014 11:37:29 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id w8so4877072qac.16 for ; Tue, 15 Jul 2014 11:37:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=spl1Lec/1h3oXBObZNRJGL5W2mNw5dFaqDxovOnHRTI=; b=UqBp9Sydv18Zjp/zI5P6frtqITP6Xethv/8aWh6vUCVd6X07xVdggy7IPLJyJC6lrK Xz9IGyXa9vFx40pigLQFRErOEki201GjtPyvnlrxT8rYnTrHb6FeEKSDztNtgcJD0DbC oPRyBAE/ho7rxcZa7U7r106+kCSntIzo64I/LgiiWFqF7LYT/sKV8xjE29PrciUh1a7B /kfqi/OCZwatcsIAzdv/O8YIJ7omNdYeJzoEaEDrzizE1ZReezag4yduhV1wYyCQrPI0 2Bwkhz1Zwa8exgJdedbUK+DY+8xsLXP/rx3ggfNvdP5TfmITtmwtrSIOXIHybVaZUHHN TFQA== X-Gm-Message-State: ALoCoQmj3voiR+5db2serYCvGNAyFyKvc1x3uC6lBk7HMMTtLTG6BPJ7wBFziDChhQWkEmA1wL8P X-Received: by 10.224.79.139 with SMTP id p11mr31274133qak.93.1405449448752; Tue, 15 Jul 2014 11:37:28 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:390:7115:22d1:58da:3b8e? ([2601:a:2a00:390:7115:22d1:58da:3b8e]) by mx.google.com with ESMTPSA id ik1sm27214917qab.32.2014.07.15.11.37.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 11:37:28 -0700 (PDT) Message-ID: <53C574EB.5040801@nthpermutation.com> Date: Tue, 15 Jul 2014 14:37:31 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <53C41080.9050204@nthpermutation.com> <53C4385A.7030007@nthpermutation.com> <53C44A03.4070603@fifthhorseman.net> In-Reply-To: <53C44A03.4070603@fifthhorseman.net> Content-Type: multipart/alternative; boundary="------------020004050003080501010904" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5244fgMNYq_apM0m6PxGT8cV8AE Subject: Re: [TLS] 1rtt thoughts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2014 18:37:34 -0000 This is a multi-part message in MIME format. --------------020004050003080501010904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Daniel - inline below, but first For grins I wrote a quick and dirty program to send a ClientKeyExchange before a ClientHello, read the response, try again, and then close the connection. I got three different results from three different machines: From my local apache server, I got a single "unexpected_message" alert, and afterwards anything sent to the TCP connection was blackholed. The TCP connection remained up though. From "mail.google.com:443" I got an abort of the TCP connection without any error alert. From "www.navyfederal.org:443" I got no error message, and no response on any further data sent on the TCP connection. The TCP connection appeared to remain up. These were the first and only ones I tried. I'm sure if I worked through a larger list I'd probably get even a wider set of responses. On 7/14/2014 5:22 PM, Daniel Kahn Gillmor wrote: > On 07/14/2014 04:06 PM, Michael StJohns wrote: > >> From the server's side this looks like two different connections. From >> the client side, it's just negotiating to the right suite. > I'm not sure what toolkit presents this as two different connections on > the server side. This closure and reopening smells very much like > problems we fixed with insecure renegotiation only a few years ago. A > TLS toolkit capable of keeping the underlying transport open while > restarting a new TLS session would need to be very clear about how it > presents such a transition to the upper-layer logic, if we don't want > another round of prefix-injection attacks. This is an interesting comment that made me consider what the issues might be lurking with things like STARTTLS style connections. Although all the current STARTTLS models have the clear text/non TLS only at the beginning of the TCP connection, I'm wondering if there isn't some application where interspersing TLS with plaintext (or maybe multiple differently credentialed TLS sessions) over the life of the TCP connection has any utility. This is just a thought experiment for now. > > I recognize that this is an API question more than a protocol question, > and therefore at the edge of scope for the WG. But we've seen enough > problematic APIs that cause applications to lose the security guarantees > that the protocol is supposed to provide that i can't help thinking we > should take these concerns seriously. It's not exactly an API, but an interface question. RFC793 (TCP) is sort of a gold standard in my eyes for how you describe them. It talks about what TCP offers to the upper layer protocol, and what it needs from the lower layer protocol. For the specifics of IP as the LLP for TCP, it provides some guidance on IP parameters. The TLS spec is very good at specifying the on-the-wire and TLS protocol processor to TLS protocol processor, but less good at specifying interface characteristics for talking to the protocol levels above or the protocols levels below. Later, Mike > > --dkg > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------020004050003080501010904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Daniel  - inline below, but first

For grins I wrote a quick and dirty program to send a ClientKeyExchange before a ClientHello, read the response, try again, and then close the connection.

I got three different results from three different machines:

From my local apache server, I got a single "unexpected_message" alert, and afterwards anything sent to the TCP connection was blackholed.  The TCP connection remained up though. 

From "mail.google.com:443" I got an abort of the TCP connection without any error alert.

From "www.navyfederal.org:443" I got no error message, and no response on any further data sent on the TCP connection.  The TCP connection appeared to remain up.


These were the first and only ones I tried.  I'm sure if I worked through a larger list I'd probably get even a wider set of responses. 



On 7/14/2014 5:22 PM, Daniel Kahn Gillmor wrote:
On 07/14/2014 04:06 PM, Michael StJohns wrote:


From the server's side this looks like two different connections. From
the client side, it's just negotiating to the right suite.

I'm not sure what toolkit presents this as two different connections on
the server side.  This closure and reopening smells very much like
problems we fixed with insecure renegotiation only a few years ago.  A
TLS toolkit capable of keeping the underlying transport open while
restarting a new TLS session would need to be very clear about how it
presents such a transition to the upper-layer logic, if we don't want
another round of prefix-injection attacks.

This is an interesting comment that made me consider what the issues might be lurking with things like STARTTLS style connections.  Although all the current STARTTLS models have the clear text/non TLS only at the beginning of the TCP connection, I'm wondering if there isn't some application where interspersing TLS with plaintext (or maybe multiple differently credentialed TLS sessions) over the life of the TCP connection has any utility.  This is just a thought experiment for now.  



I recognize that this is an API question more than a protocol question,
and therefore at the edge of scope for the WG.  But we've seen enough
problematic APIs that cause applications to lose the security guarantees
that the protocol is supposed to provide that i can't help thinking we
should take these concerns seriously.
It's not exactly an API, but an interface question.  RFC793 (TCP) is sort of a gold standard in my eyes for how you describe them.  It talks about what TCP offers to the upper layer protocol, and what it needs from the lower layer protocol.  For the specifics of IP as the LLP for TCP, it provides some guidance on IP parameters.

The TLS spec is very good at specifying the on-the-wire and TLS protocol processor to TLS protocol processor, but less good at specifying interface characteristics for talking to the protocol levels above or the protocols levels below.

Later, Mike



	--dkg




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

--------------020004050003080501010904-- From nobody Tue Jul 15 12:57:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D4C1A0086 for ; Tue, 15 Jul 2014 12:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kjDiTlQpP_U for ; Tue, 15 Jul 2014 12:57:46 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (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 53E551A0083 for ; Tue, 15 Jul 2014 12:57:46 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 5C27E21BB3; Tue, 15 Jul 2014 19:57:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1405454265; bh=Y4d26wF0YMy1ZX/+lxmg3IR2HxsmsZ2DuVMFfbSyOm8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=F/QqRxz383czCRemIIW6DjVOO0f51vWSn65/aHsHtt4nu2/4UgZMDP/6ceGK+8TLU eWEU1f/uTRDq55BkSE1TtdviT0t+y1UMxKqgPq/4aQNqT6jlYip2v7j0XWZCkkVqQX aCoFTj7dbJaK498P/yBPD7R7h2k2NKqiuGR3c3Es= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 3CD5560028; Tue, 15 Jul 2014 19:51:39 +0000 (UTC) From: James Cloos To: Michael StJohns In-Reply-To: <53C574EB.5040801@nthpermutation.com> (Michael StJohns's message of "Tue, 15 Jul 2014 14:37:31 -0400") References: <53C41080.9050204@nthpermutation.com> <53C4385A.7030007@nthpermutation.com> <53C44A03.4070603@fifthhorseman.net> <53C574EB.5040801@nthpermutation.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 15 Jul 2014 15:51:39 -0400 Message-ID: Lines: 24 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140715:msj@nthpermutation.com::UoKkNnagd9/2ECUV:000000000000000000000000000000000000006o0ZU X-Hashcash: 1:30:140715:tls@ietf.org::ifadsrPKbvJvFsfn:0000/XF0P Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xP6vIakAx7OcCzkOazsC8psr_6o Cc: tls@ietf.org Subject: Re: [TLS] 1rtt thoughts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2014 19:57:48 -0000 >>>>> "MS" == Michael StJohns writes: MS> I'm wondering if there isn't some application where interspersing MS> TLS with plaintext (or maybe multiple differently credentialed TLS MS> sessions) over the life of the TCP connection has any utility. There are several protocols where multiple credentials make sense. Among them are imap, pop, ftp and any of the tls-capable sql protocols. I'm sure there are several more I cannot think of just now. It may be uncommon to switch identities mid-stream, but not unknown. I doubt many currently use tls mutual auth in such a fashion, rather than application-level aaa, but they could. (Of the protocols I though of above, pgsql is the one where I've most often changed users in place and where cert auth is a viable option. That being said, I've never tested whether changing roles works with a connection which requires cert auth.) -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Wed Jul 16 01:32:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BA81B2797 for ; Wed, 16 Jul 2014 01:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9qCgPr01Nw7 for ; Wed, 16 Jul 2014 01:32:32 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 132141A036F for ; Wed, 16 Jul 2014 01:32:31 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id e89so446050qgf.17 for ; Wed, 16 Jul 2014 01:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Wn0pupXDJiOYuiZE2D0YReOCXp24MKkSrpCzhqnL3Zk=; b=I/PEzpEUb+tXvmDClIthheSjBuj6UfIS8jmjXWXlx5G/SvgsA4bPSNRJKCVkpymTSo bcmdPEW80oZSuo9G//9HuxZKN9J/w5rtnOG15TflDtpYdVUXThYCh5Lbzf5NeY2Z6i9R AxYnS+9kYkJ1yt/v7gAWzXb1Cg62vxgk6ZtaSXYo9mYdrgXfpDsCPBRui1fAoNv6BB8h 3I4mXuXd06Aoh3PKAlGFsOLmit78COmb7yi/O0mihgkgTgMSXT2OKrkvAyIbc66biWXs otVq4iBRgM5ETy3pkcTEdZ/e0To6WU62q3w6hNFFPMiZDAd1zWw+bGyhNXWGe45I8Axk Sncw== MIME-Version: 1.0 X-Received: by 10.140.35.232 with SMTP id n95mr41485606qgn.82.1405499551202; Wed, 16 Jul 2014 01:32:31 -0700 (PDT) Received: by 10.96.194.225 with HTTP; Wed, 16 Jul 2014 01:32:31 -0700 (PDT) Date: Wed, 16 Jul 2014 10:32:31 +0200 Message-ID: From: Pascal Urien To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c03f347b46d004fe4b5d88 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4fZSpLCCc5qS79bsm2DAHRdfH-M Subject: [TLS] TLS 1.3 Application Identifier ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2014 08:32:33 -0000 --001a11c03f347b46d004fe4b5d88 Content-Type: text/plain; charset=UTF-8 Hi All It seems there is no identifier for the application SDU transported by TLS 1.3 (which is obviously a transport protocol) With the legacy TLS, the application is identified by a TCP or UDP port. Some TLS extensions have been proposed to solve this issue. What about adding a mandatory application identifier in the client hello message?. It could be a two bytes integer (i.e. TCP or UDP port) or something else such as an application name A mandatory application identifier in the client hello message avoids tentative connections to non-available applications. It also could establish a logical link between client certificate and applications Regards Pascal Urien --001a11c03f347b46d004fe4b5d88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi All

It seems there is no identifier for the = application SDU transported by=C2=A0 TLS 1.3 (which is obviously a transpor= t=C2=A0protocol)

With the legacy TLS, the application is iden= tified by a TCP or UDP port. Some TLS extensions have been proposed to solv= e this issue.

What about adding a mandatory application identifier in the client= hello message?.

It could be a two bytes integer (i.e. TCP or= UDP port) or something else such as an application name

A mandatory application identifier in the client hello message avoids tenta= tive connections to non-available applications. It also could establish a l= ogical link between client certificate and applications

Regards

Pascal Urien


--001a11c03f347b46d004fe4b5d88-- From nobody Wed Jul 16 02:17:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E771B2878 for ; Wed, 16 Jul 2014 02:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDcStIU15JHp for ; Wed, 16 Jul 2014 02:17:14 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B671A0368 for ; Wed, 16 Jul 2014 02:17:13 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Alyssa Rowan Date: Wed, 16 Jul 2014 10:17:09 +0100 To: "tls@ietf.org" Message-ID: Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rewslpOGUvYBDJU86lvRPwZ7JrA Subject: Re: [TLS] TLS 1.3 Application Identifier ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2014 09:17:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 16 July 2014 09:32:31 BST, Pascal Urien wrote: >It seems there is no identifier for the application SDU transported by >TLS >1.3 (which is obviously a transport protocol) > >With the legacy TLS, the application is identified by a TCP or UDP >port. >Some TLS extensions have been proposed to solve this issue. Perhaps I am misunderstanding: are you not describing ALPN? It seems what you want is an ALPN identifier for your protocol, am I correct? ALPN seems to be proposed as the preferred way to do this for 1.3, is my understanding. There are obvious metadata concerns involving an untrusted intermediary identifying and demultiplexing different applications transported over TLS (current ALPN is plaintext) and ways to address this are being explored by the WG (although this has tension with those who run large-scale traffic balancers which would prefer to avoid doing crypto for both scale and key security reasons; I'm not sure that can be cleanly resolved in a privacy-preserving manner which satisfies everyone). - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI3BAEBCgAhBQJTxkMVGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t6KOoP/jnvQ4WhOW1/1U1AeFn8p/y3qlaBEelH04jasu3PClTNk8c2ddGx ICv6rE1rv8xIA6m1LrqG5kUVqctnUq2JuH6G6FRg2cu8N7QkImaIIZXZzgpmIXmW wVTCQ+RN4kmpsYMwdd+ZcwHVORbu09lnG9MI+Bt3Ybv2ck1NLjVz5+o0Iai6HOwu S0zMl8cjB2husFluuUUkt4Rk56l415hQf8VF4I4zHkIYcx5b5DHBrZRD+COCCuKO kqzeDSl09HVAGYQfkf1WzubUpq501mi39uHvFAY/NYrY51/e6g0fDQavd795bxXT rldVix9o8Y6CXSBkK/aKTMgvhoa5GCiBRE3zOAYuSZbpvTUbWwLFDHASkasnQCo1 yyDgGJXuY8P0dWMKQ0ufOmJ7AgLJnp8EaqjWY1BXAticEPPhQYAtY9oMriuyzd2p rw7HkHmIwpCb0Cqu705jFSY+x0F3R+QvhDdGg2jHQIxCUF+2L81oD4n/ekqRZK/n B1CkATZoxq4mLHS7rPDLU9HNqRHbhkkUSFmpiE+4KIIarNRfUp+tJzZtAvazo5hw iDY+IvQ8mWpUCvvL95LwSSWE4D4PPDMCltcT/6HSBT1080BtaU+r+5HeSAaQRsSq 94EtgkuczqRbQjvvgc1nqe11ZK3MZx+RQI9+Qu3r1i3151yV/qPczonh =x0a+ -----END PGP SIGNATURE----- From nobody Wed Jul 16 06:32:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62321B2A8E for ; Wed, 16 Jul 2014 06:32: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRzc8v2iABeh for ; Wed, 16 Jul 2014 06:32:11 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF0A1B2A37 for ; Wed, 16 Jul 2014 06:32:10 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id f51so714926qge.39 for ; Wed, 16 Jul 2014 06:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bRyLc4R/ypkX/Z4+Vs/VsjxIjR61zJL061oeSjKm7lM=; b=TyMJ6wfUFmPqpoer/XbXpqqkENpGaO3kXvLJqzj75f1i4Uyhf67xI9cWp72WB+XOmu VETtGqEjGDTR9a2t/YdQhlrFF8DkcREI5M9EMP7O/xKY32sdJ4hJ0HV33Xk1JnvqYsYi InW5kUZ1rRDJsSzlDkVrOzM7pg1rbWhVO/hSi+/soO8Z0jtdLH2/ctpTRfhJ6DZaap0a pXcIhn+VIJC/Cwim7mveARQBmNxeSebL9Hk+G98TCMbsRnOqDdYZV8ru10c6Oi9hTRNr 4voxy6Qacyr8JZV0RzM5fdkrtOipwEqkJSjqY1e3rdfAFS6Ye3TOktt8QlZ2+qVCgSD2 VARA== MIME-Version: 1.0 X-Received: by 10.229.117.136 with SMTP id r8mr17432687qcq.17.1405517530077; Wed, 16 Jul 2014 06:32:10 -0700 (PDT) Received: by 10.96.194.225 with HTTP; Wed, 16 Jul 2014 06:32:09 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Jul 2014 15:32:09 +0200 Message-ID: From: Pascal Urien To: Alyssa Rowan Content-Type: multipart/alternative; boundary=001a1133179c1b200904fe4f8d70 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/V4Er-fFSpOsSiwIe69E-Gla8DHA Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Application Identifier ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2014 13:32:14 -0000 --001a1133179c1b200904fe4f8d70 Content-Type: text/plain; charset=UTF-8 It could be like ALPN But ALPN is an extension from previous versions of TLS, and is not mandatory Pascal 2014-07-16 11:17 GMT+02:00 Alyssa Rowan : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 16 July 2014 09:32:31 BST, Pascal Urien wrote: > > >It seems there is no identifier for the application SDU transported by > >TLS > >1.3 (which is obviously a transport protocol) > > > >With the legacy TLS, the application is identified by a TCP or UDP > >port. > >Some TLS extensions have been proposed to solve this issue. > > Perhaps I am misunderstanding: are you not describing ALPN? It seems what > you want is an ALPN identifier for your protocol, am I correct? > > ALPN seems to be proposed as the preferred way to do this for 1.3, is my > understanding. > > There are obvious metadata concerns involving an untrusted intermediary > identifying and demultiplexing different applications transported over TLS > (current ALPN is plaintext) and ways to address this are being explored by > the WG (although this has tension with those who run large-scale traffic > balancers which would prefer to avoid doing crypto for both scale and key > security reasons; I'm not sure that can be cleanly resolved in a > privacy-preserving manner which satisfies everyone). > > - -- > /akr > -----BEGIN PGP SIGNATURE----- > Version: APG v1.1.1 > > iQI3BAEBCgAhBQJTxkMVGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE > jtkWi2t6KOoP/jnvQ4WhOW1/1U1AeFn8p/y3qlaBEelH04jasu3PClTNk8c2ddGx > ICv6rE1rv8xIA6m1LrqG5kUVqctnUq2JuH6G6FRg2cu8N7QkImaIIZXZzgpmIXmW > wVTCQ+RN4kmpsYMwdd+ZcwHVORbu09lnG9MI+Bt3Ybv2ck1NLjVz5+o0Iai6HOwu > S0zMl8cjB2husFluuUUkt4Rk56l415hQf8VF4I4zHkIYcx5b5DHBrZRD+COCCuKO > kqzeDSl09HVAGYQfkf1WzubUpq501mi39uHvFAY/NYrY51/e6g0fDQavd795bxXT > rldVix9o8Y6CXSBkK/aKTMgvhoa5GCiBRE3zOAYuSZbpvTUbWwLFDHASkasnQCo1 > yyDgGJXuY8P0dWMKQ0ufOmJ7AgLJnp8EaqjWY1BXAticEPPhQYAtY9oMriuyzd2p > rw7HkHmIwpCb0Cqu705jFSY+x0F3R+QvhDdGg2jHQIxCUF+2L81oD4n/ekqRZK/n > B1CkATZoxq4mLHS7rPDLU9HNqRHbhkkUSFmpiE+4KIIarNRfUp+tJzZtAvazo5hw > iDY+IvQ8mWpUCvvL95LwSSWE4D4PPDMCltcT/6HSBT1080BtaU+r+5HeSAaQRsSq > 94EtgkuczqRbQjvvgc1nqe11ZK3MZx+RQI9+Qu3r1i3151yV/qPczonh > =x0a+ > -----END PGP SIGNATURE----- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1133179c1b200904fe4f8d70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It could be =C2=A0like=C2=A0ALPN

But AL= PN is an extension from previous versions of TLS, and is not mandatory

Pascal


2014-07-16 11:17 GMT+02:00 Alyssa Rowan <akr@akr.io>:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 16 July 2014 09:32:31 BST, Pascal Urien <pascal.urien@gmail.com> wrote:

>It seems there is no identifier for the application SDU transported by<= br> >TLS
>1.3 (which is obviously a transport protocol)
>
>With the legacy TLS, the application is identified by a TCP or UDP
>port.
>Some TLS extensions have been proposed to solve this issue.

Perhaps I am misunderstanding: are you not describing ALPN? It seems = what you want is an ALPN identifier for your protocol, am I correct?

ALPN seems to be proposed as the preferred way to do this for 1.3, is my un= derstanding.

There are obvious metadata concerns involving an untrusted intermediary ide= ntifying and demultiplexing different applications transported over TLS (cu= rrent ALPN is plaintext) and ways to address this are being explored by the= WG (although this has tension with those who run large-scale traffic balan= cers which would prefer to avoid doing crypto for both scale and key securi= ty reasons; I'm not sure that can be cleanly resolved in a privacy-pres= erving manner which satisfies everyone).

- --
/akr
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQI3BAEBCgAhBQJTxkMVGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
jtkWi2t6KOoP/jnvQ4WhOW1/1U1AeFn8p/y3qlaBEelH04jasu3PClTNk8c2ddGx
ICv6rE1rv8xIA6m1LrqG5kUVqctnUq2JuH6G6FRg2cu8N7QkImaIIZXZzgpmIXmW
wVTCQ+RN4kmpsYMwdd+ZcwHVORbu09lnG9MI+Bt3Ybv2ck1NLjVz5+o0Iai6HOwu
S0zMl8cjB2husFluuUUkt4Rk56l415hQf8VF4I4zHkIYcx5b5DHBrZRD+COCCuKO
kqzeDSl09HVAGYQfkf1WzubUpq501mi39uHvFAY/NYrY51/e6g0fDQavd795bxXT
rldVix9o8Y6CXSBkK/aKTMgvhoa5GCiBRE3zOAYuSZbpvTUbWwLFDHASkasnQCo1
yyDgGJXuY8P0dWMKQ0ufOmJ7AgLJnp8EaqjWY1BXAticEPPhQYAtY9oMriuyzd2p
rw7HkHmIwpCb0Cqu705jFSY+x0F3R+QvhDdGg2jHQIxCUF+2L81oD4n/ekqRZK/n
B1CkATZoxq4mLHS7rPDLU9HNqRHbhkkUSFmpiE+4KIIarNRfUp+tJzZtAvazo5hw
iDY+IvQ8mWpUCvvL95LwSSWE4D4PPDMCltcT/6HSBT1080BtaU+r+5HeSAaQRsSq
94EtgkuczqRbQjvvgc1nqe11ZK3MZx+RQI9+Qu3r1i3151yV/qPczonh
=3Dx0a+
-----END PGP SIGNATURE-----

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

--001a1133179c1b200904fe4f8d70-- From nobody Wed Jul 16 08:10:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4875D1B2B85 for ; Wed, 16 Jul 2014 08:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0j7kZU2tU3C for ; Wed, 16 Jul 2014 08:10:14 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEFCE1B2B82 for ; Wed, 16 Jul 2014 08:10:13 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id f8so5490361wiw.12 for ; Wed, 16 Jul 2014 08:10:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=BodlkJsFwJTXtZM4LUY2D+Ne1GGJcGpN4eaq/ttJwz0=; b=NKgLy1/1SuQpZzEOz8ShT9I5HulGQsF53QkQ+WczVAxyEyS0ZkilMEMZTC4psPTN6d ZwYcNpiniTN+UvBV4P6nybKBNKJGZe/oEHTT6XzVis1i40Np2dIZa8ArVCdM+nsUnKVm 5k1dXNfS9t4dj5dW6oRmkf3uvoYLr8MwFoZ7Ewur/XthDJt1Rfpk5Mnx1rQ3Yq3ezvRe 7LoGJWxUPpG0M+rx2/vXf+fchLhi0ME0G+/67c3l8QV+4SAhBuWhJYCj+L+Qk8mNZG0J +YvZHbntd15+NME+dU/8aKenmxF2CRioK9sW4w/4gRBEcLmivjVbYRj9KQ5Ps4cU7ova EpEQ== X-Gm-Message-State: ALoCoQkP8LHBR2LMBWcMRfdrQvX9QiJIzza5bbcflw/b7WipV/67cR3TVUknj4Kzi1G6qxs3YGLR X-Received: by 10.180.89.143 with SMTP id bo15mr14219696wib.78.1405523409659; Wed, 16 Jul 2014 08:10:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Wed, 16 Jul 2014 08:09:29 -0700 (PDT) X-Originating-IP: [166.137.177.49] In-Reply-To: <338B3B88-CCE5-4D79-97DC-1EC7D84891AA@cisco.com> References: <338B3B88-CCE5-4D79-97DC-1EC7D84891AA@cisco.com> From: Eric Rescorla Date: Wed, 16 Jul 2014 08:09:29 -0700 Message-ID: To: "Joseph Salowey (jsalowey)" Content-Type: multipart/alternative; boundary=e89a8f3bab878e810d04fe50eb47 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/p-57PHW6SEigtr-qfTr8Eav5avo Cc: "" Subject: Re: [TLS] Resolution on gmt_time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2014 15:10:15 -0000 --e89a8f3bab878e810d04fe50eb47 Content-Type: text/plain; charset=UTF-8 See https://github.com/tlswg/tls13-spec/pull/65 Expected merge date: Friday Jul 18 On Sun, Jun 22, 2014 at 10:17 PM, Joseph Salowey (jsalowey) < jsalowey@cisco.com> wrote: > Thanks all. Based on the list discussion, the chairs believe there > is rough consensus on the following points: > > For TLS 1.3: > - Remove GMT time from the ClientHello entirely. > - Remove GMT time from the ServerHello at the MUST or SHOULD level. > > For TLS 1.2: > - Remove GMT time from the ClientHello entirely. > - Remove GMT time from the ServerHello at the SHOULD level. > > Next steps for TLS 1.3 are as follows: > The editor is directed to remove GMT time from both random values > and open an issue as to whether or not the ServerHello can have > a time value in it. > > Next steps for TLS 1.2 are as follows: > Absent any objections, the chairs intend to adopt draft-matthewson > as a WG draft. Anyone who objects to this, please say something by > Friday June 27. > > Joe > (For the chairs) > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --e89a8f3bab878e810d04fe50eb47 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
See=C2=A0https://github.com/tlswg/tls13-spec/pull/65

E= xpected merge date: Friday Jul 18

On Sun, Jun 22, 2014 at 10:17 PM, Joseph Salowey (jsalowey) <jsalowey@cis= co.com> wrote:
Thanks all. Based on the list discussion, the chairs believe there
is rough consensus on the following points:

For TLS 1.3:
- Remove GMT time from the ClientHello entirely.
- Remove GMT time from the ServerHello at the MUST or SHOULD level.

For TLS 1.2:
- Remove GMT time from the ClientHello entirely.
- Remove GMT time from the ServerHello at the SHOULD level.

Next steps for TLS 1.3 are as follows:
The editor is directed to remove GMT time from both random values
and open an issue as to whether or not the ServerHello can have
a time value in it.

Next steps for TLS 1.2 are as follows:
Absent any objections, the chairs intend to adopt draft-matthewson
as a WG draft. Anyone who objects to this, please say something by
Friday June 27.

Joe
(For the chairs)

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

--e89a8f3bab878e810d04fe50eb47-- From nobody Wed Jul 16 09:25:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D5D1A0007 for ; Wed, 16 Jul 2014 09:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BY2lIc71GpsN for ; Wed, 16 Jul 2014 09:25:41 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 327771A0002 for ; Wed, 16 Jul 2014 09:25:41 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hi2so1651439wib.11 for ; Wed, 16 Jul 2014 09:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=APyZDymfHGXB7Fvk/njnHNW3A/Q3syV+1+iIYjXEp+k=; b=nRZIpaaPDI8VVnvR4c4+BUKCDj+r7CMdkGwwqvHGPiUHqwlEFvpRkXunwB/Cbf1JXz jVjm0b1Pbvdr8aE504oBJh/yUCPnvTGKk9gMO4A7AmlDT2bCpSt9yfchXk5GyxD9Uig+ VO21hCeacbSdyS6tV6ecNiE6J0Hs590G/vSYEGIqx8BtCSK0C+UmX347Gxxu5IPxMkkI 3wmYSab8isleI62E/7UORdWnPif1+keeVUJnXjQk5d0/Q32WUxGEviv2uyua6C4KB+44 +v/bZWshGVLqwAfNBSP3f8wT9fPvpGs5CI99lwCB/Bz5rSOzP6TuY0qteIZ8iR6QYZCG BVdQ== MIME-Version: 1.0 X-Received: by 10.194.185.238 with SMTP id ff14mr37822407wjc.9.1405527939572; Wed, 16 Jul 2014 09:25:39 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Wed, 16 Jul 2014 09:25:39 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Jul 2014 09:25:39 -0700 Message-ID: From: Martin Thomson To: Pascal Urien Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cz2IGbTxoJwT-IJUQNRpt_hElU8 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Application Identifier ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2014 16:25:42 -0000 On 16 July 2014 06:32, Pascal Urien wrote: > But ALPN is an extension from previous versions of TLS, and is not mandatory How is that a problem? If you need the functionality, then implementing ALPN is not especially onerous. Actually, I can only think of negative characteristics of having it be mandatory. From nobody Wed Jul 16 12:22:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9110D1A01EB for ; Wed, 16 Jul 2014 12:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8390lsKRGGn9 for ; Wed, 16 Jul 2014 12:21:58 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80CDA1A01E8 for ; Wed, 16 Jul 2014 12:21:57 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id m20so1243995qcx.0 for ; Wed, 16 Jul 2014 12:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=00KrEZpXDJDtF5b+wVBNqDx82aStchjS+yWMx9w/en8=; b=p3a5Yo1A6oLbhnVzxlHWADM4DdN1Ndaog5XlX31qztQonXYpAyunkBeseduVnqKIVS Az105Sai8wSGG8KVwULo/Jmdn/TrcAKHeFgJLA18uPlY7fGdgemNKRuIQjoSZr8p5QSA 28ngwM4+/WxDZI7IYF6AGmsQ8eSOddT/n4fXSbN7VQzamPlaR5fDddpIsK0vWecYSihQ iFvYh3bhrfko3bMuCX7cizX+7aYy0QrESP2z/5mCzFst9+smd4WKSXdpuuQ8jkAOqmiu MOiHVC8DYtleagv8vHh10Y+v5S4uwg5Zt2I7TDR2Vndbwn1I3OiMICJNlUDBp4K7dgnS 5jqg== MIME-Version: 1.0 X-Received: by 10.224.115.3 with SMTP id g3mr50098888qaq.9.1405538516758; Wed, 16 Jul 2014 12:21:56 -0700 (PDT) Received: by 10.96.194.225 with HTTP; Wed, 16 Jul 2014 12:21:56 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Jul 2014 21:21:56 +0200 Message-ID: From: Pascal Urien To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7bdc96b0027c9304fe5470aa Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DhJCOujgtc19A8CCmLxPXdZ1ByY Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Application Identifier ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2014 19:21:59 -0000 --047d7bdc96b0027c9304fe5470aa Content-Type: text/plain; charset=UTF-8 For me TLS is a transport layer UDP or TCP are transport layers. They identify the transported apps pdu by a port number Without a mandatory application identifier the TLS 1.3 will not give by default any information on the transported application I believe that a client certificate should be bound to an application. If no application identifier is available the client could set it to null. Regards Pascal 2014-07-16 18:25 GMT+02:00 Martin Thomson : > On 16 July 2014 06:32, Pascal Urien wrote: > > But ALPN is an extension from previous versions of TLS, and is not > mandatory > > How is that a problem? If you need the functionality, then > implementing ALPN is not especially onerous. Actually, I can only > think of negative characteristics of having it be mandatory. > --047d7bdc96b0027c9304fe5470aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For me TLS is a=C2=A0transport layer

UDP or TCP are transport layers. They identify the transported app= s pdu by a port number

Without a mandatory applica= tion identifier the TLS 1.3 will not give by default any information on the= transported application

I believe that a client certificate should be bound to = an application.

If no application identifier is av= ailable the client could set it to null.

Regards
Pascal


2014-07-16 18:25 GMT+02:00 Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com>:
On 16 July 2014 06:32, Pascal Urien <= ;pascal.urien@gmail.com> w= rote:
> But ALPN is an extension from previous versions of TLS, and is not man= datory

How is that a problem? =C2=A0If you need the functionality, then
implementing ALPN is not especially onerous. =C2=A0Actually, I can only
think of negative characteristics of having it be mandatory.

--047d7bdc96b0027c9304fe5470aa-- From nobody Wed Jul 16 12:49:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444651A01FF for ; Wed, 16 Jul 2014 12:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMnoiAjZY6dU for ; Wed, 16 Jul 2014 12:49:52 -0700 (PDT) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DBB1A001C for ; Wed, 16 Jul 2014 12:49:51 -0700 (PDT) Received: from [10.178.91.249] (85-76-104-11-nat.elisa-mobile.fi [85.76.104.11]) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 844EE40016; Wed, 16 Jul 2014 22:49:43 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Wed, 16 Jul 2014 22:49:41 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4F8BD5B9-0D93-41EC-AC87-2F8519CC0980@iki.fi> References: To: Pascal Urien Archived-At: http://mailarchive.ietf.org/arch/msg/tls/z0a_Xb0HHpVsrotGMp4rkzy7YzY Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Application Identifier ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2014 19:49:54 -0000 On 16.7.2014, at 22.21, Pascal Urien wrote: >=20 > For me TLS is a transport layer >=20 > UDP or TCP are transport layers. They identify the transported apps pdu by= a port number I'm a bit lost here, as far as I know TLS always works on top of UDP or TCP,= and therefore the port numbers identifying transported apps apply there as w= ell. > Without a mandatory application identifier the TLS 1.3 will not give by de= fault any information on the transported application It does give information with either the port number, and if e.g. 443 is alw= ays used for firewall compatibility, then ALPN works. > I believe that a client certificate should be bound to an application. Can you give some specific reasoning for this? I don't see anything forbiddi= ng certificate selection based on ALPN either. Or you can run TLS in differe= nt TCP ports for different applications. > If no application identifier is available the client could set it to null.= Or it could simply not send the ALPN extension. Juho From nobody Wed Jul 16 14:37:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDDDA1A0317 for ; Wed, 16 Jul 2014 14:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f_IUgg9Ft4c2 for ; Wed, 16 Jul 2014 14:37:23 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66F801A0085 for ; Wed, 16 Jul 2014 14:37:23 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id la4so2866620vcb.5 for ; Wed, 16 Jul 2014 14:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KVrchEBfb/j3BtOtPWc/+CW4D79kEcrzbL9ZexZ5U2A=; b=d4EKo4CAsFCejccy/hwM8HhKstTBkwT/SD5HfGGptXMpKjvU+rn5MNsJH45vXHAhpM dhOSSeVUYlsEZaLiRdXBKnGYY6gpr0Lkqm4Y0D6MezE3oOMta0C4V6mUG8eXMP14T0Cz HZMbXMgMBwU/d3f3XMK43GgXUYh8xYhaj7Va5ctWTxmphTuYuoHc52vHU+/CLgisyYX2 NLays7ewMYZOszZ2+FZcyPe0GU9RKP4AwBHx6TZ3zM/wgGOHx/d5tRabGMX1jOXhyUY8 dcJbiExWi5MKeqRDH39td1/P4SkDCn6t6fjuOoRfUg77oJi/G8ZysAK401hJDvEZQPrM x5pg== MIME-Version: 1.0 X-Received: by 10.52.158.198 with SMTP id ww6mr27771233vdb.17.1405546642439; Wed, 16 Jul 2014 14:37:22 -0700 (PDT) Received: by 10.220.13.1 with HTTP; Wed, 16 Jul 2014 14:37:22 -0700 (PDT) In-Reply-To: References: Date: Thu, 17 Jul 2014 01:37:22 +0400 Message-ID: From: Mohamad Badra To: Pascal Urien Content-Type: multipart/alternative; boundary=089e0160c97056842404fe565408 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bwx1ETXWwpRUICaezwl7SQ3NKNc Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Application Identifier ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2014 21:37:28 -0000 --089e0160c97056842404fe565408 Content-Type: text/plain; charset=ISO-8859-1 Hi Pascal You may have a look at the following document: http://tools.ietf.org/html/draft-badra-tls-multiplexing-01 Or http://tools.ietf.org/html/draft-badra-hajjeh-mtls-06 Best regards Badra On Wed, Jul 16, 2014 at 12:32 PM, Pascal Urien wrote: > Hi All > It seems there is no identifier for the application SDU transported by > TLS 1.3 (which is obviously a transport protocol) > > With the legacy TLS, the application is identified by a TCP or UDP port. > Some TLS extensions have been proposed to solve this issue. > > What about adding a mandatory application identifier in the client hello > message?. > > It could be a two bytes integer (i.e. TCP or UDP port) or something else > such as an application name > > A mandatory application identifier in the client hello message avoids > tentative connections to non-available applications. It also could > establish a logical link between client certificate and applications > > Regards > > Pascal Urien > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --089e0160c97056842404fe565408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Pascal
You may have a look at the following documen= t:
Or


On Wed, Jul 16, 2014 at 12:32 PM, Pascal= Urien <pascal.urien@gmail.com> wrote:

Hi All

It seems there is no identifier for the = application SDU transported by=A0 TLS 1.3 (which is obviously a transport= =A0protocol)

With the legacy TLS, the application is identifi= ed by a TCP or UDP port. Some TLS extensions have been proposed to solve th= is issue.

What about adding a mandatory application identifier in the client= hello message?.

It could be a two bytes integer (i.e. TCP or= UDP port) or something else such as an application name

A mandatory application identifier in the client hello message avoids tenta= tive connections to non-available applications. It also could establish a l= ogical link between client certificate and applications

Regards

<= /div>
Pascal Urien
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls


--089e0160c97056842404fe565408-- From nobody Wed Jul 16 15:03:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2CFB1A0350 for ; Wed, 16 Jul 2014 15:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPX8_9mcBgAh for ; Wed, 16 Jul 2014 15:03:02 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 368201A035A for ; Wed, 16 Jul 2014 15:03:00 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id i13so1226516qae.6 for ; Wed, 16 Jul 2014 15:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ga35iVHReG/ohv6/KDj17KPJYQUT+XnZxd0yvmju7R0=; b=XAX6t3b0LszykRPTgI/HCeDBMd5YxbYur5OLOywsflpbXoWCDf34FZmed+LeGYZDJ2 8W8GeYq8ReAgC/d/PeuJwaOXxiVYM1tQwX2aBQgv1p+oXyA+XR94Ned+j7PcHSDI6Xc7 ozsbgHtUpWBez+5VxsqPKHZrkHWEvWso/tyn32wF+WBCzLQlXcaCXUejxycc7613/giK 7Gp0QkA/PScyGsA5JUAbfbumPKBZzJqAchmE4k9CVjMQ+dRjAdrgFmrFKsixBrzNR4Vo lIA1W4ijZXOjlFxloQc2e2axwmTQCeJ5uQPrVQsMLb5p+Rj5qtUWWyYF8/3XYgCRd/v+ ZaiA== MIME-Version: 1.0 X-Received: by 10.140.97.227 with SMTP id m90mr47516176qge.15.1405548179276; Wed, 16 Jul 2014 15:02:59 -0700 (PDT) Received: by 10.96.194.225 with HTTP; Wed, 16 Jul 2014 15:02:59 -0700 (PDT) In-Reply-To: <4F8BD5B9-0D93-41EC-AC87-2F8519CC0980@iki.fi> References: <4F8BD5B9-0D93-41EC-AC87-2F8519CC0980@iki.fi> Date: Thu, 17 Jul 2014 00:02:59 +0200 Message-ID: From: Pascal Urien To: =?UTF-8?B?SnVobyBWw6Row6QtSGVydHR1YQ==?= Content-Type: multipart/alternative; boundary=001a113a2a2ef0ca4704fe56afad Archived-At: http://mailarchive.ietf.org/arch/msg/tls/avbLWTH-onRkMoys5f3mM9zEdVE Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Application Identifier ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2014 22:03:04 -0000 --001a113a2a2ef0ca4704fe56afad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I believe that TLS 1.3 should work for the next 20 years, in ecosystems such as IoT or others And so for future framework, no mandatory means to identify the transported applications ?. No relationships between certificates and applications ? TLS 1.3 should be just a security layer, with no links with transported apps ? Pascal 2014-07-16 21:49 GMT+02:00 Juho V=C3=A4h=C3=A4-Herttua : > On 16.7.2014, at 22.21, Pascal Urien wrote: > > > > For me TLS is a transport layer > > > > UDP or TCP are transport layers. They identify the transported apps pdu > by a port number > > I'm a bit lost here, as far as I know TLS always works on top of UDP or > TCP, and therefore the port numbers identifying transported apps apply > there as well. > > > Without a mandatory application identifier the TLS 1.3 will not give by > default any information on the transported application > > It does give information with either the port number, and if e.g. 443 is > always used for firewall compatibility, then ALPN works. > > > I believe that a client certificate should be bound to an application. > > Can you give some specific reasoning for this? I don't see anything > forbidding certificate selection based on ALPN either. Or you can run TLS > in different TCP ports for different applications. > > > If no application identifier is available the client could set it to > null. > > Or it could simply not send the ALPN extension. > > > Juho > > --001a113a2a2ef0ca4704fe56afad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe that TLS 1.3 should work for the next 20 ye= ars, in ecosystems such as IoT or others

And so fo= r future framework, no mandatory means to identify the transported applicat= ions ?. No relationships between certificates and applications=C2=A0?

TLS 1.3 should be just a security layer, with no links = with transported apps ?

Pascal


2014-07-16 21:49 GMT+= 02:00 Juho V=C3=A4h=C3=A4-Herttua <juhovh@iki.fi>:
On 16.7.2014, at 22.21, Pascal Urien &l= t;pascal.urien@gmail.com> = wrote:
>
> For me TLS is a transport layer
>
> UDP or TCP are transport layers. They identify the transported apps pd= u by a port number

I'm a bit lost here, as far as I know TLS always works on top of = UDP or TCP, and therefore the port numbers identifying transported apps app= ly there as well.

> Without a mandatory application identifier the TLS 1.3 will not give b= y default any information on the transported application

It does give information with either the port number, and if e.g. 443= is always used for firewall compatibility, then ALPN works.

> I believe that a client certificate should be bound to an application.=

Can you give some specific reasoning for this? I don't see anythi= ng forbidding certificate selection based on ALPN either. Or you can run TL= S in different TCP ports for different applications.

> If no application identifier is available the client could set it to n= ull.

Or it could simply not send the ALPN extension.


Juho


--001a113a2a2ef0ca4704fe56afad-- From nobody Wed Jul 16 18:30:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD301A03EA for ; Wed, 16 Jul 2014 18:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deU8hN_vBywF for ; Wed, 16 Jul 2014 18:30:46 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 461761A03E8 for ; Wed, 16 Jul 2014 18:30:46 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id y13so2171081pdi.11 for ; Wed, 16 Jul 2014 18:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SY49llUny8STmX2e8x2kiCdf+iuJuSAXcxlNsQ2juMs=; b=H+ZPiS8zASVVa3fSDeqmyobsly/5ghWsxv8JS8PV+NGxGUSsuFR+6bDzp83fXxzIs/ VTbMbgjkZPvmKuY5YPn2cQZNU+i8zVggrycprGws47sqCjo4GGOv7BIdWzyD5arPM+2H YF2Xi+e6MWuI67n95BFntZc1H7z6WPgg75M5xSMXBsw9OLDUh3hAiui0iNFcaLFgQUpv nfwki5pul7Oz5Tnc7b7Vu8tmoag1MSx636UlJQCjzOVeXwRhHpuzfjICIbMrruX5MRrq Sd3kThncSFUpTG1PxzxDaaaR1LI+RZ6hPQ3/4kM7HGrxSQenwPSi2OSN6iCF1//mJ+wx gwJg== MIME-Version: 1.0 X-Received: by 10.68.110.3 with SMTP id hw3mr13685869pbb.144.1405560646006; Wed, 16 Jul 2014 18:30:46 -0700 (PDT) Received: by 10.70.56.3 with HTTP; Wed, 16 Jul 2014 18:30:45 -0700 (PDT) In-Reply-To: References: <4F8BD5B9-0D93-41EC-AC87-2F8519CC0980@iki.fi> Date: Wed, 16 Jul 2014 18:30:45 -0700 Message-ID: From: Peter Bowen To: Pascal Urien Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yk4KDoXr3hCl154F8rqKkXHlI40 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Application Identifier ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2014 01:30:47 -0000 On Wed, Jul 16, 2014 at 3:02 PM, Pascal Urien wrote: > And so for future framework, no mandatory means to identify the transported > applications ?. No relationships between certificates and applications ? TLS does not require certificates, so that it out of scope. There are existing RFCs that cover including service information in certificates, such as RFC 4985 (http://tools.ietf.org/html/rfc4985). I suspect that this will cover the use case you are discussing. Thanks, Peter From nobody Wed Jul 16 19:46:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19031A0442 for ; Wed, 16 Jul 2014 19:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCgRq8oDvhti for ; Wed, 16 Jul 2014 19:46:49 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3321A040C for ; Wed, 16 Jul 2014 19:46:48 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s6H2kkS2023247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Jul 2014 04:46:46 +0200 (MEST) In-Reply-To: To: Pascal Urien Date: Thu, 17 Jul 2014 04:46:46 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140717024646.3C3951ADAB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4Zk-St7YIzo2SNHwNJSShOnw2jU Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Application Identifier ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 02:46:51 -0000 Pascal Urien wrote: > > I believe that TLS 1.3 should work for the next 20 years, in ecosystems > such as IoT or others Considering the number of tentative changes from TLSv1.2 to TLSv1.3 so far, I considert it extremely likely that TLSv1.2 will be with us in 20 years... -Martin From nobody Wed Jul 16 20:32:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302971A0537 for ; Wed, 16 Jul 2014 20:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxM9x-dSXs5V for ; Wed, 16 Jul 2014 20:32:00 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D0841A0389 for ; Wed, 16 Jul 2014 20:32:00 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id b6so763321yha.8 for ; Wed, 16 Jul 2014 20:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ocj78/2nWlrrmsviDJiWF5VcZSLygvVqBOD2+qx7/aA=; b=BjgcX7VzMWLp9tHpDttg1Mj8nQfAPbjOjZcBA2+FB3AEZG/tXq95MEG5wlxVxFJNIM k5/pwESf9TM9o9u2e4QWNUzUZbOYhU2F7IqwuKRd56lrNSo/pCQerm1uOUZSjGFPWYhf QvBsZccUhD0hdGuOtiwnSWCclPmhJxS+hxAKKkLB6Lcak8+R19R8F4a7/T0Fpv9ugAEO SnCi2rI+BWbvUhWNTDId9xLCP+Z/cIqQGxpguhgJa7zoBgQccgG6xVX7zcM3keD6vH2S eQZnY5sjNrjcHsYo4C1bSIfTYkrZ/rU8upS/q3KIxxhuwd20RSuz0fTdwlBuD/uZqVKu XU/Q== MIME-Version: 1.0 X-Received: by 10.236.182.68 with SMTP id n44mr32827619yhm.131.1405567919892; Wed, 16 Jul 2014 20:31:59 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Wed, 16 Jul 2014 20:31:59 -0700 (PDT) In-Reply-To: <20140717024646.3C3951ADAB@ld9781.wdf.sap.corp> References: <20140717024646.3C3951ADAB@ld9781.wdf.sap.corp> Date: Wed, 16 Jul 2014 20:31:59 -0700 Message-ID: From: Watson Ladd To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fJ5GiI4sgGJJtmntc4PUUhFJiKo Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Application Identifier ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2014 03:32:02 -0000 And if there were zero changes beyond those necessary to deal with Triple Handshake, removal of weak ciphersuites, and 1RTT this would be different why? Furthermore, it's clear that the complexity of TLS doesn't solve the real problem of user (or mutual) authentication that is deployable. Interoperation with X509 makes authentication hard, which is why it is rarely done. Sincerely, Watson Ladd On Wed, Jul 16, 2014 at 7:46 PM, Martin Rex wrote: > Pascal Urien wrote: >> >> I believe that TLS 1.3 should work for the next 20 years, in ecosystems >> such as IoT or others > > Considering the number of tentative changes from TLSv1.2 to TLSv1.3 so far, > I considert it extremely likely that TLSv1.2 will be with us in 20 years... > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Jul 17 09:05:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC1A1B27B6 for ; Thu, 17 Jul 2014 09:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fl5g67kwgJI for ; Thu, 17 Jul 2014 09:05:33 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF95F1A0181 for ; Thu, 17 Jul 2014 09:05:33 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s6HG3vbN019179; Thu, 17 Jul 2014 09:05:32 -0700 Received: from sc-owa04.marvell.com ([199.233.58.150]) by mx0a-0016f401.pphosted.com with ESMTP id 1n6d4t0vy6-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 17 Jul 2014 09:05:32 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA04.marvell.com ([fe80::e56e:83a7:9eef:b5a1%16]) with mapi; Thu, 17 Jul 2014 09:05:31 -0700 From: Paul Lambert To: Mohamad Badra , Pascal Urien , "tls@ietf.org" Date: Thu, 17 Jul 2014 09:05:29 -0700 Thread-Topic: [TLS] TLS 1.3 Application Identifier ? Thread-Index: Ac+h2O6I8sP7r32/RACyaL4RLCxwYQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CFED415445D24paulmarvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-17_05:2014-07-17,2014-07-17,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407170175 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VpLWNfxiy1yV7oM9HdXmJVNHwbU Subject: Re: [TLS] TLS 1.3 Application Identifier ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2014 16:05:38 -0000 --_000_CFED415445D24paulmarvellcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable It may or may not map well into TLS, but in other forums, we=92re using a 6= octet identifier to describe services (aka applications). It=92s formed as a truncated hash of a =93service name=94 serviceId =3D SHA256( serviceName )[0:6] It can also be obscured by concatenating the Service Name with a key before= creating the identifier. Paul Hi Pascal You may have a look at the following document: http://tools.ietf.org/html/draft-badra-tls-multiplexing-01 Or http://tools.ietf.org/html/draft-badra-hajjeh-mtls-06 Best regards Badra On Wed, Jul 16, 2014 at 12:32 PM, Pascal Urien > wrote: Hi All It seems there is no identifier for the application SDU transported by TLS= 1.3 (which is obviously a transport protocol) With the legacy TLS, the application is identified by a TCP or UDP port. So= me TLS extensions have been proposed to solve this issue. What about adding a mandatory application identifier in the client hello me= ssage?. It could be a two bytes integer (i.e. TCP or UDP port) or something else su= ch as an application name A mandatory application identifier in the client hello message avoids tenta= tive connections to non-available applications. It also could establish a l= ogical link between client certificate and applications Regards Pascal Urien _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_CFED415445D24paulmarvellcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

It may or may not= map well into TLS, but in other forums, we=92re using a 6  octet iden= tifier to describe services (aka applications).
It=92s formed as = a truncated hash of a =93service name=94

  &n= bsp;    serviceId =3D SHA256( serviceName )[0:6]

It can also be obscured by concatenating the Service Name with a k= ey before creating the identifier.

Paul 


Hi Pas= cal
You may have a look at the following document:
Or
http://tool= s.ietf.org/html/draft-badra-hajjeh-mtls-06

Best regards
Badra

On Wed, Jul 16, 2014 at 12:32 PM, Pascal Urien = <pascal.urie= n@gmail.com> wrote:

Hi All

It seems there is no identifier for the applica= tion SDU transported by  TLS 1.3 (which is obviously a transport = protocol)

With the legacy TLS, the application is identified by a TCP or UDP port. So= me TLS extensions have been proposed to solve this issue.

What about adding a mandatory application identifier in the client hello me= ssage?.

It could be a two bytes integer (i.e. TCP or UDP port) or something else su= ch as an application name

A mandatory application identifier in the client hello message avoids tenta= tive connections to non-available applications. It also could establish a l= ogical link between client certificate and applications

Regards

=
Pascal Urien



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




--_000_CFED415445D24paulmarvellcom_-- From nobody Thu Jul 17 14:01:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7071C1B27E1 for ; Thu, 17 Jul 2014 14:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKRtY85_Sveb for ; Thu, 17 Jul 2014 14:01:07 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE60D1B27DD for ; Thu, 17 Jul 2014 14:01:06 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id q58so3789681wes.4 for ; Thu, 17 Jul 2014 14:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=7b4vIE2DJl4bJXEoQMCCmT4UrwXDwLrRfAbtwlNLdOw=; b=eGTnEHgrw4xrJpmMMoZe1D4WfiXFKGL3OlOWt3tieLyMU9leipePcWj1kyNOx5Lhuw Zo5UpWvRPskAQEaUm7j/v7sQT617ArEVZPibRN/zZedn+l0yRQ5kVzYhIHRwxSiYeE4q kpPrPHsgxJHtsjE5O52PGf9K3zTqiTveRLqEKjfTITJolWimhybRW9SkQ7IR1+MyG1Mv IRKGyoAq1vQ8rgXoUordOYJL5kiyHCpR9XjEIDgRzWXwf0eefeoK9A5O2W3YqT2fojsm X6ZAxQBU8wOzm9rKUxTBo4YBISApxn+rerZKuEZjG0tMzhsTdeb+UjdlSvsYRvxOuDe2 K0ng== MIME-Version: 1.0 X-Received: by 10.194.172.167 with SMTP id bd7mr49104927wjc.74.1405630865482; Thu, 17 Jul 2014 14:01:05 -0700 (PDT) Received: by 10.194.18.232 with HTTP; Thu, 17 Jul 2014 14:01:05 -0700 (PDT) Received: by 10.194.18.232 with HTTP; Thu, 17 Jul 2014 14:01:05 -0700 (PDT) Date: Fri, 18 Jul 2014 05:01:05 +0800 Message-ID: From: Kenneth Mccracken To: TLS@ietf.org Content-Type: multipart/alternative; boundary=089e013c6c226c2aa004fe69f037 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PUG_kwCVsrQCtJ3aAKenxLyvIUk Subject: [TLS] (no subject) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2014 21:01:08 -0000 --089e013c6c226c2aa004fe69f037 Content-Type: text/plain; charset=UTF-8 Please stop sending email --089e013c6c226c2aa004fe69f037 Content-Type: text/html; charset=UTF-8

Please stop sending email

--089e013c6c226c2aa004fe69f037-- From nobody Thu Jul 17 15:09:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7499A1B2829 for ; Thu, 17 Jul 2014 15:09: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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0VwGK7twvYK for ; Thu, 17 Jul 2014 15:09:36 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6379D1B2807 for ; Thu, 17 Jul 2014 15:09:36 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id r5so2708869qcx.13 for ; Thu, 17 Jul 2014 15:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KdM5b0xO0nEQ9xVPJvaG5Gg340LCgExNK6Nxln8xaoU=; b=M1M66FxIIb4BiEKOp7Fw6JKQ0mI0e8mDbj9paaGuvLjaDh1Fn3gPNB/CdcyZlZqTAI OO/rJQmrMPJ6PYmFR/ql/q4Cs8GEiI+3OwbRkxUZb9vKsyQ0gZvpc5Tb5dx8R88H7BMR LLxitko7ZRjI26h7mWdRDt1cY0qkJXGgI6tU0mRCCvr2tuqqhjmX9QRGr/h2cypYQOSU kgDQQNqeKcdzTf5CipyhY2B2nVufiFfzDvasreG3zbYicJ4CDb4uizWVtwEqCA6ZRTS8 o93TnCe8GT3kl5fujLJTlQhQj2uIZr0Z/ead7Ua28spzjqwbA4LwYJqBLjAgZlDGE2Fi sD7w== MIME-Version: 1.0 X-Received: by 10.224.28.65 with SMTP id l1mr192524qac.87.1405634975583; Thu, 17 Jul 2014 15:09:35 -0700 (PDT) Received: by 10.96.194.225 with HTTP; Thu, 17 Jul 2014 15:09:35 -0700 (PDT) In-Reply-To: References: Date: Fri, 18 Jul 2014 00:09:35 +0200 Message-ID: From: Pascal Urien To: Paul Lambert Content-Type: multipart/alternative; boundary=001a11c2cd2867559a04fe6ae51c Archived-At: http://mailarchive.ietf.org/arch/msg/tls/99oYuo-hIb5N-jIQZ-uDiPDa2P4 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Application Identifier ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2014 22:09:38 -0000 --001a11c2cd2867559a04fe6ae51c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi All Finished messages are encrypted. That are produced first by server and second by client. The today semantic (TLS1.3) of these messages is server finished and client finished (a cryptographic proof of the knowledge of secrets) They could be used also to transport protected application identifiers for both server and client ?! Regards Pascal 2014-07-17 18:05 GMT+02:00 Paul Lambert : > > It may or may not map well into TLS, but in other forums, we=E2=80=99re u= sing a 6 > octet identifier to describe services (aka applications). > It=E2=80=99s formed as a truncated hash of a =E2=80=9Cservice name=E2=80= =9D > > serviceId =3D SHA256( serviceName )[0:6] > > It can also be obscured by concatenating the Service Name with a key > before creating the identifier. > > Paul > > > Hi Pascal > You may have a look at the following document: > http://tools.ietf.org/html/draft-badra-tls-multiplexing-01 > Or > http://tools.ietf.org/html/draft-badra-hajjeh-mtls-06 > > Best regards > Badra > > > On Wed, Jul 16, 2014 at 12:32 PM, Pascal Urien > wrote: > >> Hi All >> It seems there is no identifier for the application SDU transported by >> TLS 1.3 (which is obviously a transport protocol) >> >> With the legacy TLS, the application is identified by a TCP or UDP port. >> Some TLS extensions have been proposed to solve this issue. >> >> What about adding a mandatory application identifier in the client hello >> message?. >> >> It could be a two bytes integer (i.e. TCP or UDP port) or something else >> such as an application name >> >> A mandatory application identifier in the client hello message avoids >> tentative connections to non-available applications. It also could >> establish a logical link between client certificate and applications >> >> Regards >> >> Pascal Urien >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > > > --001a11c2cd2867559a04fe6ae51c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All

Finished messages are= encrypted. That are produced first by server=C2=A0and second by client.

The today semantic (TLS1.3) of these messages is ser= ver finished and client finished (a cryptographic proof of the knowledge of= secrets)

They could be used also to transport protected applicat= ion identifiers for both server and client ?!

Rega= rds

Pascal


2014-07-17 18:05 GMT+02:00 Paul Lambert = <paul@marvell.com>:

It may or may not map well into TLS, but in other fo= rums, we=E2=80=99re using a 6 =C2=A0octet identifier to describe services (= aka applications).
It=E2=80=99s formed as a truncated hash of a =E2=80=9Cservice name=E2= =80=9D

=C2=A0 =C2=A0 =C2=A0 =C2=A0serviceId =3D SH= A256( serviceName )[0:6]

It can also be obscured b= y concatenating the Service Name with a key before creating the identifier.=

Paul=C2= =A0


Hi Pascal
You may have a look at the following document:
Or

Best regards
Badra
<= div class=3D"gmail_extra">

On Wed, Jul 16, 2014 at 12:32 PM, Pascal= Urien <pascal.urie= n@gmail.com> wrote:

Hi All

It seems there is no identifier for the = application SDU transported by=C2=A0 TLS 1.3 (which is obviously a transpor= t=C2=A0protocol)

With the legacy TLS, the application is identified by a TCP or UDP port. So= me TLS extensions have been proposed to solve this issue.

What about adding a mandatory application identifier in the client hello me= ssage?.

It could be a two bytes integer (i.e. TCP or UDP port) or something else su= ch as an application name

A mandatory application identifier in the client hello message avoids tenta= tive connections to non-available applications. It also could establish a l= ogical link between client certificate and applications

Regards

P= ascal Urien



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





--001a11c2cd2867559a04fe6ae51c-- From nobody Thu Jul 17 20:32:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6021A04AC for ; Thu, 17 Jul 2014 20:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58j0HP8cSWBN for ; Thu, 17 Jul 2014 20:32:46 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7195E1A0452 for ; Thu, 17 Jul 2014 20:32:46 -0700 (PDT) Received: by mail-yk0-f178.google.com with SMTP id 142so1860792ykq.23 for ; Thu, 17 Jul 2014 20:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JAxO0WzMhs5zUzI+PXgNQsDFVCUdR1f5AWXvPcfHqWg=; b=HEoRcLSmwX0hqs703JzMLL17Xoq1JihEpsXt7s+S3QedfwYl6475ssdA0Jn5VFGrXo 0v6FKtdDOR8HunFZOkiGPdj9vTBBu/+bycTf3C5ZqJ7WRmincC13u8G84hPOyt6mzyxy 79+3cV3bxkImirBrdpHxdZSDDba6M7Gnxc19+kiVwF13GDioFTDaeSZEvGPvmol240ci te8JixjVitcPlz/c6etBAvXrSK6utWFQzsMfLNnJRDMfInBoBczekoShbY8DUfC84uUR z4Sh7rwaNx1j78P74Z+RDxICW5CetZ0nq++KFJMq+ia9XEG5GF8hHvM/09XSenT9HxNR 7ZZA== MIME-Version: 1.0 X-Received: by 10.236.28.167 with SMTP id g27mr2875078yha.120.1405654365640; Thu, 17 Jul 2014 20:32:45 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Thu, 17 Jul 2014 20:32:45 -0700 (PDT) In-Reply-To: References: Date: Thu, 17 Jul 2014 20:32:45 -0700 Message-ID: From: Watson Ladd To: Pascal Urien Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/j1f2jtgDJzHxnCorezsLlRZ7bSc Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Application Identifier ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2014 03:32:48 -0000 What do you mean by "application identifier"? Is http enough, or should it be the application on top of http? What do you need it for? Why does it need to be manadatory: why not require clients to use ALPN? If you want to link the client cert to application (what does that mean?) why can't the ChannelID draft serve your purposes? On Thu, Jul 17, 2014 at 3:09 PM, Pascal Urien wrot= e: > Hi All > > Finished messages are encrypted. That are produced first by server and > second by client. > > The today semantic (TLS1.3) of these messages is server finished and clie= nt > finished (a cryptographic proof of the knowledge of secrets) > > They could be used also to transport protected application identifiers fo= r > both server and client ?! > > Regards > > Pascal > > > 2014-07-17 18:05 GMT+02:00 Paul Lambert : > >> >> It may or may not map well into TLS, but in other forums, we=E2=80=99re = using a 6 >> octet identifier to describe services (aka applications). >> It=E2=80=99s formed as a truncated hash of a =E2=80=9Cservice name=E2=80= =9D >> >> serviceId =3D SHA256( serviceName )[0:6] >> >> It can also be obscured by concatenating the Service Name with a key >> before creating the identifier. >> >> Paul >> >> >> Hi Pascal >> You may have a look at the following document: >> http://tools.ietf.org/html/draft-badra-tls-multiplexing-01 >> Or >> http://tools.ietf.org/html/draft-badra-hajjeh-mtls-06 >> >> Best regards >> Badra >> >> >> On Wed, Jul 16, 2014 at 12:32 PM, Pascal Urien >> wrote: >>> >>> Hi All >>> >>> It seems there is no identifier for the application SDU transported by >>> TLS 1.3 (which is obviously a transport protocol) >>> >>> With the legacy TLS, the application is identified by a TCP or UDP port= . >>> Some TLS extensions have been proposed to solve this issue. >>> >>> What about adding a mandatory application identifier in the client hell= o >>> message?. >>> >>> It could be a two bytes integer (i.e. TCP or UDP port) or something els= e >>> such as an application name >>> >>> A mandatory application identifier in the client hello message avoids >>> tentative connections to non-available applications. It also could esta= blish >>> a logical link between client certificate and applications >>> >>> Regards >>> >>> Pascal Urien >>> >>> >>> >>> _______________________________________________ >>> 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 > --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Jul 18 01:01:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74601A0A8D for ; Fri, 18 Jul 2014 01:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEB28DV2a2Ft for ; Fri, 18 Jul 2014 01:00:58 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 367FA1A0658 for ; Fri, 18 Jul 2014 01:00:58 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id r5so3077773qcx.10 for ; Fri, 18 Jul 2014 01:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JcwccD1ZZvO0yT06PgNpYITSvAmcuNQEy9OmYihT8Ns=; b=z13QwpI+5jwxwbdIHpujBAVXAIuJ7pQs/GGRgDwABa6B87lhKSmTv42SuRKvc5R/ps RtbwU4PnP2aFlgqSNG08K8caUovOKjXEIYCfNQGnySrnolUKxOPbaBECJ4QUngMxR8eM O/oVrfSLo4oIHqOHAhh/oE6mhGEd7qkB1Frwm/GnRCeVB6b/CNcaPBhdVACpOC2v0MKs mYTkrBM+/SqSqAZuPkwLT6j6cBc4jXPuxlqnUSo6vw2eOgXnriVAl4Kr8MMw6cWTj5g6 ycLyaeMta+UCDp4EkTsjy3uwAqNODyo/b990j/fEizT3HrNmf1Imb5nB5PjA9fDmhrTQ UcVg== MIME-Version: 1.0 X-Received: by 10.140.40.165 with SMTP id x34mr4902089qgx.23.1405670457266; Fri, 18 Jul 2014 01:00:57 -0700 (PDT) Received: by 10.96.194.225 with HTTP; Fri, 18 Jul 2014 01:00:57 -0700 (PDT) In-Reply-To: References: Date: Fri, 18 Jul 2014 10:00:57 +0200 Message-ID: From: Pascal Urien To: Watson Ladd Content-Type: multipart/alternative; boundary=001a11c153ca46d81c04fe732817 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WSE2GLb4eQjUhQPXBIL7ieVM3WQ Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Application Identifier ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2014 08:01:00 -0000 --001a11c153ca46d81c04fe732817 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alll According to TLS1.3 =E2=80=9CThe primary goal of the TLS protocol is to pro= vide privacy and data integrity between two communicating applications=E2=80=9D In my mind an application identifier identifies the application SDU transported by TLS 1.3. An application identifier could a be a name or a hash value of an application name At the beginning SSL was designed to secure HTTP, and used the 443 port, HTTP was implicitly the application. Many internet applications used a TCP/UDP port as application identifier with SSL/TLS With ALPN the client used an extension that contains several applications name (such as "http/1.1", "spdy/1"), and the server selects one of them. So ALPN realizes two things, it identifies application, and the server selects of them. ALPN in not mandatory anyway. For future use of TLS1.3 I believe that application identification and selection is important. Why not a list of application identifiers in the server finished message=E2= =80=A6 And the selected application identifier in the client finished message=E2= =80=A6 Regards Pascal 2014-07-18 5:32 GMT+02:00 Watson Ladd : > What do you mean by "application identifier"? Is http enough, or > should it be the application on top of http? > > What do you need it for? Why does it need to be manadatory: why not > require clients to use ALPN? > > If you want to link the client cert to application (what does that > mean?) why can't the ChannelID draft serve your purposes? > > On Thu, Jul 17, 2014 at 3:09 PM, Pascal Urien > wrote: > > Hi All > > > > Finished messages are encrypted. That are produced first by server and > > second by client. > > > > The today semantic (TLS1.3) of these messages is server finished and > client > > finished (a cryptographic proof of the knowledge of secrets) > > > > They could be used also to transport protected application identifiers > for > > both server and client ?! > > > > Regards > > > > Pascal > > > > > > 2014-07-17 18:05 GMT+02:00 Paul Lambert : > > > >> > >> It may or may not map well into TLS, but in other forums, we=E2=80=99r= e using a > 6 > >> octet identifier to describe services (aka applications). > >> It=E2=80=99s formed as a truncated hash of a =E2=80=9Cservice name=E2= =80=9D > >> > >> serviceId =3D SHA256( serviceName )[0:6] > >> > >> It can also be obscured by concatenating the Service Name with a key > >> before creating the identifier. > >> > >> Paul > >> > >> > >> Hi Pascal > >> You may have a look at the following document: > >> http://tools.ietf.org/html/draft-badra-tls-multiplexing-01 > >> Or > >> http://tools.ietf.org/html/draft-badra-hajjeh-mtls-06 > >> > >> Best regards > >> Badra > >> > >> > >> On Wed, Jul 16, 2014 at 12:32 PM, Pascal Urien > >> wrote: > >>> > >>> Hi All > >>> > >>> It seems there is no identifier for the application SDU transported b= y > >>> TLS 1.3 (which is obviously a transport protocol) > >>> > >>> With the legacy TLS, the application is identified by a TCP or UDP > port. > >>> Some TLS extensions have been proposed to solve this issue. > >>> > >>> What about adding a mandatory application identifier in the client > hello > >>> message?. > >>> > >>> It could be a two bytes integer (i.e. TCP or UDP port) or something > else > >>> such as an application name > >>> > >>> A mandatory application identifier in the client hello message avoids > >>> tentative connections to non-available applications. It also could > establish > >>> a logical link between client certificate and applications > >>> > >>> Regards > >>> > >>> Pascal Urien > >>> > >>> > >>> > >>> _______________________________________________ > >>> TLS mailing list > >>> TLS@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tls > >>> > >> > >> > >> > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > > -- > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin > --001a11c153ca46d81c04fe732817 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi=C2=A0 Alll
According to TLS1.3 =E2=80=9CThe primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications=E2=80=9D

=C2=A0In my mind an application identifier identifies the application SDU transported by TLS 1.= 3.=C2=A0 An application identifier could a be a name or a hash value of an application name

=C2=A0At the beginning SSL was designed to secure HTTP, and used the 443 port, HTTP was implicitly the application. Many internet applications used a TCP/UDP port as application = identifier with SSL/TLS

=C2=A0With ALPN the client used an extension that contains several applications name (such as "ht= tp/1.1", "spdy/1"), and the server selects one of them. So ALPN realizes t= wo things, it identifies application, and the server selects of them. ALPN in not mandatory anyway.

=C2=A0For future use of TLS1.3 I believe that application identification and selection is important= .

Why not a list of application identifiers in the server finished message=E2=80=A6

And the selected application identifier in the client finished message=E2=80=A6

Regards<= /font>
Pascal



= 2014-07-18 5:32 GMT+02:00 Watson Ladd <watsonbladd@gmail.com>:
What do you mean by "application identi= fier"? Is http enough, or
should it be the application on top of http?

What do you need it for? Why does it need to be manadatory: why not
require clients to use ALPN?

If you want to link the client cert to application (what does that
mean?) why can't the ChannelID draft serve your purposes?

On Thu, Jul 17, 2014 at 3:09 PM, Pascal Urien <pascal.urien@gmail.com> wrote:
> Hi All
>
> Finished messages are encrypted. That are produced first by server and=
> second by client.
>
> The today semantic (TLS1.3) of these messages is server finished and c= lient
> finished (a cryptographic proof of the knowledge of secrets)
>
> They could be used also to transport protected application identifiers= for
> both server and client ?!
>
> Regards
>
> Pascal
>
>
> 2014-07-17 18:05 GMT+02:00 Paul Lambert <paul@marvell.com>:
>
>>
>> It may or may not map well into TLS, but in other forums, we=E2=80= =99re using a 6
>> octet identifier to describe services (aka applications).
>> It=E2=80=99s formed as a truncated hash of a =E2=80=9Cservice name= =E2=80=9D
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0serviceId =3D SHA256( serviceName )[0:6= ]
>>
>> It can also be obscured by concatenating the Service Name with a k= ey
>> before creating the identifier.
>>
>> Paul
>>
>>
>> Hi Pascal
>> You may have a look at the following document:
>> http://tools.ietf.org/html/draft-badra-tls-multiplex= ing-01
>> Or
>> http://tools.ietf.org/html/draft-badra-hajjeh-mtls-06=
>>
>> Best regards
>> Badra
>>
>>
>> On Wed, Jul 16, 2014 at 12:32 PM, Pascal Urien <pascal.urien@gmail.com>
>> wrote:
>>>
>>> Hi All
>>>
>>> It seems there is no identifier for the application SDU transp= orted by
>>> TLS 1.3 (which is obviously a transport protocol)
>>>
>>> With the legacy TLS, the application is identified by a TCP or= UDP port.
>>> Some TLS extensions have been proposed to solve this issue. >>>
>>> What about adding a mandatory application identifier in the cl= ient hello
>>> message?.
>>>
>>> It could be a two bytes integer (i.e. TCP or UDP port) or some= thing else
>>> such as an application name
>>>
>>> A mandatory application identifier in the client hello message= avoids
>>> tentative connections to non-available applications. It also c= ould establish
>>> a logical link between client certificate and applications
>>>
>>> Regards
>>>
>>> Pascal Urien
>>>
>>>
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>
>>
>>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



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

--001a11c153ca46d81c04fe732817-- From nobody Fri Jul 18 01:07:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670381A00DE for ; Fri, 18 Jul 2014 01:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtacTmWbSPNb for ; Fri, 18 Jul 2014 01:07:31 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0284C1A00D2 for ; Fri, 18 Jul 2014 01:07:30 -0700 (PDT) Received: by mail-oi0-f53.google.com with SMTP id e131so1750383oig.40 for ; Fri, 18 Jul 2014 01:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Lzyb2ySqU+4o7Owlte2RUjPDVahNb/Dk6Wl3eL9nd8U=; b=BzUf3R9yAS3pAstgYoqlVSA+q5V/oScGQWLCrJLKsHVt1Cfby1t8QPKge3XD/FtPe2 jE+wLJZWa2gSbBeEL80L3Id/fzIWdTCKrdkxE/D79SnP6xGnaM22I1iak26zadqymZvb CSvRfXzKtg0/w8Kofcl7avXdcNIt5ZcguVV4k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Lzyb2ySqU+4o7Owlte2RUjPDVahNb/Dk6Wl3eL9nd8U=; b=G4GB+XNvKpDS43QiFuQ9ujPSKVoQ213IrfycjBupVwibUaggRwMqUYl8QlpxaeZZtZ tpC/036hbUG2pxMqOwDFiTTq6atMiuRXpEYgIPeej6yP2C4nBuwsHGgKYBDXGmxQ79aO snSbapHH7ZNdmYSaawzdVJFp+dGhIV2TTm2Cm1dudcFVJXnwLq3YZ8Ne3Pc+srpARTm7 KLguPCgrBMolhlrifSVZUEj3etDA+fVaEybwPIWh8El+U50itm8/oyiFMzHhyLEr+uEu nr4cOy2tGTjkoXTSWarHbrdaC/osddCGi/TC/Xt/sZTvKBCPKjv4W+mRjHI+jKtXprN2 VR9Q== X-Gm-Message-State: ALoCoQm0AerBoWbZSNpnQDsmqkM4FZ6yl4H/bnHzvda8tEFgR85IJ7iad0si+9AfpZg9KjyPaKGE MIME-Version: 1.0 X-Received: by 10.182.211.16 with SMTP id my16mr3957938obc.43.1405670850046; Fri, 18 Jul 2014 01:07:30 -0700 (PDT) Received: by 10.76.25.42 with HTTP; Fri, 18 Jul 2014 01:07:29 -0700 (PDT) X-Originating-IP: [128.93.188.195] In-Reply-To: References: Date: Fri, 18 Jul 2014 10:07:29 +0200 Message-ID: From: Alfredo Pironti To: Pascal Urien Content-Type: multipart/alternative; boundary=e89a8f83a985b0424304fe733f84 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/K_uZ3euPynC-3J8H_3txTIe5IpM Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Application Identifier ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2014 08:07:36 -0000 --e89a8f83a985b0424304fe733f84 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 18, 2014 at 10:00 AM, Pascal Urien wrote: > Hi Alll > According to TLS1.3 =E2=80=9CThe primary goal of the TLS protocol is to p= rovide > privacy and data integrity between two communicating applications=E2=80= =9D > > In my mind an application identifier identifies the application SDU > transported by TLS 1.3. An application identifier could a be a name or a > hash value of an application name > > At the beginning SSL was designed to secure HTTP, and used the 443 port, > HTTP was implicitly the application. Many internet applications used a > TCP/UDP port as application identifier with SSL/TLS > > With ALPN the client used an extension that contains several > applications name (such as "http/1.1", "spdy/1"), and the server selects > one of them. So ALPN realizes two things, it identifies application, and > the server selects of them. ALPN in not mandatory anyway. > > For future use of TLS1.3 I believe that application identification and > selection is important. > > Why not a list of application identifiers in the server finished message= =E2=80=A6 > And the selected application identifier in the client finished message=E2= =80=A6 > That would be too early. Although Finished messages are encrypted, by the time they're sent the encryption keys are not confirmed yet. Indeed, the Finished message content (verify data) is the way keys get confirmed. Hence, in TLS 1.2 you'd need another round trip, or give up the secrecy of such information. This has been thoroughly discussed in the ALPN vs NPN thread. Best, Alfredo > > Regards > Pascal > > > > 2014-07-18 5:32 GMT+02:00 Watson Ladd : > > What do you mean by "application identifier"? Is http enough, or >> should it be the application on top of http? >> >> What do you need it for? Why does it need to be manadatory: why not >> require clients to use ALPN? >> >> If you want to link the client cert to application (what does that >> mean?) why can't the ChannelID draft serve your purposes? >> >> On Thu, Jul 17, 2014 at 3:09 PM, Pascal Urien >> wrote: >> > Hi All >> > >> > Finished messages are encrypted. That are produced first by server and >> > second by client. >> > >> > The today semantic (TLS1.3) of these messages is server finished and >> client >> > finished (a cryptographic proof of the knowledge of secrets) >> > >> > They could be used also to transport protected application identifiers >> for >> > both server and client ?! >> > >> > Regards >> > >> > Pascal >> > >> > >> > 2014-07-17 18:05 GMT+02:00 Paul Lambert : >> > >> >> >> >> It may or may not map well into TLS, but in other forums, we=E2=80=99= re using >> a 6 >> >> octet identifier to describe services (aka applications). >> >> It=E2=80=99s formed as a truncated hash of a =E2=80=9Cservice name=E2= =80=9D >> >> >> >> serviceId =3D SHA256( serviceName )[0:6] >> >> >> >> It can also be obscured by concatenating the Service Name with a key >> >> before creating the identifier. >> >> >> >> Paul >> >> >> >> >> >> Hi Pascal >> >> You may have a look at the following document: >> >> http://tools.ietf.org/html/draft-badra-tls-multiplexing-01 >> >> Or >> >> http://tools.ietf.org/html/draft-badra-hajjeh-mtls-06 >> >> >> >> Best regards >> >> Badra >> >> >> >> >> >> On Wed, Jul 16, 2014 at 12:32 PM, Pascal Urien > > >> >> wrote: >> >>> >> >>> Hi All >> >>> >> >>> It seems there is no identifier for the application SDU transported = by >> >>> TLS 1.3 (which is obviously a transport protocol) >> >>> >> >>> With the legacy TLS, the application is identified by a TCP or UDP >> port. >> >>> Some TLS extensions have been proposed to solve this issue. >> >>> >> >>> What about adding a mandatory application identifier in the client >> hello >> >>> message?. >> >>> >> >>> It could be a two bytes integer (i.e. TCP or UDP port) or something >> else >> >>> such as an application name >> >>> >> >>> A mandatory application identifier in the client hello message avoid= s >> >>> tentative connections to non-available applications. It also could >> establish >> >>> a logical link between client certificate and applications >> >>> >> >>> Regards >> >>> >> >>> Pascal Urien >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> TLS mailing list >> >>> TLS@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/tls >> >>> >> >> >> >> >> >> >> > >> > >> > _______________________________________________ >> > TLS mailing list >> > TLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/tls >> > >> >> >> >> -- >> "Those who would give up Essential Liberty to purchase a little >> Temporary Safety deserve neither Liberty nor Safety." >> -- Benjamin Franklin >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --e89a8f83a985b0424304fe733f84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 18, 2014 at 10:00 AM, Pascal Urien &l= t;pascal.urien@= gmail.com> wrote:
Hi=C2=A0 Alll
According to TLS1.3 =E2=80=9CThe primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications=E2=80=9D

=C2=A0In my mind an application identifier identifies the application SDU transported by TLS 1.= 3.=C2=A0 An application identifier could a be a name or a hash value of an application name

=C2=A0At the beginning SSL was designed to secure HTTP, and used the 443 port, HTTP was implicitly the application. Many internet applications used a TCP/UDP port as application = identifier with SSL/TLS

=C2=A0With ALPN the client used an extension that contains several applications name (such as "ht= tp/1.1", "spdy/1"), and the server selects one of them. So ALPN realizes t= wo things, it identifies application, and the server selects of them. ALPN in not mandatory anyway.

=C2=A0For future use of TLS1.3 I believe that application identification and selection is important= .

Why not a list of application identifiers in the server finished message=E2=80=A6

And the selected application identifier in the client finished message=E2=80=A6

That would be too early. Alth= ough Finished messages are encrypted, by the time they're sent the encr= yption keys are not confirmed yet. Indeed, the Finished message content (ve= rify data) is the way keys get confirmed. Hence, in TLS 1.2 you'd need = another round trip, or give up the secrecy of such information. This has be= en thoroughly discussed in the ALPN vs NPN thread.

Best,
Alfredo
=C2=A0

Regards
Pascal



= 2014-07-18 5:32 GMT+02:00 Watson Ladd <watsonbladd@gmail.com>:

What do you mean by "application identi= fier"? Is http enough, or
should it be the application on top of http?

What do you need it for? Why does it need to be manadatory: why not
require clients to use ALPN?

If you want to link the client cert to application (what does that
mean?) why can't the ChannelID draft serve your purposes?

On Thu, Jul 17, 2014 at 3:09 PM, Pascal Urien <pascal.urien@gmail.com> wrote: > Hi All
>
> Finished messages are encrypted. That are produced first by server and=
> second by client.
>
> The today semantic (TLS1.3) of these messages is server finished and c= lient
> finished (a cryptographic proof of the knowledge of secrets)
>
> They could be used also to transport protected application identifiers= for
> both server and client ?!
>
> Regards
>
> Pascal
>
>
> 2014-07-17 18:05 GMT+02:00 Paul Lambert <paul@marvell.com>:
>
>>
>> It may or may not map well into TLS, but in other forums, we=E2=80= =99re using a 6
>> octet identifier to describe services (aka applications).
>> It=E2=80=99s formed as a truncated hash of a =E2=80=9Cservice name= =E2=80=9D
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0serviceId =3D SHA256( serviceName )[0:6= ]
>>
>> It can also be obscured by concatenating the Service Name with a k= ey
>> before creating the identifier.
>>
>> Paul
>>
>>
>> Hi Pascal
>> You may have a look at the following document:
>> http://tools.ietf.org/html/draft-badra-tls-multiplex= ing-01
>> Or
>> http://tools.ietf.org/html/draft-badra-hajjeh-mtls-06=
>>
>> Best regards
>> Badra
>>
>>
>> On Wed, Jul 16, 2014 at 12:32 PM, Pascal Urien <pascal.urien@gmail.com>=
>> wrote:
>>>
>>> Hi All
>>>
>>> It seems there is no identifier for the application SDU transp= orted by
>>> TLS 1.3 (which is obviously a transport protocol)
>>>
>>> With the legacy TLS, the application is identified by a TCP or= UDP port.
>>> Some TLS extensions have been proposed to solve this issue. >>>
>>> What about adding a mandatory application identifier in the cl= ient hello
>>> message?.
>>>
>>> It could be a two bytes integer (i.e. TCP or UDP port) or some= thing else
>>> such as an application name
>>>
>>> A mandatory application identifier in the client hello message= avoids
>>> tentative connections to non-available applications. It also c= ould establish
>>> a logical link between client certificate and applications
>>>
>>> Regards
>>>
>>> Pascal Urien
>>>
>>>
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org=
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>
>>
>>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



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


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


--e89a8f83a985b0424304fe733f84-- From nobody Fri Jul 18 13:47:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0BB1A020A for ; Fri, 18 Jul 2014 13:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rIFb4IaUWCY for ; Fri, 18 Jul 2014 13:47:45 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC031A0065 for ; Fri, 18 Jul 2014 13:47:45 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s6IKkf3C019766; Fri, 18 Jul 2014 13:47:44 -0700 Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0a-0016f401.pphosted.com with ESMTP id 1n6q3fkby6-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 18 Jul 2014 13:47:43 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA03.marvell.com ([::1]) with mapi; Fri, 18 Jul 2014 13:47:31 -0700 From: Paul Lambert To: Pascal Urien , Watson Ladd Date: Fri, 18 Jul 2014 13:47:28 -0700 Thread-Topic: [TLS] TLS 1.3 Application Identifier ? Thread-Index: Ac+iyX3EonXbzhFWQNWui8zAR2ihog== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CFEED3C846346paulmarvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-18_05:2014-07-18,2014-07-18,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407180243 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vsVANILjPc2lYv1tT2ZI2UC304M Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Application Identifier ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2014 20:47:47 -0000 --_000_CFEED3C846346paulmarvellcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Alll According to TLS1.3 =93The primary goal of the TLS protocol is to provide p= rivacy and data integrity between two communicating applications=94 In my mind an application identifier identifies the application SDU transp= orted by TLS 1.3. An application identifier could a be a name or a hash va= lue of an application name Yes =96 as mentioned before, for wireless application/service discovery we = are pursuing hash values as identifiers. These enable large numbers of app= lications without a registry. They also offer some small measure of privac= y since the identifiers are not registered and the small size (6 octets) is= somewhat ambiguous. The truncated hash also provides some compression (= over string based names). Hash based =93service identifiers" are also framework neutral =96 the =93se= rvice name=94 can be Bonjour, DLNA/UPnP or any other name space. Identifie= rs may also be explicitly obscured by including a shared key with the servi= ce name in the hashing process. Hash identifiers could also map into a bloom filter based representation if= you have relatively large numbers of services. Paul At the beginning SSL was designed to secure HTTP, and used the 443 port, H= TTP was implicitly the application. Many internet applications used a TCP/U= DP port as application identifier with SSL/TLS With ALPN the client used an extension that contains several applications = name (such as "http/1.1", "spdy/1"), and the server selects one of them. So= ALPN realizes two things, it identifies application, and the server select= s of them. ALPN in not mandatory anyway. For future use of TLS1.3 I believe that application identification and sel= ection is important. Why not a list of application identifiers in the server finished message=85 And the selected application identifier in the client finished message=85 Regards Pascal 2014-07-18 5:32 GMT+02:00 Watson Ladd >: What do you mean by "application identifier"? Is http enough, or should it be the application on top of http? What do you need it for? Why does it need to be manadatory: why not require clients to use ALPN? If you want to link the client cert to application (what does that mean?) why can't the ChannelID draft serve your purposes? On Thu, Jul 17, 2014 at 3:09 PM, Pascal Urien > wrote: > Hi All > > Finished messages are encrypted. That are produced first by server and > second by client. > > The today semantic (TLS1.3) of these messages is server finished and clie= nt > finished (a cryptographic proof of the knowledge of secrets) > > They could be used also to transport protected application identifiers fo= r > both server and client ?! > > Regards > > Pascal > > > 2014-07-17 18:05 GMT+02:00 Paul Lambert >: > >> >> It may or may not map well into TLS, but in other forums, we=92re using = a 6 >> octet identifier to describe services (aka applications). >> It=92s formed as a truncated hash of a =93service name=94 >> >> serviceId =3D SHA256( serviceName )[0:6] >> >> It can also be obscured by concatenating the Service Name with a key >> before creating the identifier. >> >> Paul >> >> >> Hi Pascal >> You may have a look at the following document: >> http://tools.ietf.org/html/draft-badra-tls-multiplexing-01 >> Or >> http://tools.ietf.org/html/draft-badra-hajjeh-mtls-06 >> >> Best regards >> Badra >> >> >> On Wed, Jul 16, 2014 at 12:32 PM, Pascal Urien > >> wrote: >>> >>> Hi All >>> >>> It seems there is no identifier for the application SDU transported by >>> TLS 1.3 (which is obviously a transport protocol) >>> >>> With the legacy TLS, the application is identified by a TCP or UDP port= . >>> Some TLS extensions have been proposed to solve this issue. >>> >>> What about adding a mandatory application identifier in the client hell= o >>> message?. >>> >>> It could be a two bytes integer (i.e. TCP or UDP port) or something els= e >>> such as an application name >>> >>> A mandatory application identifier in the client hello message avoids >>> tentative connections to non-available applications. It also could esta= blish >>> a logical link between client certificate and applications >>> >>> Regards >>> >>> Pascal Urien >>> >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> >> >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin --_000_CFEED3C846346paulmarvellcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

=

Hi  Alll
According to TLS1.3 =93The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications=94

 = In my mind an application identifier identifies the application SDU transported by TLS 1.= 3.  An application identifier could a be a name or a hash value of an application name


Yes =96 as mentioned before, for wireless= application/service discovery we are pursuing hash values as identifiers. =  These enable large numbers of applications without a registry.  = They also offer some small measure of privacy since the identifiers are not= registered and the small size (6 octets) is somewhat ambiguous.   The= truncated hash also provides some  compression (over string based nam= es).

Hash based =93service identifiers" are a= lso framework neutral =96 the =93service name=94 can be Bonjour, DLNA/UPnP = or any other name space.  Identifiers may also be explicitly obscured = by including a shared key with the service name in the hashing process.

Hash identifiers could also map into a bloom filter b= ased representation if you have relatively large numbers of services.
=

Paul



=

<= font color=3D"#000000" face=3D"Calibri" size=3D"3"> At the beginning SSL was designed to secure HTTP, and used the 443 port, HTTP was implicitly the application. Many internet applications used a TCP/UDP port as application = identifier with SSL/TLS

 With ALPN the client used an extension that contains several applications name (such as "ht= tp/1.1", "spdy/1"), and the server selects one of them. So ALPN realizes t= wo things, it identifies application, and the server selects of them. ALPN in not mandatory anyway.

 For future use of TLS1.3 I believe that application identification and selection is important= .

Why not a list of application identifiers in the server finished message=85

=
And the selected application identifier in the client finished message=85

Regards=
Pascal
=


2014-07-18 5:32 GMT+02:00 Watson Ladd <watsonbladd@gmail.= com>:
What do you mean by &= quot;application identifier"? Is http enough, or
should it be the application on top of http?

What do you need it for? Why does it need to be manadatory: why not
require clients to use ALPN?

If you want to link the client cert to application (what does that
mean?) why can't the ChannelID draft serve your purposes?

On Thu, Jul 17, 2014 at 3:09 PM, Pascal Urien <pascal.urien@gmail.com> wrote:
> Hi All
>
> Finished messages are encrypted. That are produced first by server and=
> second by client.
>
> The today semantic (TLS1.3) of these messages is server finished and c= lient
> finished (a cryptographic proof of the knowledge of secrets)
>
> They could be used also to transport protected application identifiers= for
> both server and client ?!
>
> Regards
>
> Pascal
>
>
> 2014-07-17 18:05 GMT+02:00 Paul Lambert <paul@marvell.com>:
>
>>
>> It may or may not map well into TLS, but in other forums, we=92re = using a 6
>> octet identifier to describe services (aka applications).
>> It=92s formed as a truncated hash of a =93service name=94
>>
>>        serviceId =3D SHA256( serviceName )[0:6= ]
>>
>> It can also be obscured by concatenating the Service Name with a k= ey
>> before creating the identifier.
>>
>> Paul
>>
>>
>> Hi Pascal
>> You may have a look at the following document:
>> http://tools.ietf.org/html/draft-badra-tls-multiplex= ing-01
>> Or
>> http://tools.ietf.org/html/draft-badra-hajjeh-mtls-06=
>>
>> Best regards
>> Badra
>>
>>
>> On Wed, Jul 16, 2014 at 12:32 PM, Pascal Urien <pascal.urien@gmail.com>
>> wrote:
>>>
>>> Hi All
>>>
>>> It seems there is no identifier for the application SDU transp= orted by
>>> TLS 1.3 (which is obviously a transport protocol)
>>>
>>> With the legacy TLS, the application is identified by a TCP or= UDP port.
>>> Some TLS extensions have been proposed to solve this issue. >>>
>>> What about adding a mandatory application identifier in the cl= ient hello
>>> message?.
>>>
>>> It could be a two bytes integer (i.e. TCP or UDP port) or some= thing else
>>> such as an application name
>>>
>>> A mandatory application identifier in the client hello message= avoids
>>> tentative connections to non-available applications. It also c= ould establish
>>> a logical link between client certificate and applications
>>>
>>> Regards
>>>
>>> Pascal Urien
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>



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



--_000_CFEED3C846346paulmarvellcom_-- From nobody Fri Jul 18 15:54:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B3A1A02A3 for ; Fri, 18 Jul 2014 15:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.901 X-Spam-Level: X-Spam-Status: No, score=-13.901 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, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHH0_AR1R37f for ; Fri, 18 Jul 2014 15:54:26 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 747661A02A2 for ; Fri, 18 Jul 2014 15:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5639; q=dns/txt; s=iport; t=1405724066; x=1406933666; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=O8JkH3rwPOqfSsLsLx+MyQco6A9hL9hVERYoxwKklIQ=; b=QYKG4saZMusGuhg0KekiLHcHPWC+1LGbFXUIluiZxPY+MiR42LknhtyU X7v3yb5yEnOdGWjJ9b5JFNlkAyZB+eku9wGlZaStw7IsM8xpiDqHNnBkm Gj8nueDxPQhGREi11R+Oe2L3b84ZV1/SkRlHnEuoO2JKKH+AeNHMxUz61 g=; X-IronPort-AV: E=Sophos;i="5.01,688,1400025600"; d="scan'208,217";a="338078116" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-9.cisco.com with ESMTP; 18 Jul 2014 22:54:25 +0000 Received: from [10.21.77.118] ([10.21.77.118]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6IMsNN2015953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 Jul 2014 22:54:25 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_568958A5-C2A0-4FAB-89B0-FA0817021E35" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Dan Wing In-Reply-To: Date: Fri, 18 Jul 2014 15:51:18 -0700 Message-Id: References: <338B3B88-CCE5-4D79-97DC-1EC7D84891AA@cisco.com> To: Eric Rescorla X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dTLPqejKsaTzFxAqIK3F4gJa6-E Cc: "" Subject: Re: [TLS] Resolution on gmt_time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2014 22:54:28 -0000 --Apple-Mail=_568958A5-C2A0-4FAB-89B0-FA0817021E35 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It reads for TLS 1.3: Server implementations MAY opt to include the time in their Server.random values in order to accomodate clients which use =20 that field for time synchronization. How does the TLS server know if the client uses the field for = synchronization? This feels like an excuse for a lazy implementation to = leave it in, and the text does not explain the risk. Yes, there is a = risk -- peer-to-peer TLS or peer-to-peer DTLS (such as for WebRTC and = DTLS-SRTP). I would rather kill this entirely, and if someone needs = synchronization they can run TLS 1.0-1.2, or use some other protocol = like NTP. -d On Jul 16, 2014, at 8:09 AM, Eric Rescorla wrote: > See https://github.com/tlswg/tls13-spec/pull/65 >=20 > Expected merge date: Friday Jul 18 >=20 >=20 > On Sun, Jun 22, 2014 at 10:17 PM, Joseph Salowey (jsalowey) = wrote: > Thanks all. Based on the list discussion, the chairs believe there > is rough consensus on the following points: >=20 > For TLS 1.3: > - Remove GMT time from the ClientHello entirely. > - Remove GMT time from the ServerHello at the MUST or SHOULD level. >=20 > For TLS 1.2: > - Remove GMT time from the ClientHello entirely. > - Remove GMT time from the ServerHello at the SHOULD level. >=20 > Next steps for TLS 1.3 are as follows: > The editor is directed to remove GMT time from both random values > and open an issue as to whether or not the ServerHello can have > a time value in it. >=20 > Next steps for TLS 1.2 are as follows: > Absent any objections, the chairs intend to adopt draft-matthewson > as a WG draft. Anyone who objects to this, please say something by > Friday June 27. >=20 > Joe > (For the chairs) >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_568958A5-C2A0-4FAB-89B0-FA0817021E35 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii It = reads for TLS 1.3:
  Server implementations MAY opt to include = the time in their
  Server.random values in order to accomodate = clients which use  
  that field for time = synchronization.

How does the TLS server know = if the client uses the field for synchronization?  This feels like = an excuse for a lazy implementation to leave it in, and the text does = not explain the risk. Yes, there is a risk -- peer-to-peer TLS or = peer-to-peer DTLS (such as for WebRTC and DTLS-SRTP).  I would = rather kill this entirely, and if someone needs synchronization they can = run TLS 1.0-1.2, or use some other protocol like = NTP.

-d


On= Jul 16, 2014, at 8:09 AM, Eric Rescorla <ekr@rtfm.com> wrote:

See https://github.com/tl= swg/tls13-spec/pull/65

Expected merge date: = Friday Jul 18


On Sun, Jun 22, 2014 at 10:17 PM, Joseph Salowey (jsalowey) <jsalowey@cisco.com> = wrote:
Thanks all. Based on the list discussion, the chairs believe there
is rough consensus on the following points:

For TLS 1.3:
- Remove GMT time from the ClientHello entirely.
- Remove GMT time from the ServerHello at the MUST or SHOULD level.

For TLS 1.2:
- Remove GMT time from the ClientHello entirely.
- Remove GMT time from the ServerHello at the SHOULD level.

Next steps for TLS 1.3 are as follows:
The editor is directed to remove GMT time from both random values
and open an issue as to whether or not the ServerHello can have
a time value in it.

Next steps for TLS 1.2 are as follows:
Absent any objections, the chairs intend to adopt draft-matthewson
as a WG draft. Anyone who objects to this, please say something by
Friday June 27.

Joe
(For the chairs)

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

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

= --Apple-Mail=_568958A5-C2A0-4FAB-89B0-FA0817021E35-- From nobody Fri Jul 18 15:57:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8611A02A2 for ; Fri, 18 Jul 2014 15:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQ8rfPOhjalg for ; Fri, 18 Jul 2014 15:57:12 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA8A1A02A3 for ; Fri, 18 Jul 2014 15:57:11 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id p10so5215547wes.2 for ; Fri, 18 Jul 2014 15:57:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZhkMNzslIhAOWjp0+5+PPD9zpcOKM6eaN1d+Nzl4IsM=; b=iOhZAUDYk265Tx9SR5o+3Rtlr04vE9MJB8Dc6oQzXNlgQ1UHOsQH6fFSHb9z1gYiHr 1JCmLkSnuoU7629fcoDt146lzbuv31IvjHnci/aXu421OS1gWu4oxd9PPY3fRFh+wvum gls62GwwqGt9GACJtTnuxEEo7Jaqx2Ood7Mx6X58G2saA992OF8GVPoNsPROQsqeKr3X 8SU8EzcAiC6sT6wOrjj846bFQs0y8/lMMlryRCvbbztH42Bz9dRnA12SbbzI7o7LXMyh +SAsJDh18Jk7bPcRjFT7TiHqwfF7MeI7heLMtfBYGlAiz6i0KeKOJhG6cHbMLuauBo+c +ajw== X-Gm-Message-State: ALoCoQkvUHXPPCS0DrN+BM0bTNmTxhyyhAwTBe16cOmMWcYLwhqKT3fj3nepc3zQ6ZpiKAbYN4OB X-Received: by 10.180.78.100 with SMTP id a4mr22114528wix.36.1405724230366; Fri, 18 Jul 2014 15:57:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Fri, 18 Jul 2014 15:56:30 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:69e8:5ca6:d68c:fe87] In-Reply-To: References: <338B3B88-CCE5-4D79-97DC-1EC7D84891AA@cisco.com> From: Eric Rescorla Date: Fri, 18 Jul 2014 15:56:30 -0700 Message-ID: To: Dan Wing Content-Type: multipart/alternative; boundary=f46d043890eb67781a04fe7fad38 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rltuMZ161p1cq89kw4T7fw5gvxc Cc: "" Subject: Re: [TLS] Resolution on gmt_time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2014 22:57:13 -0000 --f46d043890eb67781a04fe7fad38 Content-Type: text/plain; charset=UTF-8 I left this as an open issue per chair direction: https://github.com/tlswg/tls13-spec/issues/64 I'll take this as an argument on one side of the issue. Let's discuss in YYZ. -Ekr On Fri, Jul 18, 2014 at 3:51 PM, Dan Wing wrote: > It reads for TLS 1.3: > Server implementations MAY opt to include the time in their > Server.random values in order to accomodate clients which use > that field for time synchronization. > > How does the TLS server know if the client uses the field for > synchronization? This feels like an excuse for a lazy implementation to > leave it in, and the text does not explain the risk. Yes, there is a risk > -- peer-to-peer TLS or peer-to-peer DTLS (such as for WebRTC and > DTLS-SRTP). I would rather kill this entirely, and if someone needs > synchronization they can run TLS 1.0-1.2, or use some other protocol like > NTP. > > -d > > > On Jul 16, 2014, at 8:09 AM, Eric Rescorla wrote: > > See https://github.com/tlswg/tls13-spec/pull/65 > > Expected merge date: Friday Jul 18 > > > On Sun, Jun 22, 2014 at 10:17 PM, Joseph Salowey (jsalowey) < > jsalowey@cisco.com> wrote: > >> Thanks all. Based on the list discussion, the chairs believe there >> is rough consensus on the following points: >> >> For TLS 1.3: >> - Remove GMT time from the ClientHello entirely. >> - Remove GMT time from the ServerHello at the MUST or SHOULD level. >> >> For TLS 1.2: >> - Remove GMT time from the ClientHello entirely. >> - Remove GMT time from the ServerHello at the SHOULD level. >> >> Next steps for TLS 1.3 are as follows: >> The editor is directed to remove GMT time from both random values >> and open an issue as to whether or not the ServerHello can have >> a time value in it. >> >> Next steps for TLS 1.2 are as follows: >> Absent any objections, the chairs intend to adopt draft-matthewson >> as a WG draft. Anyone who objects to this, please say something by >> Friday June 27. >> >> Joe >> (For the chairs) >> >> _______________________________________________ >> 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 > > > --f46d043890eb67781a04fe7fad38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I left this as an open issue per chair direction:

=

I'll= take this as an argument on one side of the issue. Let's discuss
in YYZ.

-Ekr





On Fri, Jul 18, 2014 at 3:51 PM, Dan Wing <dwing@cisco.com<= /a>> wrote:
It reads= for TLS 1.3:
=C2=A0 Server implementations MAY opt to include the time= in their
=C2=A0 Server.random values in order to accomodate clients which use =C2=A0=
=C2=A0 that field for time synchronization.

=
How does the TLS server know if the client uses the field for synchron= ization? =C2=A0This feels like an excuse for a lazy implementation to leave= it in, and the text does not explain the risk. Yes, there is a risk -- pee= r-to-peer TLS or peer-to-peer DTLS (such as for WebRTC and DTLS-SRTP). =C2= =A0I would rather kill this entirely, and if someone needs synchronization = they can run TLS 1.0-1.2, or use some other protocol like NTP.

-d
=



See=C2=A0https://github.com/t= lswg/tls13-spec/pull/65

Expected merge date: Friday = Jul 18


On Sun, Jun 22, 2014 at 10:17 PM, Joseph Salowey (jsalowey) <jsalowey@cis= co.com> wrote:
Thanks all. Based on the list discussion, the chairs believe there
is rough consensus on the following points:

For TLS 1.3:
- Remove GMT time from the ClientHello entirely.
- Remove GMT time from the ServerHello at the MUST or SHOULD level.

For TLS 1.2:
- Remove GMT time from the ClientHello entirely.
- Remove GMT time from the ServerHello at the SHOULD level.

Next steps for TLS 1.3 are as follows:
The editor is directed to remove GMT time from both random values
and open an issue as to whether or not the ServerHello can have
a time value in it.

Next steps for TLS 1.2 are as follows:
Absent any objections, the chairs intend to adopt draft-matthewson
as a WG draft. Anyone who objects to this, please say something by
Friday June 27.

Joe
(For the chairs)

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

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


--f46d043890eb67781a04fe7fad38-- From nobody Sat Jul 19 06:37:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE94E1B28B5; Tue, 15 Jul 2014 06:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, T_HK_NAME_DR=0.01, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8ABcGBofArY; Tue, 15 Jul 2014 06:55:36 -0700 (PDT) Received: from bohuslav.ifi.uzh.ch (bohuslav.ifi.uzh.ch [130.60.155.10]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2B41B2881; Tue, 15 Jul 2014 06:55:35 -0700 (PDT) Received: from authenticated sender schmitt by bohuslav.ifi.uzh.ch (postfix) with ESMTPSA id SA; <743FC7FC6E> Message-ID: <53C532D6.4050301@ifi.uzh.ch> Date: Tue, 15 Jul 2014 15:55:34 +0200 From: "Dr. Corinna Schmitt" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sean Turner , ietf-secretariat@ietf.org, "TLS@ietf.org (tls@ietf.org)" References: <8B2FFA4C-9BBF-4E7E-B0E4-032139FF0EB5@ieca.com> <53C530B7.8040605@ifi.uzh.ch> In-Reply-To: <53C530B7.8040605@ifi.uzh.ch> Content-Type: multipart/alternative; boundary="------------040508090106080709040304" X-Virus-Scanned: clamav-milter 0.97.8 at bohuslav X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AAJiU-fJz3jhckfCdkiNAZUNv28 X-Mailman-Approved-At: Sat, 19 Jul 2014 06:37:19 -0700 Subject: Re: [TLS] interim meeting anoucement - Location? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2014 13:55:37 -0000 This is a multi-part message in MIME format. --------------040508090106080709040304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear Rene, thanks to point me to the correct mail. It was became lost in SPAM. Regards, Corinna Am 15.07.14 15:46, schrieb Dr. Corinna Schmitt: > Dear Sean, > > Sunday is arriving soon. So where do we meet? > I cannot find detailed information. I just found the remote > participant information. > > Regards, > Corinna > > Am 23.06.14 04:27, schrieb Sean Turner: >> WG Members, >> >> Per the doodle results, the TLS WG will hold an interim >> meeting prior to the IETF from 10am-4pm on Sunday >> July 20. >> >> The most likely location will be the Mozilla offices in Toronto. >> >> The chairs will post details with an agenda and a final location >> closer to the meeting. >> >> spt for the chairs >> [For the chairs] >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > -- -- --------------040508090106080709040304 Content-Type: multipart/related; boundary="------------020301080900060202040300" --------------020301080900060202040300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear Rene,

thanks to point me to the correct mail.
It was became lost in SPAM.

Regards, Corinna

Am 15.07.14 15:46, schrieb Dr. Corinna Schmitt:
Dear Sean,

Sunday is arriving soon. So where do we meet?
I cannot find detailed information. I just found the remote participant information.

Regards,
Corinna

Am 23.06.14 04:27, schrieb Sean Turner:
WG Members,

Per the doodle results, the TLS WG will hold an interim
meeting prior to the IETF from 10am-4pm on Sunday
July 20.

The most likely location will be the Mozilla offices in Toronto.

The chairs will post details with an agenda and a final location
closer to the meeting.

spt for the chairs
[For the chairs]

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


--


--
--------------020301080900060202040300 Content-Type: image/png Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAASgAAACgCAIAAAAw8WZPAAAAAXNSR0IArs4c6QAAAARnQU1B AACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAA buNJREFUeF7t3Qe8FtXRP3CT901i2htTTVeTGE035Z+YZkxijFFjQcVKVXrvvffee6/Se+9I R0CahSqCgtJBQKTl/9099y4P9yIiEOXq83zwus8+Z8+ePTtzZs7Mb2Y+9p///OeKd/uMGTNm 5cqVWq1atWr//v3v1jz9e3oGPnIzcOWVV/7ud7/z2DfeeON9993n67tMAcZ7p8/s2bMfeeSR q666Skd14s/o0aOdTH/SM5CegSwzMHny5MAjWAbXYRnMcg7muuKsvz333HOuvPXWW59++ul9 +/ad4/r0T+kZSM9A9hnAdTjopptuwp9nnZ+zMB5mu/nmm8/Nr+m5Ts9AegbedQYIMNKLGMze MivjVa1alax866233rXTdIP0DKRn4HxmIOifWXjqDMbDdRqdOnXqZPqTnoH0DFyKGcBNmLNP nz40z1QuPc14NEx86bc0412KCU/3kZ6BaAYC4/k0adKEYEt4L4PxKKP2dUEaphkvTTLpGbhU M5AwHs4i2Ii3wHsZjJdq/bxgxsvk7XPovWkl9lK90HQ/OWMGUhlvx44d1157bRBvEeNxQdxx xx0Ju7wnxjtx4sTJEyeSa/fs2b1mzZrp06YPHzp02JAh/jmYOmUyifrGG28kzU6eyBmzlh5l egYucgZSGQ/9ly1btk2bNhmMh+vw3oUxXrhq586dkyZNatyoYY1q1apXq1anVq0G9eo1rFu3 ob/16tWrU6d61arVq1WvX6/+6FGjt219NVx1kY+Uvjw9A5f/DGRhvJdffpnQixiP4INNSbV1 no/EI+hsBl2/ffuOnj17li9XrmrlKhivaZMmXTt3fnrwoKlTpsyeNXvO7NnTp00bNnRoj27d WjRv3rhhw+pVq5cuWbpTx46bN28K7KerSGymP+kZ+DDOQBbGQ/CMKYsWLboiMWa+J4kXGGb0 qFHlypatVrVqy+YtunbpsnDBgtkzZo4bOzb7Jm/evGecX75sWa+ePTWuXatW2dKl+/fre/jw YY2PH08z3oeR6NLPlGLVTJgiIMuuCP9LZZVzSzwsovGunTsbN2pUsUKF5k2bDujf74Xnn8c8 zg8cMLBCuXKv79hhzhM5dvTo2y2bN2/YoMHxY8e12bhhw/BhQ1s0bVa1cuWaNWps2rgxrXam SfTDOgPZJV5Ak12RP39+3r3zZzwtX968mW5Zr27dNq3bLFiwYPOmTXv37Hb+hRdeaFCvfptW rVu1aJnwkoO5s+c4o/3gQQN9XfbssmeXLiX9Onbo0KhRw9IlSzr+b8i9YPi55IbU49aY4yfi 5enSKclRT8czPD5pj86HiAuzMx49k7Z5RRbLCgY4h8Tz6ytbtpQpXTrs5ba8vMWZwQMHkn57 du/R47/vvPPfd92FLZ0/cuTI4UOHHIwaOfLef//7zjvuaNWyha99+vRt3qz59te2b33llT69 e7do1qxYkaKB984x4cnSENqkPs/5X3VJXijGyzKYLF8v6C6RvvD228defOGFtWvWHHrzzfPZ aV/QjdIXva8zkJ3xgn3lCiDOLADqs77y2JryH5EKNnXNmzXr3Knj/v37aJj169WbMX0GY+bK 5cunTJ78VMGCRQsXLl60qM3bcyuemzljhqt6dutWMH/+J/PntxvkynDJvr372rZp88zcuW+8 /kbMe81Lliix5eWXw9Yxu63l2LHjSxYvNs6DBw8ans+xt48tXrSI8ebNN98860Rqc/To0WZN m+Z54vF169ZdQjrW1fLlyx95ODeJ/fbbb7u7UZHhe/fuveC7RPrC88/f8+9/f+H//u/zn//c nDlz0ur3+8of/7WbXSzjRULm5Ek806RxEzZJTNK5c+eXXnypdMlSFM6li5doMGHcuP59+w3q 379mjeq7du3EVBs2rHfjwQMGdOvSuX/v3jWrVX/z4MG9+/Y9u2RJm9athw8btmDe/Igze/Zs 3bKVHeORw4dTN4cZwu3kyTffPPSrm276whe+sHbN2iBe9u8/8LOf/vSLX/wipgpSOhB9+DU8 LSfHN77+dfGIvXr0SG2TCMxwSTI1CdtEfcVdht6yCFhnmjZpqtsfXn/9gQMHjr711r3/vucr X/7y2rXR2MJVZ3QV95X6ZrPcMQy+YIEC+rzt73+rVq3qhg0bLoyHQ1cXdu1/jfbesePsmsI7 jTx5rZdwkBc8S8mFyajO0VXyrpOHfW8Sz2Vjx4whslq3arV169Y1q1a3atmyc8eOc2bNInwi Ujt5EkNWrVK1ZvXq+fPmxZlUphnTp1PMGjdswOJSrXLlgvny7969J2KJN97ApdOnTp01c2bb 1m22b9/eoV077r4e3bpHhH6md+HUyVOHDh36xc9//vnPfU6fmYy3/yc//jH58NJLEeNl/3jg 48feHjt6NA5n7EkaBHF61kvCSfvC1F+1T7ZeCR/a5TZv3oKEj9ofP/HTn/7ks5/97OZYYqcS U1ATMroNojzlTJYx/PmPf/z85z+/efPm6PwF4dSzdHjBhBUT9wljiN7FRXzi53jHLXagyH37 9x858lbGHTMfIPWeYcYgLvbu3Xfs2LGLGE7GpfFDnX6lnvQ99RnGGAZ//Ngxo0rOvJPmleW9 nC/jRZR36hQzZrkyZVq1aLFkyeIN69e3b9vu9dffGDVixBtv7Iyf5MT+ffuKFylSqkSJ8mXL 3H7bbfx4M6ZNw0779u3Ndd99LCj8B84vmB+JuPBZtHDRYw8/XKRQ4SOHDlO0WjVv7vL16zdk ed/uTnH91S9vuuqqLwSp4rP/wIGf/exnX/rSlzZu2Lh39+4qVau0bNmCCM11/3333ntP/379 XMU52aN791q1a7GjEstFixV1d+dPHD9OSyxUqBDLELZp367dnf/61x3//CdPo02pBtOmTS1W tOjAAf1LlSzlV2cGDhjwQK5ct/7lFiYi82u0NarXGPL009aXEiVKkKsUxNy5czdu0mTcuHGF Cxfu0rmLnr2fiRMnPvXUU8xXpihsDnfseB2Q4K4777rvnnt5Vg4dPvzKK6+UKF7i29/+1he+ 8H+PPfaYTa+Rv1e20X79uvXlypUrUqRI2TJlFi9afDFsE+xSR986+p6IMkvjt98+ijTfiRxx Ea/Sr3716+B/Mn6zWqVKlddefTXLuvP6668/kvvhv9zyl02bIt/vxQzJteSEV/PSSy8VLVLE HSN6OG/W03j1qlVVqlTdtXMX/rnrzjvZJ+2ngEN2vrHzrK/swiVeWHL43+rWrt2zRw/W/0kT Jgzo15/EM61+Oha74Xbv2tm+bZsmjRsVL1KU0Js0aSK6rFK58p7du/kMKlUoX71K5SqVKs5N 2b34SbfPPbdy8qRJWzZvfnrQ4LatW9uVvSfG44hH/V/60hc/9alPfe5zn/vaV79KYSMJly5Z ao/32//3/3y1GwQMd/DUk0/pnF3nq1/56qc++ckVK1bQb50nTn/60586sINFA40bN3aMl/wl 5Ht07/Hxj30Md/36l78qXqyYHkYMH+Gnf99993MrVlxzzTWf/cxn3Vr7W//ylzGjR/vp61// OsuTSb/9H7f72r170HVPbtu69ZY//9mZL171RQNwULRoUUP97ne+S2aSeKT67f/4x6HDkVHq PVGY9rNmzvrSF7/YpHHjMqVKXfPda6ZNm5Zlrc0i6rN8zUIiDerXDyr6WT/n1hpcsn79+rxP PHFg//7kQbL0w/b2veuus0JFciymMWTg8VetXJml5cL5C0y+peTc488+zuxEbzdeIF++l154 ccf2HTVq1CRCAg4k++esklCzMaNGf/5zn31126vWi+98+9tbt24bOWK4YdsdnPWVXTjjedp9 e/dWrVyJL47DAJXXrlmT6HtlyytBbQsikfb49KBBxYoUQXwMJ+PHje3SqXPRwkU2b9zUskWL B+6/P+/jjzdt1IhBJfVNWOybN23WsWOHl1560Z6Q2aZyxYpbtkTG0sTEgmAPHz70q1/+8qpo j5epah7YHyQe3WzrK1u9wv/5n//B2mYk1/33h30dLedvf/3rlZ/6FPfFiuXLceP1P/gByCjx 9bGPfezRRx5hSkXuv/rVr55fu3b5s8u+/73vfeMb39i9a1e7tm01+OY3vwlzQw0mD3XYrGmz iHliNZXW/Yn//d+HHngAb6Own//sZ/afkDomgXB2U+179+q9Yd26r3z5K9ddey0pF15tgwYN /PTYo4/ywcycMfNb3/qmUS1auNBk/u63/w83mh/KxQVAeXTuWur3ju2vOc6fL999993rYNu2 baR0o0aNyA2moA4dOljsKlWsNH78eL+aPQxWoWLFCRMmWEb7+/Tt1759+759+qD13/z611On Th0zekzXLl3r16/ft29feweT7EldK+1VyxYtrarI9403XgdB7Na1K5EFR/HG66+b3s9+5jPl ypazGw+i4PChw927dStXrvzokSMJ/0YNG331K1955OFHwoZWhzOmT0PKq1etHjpsWLeu3WrX qt2nV6+XN7/M4/W1r32NimFuF8xfULlSJauz9/j2sbcZGgy1d+/e8+fPN+zWrVozmLOu165d u3//fnQMQrJevegBJ0+afOjNQ7ZCn/70p5944gnaVvfu3V/dts19bRkqVKjYuWMncqxbNMJy NlCJjhxeXLJDmThhwnXXXkOhe+CBB1CLm9Kzvvud79h9XGLGi5aiyZOrVanct3dvE2pZmj9v Xs/uPRgVkiXZxBFfdWvXKl2iBN4rWCA/bHTtGjWeeOzxhfPnFy1cqFTxElTNxx99ZN68eanj 8wLwkvfXrk1b74+QbNywkYmM22RoAIHxfnnTTV+86iq6QZiIAwcO/uynP2Nc2bRxE7fEtddc 861vfSvMY4Xy5RE3kJq3/feY8RZRKU+cuOOfd2AnXPf44499/OMfR08jRowgJ6+++ms/+P73 se6nr7ySyFm/bl37du31QNsM96pZvYavhEm+vHkxcMJ4D+bK5cEt2L/+1a8w3sYYCeDTqVMn 7b1dmqQDil+w1Wh5+23/+N///d+pk6eElsyYH7viiqcHD3Z8y5//5BZWorO+v3eVfq7CeD/+ 0Y3r173k2GMa1fbXXnvwgQdKly6NDRhvmIK+fvXX/3LLn8uXL2/GVj73HDpmMKtUsSLSIf// 9te/0R2KFyuKmH584423/f3v3pdrv//97wPhMiA98fjjjzz88E0///mePXtoB48/9pjO/3n7 7XT4z332s3nz5OFM+v3NN1tWSpUs8fWvX61zQsbg0bHjm37xi2rVql1//fVDhwxF93g7f778 mD+T8aYbxuqVq+jhN97ww6pVqnztq18Z0H+A4V199dWYbf78BT/+0Y95s/7+178ZCRv7d77z bbxqOaMrff6zn9X5jTfeYCbDJYTkvGeeiVaW+Hk5kO1Hrv7a14x85IgRX/7SlxYvXITrvPpy 5cv36dW7Vo2aP/3xT9q2aQvnGI04/jAH7tu7J1CjiaXu6Wr2rJkF8hf49je/2aNHjxGB8V6+ 1IxnUlq2bNmsSZNpU6fOnjWrQL78hZ58avOm6DanF+Z4E2jBo4K21rhp0+FDhloL8z6RZ+6c udAtlhOYsjq1a82de4ahXCe4ZdCAAVga3VAz3Kh+3bpvHz29u4j2eIcOeWfUuUQPsdx+77rv mcRXXtmC8a757ncxD1+iDpECcqcVZzDelVdivIgfOnZ03j7zuuuuu/GHN9iU2gqSk7RBK6tF vXevXkOGDLEussdoSVC4yt2ZdpiUCEYnTTrl3rJH4sWM58W8GUnjq64KyoYP6f31q6/+7ne/ S9H9zGc+E7TrsOdElJ/8xCdmTJseWt59190f//jHRg4fbtfxpz/+0TpCfl4s470UMR440c2/ +x3z1be+8Y3q1asRgN/51rc2rN/wk5/8JISE/b9f/waxejSbAjveb3/725jtnnvuKVuGsh19 /n3nXcC3DpB4sVjBxsl2sLSeG274oZf1oxtvLFKoEBFHsg0aOJA2sW7dehTyg+99nwCc/8w8 rLt7d4SsoBQdPHDA5W7kq/UrX958NpA//clPpkyaFJ7XX+IUBa9ZvcpiUalSJWd+8Yufe4/0 +R//6Edert3NH3//B+fnzpn9/eu+x8LHrNWhfdRnty5db/7dzQ6KFStaqlQpBz/76U+s4wcP HJw0cSK59K1vftMBU/uNN9yw6rmVa9aspoksXby4QH6mwLzhkd3rB9ddZ80KLOeVEQx5Hn+c HiHsJrTBeFh9x47t48aOY2nXDDE4c4kZz51wfO1aNQkBhIXErZED+/c/cvjIGVvJmPEG9OvH X3fLH/8oIqFVq1b0GS9m5PARsNF33XFH7vvvb1Cv7jPPnFY1g5pK139m9pxXX3112bPP2gKx x9SqWdNXUiJZ5smKe/59D7q3CmK5I2+9xQNBdPzpD384fPgI1RTjURR37dplwKVLl4kYr3v3 LIxHInmvn/zkJzEbQ5GWtsX/8z8f/8Pv/0DHCNO6d89ef1u1aqkHARaBJmgsDvCbd+a8NXLK pMmB8fhYvFpbxM9+9jMzZ8586+hRQ/VQeZ54gnS1M7zlT382gYm1wDvWAxsS4TNr1syvfvWr FNpNmzYee/voJWG8SNWMTbhUuHz58nF+WpuEokTaY9++r732Ggq2uGjw29/8Bh0XLlS40FOF xo8bT6ZhvHvvucci69djb79929/+1qhBzHiPPVayZElbod/+9rd0H4IRw8yZNfuGH/7Q47Rr 165bt+5Urx9eHzEeje5HN9zw+o7tkyZOuuGH16OKTMY7aHnq1DFikvzYLm9eKr3BkDxZGG/t mtUYj2LpjtScXj17zJ8/z8xDbjA7sf1qz8/pdbNzSOM1NrbNWDdN4FtH3ipSuIi1wBnXDh40 GF8xoowbN55YmzB+PDObBZqoF7x23XXXLlm0mJvXJ7x9HwqdJZ5QDZYwBGrPXLBgweBAThiP Yd80/uJnP7eg6Pa/wnicdZUqVOzfty/RRJR5+LlxxrIzlJ9Tp6KtUes2jz/yCFNPoSefZLKz DbUXomHmfeLx+++55+EHHyhVongWVRNOSle8eeXLlitbqvTLmzaNGDacO962J7lFsO7QDEkP VGtl/fGPf+yAAAxKmhWBpkcR4rjz9amnCvm1U4cOGA95OZ4XbywjGnr8CV/pmfNj/yEevuvO aP/2zW9886+33oqSbM8MqWmTyLjCrBKuMvV/+P3v//ynPzn585/93F2gwx3f8c/bI9Pf0bf/ cdttvtqxMI1SuV1Cif30p690I8SdPIiDCRMm2ohrHGm2n/50tHVsEhmT7F5wL15lbcs6t++q ZcYNXEXaXPWF/6tRowat8qc/+TGf/ltHjtx9513snLiOZ4V8u+GGG/51xx3aWIOsoZ733nvv bdSwodEOHjTI17qxnCeBWYft8ZYsWfLQgw8SmJw6P/zh9XCGzlAR1730Em7MlStXv379vYXF ixfT3J5f+/zY0WO+8bWrX3t1m/0IzblunXp8sJH0OHnKevrLm36h/x98/3vDhgy1xuknvMEw /kzjynN01zKly7iEUIpcVnNm2w6w6onq5DtlD/vHP/7x8MMP79u3n6pJrLmWfmg5sI1kFi5e vDgWcS0VhsXBIBs2aGjHMWrkKHa1a7/73WJFi8nR/OUvfXHJokVI9Jvf+EaFCuXJTLLOpvHv f/ubBciON4iWQAPJMaqmVFvr+/Xrd813vst6BJjlzMZNZ4ccX6BxxS3ZAJh9Md7G9etNk72s dTSb5fTU3j17atWoQdvs368/QUdjHD923LgxY7t37fbEo4/16tnLDpjUpnNnIayYc9bPmTnr 1a1bEcrkiROrValii5jaLIwe7z36yKM0qN/f/DtK7MQJE6MZOXmS6YLW7n1gJC3tCiypqJCk kujCcsXOHhlFTv0H0gUNiRikT4Y+Ga8xmLn+/e9+h23sNo8fP0am5c2Td9SokWHSeRSQoAW1 RPHiwYPPKmMppQVYF/XDfkhJ++Mf/mBxpXlqsPWVLV48gYYWkwcJkpPZ84FcD+jt3nvu7dun L/Jykt7VsH59BEFeZZvb8+O8k6dsd2vWqFmmTBnvi0IY6AWJoHVCb8yoUXjg5z//ueelyJFv brRi+YqKFSsxhjVv3gwcp1evXjNmzAz384y2RowrWo6MzSFt2rTlzrELbdq0KdXLbNNrSpcq jb6Z3CxPFDANoAvsAL3KLp0716hZ004s2SzR9umBQ4cMiZTPgwebNWuGl8Lz+mvRsR/zRiwT 4ydMwPyWLZYSYkqfNiMeiOOX8QPgnvT2pnhTV65cpQOLSPv2Hdgdhg0bzt5o9SS6Vz5na7Ky YsWK7dq2a9q0mS+nTp4YNmxo5cqV586d26RJ02ARwUulSpVs2aI5FjJ7xhC2nYnCmbxBJ9nh 2Jm4o5cvX4ZaQD4YKfiHdu7cddYXd+GMN2rkCM9pO2TG+/XpQzcI+JIsH9qzrVqgVK+qZ4/u S5csYSgfO2Yswg3nWVCQfhbGMzKq4+yZszp16EiVJbgtwEwj2ZuFTuyUCJlwHCGLjx9PlqXw Nfzk48WEg6AuZsdYnnFh7BqJrzrt9c6Yej6tlMspk4Fb4saZ3Ub++miNDOexPVMNs0TcQ4aV KBpqpgNdJ8k4Q4vw9UK57mTq06VOTnIXB5Re3kJrfGaD03OV2syDhDiSM06mTGY0pbGqknxQ aXwy4yniB8qYRi/Fw3oXqSSYiiXIJKSM9kmz5InCGV1mecbk/SYHJzIHGRxd2T/ZZyk1f0Jq e2/8bAve6YfKmMNMensnxPyFM97oUSObNGw4aOCANatXYyFCL9ipsjLe668PHjjA4rRg3ryh Q4dWLF/e1q5e3ToWcraKFcuWPb92DRGRnfEisjtxgnmDJ501zBJr09+hfcSrZ9wiepWR3yKF QDOwIGG9DCQb+zair5nH0fnIG5wZphS3cybTaXoiK946/JTKAKk3DbfMaKCnTIdK8s7sdkDG f/Ob3/zPxz8ePGkp98q4NpXlkmdMHuFs7/t8zp3hBs4YZ+QGP33ezpxxclkmHj1pk9F7ZsvM Z8zwFWUAieKOwin/S+YhzHP0Y+bf1DPJcWr7cDJz6s71aPFbzHiEjDd4+sKMyYxXtvCM8WsO RynPknqD0/fNPJs8Vvxc5+tKT52qcNMwK9kf5mIYb0STBg1sABg/+vbuQ1PasX171oX51Enb 6B7du61du2bJ4iV0D1av4sWK534oN92M089+w1aYNynVgR5GqSsrIhvM1MmT165ebXfets3Z GO98aO+cbc4hTM4qbcKUZZ+45GTWu8XtOSHs3Ig7bqjwdBc98EvWQdhRx+p5+vM+zcDFMN4o sqtf374vb9o8fOgwaiToY3Z6YlRo3KD++LFjJk2YaBNFarEWCH+gNDLiUbvpkFx8z8zNsseL hJgOqZqCD2wbJowf53bAIqkSL2gyWT6xKHv3JSqs08m1Z7kkFqRZnyhDrGUsDUGlJCoTXora x4tw6gt0jl4wfuzYZUuXXjzW8ZKTRliUz2fSLvmtP7IdXjjjzZo1i0fO7o6Jn1zCVCReNhTv qZ2vvzH06aeZJWV5GD9u3HPPrWCoFezHz8bzvmTxInFmAVR9pg4ZEf3uXbsF+DVt3Hj5smep alUqVZaeLGmGUN566whQKLACRJx/0f9ff8NW0xJ+Pm/Utg0yo0XzFnrI3p6tr3jRYpCWYJ8Z N7UTO3Vq5vTpDRvU50WwdWbCejh3boYZXgoGJCsFW47gpuyyI3V1OJ+xpdt8uGfgwhnvpRdf tGGjZLKckntVK1WGLcimap7avXNnm9atGJHZLZk07QnFH4wYPnzqlEnMaM/MmQPCUrlChSyq Jqai+SyYP09L1iHBdazD3AlgRwnjOXj22We5azm+v/+979/wwxt++hPW8p+wPmfdB57tHWoD z816TgPs0L79GZfEu8ED+w/w7TA3c9QGPSwe1X969+x19113Pf/883//298pzLkffIiVuU2r Vjf/9ndQS4zXwXvx4aab9NNd5AxcIOPZtRAIsGAd2rWN4NETJ/bt1WvksGEg3ll4jx8PQgUQ wVatXp3anTq0nzVj+qwZM8SniwmaOmnStMmTy5YqlYrVjLekkcmLnXfixEmECfNuuzZtuCX4 W1IZD1CLP5S/FSry+ut/wOuNi8ZPiNCG4RPUp3DM4JYchzMEJgt7rvtzrVq5KiiHqXKJD5SR nRvQEpN6vl+fvgBQrOr/uO0f856ZB3ixcOHC3j17Yjnu6V/8/BfBX3+RLyZ9+Yd7Bi6Q8QKN Mkvy0tDWGC25E3r16EmyZaE5+h/n2/wFCwYNGkQWsX/CxYEOtG/Tlpth3JgxrNhdO3cJ+Npk rh2/+MKLTRs3nT59OifysqXPRpCxevXejhDrGa0i5nz7bcIQcAyUjDMN1/3zn/90hhWUX5GM 1fTwkUP82pHR9QDZvA+wYMaM6Ry7RiKGCMNjpNdf3xFQzgsWzHeeXxV4JUBPOHO576iRTViA ZkcgL+VvwRpvu+22alWr0YS5vAsXKgTnTYCDlYJZ7ty1K0H0fbipJ/10FzwDF8V406dOg9Vi q+QlB03gN0wiwRMRQeJhMHEMUPDQJ3yRi+3rnn8eAA9Kk1bmQxcNEi/1s2fvXszTulVLTmeQ P7Z4PsNEiMVSMXrqcAlNVYwCkMRS1ov//IfqG8D+jnfv3oU3YAi2bttmt/blL38ZWpIL+9NX fgrAh5aoZfC589sKSvDVBzrp0KHDv/zlLwU6XHvtNeGk2KJFcTwbvzAMDe824QZ8LNo92l/u 3MlRy88bocMu+IWkL/xozMCFM575sQsSWQdrv3DBQqSPjnUnxiR8jsrRc+zY9ldf4zSHwo/5 oQ/XeWAVYTUCTMMxYRLhvk+eDFfF/44GnyZLyboXX6SsVixfAWIzizh1iX7hG/9yyy0YI8lH OGDAAF/hVLS3KED04UlGIJLQpg4CS0YZ64ULBSx+/H8+PmvGTKoj5gTvgquIIi3mz+eWxHga 61zyeVApfYK8ZFkgsn+9rFwFHw0yznlPeeGMFywNZAvjXpVKlbgHunfp2kUIXdu2Hdu3jw/a AUbyH1SqUKFzhw7du3QRU2eb17VTpy6dOrVs1kxcpgP/BA3Vr1vHgWtdqLEDpk6XQ8oBKHVo 115wQ3auCxIPCAhL/O63v2MFDWwwcOBAZ4SWOBa7ASKMozIZ79uEHkSSn/D2vffe94lPfILH AtzUJaVKlEwYiWYKF0sGBldHk0YRUDOEJuS895we8WU2AxfOeIHoyROM0axxYzF1AszBncFZ alStWrJYcdgUdsiSJYqTV+wiUoxxxLVo1hSXVqxQ3p4NrlrqB9wovV+F8uVEo8vCAjztwJap fNmyMtuKCxbhDvgXAo5SZy+IRKBHGHAIY3HWCc9AtWKSggUKOmNrx/KZMJ4wEPbPkOKFQBYV ivHIW+nMXAKV5nyYFPKQpcSFIdhPUJIGHirNeJcZDefI4VwU4wXeY9IUEsrMwJjO9gjNLEpN zPi0KVMdkCQTxk9wnsSgjjKW3HfPPYLBxRAJNxRiSLUTAFq3Th0ijspXl+WzY0cxfngAZzYS zFi/PvuHG2X18J44CZ4pegM/PFmwIMuJVWDXrt3YyW7QSeGYrqI3iuYWBRMkHsZjBQ3xYIHx /vcT/wtC2bB+FAPONBJyfjLb4NjAeHzfacbLkdR9GQ/6Yhkv5r1TjRs1Jgrq1a3HrMevBRVF HEWwzMaN+bKLFC4s8teBXH033nCj8BPmeDEX4tA3btwApSnEi+4HPoYnwcapdrff9neARior BmYtlEkhOx4FMzCifupTnxRl873rrrWRu1702HXXiR9l5Rdf97Uog8DDbiTQTiiKZAc8H1/5 ylfiCL0Mxrvrrjvxm+Xg2aXP/t///Z9jO7q77767RrXqkaj88Y9lTAlRtqJX/Er8piXeZUzP OWZol4DxdCHEA2JDkIHkFrAsQoDhbhkwJ44bB8zRo2vXIYMHyXriQIRbrH+W+MY3vl63Vi0h RXJptmjalK+MRte+TRueCciPAX37yWUiaqNkyRJCE95pd4dp+bgF2tA2JbqQSuhrX/uquFtG mqJFikoJwV5SoEAB2YfkPhAwwhopPYGgSRKPNkniiQoVqC+oxC369O4jJyet9cpPXVmyRMk3 3zwoQwTx+EKcwkyGGFbNd9pq5pgXnh7o5TEDl4DxgpWFIle2dJnmzZsjX3Aqhkr1Ejq1b1+m ZKmunbrI605vnD51CiVT2pnyZcpiBtksbJzq162HY/3jKO/TsydoGBu9/EhqLURxbjHRv9Nc SQYvLdTpj+Pt2wW5eCoBLMRvCKySzUGzYGt9fcfrYGU0yeNxrBAOZF8NAU1hy2ozKdAJPEAM DCeBzjkJPCNbi2eEGk1jGi8P0s3Zo7gEjBcmIOK9ba8KJcRLHHpt2rQWB2R3JIpRRL1/XNJQ woKgBQLLsCBHC1w1kWV/JcUFBJYNGKEnmR+/vA2eXNROnluvS6wpWQ7CeLJ8AuI5nEwc3Emb yDNxZs3opJPgHkhtmbPfeXr0l8EMXDLGC2HUZAtZx1ApE96A/v1BsZIb0DzlgChfpsyTBQqo RpLniTyMnPIOLJgXGet95JKQb4cuV61K1Tq1a2/bGqUGuwymKD2E9Axc+hm4ZIyXyD3cItIH DlNFBF4v6BNGS0Dn3Xv2+NuwXv0QF8MKKlWE8jcRimXaNJ43fMiAoaIQeFeI/730j5vuMT0D l8cMXGLGS0DJ9k7SYJJd0kKxpjSoX89XyWSLFy0yacL4qZMnVShXntuAVGzauBEHoH8ay/YX cmCmue7yII/0KP5bM3CJGc8wQxR9YB6aJy8f/zhnQ/Wq1TgY+MS5B2r4r3JlTvOqVSqrSaIc lwwuIuoyWC4leP+/9dzpftMz8IHOwKVnvNTHSQwSUJ2SK4p2le5TZJ0SsIIS4EXomcrHnbZb XE4JET7Q95K++Yd8Bv67jJeksnkn82OmiEvnHfiQ01n68bLMwH+X8dLTnZ6B9AycdQbSjJcm jPQMfAAzkGa8D2DS07dMz0Ca8dI0kJ6BD2AGPpKMF2w+mZ/zmfX31PhdO0y9eXbkZzgTRWOk ZD4+V5+Z+Zsv7SDf9SnSDS5mBnI242VHY57PXCDULBe+61WXFqgZYOXJJwvvqScQygBHjBRV s36XD7R3AjJVGyCN4X63Cbssfs/BjGfoEpCJJFDDxUeKlMT/fu5k95oJVgLR7tipk7ydIhIC DPqdPn5dvWZNz569xDGcu+V5vlIDWLN6jVwZ3bt1X71qZZY+fVVnr3jxElteeeW8bnfqpIrN hvf88y8YQMoacbqkxHkOLN3sfZuBHMx4KEwAqwKOii0LxpPWUshcVAg6qFyZJXgcJEIgZIuQ 4EwyCFnJfvXrX//gB98XOBsQaoFkIx0vviTjZCxNVFFWhW9BnE43yKLkwHGYxDNOuntSR+WM WhnRANSjEkAo0k8JVaWJw02TSkO+CtuXSDcpc5tUPgoqaBhYUnbHVxVdRB7iPceyYsvYLWGh XqU5DWWHo/7T4IT3javO40Y5m/EmTpz46U9/pkOHjmKO7vxXVEoS9jr1kYjBKNleZmklxA0L qoghupdmQq22lzdvUhA8cNHevXtCEuhUPsSD5OquXTvXrn1exs5Enkj+Jy1nKr85Vv8tFLIy 87hFbbTdu/YEvTF5F9JVSMJ7y5/+BCAu6yGJnSDsDr75piSBcoS2adNGVC9MuQhj5cdSxyMD m7sEXtW/TG6ORQkKXAxh9YraWVNCugqRh4Lyk6Lt50EP6Sbv0wzkbMZTAfiqL1wV6qdLMi0a XeoHRRQ6deoo64TUg+o0pJZN10w9a/wp5C9hIQc4UCDS9773vWu+e43KktgMyrRixQq9evZU JlL6sxUrlovKFeCLGYoUKdy9e/e//vWvxKZKLC6H9q5Vq5a6hJLJ537oIdyC4nPdd79q7IqD Fi9WLMTmxlLq5JEjb/38pz8V6r569ZrTYvP48c6dOunwW9/6drkypQ3v61+7OveDD6ru4kYy d5LkkkpJhJEvTx55QQUZlyhWTP4YgcUwd5s2bVLYUZZeqXu///3vKT4uf+GggYOUQZUlTVpR 9d+tGmmZ9z5x1Xnc5sPAeKHcHBnw6KOPUgiVDZMB6ZOf/MQd/7yjR48eGC8p3aORDLyf/MQn 1CVPpJCDfn37OVm3Tl3JNr/whf+rXKmiSPZrr/nu16++WtXyBfPnhwy5KJtodfBArlwSY197 zTWqr7BnPPrIw5/8xCeFIFavVv3jH/+YMoCkaL06dWfOnKXqqqroI4ZnVPQOeqngep1IAwMr HmSsYoNXfvJTTxV8UuXuaVOnafCpT35SNaUuXbpKgla7dm3Z5tVzJ6uxk+f62BVXVK9eQ5Jf Bd+HDx9uYPJ/eljppG6++feSO+XJk2fK5CmVKlV2F0XGW7RoIaY+bXc5D454n5p8mBjvP2qs KyA+/5l5aj5ffbWK25EOqSxoQnC+ivdD06rUZzBeJAVOPProI6ovBKVOaW+UunHDevJHnukg lDCeXCxKN6qy4kCKNCextxzvbx48IKyesMWBG+NkSnZofnVepRZK41VXXdWkcZQGNxJ48Rpw 7NjbzCo33vBD7KcT8vbJgk/qYf++DLy4pGxqNrwYB+Cr7S6HmtxnNrHKEjnTrl27r3z5SwKv rA62uPICW2vcpWfPnn4lLV3L2uRY9hqrg7ymqXd/nygrfZtzzsCHgfGYWBAWmlZ73gIvhYQg 9x/dcOOBffsz9MlTGVusQJfIXXhuJCIzjSKqnP/5z3+Wy8zJwk899aMf3Sj3EsZTuzyD8fr1 y2S8ufKOKccZGO+mm26SEwnj/eRHP4qDel/A8HL4CryQRRffyu1px2XnmZB+YoORWub+++77 8he/+NILL+bO/fBvf/tbwjncDuMRtspq40kGmEJPPRUYz4LiV0kTv/XNb0iJv2nTxm9945tN mzSWoA3jqVTuV1U+pc1evSra48ntfc13viNxcHjYNC9cPjPwYWC8efPmI6xhQ4dR6iRaJ0/y 5817w/U/3LN7DyqP0hYpdRJ/NGPHJxBQuaRjEY3LOX/0aJlSpSXefHnzywTSH/7w+7/+9dZX trwsXyCKPyvjqeXgvLydzCSB8X584402cljl61+/WqVbumgkA48fW7Vq5Re/+MWmKRLPSfUk QreyHhqMjEw1alT/3Oc+F1JWR4zXurXx2E8eOXLkhz+8PmE8i4JfW7Vs+c1vfF0WpsB4zZo2 SWU8aRaxuiVAyy1btmhQpnSa8S4fjssYSc5mPDsi4uuvf/ubRJ0sCtgAsSK4B+6//+qvfVUq aHn7ZNGcOmVqEDiB94TCf+ELX7jh+uvt3277+9+nTJqocAIr4q9/9evb/n7b5z73WXwlv5hU gY89+kjgBNYUN1q0cFHY49kKOkmgsce4S+7cD3FoOOAAkM+ziZj6GjVtGnPlyvWnP/5R+9o1 a4YBUDTfOnpU1m2bwwceeMBmjFDl+mCTNE7M9uCDD1WrUkXCqOBOOHT4kAd5/NFHidNvf/tb IUVvwwYNlHRWHWXd+nWf+fSnpfpUJ8xdOnXqHD1dr16Ob/nzLSqHSvL7y5t+oe6KwkZvvnno sqO+j/CAcjDjRX7t1avLly//1JNP2iMxLXJhoTx03LdvX5aSw4cPod1ixUvIlptpVMwogrdk yRKZJvLlzVumTJmQoX3pkiWly5QhWzjBfN2/b7/k1gMHDoom6NSpRYsWlStXzsZJ/s9y5crL FoOJevfu3ahRY0qgBBb16tU/fOiwnLlVqlRRBkwy3BbNmxmXHNgMnqHPsMezFRQK7KcCBQr2 6N6dwyNTFK9ma3niiTzdu3aTSLtq1ap6s+1knlGDRQJCObVlpqEvsr5UrVKN319hzWrVqqki ZmDlK1ScN3++rrgWWrVspX9Zfd1UGaZiRYs1atgoLpT77jiYjzAvvK+PnoMZLwvwKoim4DtP jsNBIu7iqWVXzJr8L0tXiWxMlZOOQ82jjM5jX3y4Y3KQfTazDCD49pOTKWPOejK6XVzMPdtd Mu6LiVNulzGwgBA4PciUeyWmnfeVvtI3e4cZyMGM54kCICP5JM8YzoSv72RUOPdVSedJJ6kd huPkLllud8avmbfJMv/Z736Wx3mHu5zrdpmPnPrUqe3TjHCZzEDOZrzMScyE88d5ls49s7Ek OXviwFAUNsiZiA1SOzpxdgY+U5ZGl4QJvbC3G+RbKt8GGXthvSVXpfYQS9ywZFxst9lHFeT5 eRpPo3m+yAfLyZfnYMYLalXMJxnFzVNddmd9KciCnVAi97MSDaZl6oTw0HOis6WSLzY4gxmh yQ4dCkBKn5DS9+jRt0DMLmA3hR/Azdhgjx59O1Bwklz0+LsFKZxDpgW7bpZBBlY0d5eWdJN5 i5Ljv8MKmDHUeInxXJd2ADmotxzMeIYu/bsqPw5e27Zt5MiRGStuCj1loUgvm9Fvfpy7OnlJ QcI4M3bM2LJlynAqRILr5MlevXoqmB54+9CbB2vWqLEmNpkmOiFoJQxXEhWhKkP//v1nz5rZ qWOnpNlZNcwst05t075t29WrVrmcfaV69erlyparUaPmwhicfVaqSgafNIjQ1plNiTWrABvp nrgsWXhMZiR2I3lMzd5Zx5mI3NN3jKYoQ7s++zD8GkmwE6Bt3bt1MxWhWap+Hs6E/ScLsLLy qswT6HGb00tA/MoybhIdXerV4TJhzhzMeN4fFOWwYcMcrF29mjkxxazwH2rMGV8zzQwd2rdX F8VPQeVKbcNEmdRIQQ4lixd/KNcDwavO38BTFy5MPvsP7GeHJD/DGX48BlI2RgX9UpvFq39W m0pQa8MnlSKV5gRDcRICUywSg+2Lz78AL5baONFmk5PPPPPMCy9EjrvsHzRdpnTpBPzN3aLP uXPnrl+/HtLgrFOUejI1BiI5HwaQxZATfuUyZUNOFqPs42FP5tv0yM8tXx6gQhmTQPU9ccac ZJmfy4RhLtUwcjbjATEHZti6ZUsokrx27RoHEF4onS9B4T4FjJT88ZxDnh4CzIXspPcM5G55 htKEhLT245l//ON2QOdDh4CJT1HzlLYtVrjIizFBk5PFihThxHPVwAEDXeK+Rw4dIiGbNWuu OBmfOAwXMSUdfdPGjV0yccIEjgTgSb3Fmt6pdevWqT0GWaLw2PbtO/r169+sWTM98+D79O7Z S4F1qLckGogDoGbNmkYCitm7V2+IcEU2ZSilD/MouESue9VdDB7MTb0xGG6xF9DhilhzpZBy XO2G91SBAkHi+bRs0Tx1+bBqqJ7rcaZMnkT2zJgxs0uXLk0aN546dVrTpk1HjBjBf6j8k3ir nj17jBo5yvysX7/hjTdeBwQ1FRz3oS6Np2ioEsaYsaIlxowZy5uiTevWrT2vmoRmHgZ9/Ljx O19/49FHHgHdduHE8RN4VlauWKGUd9u2bT2Xik5eh/cFgkPfBtCrV68e2PdpCXipqP4y6CeH M16PHhxxFDz0V6N6dZuZmjWqL126lMyZO2f22jWrVSnqipQ6d/YWoftR8MO5c8+cPiNQ4YRx 413F+6wi9IplyytUqICybRTDm27epInqYoMHDrRjaVCvXtu2bZC4gs9g1oLcSpUsaWnX26hR o/jxlPJbv2FDsaJFpk6Z3LJ5c5KTgrdi+Yry5crjk9Dh2tVrli97dvCgwfh/1apV4pjokGTm ooULJ0+ajDQXLlx0/733GXO8LpzikYO6tr/DLerAvPzylnJlyr7x+uuulX57wfwF4h6sC5gN 0UNI099g06wOHdp3oAh07NABt4wfPz7XffeFrMH4X83QLS9vCeuOvwL5pPQGDADIVtUMB5ol K8uDDzwAzlr4qULLly2/9S9/GTd2bNHCRejVVjRTQWxWr1YtWo969hTN6NdHcudetHixsocW l7x58ryyZYvGvKkrn1u5bcuWObNnqZgtOmnDunWtW7cSh4Eb8z7++I7XtoOzzZhuwO29Jrgf RUsVG9W5laVooUKehVj+UNpgcjrjdcc5EydN4j1HuC+9+MJDDzyABIXwwDELz1F+CCwLir9P r17oA61079o1YTyiaVG8fVK62RIuvGD9+nW+hl2HIipCSJX1e27Fii5xmQegUChKQkybIUOe dgv4LMoVE0uNaAe42r0wXpvWrYiRpwoWhFp+5OFH4mJjERR7z569cG21a9dRBX41aRzXW+cc VzJJjaTFixZFEql58xXLl6cwXjWi28Ixa0a0WACg7Nq5U6Q5BrMXjW8XgXKQOEf53j17H3zg wU6dO4uHsvRUqVgxCDq3c5UDXcHQIPqE8dxu7uzZvpooSb7bt2urHwjPRvUbOFmnZk2kryq9 Y8vX4oULYdAUuLeiQc84CbNqVmnXVA9fmzVpGuEQSpZc/uwy/JzQlqXNSzG2DRs2KBplzHTR EsWKLlqw0AriwmiJqV5j+fJloVvIoeHDhls+OnboGJaMJKLyMpBVl2YIOZ3xeii57sVs2bwZ HYPzI3cUbBexbdurVStXUbeoV4+ezZs2xVpjRo/REouKQI/kXUQoTYT8OOjTp09c46Hl889H dTAD4ylstH7dOu3xtj5Rw/Rp05FmYDzhORivdu1aGI8hVJsMxpscM17/ARaC5cuXr1m7lh2V ukipU5hFvomhQ4ay06xa+Zy7h1tPGDcOPwcLCjVvxbJlWRiPNJg5Yzp5VblSZbqfZPj169XT Zt/+/YSneHYYmvnz52G8fHnzzJkzd8WKFQBlFcqWjRjv1KmK5cqJMAyP3LF9h4DwDh86ZFC8 RTnFjNeOVCf6LEmmgPoAc1eubFk6uQr1JDPgTq0aNaSrSBhPKv6pU6d4Cp24iq2rdMkStsTl SpdW/dNJJRCB4BYvXkJXN59DBj89bep0ANfiRYsuWbS4Tq1a2hi5NWXF8mUe31cQ9rHxy/Jy K5YvB/j24bOw5GzG69ShA7LzhtauXmWZP3L4kIrQY8eOmzNn9tZXtqrCZ9OCRqtbpNeuLVu2 7IwZM/55++30yUB2djIVCY2pU9lRtmx5GcosWBRjxjtRvUoVYT5UtVtvuQW5d+3WbdLESRiV MjZt2lS6mQiAu++6i/Ylao5eR1oWK1x4wrixlDEaoOKbtCb/mBDYcWzkShYvMWH8BMTtdkgz ADi7dOo8dtQosbyRfjVt2t9uvXXZ0qUx451EjuwiMN842bpgVJUrVcLSipm5+7atVLjZQn7b t21H4tE2d+/ehR/69+s/b94zIoawa/v27QcPHqTEvP1neK6tW7fBqhmzqaDaPfPMPHFStqYl ihWn1EGWkdgUh9o1a5gBxQynTJla+MknBUlAfs+bO4eSSQCSe+Da5u3BXLlEA5oiMln/BrZw wULMbxMrWMmiYAJ6dO9mxZk/f/6/77rTRprMr1O7Di0gz+OP7XzjdcqzXZyWdolUaOuXfhg8 Bw0Y4OmETRbMn4+4jhnvQ6Vy5mDG8yps53CUA+YTlISyrNYtmregpciqYLPEQgDfGCwco0aN FlBDY6RrhU0XKUT+MGYKnGOnmz17Djt4+IlWNnPGTK9cLDnCcvLZZ5996aV13j5SYyBhGGRI wIrdunbDdSLfhPkISF+37qUgEl2Ojok4VhDCSqcvvvCiMtQDBgw01Fdf3Yaw3IcNEwNoMHjg IMF77CUqchqAreabhw5ZGt4+dgxSFFc7iSXQqBxJrvUULVu2tDti15HsqEWLlhs2bIRWpTC3 atXKGYKCqta5c5cRw4YdOhhbjOJ93Yb1G8RGNW3SFOLUyfA4OjQDwiNog0L4bWbNgOAmSw8r CFMHcaeCvFgkthn9WCMYThTTtsS8tG4dY4n2Otm69ZWxY8dQHQ8ePEA7ZXbasH4dZcE4hw0d ynwiSNLwbJLhV60pONBusFu3bpCufsVqfBI0BTrLwAH9CUD7z2gVjLyCaca7NFruxfZyNhzj acRjlhUlC0IyZq0zai/7GsRgGFZG+0x3Q3J5oN3wyeKxSAFyngZwRs0yP8mFp3vIhJVmsdpn ONDjeyV3yfII2Xs7x5nEMJh9HlIGkzF7wcmS2jLJCpM5RWdBlqZ6F7Iv52cdW+pkJpdk91KE 7FUXSy6X2fU5W+JdZpOZHk56Bs53BnI244WlMDyDv/+NdfG8nEjvgOTM/hKMMAMReib67Hxf 17u1o6clYiQW25dOUMT5qoMwjKc6gqWE40QipaoM7zbSj/rvOZjxImTgsSi5nWc4cvhIAApe SlIL4XMAlJlozOzE4tY+4dbnRUoxgIad8xwpn0Of59XbmY3CTlL/zDkh7V8MXr2Ans5ySUaw VZxEmCE3mvaTMqYd0f2xY8cxYvxconwjS+alueWHupcczHgBlGxbz5gmHlQmr8R+EA4CBWec jMD4Z5yMfsgkkYTQkwszcsyePMkAGNIohJkKxJCx0mceMJ8wHjCuhPMZvUUwwwBFPM1FbJvA GdBtsgwi3+R2qaPN6OJsMUEBpZ3cInNIp/tnfhRcW6tWTaCZZc8uCyDIlIfKGH/2543Dfc/F 7R6Njy6a6qpVx4we/eqrrzVu2Ei0LjOmK3kO1LiHs6lZs4Zmad5710UjBzOeoUNISIk3e/Zs tjKZS84EQJ6BwwxaEBRI9l0+MRkLh+NhLlIrKyDFjRs2nC4WHRN+zF0Z3fCYAXIxq0iORBSk dp6p8sX6WCa78kZwasGy6DbcNwnbTa6dMGHCypUrU7six7MPO+PNRewSc2PMj107dwFzEboO xsUgmfJ2U0N44+CjTANSKmDVc51VdOtH5l9wNu51YLfXXnuVvZEbAGhG6he99ezenbN029at 7psYjd+V+D7KDXIw43nfDOuSWCZEiWgGDRhYpWrV3r37HH377aefHgLhIWPCqBEjYa840y3M cICcXc2aN2fdrlql6jPPzMUwjPi0MokkeAIgs6Smrle3Hm8SdPLokchr6759e1u0bFGrVm2+ JmEQfG4w+ERcseLF//WvO3E+vziQNN8G1JVkDbyCL7zwYrt27bnRIdpwV5hoRvmypcsEGyZX Ne+WA64tcrtJk6Zt2rR9Ye3zd999N+Al2z1HWeUqVYYNG+7K0aPHcJPobeTIUXXq1DVgcBl4 EYiZkLrChx+iQrnyQQ8MH+tRl85denTvsWPH6zzgnpcj0Ug4SPRPUXRrDhjhFJ4XkitSHUMs YmYPiYQ3G+pMJD0DAwG7hK98DOXKlnFt8utHmaPO89lzNuNhKlnDYrmBlE/xDpUvWxbFYwzw rkKFCtG7+HaLFi4Mc8hxDOj477vvHj92HLAvyCVvFXyTNZs/2n6Ok7pr5058g8CNWKhK5SpL Fi/hXwawhF8BziBDZKpdumQpkQKECc4CRgzvAh8t1R9S1icHF6xww/r1YankJuKnKl2ylFCA RMh07tTZ7dQ/AVXhsufyMmYAK5UPeL2xE5TzyBEjXFizeg1eNU5zmaQrV66M1qGN9UnMQoE8 PWhw6VIljYTHMkhX4+Gdc2DwHGikK6aSahrcxIVgJc57XoPx+Dz4ADe84YSYrE3AAIQYn57L 9cbDKdxB4plEVjds0PD5taejoghtqVy6du2q/arnVsLKOjBmrsjZs2afW2s9T9L8cDfL2YyH Vp59NgPn4cVDPwyPBSBHMEhHvbp16J8L5y/o1qWLkyWLF/NVPAHUv8zNI0cMf/Pgm+XLlFa9 AJoR40lSBPW7bNmzUBra8+pOmzKldq0oHK5i+fJJqAuEIfRJ7ty5582dC5gClmkSixQqTGpF AMW4aoIIicGDBgYEI7h9iPSJfcCRrLMdhbDhLyaCpkyZ0qFdO7gtTAuo7VeLBeCVWz/84EO2 jlKhLVq0MGStxYEtmjXXpnKFiuDaoGc4n8pK3YwYYOWqgOR6bfv2jh07YoaNGzcEMKSFwNLj oG+fvqCVXNjQBWRUtapVwFwAXPwEMSOeIEgt0ljaX0tA4EN/HYen8DW4+PbvP2AAAGh0yxAa 4om6dumapFT7cHPORT5dzmY82wxbi0TDGdCvX8h4CQMFMIUa1r30EjgFxsMMJYsVI5QwHigW /iRVYD6gojAevnLV9OnTevXoQRSgS19VCALdYE4gScqWKqWyl5PPrXgOdtGODriJXgrKGKCP gPwEkRgCE8qiiCKHPj0kpHZu0gT8MuCeMwwzjjEerVI8IY6dNjWKbNq2bWvZMmVF2UgyLawB OLNK5UrSh23dtk3RH1wEo+zXls1bIHxISLAsWiGciicNMwAUTrp6HMe2ZDHmez2hGo2hUSPA SAc0zxnTpoO/gNFE4M+KFa0drVtGz2t9oW068AjgY8IvILaC7HKSug5ikkx1OLCQlS9bThAQ /Tlgr23zwMqTh71I6vwQX56DGc+6Kw4I2M/mR6wXzSpCSxYtKmyMQkX+UNIYJKOok3btAK+e zJ9fcQ9qJ+Ai/oTWlTzTV0GiwJODBw/Ony+/JNBUTUod0rH8Q3VCZgLv2klWqlDRBgnErHSp UsTUww/lxqgLFiwsXqz42jVr8z2RBy4Z9kpyS4AskmrihImdOnTUj3BvgwkEjSswqruDO9tb zpg+TdkgLI3oGWkMHnga4llsgQgAjya2TVwfM73dncD5WKlr4MFJb2OzaxXWoDxQIHR/NS5S uPBo4Q6t2xCSJCSkuPNw4bZ/IP+lSpSkb7OFkI1AniJ94dGo3/aQ1atWE0aQdBVYK5C+kZtq wFGg6nHjxi1cYCzP2OtaDlh9NbMdtYKYeboAqGp84SXyY3xImS8HM17AFqlZ1a9fX2YMUdi+ KpwgqjJKanDq1Lxn5gpPhVoUFcZ2ggPZJ2logkRffPFFOx+bHNs8+5nVq1d16NCBGAQRtPvC J6QKsbNl88u6xRiWfVYNbZCySBlCxoZQYBty7NWrN7aBzHQM2ElRpPFKaiAsdeXKVZhEEKBq dcEHsHvXbtB7Ymfzps1GawtHAut8/vwFbdu2U3VMG/BuDYgOGE7PhVvkcdEJeKf+RXB7cBuz lSufAxPt06c3QRfkUtAAlyxaRFZ369ZVnmmTYz2KvJHHjsFG4gpD0obMpwaDU5PYrP8Vylc0 5kmTJodOEmZLpfloqnfvxmYqNwgFZGSKZmzYcA6MYJ59dslS97XrE5KX2s+HlHEu9rFyMOMl pJboP6mQwiABsvwUnjb5KRycFQOZ5WTYRGX/pE5flkQSoXEqyDO6XYqPQ6g7AcKtl9ptAhk9 Y/DvkMbi9NPFZBB4JvsgA7onOZ/l0UClGVTDr+dgmHMgRWP80BkOj3DmYmnzQ319zma8nPtq zLtNXefOnXfv2nlmIsH3+5nYReWcjtj2PME37/cAP5z3SzPeB/Zes8irD2QciWs+QtsdT8uo 9+8lpBnv/Zvr9J3SM5DMQJrx0sSQnoEPYAbSjPcBTHr6lukZSDNemgbSM/ABzECa8T6ASU/f Mj0DacZL00B6Bj6AGUgz3gcw6elbpmcgzXhpGkjPwAcwA2nG+wAmPX3L9AykGS9NA+kZ+ABm IM14H8Ckp2+ZnoEczHhxmscMMH5I7hhCb97rS4WZDLMQgIuOU+H277W3828f7hINOyOO4fSl IVDg3J8kniCjcQhNCBkv40+YkPiJMrJZJ8EZyU9JCEVSFDI1ju7MsImMyQkhF8ktUoeadBs1 eIfohIxHzoyWOOszhnGeT3xD8qbC857njL3b1L4fv+doxjsugaRMOwoehPcktDQqzfMeP+Lo JIOQux9QWIidIL04LewJGUfE1L1T6EBCxO/xbqebG3AIKfQ3yTLkZyvHoWgw70hGgR/kL1Ip QfomyQX90YnAQtmZMugvypwbLUzCC50PS5IDl8R3PPHWkWjqhCbs2bM7JErcs3uvZ08YSdj7 jtdff3Xbq8IRpb2QXdRESQkTzU9mHIObRj9l1pR3awUbBPueIywoZHPzV4LAqBTz2RbKI6rP HDoUErqde3rdyPOLAIwm8JwgbzdSP1C5lQt+X5f2whzMeN6KkiCFCxcpX768mjvmRSEuQdln ov5Px6Elj5p6gAIkhhg3Zkwo6dy8aZP1L70Ueli6eHHd2nVioZqZqTqOxQ5SMdBxdJz5axLz FjFPyoqeiKZIIsWfRFxYo5VFkU9JHGo476/g1Hx58qKSs5Kdk35Sk0z6oxrVqklmMWTw4Pnz 5rujNCoSioWrYu49JEGLHBOK9QiWlQRNLgwJHUJ2DPHjhQsXln9T7LmvIoNKlyotq8XmzS+H B1RJS+2X2nXqlChRQj4YZ6Q2Gz92rIygoorDg8ho5hYh2UT4KLckv2DqY2al1xMnhSM3adRY foCe3Xsk61d007ipg0mTJgmxdZyljkKsz2Smr86czEOHolJ7wurDTSPxHmVJy3jvyd39pNRu wwb1w7u7tFx0Ab3lbMYLOeeIK7m3vH605aVaBRFEyE0kdlu0NbKTalptGhOuio3zcS7naJmX EkKWPqm+oguPH1ezTra8kKlOqhW14MK6G9ggfFSl079mqhxbm8PqLhDbT/v37Uu4S/0gvzqJ evQfsu6RTqFlLO2itV8AePWqVTrG6YZcK/+SxJsPP/RQKKyV5Y0GaabmkdQS+MqodCv1g1QU 0YAXLmwYF5TMYOAZM2vXrOUWEq5MnKh82Fi50qSZqVi+whtv7JR/dvLEqFyZgXhezC+4XslI SdNCD+5ltP6akwH9+jspnp1AM11uahyRgD1yBMWHUuYmXz9SV+jBGwlBydnVPyeV1FMQk9Q1 53oIExjl84z0jKiQ4N69+6gbo0eNxn6+xm9nj+eVsjp5F5HUlUj32DGZF4sWLqTCkZ/27tsb K9sIIJreAwf2hzGEN67iZ4P69dKMdwHLxBmXmE35C6QeMbOWZNXhlFaUXESevFo1a6urLNeY 1H0Ki1etVk3qFOWOK1WsJNlJqxYtJUeRztkbVU1WZjuqZs8ePWlRsnFpQ0qowuU91aldS+eq z+lNTgdZfVSQrFatuvSYbVq1/sMf/oA4QqJOmQUlcZHQWvE3SVz69elrRVfRynIg54ocKtu3 vybZniRIJJWsE15/RGsxN0pRERjPZ9SIEf379lXQTycJC4WfgiClK6q8l5o8V5EwCSw0UNFS TdbQ2EdmJDUDpSSUr0VWmKaNm4Q8ufILyq0iA0WD+g0krUDrMlyE0sqknPRHFqkgE5yRu1Yi I6wlHYb0FmHOlYyVRUJ9eckpLAFS11A0ypevgLFNmhTD7qgs4e7dewIDJ0MKfbq7BIcmPzCh rKS4i1yVf0lqDPM5YcLEAf0HFCxYUBHZpc8+a3klq/M8kWf9upeGPP10hQoVpcawQjVp3ERi JSl0S5coIfWTZlKqCuo/8tYRiVUVnY5qa0s3HKeiqVSpcolixcx/SO59scR30dfnbIknKdgT jz/x5JNPNmsSZbZq07pNvz59LN5UUDm/VCr2RjGVcseoTQlLqY1e3rzl3rvvlgTJu5w+daqc JbNnziI6MJu/UdHWoUPkyUOyVE2aiaRjRJAstxUrlKdrPVXgSbLIvkKbGtVrWEddSNkjHCSH xhV66N2zR8F8+W0nsJZ8gZhZs2NH30aO8rXIfSLlHiZKDANy+6mwafwouE6t2mR1tSqVSYNA H74qE42BQ+72TZs216xZK17Io0IRDtq1aZsnTx6FKQsWKFi/Xn2XHIlqJ0RqcMkSJf/fb35D vURrmPmlFyMt2pDGjBqFQ3AsQmzbuo1nlKEoqJdlS5ci2SI+jzvv2qWzTDAOqH/9+kVZKnCm CntPFsj/zNw5tpSFCz2Fc0yC/bAMn1RN+UtlH5UwSh7BaJwnT3quSZMmWhnDE/krd8uTBQvK oSYHXKsWzTdt3HDHP26nvCycPx/34u2e3bpT/vv37xfeoIQuMhpa7yxnJtYyKjna448+Kukb SViiaFF7UfMvMWmp4sXVpldfVvFtSdaktLHLxefyXHl98jgaUprxLmrdiFZf5Ua7dpN6VeYv mpIcRCqJSuq65eXNqEeWS6RJF6JxeT1jxoxWAN3uR6lXKopMW7Z2gwYOkM6ImiR7LD3KCrp5 40aqqWoMC+fPsxVR1TH3Q7mbNm1WuFAhRRLpdWQdBpOtCK0bg0xbJFggTYmrH3n4YTk7EZbz XraRyDOp6KQslI8+/EjtWrXUHmgoU1hmfRUXSs2E2hy0bdO2atVqhC1VU1KjIB+sDldccYWF IFAMc0iF8hVcHudgjxp0aNe+b99+iHhklIEvSr9ZrVpV2fgIfyPctHGT7KOSiNKyQs5pOyvF n4MUOnb8mOxpshjGtZ2lEjtcoVyUri/6Lb5X9WpVg248beq0wYOj1NG1atRcv36DdKO7d+4k ssuWKW3XJ0116HDNmjVkjgMZqCRfDCc9nUfo27t3xM+ZezNZp3DF5s2baMKG59WYW3J42dJn B/bvp8w19Vj604h1T5zUZt2LL9FuHnzgAVkGZVKTetAW14pmybPHw3gjRgwnAx+4PxfhLJep h2VzkiLR17pxweeN6zeEEtNpxrtYxkNDiMacyq4Z8md6YWafUkfJrFq5UmQ76drVrlob/IAC vKeqFSsxYsppOX7cWGqkjF00N/obxtOPVJxv7NxZQzmO+fMaNWgwYfw4RPnmm4cOxkVV9UO9 JLJY0uSx9tW2SlXUtavXlCxRwg4K71GfnJcXjG4TLrH8Y0V0tmr1qsM0uSgzV/RJrClKk2um 7rG0fOq8/uWWW9wl2HAYFSWcJaAsGWHfZdl+Ji46Gz6SF6JCB1jOoqNz+iHpLb2f3KHO+5XU tdAQtr7Wr1sXe4RryZMK5ctZODz+sbeP4l5LQxBKfu3bu0+oEe9DZ+vff4CDMqVKrd+wgagk 1mybCRP6BR4IzVavWa0EswNSS20TBzpT+hxTydUZKdjRJ8PIVKZUaZk5ZWcsX6YsPqGTV65Y ycj79O5F37ZQhpkk8IcNifIUW0qsj8yqllEagc3qgf0HPG+ZUiWlVLXAUV9NjvRNqtWSvQS4 bYOnsxOJ52dZtGlPG1cuiu3ihVPuV6nUbc/oHl6YysNegL2HN03BkHOWQvj4Y4/LZCklprIK FmbWDUqLNyd565hRo627pCWZwDxDqWNIWPfii6+/sZNiJnlk3dq1WR3Z+qKq3IMGIg70pLFc sfrPlzcvC2SDevWdl41PyXXcpZ/evXrTyuyC6I0SUBIINDELBIlE3EkFL5Ulug6Gh4gxZsyU 4jJhJAdVK1UKxqFEPjiOWsfqn61agXz5KYoeH/V36tB+aqzU0cQ8e9KPgsaFnnrKgIsULqLW NLovUbwEg1CdWrVw7zNz5lIWlExo37YtUrRm2Z3KqDtz5ozQA6lu6iQvpKiTyXaMZL6Huutf /6Lu1qheTRZ3/dDeLXOutQzhwCWLF4WEtj169AwSL8seD08/v/Z59lL8Zj3yq+LYD+TKRQex ajxZoGB0bfcexKORFC9aTIp+Sqkq87LQSwFM0bXBk5rNg5PVrFk8D9RL2RatHfJk57rv/pjx mq5eufLAwQMVypbDqHazkhRbGW1D9J+WeBfJeiet0CNGjLQuBlMEFUj9ILttTIi1qKCUfsV3 hg8fMXnylI0bqX6bvWDrPdcTQqRKIeVZs2exgqgr8NZbR5Xz3r9/H3cg4tCnv7qVqdZ+Q4ER Ak25Dx2+eehNQ6d5yodp48SAqdkLz6+VSRZXUJ+wmeyuVFbjkQyXuT961LhKOCmEaJJ3H+wl EmwmcxHl+Vy1yvbpbPQRmf/ci3mDP0AaX5TnqVhuULAkogaT9KMZ48eQIUNtdwMvrVmzdsTI kbt2RuXEJH72UDNnzjIhhBLzCTvTM1G6segT7fcOHpRp0/RqRvvVP51NNls7KJZh02WG5cx+ bsUK+gLiHjt2rLoRJs2qpzG3xGvbtgX5lvrx1XThEzMZKxEnvaOQXt4uMVS091pf3vwyFXfi xEkyoCqDYdiS1StJz/eowAMlxcbPezRLVlJjsAQsW7bMhFhq2V3pI5HJ9OhR6wV92DFXkzdI nblYmrtE1+dg40qqNMiyssZrWkoKyxRpEq5Krj2zslesAmUa9MJFqQt2SjcZtofkzFnzYZ7R PsW5Fw0ghR5Dsyxn3tHwdmbyzOT9JeNMJYxkAIHtU0abJQ3m6WycyeVZKIOim/I4mbXHYqUx Ow0lg8nuToi4OqWj1JZZJjx7t6nzmepeP+sYkrechU4uEeNcbDc5m/Eu9unT16dn4AOagRzM eBbLZPRBOwoC6lLOZOYtguk/rLJZbhCt2SnFYrNInowLM4Esrk0VO6niNFEss8jYLG0iQGnS W1yJ/Ayxlu3howk5w5OWkez9vc5SIo6S580+1Umb0HmQOUGSx6PIQKWeqUecgYzNuCS+PExd xtPFVplU8Z78FCpsJhpH7IS/pDTwXmfq/NrnZMY7fpxxcssWxRG2ej0HDhxUEOHSTrqXGpAT sQUyep1gK1lqptIJbTDsKjOoTZVwu59Dh8LXBJpoJ7bjte0xnOKg3SZkhjH7avuhyMGGjRtY U5JLbOE2bNjI4geWoQ3XCD+4j32XF+Z2Nqs2OTjQ3mzbtlc3bFivOOtZnz1GyBzne1SyyxgS pMj5kUdGK0NVOMVGLjx7BAw6cCAq457Sizb2xgyOYRjhjRheJuNFLGQ36CnswWxVudftM5l4 wzzYHJoFM2OEoddQKzce+UZmEvMMPrpp8+bDbx6KqDae54ALDcgyW2VTcekX3/c0U+fdOAcz nilmqCxQoACsCazjunUvhepwyaoZjkmEQAepP6WKytS5ymJrdgksCNe58wiCAZBlLwJ2pIC5 tOGLZ0EN/b999K08jz/OPZg5jKikEeM7uytfBXplZgRe4dTmxEdMjgEs9PB8XGndYI6+fZQR r06dOmXKlKlapTLjQblyZSFu6tevhzIxKkc8MynPHuMNFEjevHlq166lxhBTx1nsMXFNJYUs QXaAeEKxsWha4k+4Y/T3zD1laj/hF2WG2HK13LtnjzEbQ2ob/WGApwoW7NGtW+jfje6+8061 BMMtNN7+2nYGZC+rR7fuVpAWzZt5BP4DDIMhlWoyh0yj/EChZxeqjlKkUCHNmG2xPb8O2IqZ dIlnZyKGEIAo0nLRosWKGbHfqj2YEMB5c8EH0DBnM556yEyall44abYvrlXIzEgURNrYKedB +EFEYmo+xueDaKK3EpePVXkHXDPWTML6Gq+cQb+JpYSWjGBPFSjA4a6BGIg+vftwWwErhVcb tB1m6wL58sVglIhW+KYfffhhjuCEppVibtUy8inrMwYiRmOAseKWcEmtWrWA9AMnJO8/0C4X Ip+BS/Ati2tykjfZsRKtHhlqhA09/HRW8tEtaczUHiBabkO0sg1akAio0C3RQTQlAtOsRDOT oSJGz6gSYJ5HH2vXJipbCQ4CjRlVoowrwifzAOf5+COPdOvcOQyGizXXvfc+M3t2Mg9gesEd J5ri6FtH98NVxvg1dcswlRqd4cIgVONhHyxetCgfaXTy2DFOF04Lx1FVtvETeGUxeVRbs0oV r4mnbu2aNdtffY3v4aww1w+At855y5zNeKRHcKBXr16DLbtA/ny1atYCwmShZmeP5EyFCtxK bx48wDmrUhwX9sJ4DSYh8SpGpUEFig+KzYwZylYtdQbtOetaLxicivvBSbKOeAp8kvAqMATg RQSJOHWKpZ6rmi+R6zkm8ij+BU1wJXNeE1YJbXFgQDBpYJ3u3r370qVLUjknNIM+4zcH91WC jz+NX85JhcSqVKqs8BjAGvs7lGapUqVZ+XftysB2ZhHvboHTVN4MHhdAFsLKs4tRgLHi4Nqz ew9NwTKUcL4DZQBVBQuPQEo3atBQnc0O7TOcjZwf0KfJUqGN9U5XADrd4yqZ3Bgtm7ckIWdn egWxfdmyZUBPpkyZZM6jQcbhHcFJyNOdN29eJQq5ExJG5QUh3HhKleNzkqfE2+TM4OLHaSbc JDhP4sGaQagErDaVRNG11Mm83FgujCeHM16PHqWjaoktOUxfevGFwk89ZTvUqWMnPiLeapAO OgxZBPFQIF9e72zunLla8sMiRE68ShUqzJsXvdRkpz5s+PA5szNAIZzOMGj2TlGlxZgqufgq la/A+5QQh57xGJcgwIqTsKMLFixQjxaAJuqWpH3r6EMPPIDhjYpqRMKAGloa/nXHHevXrder oIGBAweWKF4c80TdZm6QOAA5fMkiG6rRI0ciUGUrLS7aAEz97re/LV+uLJFjm9S/Xz8162hx RERQIHm0Bw0cZCsVhwedNAlPPPYYqlUxE4DOP15paiGOov268OlBg1yVaoYB++IfD/w/bOgw /jF4zgQXpta5KuoJ42kD0wyGCnwXqk+bDY44LLFg3rzQCdfl7X//O7CBn1q2bOV2XkeRIoWB 4/bt248DKedQRDz+bhQumTFt2q233NKlSxfaKfyDMwKXbv7tb82VZRFWRl1eJ7naoXA9CICO Pv9w880BqHR58lsyqhzPeDVr1qRu2QhZv4MONnTokJHDh9uPzZsblapE0JDQ9WrXpmpGK3GL FlMnTwKVUBQOzYnKCeQO0QurlS9/vmLFiou7EdngQBktQBNUy6VrpiLGq1AhqJq+gkrnzZMX TkW19IIFCgBM5H7oIVqQJRk+m/pkli3DDz34IIe4S4gaVIWRoF4QKPBkYm/k66cyhSUgiCxA DRU2HSQxaQplUi89jnEK/rXkI7hAo6HzZXE5eB+AG9hIkPxAf0ailDRmo2F6EIoiafn4o4/x Pnv8m37xC0IvuvXxEyJqBw8aDORx/3331YCfbtvWQz2cOzcfOgBa8WLFAn4a4yUSz1chObly 5YJxIzltPufMmQPdakkqWqQIHGmIh8J4ue6/H07aMfgIaCUtkWlEYGGIRQwf8U1hJxkdT5qM Dx2wCVFeQGHtUe0dDI+4BoUNwDfAIC1FMFN26tdvkDfPE8xI4cEv50/OZjwY6UBePiB5ETWw uAwcOGrkCLssaAdfMQ8oE5Cetw5WInATjIvwQRDEEUNZWOnhLQirunXrQUELlmFJGzNmTFQV uUGDu+++O6hA9CUlvyPTYhy1ybo4bNhwberUqY2qFi9eMnDAwN59ehcrVgzFJOEFkPIQzy5n PEiWc2AL28UQFuRDAQY7jqg/7KxOnoRTiwo4xyFnoQ2lC/W3Ugx5bCQbx40dg3UTksXqNjm+ Ghi8OAlJ4kER6M0eD60LHfAroCblmTRjtCDxdFi0cJFhQ6OtVwhTMkVMGsWLl6BtstzQZgd4 qN69WTUee/QxS4aW1i97vNB5vB7tJ6ysbqVKlbIAqWXta+/evXLnzq2ZWdKG/blkyZK0DA9I /qsNGEYOj0JHTZ5C1I99e/hqd0fERQcvvqASPXEdxjl92nT6vP02DdPX2lHQUwb0lApqHtwr dcN8ebJfzma8Xj17jB0zOrwnaK9Qu9yajbZodHQzWigwJ+t8zWrVAb5QFZ3Ei8EDUIt4EjmG lxQ6oaAmqmY4s3XrKxbXcEwpgg+0ZcowK2T60yiNtosJ9YDVU958Dd2CUJIVjRo2omjZaFnR O3ToWKhQIbApVGi9V9O4VKmS6DW6JCreesomqljRIqxEemCTJFHhpMlnazwiwyp0SyBJ+z2B diSAzuG5Q4qHLHu8iPH2G3aFsMezKgm9o28XyC+uZy5IKv4sVbIUiZF6LVmHSZInip9iUbfO 0f7NBzbVGpekWkiaUfYE4yRfgSotYck8AH2VK1OO7AJ8hSZjLnYX4ExbNc8IrWpmPKOY+qAw W3GaNW4irI51F9SOUs1oqWB14UKFCepXX32VZdhCCZ7qwWkxwLelS5acMSPCml6ezJY6qhzM eKj21ddeQ0+BYmDWoxQpJ07s2LH9jTeiRADIl34Cx4iWvTZaH20zorC4CPjkKVMIIpEjYTqC LXPH9h0Qj8G6Gc6Tb9Sz8NUL1qe/Wd6rbqNbZ35sooiUMKqQQGn16jWsKThWz4gG2jNE6MQS ZpWvhpdCLicobzwHBuVyEQDMKoLiUGSgaY3Jeaq1Y3XJp02bTrsL9snsBBebUt8Kj+9XEl4k m8gJC5PIJmZAV3GgGXMiJTws76idYWJn9ZMbKc4e1gVTDU1JPmahJLalCP4afzSz3oVY2PAh vYULG6ox0DPtt6M68ps3G4ApJV1BQ4NETXowBpZbQXfhwe0bx0+YCIubOQ+bpk6dRp671/r1 68yJZchPOcF/npONKymJseL3Gn+SXVMqeDL8mqwxWX5KKCMxsaTSUyoqJfSTnbhDgo/TFBZG kvIJYwsnU4+zf40vyoBrZHo6znVJ0ttZB5Y6pAyBlg3BmsxYlgFn0daS6T091TGiIPtjvtM8 pK7xqccZbJn5JKlskzxdWALOMXWnW0bzl0auZCfS9Jn0DKRnIEe7E876+s4qtc4io86mkATn +RkyJEYYhjOpP1EUQuN3IqHkkosZZJo+P8QzkIP3eGd9K1QSWxf/zmHXOvrWW7bmGcn54n18 0FEDa7HCrX3+ed5bEKegv9m6MKPbAs6YPoPrwh4yoBbfifF0yJDDCmLbmJofNhmwQdrC2WVd /sa3DzHpf7CPlrMZL2Xbdhqn//TTTwe7c8xOpzcGSWOmF5462MuQC1Azlr3Qnj2aoa9xo4YM bsAuTI6YBO6EV4oFnJlUtGW3rl1eBLOMWSqDac/cQ+pHFgYG1WRfl+w6kjFI4yPj0OkGHywV pO/+vs9ADma8iGdi0xk8brAQbHt1Gx/xsCFDnh78tLBxDm7cAZEo5Jm5TBuNiTt2wt17MN1e TgXJMzmvubm279jBssdCPf+ZeTiNKRwaA8SRI5v7wWfylKmSJsGOuTDOWxzJPKZCljfH7nLo 8GEeYSbQ3Xt261b2LrbNKINDDBzzZsNcGwOMr6RMI4YNjwXv0Q8+19z7TnbpG+ZgxkOv0FLl ypWHHfEiBw4YwIErzaOTeZ/IU7VqFeikyBfUrBlJVbx4cRlQgI/gvzZu2sixK5vlX2+9Fe+1 bNni9zf/XoIGPi7/eCCkypk4YeL9997L7ydjUpfOnSQO4Em//fbbpUtp2iTKJxkJq1P/ASuT GdYRcJkERDxyNWrWBONgKBejoPOKFStyeERcFzOexpzCXTp37t2zl5Qt0Plc2AaZ1jk/aqyY UxnPuNHrUwUKBlAIoAmpFXLxQ7s3b9rMDqxSpUpbt2yRlgfWkRe7dKmSXNIA7zKIyP8FMMX3 ChIpb7E2OpHoVnJleaxs88TCgXqSk9WqVMVpoDAEY+sYnl+2dGnJ0oOWSAWV/8cBNNOi2Fk8 Y9p0OZdopFHeruPHuKrlUwqN9QBXEVUFOHUK0AMUAwBaqiwyMGwm05+PzgzkVMYLMoQjWDiJ FNHgVLBUgb4BxKLceBE8ql4E4GzcGD6LqQOhO1mhbNk5c2djHjpnzHivUB2rx4xH3EmJi9Pk gcM2sqqCwsAHSwoowSOAYuu4BwBrGXXCvcSqdI0DYVq3ar1s6VLgKeBdQa7u2L5dlBxaQthp U6P86j4ghe3btAnHVocA/JXzC8Y6zXgfHZYLT5qDGS+ghwkxsEOSqnSJkiG3PugwQL0DYGWM B7m7dPESMqpl8xYeWA5Glkk4SRfWrVP3tde22+5RQbUXgikAh2pKTI0fO44SmPeJJwCa2rRt K/BHviqRYJrhyZUrngvTh/F0G/FzhQoyTwtKCGhMEq91XIRAHjuBambZjhRqXjhpcN9rKSWZ A7E/bLBpxkszHvDTtddee8Wtt96KQMPyHD6X1T7EYEDpJaWVLBkKmdTq2LEjbbN71279+/WX MNOAYflBpaLkykuXCleV6hz1V6lUUeQBqcX0Iic09K3AH8hJqGKX4C6cIMEjeKRiA5C44FGY Z+zo0WvWrpXpmX1EgmqAr9mz59jgMZPA4LvR3XfdBbIklTpjZteu3aZOnRKCaOSulKFdRoOn nx7CCkqiijETmtCrZ69JEybojVjmV0gzXprxcgbjeU+AjIIjxYABXkbrwslTjPhEDd8A6HME vNyxg1gTSCLOUkESRkvbQtZOqHzmRJdjV1vEkLpD5E6IA1Aoz0n7QDGjYbkRJKql9ObYLAKI viqkJToOFWrs0BYtWoh7FZojHl24YOFCv8aZRU6wrEBy+mzdGoEYiTtgaE5C5wUZgTtu377D lvKjRnbp583BqqaXl0jj+PgMGGL4NXm8VIdbuCq5PGkTqCGLkE8AK2d12WVpn3ptfIvTSbJS 73jmsC8vVSLNEu/PDORsxnt/5ih9l/QMXPIZyMGMd56wzOxTFm9YMyK7L4eNaxCA7wRAy/KY voZ3ltRDPjtNnAk6Df0HFeCsKNN33WSee5CXnC4/9B3mYMbzbpYtWy6vUcI8iQUoOcj+/jQW GGoPFkfuvR6Fk3+gL9l4hNvZN77TKGBKhYTbpkaPGYO2wWVgYqK0lpkg7ezP66HUalQ55OWX N6uywJcYb1Zfj/JhZkOZAuLYKvOvvNMy5LxtsL1uFi39A525nH3zHMx4iKBZ0yZRfoTMj/JU IcW/g7h2+elPwJSFp4XknD51GmMMt4GkfdH5zEC7ZDoyY/ZOB3R7zxmiJlPmRMaSk6nZrDM2 mUnLhEwDh5y5zTu9I+W3UEU5yOHTci8TZcrkw7UYJeTL3JfCo6m5lfp0MppED5gZER9+4tnv 3r0HV6dEZkp/GKp8M+r1hV8Dj4Vj7scK5cpivDNHmHoHNdNHuC87kDXLD2pNhoLVOZv8P7jR 52zGU3VNcishycePvQ2DIv+U5Hxy4xQvXkzCPLZEpsXVa9ZESTgkxoyqdUcVt9XiYsEXcCAB GQKKQJfHjqmJB4epJDrz4yG5igUl7NoVYTJPnFAfWGQ6OSFHy062yrhouISqfnIlAlabJi5D o0TOZoPRj58UFla7izMd54SMmu7omKFVOjC5H6XE4pZg3pT1QGIyFxJlADeJjUeGwlWrVovp VoKPTz+OSY9YRfrAkOCAT9+v7iKdCd8GDKrjUAuJKVU6CZnzpE6RlcSA9+7Z7Xk5UdTc4TUJ 1SfNlXEaAyeK3oTnO3mQBfiNndJym65169dp76TBw52q1KM3hm+w1aefHhzVOr8Myhp/cOxz 4XfO2YwHrSIBifLWXTt3ARC55Za/cLUpaHjLLbeEBGFAm9Wj/MT1uRMgUVCpnLZ8dzhBklaV 2WSMlRcE/cFh+lUmr/vuuUeZO7Qr8xxwCWkg52yUDnDrVkWbpd9CjqNHjxoSZ/gy8T169ChX tpwkKMDZfHTWAv4JiLCyZctyl1euVNG9otSA+/Yjbn6IRQsXkFdr1z7fpGkT2VflIDEGGACZ nsmoqHH8oXzCl0n1JSFn+bJlIcsgUSdMGO8nydQsHIBplStXIb2hdv7yl7/ECQ5fhBZQh10e Md6RO+64Q+Yy2ZnuvfdeTPXs0iUywEoPY7TyC4HLSFgGOOrCjRvWgwpUr1ZdAb1Vq1YpQKmu rdybUVKTOnXAXC09JnbihPGm4p577sH55kHVctrs5bBJvnDy/+CufEfGy58/P8JN1TYutyk2 NimGZJImpmhTXG1y/vB3m0y5vgkjnAZvqZmVfuHCRSFXCroPBcf9BNglozMyIhlyP/jgnNmz nh48qG3r1nLOyeEhPzSwGFHTplWrXj16Eq0YMs9jjxFTZGZAqBBxvPa41LF0Q/37RlXCBeMp m4r96GalS5biMDR1SjHjH7FIdlM6DBMLU0ogG4l8hFguPEX4SUag4XFwEymsN6kyn3/hBWxg n+avx1RqPGR0pWRKOEsiEbkyqamjkC9PHntXEDlZUlaufE6dR8147WU3mjZlqjLikXq5b7+R h6TLBw7sl2aTDJ8xY6YM0PJhmgQ7OreQH0ViMnVhZROcOWM6AFDPnlFv1jWLVFrVvGDOzc54 NKCbbrrpiqpVqwL+XuaMR7ysWPEcCIsCvDRJ9U0RLoUQWIwWJKnrvLlzPYJ4BVlxwrMIsSPi qIING9SXT5LWhIvgXYQSYUiJruCtmzRuBEs5eOBAVYXJrihT6vLl7dq0AcvEWoIhZJgO2fIk DnJ56Pm1ba/Cdnbu2Im0UcnZmTgZbv0AZONFV80U89t0yfnpDFEmJ6SD9u3bcf1TFKFqMG3o DbmHxKwYT0QFvVcaNfEWBq9SsfNMMmQUw4m9Wf26Uf4yCq+MmrVq1yarqakGuWH9Biq3NOna k2x8/ThfAV05wmTgVrs43ItOThrj/HnPPEMaW18sBDLf1qsjT/spD+i83mbNmCFTU7euUW8k /JLFZ2S/vmAS/GhemJ3xFLumpFwhg2/RokUvc8aT2hUpSAlesVx52zDYMcv2kbeOUNuwnxgc ATgegUBApgwDTtLTGFRgo6mp2M+mS+o7mqS48pLFi8u3aeNmyS+YL7/U1IhVSnBKJjYr/ORT UgOKbn/iscfJKM1syeS9kkIzlCUI9nr64fBhQ/2VcJrEK1tabfG3jTBUAnCJVJz6sUwApilR 4BKiiXFFmrAKRNCu3YapK3FG3bp09atr6caGR+IRxX169ZZkNrw2m668efJs2fKyXK6ygHk0 WDn1ekg8GjV0uASb4pjIbUH0+EfPAZ0zsP8AS0OZ0qVkE/NVOQcrl9mZPWumNcjKMmTQYJEZ AjU8ZqMG9a1fJJ7UzoI8BF65pEXLlhL+Ofhoss3FP3V2xgscd0VAjl3mjCcv+nPLlrEcEHFY TpSd1OLibiz79jlq7lj7baLwGIrv1bM3/VBouaXdvmh4DKSOFu+2bUNx+qqVq7ZqFSGbyTGp pnUrSK9gwYKRyDp1Cn+iYDOO1iWTtSHs3iNKV96vbx85p7Foz+7dataoKREtD4fErOqJlyhW nJa4bes2iE28JOxdks98efJaDkaNGvXE4483btzIMCSEJPEwHouFyKahQ4fRgXfu3GV7ZgXB xpLwYlTWlyaNGotdAlUjOYkgkRlgop6XJJRJmtosV6xtWMECBUl+T6rAyNKlz9oysP2SY0aL c+gyZUqXkb1X2maZKsUZCi+kJ9u7UoNpBzQFYVDuiJNZj9q0aknM6g3oVLSUxzd7xi+TvI3i 5bYBuXiWeH96yM54xB2hd4WXdPPNN1svE9673KYYKdOR6E5WcTF1NnUkwPoNG3x1nkyzq0G1 dkchpSSDJFMe6cQJwOgXWeTi2CI2TFXv4t4OImL9RKa/3XvYF0kbPUdugxMnXCjVioOouDYi PfLWGzsjNKb5YZthtECpLIohyTnepvup0SF1vN5wkZa4RVJkmzSWHssERlq1ehWZaTCYnPSL IKbHjslFaYemE4MJedfd2rVUSrfWf1zL6Di9kYWGePdePDg902aS0SXq8ODBuKzfgWich9/y q0+cJ+aE/wkLJMPDa2Ud4WkwFXL1unVczTxqSWzqwSDdSD+GZ0rDjLH6CunwK65Oavq9P8T6 YbpLFsbzpq666ip/I8aTzJxp7rJlvGBbT/xRiVcqOWC0nD49Y2uXnAzaUXioxHCf5WSYlHM3 S9pkX7pwvs1bq1atK1aoGDaZqb2lKhFZ5jal2RkJocP55Eapw07tOXUkyeSkOvdSM9CkdpLl eVMHnDEJmR7CZE6yDObDxBLvz7NkIZuE1yLGw3+0TRj/8CYuN4l37gkK/rdIvr2/nyj38/Hj FHVxQ2SCeSNC3wXe9f6OMH23y2EGUhkvldEixvMRrHnfffflUMYLw34nDOR/a/ZjKGQiyoKa +n6P4b/1bOl+L9kMpDJeqmqZwXgIiKWFvSXHSbxLNkPpjtIz8F+YgYTxmFEEnYeqmj6nGc8p 9pYs0ehn3aikT6ZnID0D72kGbEmYMJPd3BmM5wvrlp8lin1PnaYbp2cgPQPnmAGyDlvhvdQ2 pyVeOEvuPfLII1xAmDA9m+kZSM/AxcwAbrKvo2GmyrqsqmbqDYDI2Dldk2a/i5n39LUf5RmA Z7jxxhs56pJ93bkkXvIblnMNZx9rJ6OLvR8P7Ed5HtPPnp6Bc89A7FuabadGZ7zyyiuFH2RR L8+L8ZJGPA0MnsQl9lXqPv1Jz0B6Bs46A5REbILr8N5ZpVwq4/1/9BckHFTJneYAAAAASUVO RK5CYII= --------------020301080900060202040300 Content-Type: image/png; x-mac-type="0"; x-mac-creator="0"; name="visitenkarte.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="visitenkarte.png" iVBORw0KGgoAAAANSUhEUgAAASgAAACgCAIAAAAw8WZPAAAAAXNSR0IArs4c6QAAAARnQU1B AACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAA buNJREFUeF7t3Qe8FtXRP3CT901i2htTTVeTGE035Z+YZkxijFFjQcVKVXrvvffee6/Se+9I R0CahSqCgtJBQKTl/9099y4P9yIiEOXq83zwus8+Z8+ePTtzZs7Mb2Y+9p///OeKd/uMGTNm 5cqVWq1atWr//v3v1jz9e3oGPnIzcOWVV/7ud7/z2DfeeON9993n67tMAcZ7p8/s2bMfeeSR q666Skd14s/o0aOdTH/SM5CegSwzMHny5MAjWAbXYRnMcg7muuKsvz333HOuvPXWW59++ul9 +/ad4/r0T+kZSM9A9hnAdTjopptuwp9nnZ+zMB5mu/nmm8/Nr+m5Ts9AegbedQYIMNKLGMze MivjVa1alax866233rXTdIP0DKRn4HxmIOifWXjqDMbDdRqdOnXqZPqTnoH0DFyKGcBNmLNP nz40z1QuPc14NEx86bc0412KCU/3kZ6BaAYC4/k0adKEYEt4L4PxKKP2dUEaphkvTTLpGbhU M5AwHs4i2Ii3wHsZjJdq/bxgxsvk7XPovWkl9lK90HQ/OWMGUhlvx44d1157bRBvEeNxQdxx xx0Ju7wnxjtx4sTJEyeSa/fs2b1mzZrp06YPHzp02JAh/jmYOmUyifrGG28kzU6eyBmzlh5l egYucgZSGQ/9ly1btk2bNhmMh+vw3oUxXrhq586dkyZNatyoYY1q1apXq1anVq0G9eo1rFu3 ob/16tWrU6d61arVq1WvX6/+6FGjt219NVx1kY+Uvjw9A5f/DGRhvJdffpnQixiP4INNSbV1 no/EI+hsBl2/ffuOnj17li9XrmrlKhivaZMmXTt3fnrwoKlTpsyeNXvO7NnTp00bNnRoj27d WjRv3rhhw+pVq5cuWbpTx46bN28K7KerSGymP+kZ+DDOQBbGQ/CMKYsWLboiMWa+J4kXGGb0 qFHlypatVrVqy+YtunbpsnDBgtkzZo4bOzb7Jm/evGecX75sWa+ePTWuXatW2dKl+/fre/jw YY2PH08z3oeR6NLPlGLVTJgiIMuuCP9LZZVzSzwsovGunTsbN2pUsUKF5k2bDujf74Xnn8c8 zg8cMLBCuXKv79hhzhM5dvTo2y2bN2/YoMHxY8e12bhhw/BhQ1s0bVa1cuWaNWps2rgxrXam SfTDOgPZJV5Ak12RP39+3r3zZzwtX968mW5Zr27dNq3bLFiwYPOmTXv37Hb+hRdeaFCvfptW rVu1aJnwkoO5s+c4o/3gQQN9XfbssmeXLiX9Onbo0KhRw9IlSzr+b8i9YPi55IbU49aY4yfi 5enSKclRT8czPD5pj86HiAuzMx49k7Z5RRbLCgY4h8Tz6ytbtpQpXTrs5ba8vMWZwQMHkn57 du/R47/vvPPfd92FLZ0/cuTI4UOHHIwaOfLef//7zjvuaNWyha99+vRt3qz59te2b33llT69 e7do1qxYkaKB984x4cnSENqkPs/5X3VJXijGyzKYLF8v6C6RvvD228defOGFtWvWHHrzzfPZ aV/QjdIXva8zkJ3xgn3lCiDOLADqs77y2JryH5EKNnXNmzXr3Knj/v37aJj169WbMX0GY+bK 5cunTJ78VMGCRQsXLl60qM3bcyuemzljhqt6dutWMH/+J/PntxvkynDJvr372rZp88zcuW+8 /kbMe81Lliix5eWXw9Yxu63l2LHjSxYvNs6DBw8ans+xt48tXrSI8ebNN98860Rqc/To0WZN m+Z54vF169ZdQjrW1fLlyx95ODeJ/fbbb7u7UZHhe/fuveC7RPrC88/f8+9/f+H//u/zn//c nDlz0ur3+8of/7WbXSzjRULm5Ek806RxEzZJTNK5c+eXXnypdMlSFM6li5doMGHcuP59+w3q 379mjeq7du3EVBs2rHfjwQMGdOvSuX/v3jWrVX/z4MG9+/Y9u2RJm9athw8btmDe/Igze/Zs 3bKVHeORw4dTN4cZwu3kyTffPPSrm276whe+sHbN2iBe9u8/8LOf/vSLX/wipgpSOhB9+DU8 LSfHN77+dfGIvXr0SG2TCMxwSTI1CdtEfcVdht6yCFhnmjZpqtsfXn/9gQMHjr711r3/vucr X/7y2rXR2MJVZ3QV95X6ZrPcMQy+YIEC+rzt73+rVq3qhg0bLoyHQ1cXdu1/jfbesePsmsI7 jTx5rZdwkBc8S8mFyajO0VXyrpOHfW8Sz2Vjx4whslq3arV169Y1q1a3atmyc8eOc2bNInwi Ujt5EkNWrVK1ZvXq+fPmxZlUphnTp1PMGjdswOJSrXLlgvny7969J2KJN97ApdOnTp01c2bb 1m22b9/eoV077r4e3bpHhH6md+HUyVOHDh36xc9//vnPfU6fmYy3/yc//jH58NJLEeNl/3jg 48feHjt6NA5n7EkaBHF61kvCSfvC1F+1T7ZeCR/a5TZv3oKEj9ofP/HTn/7ks5/97OZYYqcS U1ATMroNojzlTJYx/PmPf/z85z+/efPm6PwF4dSzdHjBhBUT9wljiN7FRXzi53jHLXagyH37 9x858lbGHTMfIPWeYcYgLvbu3Xfs2LGLGE7GpfFDnX6lnvQ99RnGGAZ//Ngxo0rOvJPmleW9 nC/jRZR36hQzZrkyZVq1aLFkyeIN69e3b9vu9dffGDVixBtv7Iyf5MT+ffuKFylSqkSJ8mXL 3H7bbfx4M6ZNw0779u3Ndd99LCj8B84vmB+JuPBZtHDRYw8/XKRQ4SOHDlO0WjVv7vL16zdk ed/uTnH91S9vuuqqLwSp4rP/wIGf/exnX/rSlzZu2Lh39+4qVau0bNmCCM11/3333ntP/379 XMU52aN791q1a7GjEstFixV1d+dPHD9OSyxUqBDLELZp367dnf/61x3//CdPo02pBtOmTS1W tOjAAf1LlSzlV2cGDhjwQK5ct/7lFiYi82u0NarXGPL009aXEiVKkKsUxNy5czdu0mTcuHGF Cxfu0rmLnr2fiRMnPvXUU8xXpihsDnfseB2Q4K4777rvnnt5Vg4dPvzKK6+UKF7i29/+1he+ 8H+PPfaYTa+Rv1e20X79uvXlypUrUqRI2TJlFi9afDFsE+xSR986+p6IMkvjt98+ijTfiRxx Ea/Sr3716+B/Mn6zWqVKlddefTXLuvP6668/kvvhv9zyl02bIt/vxQzJteSEV/PSSy8VLVLE HSN6OG/W03j1qlVVqlTdtXMX/rnrzjvZJ+2ngEN2vrHzrK/swiVeWHL43+rWrt2zRw/W/0kT Jgzo15/EM61+Oha74Xbv2tm+bZsmjRsVL1KU0Js0aSK6rFK58p7du/kMKlUoX71K5SqVKs5N 2b34SbfPPbdy8qRJWzZvfnrQ4LatW9uVvSfG44hH/V/60hc/9alPfe5zn/vaV79KYSMJly5Z ao/32//3/3y1GwQMd/DUk0/pnF3nq1/56qc++ckVK1bQb50nTn/60586sINFA40bN3aMl/wl 5Ht07/Hxj30Md/36l78qXqyYHkYMH+Gnf99993MrVlxzzTWf/cxn3Vr7W//ylzGjR/vp61// OsuTSb/9H7f72r170HVPbtu69ZY//9mZL171RQNwULRoUUP97ne+S2aSeKT67f/4x6HDkVHq PVGY9rNmzvrSF7/YpHHjMqVKXfPda6ZNm5Zlrc0i6rN8zUIiDerXDyr6WT/n1hpcsn79+rxP PHFg//7kQbL0w/b2veuus0JFciymMWTg8VetXJml5cL5C0y+peTc488+zuxEbzdeIF++l154 ccf2HTVq1CRCAg4k++esklCzMaNGf/5zn31126vWi+98+9tbt24bOWK4YdsdnPWVXTjjedp9 e/dWrVyJL47DAJXXrlmT6HtlyytBbQsikfb49KBBxYoUQXwMJ+PHje3SqXPRwkU2b9zUskWL B+6/P+/jjzdt1IhBJfVNWOybN23WsWOHl1560Z6Q2aZyxYpbtkTG0sTEgmAPHz70q1/+8qpo j5epah7YHyQe3WzrK1u9wv/5n//B2mYk1/33h30dLedvf/3rlZ/6FPfFiuXLceP1P/gByCjx 9bGPfezRRx5hSkXuv/rVr55fu3b5s8u+/73vfeMb39i9a1e7tm01+OY3vwlzQw0mD3XYrGmz iHliNZXW/Yn//d+HHngAb6Own//sZ/afkDomgXB2U+179+q9Yd26r3z5K9ddey0pF15tgwYN /PTYo4/ywcycMfNb3/qmUS1auNBk/u63/w83mh/KxQVAeXTuWur3ju2vOc6fL999993rYNu2 baR0o0aNyA2moA4dOljsKlWsNH78eL+aPQxWoWLFCRMmWEb7+/Tt1759+759+qD13/z611On Th0zekzXLl3r16/ft29feweT7EldK+1VyxYtrarI9403XgdB7Na1K5EFR/HG66+b3s9+5jPl ypazGw+i4PChw927dStXrvzokSMJ/0YNG331K1955OFHwoZWhzOmT0PKq1etHjpsWLeu3WrX qt2nV6+XN7/M4/W1r32NimFuF8xfULlSJauz9/j2sbcZGgy1d+/e8+fPN+zWrVozmLOu165d u3//fnQMQrJevegBJ0+afOjNQ7ZCn/70p5944gnaVvfu3V/dts19bRkqVKjYuWMncqxbNMJy NlCJjhxeXLJDmThhwnXXXkOhe+CBB1CLm9Kzvvud79h9XGLGi5aiyZOrVanct3dvE2pZmj9v Xs/uPRgVkiXZxBFfdWvXKl2iBN4rWCA/bHTtGjWeeOzxhfPnFy1cqFTxElTNxx99ZN68eanj 8wLwkvfXrk1b74+QbNywkYmM22RoAIHxfnnTTV+86iq6QZiIAwcO/uynP2Nc2bRxE7fEtddc 861vfSvMY4Xy5RE3kJq3/feY8RZRKU+cuOOfd2AnXPf44499/OMfR08jRowgJ6+++ms/+P73 se6nr7ySyFm/bl37du31QNsM96pZvYavhEm+vHkxcMJ4D+bK5cEt2L/+1a8w3sYYCeDTqVMn 7b1dmqQDil+w1Wh5+23/+N///d+pk6eElsyYH7viiqcHD3Z8y5//5BZWorO+v3eVfq7CeD/+ 0Y3r173k2GMa1fbXXnvwgQdKly6NDRhvmIK+fvXX/3LLn8uXL2/GVj73HDpmMKtUsSLSIf// 9te/0R2KFyuKmH584423/f3v3pdrv//97wPhMiA98fjjjzz88E0///mePXtoB48/9pjO/3n7 7XT4z332s3nz5OFM+v3NN1tWSpUs8fWvX61zQsbg0bHjm37xi2rVql1//fVDhwxF93g7f778 mD+T8aYbxuqVq+jhN97ww6pVqnztq18Z0H+A4V199dWYbf78BT/+0Y95s/7+178ZCRv7d77z bbxqOaMrff6zn9X5jTfeYCbDJYTkvGeeiVaW+Hk5kO1Hrv7a14x85IgRX/7SlxYvXITrvPpy 5cv36dW7Vo2aP/3xT9q2aQvnGI04/jAH7tu7J1CjiaXu6Wr2rJkF8hf49je/2aNHjxGB8V6+ 1IxnUlq2bNmsSZNpU6fOnjWrQL78hZ58avOm6DanF+Z4E2jBo4K21rhp0+FDhloL8z6RZ+6c udAtlhOYsjq1a82de4ahXCe4ZdCAAVga3VAz3Kh+3bpvHz29u4j2eIcOeWfUuUQPsdx+77rv mcRXXtmC8a757ncxD1+iDpECcqcVZzDelVdivIgfOnZ03j7zuuuuu/GHN9iU2gqSk7RBK6tF vXevXkOGDLEussdoSVC4yt2ZdpiUCEYnTTrl3rJH4sWM58W8GUnjq64KyoYP6f31q6/+7ne/ S9H9zGc+E7TrsOdElJ/8xCdmTJseWt59190f//jHRg4fbtfxpz/+0TpCfl4s470UMR440c2/ +x3z1be+8Y3q1asRgN/51rc2rN/wk5/8JISE/b9f/waxejSbAjveb3/725jtnnvuKVuGsh19 /n3nXcC3DpB4sVjBxsl2sLSeG274oZf1oxtvLFKoEBFHsg0aOJA2sW7dehTyg+99nwCc/8w8 rLt7d4SsoBQdPHDA5W7kq/UrX958NpA//clPpkyaFJ7XX+IUBa9ZvcpiUalSJWd+8Yufe4/0 +R//6Edert3NH3//B+fnzpn9/eu+x8LHrNWhfdRnty5db/7dzQ6KFStaqlQpBz/76U+s4wcP HJw0cSK59K1vftMBU/uNN9yw6rmVa9aspoksXby4QH6mwLzhkd3rB9ddZ80KLOeVEQx5Hn+c HiHsJrTBeFh9x47t48aOY2nXDDE4c4kZz51wfO1aNQkBhIXErZED+/c/cvjIGVvJmPEG9OvH X3fLH/8oIqFVq1b0GS9m5PARsNF33XFH7vvvb1Cv7jPPnFY1g5pK139m9pxXX3112bPP2gKx x9SqWdNXUiJZ5smKe/59D7q3CmK5I2+9xQNBdPzpD384fPgI1RTjURR37dplwKVLl4kYr3v3 LIxHInmvn/zkJzEbQ5GWtsX/8z8f/8Pv/0DHCNO6d89ef1u1aqkHARaBJmgsDvCbd+a8NXLK pMmB8fhYvFpbxM9+9jMzZ8586+hRQ/VQeZ54gnS1M7zlT382gYm1wDvWAxsS4TNr1syvfvWr FNpNmzYee/voJWG8SNWMTbhUuHz58nF+WpuEokTaY9++r732Ggq2uGjw29/8Bh0XLlS40FOF xo8bT6ZhvHvvucci69djb79929/+1qhBzHiPPVayZElbod/+9rd0H4IRw8yZNfuGH/7Q47Rr 165bt+5Urx9eHzEeje5HN9zw+o7tkyZOuuGH16OKTMY7aHnq1DFikvzYLm9eKr3BkDxZGG/t mtUYj2LpjtScXj17zJ8/z8xDbjA7sf1qz8/pdbNzSOM1NrbNWDdN4FtH3ipSuIi1wBnXDh40 GF8xoowbN55YmzB+PDObBZqoF7x23XXXLlm0mJvXJ7x9HwqdJZ5QDZYwBGrPXLBgweBAThiP Yd80/uJnP7eg6Pa/wnicdZUqVOzfty/RRJR5+LlxxrIzlJ9Tp6KtUes2jz/yCFNPoSefZLKz DbUXomHmfeLx+++55+EHHyhVongWVRNOSle8eeXLlitbqvTLmzaNGDacO962J7lFsO7QDEkP VGtl/fGPf+yAAAxKmhWBpkcR4rjz9amnCvm1U4cOGA95OZ4XbywjGnr8CV/pmfNj/yEevuvO aP/2zW9886+33oqSbM8MqWmTyLjCrBKuMvV/+P3v//ynPzn585/93F2gwx3f8c/bI9Pf0bf/ cdttvtqxMI1SuV1Cif30p690I8SdPIiDCRMm2ohrHGm2n/50tHVsEhmT7F5wL15lbcs6t++q ZcYNXEXaXPWF/6tRowat8qc/+TGf/ltHjtx9513snLiOZ4V8u+GGG/51xx3aWIOsoZ733nvv bdSwodEOHjTI17qxnCeBWYft8ZYsWfLQgw8SmJw6P/zh9XCGzlAR1730Em7MlStXv379vYXF ixfT3J5f+/zY0WO+8bWrX3t1m/0IzblunXp8sJH0OHnKevrLm36h/x98/3vDhgy1xuknvMEw /kzjynN01zKly7iEUIpcVnNm2w6w6onq5DtlD/vHP/7x8MMP79u3n6pJrLmWfmg5sI1kFi5e vDgWcS0VhsXBIBs2aGjHMWrkKHa1a7/73WJFi8nR/OUvfXHJokVI9Jvf+EaFCuXJTLLOpvHv f/ubBciON4iWQAPJMaqmVFvr+/Xrd813vst6BJjlzMZNZ4ccX6BxxS3ZAJh9Md7G9etNk72s dTSb5fTU3j17atWoQdvs368/QUdjHD923LgxY7t37fbEo4/16tnLDpjUpnNnIayYc9bPmTnr 1a1bEcrkiROrValii5jaLIwe7z36yKM0qN/f/DtK7MQJE6MZOXmS6YLW7n1gJC3tCiypqJCk kujCcsXOHhlFTv0H0gUNiRikT4Y+Ga8xmLn+/e9+h23sNo8fP0am5c2Td9SokWHSeRSQoAW1 RPHiwYPPKmMppQVYF/XDfkhJ++Mf/mBxpXlqsPWVLV48gYYWkwcJkpPZ84FcD+jt3nvu7dun L/Jykt7VsH59BEFeZZvb8+O8k6dsd2vWqFmmTBnvi0IY6AWJoHVCb8yoUXjg5z//ueelyJFv brRi+YqKFSsxhjVv3gwcp1evXjNmzAz384y2RowrWo6MzSFt2rTlzrELbdq0KdXLbNNrSpcq jb6Z3CxPFDANoAvsAL3KLp0716hZ004s2SzR9umBQ4cMiZTPgwebNWuGl8Lz+mvRsR/zRiwT 4ydMwPyWLZYSYkqfNiMeiOOX8QPgnvT2pnhTV65cpQOLSPv2Hdgdhg0bzt5o9SS6Vz5na7Ky YsWK7dq2a9q0mS+nTp4YNmxo5cqV586d26RJ02ARwUulSpVs2aI5FjJ7xhC2nYnCmbxBJ9nh 2Jm4o5cvX4ZaQD4YKfiHdu7cddYXd+GMN2rkCM9pO2TG+/XpQzcI+JIsH9qzrVqgVK+qZ4/u S5csYSgfO2Yswg3nWVCQfhbGMzKq4+yZszp16EiVJbgtwEwj2ZuFTuyUCJlwHCGLjx9PlqXw Nfzk48WEg6AuZsdYnnFh7BqJrzrt9c6Yej6tlMspk4Fb4saZ3Ub++miNDOexPVMNs0TcQ4aV KBpqpgNdJ8k4Q4vw9UK57mTq06VOTnIXB5Re3kJrfGaD03OV2syDhDiSM06mTGY0pbGqknxQ aXwy4yniB8qYRi/Fw3oXqSSYiiXIJKSM9kmz5InCGV1mecbk/SYHJzIHGRxd2T/ZZyk1f0Jq e2/8bAve6YfKmMNMensnxPyFM97oUSObNGw4aOCANatXYyFCL9ipsjLe668PHjjA4rRg3ryh Q4dWLF/e1q5e3ToWcraKFcuWPb92DRGRnfEisjtxgnmDJ501zBJr09+hfcSrZ9wiepWR3yKF QDOwIGG9DCQb+zair5nH0fnIG5wZphS3cybTaXoiK946/JTKAKk3DbfMaKCnTIdK8s7sdkDG f/Ob3/zPxz8ePGkp98q4NpXlkmdMHuFs7/t8zp3hBs4YZ+QGP33ezpxxclkmHj1pk9F7ZsvM Z8zwFWUAieKOwin/S+YhzHP0Y+bf1DPJcWr7cDJz6s71aPFbzHiEjDd4+sKMyYxXtvCM8WsO RynPknqD0/fNPJs8Vvxc5+tKT52qcNMwK9kf5mIYb0STBg1sABg/+vbuQ1PasX171oX51Enb 6B7du61du2bJ4iV0D1av4sWK534oN92M089+w1aYNynVgR5GqSsrIhvM1MmT165ebXfets3Z GO98aO+cbc4hTM4qbcKUZZ+45GTWu8XtOSHs3Ig7bqjwdBc98EvWQdhRx+p5+vM+zcDFMN4o sqtf374vb9o8fOgwaiToY3Z6YlRo3KD++LFjJk2YaBNFarEWCH+gNDLiUbvpkFx8z8zNsseL hJgOqZqCD2wbJowf53bAIqkSL2gyWT6xKHv3JSqs08m1Z7kkFqRZnyhDrGUsDUGlJCoTXora x4tw6gt0jl4wfuzYZUuXXjzW8ZKTRliUz2fSLvmtP7IdXjjjzZo1i0fO7o6Jn1zCVCReNhTv qZ2vvzH06aeZJWV5GD9u3HPPrWCoFezHz8bzvmTxInFmAVR9pg4ZEf3uXbsF+DVt3Hj5smep alUqVZaeLGmGUN566whQKLACRJx/0f9ff8NW0xJ+Pm/Utg0yo0XzFnrI3p6tr3jRYpCWYJ8Z N7UTO3Vq5vTpDRvU50WwdWbCejh3boYZXgoGJCsFW47gpuyyI3V1OJ+xpdt8uGfgwhnvpRdf tGGjZLKckntVK1WGLcimap7avXNnm9atGJHZLZk07QnFH4wYPnzqlEnMaM/MmQPCUrlChSyq Jqai+SyYP09L1iHBdazD3AlgRwnjOXj22We5azm+v/+979/wwxt++hPW8p+wPmfdB57tHWoD z816TgPs0L79GZfEu8ED+w/w7TA3c9QGPSwe1X969+x19113Pf/883//298pzLkffIiVuU2r Vjf/9ndQS4zXwXvx4aab9NNd5AxcIOPZtRAIsGAd2rWN4NETJ/bt1WvksGEg3ll4jx8PQgUQ wVatXp3anTq0nzVj+qwZM8SniwmaOmnStMmTy5YqlYrVjLekkcmLnXfixEmECfNuuzZtuCX4 W1IZD1CLP5S/FSry+ut/wOuNi8ZPiNCG4RPUp3DM4JYchzMEJgt7rvtzrVq5KiiHqXKJD5SR nRvQEpN6vl+fvgBQrOr/uO0f856ZB3ixcOHC3j17Yjnu6V/8/BfBX3+RLyZ9+Yd7Bi6Q8QKN Mkvy0tDWGC25E3r16EmyZaE5+h/n2/wFCwYNGkQWsX/CxYEOtG/Tlpth3JgxrNhdO3cJ+Npk rh2/+MKLTRs3nT59OifysqXPRpCxevXejhDrGa0i5nz7bcIQcAyUjDMN1/3zn/90hhWUX5GM 1fTwkUP82pHR9QDZvA+wYMaM6Ry7RiKGCMNjpNdf3xFQzgsWzHeeXxV4JUBPOHO576iRTViA ZkcgL+VvwRpvu+22alWr0YS5vAsXKgTnTYCDlYJZ7ty1K0H0fbipJ/10FzwDF8V406dOg9Vi q+QlB03gN0wiwRMRQeJhMHEMUPDQJ3yRi+3rnn8eAA9Kk1bmQxcNEi/1s2fvXszTulVLTmeQ P7Z4PsNEiMVSMXrqcAlNVYwCkMRS1ov//IfqG8D+jnfv3oU3YAi2bttmt/blL38ZWpIL+9NX fgrAh5aoZfC589sKSvDVBzrp0KHDv/zlLwU6XHvtNeGk2KJFcTwbvzAMDe824QZ8LNo92l/u 3MlRy88bocMu+IWkL/xozMCFM575sQsSWQdrv3DBQqSPjnUnxiR8jsrRc+zY9ldf4zSHwo/5 oQ/XeWAVYTUCTMMxYRLhvk+eDFfF/44GnyZLyboXX6SsVixfAWIzizh1iX7hG/9yyy0YI8lH OGDAAF/hVLS3KED04UlGIJLQpg4CS0YZ64ULBSx+/H8+PmvGTKoj5gTvgquIIi3mz+eWxHga 61zyeVApfYK8ZFkgsn+9rFwFHw0yznlPeeGMFywNZAvjXpVKlbgHunfp2kUIXdu2Hdu3jw/a AUbyH1SqUKFzhw7du3QRU2eb17VTpy6dOrVs1kxcpgP/BA3Vr1vHgWtdqLEDpk6XQ8oBKHVo 115wQ3auCxIPCAhL/O63v2MFDWwwcOBAZ4SWOBa7ASKMozIZ79uEHkSSn/D2vffe94lPfILH AtzUJaVKlEwYiWYKF0sGBldHk0YRUDOEJuS895we8WU2AxfOeIHoyROM0axxYzF1AszBncFZ alStWrJYcdgUdsiSJYqTV+wiUoxxxLVo1hSXVqxQ3p4NrlrqB9wovV+F8uVEo8vCAjztwJap fNmyMtuKCxbhDvgXAo5SZy+IRKBHGHAIY3HWCc9AtWKSggUKOmNrx/KZMJ4wEPbPkOKFQBYV ivHIW+nMXAKV5nyYFPKQpcSFIdhPUJIGHirNeJcZDefI4VwU4wXeY9IUEsrMwJjO9gjNLEpN zPi0KVMdkCQTxk9wnsSgjjKW3HfPPYLBxRAJNxRiSLUTAFq3Th0ijspXl+WzY0cxfngAZzYS zFi/PvuHG2X18J44CZ4pegM/PFmwIMuJVWDXrt3YyW7QSeGYrqI3iuYWBRMkHsZjBQ3xYIHx /vcT/wtC2bB+FAPONBJyfjLb4NjAeHzfacbLkdR9GQ/6Yhkv5r1TjRs1Jgrq1a3HrMevBRVF HEWwzMaN+bKLFC4s8teBXH033nCj8BPmeDEX4tA3btwApSnEi+4HPoYnwcapdrff9neARior BmYtlEkhOx4FMzCifupTnxRl873rrrWRu1702HXXiR9l5Rdf97Uog8DDbiTQTiiKZAc8H1/5 ylfiCL0Mxrvrrjvxm+Xg2aXP/t///Z9jO7q77767RrXqkaj88Y9lTAlRtqJX/Er8piXeZUzP OWZol4DxdCHEA2JDkIHkFrAsQoDhbhkwJ44bB8zRo2vXIYMHyXriQIRbrH+W+MY3vl63Vi0h RXJptmjalK+MRte+TRueCciPAX37yWUiaqNkyRJCE95pd4dp+bgF2tA2JbqQSuhrX/uquFtG mqJFikoJwV5SoEAB2YfkPhAwwhopPYGgSRKPNkniiQoVqC+oxC369O4jJyet9cpPXVmyRMk3 3zwoQwTx+EKcwkyGGFbNd9pq5pgXnh7o5TEDl4DxgpWFIle2dJnmzZsjX3Aqhkr1Ejq1b1+m ZKmunbrI605vnD51CiVT2pnyZcpiBtksbJzq162HY/3jKO/TsydoGBu9/EhqLURxbjHRv9Nc SQYvLdTpj+Pt2wW5eCoBLMRvCKySzUGzYGt9fcfrYGU0yeNxrBAOZF8NAU1hy2ozKdAJPEAM DCeBzjkJPCNbi2eEGk1jGi8P0s3Zo7gEjBcmIOK9ba8KJcRLHHpt2rQWB2R3JIpRRL1/XNJQ woKgBQLLsCBHC1w1kWV/JcUFBJYNGKEnmR+/vA2eXNROnluvS6wpWQ7CeLJ8AuI5nEwc3Emb yDNxZs3opJPgHkhtmbPfeXr0l8EMXDLGC2HUZAtZx1ApE96A/v1BsZIb0DzlgChfpsyTBQqo RpLniTyMnPIOLJgXGet95JKQb4cuV61K1Tq1a2/bGqUGuwymKD2E9Axc+hm4ZIyXyD3cItIH DlNFBF4v6BNGS0Dn3Xv2+NuwXv0QF8MKKlWE8jcRimXaNJ43fMiAoaIQeFeI/730j5vuMT0D l8cMXGLGS0DJ9k7SYJJd0kKxpjSoX89XyWSLFy0yacL4qZMnVShXntuAVGzauBEHoH8ay/YX cmCmue7yII/0KP5bM3CJGc8wQxR9YB6aJy8f/zhnQ/Wq1TgY+MS5B2r4r3JlTvOqVSqrSaIc lwwuIuoyWC4leP+/9dzpftMz8IHOwKVnvNTHSQwSUJ2SK4p2le5TZJ0SsIIS4EXomcrHnbZb XE4JET7Q95K++Yd8Bv67jJeksnkn82OmiEvnHfiQ01n68bLMwH+X8dLTnZ6B9AycdQbSjJcm jPQMfAAzkGa8D2DS07dMz0Ca8dI0kJ6BD2AGPpKMF2w+mZ/zmfX31PhdO0y9eXbkZzgTRWOk ZD4+V5+Z+Zsv7SDf9SnSDS5mBnI242VHY57PXCDULBe+61WXFqgZYOXJJwvvqScQygBHjBRV s36XD7R3AjJVGyCN4X63Cbssfs/BjGfoEpCJJFDDxUeKlMT/fu5k95oJVgLR7tipk7ydIhIC DPqdPn5dvWZNz569xDGcu+V5vlIDWLN6jVwZ3bt1X71qZZY+fVVnr3jxElteeeW8bnfqpIrN hvf88y8YQMoacbqkxHkOLN3sfZuBHMx4KEwAqwKOii0LxpPWUshcVAg6qFyZJXgcJEIgZIuQ 4EwyCFnJfvXrX//gB98XOBsQaoFkIx0vviTjZCxNVFFWhW9BnE43yKLkwHGYxDNOuntSR+WM WhnRANSjEkAo0k8JVaWJw02TSkO+CtuXSDcpc5tUPgoqaBhYUnbHVxVdRB7iPceyYsvYLWGh XqU5DWWHo/7T4IT3javO40Y5m/EmTpz46U9/pkOHjmKO7vxXVEoS9jr1kYjBKNleZmklxA0L qoghupdmQq22lzdvUhA8cNHevXtCEuhUPsSD5OquXTvXrn1exs5Enkj+Jy1nKr85Vv8tFLIy 87hFbbTdu/YEvTF5F9JVSMJ7y5/+BCAu6yGJnSDsDr75piSBcoS2adNGVC9MuQhj5cdSxyMD m7sEXtW/TG6ORQkKXAxh9YraWVNCugqRh4Lyk6Lt50EP6Sbv0wzkbMZTAfiqL1wV6qdLMi0a XeoHRRQ6deoo64TUg+o0pJZN10w9a/wp5C9hIQc4UCDS9773vWu+e43KktgMyrRixQq9evZU JlL6sxUrlovKFeCLGYoUKdy9e/e//vWvxKZKLC6H9q5Vq5a6hJLJ537oIdyC4nPdd79q7IqD Fi9WLMTmxlLq5JEjb/38pz8V6r569ZrTYvP48c6dOunwW9/6drkypQ3v61+7OveDD6ru4kYy d5LkkkpJhJEvTx55QQUZlyhWTP4YgcUwd5s2bVLYUZZeqXu///3vKT4uf+GggYOUQZUlTVpR 9d+tGmmZ9z5x1Xnc5sPAeKHcHBnw6KOPUgiVDZMB6ZOf/MQd/7yjR48eGC8p3aORDLyf/MQn 1CVPpJCDfn37OVm3Tl3JNr/whf+rXKmiSPZrr/nu16++WtXyBfPnhwy5KJtodfBArlwSY197 zTWqr7BnPPrIw5/8xCeFIFavVv3jH/+YMoCkaL06dWfOnKXqqqroI4ZnVPQOeqngep1IAwMr HmSsYoNXfvJTTxV8UuXuaVOnafCpT35SNaUuXbpKgla7dm3Z5tVzJ6uxk+f62BVXVK9eQ5Jf Bd+HDx9uYPJ/eljppG6++feSO+XJk2fK5CmVKlV2F0XGW7RoIaY+bXc5D454n5p8mBjvP2qs KyA+/5l5aj5ffbWK25EOqSxoQnC+ivdD06rUZzBeJAVOPProI6ovBKVOaW+UunHDevJHnukg lDCeXCxKN6qy4kCKNCextxzvbx48IKyesMWBG+NkSnZofnVepRZK41VXXdWkcZQGNxJ48Rpw 7NjbzCo33vBD7KcT8vbJgk/qYf++DLy4pGxqNrwYB+Cr7S6HmtxnNrHKEjnTrl27r3z5SwKv rA62uPICW2vcpWfPnn4lLV3L2uRY9hqrg7ymqXd/nygrfZtzzsCHgfGYWBAWmlZ73gIvhYQg 9x/dcOOBffsz9MlTGVusQJfIXXhuJCIzjSKqnP/5z3+Wy8zJwk899aMf3Sj3EsZTuzyD8fr1 y2S8ufKOKccZGO+mm26SEwnj/eRHP4qDel/A8HL4CryQRRffyu1px2XnmZB+YoORWub+++77 8he/+NILL+bO/fBvf/tbwjncDuMRtspq40kGmEJPPRUYz4LiV0kTv/XNb0iJv2nTxm9945tN mzSWoA3jqVTuV1U+pc1evSra48ntfc13viNxcHjYNC9cPjPwYWC8efPmI6xhQ4dR6iRaJ0/y 5817w/U/3LN7DyqP0hYpdRJ/NGPHJxBQuaRjEY3LOX/0aJlSpSXefHnzywTSH/7w+7/+9dZX trwsXyCKPyvjqeXgvLydzCSB8X584402cljl61+/WqVbumgkA48fW7Vq5Re/+MWmKRLPSfUk QreyHhqMjEw1alT/3Oc+F1JWR4zXurXx2E8eOXLkhz+8PmE8i4JfW7Vs+c1vfF0WpsB4zZo2 SWU8aRaxuiVAyy1btmhQpnSa8S4fjssYSc5mPDsi4uuvf/ubRJ0sCtgAsSK4B+6//+qvfVUq aHn7ZNGcOmVqEDiB94TCf+ELX7jh+uvt3277+9+nTJqocAIr4q9/9evb/n7b5z73WXwlv5hU gY89+kjgBNYUN1q0cFHY49kKOkmgsce4S+7cD3FoOOAAkM+ziZj6GjVtGnPlyvWnP/5R+9o1 a4YBUDTfOnpU1m2bwwceeMBmjFDl+mCTNE7M9uCDD1WrUkXCqOBOOHT4kAd5/NFHidNvf/tb IUVvwwYNlHRWHWXd+nWf+fSnpfpUJ8xdOnXqHD1dr16Ob/nzLSqHSvL7y5t+oe6KwkZvvnno sqO+j/CAcjDjRX7t1avLly//1JNP2iMxLXJhoTx03LdvX5aSw4cPod1ixUvIlptpVMwogrdk yRKZJvLlzVumTJmQoX3pkiWly5QhWzjBfN2/b7/k1gMHDoom6NSpRYsWlStXzsZJ/s9y5crL FoOJevfu3ahRY0qgBBb16tU/fOiwnLlVqlRRBkwy3BbNmxmXHNgMnqHPsMezFRQK7KcCBQr2 6N6dwyNTFK9ma3niiTzdu3aTSLtq1ap6s+1knlGDRQJCObVlpqEvsr5UrVKN319hzWrVqqki ZmDlK1ScN3++rrgWWrVspX9Zfd1UGaZiRYs1atgoLpT77jiYjzAvvK+PnoMZLwvwKoim4DtP jsNBIu7iqWVXzJr8L0tXiWxMlZOOQ82jjM5jX3y4Y3KQfTazDCD49pOTKWPOejK6XVzMPdtd Mu6LiVNulzGwgBA4PciUeyWmnfeVvtI3e4cZyMGM54kCICP5JM8YzoSv72RUOPdVSedJJ6kd huPkLllud8avmbfJMv/Z736Wx3mHu5zrdpmPnPrUqe3TjHCZzEDOZrzMScyE88d5ls49s7Ek OXviwFAUNsiZiA1SOzpxdgY+U5ZGl4QJvbC3G+RbKt8GGXthvSVXpfYQS9ywZFxst9lHFeT5 eRpPo3m+yAfLyZfnYMYLalXMJxnFzVNddmd9KciCnVAi97MSDaZl6oTw0HOis6WSLzY4gxmh yQ4dCkBKn5DS9+jRt0DMLmA3hR/Azdhgjx59O1Bwklz0+LsFKZxDpgW7bpZBBlY0d5eWdJN5 i5Ljv8MKmDHUeInxXJd2ADmotxzMeIYu/bsqPw5e27Zt5MiRGStuCj1loUgvm9Fvfpy7OnlJ QcI4M3bM2LJlynAqRILr5MlevXoqmB54+9CbB2vWqLEmNpkmOiFoJQxXEhWhKkP//v1nz5rZ qWOnpNlZNcwst05t075t29WrVrmcfaV69erlyparUaPmwhicfVaqSgafNIjQ1plNiTWrABvp nrgsWXhMZiR2I3lMzd5Zx5mI3NN3jKYoQ7s++zD8GkmwE6Bt3bt1MxWhWap+Hs6E/ScLsLLy qswT6HGb00tA/MoybhIdXerV4TJhzhzMeN4fFOWwYcMcrF29mjkxxazwH2rMGV8zzQwd2rdX F8VPQeVKbcNEmdRIQQ4lixd/KNcDwavO38BTFy5MPvsP7GeHJD/DGX48BlI2RgX9UpvFq39W m0pQa8MnlSKV5gRDcRICUywSg+2Lz78AL5baONFmk5PPPPPMCy9EjrvsHzRdpnTpBPzN3aLP uXPnrl+/HtLgrFOUejI1BiI5HwaQxZATfuUyZUNOFqPs42FP5tv0yM8tXx6gQhmTQPU9ccac ZJmfy4RhLtUwcjbjATEHZti6ZUsokrx27RoHEF4onS9B4T4FjJT88ZxDnh4CzIXspPcM5G55 htKEhLT245l//ON2QOdDh4CJT1HzlLYtVrjIizFBk5PFihThxHPVwAEDXeK+Rw4dIiGbNWuu OBmfOAwXMSUdfdPGjV0yccIEjgTgSb3Fmt6pdevWqT0GWaLw2PbtO/r169+sWTM98+D79O7Z S4F1qLckGogDoGbNmkYCitm7V2+IcEU2ZSilD/MouESue9VdDB7MTb0xGG6xF9DhilhzpZBy XO2G91SBAkHi+bRs0Tx1+bBqqJ7rcaZMnkT2zJgxs0uXLk0aN546dVrTpk1HjBjBf6j8k3ir nj17jBo5yvysX7/hjTdeBwQ1FRz3oS6Np2ioEsaYsaIlxowZy5uiTevWrT2vmoRmHgZ9/Ljx O19/49FHHgHdduHE8RN4VlauWKGUd9u2bT2Xik5eh/cFgkPfBtCrV68e2PdpCXipqP4y6CeH M16PHhxxFDz0V6N6dZuZmjWqL126lMyZO2f22jWrVSnqipQ6d/YWoftR8MO5c8+cPiNQ4YRx 413F+6wi9IplyytUqICybRTDm27epInqYoMHDrRjaVCvXtu2bZC4gs9g1oLcSpUsaWnX26hR o/jxlPJbv2FDsaJFpk6Z3LJ5c5KTgrdi+Yry5crjk9Dh2tVrli97dvCgwfh/1apV4pjokGTm ooULJ0+ajDQXLlx0/733GXO8LpzikYO6tr/DLerAvPzylnJlyr7x+uuulX57wfwF4h6sC5gN 0UNI099g06wOHdp3oAh07NABt4wfPz7XffeFrMH4X83QLS9vCeuOvwL5pPQGDADIVtUMB5ol K8uDDzwAzlr4qULLly2/9S9/GTd2bNHCRejVVjRTQWxWr1YtWo969hTN6NdHcudetHixsocW l7x58ryyZYvGvKkrn1u5bcuWObNnqZgtOmnDunWtW7cSh4Eb8z7++I7XtoOzzZhuwO29Jrgf RUsVG9W5laVooUKehVj+UNpgcjrjdcc5EydN4j1HuC+9+MJDDzyABIXwwDELz1F+CCwLir9P r17oA61079o1YTyiaVG8fVK62RIuvGD9+nW+hl2HIipCSJX1e27Fii5xmQegUChKQkybIUOe dgv4LMoVE0uNaAe42r0wXpvWrYiRpwoWhFp+5OFH4mJjERR7z569cG21a9dRBX41aRzXW+cc VzJJjaTFixZFEql58xXLl6cwXjWi28Ixa0a0WACg7Nq5U6Q5BrMXjW8XgXKQOEf53j17H3zg wU6dO4uHsvRUqVgxCDq3c5UDXcHQIPqE8dxu7uzZvpooSb7bt2urHwjPRvUbOFmnZk2kryq9 Y8vX4oULYdAUuLeiQc84CbNqVmnXVA9fmzVpGuEQSpZc/uwy/JzQlqXNSzG2DRs2KBplzHTR EsWKLlqw0AriwmiJqV5j+fJloVvIoeHDhls+OnboGJaMJKLyMpBVl2YIOZ3xeii57sVs2bwZ HYPzI3cUbBexbdurVStXUbeoV4+ezZs2xVpjRo/REouKQI/kXUQoTYT8OOjTp09c46Hl889H dTAD4ylstH7dOu3xtj5Rw/Rp05FmYDzhORivdu1aGI8hVJsMxpscM17/ARaC5cuXr1m7lh2V ukipU5hFvomhQ4ay06xa+Zy7h1tPGDcOPwcLCjVvxbJlWRiPNJg5Yzp5VblSZbqfZPj169XT Zt/+/YSneHYYmvnz52G8fHnzzJkzd8WKFQBlFcqWjRjv1KmK5cqJMAyP3LF9h4DwDh86ZFC8 RTnFjNeOVCf6LEmmgPoAc1eubFk6uQr1JDPgTq0aNaSrSBhPKv6pU6d4Cp24iq2rdMkStsTl SpdW/dNJJRCB4BYvXkJXN59DBj89bep0ANfiRYsuWbS4Tq1a2hi5NWXF8mUe31cQ9rHxy/Jy K5YvB/j24bOw5GzG69ShA7LzhtauXmWZP3L4kIrQY8eOmzNn9tZXtqrCZ9OCRqtbpNeuLVu2 7IwZM/55++30yUB2djIVCY2pU9lRtmx5GcosWBRjxjtRvUoVYT5UtVtvuQW5d+3WbdLESRiV MjZt2lS6mQiAu++6i/Ylao5eR1oWK1x4wrixlDEaoOKbtCb/mBDYcWzkShYvMWH8BMTtdkgz ADi7dOo8dtQosbyRfjVt2t9uvXXZ0qUx451EjuwiMN842bpgVJUrVcLSipm5+7atVLjZQn7b t21H4tE2d+/ehR/69+s/b94zIoawa/v27QcPHqTEvP1neK6tW7fBqhmzqaDaPfPMPHFStqYl ihWn1EGWkdgUh9o1a5gBxQynTJla+MknBUlAfs+bO4eSSQCSe+Da5u3BXLlEA5oiMln/BrZw wULMbxMrWMmiYAJ6dO9mxZk/f/6/77rTRprMr1O7Di0gz+OP7XzjdcqzXZyWdolUaOuXfhg8 Bw0Y4OmETRbMn4+4jhnvQ6Vy5mDG8yps53CUA+YTlISyrNYtmregpciqYLPEQgDfGCwco0aN FlBDY6RrhU0XKUT+MGYKnGOnmz17Djt4+IlWNnPGTK9cLDnCcvLZZ5996aV13j5SYyBhGGRI wIrdunbDdSLfhPkISF+37qUgEl2Ojok4VhDCSqcvvvCiMtQDBgw01Fdf3Yaw3IcNEwNoMHjg IMF77CUqchqAreabhw5ZGt4+dgxSFFc7iSXQqBxJrvUULVu2tDti15HsqEWLlhs2bIRWpTC3 atXKGYKCqta5c5cRw4YdOhhbjOJ93Yb1G8RGNW3SFOLUyfA4OjQDwiNog0L4bWbNgOAmSw8r CFMHcaeCvFgkthn9WCMYThTTtsS8tG4dY4n2Otm69ZWxY8dQHQ8ePEA7ZXbasH4dZcE4hw0d ynwiSNLwbJLhV60pONBusFu3bpCufsVqfBI0BTrLwAH9CUD7z2gVjLyCaca7NFruxfZyNhzj acRjlhUlC0IyZq0zai/7GsRgGFZG+0x3Q3J5oN3wyeKxSAFyngZwRs0yP8mFp3vIhJVmsdpn ONDjeyV3yfII2Xs7x5nEMJh9HlIGkzF7wcmS2jLJCpM5RWdBlqZ6F7Iv52cdW+pkJpdk91KE 7FUXSy6X2fU5W+JdZpOZHk56Bs53BnI244WlMDyDv/+NdfG8nEjvgOTM/hKMMAMReib67Hxf 17u1o6clYiQW25dOUMT5qoMwjKc6gqWE40QipaoM7zbSj/rvOZjxImTgsSi5nWc4cvhIAApe SlIL4XMAlJlozOzE4tY+4dbnRUoxgIad8xwpn0Of59XbmY3CTlL/zDkh7V8MXr2Ans5ySUaw VZxEmCE3mvaTMqYd0f2xY8cxYvxconwjS+alueWHupcczHgBlGxbz5gmHlQmr8R+EA4CBWec jMD4Z5yMfsgkkYTQkwszcsyePMkAGNIohJkKxJCx0mceMJ8wHjCuhPMZvUUwwwBFPM1FbJvA GdBtsgwi3+R2qaPN6OJsMUEBpZ3cInNIp/tnfhRcW6tWTaCZZc8uCyDIlIfKGH/2543Dfc/F 7R6Njy6a6qpVx4we/eqrrzVu2Ei0LjOmK3kO1LiHs6lZs4Zmad5710UjBzOeoUNISIk3e/Zs tjKZS84EQJ6BwwxaEBRI9l0+MRkLh+NhLlIrKyDFjRs2nC4WHRN+zF0Z3fCYAXIxq0iORBSk dp6p8sX6WCa78kZwasGy6DbcNwnbTa6dMGHCypUrU7six7MPO+PNRewSc2PMj107dwFzEboO xsUgmfJ2U0N44+CjTANSKmDVc51VdOtH5l9wNu51YLfXXnuVvZEbAGhG6he99ezenbN029at 7psYjd+V+D7KDXIw43nfDOuSWCZEiWgGDRhYpWrV3r37HH377aefHgLhIWPCqBEjYa840y3M cICcXc2aN2fdrlql6jPPzMUwjPi0MokkeAIgs6Smrle3Hm8SdPLokchr6759e1u0bFGrVm2+ JmEQfG4w+ERcseLF//WvO3E+vziQNN8G1JVkDbyCL7zwYrt27bnRIdpwV5hoRvmypcsEGyZX Ne+WA64tcrtJk6Zt2rR9Ye3zd999N+Al2z1HWeUqVYYNG+7K0aPHcJPobeTIUXXq1DVgcBl4 EYiZkLrChx+iQrnyQQ8MH+tRl85denTvsWPH6zzgnpcj0Ug4SPRPUXRrDhjhFJ4XkitSHUMs YmYPiYQ3G+pMJD0DAwG7hK98DOXKlnFt8utHmaPO89lzNuNhKlnDYrmBlE/xDpUvWxbFYwzw rkKFCtG7+HaLFi4Mc8hxDOj477vvHj92HLAvyCVvFXyTNZs/2n6Ok7pr5058g8CNWKhK5SpL Fi/hXwawhF8BziBDZKpdumQpkQKECc4CRgzvAh8t1R9S1icHF6xww/r1YankJuKnKl2ylFCA RMh07tTZ7dQ/AVXhsufyMmYAK5UPeL2xE5TzyBEjXFizeg1eNU5zmaQrV66M1qGN9UnMQoE8 PWhw6VIljYTHMkhX4+Gdc2DwHGikK6aSahrcxIVgJc57XoPx+Dz4ADe84YSYrE3AAIQYn57L 9cbDKdxB4plEVjds0PD5taejoghtqVy6du2q/arnVsLKOjBmrsjZs2afW2s9T9L8cDfL2YyH Vp59NgPn4cVDPwyPBSBHMEhHvbp16J8L5y/o1qWLkyWLF/NVPAHUv8zNI0cMf/Pgm+XLlFa9 AJoR40lSBPW7bNmzUBra8+pOmzKldq0oHK5i+fJJqAuEIfRJ7ty5582dC5gClmkSixQqTGpF AMW4aoIIicGDBgYEI7h9iPSJfcCRrLMdhbDhLyaCpkyZ0qFdO7gtTAuo7VeLBeCVWz/84EO2 jlKhLVq0MGStxYEtmjXXpnKFiuDaoGc4n8pK3YwYYOWqgOR6bfv2jh07YoaNGzcEMKSFwNLj oG+fvqCVXNjQBWRUtapVwFwAXPwEMSOeIEgt0ljaX0tA4EN/HYen8DW4+PbvP2AAAGh0yxAa 4om6dumapFT7cHPORT5dzmY82wxbi0TDGdCvX8h4CQMFMIUa1r30EjgFxsMMJYsVI5QwHigW /iRVYD6gojAevnLV9OnTevXoQRSgS19VCALdYE4gScqWKqWyl5PPrXgOdtGODriJXgrKGKCP gPwEkRgCE8qiiCKHPj0kpHZu0gT8MuCeMwwzjjEerVI8IY6dNjWKbNq2bWvZMmVF2UgyLawB OLNK5UrSh23dtk3RH1wEo+zXls1bIHxISLAsWiGciicNMwAUTrp6HMe2ZDHmez2hGo2hUSPA SAc0zxnTpoO/gNFE4M+KFa0drVtGz2t9oW068AjgY8IvILaC7HKSug5ikkx1OLCQlS9bThAQ /Tlgr23zwMqTh71I6vwQX56DGc+6Kw4I2M/mR6wXzSpCSxYtKmyMQkX+UNIYJKOok3btAK+e zJ9fcQ9qJ+Ai/oTWlTzTV0GiwJODBw/Ony+/JNBUTUod0rH8Q3VCZgLv2klWqlDRBgnErHSp UsTUww/lxqgLFiwsXqz42jVr8z2RBy4Z9kpyS4AskmrihImdOnTUj3BvgwkEjSswqruDO9tb zpg+TdkgLI3oGWkMHnga4llsgQgAjya2TVwfM73dncD5WKlr4MFJb2OzaxXWoDxQIHR/NS5S uPBo4Q6t2xCSJCSkuPNw4bZ/IP+lSpSkb7OFkI1AniJ94dGo3/aQ1atWE0aQdBVYK5C+kZtq wFGg6nHjxi1cYCzP2OtaDlh9NbMdtYKYeboAqGp84SXyY3xImS8HM17AFqlZ1a9fX2YMUdi+ KpwgqjJKanDq1Lxn5gpPhVoUFcZ2ggPZJ2logkRffPFFOx+bHNs8+5nVq1d16NCBGAQRtPvC J6QKsbNl88u6xRiWfVYNbZCySBlCxoZQYBty7NWrN7aBzHQM2ElRpPFKaiAsdeXKVZhEEKBq dcEHsHvXbtB7Ymfzps1GawtHAut8/vwFbdu2U3VMG/BuDYgOGE7PhVvkcdEJeKf+RXB7cBuz lSufAxPt06c3QRfkUtAAlyxaRFZ369ZVnmmTYz2KvJHHjsFG4gpD0obMpwaDU5PYrP8Vylc0 5kmTJodOEmZLpfloqnfvxmYqNwgFZGSKZmzYcA6MYJ59dslS97XrE5KX2s+HlHEu9rFyMOMl pJboP6mQwiABsvwUnjb5KRycFQOZ5WTYRGX/pE5flkQSoXEqyDO6XYqPQ6g7AcKtl9ptAhk9 Y/DvkMbi9NPFZBB4JvsgA7onOZ/l0UClGVTDr+dgmHMgRWP80BkOj3DmYmnzQ319zma8nPtq zLtNXefOnXfv2nlmIsH3+5nYReWcjtj2PME37/cAP5z3SzPeB/Zes8irD2QciWs+QtsdT8uo 9+8lpBnv/Zvr9J3SM5DMQJrx0sSQnoEPYAbSjPcBTHr6lukZSDNemgbSM/ABzECa8T6ASU/f Mj0DacZL00B6Bj6AGUgz3gcw6elbpmcgzXhpGkjPwAcwA2nG+wAmPX3L9AykGS9NA+kZ+ABm IM14H8Ckp2+ZnoEczHhxmscMMH5I7hhCb97rS4WZDLMQgIuOU+H277W3828f7hINOyOO4fSl IVDg3J8kniCjcQhNCBkv40+YkPiJMrJZJ8EZyU9JCEVSFDI1ju7MsImMyQkhF8ktUoeadBs1 eIfohIxHzoyWOOszhnGeT3xD8qbC857njL3b1L4fv+doxjsugaRMOwoehPcktDQqzfMeP+Lo JIOQux9QWIidIL04LewJGUfE1L1T6EBCxO/xbqebG3AIKfQ3yTLkZyvHoWgw70hGgR/kL1Ip QfomyQX90YnAQtmZMugvypwbLUzCC50PS5IDl8R3PPHWkWjqhCbs2bM7JErcs3uvZ08YSdj7 jtdff3Xbq8IRpb2QXdRESQkTzU9mHIObRj9l1pR3awUbBPueIywoZHPzV4LAqBTz2RbKI6rP HDoUErqde3rdyPOLAIwm8JwgbzdSP1C5lQt+X5f2whzMeN6KkiCFCxcpX768mjvmRSEuQdln ov5Px6Elj5p6gAIkhhg3Zkwo6dy8aZP1L70Ueli6eHHd2nVioZqZqTqOxQ5SMdBxdJz5axLz FjFPyoqeiKZIIsWfRFxYo5VFkU9JHGo476/g1Hx58qKSs5Kdk35Sk0z6oxrVqklmMWTw4Pnz 5rujNCoSioWrYu49JEGLHBOK9QiWlQRNLgwJHUJ2DPHjhQsXln9T7LmvIoNKlyotq8XmzS+H B1RJS+2X2nXqlChRQj4YZ6Q2Gz92rIygoorDg8ho5hYh2UT4KLckv2DqY2al1xMnhSM3adRY foCe3Xsk61d007ipg0mTJgmxdZyljkKsz2Smr86czEOHolJ7wurDTSPxHmVJy3jvyd39pNRu wwb1w7u7tFx0Ab3lbMYLOeeIK7m3vH605aVaBRFEyE0kdlu0NbKTalptGhOuio3zcS7naJmX EkKWPqm+oguPH1ezTra8kKlOqhW14MK6G9ggfFSl079mqhxbm8PqLhDbT/v37Uu4S/0gvzqJ evQfsu6RTqFlLO2itV8AePWqVTrG6YZcK/+SxJsPP/RQKKyV5Y0GaabmkdQS+MqodCv1g1QU 0YAXLmwYF5TMYOAZM2vXrOUWEq5MnKh82Fi50qSZqVi+whtv7JR/dvLEqFyZgXhezC+4XslI SdNCD+5ltP6akwH9+jspnp1AM11uahyRgD1yBMWHUuYmXz9SV+jBGwlBydnVPyeV1FMQk9Q1 53oIExjl84z0jKiQ4N69+6gbo0eNxn6+xm9nj+eVsjp5F5HUlUj32DGZF4sWLqTCkZ/27tsb K9sIIJreAwf2hzGEN67iZ4P69dKMdwHLxBmXmE35C6QeMbOWZNXhlFaUXESevFo1a6urLNeY 1H0Ki1etVk3qFOWOK1WsJNlJqxYtJUeRztkbVU1WZjuqZs8ePWlRsnFpQ0qowuU91aldS+eq z+lNTgdZfVSQrFatuvSYbVq1/sMf/oA4QqJOmQUlcZHQWvE3SVz69elrRVfRynIg54ocKtu3 vybZniRIJJWsE15/RGsxN0pRERjPZ9SIEf379lXQTycJC4WfgiClK6q8l5o8V5EwCSw0UNFS TdbQ2EdmJDUDpSSUr0VWmKaNm4Q8ufILyq0iA0WD+g0krUDrMlyE0sqknPRHFqkgE5yRu1Yi I6wlHYb0FmHOlYyVRUJ9eckpLAFS11A0ypevgLFNmhTD7qgs4e7dewIDJ0MKfbq7BIcmPzCh rKS4i1yVf0lqDPM5YcLEAf0HFCxYUBHZpc8+a3klq/M8kWf9upeGPP10hQoVpcawQjVp3ERi JSl0S5coIfWTZlKqCuo/8tYRiVUVnY5qa0s3HKeiqVSpcolixcx/SO59scR30dfnbIknKdgT jz/x5JNPNmsSZbZq07pNvz59LN5UUDm/VCr2RjGVcseoTQlLqY1e3rzl3rvvlgTJu5w+daqc JbNnziI6MJu/UdHWoUPkyUOyVE2aiaRjRJAstxUrlKdrPVXgSbLIvkKbGtVrWEddSNkjHCSH xhV66N2zR8F8+W0nsJZ8gZhZs2NH30aO8rXIfSLlHiZKDANy+6mwafwouE6t2mR1tSqVSYNA H74qE42BQ+72TZs216xZK17Io0IRDtq1aZsnTx6FKQsWKFi/Xn2XHIlqJ0RqcMkSJf/fb35D vURrmPmlFyMt2pDGjBqFQ3AsQmzbuo1nlKEoqJdlS5ci2SI+jzvv2qWzTDAOqH/9+kVZKnCm CntPFsj/zNw5tpSFCz2Fc0yC/bAMn1RN+UtlH5UwSh7BaJwnT3quSZMmWhnDE/krd8uTBQvK oSYHXKsWzTdt3HDHP26nvCycPx/34u2e3bpT/vv37xfeoIQuMhpa7yxnJtYyKjna448+Kukb SViiaFF7UfMvMWmp4sXVpldfVvFtSdaktLHLxefyXHl98jgaUprxLmrdiFZf5Ua7dpN6VeYv mpIcRCqJSuq65eXNqEeWS6RJF6JxeT1jxoxWAN3uR6lXKopMW7Z2gwYOkM6ImiR7LD3KCrp5 40aqqWoMC+fPsxVR1TH3Q7mbNm1WuFAhRRLpdWQdBpOtCK0bg0xbJFggTYmrH3n4YTk7EZbz XraRyDOp6KQslI8+/EjtWrXUHmgoU1hmfRUXSs2E2hy0bdO2atVqhC1VU1KjIB+sDldccYWF IFAMc0iF8hVcHudgjxp0aNe+b99+iHhklIEvSr9ZrVpV2fgIfyPctHGT7KOSiNKyQs5pOyvF n4MUOnb8mOxpshjGtZ2lEjtcoVyUri/6Lb5X9WpVg248beq0wYOj1NG1atRcv36DdKO7d+4k ssuWKW3XJ0116HDNmjVkjgMZqCRfDCc9nUfo27t3xM+ZezNZp3DF5s2baMKG59WYW3J42dJn B/bvp8w19Vj604h1T5zUZt2LL9FuHnzgAVkGZVKTetAW14pmybPHw3gjRgwnAx+4PxfhLJep h2VzkiLR17pxweeN6zeEEtNpxrtYxkNDiMacyq4Z8md6YWafUkfJrFq5UmQ76drVrlob/IAC vKeqFSsxYsppOX7cWGqkjF00N/obxtOPVJxv7NxZQzmO+fMaNWgwYfw4RPnmm4cOxkVV9UO9 JLJY0uSx9tW2SlXUtavXlCxRwg4K71GfnJcXjG4TLrH8Y0V0tmr1qsM0uSgzV/RJrClKk2um 7rG0fOq8/uWWW9wl2HAYFSWcJaAsGWHfZdl+Ji46Gz6SF6JCB1jOoqNz+iHpLb2f3KHO+5XU tdAQtr7Wr1sXe4RryZMK5ctZODz+sbeP4l5LQxBKfu3bu0+oEe9DZ+vff4CDMqVKrd+wgagk 1mybCRP6BR4IzVavWa0EswNSS20TBzpT+hxTydUZKdjRJ8PIVKZUaZk5ZWcsX6YsPqGTV65Y ycj79O5F37ZQhpkk8IcNifIUW0qsj8yqllEagc3qgf0HPG+ZUiWlVLXAUV9NjvRNqtWSvQS4 bYOnsxOJ52dZtGlPG1cuiu3ihVPuV6nUbc/oHl6YysNegL2HN03BkHOWQvj4Y4/LZCklprIK FmbWDUqLNyd565hRo627pCWZwDxDqWNIWPfii6+/sZNiJnlk3dq1WR3Z+qKq3IMGIg70pLFc sfrPlzcvC2SDevWdl41PyXXcpZ/evXrTyuyC6I0SUBIINDELBIlE3EkFL5Ulug6Gh4gxZsyU 4jJhJAdVK1UKxqFEPjiOWsfqn61agXz5KYoeH/V36tB+aqzU0cQ8e9KPgsaFnnrKgIsULqLW NLovUbwEg1CdWrVw7zNz5lIWlExo37YtUrRm2Z3KqDtz5ozQA6lu6iQvpKiTyXaMZL6Huutf /6Lu1qheTRZ3/dDeLXOutQzhwCWLF4WEtj169AwSL8seD08/v/Z59lL8Zj3yq+LYD+TKRQex ajxZoGB0bfcexKORFC9aTIp+Sqkq87LQSwFM0bXBk5rNg5PVrFk8D9RL2RatHfJk57rv/pjx mq5eufLAwQMVypbDqHazkhRbGW1D9J+WeBfJeiet0CNGjLQuBlMEFUj9ILttTIi1qKCUfsV3 hg8fMXnylI0bqX6bvWDrPdcTQqRKIeVZs2exgqgr8NZbR5Xz3r9/H3cg4tCnv7qVqdZ+Q4ER Ak25Dx2+eehNQ6d5yodp48SAqdkLz6+VSRZXUJ+wmeyuVFbjkQyXuT961LhKOCmEaJJ3H+wl EmwmcxHl+Vy1yvbpbPQRmf/ci3mDP0AaX5TnqVhuULAkogaT9KMZ48eQIUNtdwMvrVmzdsTI kbt2RuXEJH72UDNnzjIhhBLzCTvTM1G6segT7fcOHpRp0/RqRvvVP51NNls7KJZh02WG5cx+ bsUK+gLiHjt2rLoRJs2qpzG3xGvbtgX5lvrx1XThEzMZKxEnvaOQXt4uMVS091pf3vwyFXfi xEkyoCqDYdiS1StJz/eowAMlxcbPezRLVlJjsAQsW7bMhFhq2V3pI5HJ9OhR6wV92DFXkzdI nblYmrtE1+dg40qqNMiyssZrWkoKyxRpEq5Krj2zslesAmUa9MJFqQt2SjcZtofkzFnzYZ7R PsW5Fw0ghR5Dsyxn3tHwdmbyzOT9JeNMJYxkAIHtU0abJQ3m6WycyeVZKIOim/I4mbXHYqUx Ow0lg8nuToi4OqWj1JZZJjx7t6nzmepeP+sYkrechU4uEeNcbDc5m/Eu9unT16dn4AOagRzM eBbLZPRBOwoC6lLOZOYtguk/rLJZbhCt2SnFYrNInowLM4Esrk0VO6niNFEss8jYLG0iQGnS W1yJ/Ayxlu3howk5w5OWkez9vc5SIo6S580+1Umb0HmQOUGSx6PIQKWeqUecgYzNuCS+PExd xtPFVplU8Z78FCpsJhpH7IS/pDTwXmfq/NrnZMY7fpxxcssWxRG2ej0HDhxUEOHSTrqXGpAT sQUyep1gK1lqptIJbTDsKjOoTZVwu59Dh8LXBJpoJ7bjte0xnOKg3SZkhjH7avuhyMGGjRtY U5JLbOE2bNjI4geWoQ3XCD+4j32XF+Z2Nqs2OTjQ3mzbtlc3bFivOOtZnz1GyBzne1SyyxgS pMj5kUdGK0NVOMVGLjx7BAw6cCAq457Sizb2xgyOYRjhjRheJuNFLGQ36CnswWxVudftM5l4 wzzYHJoFM2OEoddQKzce+UZmEvMMPrpp8+bDbx6KqDae54ALDcgyW2VTcekX3/c0U+fdOAcz nilmqCxQoACsCazjunUvhepwyaoZjkmEQAepP6WKytS5ymJrdgksCNe58wiCAZBlLwJ2pIC5 tOGLZ0EN/b999K08jz/OPZg5jKikEeM7uytfBXplZgRe4dTmxEdMjgEs9PB8XGndYI6+fZQR r06dOmXKlKlapTLjQblyZSFu6tevhzIxKkc8MynPHuMNFEjevHlq166lxhBTx1nsMXFNJYUs QXaAeEKxsWha4k+4Y/T3zD1laj/hF2WG2HK13LtnjzEbQ2ob/WGApwoW7NGtW+jfje6+8061 BMMtNN7+2nYGZC+rR7fuVpAWzZt5BP4DDIMhlWoyh0yj/EChZxeqjlKkUCHNmG2xPb8O2IqZ dIlnZyKGEIAo0nLRosWKGbHfqj2YEMB5c8EH0DBnM556yEyall44abYvrlXIzEgURNrYKedB +EFEYmo+xueDaKK3EpePVXkHXDPWTML6Gq+cQb+JpYSWjGBPFSjA4a6BGIg+vftwWwErhVcb tB1m6wL58sVglIhW+KYfffhhjuCEppVibtUy8inrMwYiRmOAseKWcEmtWrWA9AMnJO8/0C4X Ip+BS/Ati2tykjfZsRKtHhlqhA09/HRW8tEtaczUHiBabkO0sg1akAio0C3RQTQlAtOsRDOT oSJGz6gSYJ5HH2vXJipbCQ4CjRlVoowrwifzAOf5+COPdOvcOQyGizXXvfc+M3t2Mg9gesEd J5ri6FtH98NVxvg1dcswlRqd4cIgVONhHyxetCgfaXTy2DFOF04Lx1FVtvETeGUxeVRbs0oV r4mnbu2aNdtffY3v4aww1w+At855y5zNeKRHcKBXr16DLbtA/ny1atYCwmShZmeP5EyFCtxK bx48wDmrUhwX9sJ4DSYh8SpGpUEFig+KzYwZylYtdQbtOetaLxicivvBSbKOeAp8kvAqMATg RQSJOHWKpZ6rmi+R6zkm8ij+BU1wJXNeE1YJbXFgQDBpYJ3u3r370qVLUjknNIM+4zcH91WC jz+NX85JhcSqVKqs8BjAGvs7lGapUqVZ+XftysB2ZhHvboHTVN4MHhdAFsLKs4tRgLHi4Nqz ew9NwTKUcL4DZQBVBQuPQEo3atBQnc0O7TOcjZwf0KfJUqGN9U5XADrd4yqZ3Bgtm7ckIWdn egWxfdmyZUBPpkyZZM6jQcbhHcFJyNOdN29eJQq5ExJG5QUh3HhKleNzkqfE2+TM4OLHaSbc JDhP4sGaQagErDaVRNG11Mm83FgujCeHM16PHqWjaoktOUxfevGFwk89ZTvUqWMnPiLeapAO OgxZBPFQIF9e72zunLla8sMiRE68ShUqzJsXvdRkpz5s+PA5szNAIZzOMGj2TlGlxZgqufgq la/A+5QQh57xGJcgwIqTsKMLFixQjxaAJuqWpH3r6EMPPIDhjYpqRMKAGloa/nXHHevXrder oIGBAweWKF4c80TdZm6QOAA5fMkiG6rRI0ciUGUrLS7aAEz97re/LV+uLJFjm9S/Xz8162hx RERQIHm0Bw0cZCsVhwedNAlPPPYYqlUxE4DOP15paiGOov268OlBg1yVaoYB++IfD/w/bOgw /jF4zgQXpta5KuoJ42kD0wyGCnwXqk+bDY44LLFg3rzQCdfl7X//O7CBn1q2bOV2XkeRIoWB 4/bt248DKedQRDz+bhQumTFt2q233NKlSxfaKfyDMwKXbv7tb82VZRFWRl1eJ7naoXA9CICO Pv9w880BqHR58lsyqhzPeDVr1qRu2QhZv4MONnTokJHDh9uPzZsblapE0JDQ9WrXpmpGK3GL FlMnTwKVUBQOzYnKCeQO0QurlS9/vmLFiou7EdngQBktQBNUy6VrpiLGq1AhqJq+gkrnzZMX TkW19IIFCgBM5H7oIVqQJRk+m/pkli3DDz34IIe4S4gaVIWRoF4QKPBkYm/k66cyhSUgiCxA DRU2HSQxaQplUi89jnEK/rXkI7hAo6HzZXE5eB+AG9hIkPxAf0ailDRmo2F6EIoiafn4o4/x Pnv8m37xC0IvuvXxEyJqBw8aDORx/3331YCfbtvWQz2cOzcfOgBa8WLFAn4a4yUSz1chObly 5YJxIzltPufMmQPdakkqWqQIHGmIh8J4ue6/H07aMfgIaCUtkWlEYGGIRQwf8U1hJxkdT5qM Dx2wCVFeQGHtUe0dDI+4BoUNwDfAIC1FMFN26tdvkDfPE8xI4cEv50/OZjwY6UBePiB5ETWw uAwcOGrkCLssaAdfMQ8oE5Cetw5WInATjIvwQRDEEUNZWOnhLQirunXrQUELlmFJGzNmTFQV uUGDu+++O6hA9CUlvyPTYhy1ybo4bNhwberUqY2qFi9eMnDAwN59ehcrVgzFJOEFkPIQzy5n PEiWc2AL28UQFuRDAQY7jqg/7KxOnoRTiwo4xyFnoQ2lC/W3Ugx5bCQbx40dg3UTksXqNjm+ Ghi8OAlJ4kER6M0eD60LHfAroCblmTRjtCDxdFi0cJFhQ6OtVwhTMkVMGsWLl6BtstzQZgd4 qN69WTUee/QxS4aW1i97vNB5vB7tJ6ysbqVKlbIAqWXta+/evXLnzq2ZWdKG/blkyZK0DA9I /qsNGEYOj0JHTZ5C1I99e/hqd0fERQcvvqASPXEdxjl92nT6vP02DdPX2lHQUwb0lApqHtwr dcN8ebJfzma8Xj17jB0zOrwnaK9Qu9yajbZodHQzWigwJ+t8zWrVAb5QFZ3Ei8EDUIt4EjmG lxQ6oaAmqmY4s3XrKxbXcEwpgg+0ZcowK2T60yiNtosJ9YDVU958Dd2CUJIVjRo2omjZaFnR O3ToWKhQIbApVGi9V9O4VKmS6DW6JCreesomqljRIqxEemCTJFHhpMlnazwiwyp0SyBJ+z2B diSAzuG5Q4qHLHu8iPH2G3aFsMezKgm9o28XyC+uZy5IKv4sVbIUiZF6LVmHSZInip9iUbfO 0f7NBzbVGpekWkiaUfYE4yRfgSotYck8AH2VK1OO7AJ8hSZjLnYX4ExbNc8IrWpmPKOY+qAw W3GaNW4irI51F9SOUs1oqWB14UKFCepXX32VZdhCCZ7qwWkxwLelS5acMSPCml6ezJY6qhzM eKj21ddeQ0+BYmDWoxQpJ07s2LH9jTeiRADIl34Cx4iWvTZaH20zorC4CPjkKVMIIpEjYTqC LXPH9h0Qj8G6Gc6Tb9Sz8NUL1qe/Wd6rbqNbZ35sooiUMKqQQGn16jWsKThWz4gG2jNE6MQS ZpWvhpdCLicobzwHBuVyEQDMKoLiUGSgaY3Jeaq1Y3XJp02bTrsL9snsBBebUt8Kj+9XEl4k m8gJC5PIJmZAV3GgGXMiJTws76idYWJn9ZMbKc4e1gVTDU1JPmahJLalCP4afzSz3oVY2PAh vYULG6ox0DPtt6M68ps3G4ApJV1BQ4NETXowBpZbQXfhwe0bx0+YCIubOQ+bpk6dRp671/r1 68yJZchPOcF/npONKymJseL3Gn+SXVMqeDL8mqwxWX5KKCMxsaTSUyoqJfSTnbhDgo/TFBZG kvIJYwsnU4+zf40vyoBrZHo6znVJ0ttZB5Y6pAyBlg3BmsxYlgFn0daS6T091TGiIPtjvtM8 pK7xqccZbJn5JKlskzxdWALOMXWnW0bzl0auZCfS9Jn0DKRnIEe7E876+s4qtc4io86mkATn +RkyJEYYhjOpP1EUQuN3IqHkkosZZJo+P8QzkIP3eGd9K1QSWxf/zmHXOvrWW7bmGcn54n18 0FEDa7HCrX3+ed5bEKegv9m6MKPbAs6YPoPrwh4yoBbfifF0yJDDCmLbmJofNhmwQdrC2WVd /sa3DzHpf7CPlrMZL2Xbdhqn//TTTwe7c8xOpzcGSWOmF5462MuQC1Azlr3Qnj2aoa9xo4YM bsAuTI6YBO6EV4oFnJlUtGW3rl1eBLOMWSqDac/cQ+pHFgYG1WRfl+w6kjFI4yPj0OkGHywV pO/+vs9ADma8iGdi0xk8brAQbHt1Gx/xsCFDnh78tLBxDm7cAZEo5Jm5TBuNiTt2wt17MN1e TgXJMzmvubm279jBssdCPf+ZeTiNKRwaA8SRI5v7wWfylKmSJsGOuTDOWxzJPKZCljfH7nLo 8GEeYSbQ3Xt261b2LrbNKINDDBzzZsNcGwOMr6RMI4YNjwXv0Q8+19z7TnbpG+ZgxkOv0FLl ypWHHfEiBw4YwIErzaOTeZ/IU7VqFeikyBfUrBlJVbx4cRlQgI/gvzZu2sixK5vlX2+9Fe+1 bNni9zf/XoIGPi7/eCCkypk4YeL9997L7ydjUpfOnSQO4Em//fbbpUtp2iTKJxkJq1P/ASuT GdYRcJkERDxyNWrWBONgKBejoPOKFStyeERcFzOexpzCXTp37t2zl5Qt0Plc2AaZ1jk/aqyY UxnPuNHrUwUKBlAIoAmpFXLxQ7s3b9rMDqxSpUpbt2yRlgfWkRe7dKmSXNIA7zKIyP8FMMX3 ChIpb7E2OpHoVnJleaxs88TCgXqSk9WqVMVpoDAEY+sYnl+2dGnJ0oOWSAWV/8cBNNOi2Fk8 Y9p0OZdopFHeruPHuKrlUwqN9QBXEVUFOHUK0AMUAwBaqiwyMGwm05+PzgzkVMYLMoQjWDiJ FNHgVLBUgb4BxKLceBE8ql4E4GzcGD6LqQOhO1mhbNk5c2djHjpnzHivUB2rx4xH3EmJi9Pk gcM2sqqCwsAHSwoowSOAYuu4BwBrGXXCvcSqdI0DYVq3ar1s6VLgKeBdQa7u2L5dlBxaQthp U6P86j4ghe3btAnHVocA/JXzC8Y6zXgfHZYLT5qDGS+ghwkxsEOSqnSJkiG3PugwQL0DYGWM B7m7dPESMqpl8xYeWA5Glkk4SRfWrVP3tde22+5RQbUXgikAh2pKTI0fO44SmPeJJwCa2rRt K/BHviqRYJrhyZUrngvTh/F0G/FzhQoyTwtKCGhMEq91XIRAHjuBambZjhRqXjhpcN9rKSWZ A7E/bLBpxkszHvDTtddee8Wtt96KQMPyHD6X1T7EYEDpJaWVLBkKmdTq2LEjbbN71279+/WX MNOAYflBpaLkykuXCleV6hz1V6lUUeQBqcX0Iic09K3AH8hJqGKX4C6cIMEjeKRiA5C44FGY Z+zo0WvWrpXpmX1EgmqAr9mz59jgMZPA4LvR3XfdBbIklTpjZteu3aZOnRKCaOSulKFdRoOn nx7CCkqiijETmtCrZ69JEybojVjmV0gzXprxcgbjeU+AjIIjxYABXkbrwslTjPhEDd8A6HME vNyxg1gTSCLOUkESRkvbQtZOqHzmRJdjV1vEkLpD5E6IA1Aoz0n7QDGjYbkRJKql9ObYLAKI viqkJToOFWrs0BYtWoh7FZojHl24YOFCv8aZRU6wrEBy+mzdGoEYiTtgaE5C5wUZgTtu377D lvKjRnbp583BqqaXl0jj+PgMGGL4NXm8VIdbuCq5PGkTqCGLkE8AK2d12WVpn3ptfIvTSbJS 73jmsC8vVSLNEu/PDORsxnt/5ih9l/QMXPIZyMGMd56wzOxTFm9YMyK7L4eNaxCA7wRAy/KY voZ3ltRDPjtNnAk6Df0HFeCsKNN33WSee5CXnC4/9B3mYMbzbpYtWy6vUcI8iQUoOcj+/jQW GGoPFkfuvR6Fk3+gL9l4hNvZN77TKGBKhYTbpkaPGYO2wWVgYqK0lpkg7ezP66HUalQ55OWX N6uywJcYb1Zfj/JhZkOZAuLYKvOvvNMy5LxtsL1uFi39A525nH3zHMx4iKBZ0yZRfoTMj/JU IcW/g7h2+elPwJSFp4XknD51GmMMt4GkfdH5zEC7ZDoyY/ZOB3R7zxmiJlPmRMaSk6nZrDM2 mUnLhEwDh5y5zTu9I+W3UEU5yOHTci8TZcrkw7UYJeTL3JfCo6m5lfp0MppED5gZER9+4tnv 3r0HV6dEZkp/GKp8M+r1hV8Dj4Vj7scK5cpivDNHmHoHNdNHuC87kDXLD2pNhoLVOZv8P7jR 52zGU3VNcishycePvQ2DIv+U5Hxy4xQvXkzCPLZEpsXVa9ZESTgkxoyqdUcVt9XiYsEXcCAB GQKKQJfHjqmJB4epJDrz4yG5igUl7NoVYTJPnFAfWGQ6OSFHy062yrhouISqfnIlAlabJi5D o0TOZoPRj58UFla7izMd54SMmu7omKFVOjC5H6XE4pZg3pT1QGIyFxJlADeJjUeGwlWrVovp VoKPTz+OSY9YRfrAkOCAT9+v7iKdCd8GDKrjUAuJKVU6CZnzpE6RlcSA9+7Z7Xk5UdTc4TUJ 1SfNlXEaAyeK3oTnO3mQBfiNndJym65169dp76TBw52q1KM3hm+w1aefHhzVOr8Myhp/cOxz 4XfO2YwHrSIBifLWXTt3ARC55Za/cLUpaHjLLbeEBGFAm9Wj/MT1uRMgUVCpnLZ8dzhBklaV 2WSMlRcE/cFh+lUmr/vuuUeZO7Qr8xxwCWkg52yUDnDrVkWbpd9CjqNHjxoSZ/gy8T169ChX tpwkKMDZfHTWAv4JiLCyZctyl1euVNG9otSA+/Yjbn6IRQsXkFdr1z7fpGkT2VflIDEGGACZ nsmoqHH8oXzCl0n1JSFn+bJlIcsgUSdMGO8nydQsHIBplStXIb2hdv7yl7/ECQ5fhBZQh10e Md6RO+64Q+Yy2ZnuvfdeTPXs0iUywEoPY7TyC4HLSFgGOOrCjRvWgwpUr1ZdAb1Vq1YpQKmu rdybUVKTOnXAXC09JnbihPGm4p577sH55kHVctrs5bBJvnDy/+CufEfGy58/P8JN1TYutyk2 NimGZJImpmhTXG1y/vB3m0y5vgkjnAZvqZmVfuHCRSFXCroPBcf9BNglozMyIhlyP/jgnNmz nh48qG3r1nLOyeEhPzSwGFHTplWrXj16Eq0YMs9jjxFTZGZAqBBxvPa41LF0Q/37RlXCBeMp m4r96GalS5biMDR1SjHjH7FIdlM6DBMLU0ogG4l8hFguPEX4SUag4XFwEymsN6kyn3/hBWxg n+avx1RqPGR0pWRKOEsiEbkyqamjkC9PHntXEDlZUlaufE6dR8147WU3mjZlqjLikXq5b7+R h6TLBw7sl2aTDJ8xY6YM0PJhmgQ7OreQH0ViMnVhZROcOWM6AFDPnlFv1jWLVFrVvGDOzc54 NKCbbrrpiqpVqwL+XuaMR7ysWPEcCIsCvDRJ9U0RLoUQWIwWJKnrvLlzPYJ4BVlxwrMIsSPi qIING9SXT5LWhIvgXYQSYUiJruCtmzRuBEs5eOBAVYXJrihT6vLl7dq0AcvEWoIhZJgO2fIk DnJ56Pm1ba/Cdnbu2Im0UcnZmTgZbv0AZONFV80U89t0yfnpDFEmJ6SD9u3bcf1TFKFqMG3o DbmHxKwYT0QFvVcaNfEWBq9SsfNMMmQUw4m9Wf26Uf4yCq+MmrVq1yarqakGuWH9Biq3NOna k2x8/ThfAV05wmTgVrs43ItOThrj/HnPPEMaW18sBDLf1qsjT/spD+i83mbNmCFTU7euUW8k /JLFZ2S/vmAS/GhemJ3xFLumpFwhg2/RokUvc8aT2hUpSAlesVx52zDYMcv2kbeOUNuwnxgc ATgegUBApgwDTtLTGFRgo6mp2M+mS+o7mqS48pLFi8u3aeNmyS+YL7/U1IhVSnBKJjYr/ORT UgOKbn/iscfJKM1syeS9kkIzlCUI9nr64fBhQ/2VcJrEK1tabfG3jTBUAnCJVJz6sUwApilR 4BKiiXFFmrAKRNCu3YapK3FG3bp09atr6caGR+IRxX169ZZkNrw2m668efJs2fKyXK6ygHk0 WDn1ekg8GjV0uASb4pjIbUH0+EfPAZ0zsP8AS0OZ0qVkE/NVOQcrl9mZPWumNcjKMmTQYJEZ AjU8ZqMG9a1fJJ7UzoI8BF65pEXLlhL+Ofhoss3FP3V2xgscd0VAjl3mjCcv+nPLlrEcEHFY TpSd1OLibiz79jlq7lj7baLwGIrv1bM3/VBouaXdvmh4DKSOFu+2bUNx+qqVq7ZqFSGbyTGp pnUrSK9gwYKRyDp1Cn+iYDOO1iWTtSHs3iNKV96vbx85p7Foz+7dataoKREtD4fErOqJlyhW nJa4bes2iE28JOxdks98efJaDkaNGvXE4483btzIMCSEJPEwHouFyKahQ4fRgXfu3GV7ZgXB xpLwYlTWlyaNGotdAlUjOYkgkRlgop6XJJRJmtosV6xtWMECBUl+T6rAyNKlz9oysP2SY0aL c+gyZUqXkb1X2maZKsUZCi+kJ9u7UoNpBzQFYVDuiJNZj9q0aknM6g3oVLSUxzd7xi+TvI3i 5bYBuXiWeH96yM54xB2hd4WXdPPNN1svE9673KYYKdOR6E5WcTF1NnUkwPoNG3x1nkyzq0G1 dkchpSSDJFMe6cQJwOgXWeTi2CI2TFXv4t4OImL9RKa/3XvYF0kbPUdugxMnXCjVioOouDYi PfLWGzsjNKb5YZthtECpLIohyTnepvup0SF1vN5wkZa4RVJkmzSWHssERlq1ehWZaTCYnPSL IKbHjslFaYemE4MJedfd2rVUSrfWf1zL6Di9kYWGePdePDg902aS0SXq8ODBuKzfgWich9/y q0+cJ+aE/wkLJMPDa2Ud4WkwFXL1unVczTxqSWzqwSDdSD+GZ0rDjLH6CunwK65Oavq9P8T6 YbpLFsbzpq666ip/I8aTzJxp7rJlvGBbT/xRiVcqOWC0nD49Y2uXnAzaUXioxHCf5WSYlHM3 S9pkX7pwvs1bq1atK1aoGDaZqb2lKhFZ5jal2RkJocP55Eapw07tOXUkyeSkOvdSM9CkdpLl eVMHnDEJmR7CZE6yDObDxBLvz7NkIZuE1yLGw3+0TRj/8CYuN4l37gkK/rdIvr2/nyj38/Hj FHVxQ2SCeSNC3wXe9f6OMH23y2EGUhkvldEixvMRrHnfffflUMYLw34nDOR/a/ZjKGQiyoKa +n6P4b/1bOl+L9kMpDJeqmqZwXgIiKWFvSXHSbxLNkPpjtIz8F+YgYTxmFEEnYeqmj6nGc8p 9pYs0ehn3aikT6ZnID0D72kGbEmYMJPd3BmM5wvrlp8lin1PnaYbp2cgPQPnmAGyDlvhvdQ2 pyVeOEvuPfLII1xAmDA9m+kZSM/AxcwAbrKvo2GmyrqsqmbqDYDI2Dldk2a/i5n39LUf5RmA Z7jxxhs56pJ93bkkXvIblnMNZx9rJ6OLvR8P7Ed5HtPPnp6Bc89A7FuabadGZ7zyyiuFH2RR L8+L8ZJGPA0MnsQl9lXqPv1Jz0B6Bs46A5REbILr8N5ZpVwq4/1/9BckHFTJneYAAAAASUVO RK5CYII= --------------020301080900060202040300-- --------------040508090106080709040304-- From nobody Sat Jul 19 11:57:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E6C1B2A6C for ; Sat, 19 Jul 2014 11:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-qcD7NG2Szc for ; Sat, 19 Jul 2014 11:56:58 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385041B2A29 for ; Sat, 19 Jul 2014 11:56:58 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so2309672wiv.1 for ; Sat, 19 Jul 2014 11:56:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=r1HLOkaLg1ERCEFLlLLlO/Eb31rPr3oEERvHzN5rt7w=; b=a2aBEDaDxR6OW8c5F+HBVqwI7XzMhuek1EaGML1/S38pVeQoLu0SrkHtgezh5ckW50 F8EpAIFp8A4khBIkzugfT8MKchk7azcFmi6qybhHMaygMMlgPNf08+v7HqbqFkz1mmut N39Q4TrogoGal06S7TC2sOHloBi0YYZrLtqQZqerR480Tztu/N9b1FThOPLAFXgnTJCR edIKNMYSNiaRPUk/fB7grZLUdr7CS8ZrNfJ6SE857zGrQ1RPUNDZ2ZzNj0mYcQy20WfV 1PlXZ6LhO7+XIT8UNmltd/jQ5DVRxZsEX8hqoNjC3mWDsZ5zoFW71ENS90uHIqngb4zC TK9g== X-Gm-Message-State: ALoCoQnLvvtL9ThuGXseCNDxNnrh6kNIRAnNhRM9+sanjC8Cmvcyv9gURq8z3P5UZWUoSEPQSM10 X-Received: by 10.180.89.143 with SMTP id bo15mr18376903wib.78.1405796216814; Sat, 19 Jul 2014 11:56:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Sat, 19 Jul 2014 11:56:16 -0700 (PDT) X-Originating-IP: [64.88.227.134] From: Eric Rescorla Date: Sat, 19 Jul 2014 11:56:16 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f3bab87217fc604fe9070b6 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GDSTBNlaZ9MxK1D9VraOtPcAv6I Subject: [TLS] Reducing record expansion overhead allowance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2014 18:57:00 -0000 --e89a8f3bab87217fc604fe9070b6 Content-Type: text/plain; charset=UTF-8 https://github.com/tlswg/tls13-spec/issues/55 In TLS 1.2, we had the following maximum values: TLSPlaintext: 2^{14} TLSCompressed: 2^{14} + 1024 TLSCiphertext: 2^{14} + 2048 These overhead values allow for expansion in these transforms due to potential bad compression overhead or padding, etc. Wan-Teh Chang points out that we no longer have compression so there's no need to allow for 1024 bytes of expansion there. Minimally we should reduce the TLSCiphertext overhead to 2^{14} + 1024. Do people believe that we will have AEAD ciphers with 1024 bytes of expansion or should we reduce it further? I'm inclined to not re-judge that and just leave it at 2^{14} + 1024. Thoughts? -Ekr --e89a8f3bab87217fc604fe9070b6 Content-Type: text/html; charset=UTF-8

In TLS 1.2, we had the following maximum values:

TLSPlaintext: 2^{14}
TLSCompressed: 2^{14} + 1024
TLSCiphertext: 2^{14} + 2048

These overhead values allow for expansion in these transforms
due to potential bad compression overhead or padding, etc.

Wan-Teh Chang points out that we no longer have compression
so there's no need to allow for 1024 bytes of expansion there.

Minimally we should reduce the TLSCiphertext overhead to
2^{14} + 1024. Do people believe that we will have AEAD
ciphers with 1024 bytes of expansion or should we reduce
it further? I'm inclined to not re-judge that and just leave it
at 2^{14} + 1024.

Thoughts?
-Ekr

--e89a8f3bab87217fc604fe9070b6-- From nobody Sat Jul 19 19:35:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18D91B2B5A for ; Sat, 19 Jul 2014 19:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDWpTXMefMUw for ; Sat, 19 Jul 2014 19:35:38 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D993B1B2B58 for ; Sat, 19 Jul 2014 19:35:37 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id u56so6030737wes.14 for ; Sat, 19 Jul 2014 19:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iQAkc+LmB5jwYwNeJiv0lkLqcWHThOVJIvaIgzoVgkA=; b=u+m3KH7yVRfVh5TJ+QHLdFOApwLE1MzPI1I8BMVf1IkC+a/SeUV+ec3k+H3n5q6s5u 3xfj+tXPBc/TjzfwNAbWltp+mu88oi3EhvP9E5qZe1gSmkL/PCu1fF3YHqgXA2hS6SpX OGDvx/6VbJXfKbi2jX9Ti/mppgeLIuhBSOq30I4i8Tlm2dKQ2BL+n5MUC5dEr4O7y/fv 1JQewz34UFoTVZ7dg5bt1L8eJSNIj/WlG1SITeoiI1mDAAKzyggHwjg2B/aeuJflwN3d KJ/bKpChu1yhCX04iAsOG1sAqlJMosPzvN16k1BkeP07vj+f9Lz601niWI2fZDr0+yiO nKig== MIME-Version: 1.0 X-Received: by 10.194.143.49 with SMTP id sb17mr9183669wjb.25.1405823736249; Sat, 19 Jul 2014 19:35:36 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Sat, 19 Jul 2014 19:35:36 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Sat, 19 Jul 2014 19:35:36 -0700 (PDT) In-Reply-To: References: Date: Sat, 19 Jul 2014 19:35:36 -0700 Message-ID: From: Martin Thomson To: EKR Content-Type: multipart/alternative; boundary=089e013c635a6a849e04fe96d8eb Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NiMLKw0G1XkhQgvH_nuEbvOvs0g Cc: tls@ietf.org Subject: Re: [TLS] Reducing record expansion overhead allowance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2014 02:35:39 -0000 --089e013c635a6a849e04fe96d8eb Content-Type: text/plain; charset=UTF-8 I'd have thought the first 1024 was a no-brainer. As for the aead expansion, it does seem excessive. Even if we listen to doomsayers and acknowledge that we might need as much as 8 times the current biggest algorithm pad from the non-aead suites, that would all allow us to halve it. On Jul 19, 2014 2:57 PM, "Eric Rescorla" wrote: > https://github.com/tlswg/tls13-spec/issues/55 > > In TLS 1.2, we had the following maximum values: > > TLSPlaintext: 2^{14} > TLSCompressed: 2^{14} + 1024 > TLSCiphertext: 2^{14} + 2048 > > These overhead values allow for expansion in these transforms > due to potential bad compression overhead or padding, etc. > > Wan-Teh Chang points out that we no longer have compression > so there's no need to allow for 1024 bytes of expansion there. > > Minimally we should reduce the TLSCiphertext overhead to > 2^{14} + 1024. Do people believe that we will have AEAD > ciphers with 1024 bytes of expansion or should we reduce > it further? I'm inclined to not re-judge that and just leave it > at 2^{14} + 1024. > > Thoughts? > -Ekr > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --089e013c635a6a849e04fe96d8eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'd have thought the first 1024 was a no-brainer. As for= the aead expansion, it does seem excessive. Even if we listen to doomsayer= s and acknowledge that we might need as much as 8 times the current biggest= algorithm pad from the non-aead suites, that would all allow us to halve i= t.

On Jul 19, 2014 2:57 PM, "Eric Rescorla&quo= t; <ekr@rtfm.com> wrote:

In TLS 1.2, we had the following maximum values:
=
TLSPlaintext: 2^{14}
TLSCompressed: 2^{14} + 1024
TLSCiphertext: 2^{14} + 2048

These overhead values allow for expansion in these t= ransforms
due to potential bad compression overhead or padding, e= tc.

Wan-Teh Chang points out that we no longer have compres= sion
so there's no need to allow for 1024 bytes of expansion = there.

Minimally we should reduce the TLSCiphertex= t overhead to
2^{14} + 1024. Do people believe that we will have AEAD
ciph= ers with 1024 bytes of expansion or should we reduce
it further? = I'm inclined to not re-judge that and just leave it
at 2^{14}= + 1024.

Thoughts?
-Ekr


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

--089e013c635a6a849e04fe96d8eb-- From nobody Sat Jul 19 21:32:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0881A08EC for ; Sat, 19 Jul 2014 21:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtDY7DnAZHI7 for ; Sat, 19 Jul 2014 21:31:57 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B96B1A03AF for ; Sat, 19 Jul 2014 21:31:57 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id fa1so7664939pad.13 for ; Sat, 19 Jul 2014 21:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Vla5FmUnJCbsNeMJjxMr6pvdP6PqR+41uxiEcPgRyT4=; b=oGAGeAW5BABSNMORSf80jKFtuyxZjbwVXouaz5/i5ELUfowduM5wduaqrRz+O1tCMf 9lcPK5yyTIajrq4+A3HK+Xx2BVIpcCK/LsNQL7HWWxDEpXfFIceQXgzs/hJEorJEiSYw XdfK6LUyzoXBoHIqpIevw3FtrpPYhVm5DLwDR3ya+hvxNFez7ORcr9rVczCclAU8rZ3+ Hxz0YrIgPTcRY81deJeCfP5beXRVmWfKSyNaxp64K51SKkr+1f7jFplsbk+e+R8N52Er 2OyCO2KbyYs4orYT8I4//rRWWQX6J5E9P/c1gknqNVrwLZBHuTkbuQVP28a8HfkdAQS2 Dmig== X-Received: by 10.68.65.36 with SMTP id u4mr101019pbs.127.1405830717194; Sat, 19 Jul 2014 21:31:57 -0700 (PDT) Received: from [10.0.1.4] (c-67-188-142-21.hsd1.ca.comcast.net. [67.188.142.21]) by mx.google.com with ESMTPSA id v5sm13632102pdc.7.2014.07.19.21.31.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Jul 2014 21:31:55 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-22C7F32D-4511-48DC-BB70-F8F4156ABD18 Mime-Version: 1.0 (1.0) From: Fabrice X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Sat, 19 Jul 2014 21:31:53 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Eric Rescorla Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fG9YTKLWUCbsmYadBlrwwpHuNkE Cc: "tls@ietf.org" Subject: Re: [TLS] Reducing record expansion overhead allowance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2014 04:31:59 -0000 --Apple-Mail-22C7F32D-4511-48DC-BB70-F8F4156ABD18 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit What are the benefits of reducing the allowed overhead? -- Fabrice > On Jul 19, 2014, at 11:56, Eric Rescorla wrote: > > https://github.com/tlswg/tls13-spec/issues/55 > > In TLS 1.2, we had the following maximum values: > > TLSPlaintext: 2^{14} > TLSCompressed: 2^{14} + 1024 > TLSCiphertext: 2^{14} + 2048 > > These overhead values allow for expansion in these transforms > due to potential bad compression overhead or padding, etc. > > Wan-Teh Chang points out that we no longer have compression > so there's no need to allow for 1024 bytes of expansion there. > > Minimally we should reduce the TLSCiphertext overhead to > 2^{14} + 1024. Do people believe that we will have AEAD > ciphers with 1024 bytes of expansion or should we reduce > it further? I'm inclined to not re-judge that and just leave it > at 2^{14} + 1024. > > Thoughts? > -Ekr > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-22C7F32D-4511-48DC-BB70-F8F4156ABD18 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
What are the benefits of reducing the allowed overhead?

-- Fabrice


On Jul 19, 2014, at 11:56, Eric Rescorla <ekr@rtfm.com> wrote:


In TLS 1.2, we had the following maximum values:

TLSPlaintext: 2^{14}
TLSCompressed: 2^{14} + 1024
TLSCiphertext: 2^{14} + 2048

These overhead values allow for expansion in these transforms
due to potential bad compression overhead or padding, etc.

Wan-Teh Chang points out that we no longer have compression
so there's no need to allow for 1024 bytes of expansion there.

Minimally we should reduce the TLSCiphertext overhead to
2^{14} + 1024. Do people believe that we will have AEAD
ciphers with 1024 bytes of expansion or should we reduce
it further? I'm inclined to not re-judge that and just leave it
at 2^{14} + 1024.

Thoughts?
-Ekr

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--Apple-Mail-22C7F32D-4511-48DC-BB70-F8F4156ABD18-- From nobody Sun Jul 20 06:12:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F621B2C18 for ; Sun, 20 Jul 2014 06:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qfq-XAfaxF0k for ; Sun, 20 Jul 2014 06:12:05 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90A961B2C11 for ; Sun, 20 Jul 2014 06:12:05 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id k14so5258973wgh.20 for ; Sun, 20 Jul 2014 06:12:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=QAwGbJojbf2PuMiqojiA8wFnx+99k3z2CuhW5hIaXJI=; b=BM1rYVIi5wPZQw41BwWGQU8GtbWJgo3HoyV2AgzxuKZk+t4uWPlkgGjvC2T6jfR+22 qlgLbR/6SuWhjiHIJw7LcujUcHx2dP0gfRBXehSo3Pd5YbCJ24qY2vjJA+Adz0BTQRe3 KYxyP/smwVjbKiln9ylMWlhbJLDc2ZjwTIJ4krv7Fk+Dv4MdZDrOekCz4jzbQcKW9KFS c36V04A9Q++RVwn3LCK53ZIPq6WiD5FUEP/NX2u1ooJBjDi1vJ8PltI/j2aNxc86NNgo KgUlCcVsG0qWlADlk0CQ4OWjZfKfGmznV/bfpIYNsfRvOiaH9NLCO1x/lifQ73Q7L268 T+0Q== X-Gm-Message-State: ALoCoQkKOU/56DoLeCh5ZRfw32vVuKKMjQGVq11PKUV07UkbeBzzhSulY6OFpVNis+EQSFaY04nt X-Received: by 10.180.78.100 with SMTP id a4mr33846708wix.36.1405861924172; Sun, 20 Jul 2014 06:12:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Sun, 20 Jul 2014 06:11:24 -0700 (PDT) X-Originating-IP: [2001:450:1f:232:c9fd:4f6f:8085:675b] From: Eric Rescorla Date: Sun, 20 Jul 2014 06:11:24 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=f46d043890eb98113304fe9fbc8a Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KtRZIEf5mluLMP993pr-e2T5lWo Subject: [TLS] Interim Logistics X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2014 13:12:07 -0000 --f46d043890eb98113304fe9fbc8a Content-Type: text/plain; charset=UTF-8 As mentioned previously, the interim will be at the Mozilla offices in Toronto: Mozilla Toronto http://www.mozilla.org/en-US/contact/spaces/toronto/ 366 Adelaide St W, Suite 500 Toronto, ON M5V 1R9 Canada This is a locked building so we will have someone downstairs from about 9:30 till 10:10 or so. After that, please message on IETF TLS Jabber and someone will come down. -Ekr --f46d043890eb98113304fe9fbc8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As mentioned previously, the interim will be at the Mozill= a offices in Toronto:

Mozilla Toronto
http://www.mozilla.org/en-US/contact/spaces/toronto/
366 Adelaide St W, Suite 500
Toronto, ON M5V 1R9
Canada

This is a locked =C2= =A0building so we will have someone downstairs from about
9:30 till 10:10 or so. After that, pl= ease message on IETF TLS Jabber and
someone will come down.

-Ekr

--f46d043890eb98113304fe9fbc8a-- From nobody Sun Jul 20 06:15:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138D11B2C1A for ; Sun, 20 Jul 2014 06:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KR0kj7z1iotG for ; Sun, 20 Jul 2014 06:15:00 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84611B2C11 for ; Sun, 20 Jul 2014 06:14:59 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id k48so5239706wev.27 for ; Sun, 20 Jul 2014 06:14:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ey2Msh41j2SdGnBuPIW6X4YtaN+lTgH4WsdHIiLmwOg=; b=cJgzBTtXY7Cw59pO+sQr/JdopgfbpqXGd/ZurQgQgG1iZDKZH/jOxZGe8qroysXdbf xki0qSbtVkPTlWE+YK+FSA/I44UiN03McCkc2be9c8idNnTuMBT77+/pbxvXrdYSUR1H nGCeQJxZ4EqOJT9u3m9+tJcszFsp48TkCQFxlbCaQTj/68GjawbEyQfF7VgxyI2TyI92 qOeIG+sB8gGSJJ0wjCQLadf6yFFEBTF2T8oY7gzkhxlepK+gRz0awHnA3QR9epels7fw 4qJ6+OoMJQ7eZADjlhV7OaCZJRovFSEnvnNm0j8aCEy8BJQ7FvhbGnfIYU18nal19tCl EHPA== X-Gm-Message-State: ALoCoQmz5n730pAajaT4Dgviv+DJbgPGvoZYmlEc7z8/Iu1S8zExe+QckjCB8j9sijs0u4nnjn3v X-Received: by 10.180.75.49 with SMTP id z17mr20561909wiv.80.1405862098305; Sun, 20 Jul 2014 06:14:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Sun, 20 Jul 2014 06:14:18 -0700 (PDT) X-Originating-IP: [2001:450:1f:232:c9fd:4f6f:8085:675b] In-Reply-To: References: From: Eric Rescorla Date: Sun, 20 Jul 2014 06:14:18 -0700 Message-ID: To: Fabrice Content-Type: multipart/alternative; boundary=f46d04389533f9202804fe9fc638 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mYFkmdoXBNLa2-U4IgNmTtwsV_g Cc: "tls@ietf.org" Subject: Re: [TLS] Reducing record expansion overhead allowance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2014 13:15:02 -0000 --f46d04389533f9202804fe9fc638 Content-Type: text/plain; charset=UTF-8 On Sat, Jul 19, 2014 at 9:31 PM, Fabrice wrote: > What are the benefits of reducing the allowed overhead? > It's good to have some fixed overhead to make implementation easier. The benefit to reducing it to 1024 is mostly consistency of assumptions about the AEAD ciphers. -Ekr > -- Fabrice > > > On Jul 19, 2014, at 11:56, Eric Rescorla wrote: > > https://github.com/tlswg/tls13-spec/issues/55 > > In TLS 1.2, we had the following maximum values: > > TLSPlaintext: 2^{14} > TLSCompressed: 2^{14} + 1024 > TLSCiphertext: 2^{14} + 2048 > > These overhead values allow for expansion in these transforms > due to potential bad compression overhead or padding, etc. > > Wan-Teh Chang points out that we no longer have compression > so there's no need to allow for 1024 bytes of expansion there. > > Minimally we should reduce the TLSCiphertext overhead to > 2^{14} + 1024. Do people believe that we will have AEAD > ciphers with 1024 bytes of expansion or should we reduce > it further? I'm inclined to not re-judge that and just leave it > at 2^{14} + 1024. > > Thoughts? > -Ekr > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --f46d04389533f9202804fe9fc638 Content-Type: text/html; charset=UTF-8
On Sat, Jul 19, 2014 at 9:31 PM, Fabrice <fabrice.gautier@gmail.com> wrote:
What are the benefits of reducing the allowed overhead?

It's good to have some fixed overhead to make implementation easier.

The benefit to reducing it to 1024 is mostly consistency of assumptions
about the AEAD ciphers.

-Ekr


-- Fabrice


On Jul 19, 2014, at 11:56, Eric Rescorla <ekr@rtfm.com> wrote:


In TLS 1.2, we had the following maximum values:

TLSPlaintext: 2^{14}
TLSCompressed: 2^{14} + 1024
TLSCiphertext: 2^{14} + 2048

These overhead values allow for expansion in these transforms
due to potential bad compression overhead or padding, etc.

Wan-Teh Chang points out that we no longer have compression
so there's no need to allow for 1024 bytes of expansion there.

Minimally we should reduce the TLSCiphertext overhead to
2^{14} + 1024. Do people believe that we will have AEAD
ciphers with 1024 bytes of expansion or should we reduce
it further? I'm inclined to not re-judge that and just leave it
at 2^{14} + 1024.

Thoughts?
-Ekr

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

--f46d04389533f9202804fe9fc638-- From nobody Sun Jul 20 07:52:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19081B2818 for ; Sun, 20 Jul 2014 07:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuspUf_AlKH7 for ; Sun, 20 Jul 2014 07:52:23 -0700 (PDT) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFD681B2816 for ; Sun, 20 Jul 2014 07:52:22 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id j7so4480568qaq.28 for ; Sun, 20 Jul 2014 07:52:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UN76WBkqBWdcfCSNfos/elBq0VhYSemS62dOuwLMRwI=; b=WfGjolJG1oFppwl8hhBGggWMse8l79GgYFJTLBtwMz3f9r2CSyV3bWtfYKa/7rMlnH XuFarmenWAgF1s58m6hoL2CJNRZkPwjPTky27ah1qtvra6jtB8tnBOW8FyesZ34qHgaj gVYcI2f7bBeLxm67XK/2Jcu+4+od4ibWcdRYFPLmZTKzCv3X8AlcnctdOa5xbxt1fO2o KQKZ8j9FN504MVOUqVVJ6IeGSYIvn+QckJQVE1GfwkfLMiX8xzehNA8q0B/H5E5q0wST RlI9jW21Z6PBhShYLFJmPycCC/DHDpF1biO+Bexzr4d+janwAL/RapnDmn6uot5yK/4m rGGg== X-Gm-Message-State: ALoCoQnybWUaEAHRdUv0kqPC9NoixvBEFGHmzHb7EWEsIe8PaeKidPeYfgWaECf3G+ZQn+RFnyki MIME-Version: 1.0 X-Received: by 10.140.43.245 with SMTP id e108mr28679077qga.76.1405867941903; Sun, 20 Jul 2014 07:52:21 -0700 (PDT) Received: by 10.140.108.75 with HTTP; Sun, 20 Jul 2014 07:52:21 -0700 (PDT) X-Originating-IP: [172.56.2.41] In-Reply-To: References: Date: Sun, 20 Jul 2014 10:52:21 -0400 Message-ID: From: "StJohns, Michael" To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113a666447912304fea123c2 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1Jv_EuQpe4eFOzw3TS1ZSP53JoY Cc: "tls@ietf.org" Subject: Re: [TLS] Reducing record expansion overhead allowance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2014 14:52:24 -0000 --001a113a666447912304fea123c2 Content-Type: text/plain; charset=UTF-8 The only other thing that hasn't been mentioned that was discussed at the interim in Denver is padding for traffic analysis resistance. That could hit 1k in size. But since there's no proposal that's just a guess on size. On Saturday, July 19, 2014, Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/issues/55 > > In TLS 1.2, we had the following maximum values: > > TLSPlaintext: 2^{14} > TLSCompressed: 2^{14} + 1024 > TLSCiphertext: 2^{14} + 2048 > > These overhead values allow for expansion in these transforms > due to potential bad compression overhead or padding, etc. > > Wan-Teh Chang points out that we no longer have compression > so there's no need to allow for 1024 bytes of expansion there. > > Minimally we should reduce the TLSCiphertext overhead to > 2^{14} + 1024. Do people believe that we will have AEAD > ciphers with 1024 bytes of expansion or should we reduce > it further? I'm inclined to not re-judge that and just leave it > at 2^{14} + 1024. > > Thoughts? > -Ekr > > --001a113a666447912304fea123c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The only other thing that hasn't been mentioned that was discussed at t= he interim in Denver=C2=A0is padding for traffic analysis resistance. That = could hit 1k in size. =C2=A0But since there's no proposal that's ju= st a guess on size. =C2=A0

On Saturday, July 19, 2014, Eric Rescorla <ekr@rtfm.com> wrote:

<= /div>In TLS 1.2, we had the following maximum values:

TL= SPlaintext: 2^{14}
TLSCompressed: 2^{14} + 1024
TLSCiphertext: 2^{14} + 2048

These overhead values allow for expansion in these t= ransforms
due to potential bad compression overhead or padding, e= tc.

Wan-Teh Chang points out that we no longer have compres= sion
so there's no need to allow for 1024 bytes of expansion = there.

Minimally we should reduce the TLSCiphertex= t overhead to
2^{14} + 1024. Do people believe that we will have AEAD
ciph= ers with 1024 bytes of expansion or should we reduce
it further? = I'm inclined to not re-judge that and just leave it
at 2^{14}= + 1024.

Thoughts?
-Ekr

--001a113a666447912304fea123c2-- From nobody Sun Jul 20 07:55:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4FA1B2818 for ; Sun, 20 Jul 2014 07:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MFKqm79C-ne for ; Sun, 20 Jul 2014 07:55:31 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 279731B2816 for ; Sun, 20 Jul 2014 07:55:31 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id b6so3247543yha.28 for ; Sun, 20 Jul 2014 07:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mSEo5YZCbHkU7FPei/GRnoDpcNp8FcVsr6o3pS63Hjw=; b=eGE0rGr8kz5plOv62n5ILn2Qjic4jMMIHfDBKiIHBzfAgAUIOdmXtYOdWOQp5B/UOg fxR0IEmNC7NvMU+vrHFTGCr6g6DYH35DfZNDey7af9IrWWESbUZKZJ2Viujvj+mowq4u tsBn1nyrkEk+yhJMK/EXWBn92ED0JCLYIyNQ0UMA4Ie2D+JJmZw4JBHuGaQnV5AgTOa7 x+7y5SXwfopct3SayU2A4r/hH1AREmwf4FkbGSEdXwzL9kU6CVcGNMBNztXwvKKtvlvF /NNsquXq5DiVawwMfcDj+2wQ2qQfcSa7dz8NGBe2dIBeS7mezYSDnVVOgkH0uyD5Q+ua NyrQ== MIME-Version: 1.0 X-Received: by 10.236.131.193 with SMTP id m41mr30538749yhi.96.1405868130449; Sun, 20 Jul 2014 07:55:30 -0700 (PDT) Received: by 10.170.219.10 with HTTP; Sun, 20 Jul 2014 07:55:30 -0700 (PDT) In-Reply-To: References: Date: Sun, 20 Jul 2014 16:55:30 +0200 Message-ID: From: Pascal Urien To: Eric Rescorla Content-Type: multipart/alternative; boundary=20cf3003bda284418004fea12ea2 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ieOMrg4ZYnSJIOkEuW9cddO4QX8 Cc: "tls@ietf.org" Subject: Re: [TLS] Interim Logistics X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2014 14:55:33 -0000 --20cf3003bda284418004fea12ea2 Content-Type: text/plain; charset=UTF-8 Hi Eric Sorry I missed this info I start from the IETF now and should be at the Mozilla Toronto at 11h20 Regards Pascal 2014-07-20 15:11 GMT+02:00 Eric Rescorla : > As mentioned previously, the interim will be at the Mozilla offices in > Toronto: > > Mozilla Toronto > http://www.mozilla.org/en-US/contact/spaces/toronto/ > 366 Adelaide St W, Suite 500 > Toronto, ON M5V 1R9 > Canada > > This is a locked building so we will have someone downstairs from about > 9:30 till 10:10 or so. After that, please message on IETF TLS Jabber and > someone will come down. > > -Ekr > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --20cf3003bda284418004fea12ea2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Eric

Sorry I missed this = info

I start from the IETF now and should be at th= e Mozilla Toronto at 11h20

Regards

Pascal


2014-07-20 15:11 GMT+02:00 Eric Rescorla <ekr@rtfm.com>= :
As mentioned previously, th= e interim will be at the Mozilla offices in Toronto:

Mozilla Toronto=
http://www= .mozilla.org/en-US/contact/spaces/toronto/
366 Adelaide= St W, Suite 500
Tor= onto, ON M5V 1R9
Canada

This is a locked =C2=A0building so we will have someone downs= tairs from about
9:30 till 10:10 or so. After that, pl= ease message on IETF TLS Jabber and
someone will come down.

-Ekr


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


--20cf3003bda284418004fea12ea2-- From nobody Sun Jul 20 09:00:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0BB1B2C62 for ; Sun, 20 Jul 2014 09:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3onYCig2f9Hk for ; Sun, 20 Jul 2014 09:00:00 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D52F41B2C56 for ; Sun, 20 Jul 2014 08:59:59 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id l18so5462855wgh.14 for ; Sun, 20 Jul 2014 08:59:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rjMRgXohGaL2w27pKGlAMWriihB2NbQYTJnTDvkYP0k=; b=R5E1mWikMUEjpHz7vgTpvcCzK/LG7+7+gdNCpYkjjY2IOvwFNByYyTZBafPfyPCSen 4W1MR0GYcEoU1Wdwb3SHplwe140jOOpjvkAeOWnkEBEgPFUWh+IKKcDt1qZHmY/niaK8 EK6GeL1aE1omFKjuXz8ajRhgA+fDHw4JNNH1k0Q4stUneYM0HQOrayK7Fgz6vCd0nCdI 9XJqsjQyO/58aKIav3XAbGCxxfEig/iPYnVxFOqDQF4sprFQ9qDlVIxhd++UoapvTUHx TT1Y2hXnvpF8KVqC/DqLmPFi8hzP8KXyz8PZLa0WMeKgu/WN858fvcRoq2Yun32nAlFQ gl0w== X-Gm-Message-State: ALoCoQmVHNcrw8x2w6SgoRTKTjjIeENMyjZNTaZNYgFbtM+IuN57/7DUW31F0iGEsCoYcaD0uSJF X-Received: by 10.194.91.228 with SMTP id ch4mr14513681wjb.59.1405871998311; Sun, 20 Jul 2014 08:59:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Sun, 20 Jul 2014 08:59:18 -0700 (PDT) X-Originating-IP: [2001:450:1f:232:8156:91cb:2632:185b] In-Reply-To: References: From: Eric Rescorla Date: Sun, 20 Jul 2014 08:59:18 -0700 Message-ID: To: "StJohns, Michael" Content-Type: multipart/alternative; boundary=047d7bd91d9e0f34b104fea215b5 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lG3tL9gmsHXykPg72Nx6HZpGkb0 Cc: "tls@ietf.org" Subject: Re: [TLS] Reducing record expansion overhead allowance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2014 16:00:04 -0000 --047d7bd91d9e0f34b104fea215b5 Content-Type: text/plain; charset=UTF-8 On Sun, Jul 20, 2014 at 7:52 AM, StJohns, Michael wrote: > The only other thing that hasn't been mentioned that was discussed at the > interim in Denver is padding for traffic analysis resistance. That could > hit 1k in size. But since there's no proposal that's just a guess on size. > I believe the consensus here was to have padding be done separately. -Ekr > > On Saturday, July 19, 2014, Eric Rescorla wrote: > >> https://github.com/tlswg/tls13-spec/issues/55 >> >> In TLS 1.2, we had the following maximum values: >> >> TLSPlaintext: 2^{14} >> TLSCompressed: 2^{14} + 1024 >> TLSCiphertext: 2^{14} + 2048 >> >> These overhead values allow for expansion in these transforms >> due to potential bad compression overhead or padding, etc. >> >> Wan-Teh Chang points out that we no longer have compression >> so there's no need to allow for 1024 bytes of expansion there. >> >> Minimally we should reduce the TLSCiphertext overhead to >> 2^{14} + 1024. Do people believe that we will have AEAD >> ciphers with 1024 bytes of expansion or should we reduce >> it further? I'm inclined to not re-judge that and just leave it >> at 2^{14} + 1024. >> >> Thoughts? >> -Ekr >> >> --047d7bd91d9e0f34b104fea215b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Jul 20, 2014 at 7:52 AM, StJohns, Michael <msj@nthpermutation.com= > wrote:
The only other thing that hasn't been me= ntioned that was discussed at the interim in Denver=C2=A0is padding for tra= ffic analysis resistance. That could hit 1k in size. =C2=A0But since there&= #39;s no proposal that's just a guess on size. =C2=A0

I believe the consensus here was to have padding be don= e separately.

-Ekr
=C2=A0

On Saturday, July 19, 2014, Eric Rescorla <ekr@rtfm.com> wrote:

<= /div>In TLS 1.2, we had the following maximum values:

TL= SPlaintext: 2^{14}
TLSCompressed: 2^{14} + 1024
TLSCiphertext: 2^{14} + 2048

These overhead values allow for expansion in these t= ransforms
due to potential bad compression overhead or padding, e= tc.

Wan-Teh Chang points out that we no longer have compres= sion
so there's no need to allow for 1024 bytes of expansion = there.

Minimally we should reduce the TLSCiphertex= t overhead to
2^{14} + 1024. Do people believe that we will have AEAD
ciph= ers with 1024 bytes of expansion or should we reduce
it further? = I'm inclined to not re-judge that and just leave it
at 2^{14}= + 1024.

Thoughts?
-Ekr


--047d7bd91d9e0f34b104fea215b5-- From nobody Sun Jul 20 09:09:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C8E1B2C78 for ; Sun, 20 Jul 2014 09:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgciFY_FBfrc for ; Sun, 20 Jul 2014 09:08:58 -0700 (PDT) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABF561B2C74 for ; Sun, 20 Jul 2014 09:08:58 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id a108so4629651qge.24 for ; Sun, 20 Jul 2014 09:08:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jjl4iEMDn1WzGyiGXqDryUHBkA4M9VZOE247LwQIkCg=; b=Ysbom2Et2TFATgZrN0F+IbnQqn9GnHHmEytdsRFbfYcP7g7SB3/pgG8pDbk95isJdo //0GkeEbFIuCK7CwP8LN4vRJ24CI+21su3PuDViKfIS66iy7Dovm2EH2MTNiRSmbPzNr 3UlkGJUTA7gDROyL8ZrV6jFDnjR6sC9YBiqzqt1m8fEX/LtiWDKEUWefvjMTSNm/XZPR 0gtB8FnSdVSAHN7HAfSV3N+uTHsvXo0znvaUh/ue6J9vhHw2sgt9dCPZ/rz5Qs/woFvF UIRb3ubQIpEIvU5g2pm+0CzWg4byB1k7XU0H9/KVNX5aYO4hcPsKE13Vl2QW4sz3wgu/ Rpuw== X-Gm-Message-State: ALoCoQn32rahWnMRYfCo9kXn/SIXnkBqb5wOg4b+181ZxWi5RlGr4p+hWXE4PsmDQFRKvsQETaby MIME-Version: 1.0 X-Received: by 10.224.92.83 with SMTP id q19mr30960343qam.29.1405872537468; Sun, 20 Jul 2014 09:08:57 -0700 (PDT) Received: by 10.140.108.75 with HTTP; Sun, 20 Jul 2014 09:08:57 -0700 (PDT) X-Originating-IP: [172.56.29.108] In-Reply-To: References: Date: Sun, 20 Jul 2014 12:08:57 -0400 Message-ID: From: "StJohns, Michael" To: Eric Rescorla Content-Type: multipart/alternative; boundary=089e0149cf94321db504fea235a1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ipGxRyfCr6Wbhjdbiwgf5E3JHI0 Cc: "tls@ietf.org" Subject: Re: [TLS] Reducing record expansion overhead allowance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2014 16:09:09 -0000 --089e0149cf94321db504fea235a1 Content-Type: text/plain; charset=UTF-8 You mean as part of the plain text? On Sunday, July 20, 2014, Eric Rescorla wrote: > On Sun, Jul 20, 2014 at 7:52 AM, StJohns, Michael > wrote: > >> The only other thing that hasn't been mentioned that was discussed at the >> interim in Denver is padding for traffic analysis resistance. That could >> hit 1k in size. But since there's no proposal that's just a guess on size. >> > > > I believe the consensus here was to have padding be done separately. > > -Ekr > > >> >> On Saturday, July 19, 2014, Eric Rescorla > > wrote: >> >>> https://github.com/tlswg/tls13-spec/issues/55 >>> >>> In TLS 1.2, we had the following maximum values: >>> >>> TLSPlaintext: 2^{14} >>> TLSCompressed: 2^{14} + 1024 >>> TLSCiphertext: 2^{14} + 2048 >>> >>> These overhead values allow for expansion in these transforms >>> due to potential bad compression overhead or padding, etc. >>> >>> Wan-Teh Chang points out that we no longer have compression >>> so there's no need to allow for 1024 bytes of expansion there. >>> >>> Minimally we should reduce the TLSCiphertext overhead to >>> 2^{14} + 1024. Do people believe that we will have AEAD >>> ciphers with 1024 bytes of expansion or should we reduce >>> it further? I'm inclined to not re-judge that and just leave it >>> at 2^{14} + 1024. >>> >>> Thoughts? >>> -Ekr >>> >>> > --089e0149cf94321db504fea235a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You mean as part of the plain text?

On Sunday, July 20, 2014, Eric R= escorla <ekr@rtfm.com> wrote:
=
On S= un, Jul 20, 2014 at 7:52 AM, StJohns, Michael <msj@nthpermutation.com> wrote:
The only other thing that hasn't been me= ntioned that was discussed at the interim in Denver=C2=A0is padding for tra= ffic analysis resistance. That could hit 1k in size. =C2=A0But since there&= #39;s no proposal that's just a guess on size. =C2=A0

I believe the consensus here was to have padding be don= e separately.

-Ekr
=C2=A0

On Saturday, July 19, 2014, Eric Rescorla <ekr@rtfm.= com> wrote:

<= /div>In TLS 1.2, we had the following maximum values:

TL= SPlaintext: 2^{14}
TLSCompressed: 2^{14} + 1024
TLSCiphertext: 2^{14} + 2048

These overhead values allow for expansion in these t= ransforms
due to potential bad compression overhead or padding, e= tc.

Wan-Teh Chang points out that we no longer have compres= sion
so there's no need to allow for 1024 bytes of expansion = there.

Minimally we should reduce the TLSCiphertex= t overhead to
2^{14} + 1024. Do people believe that we will have AEAD
ciph= ers with 1024 bytes of expansion or should we reduce
it further? = I'm inclined to not re-judge that and just leave it
at 2^{14}= + 1024.

Thoughts?
-Ekr


--089e0149cf94321db504fea235a1-- From nobody Sun Jul 20 09:11:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92ED61B2C7A for ; Sun, 20 Jul 2014 09:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PtNu57Z-3vc for ; Sun, 20 Jul 2014 09:11:00 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B335E1B2C7E for ; Sun, 20 Jul 2014 09:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=157; q=dns/txt; s=iport; t=1405872651; x=1407082251; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=tKBpQVuRTcIgRADwG/xFBVNM7PRnICKuptypGcW8VPQ=; b=MA4uj8fO1WzOuVbA3nsoHfYtdaAmW2mvSht4c6cyspDm32VykUL8jt0L mw2Y8fyJ63NbCJFOGN54wOx9cm22Km6gX+tIgSue7P8q7Qdk1l/VmvxbN 7SLVYcrSENYKZezwQpp3LWLksg+ifZ7YYN+Ky5V0dZuXOac2dBU0+MuED w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFAMDpy1OtJV2R/2dsb2JhbABZgw5SVwSNH7d/h0KBBxZ2hAo6UQE+QicEHIg5DZsKph4Xj02DM4EYBZsllC+DRGwBgUQ X-IronPort-AV: E=Sophos;i="5.01,695,1400025600"; d="scan'208";a="341457836" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP; 20 Jul 2014 16:10:45 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6KGAiN7022297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 20 Jul 2014 16:10:44 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Sun, 20 Jul 2014 11:10:44 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Interim Meeting Materials Thread-Index: AQHPpDUoXxATh6D/s02IjG9QxOLlaQ== Date: Sun, 20 Jul 2014 16:10:44 +0000 Message-ID: <42F1B6A2-BB07-41A1-90E4-5D3D12DBD2BE@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.85.164.220] Content-Type: text/plain; charset="us-ascii" Content-ID: <05CFF56E1F54AA48A865CD7010FCD05D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IMGLpm4AV6S3_3bQDrKtlDTeFco Subject: [TLS] Interim Meeting Materials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2014 16:11:05 -0000 Interim meeting materials can be found at: http://www.ietf.org/proceedings/interim/2014/07/20/tls/proceedings.html or=20 https://github.com/tlswg/ From nobody Sun Jul 20 09:16:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE951B2C7B for ; Sun, 20 Jul 2014 09:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZINe4TdiDlIP for ; Sun, 20 Jul 2014 09:16:06 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A129C1A0B0B for ; Sun, 20 Jul 2014 09:16:05 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b13so5477753wgh.22 for ; Sun, 20 Jul 2014 09:16:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2zR5f+BumvgT7pUwjBd5cW1BtoRmkAAbc/MlY4ShKmM=; b=jD70K11HP59QOn6cZjh9r2ksv5662/zrG0lLCBaIPTvsRGAUB6LalsuDa8HmNl6Hdd Cw60+sknELI35ALLfvIE4nvcpnn/EHg3ZOjMA+nEM+GzH2fHgj9BlyabEU5ExCRKVVq6 TCn+h4BOgjFfmod/6eyNjR9m5t1Bl7+oDA0JRzW8H2tnmFDEpNijf9oyOKwvHTgXUM1X 1YFBboDaQKvui6OllCe43eGUCSfvqldNpYXKZNOqUHnl33AA1DtSdf1pfqS7QKnVAXOv q2CP+kLNb88AXygbkW1WCwSh5HVxknsyvxiFacfnAvJ0V7eeZp8pJUBdQ9V+s6SXGxuH RZDw== X-Gm-Message-State: ALoCoQlO9IQUCj+J3jqs3f9jJQ4br237IxfakjmaOqGx3eh/Y0q5CBjSjmWC6tEDN05YrbXeLTDk X-Received: by 10.194.184.200 with SMTP id ew8mr14232888wjc.61.1405872964280; Sun, 20 Jul 2014 09:16:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Sun, 20 Jul 2014 09:15:24 -0700 (PDT) X-Originating-IP: [2001:450:1f:232:8156:91cb:2632:185b] In-Reply-To: References: From: Eric Rescorla Date: Sun, 20 Jul 2014 09:15:24 -0700 Message-ID: To: "StJohns, Michael" Content-Type: multipart/alternative; boundary=047d7bb03940a2bc8104fea24ea7 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AGD4gM63NxJgrJjPUamM5ccZg1s Cc: "tls@ietf.org" Subject: Re: [TLS] Reducing record expansion overhead allowance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2014 16:16:07 -0000 --047d7bb03940a2bc8104fea24ea7 Content-Type: text/plain; charset=UTF-8 On Sun, Jul 20, 2014 at 9:08 AM, StJohns, Michael wrote: > You mean as part of the plain text? >From the perspective of the AEAD algorithm, yes. -Ekr > > On Sunday, July 20, 2014, Eric Rescorla wrote: > >> On Sun, Jul 20, 2014 at 7:52 AM, StJohns, Michael > > wrote: >> >>> The only other thing that hasn't been mentioned that was discussed at >>> the interim in Denver is padding for traffic analysis resistance. That >>> could hit 1k in size. But since there's no proposal that's just a guess on >>> size. >> >> >> I believe the consensus here was to have padding be done separately. >> >> -Ekr >> >> >>> >>> On Saturday, July 19, 2014, Eric Rescorla wrote: >>> >>>> https://github.com/tlswg/tls13-spec/issues/55 >>>> >>>> In TLS 1.2, we had the following maximum values: >>>> >>>> TLSPlaintext: 2^{14} >>>> TLSCompressed: 2^{14} + 1024 >>>> TLSCiphertext: 2^{14} + 2048 >>>> >>>> These overhead values allow for expansion in these transforms >>>> due to potential bad compression overhead or padding, etc. >>>> >>>> Wan-Teh Chang points out that we no longer have compression >>>> so there's no need to allow for 1024 bytes of expansion there. >>>> >>>> Minimally we should reduce the TLSCiphertext overhead to >>>> 2^{14} + 1024. Do people believe that we will have AEAD >>>> ciphers with 1024 bytes of expansion or should we reduce >>>> it further? I'm inclined to not re-judge that and just leave it >>>> at 2^{14} + 1024. >>>> >>>> Thoughts? >>>> -Ekr >>>> >>>> >> --047d7bb03940a2bc8104fea24ea7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Jul 20, 2014 at 9:08 AM, StJohns, Michael <msj@nthpermutation.com= > wrote:
You mean as part of the plain text?

From the perspective of the AEAD algorithm, yes.

-Ekr
=C2=A0

On Sunday, July 20, 2014, Er= ic Rescorla <ekr@rtfm.= com> wrote:
On S= un, Jul 20, 2014 at 7:52 AM, StJohns, Michael <msj@= nthpermutation.com> wrote:
The only other thing that hasn't been me= ntioned that was discussed at the interim in Denver=C2=A0is padding for tra= ffic analysis resistance. That could hit 1k in size. =C2=A0But since there&= #39;s no proposal that's just a guess on size. =C2=A0

I believe the consensus here was to have padding be don= e separately.

-Ekr
=C2=A0

On Saturday, July 19, 2014, Eric Rescorla <ekr@rtfm.com> w= rote:

<= /div>In TLS 1.2, we had the following maximum values:

TL= SPlaintext: 2^{14}
TLSCompressed: 2^{14} + 1024
TLSCiphertext: 2^{14} + 2048

These overhead values allow for expansion in these t= ransforms
due to potential bad compression overhead or padding, e= tc.

Wan-Teh Chang points out that we no longer have compres= sion
so there's no need to allow for 1024 bytes of expansion = there.

Minimally we should reduce the TLSCiphertex= t overhead to
2^{14} + 1024. Do people believe that we will have AEAD
ciph= ers with 1024 bytes of expansion or should we reduce
it further? = I'm inclined to not re-judge that and just leave it
at 2^{14}= + 1024.

Thoughts?
-Ekr



--047d7bb03940a2bc8104fea24ea7-- From nobody Sun Jul 20 09:21:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330741B2C7A for ; Sun, 20 Jul 2014 09:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0pHUNGQF2YQ for ; Sun, 20 Jul 2014 09:21:36 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F198F1B2828 for ; Sun, 20 Jul 2014 09:21:35 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id j15so4540575qaq.29 for ; Sun, 20 Jul 2014 09:21:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=En6Mfcc66o+WRTsqkG7fizTDISWEyeRVnQH8XMz9BGU=; b=Fu6Wz+QJC6LZtPrPsH/N/Pnh8qoU5V6YIYQ753WF8wIHYfcP6xVIE44rk9A2IJ/zGH kJx4boj+eU0o+pebeiUGQnra8j4Dg0T9g38HRMcaSeBRB6yNNThtc1QNVNxguaH9goLE ZZybWvI/3aYfZ2S8tyluieuY41TQVxiTZ9I1obOUOpz1D4YQ/jgf7SHUJx7T2v5eMi08 oLd5aSBFDl1RlORY+aj3lKcv13btGS1A27QRIhiC0kkliVWHWP4xFM+SrvcxWSRGuwgN vCaHD4e3Zwps5+5MQwNMM/ZYo2o227PgaIKeyV+qdv5cJSm9BqpTh0OpMZ7CxlljhOLr TJrw== X-Gm-Message-State: ALoCoQnbgfhl0MZGDFdi4BH3iTAtAAFUDhVtVHvEvQRgF6LfVaGuHAItCldFTQCzg8NBo3CTcWF0 MIME-Version: 1.0 X-Received: by 10.224.11.130 with SMTP id t2mr32157645qat.101.1405873293543; Sun, 20 Jul 2014 09:21:33 -0700 (PDT) Received: by 10.140.108.75 with HTTP; Sun, 20 Jul 2014 09:21:33 -0700 (PDT) X-Originating-IP: [172.56.29.108] In-Reply-To: References: Date: Sun, 20 Jul 2014 12:21:33 -0400 Message-ID: From: "StJohns, Michael" To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11c1d96a42e20b04fea262cd Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LQHi4zUpQH8lRE5RsdAf6ZRDGRk Cc: "tls@ietf.org" Subject: Re: [TLS] Reducing record expansion overhead allowance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2014 16:21:38 -0000 --001a11c1d96a42e20b04fea262cd Content-Type: text/plain; charset=UTF-8 So then not really a TLS issue, but has to be supported by each application and is transparent to TLS? Ok - Thanks. On Sunday, July 20, 2014, Eric Rescorla wrote: > On Sun, Jul 20, 2014 at 9:08 AM, StJohns, Michael > wrote: > >> You mean as part of the plain text? > > > From the perspective of the AEAD algorithm, yes. > > -Ekr > > >> >> On Sunday, July 20, 2014, Eric Rescorla > > wrote: >> >>> On Sun, Jul 20, 2014 at 7:52 AM, StJohns, Michael < >>> msj@nthpermutation.com> wrote: >>> >>>> The only other thing that hasn't been mentioned that was discussed at >>>> the interim in Denver is padding for traffic analysis resistance. That >>>> could hit 1k in size. But since there's no proposal that's just a guess on >>>> size. >>> >>> >>> I believe the consensus here was to have padding be done separately. >>> >>> -Ekr >>> >>> >>>> >>>> On Saturday, July 19, 2014, Eric Rescorla wrote: >>>> >>>>> https://github.com/tlswg/tls13-spec/issues/55 >>>>> >>>>> In TLS 1.2, we had the following maximum values: >>>>> >>>>> TLSPlaintext: 2^{14} >>>>> TLSCompressed: 2^{14} + 1024 >>>>> TLSCiphertext: 2^{14} + 2048 >>>>> >>>>> These overhead values allow for expansion in these transforms >>>>> due to potential bad compression overhead or padding, etc. >>>>> >>>>> Wan-Teh Chang points out that we no longer have compression >>>>> so there's no need to allow for 1024 bytes of expansion there. >>>>> >>>>> Minimally we should reduce the TLSCiphertext overhead to >>>>> 2^{14} + 1024. Do people believe that we will have AEAD >>>>> ciphers with 1024 bytes of expansion or should we reduce >>>>> it further? I'm inclined to not re-judge that and just leave it >>>>> at 2^{14} + 1024. >>>>> >>>>> Thoughts? >>>>> -Ekr >>>>> >>>>> >>> > --001a11c1d96a42e20b04fea262cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So then not really a TLS issue, but has to be supported by each application= and is transparent to TLS? =C2=A0 Ok - Thanks. =C2=A0

On Sunday, Ju= ly 20, 2014, Eric Rescorla <ekr@rtfm.com= > wrote:
=
On Sun, Jul 20, 2014 at 9:08 AM, StJohns, Michae= l <msj@nthpermutation.com> wrote:
You mean as part of the plain text?

From the perspective of the AEAD algorithm, yes.

-Ekr
=C2=A0

On Sunday, July 20, 2014, Eric Rescorla <ekr@rtfm.com> wrote:
On S= un, Jul 20, 2014 at 7:52 AM, StJohns, Michael <msj@= nthpermutation.com> wrote:
The only other thing that hasn't been me= ntioned that was discussed at the interim in Denver=C2=A0is padding for tra= ffic analysis resistance. That could hit 1k in size. =C2=A0But since there&= #39;s no proposal that's just a guess on size. =C2=A0

I believe the consensus here was to have padding be don= e separately.

-Ekr
=C2=A0

On Saturday, July 19, 2014, Eric Rescorla <ekr@rtfm.com> w= rote:

<= /div>In TLS 1.2, we had the following maximum values:

TL= SPlaintext: 2^{14}
TLSCompressed: 2^{14} + 1024
TLSCiphertext: 2^{14} + 2048

These overhead values allow for expansion in these t= ransforms
due to potential bad compression overhead or padding, e= tc.

Wan-Teh Chang points out that we no longer have compres= sion
so there's no need to allow for 1024 bytes of expansion = there.

Minimally we should reduce the TLSCiphertex= t overhead to
2^{14} + 1024. Do people believe that we will have AEAD
ciph= ers with 1024 bytes of expansion or should we reduce
it further? = I'm inclined to not re-judge that and just leave it
at 2^{14}= + 1024.

Thoughts?
-Ekr



--001a11c1d96a42e20b04fea262cd-- From nobody Sun Jul 20 11:50:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5A11B2C98 for ; Sun, 20 Jul 2014 11:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztjSjRr84xy9 for ; Sun, 20 Jul 2014 11:50:26 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8C341B2946 for ; Sun, 20 Jul 2014 11:50:26 -0700 (PDT) Received: by mail-yk0-f172.google.com with SMTP id 10so3412242ykt.17 for ; Sun, 20 Jul 2014 11:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gSScf/W3eKKpWwfho6joE5UWoShroY3CPpCt/CuBPZQ=; b=i9F0Qsi3sPoVUDzl8CK/RvuGY3rfNkHum1A29ZJUj0YsxVjz12BX0nTrMBQHX8XTLL MR1hZzKRI7SjqrMrGav+UOfJt9MRiCYxz75QSnVKuuca6e143H3GjJMnHowxDNFtNmc/ ndo6PntVZNSrASEiHtFSATWN/K6DrcITczP2KpESKStyfaOrWb6Cgy3fVEetc2TnsUlS n93MKkauHb56zohwAe7I6ikR9JaShv9bdeEPG3F+SqBmm+a/k/Gni5CH3KEUAUdn6xP7 wiM87XCjVt2DpfapP/QInhSeeCmq0783mpMGDDgtlv+ke0QRrz6nUovnkKgc1mx5DqAe GMSg== MIME-Version: 1.0 X-Received: by 10.236.37.97 with SMTP id x61mr30780002yha.87.1405882225877; Sun, 20 Jul 2014 11:50:25 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Sun, 20 Jul 2014 11:50:25 -0700 (PDT) Date: Sun, 20 Jul 2014 11:50:25 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Msj7qSe7o-5qeSYokD_yJsqsykA Subject: [TLS] Don't fix Triple Handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 18:50:28 -0000 Instead, create a secure key exchange protocol. Actually, don't do that: just steal one. Why is this a good idea? 1: Get to use analysis work already done 2: Avoids making mistakes 3: Now that CCS and Finished is potentially on the chopping block, we can actually make a key exchange protocol satisfying standard properties, and couple to a record layer that is secure, about 20 years too late. Sincerely, Watson Ladd (Note that we need an additional property: as Hugo Krawczyk was kind enough to point out to me channel binding is not necessarily supported by any key-exchange protocol) From nobody Sun Jul 20 11:56:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020C01B2CB8; Sun, 20 Jul 2014 11:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5e5SAgAHRBz; Sun, 20 Jul 2014 11:56:27 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E64991B2CA7; Sun, 20 Jul 2014 11:56:26 -0700 (PDT) Received: from BL2PR03MB242.namprd03.prod.outlook.com (10.255.231.18) by BL2PR03MB243.namprd03.prod.outlook.com (10.255.231.23) with Microsoft SMTP Server (TLS) id 15.0.990.7; Sun, 20 Jul 2014 18:56:25 +0000 Received: from BL2PR03MB242.namprd03.prod.outlook.com ([169.254.8.232]) by BL2PR03MB242.namprd03.prod.outlook.com ([169.254.8.232]) with mapi id 15.00.0990.007; Sun, 20 Jul 2014 18:56:25 +0000 From: Brian LaMacchia To: "tls@ietf.org" , "cfrg@ietf.org" Thread-Topic: V1.1 of MSR ECCLib for NUMS Curves library released (now supporting GCC on Linux) Thread-Index: Ac+kTESvmkQ17PaKRGm9P1nDdxWNMQ== Date: Sun, 20 Jul 2014 18:56:25 +0000 Message-ID: <32919a77a6ba4b2aab3c446b087ad979@BL2PR03MB242.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.166.41.173] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02788FF38E x-forefront-antispam-report: SFV:NSPM; SFS:(164054003)(377454003)(13464003)(243025005)(189002)(199002)(26614003)(105586002)(16236675004)(77096002)(19300405004)(79102001)(15975445006)(83322001)(85306003)(106356001)(31966008)(95666004)(99286002)(74502001)(74662001)(21056001)(83072002)(77982001)(46102001)(4396001)(92566001)(85852003)(107886001)(76576001)(81542001)(33646002)(19617315012)(81342001)(74316001)(86612001)(54356999)(19625215002)(50986999)(19580405001)(19580395003)(87936001)(15202345003)(86362001)(229853001)(76482001)(101416001)(107046002)(2656002)(99396002)(20776003)(64706001)(66066001)(80022001)(108616002)(42262001)(24736002)(9853045004); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB243; H:BL2PR03MB242.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_32919a77a6ba4b2aab3c446b087ad979BL2PR03MB242namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1pDtlOJo27B4_yj6HkDnKf9UJJg Subject: [TLS] V1.1 of MSR ECCLib for NUMS Curves library released (now supporting GCC on Linux) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2014 18:56:38 -0000 --_000_32919a77a6ba4b2aab3c446b087ad979BL2PR03MB242namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Microsoft Research is pleased to announce the release of v1.1 of the MSR El= liptic Curve Cryptography Library for NUMS curves. Please visit http://research.microsoft.com/en-us/projects/nums/ for full details and download links. New features in v1.1 include: * GCC support on Linux: The new pre-assembly files .S located in <= LibraryPath>/MSR_ECCLib/AMD64 are compatible with both GNU GCC (GAS assembl= er) and MSVS (MASM assembler) compilers * New API for ephemeral elliptic curve Diffie-Hellman key exchange = (ECDHE) * New tests for ECDHE * Simplified API for some ECC scalar multiplication functions * Extended support to any x64 processor We welcome questions/comments/feedback on this library; please send them to= msrsc@microsoft.com. Thanks, = --bal -----Original Message----- From: Brian LaMacchia Sent: Monday, June 30, 2014 3:58 AM To: cfrg@ietf.org; tls@ietf.org Subject: Announcing the availability of the MSR Elliptic Curve Cryptography= Library for NUMS Curves Dear members of the IRTF CFRG and the IETF TLS WG, On behalf of the Microsoft Research ECCLib Project, I am pleased to announc= e the first release of the Microsoft Research Elliptic Curve Cryptography L= ibrary (ECCLib) for NUMS ("Nothing Up My Sleeve") curves. We are releasing= ECCLib under the Apache 2.0 License. Here is a link to the project page a= nd download location: http://research.microsoft.com/en-us/projects/nums/ The MSR ECCLib is an efficient cryptography library that provides functions= for computing essential elliptic curve operations on a new set of high-sec= urity curves as previously described in [1] and presented at the CFRG Sprin= g 2014 Interim Meeting (see [2] for a copy of the slides from that presenta= tion). All computations in ECCLib on secret data exhibit regular, constant= -time execution, providing protection against timing and cache attacks. ECCLib supports six high-security elliptic curves proposed in [1], which co= ver three security levels (128-, 192-, and 256-bit security) and two curve = models. The curves have a very simple and deterministic generation with min= imal room for parameter manipulation. ECCLib includes all the ECC function= s necessary to implement most popular elliptic curve-based schemes. In part= icular, ECCLib supports the computation of scalar multiplication for the si= x curves above in three variants: 1. Variable-base scalar multiplication (e.g., this is used = for computing the shared key in the Diffie-Hellman key exchange). 2. Fixed-base scalar multiplication (e.g., this is used for= key generation in the Diffie-Hellman key exchange). 3. Double-scalar multiplication. This operation is typicall= y used for verifying signatures. As both the CFRG and the TLS WG are currently considering additional curves= for elliptic curve cryptography, we hope that this contribution (in additi= on to the technical paper previously presented) will further a thoughtful d= iscussion concerning what new curves CFRG should recommend and TLS should c= onsider for inclusion. We welcome questions/comments/feedback on this libr= ary; please send them to msrsc@microsoft.com. Please Note: the version of ECCLib that we are releasing today is for x64 p= latforms with AVX and builds with the Microsoft Visual Studio toolchain. W= e are actively working on both a version that builds with GCC and also a po= rtable C version and hope to add these to the release in the near future. Thanks, = --bal [1] Joppe W. Bos, Craig Costello, Patrick Longa and Michael Naehrig, "Selec= ting Elliptic Curves for Cryptography: An Efficiency and Security Analysis"= , Cryptology ePrint Archive: Report 2014/130. Available at: http://eprint.i= acr.org/2014/130 [2] http://patricklonga.webs.com/Presentation_CFRG_Selecting_Elliptic_Curve= s_for_Cryptography.pdf --_000_32919a77a6ba4b2aab3c446b087ad979BL2PR03MB242namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Microsoft Research is pleased to announce the rel= ease of v1.1 of the MSR Elliptic Curve Cryptography Library for NUMS curves= .  Please visit

 

http://research.microsoft.com/en-us/projects/nums/

 

for full details and download links.  New fe= atures in v1.1 include:

 

·         GCC support on Linux:  The new pre-asse= mbly files .S located in <LibraryPath>/MSR_ECCLib/AMD64 are compatibl= e with both GNU GCC (GAS assembler) and MSVS (MASM assembler) compilers

·         New API for ephemeral elliptic curve Diffie-= Hellman key exchange (ECDHE)

·         New tests for ECDHE

·         Simplified API for some ECC scalar multiplic= ation functions

·         Extended support to any x64 processor

 

We welcome questions/comments/feedback on this li= brary; please send them to msrsc@microsoft.com.

 

Thanks,

 

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;         --bal

 =

-----Original Message-----
From: Brian LaMacchia
Sent: Monday, June 30, 2014 3:58 AM
To: cfrg@ietf.org; tls@ietf.org
Subject: Announcing the availability of the MSR Elliptic Curve Cryptography= Library for NUMS Curves

 

Dear members of the IRTF CFRG and the IETF TLS WG= ,

 

On behalf of the Microsoft Research ECCLib Projec= t, I am pleased to announce the first release of the Microsoft Research Ell= iptic Curve Cryptography Library (ECCLib) for NUMS (“Nothing Up My Sl= eeve”) curves.  We are releasing ECCLib under the Apache 2.0 License.  Here is a link to the project page and= download location:

 

http://= research.microsoft.com/en-us/projects/nums/ 

 

The MSR ECCLib is an efficient cryptography libra= ry that provides functions for computing essential elliptic curve operation= s on a new set of high-security curves as previously described in [1] and p= resented at the CFRG Spring 2014 Interim Meeting (see [2] for a copy of the slides from that presentation).  A= ll computations in ECCLib on secret data exhibit regular, constant-time exe= cution, providing protection against timing and cache attacks.

 

ECCLib supports six high-security elliptic curves= proposed in [1], which cover three security levels (128-, 192-, and 256-bi= t security) and two curve models. The curves have a very simple and determi= nistic generation with minimal room for parameter manipulation.  ECCLib includes all the ECC functions ne= cessary to implement most popular elliptic curve-based schemes. In particul= ar, ECCLib supports the computation of scalar multiplication for the six cu= rves above in three variants:

        &= nbsp;       1. Variable-base scalar multiplic= ation (e.g., this is used for computing the shared key in the Diffie-Hellma= n key exchange).

        &= nbsp;       2. Fixed-base scalar multiplicati= on (e.g., this is used for key generation in the Diffie-Hellman key exchang= e).

        &= nbsp;       3. Double-scalar multiplication. = This operation is typically used for verifying signatures.

 

As both the CFRG and the TLS WG are currently con= sidering additional curves for elliptic curve cryptography, we hope that th= is contribution (in addition to the technical paper previously presented) w= ill further a thoughtful discussion concerning what new curves CFRG should recommend and TLS should consider f= or inclusion.  We welcome questions/comments/feedback on this library;= please send them to msrsc@microsoft.com.

 

Please Note: the version of ECCLib that we are re= leasing today is for x64 platforms with AVX and builds with the Microsoft V= isual Studio toolchain.  We are actively working on both a version tha= t builds with GCC and also a portable C version and hope to add these to the release in the near future.

 

Thanks,

 

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;         --bal

 

[1] Joppe W. Bos, Craig Costello, Patrick Longa a= nd Michael Naehrig, “Selecting Elliptic Curves for Cryptography: An E= fficiency and Security Analysis”, Cryptology ePrint Archive: Report 2= 014/130. Available at: http://eprint.iacr.org/2014/130

 

[2] http://patricklonga.w= ebs.com/Presentation_CFRG_Selecting_Elliptic_Curves_for_Cryptography.pdf

 

 

--_000_32919a77a6ba4b2aab3c446b087ad979BL2PR03MB242namprd03pro_-- From nobody Sun Jul 20 12:21:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C711B29B1; Sun, 20 Jul 2014 12:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1N3zgAscMA4; Sun, 20 Jul 2014 12:21:44 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D051B296C; Sun, 20 Jul 2014 12:21:44 -0700 (PDT) Received: from [192.168.10.128] ([66.207.208.102]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MFu0Y-1XLbbY0GCE-00EwDs; Sun, 20 Jul 2014 21:21:38 +0200 Message-ID: <53CC16BF.3080108@gmx.net> Date: Sun, 20 Jul 2014 21:21:35 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian LaMacchia , "tls@ietf.org" , "cfrg@ietf.org" References: <32919a77a6ba4b2aab3c446b087ad979@BL2PR03MB242.namprd03.prod.outlook.com> In-Reply-To: <32919a77a6ba4b2aab3c446b087ad979@BL2PR03MB242.namprd03.prod.outlook.com> X-Enigmail-Version: 1.5.2 OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gKvR9uL9QCjw2pEh3haRj3cLBs7hhCiXk" X-Provags-ID: V03:K0:kcanRWmfn29/GHSrROVSHmTa3EOdiUqWNLIw1xWb04GgP/cEtRy YQsRyyiBgBkURLdmrcjjwFh8g4b/eXyacjfDUPZutSWuuYIcq+ZiF++v0RP5CzCfyQjkFRE mSjOP7jFDqVnEj3RGGGDKsbMtDPFQHpHqDmbG1RzJW1/2xcqrBqmhlQfhIosxTC69x3PD2i 29NXK+aIXbujra9fD2tkQ== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9xn-NWlBro34RIGFQwpDk3Z1Szk Subject: Re: [TLS] [Cfrg] V1.1 of MSR ECCLib for NUMS Curves library released (now supporting GCC on Linux) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2014 19:21:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gKvR9uL9QCjw2pEh3haRj3cLBs7hhCiXk Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Brian, thanks for sharing the code. I am wondering whether you also have a version that does not make use of assembler code since I cannot run this code on 32-bit ARM processors. Ciao Hannes On 07/20/2014 08:56 PM, Brian LaMacchia wrote: > Folks, >=20 > =20 >=20 > Microsoft Research is pleased to announce the release of v1.1 of the MS= R > Elliptic Curve Cryptography Library for NUMS curves. Please visit >=20 > =20 >=20 > http://research.microsoft.com/en-us/projects/nums/ >=20 > =20 >=20 > for full details and download links. New features in v1.1 include: >=20 > =20 >=20 > =B7 GCC support on Linux: The new pre-assembly files .S locate= d > in /MSR_ECCLib/AMD64 are compatible with both GNU GCC (GAS= > assembler) and MSVS (MASM assembler) compilers >=20 > =B7 New API for ephemeral elliptic curve Diffie-Hellman key > exchange (ECDHE) >=20 > =B7 New tests for ECDHE >=20 > =B7 Simplified API for some ECC scalar multiplication functions= >=20 > =B7 Extended support to any x64 processor >=20 > =20 >=20 > We welcome questions/comments/feedback on this library; please send the= m > to msrsc@microsoft.com . >=20 > =20 >=20 > Thanks, >=20 > =20 >=20 > = =20 > --bal >=20 > =20 >=20 > -----Original Message----- > From: Brian LaMacchia > Sent: Monday, June 30, 2014 3:58 AM > To: cfrg@ietf.org; tls@ietf.org > Subject: Announcing the availability of the MSR Elliptic Curve > Cryptography Library for NUMS Curves >=20 > =20 >=20 > Dear members of the IRTF CFRG and the IETF TLS WG, >=20 > =20 >=20 > On behalf of the Microsoft Research ECCLib Project, I am pleased to > announce the first release of the Microsoft Research Elliptic Curve > Cryptography Library (ECCLib) for NUMS (=93Nothing Up My Sleeve=94) cur= ves.=20 > We are releasing ECCLib under the Apache 2.0 License. Here is a link t= o > the project page and download location: >=20 > =20 >=20 > http://research.microsoft.com/en-us/projects/nums/=20 >=20 > =20 >=20 > The MSR ECCLib is an efficient cryptography library that provides > functions for computing essential elliptic curve operations on a new se= t > of high-security curves as previously described in [1] and presented at= > the CFRG Spring 2014 Interim Meeting (see [2] for a copy of the slides > from that presentation). All computations in ECCLib on secret data > exhibit regular, constant-time execution, providing protection against > timing and cache attacks. >=20 > =20 >=20 > ECCLib supports six high-security elliptic curves proposed in [1], whic= h > cover three security levels (128-, 192-, and 256-bit security) and two > curve models. The curves have a very simple and deterministic generatio= n > with minimal room for parameter manipulation. ECCLib includes all the > ECC functions necessary to implement most popular elliptic curve-based > schemes. In particular, ECCLib supports the computation of scalar > multiplication for the six curves above in three variants: >=20 > 1. Variable-base scalar multiplication (e.g., this is > used for computing the shared key in the Diffie-Hellman key exchange). >=20 > 2. Fixed-base scalar multiplication (e.g., this is used= > for key generation in the Diffie-Hellman key exchange). >=20 > 3. Double-scalar multiplication. This operation is > typically used for verifying signatures. >=20 > =20 >=20 > As both the CFRG and the TLS WG are currently considering additional > curves for elliptic curve cryptography, we hope that this contribution > (in addition to the technical paper previously presented) will further = a > thoughtful discussion concerning what new curves CFRG should recommend > and TLS should consider for inclusion. We welcome > questions/comments/feedback on this library; please send them to > msrsc@microsoft.com . >=20 > =20 >=20 > Please Note: the version of ECCLib that we are releasing today is for > x64 platforms with AVX and builds with the Microsoft Visual Studio > toolchain. We are actively working on both a version that builds with > GCC and also a portable C version and hope to add these to the release > in the near future. >=20 > =20 >=20 > Thanks, >=20 > =20 >=20 > = =20 > --bal >=20 > =20 >=20 > [1] Joppe W. Bos, Craig Costello, Patrick Longa and Michael Naehrig, > =93Selecting Elliptic Curves for Cryptography: An Efficiency and Securi= ty > Analysis=94, Cryptology ePrint Archive: Report 2014/130. Available at: > http://eprint.iacr.org/2014/130 >=20 > =20 >=20 > [2] > http://patricklonga.webs.com/Presentation_CFRG_Selecting_Elliptic_Curve= s_for_Cryptography.pdf >=20 > =20 >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg >=20 --gKvR9uL9QCjw2pEh3haRj3cLBs7hhCiXk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTzBa/AAoJEGhJURNOOiAtixoH/1Q3CALDlO0I81T120R4a4CL am8kLand1TVmngWbJqZLl+LWqVXP9+p9vfXCoGiDJmIE/HFfTVWI19dwTYwXBKBO S9anUCczy2djEuSc+2DFD6aGEu5RSyYK4oQ9+i0ujo3YKoD5op+2Hl4OuYxuoUGI 28eEjIlJ0YCITeC8T5IZbim4cJJrmUq4fA482Uf9PnYNI1oqkRx8lD/UFn6jc6Cg G/lKvf5gT6A5zuaJCh46vF7wxXJbYgtd3Z1NDLdTNPO5R8xfcY0dOQIAg9BcO9A5 TM7AlXmjAWQ9TIjQHr+yinRMu8A0Pj6Xba3aL90yVJGa4CR2kEvuf7fEd4jWAVM= =BrD8 -----END PGP SIGNATURE----- --gKvR9uL9QCjw2pEh3haRj3cLBs7hhCiXk-- From nobody Sun Jul 20 12:39:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C302D1B29D8; Sun, 20 Jul 2014 12:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mm2YMZ6yjyTz; Sun, 20 Jul 2014 12:39:52 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0140.outbound.protection.outlook.com [207.46.163.140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92EC91B29F3; Sun, 20 Jul 2014 12:39:49 -0700 (PDT) Received: from BL2PR03MB242.namprd03.prod.outlook.com (10.255.231.18) by BL2PR03MB243.namprd03.prod.outlook.com (10.255.231.23) with Microsoft SMTP Server (TLS) id 15.0.990.7; Sun, 20 Jul 2014 19:39:47 +0000 Received: from BL2PR03MB242.namprd03.prod.outlook.com ([169.254.8.232]) by BL2PR03MB242.namprd03.prod.outlook.com ([169.254.8.232]) with mapi id 15.00.0990.007; Sun, 20 Jul 2014 19:39:46 +0000 From: Brian LaMacchia To: Hannes Tschofenig , "tls@ietf.org" , "cfrg@ietf.org" Thread-Topic: [Cfrg] V1.1 of MSR ECCLib for NUMS Curves library released (now supporting GCC on Linux) Thread-Index: Ac+kTESvmkQ17PaKRGm9P1nDdxWNMQAA41WAAAAkyHA= Date: Sun, 20 Jul 2014 19:39:45 +0000 Message-ID: <45fdc0b2d9754990aa70d9d92d349c84@BL2PR03MB242.namprd03.prod.outlook.com> References: <32919a77a6ba4b2aab3c446b087ad979@BL2PR03MB242.namprd03.prod.outlook.com> <53CC16BF.3080108@gmx.net> In-Reply-To: <53CC16BF.3080108@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.166.41.173] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02788FF38E x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(26614003)(13464003)(52604005)(164054003)(377454003)(51704005)(479174003)(189002)(24454002)(199002)(74316001)(86612001)(54356999)(81342001)(50986999)(87936001)(19580395003)(19580405001)(107886001)(76576001)(81542001)(33646002)(64706001)(2656002)(76176999)(99396002)(20776003)(66066001)(80022001)(86362001)(15202345003)(101416001)(107046002)(76482001)(106356001)(31966008)(83322001)(85306003)(95666004)(99286002)(77096002)(105586002)(15975445006)(19273905006)(79102001)(83072002)(21056001)(46102001)(2201001)(77982001)(92566001)(85852003)(4396001)(74502001)(74662001)(108616002)(42262001)(24736002)(563064011)(9853045004); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB243; H:BL2PR03MB242.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ryDjq9i3Qq5l85rv-UCxhXnlMgQ Subject: Re: [TLS] [Cfrg] V1.1 of MSR ECCLib for NUMS Curves library released (now supporting GCC on Linux) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2014 19:39:55 -0000 Hi Hannes, Thanks very much for your interest and yes we are working on a portable C v= ersion but it's not quite ready yet. As soon as it's done & posted I'll se= nd out another announcement. =20 --bal -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Sunday, July 20, 2014 3:22 PM To: Brian LaMacchia; tls@ietf.org; cfrg@ietf.org Subject: Re: [Cfrg] V1.1 of MSR ECCLib for NUMS Curves library released (no= w supporting GCC on Linux) Hi Brian, thanks for sharing the code. I am wondering whether you also have a version that does not make use of as= sembler code since I cannot run this code on 32-bit ARM processors. Ciao Hannes On 07/20/2014 08:56 PM, Brian LaMacchia wrote: > Folks, >=20 > =20 >=20 > Microsoft Research is pleased to announce the release of v1.1 of the=20 > MSR Elliptic Curve Cryptography Library for NUMS curves. Please visit >=20 > =20 >=20 > http://research.microsoft.com/en-us/projects/nums/ >=20 > =20 >=20 > for full details and download links. New features in v1.1 include: >=20 > =20 >=20 > * GCC support on Linux: The new pre-assembly files .S located > in /MSR_ECCLib/AMD64 are compatible with both GNU GCC=20 > (GAS > assembler) and MSVS (MASM assembler) compilers >=20 > * New API for ephemeral elliptic curve Diffie-Hellman key > exchange (ECDHE) >=20 > * New tests for ECDHE >=20 > * Simplified API for some ECC scalar multiplication functions >=20 > * Extended support to any x64 processor >=20 > =20 >=20 > We welcome questions/comments/feedback on this library; please send=20 > them to msrsc@microsoft.com . >=20 > =20 >=20 > Thanks, >=20 > =20 >=20 > = =20 > --bal >=20 > =20 >=20 > -----Original Message----- > From: Brian LaMacchia > Sent: Monday, June 30, 2014 3:58 AM > To: cfrg@ietf.org; tls@ietf.org > Subject: Announcing the availability of the MSR Elliptic Curve=20 > Cryptography Library for NUMS Curves >=20 > =20 >=20 > Dear members of the IRTF CFRG and the IETF TLS WG, >=20 > =20 >=20 > On behalf of the Microsoft Research ECCLib Project, I am pleased to=20 > announce the first release of the Microsoft Research Elliptic Curve=20 > Cryptography Library (ECCLib) for NUMS ("Nothing Up My Sleeve") curves. > We are releasing ECCLib under the Apache 2.0 License. Here is a link=20 > to the project page and download location: >=20 > =20 >=20 > http://research.microsoft.com/en-us/projects/nums/ >=20 > =20 >=20 > The MSR ECCLib is an efficient cryptography library that provides=20 > functions for computing essential elliptic curve operations on a new=20 > set of high-security curves as previously described in [1] and=20 > presented at the CFRG Spring 2014 Interim Meeting (see [2] for a copy=20 > of the slides from that presentation). All computations in ECCLib on=20 > secret data exhibit regular, constant-time execution, providing=20 > protection against timing and cache attacks. >=20 > =20 >=20 > ECCLib supports six high-security elliptic curves proposed in [1],=20 > which cover three security levels (128-, 192-, and 256-bit security)=20 > and two curve models. The curves have a very simple and deterministic=20 > generation with minimal room for parameter manipulation. ECCLib=20 > includes all the ECC functions necessary to implement most popular=20 > elliptic curve-based schemes. In particular, ECCLib supports the=20 > computation of scalar multiplication for the six curves above in three va= riants: >=20 > 1. Variable-base scalar multiplication (e.g., this is=20 > used for computing the shared key in the Diffie-Hellman key exchange). >=20 > 2. Fixed-base scalar multiplication (e.g., this is=20 > used for key generation in the Diffie-Hellman key exchange). >=20 > 3. Double-scalar multiplication. This operation is=20 > typically used for verifying signatures. >=20 > =20 >=20 > As both the CFRG and the TLS WG are currently considering additional=20 > curves for elliptic curve cryptography, we hope that this contribution=20 > (in addition to the technical paper previously presented) will further=20 > a thoughtful discussion concerning what new curves CFRG should=20 > recommend and TLS should consider for inclusion. We welcome=20 > questions/comments/feedback on this library; please send them to=20 > msrsc@microsoft.com . >=20 > =20 >=20 > Please Note: the version of ECCLib that we are releasing today is for > x64 platforms with AVX and builds with the Microsoft Visual Studio=20 > toolchain. We are actively working on both a version that builds with=20 > GCC and also a portable C version and hope to add these to the release=20 > in the near future. >=20 > =20 >=20 > Thanks, >=20 > =20 >=20 > = =20 > --bal >=20 > =20 >=20 > [1] Joppe W. Bos, Craig Costello, Patrick Longa and Michael Naehrig,=20 > "Selecting Elliptic Curves for Cryptography: An Efficiency and=20 > Security Analysis", Cryptology ePrint Archive: Report 2014/130. Available= at: > http://eprint.iacr.org/2014/130 >=20 > =20 >=20 > [2] > http://patricklonga.webs.com/Presentation_CFRG_Selecting_Elliptic_Curv > es_for_Cryptography.pdf >=20 > =20 >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg >=20 From nobody Sun Jul 20 20:12:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578131B2AB1 for ; Sun, 20 Jul 2014 20:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ziUAzG6Kyev for ; Sun, 20 Jul 2014 20:12:26 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id C01361B2B02 for ; Sun, 20 Jul 2014 20:12:25 -0700 (PDT) Received: from [10.0.1.131] (173-230-166-62.cable.teksavvy.com [173.230.166.62]) by che.mayfirst.org (Postfix) with ESMTPSA id 7FD21F984; Sun, 20 Jul 2014 23:12:22 -0400 (EDT) Message-ID: <53CC8513.8040808@fifthhorseman.net> Date: Sun, 20 Jul 2014 23:12:19 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0 MIME-Version: 1.0 To: "StJohns, Michael" , Eric Rescorla References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SQCVK5rd4AHppws9RWQD20HNiXTaDDkG0" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/01wsG4oK9xfw0aWtNnpIS9vGtEY Cc: "tls@ietf.org" Subject: Re: [TLS] Reducing record expansion overhead allowance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 03:12:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SQCVK5rd4AHppws9RWQD20HNiXTaDDkG0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [reordering for chronological sanity] On 07/20/2014 12:21 PM, StJohns, Michael wrote: > On Sunday, July 20, 2014, Eric Rescorla wrote: >> On Sun, Jul 20, 2014 at 9:08 AM, StJohns, Michael >> On Sunday, July 20, 2014, Eric Rescorla wrote: >>>> >>>> I believe the consensus here was to have padding be done separately.= >> >>> You mean as part of the plain text? >> >> From the perspective of the AEAD algorithm, yes. >=20 > So then not really a TLS issue, but has to be supported by each applica= tion > and is transparent to TLS? Ok - Thanks. No, i don't think that was the intended meaning. I think padding should be made available within TLS, but applied directly on the cleartext; the padded form of the cleartext is what is fed to the cipher. Unpacking the nuances i recall from Denver: * padding is probably most correctly and effectively done at the application layer, since the application itself has an understanding of what its common usage patterns are, and how to frame a plausible anonymity set as a padding target. * but in practice, most applications (and most implementations) are likely to just slap TLS on top of a cleartext protocol "for security", and not think much more about it. * some application layers themselves may not have the means to produce and consume the padding needed within the application cleartext. * some (imperfect) level of resistance to traffic analysis is probably achievable with a simple policy applied at the TLS layer, without application layers having to do anything but flip a switch. This is much more likely to happen for any given application than detailed analys= is. Given these constraints, TLS is probably the best place to provide the possibility of padding. Defining reasonable and comprehensible padding policies/profiles is a lot more work that will also need to be done, but we should be able to define the mechanism within TLS without too much complexity. --dkg --SQCVK5rd4AHppws9RWQD20HNiXTaDDkG0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJTzIUTXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcYmYP/1as955ehMH1oAGkRdqePoGF I5jaSfWvHpM/Z71geTFcAs6ogH1OojCPPBHula/UPI0EAVJuZh8qEMDsc5kmEcYw nbHk/VTsTyRMBl5SrPgBM/C3OX8TAP3dqTGAULPmpJFbH3/B7xv/VzHxdSbV2bMw 4s/e7h+OWIusFJrgnwaMWnOTwJ8nsfuljafJzI5RPyw7+czaJ9BXhdS+epd7wuKv Yv0r+yaz77ZPamRe/+8r4lyi4WU2OR8RVytbuRWbSBfEb2liOuIhkuUNfywtzysS zCpxJziepQ7e1Sf4yvB5ka1j0y7UQkqqT3cyzwWxYf9MwPsUnefV5ZHaQi7DcWYM 7JT6PeYOLazTr12fspiRALGlryrOMBicDSupWD/JyzO6JXG93VmlkbF3uvzt1qI2 6uB9Nj6+8kewBCs26fNOJuYdY7RFJKRd+GH14oF7fkz9h7QBQZc5vfQP9hsBkx8C 5ifkE1oBJTQ/wNUJKYg/Rn/wei7ow4qTB9a8a4//UvQoT1SnaStY/6CW8skadrWx Ty/sgAUL4r+ARDut/CD9Sj3foidit0zVQR42+s6071RClYvEYWvSj0FHebCNH4yi pRWH805XOFydQyV9wYQs3pz6OA9ZOWRnpws6jGdGHCJfdkM9vfwSx/z8PFuk8wub gPSMGi2QzWh2xCJtrn7X =uX0o -----END PGP SIGNATURE----- --SQCVK5rd4AHppws9RWQD20HNiXTaDDkG0-- From nobody Sun Jul 20 21:49:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC5B1B2D67 for ; Sun, 20 Jul 2014 21:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04kQzKUsf6tC for ; Sun, 20 Jul 2014 21:49:04 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06DC21B2D5B for ; Sun, 20 Jul 2014 21:49:04 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id hz1so8929878pad.8 for ; Sun, 20 Jul 2014 21:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=3gqKOqmaIYPKzbfX1zkqH1LYO/OEKW+P8FZpPnYoBGM=; b=t2ZfFBe8XseOCwfzsZ5p2jV43mEJfhha2PUV4G+qSNL8Y/0IFFnkY/ZaGWxFJyPC8D kHjcnygWdJ/6esDJLVGcTv4dTyCQ55Iv6plsiU0fvwndzGhhIQ3XptrtpbLRRJnR6ni3 Gh22SFDEdwFyROAAUTys8MLUhH1xhq1vpVpycQuCyujvCL/pGn8V/1HgaX89XCJOA+hi q7MgW1D65PF5wlgU2vvuDCqUwxcPzlO1UVrbw5QIhx/CDR16kA0ypiWxZOg2nRnj4L/x PR7jNkvCTXWxmdhfHGxN3ehMK1jFTHJ20x3mjU3FebwZXqT3Lk0yUc3tjvrbm9yoJmYJ uImg== X-Received: by 10.68.225.74 with SMTP id ri10mr7293450pbc.116.1405918143703; Sun, 20 Jul 2014 21:49:03 -0700 (PDT) Received: from [10.0.1.7] (c-67-188-142-21.hsd1.ca.comcast.net. [67.188.142.21]) by mx.google.com with ESMTPSA id sh5sm12760569pbc.21.2014.07.20.21.49.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Jul 2014 21:49:01 -0700 (PDT) References: <53CC8513.8040808@fifthhorseman.net> Mime-Version: 1.0 (1.0) In-Reply-To: <53CC8513.8040808@fifthhorseman.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (11D201) From: Fabrice Gautier Date: Sun, 20 Jul 2014 21:48:59 -0700 To: Daniel Kahn Gillmor Archived-At: http://mailarchive.ietf.org/arch/msg/tls/X7zq4snhfaJygAtkn4Np-jgycKQ Cc: "tls@ietf.org" Subject: Re: [TLS] Reducing record expansion overhead allowance X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 04:49:06 -0000 > On Jul 20, 2014, at 20:12, Daniel Kahn Gillmor wro= te: >=20 > [reordering for chronological sanity] >> On 07/20/2014 12:21 PM, StJohns, Michael wrote: >>> On Sunday, July 20, 2014, Eric Rescorla wrote: >>>> On Sun, Jul 20, 2014 at 9:08 AM, StJohns, Michael >>>> On Sunday, July 20, 2014, Eric Rescorla wrote: >>>>>=20 >>>>> I believe the consensus here was to have padding be done separately. >>>=20 >>>> You mean as part of the plain text? >>>=20 >>> =46rom the perspective of the AEAD algorithm, yes. >>=20 >> So then not really a TLS issue, but has to be supported by each applicati= on >> and is transparent to TLS? Ok - Thanks. >=20 > No, i don't think that was the intended meaning. I think padding should > be made available within TLS, but applied directly on the cleartext; the > padded form of the cleartext is what is fed to the cipher. 0 So, if I understand, we would have something like: TLSPlaintext: what the application sends TLSPadded: the same with added padding, input of the AEAD engine TLSCiphertext: output of the AEAD engine, what goes on the wire.=20 In that model, TLSPadded basically replace TLSCompressed of TLS 1.2, and, to= go back to the original issue, your allowed overhead should probably stay t= he same. >=20 > Unpacking the nuances i recall from Denver: >=20 > * padding is probably most correctly and effectively done at the > application layer, since the application itself has an understanding of > what its common usage patterns are, and how to frame a plausible > anonymity set as a padding target. >=20 > * but in practice, most applications (and most implementations) are > likely to just slap TLS on top of a cleartext protocol "for security", > and not think much more about it. >=20 > * some application layers themselves may not have the means to produce > and consume the padding needed within the application cleartext. >=20 > * some (imperfect) level of resistance to traffic analysis is probably > achievable with a simple policy applied at the TLS layer, without > application layers having to do anything but flip a switch. This is > much more likely to happen for any given application than detailed analysi= s. > Given these constraints, TLS is probably the best place to provide the > possibility of padding. >=20 > Defining reasonable and comprehensible padding policies/profiles is a > lot more work that will also need to be done, but we should be able to > define the mechanism within TLS without too much complexity. >=20 > --dkg >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jul 21 07:37:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF861A007E; Mon, 21 Jul 2014 07:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCEA8l4-k1BK; Mon, 21 Jul 2014 07:37:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E9C1A0056; Mon, 21 Jul 2014 07:37:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721143750.4858.12780.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 07:37:50 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/stb_913PoygcjQCFYGbhlnlheeM Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-negotiated-dl-dhe-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:37:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Negotiated Discrete Log Diffie-Hellman Ephemeral Parameters for TLS Author : Daniel Kahn Gillmor Filename : draft-ietf-tls-negotiated-dl-dhe-00.txt Pages : 19 Date : 2014-07-21 Abstract: Traditional discrete logarithm-based Diffie-Hellman (DH) key exchange during the TLS handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by establishing a registry of DH parameters with known structure and a mechanism for peers to indicate support for these groups. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-dl-dhe/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-negotiated-dl-dhe-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 21 07:41:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4DA1A00E4 for ; Mon, 21 Jul 2014 07:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkfHBqR7x2Uz for ; Mon, 21 Jul 2014 07:41:11 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C731A0079 for ; Mon, 21 Jul 2014 07:41:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=254; q=dns/txt; s=iport; t=1405953672; x=1407163272; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=lapdJGAIvTPKq0YmF9HyP7vxtz/5b5jYLtulYJzv8zg=; b=Gb2VwFiFcblC1kgWPFIRhA0s/veOaJsvb2dXHtdJTYJoIv5BGSOwznW8 rLfkVOjtQf0/traSakh+V1IzVddiXjq832x1SnRd1AM0U/3emKWzptJnV ZxbFMAMjprg/3ESihExw8MfnTSaU56ucq1tJ1ejDnkz4olNSy5Lij9/oC w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANIlzVOtJV2Q/2dsb2JhbABZgw6BLc4qFnaECjpRAT5CJwSIVZgnpiwXkwCBGAWbJZQvg0SCMQ X-IronPort-AV: E=Sophos;i="5.01,701,1400025600"; d="scan'208";a="341740237" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP; 21 Jul 2014 14:41:11 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6LEfA29017196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Jul 2014 14:41:10 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Mon, 21 Jul 2014 09:40:54 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Resolution AEAD Cipher length and padding Thread-Index: AQHPpPHPs4RxOBnIA0miMPTuChlIcA== Date: Mon, 21 Jul 2014 14:41:09 +0000 Message-ID: <2F856D8D-44B1-4319-8D61-556F3C3ADE01@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.85.165.36] Content-Type: text/plain; charset="us-ascii" Content-ID: <5AE9ACC0E3BA0A41A521987F31CAF98D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ayOc4MVUz5X6GvykT_k5F9i7-hg Subject: [TLS] Resolution AEAD Cipher length and padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 14:41:13 -0000 At the interim meeting we decided to fix the specification of AEAD to suppo= rt ciphers that pad and expand the cipher text length. Please respond to t= his message by Friday, July 25 if you have an objection.=20 Thanks, Joe [for the chairs]= From nobody Mon Jul 21 07:42:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0D01A007D for ; Mon, 21 Jul 2014 07:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FoafsznYCn6 for ; Mon, 21 Jul 2014 07:42:53 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4F791A002A for ; Mon, 21 Jul 2014 07:42:52 -0700 (PDT) Received: by mail-yk0-f180.google.com with SMTP id 200so3969522ykr.11 for ; Mon, 21 Jul 2014 07:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tmqNFFiskiKfLuoOcjj7SQxfHLpl+qoXNJzgUroMNGA=; b=qzk8KRJzY7nuaXTRxGnbV9kTtVRwzH/r/fsIArsYiZcO1o/QvTLa5XwdrxVypPskna q53f86UPFJcmVZjp3Ko9+NLCd4LtlIyDFREHg8wdo3hTTAtHkuEKYb4j8wmjOFy1Fghq W6kkAvSmtdKXqqUxvDDfR79Q2s++4ILxZ8I4f7pAZrkBWDjUzN+GLZD1cBeReG1e/aTX DXjlyIIAxmrFPo0KZ4lDqaJNLYWQDJy/vdmUQDelRn0IPFuamrpcmCy1n7ilC5QP9dso kSYc9LZpDGla6Xv2xUYI00EP3CsBHpUPhFFUEutQINu7TuBiiOP/jAYdX/PQ3YgElTAY BvUA== MIME-Version: 1.0 X-Received: by 10.236.39.172 with SMTP id d32mr41419374yhb.66.1405953771960; Mon, 21 Jul 2014 07:42:51 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Mon, 21 Jul 2014 07:42:51 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Jul 2014 07:42:51 -0700 Message-ID: From: Watson Ladd To: Benjamin Black , "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ui1DQj344Tw34x7wbv8kppj88rs Cc: "cfrg@irtf.org" Subject: Re: [TLS] [Cfrg] Formal request from TLS WG to CFRG for new elliptic curves X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 14:42:56 -0000 On Sun, Jul 20, 2014 at 8:56 PM, Benjamin Black wrote: > On Sat, Jul 19, 2014 at 9:50 PM, Watson Ladd wrote: >> >> On Sat, Jul 19, 2014 at 4:09 PM, Benjamin Black wrote: >> > "This stems from the fact that in some specific cases an algorithm and a >> > curve are closely linked, with the two in some sense being carefully >> > co-designed to gain security and performance." >> > >> > I am aware of claims to this effect, but I have seen no evidence of >> > meaningful security or performance gains that would be seen in practical >> > deployments in TLS. Similar claims have been made about the dramatic >> > performance gains from certain curve forms, but the MSR research that >> > produced the NUMS curves shows only slight performance advantages for >> > those >> > forms and only at low security levels. The ECCLib implementations >> > support >> > the conclusion that there is little benefit. Please provide specific >> > supporting documentation for claims of significant, not incremental, >> > performance or security gains for TLS from this. >> >> http://bench.cr.yp.to/ >> >> Of course, when it comes to TLS, the two round trips cost far more, >> but when we have 1-RTT the exponentiations become far >> more critical for performance. Furthermore, CPU is not free, while a >> server can do other things while it waits. >> > > If TLS 1.2 is a guide, we are 5 years from widespread TLS 1.3 deployment. I > suggest 2 round trips is a more realistic expectation here. TLS 1.2 offered no compelling advantages. Everyone hates latency on the web. > > Even with a single round trip the network latency dwarfs differences in > latency between the various curves under discussion. As session resumption > becomes more widespread, and I am working to see that it does, the cost is > amortized over multiple connections, making it even less of a concern. > Regarding a server doing "other things" while it "waits" it seems you are > not familiar with what actually happens in large scale online services. > Front end servers terminating customer connections have nothing else to do > but terminate connections and route requests. If a client is slow to respond > that just means the server is handling connections/requests from clients > that are responsive. There is no waiting. If the server is slow to do a calculation, that reduces the number of clients it can handle. > >> >> > >> > If we had evidence of radically improved security or radically improved >> > performance at a given security level I would agree it would be worth >> > exploring. For less than 10% performance gain and no security gain I see >> > no >> > reason to even consider adopting a new signature algorithm. In the >> > abstract >> > it might seem plausible, but when faced with updating a billion devices >> > along with all of the supporting infrastructure previously hinted at, it >> > has >> > to be excluded. >> > >> > "My own view is that we should broaden our interpretation of the scope >> > of >> > the request to accommodate this fact, providing both new curves, and >> > where >> > appropriate, pointers to algorithms for those curves." >> > >> > There are multiple available options that support all relevant security >> > levels, are faster than the NIST curves, and are compatible with >> > existing >> > infrastructure. There will always be new curves published. Their >> > existence >> > cannot mean we constantly push incompatible algorithms with enormous >> > adoption costs at scale. If the goal is radically higher performance at >> > a >> > given security level and we don't care at all about compatibility, then >> > why >> > not consider genus 2 curves or other forms which are known to be >> > enormously >> > faster than even the twisted Edwards curves on the table? Throwing out >> > compatibility is a very slippery slope. >> >> I can't think of a reason why hyperelliptic curves shouldn't be on the >> table. >> Is your argument that we should keep Weierstrass form despite the >> barrier at 13 field ops >> per addition? By my calculation twisted (a=-1) Edwards form enables a >> 25% speedup, (10 field ops) >> together with increased ease of avoiding side channels. The 13 field >> op formula is not complete, >> and the complete method is not fast. >> > > My argument is that Montgomery is not necessary to achieve the desired > performance improvements and thus there is no justification at all for > tossing out the existing protocols. How does Montgomery involve tossing out an existing protocol? Or does protocol mean something to me it doesn't to me. A change in form from short Weierstrass is necessary to have the absolute best speed. The more speed, the more places we can stick encryption. > >> >> Secondly, scale reduces, not increases, the cost of switching. Write >> once, deploy many. There are not that >> many TLS implementations out there. We need a new car, which requires >> making a garage. >> If we are going to pay that cost, why not add the extra zero dollars for >> the >> Ferrar >> > > There are a dozen relevant implementations and a dozen versions of each. Or > did you think this would only be implemented going forward? Beyond that, you > are confusing unit cost with absolute cost and completely ignoring the > significant infrastructure costs. Where in your write once, deploy many are > HSMs upgraded? Where are compatibility problems between independent or old > implementations handled? Where are the customer support costs? The extensive > interop testing? Write once, deploy many is a myth. > > Your Ferrari analogy is apt: expensive, unreliable, and pointless except in > the service of vanity. > >> >> > >> > I ask once again that you and the rest of the CFRG leadership along with >> > the >> > TLS leadership focus on practical, clear, and specific requirements for >> > elimination of the NIST curves. Expanding the scope beyond that either >> > means >> > a hasty process producing something we are likely to regret in a few >> > years >> > (this is a 15+ year commitment!), or a long and careful process >> > producing >> > something we will still want around in a few years. Pushing new crypto >> > on >> > vendors and customers for the sake of maybe a few percent performance >> > improvement, and that is exactly what we are discussing here, should >> > alarm >> > everyone. >> >> We are not eliminating the NIST curves, but providing high speed >> alternatives that should look like reasonable >> choice for the next decade. If you don't want Curve25519 in TLS, or >> whatever emerges, don't enable it. >> > > If we were only discussing new curves, as we should be, that would be true. > What you and others are promoting is new curves and new protocols. The small > performance advantage of Curve25519 over a good twisted Edwards curve in > standard ECDHE does not justify a new protocol. > > I wouldn't be so quick to dismiss our deploying it. Might matter in whether > it is successful. How is Curve25519 a new protocol? x-coordinate only transmission was invented in the same paper with ECC. How does that make it harder to deploy or not? > >> >> If you want to be alarmed, go read any protocol other than IPsec that >> the IETF has made that uses cryptography, >> and try to prove it secure/write a clearly correct implementation. (My >> particular favorite is PGP) However, >> I'm pretty sure that DJB and Tanja gathered all the publicly known >> attacks on ECC on the Safecurves site. >> >> > >> > I will unfortunately not be in Toronto, but a number of others from >> > Microsoft will be and I hope there can be productive discussion on this >> > grounded a bit more in the facts of performance, security, and practice. >> >> Chrome wants Curve25519. SSH uses Curve25519. Somehow we added >> Brainpool, which no one uses, >> without this hullabaloo. Somehow Camelia (a Japanese AES knockoff) is >> in TLS, despite being less studied >> than AES. So what makes these new curve so much different? >> > > It would be more honest and accurate to say the Chrome/Google team wants > more efficient curves. Curve25519 was convenient. This applies to a number > of folks considering Curve25519, as well. There are now other options which > do not bring the incompleteness and incompatibility concerns of Curve25519. But your incompatibility concerns would apply to a twisted Edwards curve as well, and to anything not in short Weierstrass form. I see this could be an issue: how about "RTBD: represent a group, not a Kummer surface, for use in signatures" (I also don't think its much of one: most of the work is in the field, not the group. That said the fixed-based speed of twisted Edwards is mildly useful) > > Regarding IETF crypto adoption, you are describing how things should work: a > variety of systems are specified and they are integrated into protocols and > deployed by customers, resulting in some becoming very popular and others > seeing little use. That is not a flaw in the system, it is working as > designed and it is exactly why I don't understand the point of this request. > Specify them all, the market will know its own. I'm going to send this to TLS: I must confess to not having seen much discussion of this point. However, with signatures it is impossible to ignore even slightly used algorithms for risk of failing to verify something valid. This has already become an issue in DNSSEC. Sincerely, Watson Ladd > > > Ben > >> >> Sincerely, >> Watson Ladd >> > >> > >> > Ben >> > >> > >> > >> > On Fri, Jul 18, 2014 at 3:29 PM, Paterson, Kenny >> > >> > wrote: >> >> >> >> Hi Ben, >> >> >> >> Thanks for your questions. I agree there is ambiguity. This stems from >> >> the >> >> fact that in some specific cases an algorithm and a curve are closely >> >> linked, with the two in some sense being carefully co-designed to gain >> >> security and performance. >> >> >> >> I understand very well your point that if it is "curves only", then >> >> certain curves which are incompatible with existing standardized and >> >> widely deployed algorithms would need to be excluded. >> >> >> >> My own view is that we should broaden our interpretation of the scope >> >> of >> >> the request to accommodate this fact, providing both new curves, and >> >> where >> >> appropriate, pointers to algorithms for those curves. (Note that CFRG >> >> is >> >> not being asked to produce I-Ds for either curves or algorithms, though >> >> that kind of work might inevitably follow depending on the exact >> >> choices >> >> we recommend.) Of course, we can and should have discussion on this >> >> question of broadening of scope, as you rightly suggest below. >> >> >> >> Concerning your second question, yes, in an ideal world we would reach >> >> rough consensus on the requirements, and they would be clear, complete >> >> and >> >> unambiguous. >> >> >> >> If you are in Toronto next week, I'd be glad to continue the >> >> conversation, >> >> otherwise, let's do it on the list. >> >> >> >> Regards >> >> >> >> Kenny >> >> >> >> >> >> On 18/07/2014 06:51, "Benjamin Black" wrote: >> >> >> >> >Kenny, >> >> > >> >> > >> >> >There is rather a lot of ambiguity in these various versions of the >> >> >requirements. It would be helpful to get clarity on at least two >> >> > points: >> >> > >> >> > >> >> >1) Is this request for _only_ new curves, as the subject line of your >> >> >email indicates, or for new "ECC mechanisms" as in the included list >> >> > from >> >> >David McGrew? If it is the former, then curves which are incompatible >> >> >with existing standardized and widely >> >> > deployed algorithms, at least including ECDHE and ECDSA, must be >> >> >excluded. If it is the latter, then this request goes far beyond some >> >> >curves and I suggest deserves a lot more debate on how far down the >> >> > new >> >> >cryptography rabbit hole CFRG and the IETF wish to >> >> > go. >> >> > >> >> > >> >> >2) Is the process here to agree on clear, complete, unambiguous >> >> >requirements against which candidate curves will be evaluated? I >> >> > believe >> >> >the answer is, or should be, yes. However, based on ambiguities in the >> >> >stated requirements and the subsequent further >> >> > blurring of those requirements on the mailing list, it seems that >> >> > might >> >> >not be the consensus view. >> >> > >> >> > >> >> > >> >> > >> >> >Ben >> >> > >> >> > >> >> > >> >> > >> >> >On Mon, Jul 14, 2014 at 12:49 PM, Paterson, Kenny >> >> > wrote: >> >> > >> >> >Dear CFRG, >> >> > >> >> >CFRG has received a formal request from the TLS Working Group for >> >> >recommendations for new elliptic curves. Specifically, the TLS WG >> >> > would >> >> >like CFRG to recommend: >> >> > >> >> >- Curves suitable for both key establishment and digital signature >> >> > (though the same curves need not be used for both purposes). >> >> > >> >> >- One proposed curve or set of curves at the following security >> >> > levels: 128-bit (~256-bit curve) and 256-bit (~512 bit curve). >> >> > 192-bit security is optional. >> >> > >> >> >Note that these curves are not intended to supplant current curves in >> >> >widespread use, but rather to supplement them. Full details of the >> >> > request >> >> >can be found in the e-mail from the TLS WG chairs below. >> >> > >> >> >The CFRG chairs will coordinate a response to this request from the >> >> > CFRG >> >> >readership. Ideally we will reach a rough consensus through discussion >> >> > on >> >> >the >> >> >list and at the upcoming IETF 90 meeting in Toronto. While no deadline >> >> > is >> >> >set for our response to the TLS WG, we should aim to have one ready >> >> > within >> >> >2 months. >> >> > >> >> >We regard this as a major work item for CFRG and one where CFRG can >> >> >provide real value to the TLS WG and the IETF more widely. So we >> >> > encourage >> >> >(and indeed request) active participation from the widest set of >> >> >participants on this project. >> >> > >> >> >As a first step, we propose to discuss the requirements for new curves >> >> > for >> >> >a period of 2 weeks. Using an agreed set of requirements, in a second >> >> >step, we will then evaluate different curve proposals (including >> >> > extant >> >> >proposals and any emerging ones) for a period of 4 weeks. In a final >> >> >period of 2 weeks, we will produce a proposal for the TLS WG and seek >> >> >consensus on it. >> >> > >> >> > >> >> >The first step, running for 2 weeks, begins here. >> >> > >> >> >A starting point for requirements can be found in David McGrew's >> >> > recent >> >> >CFRG post >> >> >(http://www.ietf.org/mail-archive/web/cfrg/current/msg04461.html) and >> >> >reproduced here: >> >> > >> >> >---- >> >> > >> >> >Simplicity >> >> > >> >> > R1. Desired: easy to understand and implement [1] >> >> > >> >> >Efficiency >> >> > >> >> > R2. Required: amenable to compact implementations and fast >> >> > implementations, across both small and large processors [1] >> >> > >> >> > R3. Desired: re-use components between signatures and key exchange >> >> > algorithms [3] >> >> > >> >> >Intellectual Property >> >> > >> >> > R4. Required: available worldwide under reasonable and well >> >> > understood licensing terms [1] >> >> > >> >> > R5. Desired: available worldwide under royalty-free licensing >> >> > terms [1] >> >> > >> >> >Interoperability >> >> > >> >> > R6. Desired: can be used with current software implementations >> >> > (using different curve parameters) of TLS, PKIX, SSH, and IKE [4] >> >> > >> >> > R7. Desired: can be used within current ECC standards of TLS, >> >> > PKIX, SSH, and IKE [4] >> >> > >> >> >Security >> >> > >> >> > R8. Required: amenable to constant-time implementations, to avoid >> >> > side channel attacks [2] >> >> > >> >> > R9. Required: resist twist attacks [2] >> >> > >> >> > R10. Required: curve parameters should have good provenance; >> >> > random curves should be provably pseudorandom [5] >> >> > >> >> > R11. Desired for key exchange: resist invalid curve attacks [2]; >> >> > note that complete addition laws help and are thus desirable [2]. >> >> > (Note that the use of ephemeral keys also resist such attacks.) >> >> > >> >> > R12. Required for PAKE: indistinguishability of curve points from >> >> > random strings [2] >> >> > >> >> >Footnotes: >> >> > >> >> > [1] Original criteria set out for the Advanced Encryption Standard, >> >> > which is equally applicable to ECC. National Institute of >> >> > Standards and Technology (NIST) of the United States, 1998. >> >> > >> >> > [2] Daniel J. Bernstein and Tanja Lange. SafeCurves: choosing safe >> >> > curves for elliptic-curve cryptography. >> >> > http://safecurves.cr.yp.to >> >> >, accessed >> >> >April 2014. >> >> > >> >> > [3] Criteria identified by David McGrew, 2014. >> >> > >> >> > [4] Criteria identified by Russ Housley, TLS WG meeting at IETF89. >> >> > >> >> > [5] Criteria widely acknowledged on CFRG email list during 2014. >> >> > >> >> >---- >> >> > >> >> > >> >> >Our first request, then, is that you consider these requirements, and >> >> >provide your views on their appropriateness, completeness, and >> >> > individual >> >> >classifications (required/desired). We will continue that discussion >> >> > for >> >> > 2 >> >> >weeks, until the end of the IETF meeting in Toronto. The chairs will >> >> > then >> >> >compile a consensus-based list of requirements of the above form, >> >> > after >> >> >which we will move to the second step. >> >> > >> >> >We thank you in advance for your participation in this important task. >> >> > >> >> >Regards >> >> > >> >> >Alexei, Kenny and Kevin (CFRG co-chairs) >> >> > >> >> > >> >> > >> >> > >> >> >On 11/07/2014 05:44, "Joseph Salowey (jsalowey)" >> >> >wrote: >> >> > >> >> >>CFRG Chairs and Security ADs, >> >> >> >> >> >>TLS WG would like to formally request that the >> >> >>CFRG make a recommendation for new ECC group support for TLS >> >> >>and other similar applications. Specifically, we request that CFRG >> >> >>recommend the following: >> >> >> >> >> >>- Curves suitable for both key establishment and digital signature >> >> >> (though the same curves need not be used for both purposes). >> >> >> >> >> >>- One proposed curve or set of curves at the following security >> >> >> levels: 128-bit (~256-bit curvee) and 256-bit (~512 bit curve). >> >> >> 192-bit security is optional. >> >> >> >> >> >>If the same curves are used for key establishment and signature, this >> >> >>would be a recommendation for two curves. If different curves are >> >> >>used, this would be a recommendation for four curves. >> >> >> >> >> >>In addition to a recommendation, we also request that the CFRG >> >> >> provide >> >> >>a technical rationale for their selection. >> >> >> >> >> >>If the CFRG does not feel comfortable making a single set of >> >> >>selections, we propose that they select a small number of potential >> >> >>choices with a detailed technical analysis of the advantages and >> >> >>disadvantages of each selection and that the Security ADs sponsor a >> >> >>process (perhaps via SAAG) to narrow it down to the specification >> >> >>above. >> >> >> >> >> >>For clarity, we are not currently requesting that CFRG replace or >> >> >>profile the existing curves in RFC4492 and RFC 7027, although we are >> >> >>also not ruling out such an effort in the future. The current request >> >> >>is for a new set of curves to complement the existing ones. >> >> >> >> >> >>Please reach out to us if this is unclear or further information is >> >> >>required. >> >> >> >> >> >>Thanks, >> >> >> >> >> >>TLS Chairs >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> >_______________________________________________ >> >> >Cfrg mailing list >> >> >Cfrg@irtf.org >> >> >http://www.irtf.org/mailman/listinfo/cfrg >> >> > >> >> > >> >> > >> >> > >> >> > >> >> >> > >> > >> > _______________________________________________ >> > Cfrg mailing list >> > Cfrg@irtf.org >> > http://www.irtf.org/mailman/listinfo/cfrg >> > >> >> >> >> -- >> "Those who would give up Essential Liberty to purchase a little >> Temporary Safety deserve neither Liberty nor Safety." >> -- Benjamin Franklin > > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon Jul 21 07:45:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4E81A000F for ; Mon, 21 Jul 2014 07:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftzVnVaI3VfL for ; Mon, 21 Jul 2014 07:45:14 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED5E31A007D for ; Mon, 21 Jul 2014 07:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=228; q=dns/txt; s=iport; t=1405953914; x=1407163514; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=4vKnCwDQMwzHKO1euNswXRBeMMJY7cS8hNqRU2Gv4bo=; b=I1usmYmD7wRYeE0dZMBoLlto12DOznMM9TNZLEYqObvXmz2e5avvaouK 7tX8nueZqx9kb03Zq4u2PbwuVDxqRnC5ahtnJg/Pob/JU9vxyvOvWUYCW nvmaFw8f5nmOuJTbm2GcGx7AS24at4vZvsZnyJ/tdVXwoFEVxL7BgvZXQ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEomzVOtJV2b/2dsb2JhbABZgw6BLc4qFnaECjpRAT5CJwSIVZgmpiwXkwCBGAWbJZQvg0SCMQ X-IronPort-AV: E=Sophos;i="5.01,701,1400025600"; d="scan'208";a="62694085" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP; 21 Jul 2014 14:45:13 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6LEjDix019208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Jul 2014 14:45:13 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Mon, 21 Jul 2014 09:45:13 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Removing support for custom unnamed DIffie-Hellman groups Thread-Index: AQHPpPJgYC2+zz5lPEuv95UOPQaikQ== Date: Mon, 21 Jul 2014 14:45:12 +0000 Message-ID: <3BA3F4D9-84FF-45ED-A1D3-F00C649019DC@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.85.165.36] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/q469Nam744M5azWbW3PiwpXwv-E Subject: [TLS] Removing support for custom unnamed DIffie-Hellman groups X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 14:45:15 -0000 At the interim there was support for removing support for custom unnamed Di= ffie-Hellman groups from TLS 1.3. If you have an objection please respond = on the list by July 25, 2014. Thanks, Joe=20 [For the chairs] = From nobody Mon Jul 21 07:46:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149321A0067 for ; Mon, 21 Jul 2014 07:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.332 X-Spam-Level: X-Spam-Status: No, score=0.332 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJSYX07F90Gq for ; Mon, 21 Jul 2014 07:46:54 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.56.176.20]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 486201A002A for ; Mon, 21 Jul 2014 07:46:54 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id 9E4BA2B890367; Mon, 21 Jul 2014 09:46:53 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 704B52B88D05F for ; Mon, 21 Jul 2014 09:46:41 -0500 (CDT) Received: from [31.133.164.43] (port=52670 helo=dhcp-a42b.meeting.ietf.org) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X9ErQ-0001ue-SG for tls@ietf.org; Mon, 21 Jul 2014 09:46:41 -0500 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5A318D71-E491-490B-82D3-6D1BA3C60684@ieca.com> Date: Mon, 21 Jul 2014 10:46:39 -0400 To: "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 31.133.164.43 X-Exim-ID: 1X9ErQ-0001ue-SG X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-a42b.meeting.ietf.org) [31.133.164.43]:52670 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ojH-aX3EbXj-41MqLbc7Czw9BAY Subject: [TLS] adopted: draft-popov-tls-prohibiting-rc4-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 14:46:55 -0000 At the TLS interim held on 20140720, there wg consensus was re-confirmed = to adopt draft-popov-tls-prohibiting-rc4-02 . This is consistent with = the wg adoption call = (http://www.ietf.org/mail-archive/web/tls/current/msg11932.html). Andrei, Please submit your individual draft as = draft-ietf-tls-prohibiting-rc4-00. spt {for the chairs}= From nobody Mon Jul 21 07:47:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9AC31A00FF for ; Mon, 21 Jul 2014 07:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ltl8puSsK_wg for ; Mon, 21 Jul 2014 07:47:12 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF361A002E for ; Mon, 21 Jul 2014 07:47:12 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3B17A47639; Mon, 21 Jul 2014 14:47:11 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 34C5647685; Mon, 21 Jul 2014 14:47:11 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 2F2348004A; Mon, 21 Jul 2014 14:47:11 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.95]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Mon, 21 Jul 2014 10:47:10 -0400 From: "Salz, Rich" To: Watson Ladd , Benjamin Black , "tls@ietf.org" Date: Mon, 21 Jul 2014 10:47:09 -0400 Thread-Topic: [TLS] [Cfrg] Formal request from TLS WG to CFRG for new elliptic curves Thread-Index: Ac+k8hLl+hmFdwo/SF6v76cPHuDX0gAAGQlg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7185928AAB5@USMBX1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3ue-THwx-J8Et1g-YAqmVZW1WEo Cc: "cfrg@irtf.org" Subject: Re: [TLS] [Cfrg] Formal request from TLS WG to CFRG for new elliptic curves X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 14:47:17 -0000 > TLS 1.2 offered no compelling advantages. Yes. TLS 1.3 will offer some good reasons to adopt, from the simplicity, s= ecurity, privacy, and efficiency areas. The comparison to TLS 1.2 doesn't = hold. /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Mon Jul 21 07:51:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4561A0126 for ; Mon, 21 Jul 2014 07:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BW4W_ukdYsDd for ; Mon, 21 Jul 2014 07:51:24 -0700 (PDT) Received: from services-1.meeting.ietf.org (services-1.meeting.ietf.org [IPv6:2001:67c:370:229::6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 124B61A0114 for ; Mon, 21 Jul 2014 07:51:23 -0700 (PDT) Received: from hotel-wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:144:6233:4bff:fe20:eb18]) by services-1.meeting.ietf.org (Postfix) with ESMTP id 2600B4E7A3; Mon, 21 Jul 2014 14:51:22 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <3BA3F4D9-84FF-45ED-A1D3-F00C649019DC@cisco.com> Date: Mon, 21 Jul 2014 10:51:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3BA3F4D9-84FF-45ED-A1D3-F00C649019DC@cisco.com> To: "Joseph Salowey (jsalowey)" X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pRR-Zw64zVQwHCNYxst71Crb3I4 Cc: "" Subject: Re: [TLS] Removing support for custom unnamed DIffie-Hellman groups X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 14:51:25 -0000 I think this means that only well-known groups will be used. I am = assuming that an IANA registry will be used to provide identifiers for = these well-known groups. If that is correct, then I fully support this = direction. Russ On Jul 21, 2014, at 10:45 AM, Joseph Salowey (jsalowey) wrote: > At the interim there was support for removing support for custom = unnamed Diffie-Hellman groups from TLS 1.3. If you have an objection = please respond on the list by July 25, 2014. >=20 > Thanks, >=20 > Joe=20 > [For the chairs]=20 From nobody Mon Jul 21 07:54:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F071A0151 for ; Mon, 21 Jul 2014 07:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4biVHMT6zYv for ; Mon, 21 Jul 2014 07:54:18 -0700 (PDT) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B14DA1A015B for ; Mon, 21 Jul 2014 07:54:16 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id m1so7410943oag.7 for ; Mon, 21 Jul 2014 07:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ij/4C3d++Loph0G/+nzRdqwUd5HdBIyB3imTfVhagh0=; b=aXtNOvdMEv8QIf57bI7Y1KsyFv2Hh7l1U7IN1iBQ8TInzxAlZK5TcOBHA8UCgET5bX 8CoSjIkz0lOQZm9xEaFdLSp/ldaYF2ooBRK1vr7ZZCyFyjYlGNjmnBhF1Mtyhwtl5Xpe +3XFMLX8NRGvXvMQND21PbrIO9mpLyE2dpoCw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ij/4C3d++Loph0G/+nzRdqwUd5HdBIyB3imTfVhagh0=; b=SFLMKd4ftAIQOkXCDaTcVX20sZvbzm3qCdS4SIjJgBa1oHQgB4F5uxO0J1Dm7pH3+w m/+WnUhqbmqsY+LMB7HVmMW0Nclveoqt2Ym2McL3Hx25KkCC2JhcF7DHm7cqYGfLTb9v IDylD0MOrs1kPpc4y2H7Kap3s/hghGkJeEMHHn7JekREvg1uhIVAUVbE/muVv0BCTsmZ SOfSKxJZAQ/L0uclbcvVAhoK7MJTGKRDjAaWkenexDz1mPGKoM+WdYybp5R4EDcnp7UH IDEub3u/mtN6XNXvHCYqRMjRn2a0gWiTBgLr2/mXI6R/XYfyWqtOCsHp9pDKkglO21dP mD0Q== X-Gm-Message-State: ALoCoQlHrEgLhHaxTvw6PeGqt1cYcV/TceMNWZVhC5sCFRvQtqcll+hIcTX4JdgY18GO4M4PUZim MIME-Version: 1.0 X-Received: by 10.60.47.77 with SMTP id b13mr15976618oen.83.1405954454915; Mon, 21 Jul 2014 07:54:14 -0700 (PDT) Received: by 10.76.25.42 with HTTP; Mon, 21 Jul 2014 07:54:14 -0700 (PDT) X-Originating-IP: [128.93.188.195] In-Reply-To: <2F856D8D-44B1-4319-8D61-556F3C3ADE01@cisco.com> References: <2F856D8D-44B1-4319-8D61-556F3C3ADE01@cisco.com> Date: Mon, 21 Jul 2014 16:54:14 +0200 Message-ID: From: Alfredo Pironti To: "Joseph Salowey (jsalowey)" Content-Type: multipart/alternative; boundary=001a11c21116db201704feb547d9 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uozsItpBZBvhe0mJ7ZaDxrT-5SQ Cc: "" Subject: Re: [TLS] Resolution AEAD Cipher length and padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 14:54:20 -0000 --001a11c21116db201704feb547d9 Content-Type: text/plain; charset=UTF-8 It's not clear to me what this resolution is about; could you please elaborate (or give pointers)? Is this about AEAD ciphers built on top of block-encrypt then mac? To some extent, current GCM and CCM ciphers are already expanding the cipher text length by the tag length, so I must be missing the point here. Thanks. Best, Alfredo On Mon, Jul 21, 2014 at 4:41 PM, Joseph Salowey (jsalowey) < jsalowey@cisco.com> wrote: > At the interim meeting we decided to fix the specification of AEAD to > support ciphers that pad and expand the cipher text length. Please respond > to this message by Friday, July 25 if you have an objection. > > Thanks, > > Joe > [for the chairs] > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c21116db201704feb547d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's not clear to me what this resolution is about; co= uld you please elaborate (or give pointers)?
Is this about AEAD ciphers = built on top of block-encrypt then mac? To some extent, current GCM and CCM= ciphers are already expanding the cipher text length by the tag length, so= I must be missing the point here. Thanks.

Best,
Alfredo


On Mon, Jul 21, 2014 at 4:41 PM, Joseph Salowey (jsalowey)= <jsalowey@cisco.com> wrote:
At the interim meeting we decided to fix the= specification of AEAD to support ciphers that pad and expand the cipher te= xt length. =C2=A0Please respond to this message by Friday, July 25 if you h= ave an objection.

Thanks,

Joe
[for the chairs]
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--001a11c21116db201704feb547d9-- From nobody Mon Jul 21 07:56:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B243F1A0103 for ; Mon, 21 Jul 2014 07:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XE3gJ3DlM0FC for ; Mon, 21 Jul 2014 07:56:45 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DECD1A016B for ; Mon, 21 Jul 2014 07:56:44 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id x48so7788802wes.31 for ; Mon, 21 Jul 2014 07:56:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=AovVWFSH+LAKw00RdQNvvrCWIuArNVA/7S7fdcvSbkg=; b=I0CBXP2hderw6ZuZ23sG9vUorBVmHhOahqbtbMaAxfzZfpOBXcn9lx7JSo695dY6fy OCajfunLl368ktFSv+TdXCa5rDqJ0fxBhMUy+ziRfNu0jIYWffKCY67yMTosQB0jLKkc Pca/z1FT+YWBVkw+QMhuGLkKgJE110VC/d7FaZkNKXQJkEEwDyU0AsCI5qHSPhlQV1G9 honRVWqAF1Hklrh0henRFcu7/71H0rCuyq0jL5tPw9o839erliy5QS9HalnBMbawZJEb 5vIwgJmJqgsBX5g1TvnEiP8PGZ9u5zeuU8eeR7WWDzaAYd3b8cPQAlQE0cSfOx5PiEKr I3Sw== X-Gm-Message-State: ALoCoQmm3DfBKb+txW8Guw0UBDnpS99rSZAuWe9glRwEMVSjyZmTnF3RAgEy7FRkHNLwgFEc08/6 X-Received: by 10.194.91.228 with SMTP id ch4mr23995742wjb.59.1405954603056; Mon, 21 Jul 2014 07:56:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Mon, 21 Jul 2014 07:56:02 -0700 (PDT) X-Originating-IP: [2001:67c:370:176:fd4c:933f:5f3e:943e] In-Reply-To: References: <3BA3F4D9-84FF-45ED-A1D3-F00C649019DC@cisco.com> From: Eric Rescorla Date: Mon, 21 Jul 2014 07:56:02 -0700 Message-ID: To: Russ Housley Content-Type: multipart/alternative; boundary=047d7bd91d9eaf902f04feb550c5 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9z5wEXjw-LIvDOmLY909Vfy5uSw Cc: "" Subject: Re: [TLS] Removing support for custom unnamed DIffie-Hellman groups X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 14:56:46 -0000 --047d7bd91d9eaf902f04feb550c5 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 21, 2014 at 7:51 AM, Russ Housley wrote: > I think this means that only well-known groups will be used. Yes. > I am assuming that an IANA registry will be used to provide identifiers > for these well-known groups. If that is correct, then I fully support this > direction. Yes: http://tools.ietf.org/html/draft-ietf-tls-negotiated-dl-dhe-00#section-7 -Ekr > > Russ > > On Jul 21, 2014, at 10:45 AM, Joseph Salowey (jsalowey) wrote: > > > At the interim there was support for removing support for custom unnamed > Diffie-Hellman groups from TLS 1.3. If you have an objection please > respond on the list by July 25, 2014. > > > > Thanks, > > > > Joe > > [For the chairs] > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7bd91d9eaf902f04feb550c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Jul 21, 2014 at 7:51 AM, Russ Housley <= ;housley@vigilsec= .com> wrote:
I think this means that only well-known groups will be use= d.

Yes.

=C2=A0
=C2=A0I am assuming that an IANA registry will be used to provide identifi= ers for these well-known groups. =C2=A0If that is correct, then I fully sup= port this direction.


-Ekr
=C2=A0

Russ

On Jul 21, 2014, at 10:45 AM, Joseph Salowey (jsalowey) wrote:

> At the interim there was support for removing support for custom unnam= ed Diffie-Hellman groups from TLS 1.3. =C2=A0If you have an objection pleas= e respond on the list by July 25, 2014.
>
> Thanks,
>
> Joe
> [For the chairs]

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

--047d7bd91d9eaf902f04feb550c5-- From nobody Mon Jul 21 07:59:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9A21A0179 for ; Mon, 21 Jul 2014 07:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfTpi_q2V6Tv for ; Mon, 21 Jul 2014 07:59:54 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 054541A000F for ; Mon, 21 Jul 2014 07:59:53 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id m15so6609220wgh.29 for ; Mon, 21 Jul 2014 07:59:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=DVcu+WtY87y2sIIbTEdnPOCRryQHghLrfTx6Fpa/5Xc=; b=kwMPYLx8IqWu/ilJwlbXEphdFcN4//zsqKklfOJ+D8L7sgrBLlJzHc9RlhjXICYkiN dAHN0L++R0BpH6QJA+Dj1ZCTZFHi9DxV8Tm0CRqhQ1SvLZ9SzuQtlnD8HCVAGO7HzKke uUTZtQjaCNEM/c4UtXY+9sX88ilKykizGyfemHdxMEGZJUMmwjPb9g/uDRquTd8horpF XHkOES/RgvBJaOPKszwIee+r7lHatX6T8O+cmsgN6wMz+/W9BFvXiSJdWNEeVDByfNdJ fM7Ggp7gSm4q/mY7nu31w3s+VPD0aQDGbtc4melfdYzfLH1EpAjhsQwSvQr/57Q3dMRb ix/Q== X-Gm-Message-State: ALoCoQlSRBnVac27+ZCYEIWV68C70PZyEX44dL2jj3cePNbYulHdLs0hOjqQI67gmGROtoERKj8S X-Received: by 10.194.91.228 with SMTP id ch4mr24023801wjb.59.1405954792187; Mon, 21 Jul 2014 07:59:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Mon, 21 Jul 2014 07:59:12 -0700 (PDT) X-Originating-IP: [2001:67c:370:176:fd4c:933f:5f3e:943e] In-Reply-To: References: <2F856D8D-44B1-4319-8D61-556F3C3ADE01@cisco.com> From: Eric Rescorla Date: Mon, 21 Jul 2014 07:59:12 -0700 Message-ID: To: Alfredo Pironti Content-Type: multipart/alternative; boundary=047d7bd91d9ef56ec004feb55b93 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QW1ttjArcgAMOyBrWHCpzVaLta4 Cc: "" Subject: Re: [TLS] Resolution AEAD Cipher length and padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 14:59:56 -0000 --047d7bd91d9ef56ec004feb55b93 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 21, 2014 at 7:54 AM, Alfredo Pironti wrote: > It's not clear to me what this resolution is about; could you please > elaborate (or give pointers)? > Is this about AEAD ciphers built on top of block-encrypt then mac? To some > extent, current GCM and CCM ciphers are already expanding the cipher text > length by the tag length, so I must be missing the point here. Thanks. > if you have a cipher mode (as you say, CBC is an example) which expands the plaintext by a non-deterministic amount (specifically an amount which can't be determined by the receiver prior to decryption) the it doesn't work to have the length be part of additional data. See: https://github.com/tlswg/tls13-spec/issues/67 -Ekr > Best, > Alfredo > > > On Mon, Jul 21, 2014 at 4:41 PM, Joseph Salowey (jsalowey) < > jsalowey@cisco.com> wrote: > >> At the interim meeting we decided to fix the specification of AEAD to >> support ciphers that pad and expand the cipher text length. Please respond >> to this message by Friday, July 25 if you have an objection. >> >> Thanks, >> >> Joe >> [for the chairs] >> _______________________________________________ >> 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 > > --047d7bd91d9ef56ec004feb55b93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 21, 2014 at 7:54 AM, Alfredo Pironti <= alfredo@pironti.eu<= /a>> wrote:
It's not clear to me what this resolu= tion is about; could you please elaborate (or give pointers)?
Is this about AEAD ciphers built on top of block-encrypt then mac? To some = extent, current GCM and CCM ciphers are already expanding the cipher text l= ength by the tag length, so I must be missing the point here. Thanks.

if you have a cipher mode (as you say, CBC= is an example) which expands the
plaintext by a non-deterministi= c amount (specifically an amount which can't
be determined by= the receiver prior to decryption) the =C2=A0it doesn't work to have
the length be part of additional data.

See:

-Ekr=

=C2=A0
Best,
Alfredo


On Mon, Jul= 21, 2014 at 4:41 PM, Joseph Salowey (jsalowey) <jsalowey@cisco.com&g= t; wrote:
At the interim meeting we decided to fix the specification= of AEAD to support ciphers that pad and expand the cipher text length. =C2= =A0Please respond to this message by Friday, July 25 if you have an objecti= on.

Thanks,

Joe
[for the chairs]
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls


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


--047d7bd91d9ef56ec004feb55b93-- From nobody Mon Jul 21 08:03:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE5C1A01AF for ; Mon, 21 Jul 2014 08:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRxr-uEgk9GC for ; Mon, 21 Jul 2014 08:03:35 -0700 (PDT) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E563D1A01C6 for ; Mon, 21 Jul 2014 08:02:49 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id eb12so7644187oac.31 for ; Mon, 21 Jul 2014 08:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=utiOqTjDNF8lVQrpSwo9kToKNNN8LhXIAPmuXRVnTRU=; b=YrtCCY5JBE/KI4Q6vrVwOUZf9mbzjZLFZb+TjtK4ADvOBtjsja7yZXQ9iAp5orIcw8 EX0fT9mTDEXZPzIjJ4qacw6prhLmJxGu2aoqn2LFDYhFwuMB85AivvEJj4U9dkZCyYXT dDwdG/zMkyuXoPI+ved6wFu6X3y/QCiGu8eXk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=utiOqTjDNF8lVQrpSwo9kToKNNN8LhXIAPmuXRVnTRU=; b=Nf6oA7ykVKiN+s6/mFTmggrLsCmJLLxNXxyPE6ch23C3OXUmZRuIZsjjlAxzejqa/i bWA7yWE3WeGm517H75QMhoTAMr/aV3LLTScH+QQ5lWgX3uqbQr12GZUTdkv9yyXQRuMi 8pVY6EKPRbUFeddEmSWetsuMxM72JBs/CNThCfR4f4H9HYr7RGjvNvj9uxCSXmJnMX5y LpNKeFDUUEQmH/9bxbKNptM6XDQTF+UD0BPPVrj92J/bs9Ko3yhAdrbxNGVXOsc5C5RM ayqgSjNOA9XuBR146o0CSaV/dx0aL0oip0ny4OR/IVIx+v1/qui8JXZjSFqOUlUlRPsa kB4g== X-Gm-Message-State: ALoCoQnPxZPix38F4McWmkZlYwfb/Jfu7QQKNvfpLc66bDFCKsUMuwEca8Hs+95oLLuIxsvWZbyW MIME-Version: 1.0 X-Received: by 10.60.146.228 with SMTP id tf4mr38212348oeb.37.1405954969399; Mon, 21 Jul 2014 08:02:49 -0700 (PDT) Received: by 10.76.25.42 with HTTP; Mon, 21 Jul 2014 08:02:49 -0700 (PDT) X-Originating-IP: [128.93.188.195] In-Reply-To: References: <2F856D8D-44B1-4319-8D61-556F3C3ADE01@cisco.com> Date: Mon, 21 Jul 2014 17:02:49 +0200 Message-ID: From: Alfredo Pironti To: Eric Rescorla Content-Type: multipart/alternative; boundary=047d7b5d98ef858cea04feb566a6 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TIJc7He6WSdHshD0eelcdMF6edM Cc: "" Subject: Re: [TLS] Resolution AEAD Cipher length and padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 15:03:39 -0000 --047d7b5d98ef858cea04feb566a6 Content-Type: text/plain; charset=UTF-8 Thanks for the clarification. I'm fine with the proposed change. On Mon, Jul 21, 2014 at 4:59 PM, Eric Rescorla wrote: > > > On Mon, Jul 21, 2014 at 7:54 AM, Alfredo Pironti > wrote: > >> It's not clear to me what this resolution is about; could you please >> elaborate (or give pointers)? >> Is this about AEAD ciphers built on top of block-encrypt then mac? To >> some extent, current GCM and CCM ciphers are already expanding the cipher >> text length by the tag length, so I must be missing the point here. Thanks. >> > > if you have a cipher mode (as you say, CBC is an example) which expands the > plaintext by a non-deterministic amount (specifically an amount which can't > be determined by the receiver prior to decryption) the it doesn't work to > have > the length be part of additional data. > > See: > https://github.com/tlswg/tls13-spec/issues/67 > > -Ekr > > >> > Best, >> Alfredo >> >> >> On Mon, Jul 21, 2014 at 4:41 PM, Joseph Salowey (jsalowey) < >> jsalowey@cisco.com> wrote: >> >>> At the interim meeting we decided to fix the specification of AEAD to >>> support ciphers that pad and expand the cipher text length. Please respond >>> to this message by Friday, July 25 if you have an objection. >>> >>> Thanks, >>> >>> Joe >>> [for the chairs] >>> _______________________________________________ >>> 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 >> >> > --047d7b5d98ef858cea04feb566a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the clarification. I'm fine with the propos= ed change.


On Mon, Jul 21, 2014 at 4:59 PM, Eric Rescorla <= ;ekr@rtfm.com> wrote:
=

On Mon, Jul 21, 2014 at = 7:54 AM, Alfredo Pironti <alfredo@pironti.eu> wrote:
It's not clear to me what this resolu= tion is about; could you please elaborate (or give pointers)?
Is this about AEAD ciphers built on top of block-encrypt then mac? To some = extent, current GCM and CCM ciphers are already expanding the cipher text l= ength by the tag length, so I must be missing the point here. Thanks.

if you have a cipher mode (as you sa= y, CBC is an example) which expands the
plaintext by a non-determ= inistic amount (specifically an amount which can't
be determi= ned by the receiver prior to decryption) the =C2=A0it doesn't work to h= ave
the length be part of additional data.

-Ekr

=C2=A0
Best,
Alfredo


On Mon, Jul 21, 2014 at 4:41 PM, Jo= seph Salowey (jsalowey) <jsalowey@cisco.com> wrote:
At the interim meeting we decided to fix the specification= of AEAD to support ciphers that pad and expand the cipher text length. =C2= =A0Please respond to this message by Friday, July 25 if you have an objecti= on.

Thanks,

Joe
[for the chairs]
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls


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



--047d7b5d98ef858cea04feb566a6-- From nobody Mon Jul 21 08:03:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45261A00A7 for ; Mon, 21 Jul 2014 08:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zz6c1t6cmVbk for ; Mon, 21 Jul 2014 08:03:47 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id D17D41A01AA for ; Mon, 21 Jul 2014 08:03:12 -0700 (PDT) Received: from [31.133.161.14] (dhcp-a10e.meeting.ietf.org [31.133.161.14]) by che.mayfirst.org (Postfix) with ESMTPSA id 5B514F984; Mon, 21 Jul 2014 11:03:09 -0400 (EDT) Message-ID: <53CD2BAE.1000004@fifthhorseman.net> Date: Mon, 21 Jul 2014 11:03:10 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0 MIME-Version: 1.0 To: Alfredo Pironti , "Joseph Salowey (jsalowey)" References: <2F856D8D-44B1-4319-8D61-556F3C3ADE01@cisco.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="I2fC3ilQQmjFtAOCteJ6Cjf6tjbELqrhM" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tjRcczFXoQ8IrjvaowYQ6cBH0lg Cc: "" Subject: Re: [TLS] Resolution AEAD Cipher length and padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 15:03:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --I2fC3ilQQmjFtAOCteJ6Cjf6tjbELqrhM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/21/2014 10:54 AM, Alfredo Pironti wrote: > It's not clear to me what this resolution is about; could you please > elaborate (or give pointers)? The most recent discussion of this situation was my re-discovery of the problem, which was apparently known to several people already: https://www.ietf.org/mail-archive/web/tls/current/msg12871.html --dkg --I2fC3ilQQmjFtAOCteJ6Cjf6tjbELqrhM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJTzSuuXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcmAsP+QE1j9Ln1fQ3eMGXr38teYR7 h+r0Os7K3pexXo1CrF38dqkNsZe8BqJrHIMq8vuZAem/FK4bncQoUpCGM6iOmQsw rtdxChfBCsF7vxby3qpFuqL5KsZ3AytIBAuVP7AliAtqgUuMsxt8HO1xYlnyvPC8 fqJLIb5b2yayebg+NKYknLlaP3tLv0sI/7+v7YnK3SJrO87VTEXbwZngY8oP61MM e/RXRljFT9F2da6GOEqVKQbiNUaenAz2eWuCGs8dw+Z72vnVAypzYosyTxE9wDsP TcSrS5Z6WeX9HQxqs2WAx9ZR0F/wWSJPopcGlPfrskJGd6JxQSQGfCJ141FkJLJQ 5S25bItD4Od1nv7yBXmsOQKmg/9qd0Yz0sDRCVqX+ryLIutwTcoLYOoi0tAbM3ZT FpuNWgzqtsf5yLfodtJSLsGdK/5nvcWYBdn1uT8vNJzSfMbqstqfSOCi3hNthERw Vib6jC81QqVi4zr+YJ1oDXCw6rtugycsFgkNU3ruHF/7KAA5OJtXwAnM4UZ++2uy Np0/ynz2C4KL9UboUVqnkyIuOOusGM7TiddwcFGexFHLGUFpoaWNm/oO0oTRyD6k tby30n0ZW1EY6iXwRyrqiBHdaVPt3I/eXFssCGBXTl8ox2+XNi0hPT6JfAvxEzFT 3Ny+S1kv7guR4ubdVuiE =JcnP -----END PGP SIGNATURE----- --I2fC3ilQQmjFtAOCteJ6Cjf6tjbELqrhM-- From nobody Mon Jul 21 08:08:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC1B1A01A8 for ; Mon, 21 Jul 2014 08:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.133 X-Spam-Level: * X-Spam-Status: No, score=1.133 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfZrWAyc_fNA for ; Mon, 21 Jul 2014 08:08:52 -0700 (PDT) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [69.93.243.26]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5311A017F for ; Mon, 21 Jul 2014 08:08:52 -0700 (PDT) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 98C2D5DBB5B26; Mon, 21 Jul 2014 10:08:38 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway13.websitewelcome.com (Postfix) with ESMTP id F23A65DBB25D7 for ; Mon, 21 Jul 2014 10:08:37 -0500 (CDT) Received: from [31.133.164.43] (port=52813 helo=dhcp-a42b.meeting.ietf.org) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X9FCf-0005pJ-Db for tls@ietf.org; Mon, 21 Jul 2014 10:08:37 -0500 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <502C3758-9F12-4ABC-B595-FD0994A28B18@ieca.com> Date: Mon, 21 Jul 2014 11:08:35 -0400 To: "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 31.133.164.43 X-Exim-ID: 1X9FCf-0005pJ-Db X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-a42b.meeting.ietf.org) [31.133.164.43]:52813 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4FY5mMz71ETRmlDXyucMIouG9o0 Subject: [TLS] Call for adoption: draft-bhargavan-tls-session-hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:08:54 -0000 At the TLS interim meeting held Sunday the 20th of July 2014, we = discussed adopting the following draft: http://datatracker.ietf.org/doc/draft-bhargavan-tls-session-hash/ There was consensus to adopt it with the stipulation that the Signaling = Cipher Suite Value (SCSV) be removed. Please indicate whether you = object to adoption (and why) by July 25, 2014. spt PS Stay tuned for an early code point assignment thread. From nobody Mon Jul 21 08:11:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F241A0252 for ; Mon, 21 Jul 2014 08:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryf3-zXU21qg for ; Mon, 21 Jul 2014 08:11:00 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 588601A0217 for ; Mon, 21 Jul 2014 08:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4248; q=dns/txt; s=iport; t=1405955460; x=1407165060; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=t9WR8rqWT1G/ZMlvOQGaB89Z2KO9KFOa7dQVXUMs1YM=; b=RYitr/jzywWKYMcoKEChHRfvq7Pp+eUOXm6XYp70oKx6Q3WNZxNUIcEI JXAPxYnPXOazemfC9hNLBRt57yOhLL6v/Gb641lJ81hSE7CkNM57+I7Ge dw6kFItoVUfXSArOQjbnzRogMf3HksTH6hSV5l8EPhJUiK50qU/T+ORv3 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAGQszVOtJV2U/2dsb2JhbABZgw5SW8VCAQmHRQGBGBZ2hAQBAQQBAQFrCxACAQgEOwcnCxQRAgQOBYhCDb5TEwSPRwQHgy6BGAWbJZQvg0RsgUU X-IronPort-AV: E=Sophos; i="5.01,701,1400025600"; d="scan'208,217"; a="62697999" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP; 21 Jul 2014 15:10:59 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6LFAxKI015323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jul 2014 15:10:59 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Mon, 21 Jul 2014 10:10:59 -0500 From: "Joseph Salowey (jsalowey)" To: Alfredo Pironti Thread-Topic: [TLS] Resolution AEAD Cipher length and padding Thread-Index: AQHPpPHPs4RxOBnIA0miMPTuChlIcJuq8TQAgAAErQA= Date: Mon, 21 Jul 2014 15:10:58 +0000 Message-ID: References: <2F856D8D-44B1-4319-8D61-556F3C3ADE01@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.85.165.36] Content-Type: multipart/alternative; boundary="_000_C012B5C952DC478985F493BE4CF8F12Fciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SvshwTw2QuUXf36o83R4c5ACJ48 Cc: "" Subject: Re: [TLS] Resolution AEAD Cipher length and padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 15:11:08 -0000 --_000_C012B5C952DC478985F493BE4CF8F12Fciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jul 21, 2014, at 7:54 AM, Alfredo Pironti > wrote: It's not clear to me what this resolution is about; could you please elabor= ate (or give pointers)? Is this about AEAD ciphers built on top of block-encrypt then mac? To some = extent, current GCM and CCM ciphers are already expanding the cipher text l= ength by the tag length, so I must be missing the point here. Thanks. [Joe] to clarify: current AEAD cipher modes (GCM, CCM) do not expand the = cipher text through padding, their cipher text length is the same as the cl= ear text length. With the current construction you cannot support an AEAD = mode build out of an AES-CBC cipher because the cipher text length would no= t be the same as the clear text length. This resolution would change the c= onstruction to support AEAD ciphers that perform padding. Best, Alfredo On Mon, Jul 21, 2014 at 4:41 PM, Joseph Salowey (jsalowey) > wrote: At the interim meeting we decided to fix the specification of AEAD to suppo= rt ciphers that pad and expand the cipher text length. Please respond to t= his message by Friday, July 25 if you have an objection. Thanks, Joe [for the chairs] _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_C012B5C952DC478985F493BE4CF8F12Fciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jul 21, 2014, at 7:54 AM, Alfredo Pironti <alfredo@pironti.eu> wrote:

It's not clear to me what this resolution is about; could = you please elaborate (or give pointers)?
Is this about AEAD ciphers built on top of block-encrypt then mac? To some = extent, current GCM and CCM ciphers are already expanding the cipher text l= ength by the tag length, so I must be missing the point here. Thanks.


[Joe] to clarify:  current AEAD cipher modes (GCM, CCM)  do = not expand the cipher text through padding, their cipher text length is the= same as the clear text length.  With the current construction you can= not support an AEAD mode build out of an AES-CBC cipher because the cipher text length would not be the same as the clear t= ext length.  This resolution would change the construction to support = AEAD ciphers that perform padding. 


Best,
Alfredo


On Mon, Jul 21, 2014 at 4:41 PM, Joseph Salowey = (jsalowey) <jsalowey@cisco.com> wrote:
At the interim meeting we decided to fix the specification of AEAD to suppo= rt ciphers that pad and expand the cipher text length.  Please respond= to this message by Friday, July 25 if you have an objection.

Thanks,

Joe
[for the chairs]
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls


--_000_C012B5C952DC478985F493BE4CF8F12Fciscocom_-- From nobody Mon Jul 21 08:19:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1001A02A5 for ; Mon, 21 Jul 2014 08:19: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mecfdPHgleD5 for ; Mon, 21 Jul 2014 08:19:41 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 705C61A0252 for ; Mon, 21 Jul 2014 08:19:40 -0700 (PDT) Received: by mail-yk0-f180.google.com with SMTP id 200so4009011ykr.11 for ; Mon, 21 Jul 2014 08:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nij3/sfkh39oc62t3cQkEMaL7EKqsuzgzEuo3BjjKhM=; b=Y+xBEfjC6fNjGXFnen2UA+44TVSGxnVpiy8fQkehjNQ7pzAqhbXLMoLGj5+wQ8oxY2 wfoQA4ifTvi48RMBLKTytA8hPTet/qrVDmLXNlFORulaYpGvkKy3K45grF3ziC22uHht QJrlJ7ajrRM/yWL4Mnr3HIrN+WVL1w2KkQ2LMtuyf/jPYmXPjDEsoT1mcfPKG2/L2z5g BKZGW+++nSmZLNNZL9+kkcVR4GzvuSb2bl1hZa62QdZf0TjVRQAdID+SGjx9+2wCX24y 4XQ5/qvDZLWO48kXjiSGix4sdSsiXHUAfVxCNtqnIbMXZ1bN/oj1cq6TA/tIMAvTGZh+ A33A== MIME-Version: 1.0 X-Received: by 10.236.152.169 with SMTP id d29mr41412520yhk.83.1405955979712; Mon, 21 Jul 2014 08:19:39 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Mon, 21 Jul 2014 08:19:39 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Mon, 21 Jul 2014 08:19:39 -0700 (PDT) In-Reply-To: <502C3758-9F12-4ABC-B595-FD0994A28B18@ieca.com> References: <502C3758-9F12-4ABC-B595-FD0994A28B18@ieca.com> Date: Mon, 21 Jul 2014 08:19:39 -0700 Message-ID: From: Watson Ladd To: Sean Turner Content-Type: multipart/alternative; boundary=20cf3040ede8bd9fbe04feb5a238 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ILN9srqpFbZzRjq_NLlqTaLz6io Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Call for adoption: draft-bhargavan-tls-session-hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:19:45 -0000 --20cf3040ede8bd9fbe04feb5a238 Content-Type: text/plain; charset=UTF-8 On Jul 21, 2014 8:09 AM, "Sean Turner" wrote: > > At the TLS interim meeting held Sunday the 20th of July 2014, we discussed adopting the following draft: > > http://datatracker.ietf.org/doc/draft-bhargavan-tls-session-hash/ > > There was consensus to adopt it with the stipulation that the Signaling Cipher Suite Value (SCSV) be removed. Please indicate whether you object to adoption (and why) by July 25, 2014. I cannot say: does this fix the key exchange or not? It is unclear from the MiTLS papers, but because TLS is a mess I don't know if it fixes the problem without the MiTLS proof. > > spt > > PS Stay tuned for an early code point assignment thread. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --20cf3040ede8bd9fbe04feb5a238 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jul 21, 2014 8:09 AM, "Sean Turner" <TurnerS@ieca.com> wrote:
>
> At the TLS interim meeting held Sunday the 20th of July 2014, we discu= ssed adopting the following draft:
>
> http://datatracker.ietf.org/doc/draft-bhargavan-tls-session-hash/
>
> There was consensus to adopt it with the stipulation that the Signalin= g Cipher Suite Value (SCSV) be removed. =C2=A0Please indicate whether you o= bject to adoption (and why) by July 25, 2014.

I cannot say: does this fix the key exchange or not? It is u= nclear from the MiTLS papers, but because TLS is a mess I don't know if= it fixes the problem without the MiTLS proof.

>
> spt
>
> PS Stay tuned for an early code point assignment thread.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

--20cf3040ede8bd9fbe04feb5a238-- From nobody Mon Jul 21 08:21:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AD81A02A5 for ; Mon, 21 Jul 2014 08:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.133 X-Spam-Level: * X-Spam-Status: No, score=1.133 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHBTND1r8bu5 for ; Mon, 21 Jul 2014 08:21:50 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.56.159.20]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15CBC1A0178 for ; Mon, 21 Jul 2014 08:21:50 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id 5A9852BA70B23; Mon, 21 Jul 2014 10:21:49 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 397FC2BA70AA4 for ; Mon, 21 Jul 2014 10:21:49 -0500 (CDT) Received: from [31.133.164.43] (port=52897 helo=dhcp-a42b.meeting.ietf.org) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X9FPQ-0003VI-L6 for tls@ietf.org; Mon, 21 Jul 2014 10:21:48 -0500 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7C3D5CF9-2B17-4953-A13D-C5E7226D13E7@ieca.com> Date: Mon, 21 Jul 2014 11:21:47 -0400 To: "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 31.133.164.43 X-Exim-ID: 1X9FPQ-0003VI-L6 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-a42b.meeting.ietf.org) [31.133.164.43]:52897 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UmQrb8Zhbo91FPsQFfCLpFgtvr0 Subject: [TLS] tls 1.3: renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:21:51 -0000 At the TLS interim meeting held on Sunday July 20th, 2014, there was = consensus to remove renegotiation on the assumption we will provide a = rekeying facility of some form and client initated client = authentication. This message serves to confirm that consensus. Please = indicate by July 25th, 2014 whether you disagree with this (and why). spt= From SRS0=Mag+=4Q=acm.org=bmoeller@srs.kundenserver.de Mon Jul 21 08:34:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A961A0137 for ; Mon, 21 Jul 2014 08:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWnXM5nSL8ZK for ; Mon, 21 Jul 2014 08:34:00 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C637A1A00B8 for ; Mon, 21 Jul 2014 08:33:59 -0700 (PDT) Received: from mail-yh0-f43.google.com (mail-yh0-f43.google.com [209.85.213.43]) by mrelayeu.kundenserver.de (node=mreue003) with ESMTP (Nemesis) id 0LeyRX-1WkKAk1hnz-00qmY4; Mon, 21 Jul 2014 17:33:57 +0200 Received: by mail-yh0-f43.google.com with SMTP id 29so4136037yhl.16 for ; Mon, 21 Jul 2014 08:33:52 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.223.229 with SMTP id v95mr41912074yhp.128.1405956832277; Mon, 21 Jul 2014 08:33:52 -0700 (PDT) Received: by 10.170.129.17 with HTTP; Mon, 21 Jul 2014 08:33:52 -0700 (PDT) In-Reply-To: References: <2F856D8D-44B1-4319-8D61-556F3C3ADE01@cisco.com> Date: Mon, 21 Jul 2014 11:33:52 -0400 Message-ID: From: Bodo Moeller To: "Joseph Salowey (jsalowey)" Content-Type: multipart/alternative; boundary=001a11c1ecbe8ebdbc04feb5d537 X-Provags-ID: V02:K0:jk32ipftDqGtSJDK5N5p3qY0D+Uvoug14JpdvcflZ8K vWQarrwCt2w2ISoAFNW2BCMvsJ1ihhI+IYIKtxOj3DpXq1bO0V rMXnflsCB4HeZOmg+GTW11R4w4E0l2NL7VjAETzzZzbS7G3NF4 R5bptb+Ixe+4ESDQ9U72h9fZDA4Nifdewga24yhd5KpMieRBCh 4jP3Y3VVBmc/gcy4oCCiKRoe7eaonFDliaw3s8/cwFy8HzCQrc pLBEeBpGXel31JG9wj63+dS/f1SGXxwG5yxbg0E+MMAREv1/dL VF6Yzqq7kQZzQu8B4OQ33xDYoy9ui0+fligLg51kavZTVxXs8h xy+JRBEzmgiRLtsjCgR3Y/zFYwfutoNRfDEZlyl62ilIDvXZjb 6NIXckfaxWh9QJ4EqVAPslkARHxb6SFOZXEZiUGco9vw5fMVr8 oev8P Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jITCbXxulR4XJmssdi4V9m1u7wQ Cc: "" , Alfredo Pironti Subject: Re: [TLS] Resolution AEAD Cipher length and padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 15:35:29 -0000 --001a11c1ecbe8ebdbc04feb5d537 Content-Type: text/plain; charset=UTF-8 Joseph Salowey (jsalowey) : > > On Jul 21, 2014, at 7:54 AM, Alfredo Pironti wrote: > > It's not clear to me what this resolution is about; could you please > elaborate (or give pointers)? > Is this about AEAD ciphers built on top of block-encrypt then mac? To some > extent, current GCM and CCM ciphers are already expanding the cipher text > length by the tag length, so I must be missing the point here. Thanks. > > > [Joe] to clarify: current AEAD cipher modes (GCM, CCM) do not expand > the cipher text through padding, their cipher text length is the same as > the clear text length. > I think the authentication tag (8 octets for these -- RFC 5288 or RFC 6655) is considered part of the ciphertext for the AEAD interface (RFC 5116) as used by TLS 1.2 (RFC 5246), so length expansion indeed already takes place. So unless I'm missing something, the point actually is that with these the exact amount of length expansion is implicit (and you can recover TLSPlaintext.length and thus determine additional_data by subtracting a constant from the ciphertext length). Thus, this decision is not about padding per se, but specifically about *variable* padding, which wouldn't work with the current spec. Bodo --001a11c1ecbe8ebdbc04feb5d537 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jose= ph Salowey (jsalowey) <jsalowey@cisco.com>:
On Jul 21, 2014, at 7:54 AM, Alfredo Pironti <alfredo@pironti.eu> wrote:

It's not clear to me what this resolution is about; co= uld you please elaborate (or give pointers)?
Is this about AEAD ciphers built on top of block-encrypt then mac? To some = extent, current GCM and CCM ciphers are already expanding the cipher text l= ength by the tag length, so I must be missing the point here. Thanks.


[Joe] to clarify: =C2=A0current AEAD cipher modes (GCM, CCM) =C2= =A0do not expand the cipher text through padding, their cipher text length = is the same as the clear text length.
I think the authentication tag (8 octets for these -- RFC 5288 or RFC = 6655) is considered part of the ciphertext for the AEAD interface (RFC 5116= ) as used by TLS 1.2 (RFC 5246), so length expansion indeed already takes p= lace. =C2=A0So unless I'm missing something, the point actually is that= with these the exact amount of length expansion is implicit (and you can r= ecover TLSPlaintext.length and thus determine additional_data by subtractin= g a constant from the ciphertext length).

Thus, this decision is not about padding per se, but sp= ecifically about *variable* padding, which wouldn't work with the curre= nt spec.

Bodo

--001a11c1ecbe8ebdbc04feb5d537-- From nobody Mon Jul 21 08:57:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D2B1A02E6 for ; Mon, 21 Jul 2014 08:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4egozj_NKlM for ; Mon, 21 Jul 2014 08:57:12 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23A5E1A02DE for ; Mon, 21 Jul 2014 08:57:11 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id z12so6617903wgg.12 for ; Mon, 21 Jul 2014 08:57:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jccVL5DSmEMay/qgLNeRad3Sx6StJuJnFrMU49nYLCo=; b=W9HpaxgQm2V0Og6mx14nTdCx7v502I834iQHMGCDPhwCOQyzfYD+GGC0Q1gNZSIqDl ypjOayss8C+aqNDO/ueaPshq8td6BhpgIy1PxkComf4v1AxlJ1hozKsJhBxaYAPaYcYV RCk5UygbJcfNoYpTv6xytwcdxKJuG3NtE0a9mlDuiFS8OF33ARMME9oGV2MS55eV1tZR uC68b5GQSRmG59M3SVkyRscLArtGnsVR4F9q/jhXOU+EM/anaVkLwTD4CyfNXuoyLZ3T MJlmtJEAfauhs46HLDVYHfOYpLLfBonTYOFtopjJ8uCTINH+xMmYVGBztuweCK6Bf7c0 3rQw== X-Gm-Message-State: ALoCoQn/IDUYHBaLXTFlcWxyNgrS4AvxBYMFLGtiKMkUzgfedFgLPb90mBlCtZUFlnm4XU8I+AUT X-Received: by 10.194.71.52 with SMTP id r20mr23469639wju.113.1405958229576; Mon, 21 Jul 2014 08:57:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.44.138 with HTTP; Mon, 21 Jul 2014 08:56:49 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7185928AAB5@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7185928AAB5@USMBX1.msg.corp.akamai.com> From: Benjamin Black Date: Mon, 21 Jul 2014 08:56:49 -0700 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=047d7bfcec50d7ed8004feb6283c Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ElpIXjvW0MpPjr79spN2lJ8rzek Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Formal request from TLS WG to CFRG for new elliptic curves X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 15:57:13 -0000 --047d7bfcec50d7ed8004feb6283c Content-Type: text/plain; charset=UTF-8 On Mon, Jul 21, 2014 at 7:47 AM, Salz, Rich wrote: > > TLS 1.2 offered no compelling advantages. > > Yes. TLS 1.3 will offer some good reasons to adopt, from the simplicity, > security, privacy, and efficiency areas. The comparison to TLS 1.2 doesn't > hold. > > We are all speculating here, but I don't see how TLS 1.3 will be different from every other new protocol/version. These things take years, even if there are some large early adopters. Ben --047d7bfcec50d7ed8004feb6283c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jul 21, 2014 at 7:47 AM, Salz, Rich <rsalz@akamai.com> wr= ote:
> TLS 1.2 offered no compelling advantages.

Yes. =C2=A0TLS 1.3 will offer some good reasons to adopt, from the si= mplicity, security, privacy, and efficiency areas. =C2=A0The comparison to = TLS 1.2 doesn't hold.

<= br>
We are all speculating here, but I don't see how TLS 1.3 = will be different from every other new protocol/version. These things take = years, even if there are some large early adopters.


Ben
--047d7bfcec50d7ed8004feb6283c-- From nobody Mon Jul 21 08:57:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980181A02F9 for ; Mon, 21 Jul 2014 08:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euY1FsH5qHhj for ; Mon, 21 Jul 2014 08:57:27 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B8C21A02F4 for ; Mon, 21 Jul 2014 08:57:23 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id z60so5527960qgd.33 for ; Mon, 21 Jul 2014 08:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=5lSnoO+pSO0AQ8PmLyy5yNPOWtLwWH8v9zYfeRLGvT4=; b=x5+STMSuKVS5bdZ5u2btvevjet8R8aOZygTloZIbqaJtQIKLwvAmVmsmEZ42iFm4qc bf1rT5rGpAs9RFP6yx4xtPpWxyZ+DX3rydp81Sjkajiz/iEVsvaZ5TLTrlIihHTsRHjI rvA6KAsxLgZbvj69Febxuponb6XpzW/53EFcRwH+AV49LVBOPMnpjryqAcf5sJCC8If8 wb5qJ02+2hdftskpW9fxCSyPDAv/9CuLAUpd0ooCsEC98kQpYBOqU3l2qg+de9Cvdxzp ry+MxlzdQAG4nfso/hUeoYe4KEGLsV3eVuGQDClCQXCrkn52XC+/PzYPiovEVyH4dmS6 p/nw== X-Received: by 10.224.163.144 with SMTP id a16mr7525177qay.61.1405958242538; Mon, 21 Jul 2014 08:57:22 -0700 (PDT) Received: from [10.0.1.3] (pool-71-161-98-142.cncdnh.east.myfairpoint.net. [71.161.98.142]) by mx.google.com with ESMTPSA id d69sm16505495qge.35.2014.07.21.08.57.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 08:57:21 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_52AB78FB-4FFA-4E59-A4C1-B5301D4414DE" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Mon, 21 Jul 2014 11:57:19 -0400 Message-Id: References: <502C3758-9F12-4ABC-B595-FD0994A28B18@ieca.com> To: Watson Ladd X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OmP0Ed6cHdW9W6iNHKWmBzB0QlE Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Call for adoption: draft-bhargavan-tls-session-hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:57:32 -0000 --Apple-Mail=_52AB78FB-4FFA-4E59-A4C1-B5301D4414DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We have ProVerif-based analyses that show that the session hash fixes = the triple-handshake problem for clients and servers that implement any = combination of: - TLS-RSA - TLS-DHE - Resumption with a Cache or Session Tickets - Renegotiation with Renegotiation Indication - SCRAM-SHA-1-PLUS with tls-unique channel binding The analysis shows that, even if these features of TLS are implemented = unchanged (i.e. arbitrary DH groups, no public key validation, = renegotiation with any third-party, current definition of tls-unique), = the TLS session hash guarantees composite agreement on the sequence of = epochs on the current connection and also on their session parameters. = The guarantee is similar to that of Giesen et al in CCS=9213 [1] but = extended to session resumption and extends to some other channel = bindings like tls-unique and channel ID. Having said that, our guarantees are in the symbolic model, and are not = yet cryptographic proofs. Proof of the session hash implementation in = miTLS is ongoing.=20 Moreover, we cannot say anything about other ciphersuites, except to = give general guidelines on what to watch out for.=20 If there is interest, we=92d be happy to make available our formal = ProVerif models in some form and cite it within the current session-hash = draft. [1] https://eprint.iacr.org/2012/630 Best regards, Karthik On 21 Jul 2014, at 11:19, Watson Ladd wrote: >=20 > On Jul 21, 2014 8:09 AM, "Sean Turner" wrote: > > > > At the TLS interim meeting held Sunday the 20th of July 2014, we = discussed adopting the following draft: > > > > http://datatracker.ietf.org/doc/draft-bhargavan-tls-session-hash/ > > > > There was consensus to adopt it with the stipulation that the = Signaling Cipher Suite Value (SCSV) be removed. Please indicate whether = you object to adoption (and why) by July 25, 2014. >=20 > I cannot say: does this fix the key exchange or not? It is unclear = from the MiTLS papers, but because TLS is a mess I don't know if it = fixes the problem without the MiTLS proof. >=20 > > > > spt > > > > PS Stay tuned for an early code point assignment thread. > > > > > > _______________________________________________ > > 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 --Apple-Mail=_52AB78FB-4FFA-4E59-A4C1-B5301D4414DE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 We have ProVerif-based analyses = that show that the session hash fixes the triple-handshake problem for = clients and servers that implement any combination of:
- TLS-RSA
- TLS-DHE
- Resumption = with a Cache or Session Tickets
- Renegotiation with = Renegotiation Indication
- SCRAM-SHA-1-PLUS with = tls-unique channel binding

The analysis = shows that, even if these features of TLS are implemented unchanged = (i.e. arbitrary DH groups, no public key validation, renegotiation with = any third-party, current definition of tls-unique), the TLS session hash = guarantees composite agreement on the sequence of epochs on the current = connection and also on their session parameters. The guarantee is = similar to that of Giesen et al in CCS=9213 [1] but extended to session = resumption and extends to some other channel bindings like tls-unique = and channel ID.

Having said = that, our guarantees are in the symbolic model, and are not yet = cryptographic proofs. Proof of the session hash implementation in miTLS = is ongoing. 

Moreover, = we cannot say anything about other ciphersuites, except to give general = guidelines on what to watch out for. 

If = there is interest, we=92d be happy to make available our formal ProVerif = models in some form and cite it within the current session-hash = draft.



Best = regards,
Karthik

On 21 Jul = 2014, at 11:19, Watson Ladd <watsonbladd@gmail.com> = wrote:


On Jul 21, 2014 8:09 AM, "Sean Turner" <TurnerS@ieca.com> wrote:
>
> At the TLS interim meeting held Sunday the 20th of July 2014, we = discussed adopting the following draft:
>
> http://datatracker.ietf.org/doc/draft-bhargavan-tls-session-hash/
= >
> There was consensus to adopt it with the stipulation that the = Signaling Cipher Suite Value (SCSV) be removed.  Please indicate = whether you object to adoption (and why) by July 25, 2014.

I cannot say: does this fix the key exchange or not? It is = unclear from the MiTLS papers, but because TLS is a mess I don't know if = it fixes the problem without the MiTLS proof.

>
> spt
>
> PS Stay tuned for an early code point assignment thread.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/ma= ilman/listinfo/tls

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

= --Apple-Mail=_52AB78FB-4FFA-4E59-A4C1-B5301D4414DE-- From nobody Mon Jul 21 08:57:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DED1A02FB for ; Mon, 21 Jul 2014 08:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0Qdp3wu8kxy for ; Mon, 21 Jul 2014 08:57:38 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCBF11A02F7 for ; Mon, 21 Jul 2014 08:57:34 -0700 (PDT) Received: by mail-oi0-f52.google.com with SMTP id h136so3498579oig.39 for ; Mon, 21 Jul 2014 08:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yhfHP7Z2VQt73u6Y+Me41tz8/iU9LNQwBF5goByqYrU=; b=EOI6py0EHv6yIBpt4FMynIkU8dNU0b16QDSntTg1YvBIiWrPF2a+FgSmeWb6g4Tv2T Pb++3DWP9oza4YB4io3FHyC4oNLf2rJL3rnJtyd1Mgl7IoIfkN02ou6hvgQwfgqlxC23 +0qYrBXPGOTfk4HF4sQccbOzbfJXJ8H72DOME= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yhfHP7Z2VQt73u6Y+Me41tz8/iU9LNQwBF5goByqYrU=; b=go5b79N+pCWcJ1QQKXmcBGAmH8vc/tmuNdf9ObbZyGppq5qyWC4Xb2sbJIpe/eb69C owa50qtJA3p+MADv5yqNmr9tP2VeOwdVVeKPXaOW3Mo7RZVzLfjVSlH68CgD5WCrFELt Fhmdxka871twPk1MKiO1AlB+JRCAo7VgykGLWveLLmekI/kOyN0MFnQxJLmTYjpnOaeL JPq4EZ/swU/W4FktYCHhPE4xd+per+NuP7iBA8BcCBujdJMRNbClvMcUORgdjQ75syRz XX3uuNELYVtJMM3IBS2D8LXgk8Fvj6jsuCkc+8qGT7LXKVPIwI4UVoVYFs420OFHHSZ2 iq6A== X-Gm-Message-State: ALoCoQlQ2VHovM+1m2mWuxTplxEKZHM5CHUOJkX9UL4HaVYOP1gWxmoBQTeRGM5rL5ELVJOgfvfJ MIME-Version: 1.0 X-Received: by 10.182.24.193 with SMTP id w1mr39056439obf.47.1405958252631; Mon, 21 Jul 2014 08:57:32 -0700 (PDT) Received: by 10.76.25.42 with HTTP; Mon, 21 Jul 2014 08:57:32 -0700 (PDT) X-Originating-IP: [128.93.188.195] In-Reply-To: <502C3758-9F12-4ABC-B595-FD0994A28B18@ieca.com> References: <502C3758-9F12-4ABC-B595-FD0994A28B18@ieca.com> Date: Mon, 21 Jul 2014 17:57:32 +0200 Message-ID: From: Alfredo Pironti To: Sean Turner Content-Type: multipart/alternative; boundary=001a11c2ff9437c94c04feb62a4c Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NERdNd88aOc5gQ1Ll0223JlGE2Y Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Call for adoption: draft-bhargavan-tls-session-hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:57:39 -0000 --001a11c2ff9437c94c04feb62a4c Content-Type: text/plain; charset=UTF-8 Thanks for the update. As requested, I've uploaded an updated version with SCSV removed. Cheers, Alfredo On Mon, Jul 21, 2014 at 5:08 PM, Sean Turner wrote: > At the TLS interim meeting held Sunday the 20th of July 2014, we discussed > adopting the following draft: > > http://datatracker.ietf.org/doc/draft-bhargavan-tls-session-hash/ > > There was consensus to adopt it with the stipulation that the Signaling > Cipher Suite Value (SCSV) be removed. Please indicate whether you object > to adoption (and why) by July 25, 2014. > > spt > > PS Stay tuned for an early code point assignment thread. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c2ff9437c94c04feb62a4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the update. As requested, I've uploade= d an updated version with SCSV removed.

Cheers,
Alfredo
=


On Mon,= Jul 21, 2014 at 5:08 PM, Sean Turner <TurnerS@ieca.com> wrot= e:
At the TLS interim meeting held Sunday the 2= 0th of July 2014, we discussed adopting the following draft:

http://datatracker.ietf.org/doc/draft-bhargavan-tls-se= ssion-hash/

There was consensus to adopt it with the stipulation that the Signaling Cip= her Suite Value (SCSV) be removed. =C2=A0Please indicate whether you object= to adoption (and why) by July 25, 2014.

spt

PS Stay tuned for an early code point assignment thread.


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

--001a11c2ff9437c94c04feb62a4c-- From nobody Mon Jul 21 09:51:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4BD1B28D0 for ; Sat, 19 Jul 2014 09:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsOS6Nzv6L4f for ; Sat, 19 Jul 2014 09:28:58 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29EE81B28C1 for ; Sat, 19 Jul 2014 09:28:58 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q58so5816550wes.7 for ; Sat, 19 Jul 2014 09:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=weEL9o6UMyJAytivpy75UwDGEgMb94zvGpsETA7pjNg=; b=PZ627409U22M50uxymYe8gpVPgrR+wpru0TIsSrFw0aEOf3zzA/TKgZKELrcaoTAsu vHvX1DlPW74IPhph7XW5ZIX21p9tB+lMau1BL6cHBiH6a4q8jR+n+HO5W5RhFtO5PC69 vU+18t4HMbvf4pKMQp6+6u3QUNLLCyumLNi3bJkbYrp0lSnaKW3W7Rh524qrTmbNAg/f 4Co13gPnegdtZWRbmVG9RSqEmOy5PxxWkZhWDNxkMIvvK9J8slDq7982hOtjHw+OWI6g 09RK16y1fkR++XSzNUSGd69j24qo65AkZdnO6AJDMQ0+EtZ8Ufezt4jd2bwiS9Iqm6lV z24w== MIME-Version: 1.0 X-Received: by 10.194.158.226 with SMTP id wx2mr6371288wjb.107.1405787336601; Sat, 19 Jul 2014 09:28:56 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.123.167 with HTTP; Sat, 19 Jul 2014 09:28:56 -0700 (PDT) Date: Sat, 19 Jul 2014 12:28:56 -0400 X-Google-Sender-Auth: HrB6dfjxTHr_bhEo44V4lc08e5Q Message-ID: From: Phillip Hallam-Baker To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Bf0x0ip6vdWgxrEK67h08uGzZ_U X-Mailman-Approved-At: Mon, 21 Jul 2014 09:51:52 -0700 Subject: [TLS] Non-TLS opportunistic encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2014 16:28:59 -0000 While at the Hope conference watching the 'HTTP must die' presentation I had an idea that might or might not be useful. People frequently propose use of opportunistic TLS with self-signed credentials. This worries me for two reasons: 1) TLS is a huge standard with a lot of details that have to be got right. It takes a lot of time and effort to implement and a lot of memory to run. Constrained devices are going to find it very hard to do TLS 2) One consequence of (1) is that opportunistic TLS risks weakening the https infrastructure rather than improving the http infrastructure. That is not a win as far as I am concerned. So one proposal that is made is to drop the padlock icon when non-credentialed self-signed certs or keys passed in band are in use. This seems a very good approach to me but we still have the problem of it being a 'thick stack'. This is even more problematic when we consider the fact that most of that 'thick stack' is actually involved in addressing issues that just don't apply if we are not going to validate the end-entity-keys. Self-signed certs are a reasonable way to exchange keys in a world where the infrastructure has ubiquitous support for X.509 path math. But why clutter up the client with the path math if we are not going to check cert chains? If we are going to insist on 'encryption everywhere' and accept opportunistic encryption then all we need is a D-H key agreement and some mechanism for applying encryption to packets. The result might be TLS-Lite, a very minimal subset of TLS or it might be a completely different protocol. But the key thing would be to keep it separate from TLS so that ubiquitous best effort TLS does not end up weakening regular TLS. From nobody Mon Jul 21 10:17:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349FF1A009E for ; Mon, 21 Jul 2014 10:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfSjqfRR948q for ; Mon, 21 Jul 2014 10:17:54 -0700 (PDT) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77B2F1A02DB for ; Mon, 21 Jul 2014 10:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:To:MIME-Version:From:Date:Message-ID; bh=7vnZu/i2jgy3Km+AuzeVm9SC8erNP4YZXMahYq/Lu60=; b=okdzQ8CILIJOUY66ZXkWkqEMGV2kWZZQaSUIy7L00JLs5+7KYJ/t/H7vvU9960z+DWgeBzifsZ5tP5uOqTzXJUOtVxEEpDMhpGnOnsBfFMNP9KJnTKph7BF0vOHtvRW1u9HKCVgR8Oz7qTuUOK0UDCKxnHv1eH3JNwC5lonY7y4=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1X9HDc-0001Dy-SO for tls@ietf.org; Mon, 21 Jul 2014 19:17:45 +0200 Message-ID: <53CD4B2C.5080906@polarssl.org> Date: Mon, 21 Jul 2014 19:17:32 +0200 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rRSiR1s55E6CoP0ZM37AKxWezd0 Subject: [TLS] DTLS HelloVerifyRequest.server_version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 17:17:55 -0000 Hi, Sorry if I'm just being dense and fail to understand something very obvious, but I have trouble understanding how the server_version field of HelloVerifyRequest should be handled, according to section 4.2.1 of RFC 6347. More precisely, I'm under the impression that the last paragraph of page 15 and the first of page 16 contain contradictory statements: DTLS 1.2 server implementations SHOULD use DTLS version 1.0 regardless of the version of TLS that is expected to be negotiated. The server MUST use the same version number in the HelloVerifyRequest that it would use when sending a ServerHello. It seems to me that if a server obeys the MUST of the second sentence, it cannot obey the SHOULD of the first one (unless of course it never negotiates DTLS 1.2, which I assume is not the intention of the RFC). DTLS 1.2 and 1.0 clients MUST use the version solely to indicate packet formatting (which is the same in both DTLS 1.2 and 1.0) and not as part of version negotiation. In particular, DTLS 1.2 clients MUST NOT assume that because the server uses version 1.0 in the HelloVerifyRequest that the server is not DTLS 1.2 or that it will eventually negotiate DTLS 1.0 rather than DTLS 1.2. Upon receipt of the ServerHello, the client MUST verify that the server version values match. It seems to me that verifying the server version values match (between HelloVerifyRequest and ServerHello) is actually using the version for another goal that "to indicate packet formatting", something that seems to be forbidden. Am I misinterpreting the text? Thanks, Manuel From nobody Mon Jul 21 10:18:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F091A026E for ; Mon, 21 Jul 2014 10:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.779 X-Spam-Level: X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWPbC_NHcldK for ; Mon, 21 Jul 2014 10:18:02 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A3081A02E5 for ; Mon, 21 Jul 2014 10:18:02 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id hq11so11199249vcb.16 for ; Mon, 21 Jul 2014 10:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YcwmOpj6Cr7pLIk6BYq0qoxPspfbtZP+x8UCCgJukbo=; b=sCknBuXzeNoYp7PjoXsCC/AthMLO9db0OOQr9ijakMEs/JfnaFoQkZqU5aYNg8ORsH tJfbsCFg/r1fioL6ySKGWTreblUkbIkrHsUhkDpFCummK3g8x+TQNKF8ih3Qa6oT06FD CNTMD1r6TbJfvdzLl3NUYKSFfY1au7HgHF33U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YcwmOpj6Cr7pLIk6BYq0qoxPspfbtZP+x8UCCgJukbo=; b=LXP+GyramtzgSxCrC67HXJ3gKp6WjDejUiZiHosb16ILjgRPzlQKq9P6Nknaty9iK9 sYGsUPE6nMHuM7u1Bt1ssQGYZpUWSGigkWwy62PnHcpoFuzOjZZ1A1GMDuqdo5smVN0S biPde0IQIBVmZ4b3ZsxmGaIsx8aemUYKKn49naHGBdL94xFfaMazhTmbig4i/h3IJDoo bzh7Y29Qr/HUJVUdsGV8wR3gvHku9jcEqS9ldtVsoNWCHFN4qBB8sIuKKJJSYvAwNxi6 HFtLpA6+AG3CVgIwTIcUaajJ6P1rW5bTFgpFKnhEvH8I+q2LWiernRgKDEZK8tYS8bUu I/6Q== X-Gm-Message-State: ALoCoQkKLRjIevDn6ZZj41wMdYg1WZD1BUtuG0vURqGsxLlRvCz196EJSs7ejmI3yx7LhH/o/ihB X-Received: by 10.52.84.2 with SMTP id u2mr3448469vdy.84.1405963080772; Mon, 21 Jul 2014 10:18:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.124.131 with HTTP; Mon, 21 Jul 2014 10:17:40 -0700 (PDT) In-Reply-To: References: From: Tom Ritter Date: Mon, 21 Jul 2014 12:17:40 -0500 Message-ID: To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/y-4sWRnaYp2gwkcmAKvHhLnTe7c Cc: "tls@ietf.org" Subject: Re: [TLS] Non-TLS opportunistic encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 17:18:03 -0000 On 19 July 2014 11:28, Phillip Hallam-Baker wrote: > If we are going to insist on 'encryption everywhere' and accept > opportunistic encryption then all we need is a D-H key agreement and > some mechanism for applying encryption to packets. > > The result might be TLS-Lite, a very minimal subset of TLS or it might > be a completely different protocol. But the key thing would be to keep > it separate from TLS so that ubiquitous best effort TLS does not end > up weakening regular TLS. It's not clear to me exactly what you mean by 'weakening regular TLS' - I'd also disagree that opportunistic encryption should get any of the UI indicators that TLS gets. I'm not sure if Opportunistic TLS is still on-topic for this list, but the primary concern I've seen people put forward (and agree with) about Unauthenticated Ciphersuites or a DH handshake is that with self-signed certs - you can build a Convergence-style in-line authenticity system or a CT-style after-the-fact detection system on top of it. With the other options, you lose that capability. And if you try and shoe-horn a long-lived signing key on top of that, you've reinvented some subset of TLS+PKIX - why not just use that subset and not require any (significant) server code changes. -tom From nobody Mon Jul 21 10:35:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535141A01C8 for ; Mon, 21 Jul 2014 10:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5_CVBlBtQQV for ; Mon, 21 Jul 2014 10:34:57 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7379D1A01AC for ; Mon, 21 Jul 2014 10:34:57 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id k15so5258526qaq.38 for ; Mon, 21 Jul 2014 10:34:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mDfuWDTqx42iaYcW1lng8zzUvkGReL+IZsF4sBa1lI0=; b=g4RhyKER9OcHcLmotg6NiZH9kJz/tJjmtdKGqr2699IIBfPYM/F6HrVwmsRGOZgxBr JRQBWJ89xjv0pIARYyeeODDlPof/9eChLam4MfMgAbEo9pYFkOsqPO3AAlJ8kqVHPoEU S4h2HGAm6Dp+FqL6k79PW62VoNqrnHo3b09rNVe0xOsMNXF995doSGCXcSfpjQTNb9ra w9znNscu9TXYNZZncPc5zNCGMdG97LYRxN4911YtmoxmTl2LiecJ0kZJ1Oi1pF3wkvCj 3z6VeckK6OxexNzbBELhS7KHTIVYNu6fNw5d6ydKHSmULfCqDVckA76f/lOsLI2f0lVj vgLQ== X-Gm-Message-State: ALoCoQnAKdTEQU26nfAQTf4w8SDNyPvVWx9VheCl87yMuExMLRPyYCpiY1rA9MMtHVaX6JzABgkQ X-Received: by 10.140.109.164 with SMTP id l33mr41855142qgf.72.1405964096229; Mon, 21 Jul 2014 10:34:56 -0700 (PDT) Received: from ?IPv6:2001:67c:370:144:dc9a:60e2:4cde:74a0? ([2001:67c:370:144:dc9a:60e2:4cde:74a0]) by mx.google.com with ESMTPSA id 106sm3163355qgo.16.2014.07.21.10.34.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 10:34:55 -0700 (PDT) Message-ID: <53CD4F3B.4090704@nthpermutation.com> Date: Mon, 21 Jul 2014 13:34:51 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <502C3758-9F12-4ABC-B595-FD0994A28B18@ieca.com> In-Reply-To: <502C3758-9F12-4ABC-B595-FD0994A28B18@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8iiAE1a22zQQDDoAFmigdJbmmt0 Subject: Re: [TLS] Call for adoption: draft-bhargavan-tls-session-hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 17:35:00 -0000 On 7/21/2014 11:08 AM, Sean Turner wrote: > At the TLS interim meeting held Sunday the 20th of July 2014, we discussed adopting the following draft: > > http://datatracker.ietf.org/doc/draft-bhargavan-tls-session-hash/ > > There was consensus to adopt it with the stipulation that the Signaling Cipher Suite Value (SCSV) be removed. Please indicate whether you object to adoption (and why) by July 25, 2014. > > spt > > PS Stay tuned for an early code point assignment thread. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > How does this work with 1rtt? E.g. the first message sent from the client side includes the ClientHello and embedded extension containing the ClientKeyExchange. As I read this, the hash would then only cover that message. (E.g. it says "up to and including ClientKeyExchange"). > When a full handshake takes place, we define > > session_hash = Hash(handshake_messages) > > where "handshake_messages" refers to all handshake messages sent or > received, starting at client hello up to and including the Client Key > Exchange message, including the type and length fields of the > handshake messages. This is the concatenation of all the exchanged > Handshake structures, as defined in Section 7.4 of [RFC5246]. To be honest, I'm not a big fan of this approach as it requires the derivation of the master secret to be deferred until all the other exchanges are done and that seems to be counter to the move towards fewer round trips and prevents the ability to encrypt any of the handshake messages. Or did I miss something here? I would note that the attack on RSA encrypted secrets is not applicable to TLS1.3 as Key Transport as a pre-master mechanism is being removed. More detail expanding the DHE (and ECDHE) attack would be useful. Mike From nobody Mon Jul 21 11:03:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AAE91A0235 for ; Mon, 21 Jul 2014 11:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRZB0bLgBXYt for ; Mon, 21 Jul 2014 11:02:58 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 670371A0023 for ; Mon, 21 Jul 2014 11:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4794; q=dns/txt; s=iport; t=1405965778; x=1407175378; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=voTuaXNWMn2Ur/MkPR5H+pbusXi03W8qCYI1RphjODo=; b=L5ApCaMDuhgRxkLjmIyOTIoBs6NkZuhA43AG4W8j61gQQa2516Awv3lY jdys8nhqASh5ilf/3OSKQ3qFpj31CJrtxzKYoen3a2iZHy8VksUESlqpB 2lXwXk8E2bBxG5qNV/p3CJ3nVP/GpUyCFYizWYun7wiEc3cjWn3I6NdDK s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAGtVzVOtJA2F/2dsb2JhbABZgw6BLc0RAYEdFnaEBAEBBHkQAgEIBAoxBzIUEQIEDgWIQr5cF49LB4MugRgFmyWUL4NEbIFF X-IronPort-AV: E=Sophos;i="5.01,702,1400025600"; d="scan'208,217";a="341685681" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP; 21 Jul 2014 18:02:57 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6LI2vLI005085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jul 2014 18:02:57 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Mon, 21 Jul 2014 13:02:57 -0500 From: "Joseph Salowey (jsalowey)" To: Bodo Moeller Thread-Topic: [TLS] Resolution AEAD Cipher length and padding Thread-Index: AQHPpPHPs4RxOBnIA0miMPTuChlIcJuq8TQAgAAErQCAAAZmAIAAJpeA Date: Mon, 21 Jul 2014 18:02:57 +0000 Message-ID: References: <2F856D8D-44B1-4319-8D61-556F3C3ADE01@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.85.165.61] Content-Type: multipart/alternative; boundary="_000_F622B101CC844AF19D9591E1ABE8158Cciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rNSuauGkWWTtzT0iS4eMbbBc3OA Cc: "" , Alfredo Pironti Subject: Re: [TLS] Resolution AEAD Cipher length and padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 18:03:01 -0000 --_000_F622B101CC844AF19D9591E1ABE8158Cciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jul 21, 2014, at 8:33 AM, Bodo Moeller > wrote: Joseph Salowey (jsalowey) >: On Jul 21, 2014, at 7:54 AM, Alfredo Pironti > wrote: It's not clear to me what this resolution is about; could you please elabor= ate (or give pointers)? Is this about AEAD ciphers built on top of block-encrypt then mac? To some = extent, current GCM and CCM ciphers are already expanding the cipher text l= ength by the tag length, so I must be missing the point here. Thanks. [Joe] to clarify: current AEAD cipher modes (GCM, CCM) do not expand the = cipher text through padding, their cipher text length is the same as the cl= ear text length. I think the authentication tag (8 octets for these -- RFC 5288 or RFC 6655)= is considered part of the ciphertext for the AEAD interface (RFC 5116) as = used by TLS 1.2 (RFC 5246), so length expansion indeed already takes place.= So unless I'm missing something, the point actually is that with these th= e exact amount of length expansion is implicit (and you can recover TLSPlai= ntext.length and thus determine additional_data by subtracting a constant f= rom the ciphertext length). Thus, this decision is not about padding per se, but specifically about *va= riable* padding, which wouldn't work with the current spec. [Joe] Yes, that would be more accurate - variable length padding added as p= art of the encryption process. Bodo --_000_F622B101CC844AF19D9591E1ABE8158Cciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jul 21, 2014, at 8:33 AM, Bodo Moeller <bmoeller@acm.org> wrote:

Joseph Salowey (jsalowey) <= jsalowey@cisco.com<= /a>>:

It's not clear to me what this resolution is about; could = you please elaborate (or give pointers)?
Is this about AEAD ciphers built on top of block-encrypt then mac? To some = extent, current GCM and CCM ciphers are already expanding the cipher text l= ength by the tag length, so I must be missing the point here. Thanks.


[Joe] to clarify:  current AEAD cipher modes (GCM, CCM)  do = not expand the cipher text through padding, their cipher text length is the= same as the clear text length.

I think the authentication tag (8 octets for these -- RFC 5288 or RFC = 6655) is considered part of the ciphertext for the AEAD interface (RFC 5116= ) as used by TLS 1.2 (RFC 5246), so length expansion indeed already takes p= lace.  So unless I'm missing something, the point actually is that with these the exact amount of length expansion= is implicit (and you can recover TLSPlaintext.length and thus determine ad= ditional_data by subtracting a constant from the ciphertext length).

Thus, this decision is not about padding per se, but specifically abou= t *variable* padding, which wouldn't work with the current spec.


[Joe] Yes, that would be more accurate - variable length padding added= as part of the encryption process. 

Bodo


--_000_F622B101CC844AF19D9591E1ABE8158Cciscocom_-- From nobody Mon Jul 21 11:14:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE991A0352 for ; Mon, 21 Jul 2014 11:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.332 X-Spam-Level: X-Spam-Status: No, score=0.332 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSza-2yMOqEw for ; Mon, 21 Jul 2014 11:14:16 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.93.126.19]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E6D1A033A for ; Mon, 21 Jul 2014 11:14:15 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 47248D2237EA6; Mon, 21 Jul 2014 13:14:14 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 303D2D222E4C8 for ; Mon, 21 Jul 2014 13:13:42 -0500 (CDT) Received: from [31.133.164.43] (port=54007 helo=dhcp-a42b.meeting.ietf.org) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X9I5l-0003ef-Iv for tls@ietf.org; Mon, 21 Jul 2014 13:13:41 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <2B94CF16-83C1-4315-BA94-C5671DCFEF62@ieca.com> Date: Mon, 21 Jul 2014 14:13:39 -0400 To: "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 31.133.164.43 X-Exim-ID: 1X9I5l-0003ef-Iv X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-a42b.meeting.ietf.org) [31.133.164.43]:54007 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/L-RZ7X8yNFspNBA17sO_2iK54QE Subject: [TLS] wg github repo X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 18:14:17 -0000 In addition to uploading WG slides to the usual place = (http://tools.ietf.org/agenda/90/) we=92ve also set up a github repo for = the wg. It is located here: https://github.com/tlswg There=92s a place for wg-materials: https://github.com/tlswg/wg-materials The TLS 1.3 specification can also be found there: https://github.com/tlswg/tls13-spec spt= From nobody Mon Jul 21 12:43:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9418A1A03A0 for ; Mon, 21 Jul 2014 12:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQ4SkLveytVl for ; Mon, 21 Jul 2014 12:43:34 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ED521A039B for ; Mon, 21 Jul 2014 12:43:34 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id p10so8150086wes.2 for ; Mon, 21 Jul 2014 12:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SluaK534DUKWujkF6UJ+omDNhLFmuI8S5rstp/6ms48=; b=bB+w7ZSpyhZlZTP0LbdNxLsLLdBAkssdLOR9n6D2VyfTRQtxkZk2rCvxBWEzV2jlYb VId4xd+LW7OTS3dhgXM/ALjDkihHvEL6ZfBM3DU0RPv7cB5PSzpw+hiruSx1fVVgM010 tOw9ReTht4JSI+pKfx6F3tQ1o6jB9kZG8r0Cil8iP+eFikJ3TizeJK4qYjXouwo8yHWw QlIyyvSAL4JlngX5mAjY88gWrIrNc+KQRl/FUWMZGyH43vP9IuqSdcuudve7GPQX499L BIlpFEV9LB97KuEXLWoq5tsyM+YfEhdzM2EAB5rwnyuvU99CoP0+1QH1UwqFi/qR2G1U VhUA== MIME-Version: 1.0 X-Received: by 10.194.185.238 with SMTP id ff14mr26625532wjc.9.1405971812289; Mon, 21 Jul 2014 12:43:32 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Mon, 21 Jul 2014 12:43:32 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Jul 2014 12:43:32 -0700 Message-ID: From: Martin Thomson To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GlODTXJSEm7DSwrJobZW0E5TmVc Cc: "tls@ietf.org" Subject: Re: [TLS] Non-TLS opportunistic encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 19:43:36 -0000 On 19 July 2014 09:28, Phillip Hallam-Baker wrote: > 1) TLS is a huge standard with a lot of details that have to be got > right. It takes a lot of time and effort to implement and a lot of > memory to run. Constrained devices are going to find it very hard to > do TLS > > 2) One consequence of (1) is that opportunistic TLS risks weakening > the https infrastructure rather than improving the http > infrastructure. That is not a win as far as I am concerned. I'm struggling with your premise. I don't think that either is really true. Yes, TLS is complex, but inventing a new protocol sounds like a cure that is worse than the disease. I don't know if you are aware, but there is this: http://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-00 From nobody Mon Jul 21 12:55:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EAF1A03FA for ; Mon, 21 Jul 2014 12:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsFtV37AOpbG for ; Mon, 21 Jul 2014 12:55:47 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01ED81A03F4 for ; Mon, 21 Jul 2014 12:55:46 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id w61so8147520wes.9 for ; Mon, 21 Jul 2014 12:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UrqPVb3agBvNpnEzv9iyDJFdZc5fINh3xbd13kdiiZ4=; b=y8foCGqX01rKn6HyuJnv+StNsctM/EEbSwUuY6b80hTqZypTCmWZ3wVi/16SuAfpYG BsMwhKDCeCLjPhbwya2UNZ9WAdLJ6qsUFwbHZkQJUzBxjalYn56fuqvfIW3c75dIRRaA M5rPY6HRmYBebszmRrzF1yK5tQ+5ABXM7UM4gnPvJQtbv6NeqQoZbWbRaLDs0zO6F/wa mP0nG91IZi4xl2dAU6BiXzl8oflOE2heUOBdq2tyjU/FQS9c0t49Zl7MWPqYE12bmKM+ 5got5WCJOmo5nasC5d19oIL3K++bwzdtvi4qayF/I7M7xFUOTpwP8L+DMHLCygAOnWJi jEDw== MIME-Version: 1.0 X-Received: by 10.194.185.238 with SMTP id ff14mr26719646wjc.9.1405972545041; Mon, 21 Jul 2014 12:55:45 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Mon, 21 Jul 2014 12:55:44 -0700 (PDT) In-Reply-To: <53CD4F3B.4090704@nthpermutation.com> References: <502C3758-9F12-4ABC-B595-FD0994A28B18@ieca.com> <53CD4F3B.4090704@nthpermutation.com> Date: Mon, 21 Jul 2014 12:55:44 -0700 Message-ID: From: Martin Thomson To: Michael StJohns Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CjTjJefDKYKjN-ZIrrfDF_F9JA4 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for adoption: draft-bhargavan-tls-session-hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 19:55:51 -0000 On 21 July 2014 10:34, Michael StJohns wrote: > How does this work with 1rtt? There is an open question here, because the 1RTT handshake doesn't allow for the master secret to cover the certificate. The way that the solution is formulated here (cover the server identity) isn't compatible with an encrypted certificate. We probably need some analysis here, but the idea that was floated what that covering the (EC)DH shares could be sufficient. I think that's a separable concern and we should consider this draft to be <= 1.2 only. We can choose to use this solution, if it is appropriate and can be adapted for 1.3. However, as I understand it, the current 1.3 structure doesn't allow this exact form for the fix. From nobody Mon Jul 21 14:01:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BD71A0452 for ; Mon, 21 Jul 2014 14:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-DrWPvDxDrl for ; Mon, 21 Jul 2014 14:01:33 -0700 (PDT) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0022B1A035E for ; Mon, 21 Jul 2014 14:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=6DKZ/DPT+CKaLnl/snKCVys1s20yi6+gVGdsEXfxYto=; b=W+pnPuGKjsTGi7nF7KnCdn+P9GINU3smKLbL/5j1AF93zUr7CZT2oqunZTyg7xbJGV3G8MSTjte/yRBF339qnhAjDlZnk38+2vnax2AT9n+GPpypiRvziFuITLSKt4+ii2q059HdCxHffsEfOhDSou+D79Y7LpJ2FQRaETfrll8=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1X9Kho-0002Lf-8M; Mon, 21 Jul 2014 23:01:08 +0200 Message-ID: <53CD7F86.8040707@polarssl.org> Date: Mon, 21 Jul 2014 23:00:54 +0200 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Russ Housley , "Joseph Salowey (jsalowey)" References: <3BA3F4D9-84FF-45ED-A1D3-F00C649019DC@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2JlRlkeooG4iNk9tc-Xi5HnKX_g Cc: "" Subject: Re: [TLS] Removing support for custom unnamed DIffie-Hellman groups X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 21:01:34 -0000 On 21/07/2014 16:51, Russ Housley wrote: > I think this means that only well-known groups will be used. I am assuming > that an IANA registry will be used to provide identifiers for these > well-known groups. If that is correct, then I fully support this direction. > +1 Manuel. From nobody Mon Jul 21 14:43:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429F01A08F8 for ; Mon, 21 Jul 2014 14:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OAnEK-J6_ux for ; Mon, 21 Jul 2014 14:43:12 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BA2D1A063C for ; Mon, 21 Jul 2014 14:43:12 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB420.namprd03.prod.outlook.com (10.141.92.25) with Microsoft SMTP Server (TLS) id 15.0.990.7; Mon, 21 Jul 2014 21:43:10 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.0990.007; Mon, 21 Jul 2014 21:43:11 +0000 From: Andrei Popov To: Martin Thomson , Michael StJohns Thread-Topic: [TLS] Call for adoption: draft-bhargavan-tls-session-hash Thread-Index: AQHPpPW3yLw3mw3Gjk+IMUj+Y+Di5ZuqyjuAgAAnXQCAAB0FgA== Date: Mon, 21 Jul 2014 21:43:10 +0000 Message-ID: References: <502C3758-9F12-4ABC-B595-FD0994A28B18@ieca.com> <53CD4F3B.4090704@nthpermutation.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [207.236.147.203] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0279B3DD0D x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(24454002)(13464003)(377454003)(51444003)(189002)(199002)(81342001)(81542001)(4396001)(19580405001)(19580395003)(83322001)(105586002)(106116001)(85306003)(80022001)(20776003)(64706001)(2656002)(66066001)(77982001)(101416001)(79102001)(87936001)(15975445006)(106356001)(85852003)(83072002)(21056001)(31966008)(107046002)(33646002)(86362001)(76576001)(76482001)(95666004)(86612001)(54356999)(74316001)(92566001)(46102001)(76176999)(74502001)(74662001)(50986999)(99396002)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB420; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SEscYQEeqgFSEzrvQzZ9UDXWPx4 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for adoption: draft-bhargavan-tls-session-hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 21:43:14 -0000 I agree with Martin on this, and also think more generally that TLS 1.3 sho= uld not rely on extensions to fix known problems such as triple handshake. = Since the issue is known at the time of TLS 1.3 design, IMHO the fix should= be an integral part of TLS 1.3. -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson Sent: Monday, July 21, 2014 3:56 PM To: Michael StJohns Cc: tls@ietf.org Subject: Re: [TLS] Call for adoption: draft-bhargavan-tls-session-hash On 21 July 2014 10:34, Michael StJohns wrote: > How does this work with 1rtt? There is an open question here, because the 1RTT handshake doesn't allow fo= r the master secret to cover the certificate. The way that the solution is= formulated here (cover the server identity) isn't compatible with an encry= pted certificate. We probably need some analysis here, but the idea that w= as floated what that covering the (EC)DH shares could be sufficient. I think that's a separable concern and we should consider this draft to be = <=3D 1.2 only. We can choose to use this solution, if it is appropriate an= d can be adapted for 1.3. However, as I understand it, the current 1.3 str= ucture doesn't allow this exact form for the fix. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jul 21 14:52:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71E61A006D for ; Mon, 21 Jul 2014 14:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id df-B8JqVoRgX for ; Mon, 21 Jul 2014 14:52:32 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33FE61A006B for ; Mon, 21 Jul 2014 14:52:32 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id j15so5906213qaq.29 for ; Mon, 21 Jul 2014 14:52:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jR0thCXvsWW1uety71chzG2KF+GyyrigCq0b5UdeeCI=; b=AHYHCRRG0hxG0/fUxAo1nVom28Wkve1zTwLjQdiPguBLWam13J40kayWWsklWBAjN0 Re812Zz14u4bn+2BzeoLQZUDEbdewIT91oHPH9lP2x4xEAwVGXcC92hJ7A8eUhkWMeE/ 2xb0pDgFgWrk4x1ewv94IwH8aTMFHgROx8o+bUWdGUMdKDuaqmPJvckWF3cEJLEnGdF5 vV2PWDvmmrkPWVlr7/WoHxLEipeat+cDVPM6kXesPXGHUPAy2MqRF4QLzNxcKmyFD/6p vn35xWzcS2YvKySZN+07ww3NIyYdGyee405zoJ2XNKzZfWiWbBaqhjcslmxSq4y4LlHh kDAw== X-Gm-Message-State: ALoCoQmRmqofKrQlZeplPUgjavh35AmCBIqfKtkFctUcBOilo/Y2cy47KdOPs6iW7QVF1bl5ZWfW X-Received: by 10.224.130.5 with SMTP id q5mr46763532qas.72.1405979551326; Mon, 21 Jul 2014 14:52:31 -0700 (PDT) Received: from [31.133.165.195] (dhcp-a5c3.meeting.ietf.org. [31.133.165.195]) by mx.google.com with ESMTPSA id k76sm17419373qgd.38.2014.07.21.14.52.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 14:52:30 -0700 (PDT) Message-ID: <53CD8B87.4030701@nthpermutation.com> Date: Mon, 21 Jul 2014 17:52:07 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Martin Thomson References: <502C3758-9F12-4ABC-B595-FD0994A28B18@ieca.com> <53CD4F3B.4090704@nthpermutation.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Jv6K4AifrTNFjqyPREP32dCpq64 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for adoption: draft-bhargavan-tls-session-hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 21:52:39 -0000 On 7/21/2014 3:55 PM, Martin Thomson wrote: > On 21 July 2014 10:34, Michael StJohns wrote: >> How does this work with 1rtt? > There is an open question here, because the 1RTT handshake doesn't > allow for the master secret to cover the certificate. The way that > the solution is formulated here (cover the server identity) isn't > compatible with an encrypted certificate. We probably need some > analysis here, but the idea that was floated what that covering the > (EC)DH shares could be sufficient. > > I think that's a separable concern and we should consider this draft > to be <= 1.2 only. We can choose to use this solution, if it is > appropriate and can be adapted for 1.3. However, as I understand it, > the current 1.3 structure doesn't allow this exact form for the fix. > > Ok - that makes a bit more sense. I've been overloading the queries by Sean/Joe for adoption as being solely fo TLS1.3. I don't have any great objections to adoption as a WG item as a 1.2 and before extension. I think it's got a good bit of work necessary before submission as an RFC though. Mike From nobody Mon Jul 21 16:09:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABED1A00D8 for ; Mon, 21 Jul 2014 16:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.132 X-Spam-Level: X-Spam-Status: No, score=-1.132 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W_WoD0jCOn6A for ; Mon, 21 Jul 2014 16:09:06 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB6B81A0024 for ; Mon, 21 Jul 2014 16:09:06 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB418.namprd03.prod.outlook.com (10.141.92.13) with Microsoft SMTP Server (TLS) id 15.0.990.7; Mon, 21 Jul 2014 23:09:04 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.0990.007; Mon, 21 Jul 2014 23:09:04 +0000 From: Andrei Popov To: Sean Turner , "TLS@ietf.org (tls@ietf.org)" Thread-Topic: [TLS] adopted: draft-popov-tls-prohibiting-rc4-02 Thread-Index: AQHPpPKlOf5pO7+e1U2aplPkGNYpPpurJwjA Date: Mon, 21 Jul 2014 23:09:03 +0000 Message-ID: References: <5A318D71-E491-490B-82D3-6D1BA3C60684@ieca.com> In-Reply-To: <5A318D71-E491-490B-82D3-6D1BA3C60684@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [207.236.147.203] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0279B3DD0D x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(13464003)(164054003)(377454003)(74316001)(95666004)(54356999)(4396001)(76576001)(74662001)(31966008)(74502001)(85306003)(15975445006)(105586002)(106116001)(106356001)(99286002)(99396002)(76482001)(76176999)(64706001)(50986999)(66066001)(107046002)(107886001)(33646002)(21056001)(46102001)(101416001)(19580405001)(92566001)(19580395003)(86612001)(15202345003)(79102001)(83322001)(80022001)(81342001)(2656002)(20776003)(85852003)(87936001)(83072002)(81542001)(77982001)(86362001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB418; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MGak_PIIQpOpyX230aB9hTKmEQg Subject: Re: [TLS] adopted: draft-popov-tls-prohibiting-rc4-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 23:09:08 -0000 Done. I've also updated Appendix A "RC4 Cipher Suites" with what I believe = is an exhaustive list of IANA-registered RC4 cipher suites. Thanks, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Sean Turner Sent: Monday, July 21, 2014 10:47 AM To: TLS@ietf.org (tls@ietf.org) Subject: [TLS] adopted: draft-popov-tls-prohibiting-rc4-02 At the TLS interim held on 20140720, there wg consensus was re-confirmed to= adopt draft-popov-tls-prohibiting-rc4-02 . This is consistent with the wg= adoption call (http://www.ietf.org/mail-archive/web/tls/current/msg11932.h= tml). Andrei, Please submit your individual draft as draft-ietf-tls-prohibiting-rc4-00. spt {for the chairs} _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jul 21 16:41:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90EAE1A028A for ; Mon, 21 Jul 2014 16:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyZpg9Kje8Zk for ; Mon, 21 Jul 2014 16:41:24 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAF161A0282 for ; Mon, 21 Jul 2014 16:41:24 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s6LNeSbU031680; Mon, 21 Jul 2014 16:41:23 -0700 Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0a-0016f401.pphosted.com with ESMTP id 1n8ud7k7dv-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 21 Jul 2014 16:41:23 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Mon, 21 Jul 2014 16:41:23 -0700 From: Paul Lambert To: Watson Ladd , Pascal Urien Date: Mon, 21 Jul 2014 16:41:17 -0700 Thread-Topic: [TLS] TLS 1.3 Application Identifier ? Thread-Index: Ac+iOPI4iF58g0r+S8+5Wj0XkPNBcQDA7aSA Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01EE45B1C3D@SC-VEXCH2.marvell.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-20_03:2014-07-18,2014-07-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407210273 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lt1lAfgdNxmaElwr3IFmQrJ2nag Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Application Identifier ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 21 Jul 2014 23:41:26 -0000 DQoNCl0tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KXUZyb206IFdhdHNvbiBMYWRkIFttYWls dG86d2F0c29uYmxhZGRAZ21haWwuY29tXQ0KXVNlbnQ6IFRodXJzZGF5LCBKdWx5IDE3LCAyMDE0 IDg6MzMgUE0NCl1UbzogUGFzY2FsIFVyaWVuDQpdQ2M6IFBhdWwgTGFtYmVydDsgdGxzQGlldGYu b3JnDQpdU3ViamVjdDogUmU6IFtUTFNdIFRMUyAxLjMgQXBwbGljYXRpb24gSWRlbnRpZmllciA/ DQpdDQpdV2hhdCBkbyB5b3UgbWVhbiBieSAiYXBwbGljYXRpb24gaWRlbnRpZmllciI/IElzIGh0 dHAgZW5vdWdoLCBvciBzaG91bGQNCl1pdCBiZSB0aGUgYXBwbGljYXRpb24gb24gdG9wIG9mIGh0 dHA/DQpdDQpdV2hhdCBkbyB5b3UgbmVlZCBpdCBmb3I/IFdoeSBkb2VzIGl0IG5lZWQgdG8gYmUg bWFuYWRhdG9yeTogd2h5IG5vdA0KXXJlcXVpcmUgY2xpZW50cyB0byB1c2UgQUxQTj8NCg0KQUxQ TiByZXF1aXJlcyBJQU5BIHJlZ2lzdHJhdGlvbiBvZiAnYXBwbGljYXRpb25zJyAobmVnYXRpdmUg ZnJvbSBteSBwZXJzcGVjdGl2ZSkNClJlZ2lzdHJhdGlvbiBhbHNvIGV4cG9zZXMgdGhlIGFwcGxp Y2F0aW9ucyBhbGxvd2luZyBzb21lIHNlcnZlcnMgdG8gYmUgZGlzY3JpbWluYXRlZA0KYWdhaW5z dCBiYXNlZCBvbiBhcHBsaWNhdGlvbnMgc2VydmVkLg0KDQoNClBhdWwNCg0KDQpdDQpdSWYgeW91 IHdhbnQgdG8gbGluayB0aGUgY2xpZW50IGNlcnQgdG8gYXBwbGljYXRpb24gKHdoYXQgZG9lcyB0 aGF0DQpdbWVhbj8pIHdoeSBjYW4ndCB0aGUgQ2hhbm5lbElEIGRyYWZ0IHNlcnZlIHlvdXIgcHVy cG9zZXM/DQpdDQpdT24gVGh1LCBKdWwgMTcsIDIwMTQgYXQgMzowOSBQTSwgUGFzY2FsIFVyaWVu IDxwYXNjYWwudXJpZW5AZ21haWwuY29tPg0KXXdyb3RlOg0KXT4gSGkgQWxsDQpdPg0KXT4gRmlu aXNoZWQgbWVzc2FnZXMgYXJlIGVuY3J5cHRlZC4gVGhhdCBhcmUgcHJvZHVjZWQgZmlyc3QgYnkg c2VydmVyIGFuZA0KXT4gc2Vjb25kIGJ5IGNsaWVudC4NCl0+DQpdPiBUaGUgdG9kYXkgc2VtYW50 aWMgKFRMUzEuMykgb2YgdGhlc2UgbWVzc2FnZXMgaXMgc2VydmVyIGZpbmlzaGVkIGFuZA0KXT4g Y2xpZW50IGZpbmlzaGVkIChhIGNyeXB0b2dyYXBoaWMgcHJvb2Ygb2YgdGhlIGtub3dsZWRnZSBv ZiBzZWNyZXRzKQ0KXT4NCl0+IFRoZXkgY291bGQgYmUgdXNlZCBhbHNvIHRvIHRyYW5zcG9ydCBw cm90ZWN0ZWQgYXBwbGljYXRpb24gaWRlbnRpZmllcnMNCl0+IGZvciBib3RoIHNlcnZlciBhbmQg Y2xpZW50ID8hDQpdPg0KXT4gUmVnYXJkcw0KXT4NCl0+IFBhc2NhbA0KXT4NCl0+DQpdPiAyMDE0 LTA3LTE3IDE4OjA1IEdNVCswMjowMCBQYXVsIExhbWJlcnQgPHBhdWxAbWFydmVsbC5jb20+Og0K XT4NCl0+Pg0KXT4+IEl0IG1heSBvciBtYXkgbm90IG1hcCB3ZWxsIGludG8gVExTLCBidXQgaW4g b3RoZXIgZm9ydW1zLCB3ZeKAmXJlIHVzaW5nDQpdPj4gYSA2IG9jdGV0IGlkZW50aWZpZXIgdG8g ZGVzY3JpYmUgc2VydmljZXMgKGFrYSBhcHBsaWNhdGlvbnMpLg0KXT4+IEl04oCZcyBmb3JtZWQg YXMgYSB0cnVuY2F0ZWQgaGFzaCBvZiBhIOKAnHNlcnZpY2UgbmFtZeKAnQ0KXT4+DQpdPj4gICAg ICAgIHNlcnZpY2VJZCA9IFNIQTI1Niggc2VydmljZU5hbWUgKVswOjZdDQpdPj4NCl0+PiBJdCBj YW4gYWxzbyBiZSBvYnNjdXJlZCBieSBjb25jYXRlbmF0aW5nIHRoZSBTZXJ2aWNlIE5hbWUgd2l0 aCBhIGtleQ0KXT4+IGJlZm9yZSBjcmVhdGluZyB0aGUgaWRlbnRpZmllci4NCl0+Pg0KXT4+IFBh dWwNCl0+Pg0KXT4+DQpdPj4gSGkgUGFzY2FsDQpdPj4gWW91IG1heSBoYXZlIGEgbG9vayBhdCB0 aGUgZm9sbG93aW5nIGRvY3VtZW50Og0KXT4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWJhZHJhLXRscy1tdWx0aXBsZXhpbmctMDENCl0+PiBPcg0KXT4+IGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWJhZHJhLWhhamplaC1tdGxzLTA2DQpdPj4NCl0+PiBCZXN0IHJl Z2FyZHMNCl0+PiBCYWRyYQ0KXT4+DQpdPj4NCl0+PiBPbiBXZWQsIEp1bCAxNiwgMjAxNCBhdCAx MjozMiBQTSwgUGFzY2FsIFVyaWVuDQpdPj4gPHBhc2NhbC51cmllbkBnbWFpbC5jb20+DQpdPj4g d3JvdGU6DQpdPj4+DQpdPj4+IEhpIEFsbA0KXT4+Pg0KXT4+PiBJdCBzZWVtcyB0aGVyZSBpcyBu byBpZGVudGlmaWVyIGZvciB0aGUgYXBwbGljYXRpb24gU0RVIHRyYW5zcG9ydGVkDQpdPj4+IGJ5 IFRMUyAxLjMgKHdoaWNoIGlzIG9idmlvdXNseSBhIHRyYW5zcG9ydCBwcm90b2NvbCkNCl0+Pj4N Cl0+Pj4gV2l0aCB0aGUgbGVnYWN5IFRMUywgdGhlIGFwcGxpY2F0aW9uIGlzIGlkZW50aWZpZWQg YnkgYSBUQ1Agb3IgVURQDQpdcG9ydC4NCl0+Pj4gU29tZSBUTFMgZXh0ZW5zaW9ucyBoYXZlIGJl ZW4gcHJvcG9zZWQgdG8gc29sdmUgdGhpcyBpc3N1ZS4NCl0+Pj4NCl0+Pj4gV2hhdCBhYm91dCBh ZGRpbmcgYSBtYW5kYXRvcnkgYXBwbGljYXRpb24gaWRlbnRpZmllciBpbiB0aGUgY2xpZW50DQpd Pj4+IGhlbGxvIG1lc3NhZ2U/Lg0KXT4+Pg0KXT4+PiBJdCBjb3VsZCBiZSBhIHR3byBieXRlcyBp bnRlZ2VyIChpLmUuIFRDUCBvciBVRFAgcG9ydCkgb3Igc29tZXRoaW5nDQpdPj4+IGVsc2Ugc3Vj aCBhcyBhbiBhcHBsaWNhdGlvbiBuYW1lDQpdPj4+DQpdPj4+IEEgbWFuZGF0b3J5IGFwcGxpY2F0 aW9uIGlkZW50aWZpZXIgaW4gdGhlIGNsaWVudCBoZWxsbyBtZXNzYWdlDQpdPj4+IGF2b2lkcyB0 ZW50YXRpdmUgY29ubmVjdGlvbnMgdG8gbm9uLWF2YWlsYWJsZSBhcHBsaWNhdGlvbnMuIEl0IGFs c28NCl0+Pj4gY291bGQgZXN0YWJsaXNoIGEgbG9naWNhbCBsaW5rIGJldHdlZW4gY2xpZW50IGNl cnRpZmljYXRlIGFuZA0KXT4+PiBhcHBsaWNhdGlvbnMNCl0+Pj4NCl0+Pj4gUmVnYXJkcw0KXT4+ Pg0KXT4+PiBQYXNjYWwgVXJpZW4NCl0+Pj4NCl0+Pj4NCl0+Pj4NCl0+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCl0+Pj4gVExTIG1haWxpbmcgbGlz dA0KXT4+PiBUTFNAaWV0Zi5vcmcNCl0+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90bHMNCl0+Pj4NCl0+Pg0KXT4+DQpdPj4NCl0+DQpdPg0KXT4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCl0+IFRMUyBtYWlsaW5nIGxpc3QN Cl0+IFRMU0BpZXRmLm9yZw0KXT4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90bHMNCl0+DQpdDQpdDQpdDQpdLS0NCl0iVGhvc2Ugd2hvIHdvdWxkIGdpdmUgdXAgRXNzZW50 aWFsIExpYmVydHkgdG8gcHVyY2hhc2UgYSBsaXR0bGUNCl1UZW1wb3JhcnkgU2FmZXR5IGRlc2Vy dmUgbmVpdGhlciAgTGliZXJ0eSBub3IgU2FmZXR5LiINCl0tLSBCZW5qYW1pbiBGcmFua2xpbg0K From nobody Tue Jul 22 03:40:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB081A0AB7 for ; Tue, 22 Jul 2014 03:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtN6ZQiNe0A0 for ; Tue, 22 Jul 2014 03:40:18 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25B61A05D1 for ; Tue, 22 Jul 2014 03:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1406025618; x=1437561618; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=IcsCmaWWOruvsmYVGsky+rFys8pSSSIIOXESBu5FHik=; b=WgsNDrEFEH3IqwzyXbua3chxs5x10/Fy+vyj58c3HUjt2akyve6SARAa g6yPYZAqg0DnYuc6AJS3Ubdc2kjWlhTynWQS/aZn0fbBZfsINEpbvp27d 1ZEp6MfnnbKfe2zTGxTZmO6stLm/XRkJY4als7WFBh7VDDWDA3SbiXE4I g=; X-IronPort-AV: E=Sophos;i="5.01,709,1399982400"; d="scan'208";a="265151160" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 22 Jul 2014 22:40:15 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.247]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 22:40:15 +1200 From: Peter Gutmann To: "tls@ietf.org" , "cfrg@irtf.org" Thread-Topic: [TLS] [Cfrg] Formal request from TLS WG to CFRG for new elliptic curves Thread-Index: Ac+lmVKBp1FFM2f1RJS1LzlOl6ghTQ== Date: Tue, 22 Jul 2014 10:40:15 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738EFAE9B3@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CmOf53BLbOQMwiySQaSbz5V2Jgc Subject: Re: [TLS] [Cfrg] Formal request from TLS WG to CFRG for new elliptic curves X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 22 Jul 2014 10:40:23 -0000 "Salz, Rich" writes:=0A= >> TLS 1.2 offered no compelling advantages.=0A= >=0A= >Yes. TLS 1.3 will offer some good reasons to adopt, from the simplicity,= =0A= >security, privacy, and efficiency areas. The comparison to TLS 1.2 doesn'= t=0A= >hold.=0A= =0A= TLS 1.3 will also offer a really strong reason to defer adoption for as lon= g=0A= as possible: Unlike the previous tweaks of SSL, which did lead to the=0A= frankensteinian implementation we have to deal with now but at least were= =0A= close to the original, TLS 1.3 is pretty much an entirely new protocol. I= =0A= have no idea what it'll end up looking like once the design committee has= =0A= finished adding every feature everyone's ever wanted in a protocol to it, b= ut=0A= it's most likely going to be TLS 2.0 even if it's called TLS 1.3. That mea= ns=0A= a completely new implementation from scratch rather than trying to add yet= =0A= another layer to what started long ago as an SSL implementation, and deploy= ing=0A= a new protocol up against SSL/TLS, even if it's sold as TLS-something, will= be=0A= a huge uphill battle. Look at how long TLS 1.2 adoption took, outside of w= eb=0A= browsers it's still very much the exception rather than the rule (and even = for=0A= web browsers there are some amazing calisthenics they perform in order to m= ake=0A= things work for non-TLS 1.2 servers and devices).=0A= =0A= Peter.= From nobody Tue Jul 22 05:17:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8061A0AD7; Tue, 22 Jul 2014 05:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qURkV7WOmMAS; Tue, 22 Jul 2014 05:17:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 962231A064A; Tue, 22 Jul 2014 05:17:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140722121755.11842.62697.idtracker@ietfa.amsl.com> Date: Tue, 22 Jul 2014 05:17:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZYtFzjxq-MupG9qEqsqOwXuo3G0 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-encrypt-then-mac-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 12:17:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Encrypt-then-MAC for TLS and DTLS Author : Peter Gutmann Filename : draft-ietf-tls-encrypt-then-mac-03.txt Pages : 7 Date : 2014-07-22 Abstract: This document describes a means of negotiating the use of the encrypt-then-MAC security mechanism in place of TLS'/DTLS' existing MAC-then-encrypt one, which has been the subject of a number of security vulnerabilities over a period of many years. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-encrypt-then-mac/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-encrypt-then-mac-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-encrypt-then-mac-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 22 06:34:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F801B27E8; Tue, 22 Jul 2014 06:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEMCPtfd6uAz; Tue, 22 Jul 2014 06:34:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A061B27C9; Tue, 22 Jul 2014 06:34:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140722133402.789.27686.idtracker@ietfa.amsl.com> Date: Tue, 22 Jul 2014 06:34:02 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/34WSISQMF7x3_CMnCe5sUW4hv30 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-prohibiting-rc4-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 13:34: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 Working Group of the IETF. Title : Prohibiting RC4 Cipher Suites Author : Andrei Popov Filename : draft-ietf-tls-prohibiting-rc4-00.txt Pages : 5 Date : 2014-07-21 Abstract: This document requires that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-prohibiting-rc4/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-prohibiting-rc4-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 22 15:12:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0081A0658; Tue, 22 Jul 2014 15:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZVpOk0h5JpY; Tue, 22 Jul 2014 15:12:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9C31A010C; Tue, 22 Jul 2014 15:12:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140722221245.32316.93225.idtracker@ietfa.amsl.com> Date: Tue, 22 Jul 2014 15:12:45 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ihh56Vyb7esTAa4-4PXJRTkpDQ0 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 22:12:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS Author : Daniel Kahn Gillmor Filename : draft-ietf-tls-negotiated-ff-dhe-00.txt Pages : 19 Date : 2014-07-22 Abstract: Traditional finite-field-based Diffie-Hellman (DH) key exchange during the TLS handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by establishing a registry of DH parameters with known structure and a mechanism for peers to indicate support for these groups. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 22 23:03:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253651A0011 for ; Tue, 22 Jul 2014 23:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcLxl6xUlCtX for ; Tue, 22 Jul 2014 23:03:43 -0700 (PDT) Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id A9ACE1A002B for ; Tue, 22 Jul 2014 23:03:41 -0700 (PDT) Received: (qmail 6408 invoked from network); 23 Jul 2014 06:03:42 -0000 Received: from unknown (HELO hyperelliptic.org) (131.155.71.33) by mace.cs.uic.edu with SMTP; 23 Jul 2014 06:03:42 -0000 Received: (qmail 13007 invoked by uid 1000); 23 Jul 2014 06:03:14 -0000 Date: Wed, 23 Jul 2014 08:03:14 +0200 From: Tanja Lange To: tls@ietf.org, cfrg@irtf.org Message-ID: <20140723060313.GU28481@cph.win.tue.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.11 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/57ZNXIo0wIYT2jqKtOZvSBqH-xU Cc: "D. J. Bernstein" Subject: [TLS] [djb@cr.yp.to: Re: New curve-selection paper] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 23 Jul 2014 06:03:44 -0000 There seems to be some issue with emails from DJB to ietf.org ----- Forwarded message from "D. J. Bernstein" ----- Subject: New curve-selection paper From: "D. J. Bernstein" Date: 23 Jul 2014 05:32:50 -0000 To: tls@ietf.org, cfrg@irtf.org Message-ID: <20140723053250.30025.qmail@cr.yp.to> "How to manipulate curve standards: a white paper for the black hat" Authors (alphabetical order): Bernstein, Chou, Chuengsatiansup, Hülsing, Lange, Niederhagen, van Vredendaal http://safecurves.cr.yp.to/bada55/bada55-20140722.pdf ---Dan ----- End forwarded message ----- From nobody Wed Jul 23 10:55:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80B31B2A22; Wed, 23 Jul 2014 10:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h16fw0oysHy4; Wed, 23 Jul 2014 10:55:13 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A76A71B2B0F; Wed, 23 Jul 2014 10:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1331; q=dns/txt; s=iport; t=1406138100; x=1407347700; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/dLFWfN95CJ6yKnv/vBf0sETzZoyiZ0OduS04zlmCM0=; b=MNWM5RaH0vS/YLsP1cwaTWxg2+o/GAuBYlGxynIAQD6wCfgsGBN3F1wW DovEaNItcuP3h61au/IkBVlAvo06wdb73pdH1hwvBqa4i1KzQWAmGesT9 tB2s/TD0cLHZWLQowFXHaXi0Qx4nuafDaEPzHRip+C5o5klePoC3OdAAb 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FANr1z1OtJA2B/2dsb2JhbABZgw6BLc8qAYELFnaEBAEBBHkQAgFOMiUCBA6IR8AxF49LB4MugRgBBJstlECDSIIx X-IronPort-AV: E=Sophos;i="5.01,718,1400025600"; d="scan'208";a="342268064" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-2.cisco.com with ESMTP; 23 Jul 2014 17:54:59 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6NHsvqF022898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 17:54:59 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 12:54:56 -0500 From: "Cullen Jennings (fluffy)" To: Marc Petit-Huguenin Thread-Topic: draft-petithuguenin-avtcore-rfc5764-mux-fixes-00 Thread-Index: AQHPpp82fjgNGTILOE6Hla7Sj7WHsg== Date: Wed, 23 Jul 2014 17:54:56 +0000 Message-ID: References: <53B3F0D9.2010107@getjive.com> In-Reply-To: <53B3F0D9.2010107@getjive.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.91.147] Content-Type: text/plain; charset="Windows-1252" Content-ID: <19C0B5070E4F854BA66EBA021DF681AA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3JRCeYQxTllmpHD8feDJhPY5Yu0 Cc: "tram@ietf.org" , "avt@ietf.org" , "tls@ietf.org" Subject: [TLS] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 17:55:15 -0000 Thank you for doing this - I=92ve wanted to have this fixed for a long time= .=20 I think this is good but some recommendations I would make. We should make a new IANA registry that keeps track of for each value of th= e first byte, which protocol it is allocated to. I would suggest that it re= quire "Standards Action=94 to allocate a new code point to a protocol but o= f course one allocated to that protocol, the protocol would manager it with= in it=92s existing IANA registry for that protocol with that protocols exis= ting rules.=20 The advantage of this is we can allocate the points as needed instead of gu= essing if TLS or STUN or some new protocol will need a given number points= . There is no implementation problem for the demux because things that use = the new code points would know how to demux them.=20 I think that STUN and TURN should use up the minimal number of code points = in the registry that they easily can. Later, if they need more code points,= they can co back registry to get more.=20 I would suggest that 256 channels would be enough for TURN. If a given TURN= client needs more than that, it just needs to allocate a second local UDP = port. So TURN probably needs 1 code point for now.=20 It would be good to allocate one code point for experimental use. From nobody Wed Jul 23 12:44:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5641B2CBE; Wed, 23 Jul 2014 12:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.952 X-Spam-Level: X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euaakBhbyUFw; Wed, 23 Jul 2014 12:44:45 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id B34041A014F; Wed, 23 Jul 2014 12:44:44 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s6NJidZW008268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jul 2014 21:44:39 +0200 (MEST) In-Reply-To: To: "Cullen Jennings (fluffy)" Date: Wed, 23 Jul 2014 21:44:38 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140723194438.EC4C71ADB9@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NSlqWwn77qkMTQtFoH-wyqSXxWs Cc: "tls@ietf.org" , "tram@ietf.org" , "avt@ietf.org" Subject: Re: [TLS] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 19:44:47 -0000 Cullen Jennings (fluffy) wrote: > > We should make a new IANA registry that keeps track of for each value > of the first byte, which protocol it is allocated to. I would suggest > that it require "Standards Action? to allocate a new code point to a > protocol but of course one allocated to that protocol, the protocol > would manager it within it?s existing IANA registry for that protocol > with that protocols existing rules. > > The advantage of this is we can allocate the points as needed instead > of guessing if TLS or STUN or some new protocol will need a given > number points. There is no implementation problem for the demux because > things that use the new code points would know how to demux them. I'm slightly confused. Is that first byte in Figure 3: http://tools.ietf.org/html/draft-petithuguenin-avtcore-rfc5764-mux-fixes-00#page-6 +----------------+ | 127 < B < 192 -+--> forward to RTP | | packet --> | 19 < B < 64 -+--> forward to DTLS | | | B < 2 -+--> forward to STUN +----------------+ Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. Here the field B denotes the leading byte of the packet. the actual "ContentType" byte of the (D)TLS record protocol, which happens to currently be visible on the outside of the (D)TLS record protocol with a fairly small set of values: enum { change_cipher_spec(20), alert(21), handshake(22), application_data(23), (255) } ContentType; There has been a proposal to hide the ContentType for TLSv1.3 and break lots of existing software that relies on being able to parse TLS records: https://www.ietf.org/mail-archive/web/tls/current/msg13055.html Will rfc5764 have to be added to the list of things that would break by such a (needless) TLSv1.3 change? -Martin From nobody Wed Jul 23 13:42:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5711A03A8; Wed, 23 Jul 2014 13:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98L-7cN6AJ2B; Wed, 23 Jul 2014 13:41:58 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 246DD1A03EE; Wed, 23 Jul 2014 13:41:57 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ho1so8490869wib.14 for ; Wed, 23 Jul 2014 13:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jbFuvbN/XJnlOKHIZEISbyutR28UKBfKE79MmEmCiWc=; b=xd4H+pL74EAODP5cKE37OuE0G9mjAzbpDWe0NIiQWqHAAHzWxuSAFJrb98WxFzAJkn j4m9tHU++HZR/Ek9QonmXQQ+PsN35xxuWUfq6X29YBc0HYUp3TY6pttlybHbQsBuWJ0y yxLSKuLHg1RNR0+FFn1ttkPwXPPy8ySrzlOkT/EMYtItyXKid0WRZYYPmdVzMz+7MedF h9AfouR+jP3cInn1+Ei8hWHzZirUvMturD45Rl9gOA7OyCKYcPTEQgYgtKD2tcKXzLOl QS5ZldzYqBTzNQ2qZyHUPnDFi4JmKF3cLqbHsFigGox4dFpUvRsOggwKh8KMN4o7sOhW aUdg== MIME-Version: 1.0 X-Received: by 10.194.185.238 with SMTP id ff14mr5462277wjc.9.1406148116089; Wed, 23 Jul 2014 13:41:56 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Wed, 23 Jul 2014 13:41:56 -0700 (PDT) In-Reply-To: <20140723194438.EC4C71ADB9@ld9781.wdf.sap.corp> References: <20140723194438.EC4C71ADB9@ld9781.wdf.sap.corp> Date: Wed, 23 Jul 2014 13:41:56 -0700 Message-ID: From: Martin Thomson To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LqikwrtJXPRRONgUb8mQIYIrAU4 Cc: "Cullen Jennings \(fluffy\)" , "tls@ietf.org" , "avt@ietf.org" , "tram@ietf.org" Subject: Re: [TLS] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:42:01 -0000 On 23 July 2014 12:44, Martin Rex wrote: > There has been a proposal to hide the ContentType for TLSv1.3 > and break lots of existing software that relies on being able > to parse TLS records: We discussed fixing that at the interim meeting where that proposal was discussed. The fix is trivial; we could, for instance, always send 23. Or, we could use Fluffy's proposed new registry to obtain a different demux byte value. I suspect that the former is fine. From nobody Wed Jul 23 14:25:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678711A0AF2 for ; Wed, 23 Jul 2014 14:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fukukfUQSYxO for ; Wed, 23 Jul 2014 14:25:20 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9FC41A0AEC for ; Wed, 23 Jul 2014 14:25:19 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id x48so1851264wes.33 for ; Wed, 23 Jul 2014 14:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HcgMY2KZ9BlHjhkk3OWFa4mAtFDVQuwRoCcDSvqjPKk=; b=VmufvTd7rlg6F4FrXEM2V76q14AZDEpWvt0hBg1z0wDZ43EtPvtN2e/AMj07r3jnAK lqN/A1ViFdGRCQsoy6qykq+LCFF5HdJiOzrmWi6HGHeNkYDA2dMUbYDbTVkL4+LYmEhq GqUz4Ut5PBzEquw78Vc9qsLwFwjbjnRUKEmsXEMawTyWnxRsMpKwMyqDG9DdDSpiaEmU gndkelzAMk4nGqns87UJEn/FZ1co5m1rm/yr0JlZb6ZPWuPTbLSF2O8ocIIEEJs95khV 40fkuARuIRRRUgWBQKHguQ0U3O3LTyHL/P/ACa9LldD9vgI9igBDZv4yq2Ip6JnotAJW O4CA== X-Received: by 10.194.80.7 with SMTP id n7mr5876379wjx.8.1406150718348; Wed, 23 Jul 2014 14:25:18 -0700 (PDT) Received: from wireless-v6.meeting.ietf.org ([2001:67c:370:160:98aa:ef28:d4ce:23b0]) by mx.google.com with ESMTPSA id p3sm9556273wjw.13.2014.07.23.14.25.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 14:25:17 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: Date: Wed, 23 Jul 2014 17:25:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5D265DE8-7157-40C9-933F-DF229D26769F@gmail.com> References: <20140723194438.EC4C71ADB9@ld9781.wdf.sap.corp> To: Martin Thomson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PIDnab3cpK17JkjGvzWrACnsYSI Cc: "tls@ietf.org" Subject: Re: [TLS] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 21:25:21 -0000 On Jul 23, 2014, at 4:41 PM, Martin Thomson = wrote: > On 23 July 2014 12:44, Martin Rex wrote: >> There has been a proposal to hide the ContentType for TLSv1.3 >> and break lots of existing software that relies on being able >> to parse TLS records: >=20 > We discussed fixing that at the interim meeting where that proposal > was discussed. The fix is trivial; we could, for instance, always > send 23. Or, we could use Fluffy's proposed new registry to obtain a > different demux byte value. I suspect that the former is fine. We also talked about padding to hinder traffic analysis. I think we can = solve both at the same time by doing something like this (sorry for not = using TLS curly bracket notation): Record header remains the same, except the contentType 23 gets renamed = to =93encrypted=94. When decrypted, the encrypted record has a three-byte header: 1 byte - ContentType. Either 23 means =93application data=94 here, or = we use a new number for it. something else for alert, etc. Zero can be = used for a special, all-padding record that can be discarded. 2 bytes - length. The difference between the decrypted length and this = field is the padding. If we limit ourselves to only 4 types of encrypted record (app data, = alert, padding and some yet unspecified fourth type - handshake?) we can = use a 2-byte header and use the two free bits from the TLS record = length. Yoav From nobody Thu Jul 24 07:54:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9B91A03D6 for ; Thu, 24 Jul 2014 07:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcH7-0WmH1lv for ; Thu, 24 Jul 2014 07:53:52 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28ACE1A03C2 for ; Thu, 24 Jul 2014 07:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1406213632; x=1437749632; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=M8iyxcjjZItqyG7cgq8m6s5n/21KNJ0odB1GGxW3hT0=; b=fw5gMAaB6JRSBwou5vjXNoWxZKcYm6e4T0FCgrXP8rR3kQAw8msqre3s keDEef+LSXeR6Rc+Nf5JwLwv9to24zcwSdRRUBhdSwJN0S3rvJgbxET2T oPUv1VC32m4huvT9XQZrtDz9fxrvQej1XJX6ZGP2dGjdfUetyqnEORR3A k=; X-IronPort-AV: E=Sophos;i="5.01,724,1399982400"; d="scan'208";a="265551589" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 25 Jul 2014 02:53:47 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.247]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Fri, 25 Jul 2014 02:53:46 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.txt Thread-Index: Ac+nTxIDPv2cUlFtTNOADpXqJ0CiGQ== Date: Thu, 24 Jul 2014 14:53:46 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738EFB003E@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/n8zyEyO7YMRSQktu3I6ONEVGV2E Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 14:53:59 -0000 writes:=0A= =0A= > Traditional finite-field-based Diffie-Hellman (DH) key exchange=0A= > during the TLS handshake suffers from a number of security,=0A= > interoperability, and efficiency shortcomings. These shortcomings=0A= > arise from lack of clarity about which DH group parameters TLS=0A= > servers should offer and clients should accept. This document offers= =0A= > a solution to these shortcomings for compatible peers by establishing= =0A= > a registry of DH parameters with known structure and a mechanism for=0A= > peers to indicate support for these groups.=0A= =0A= Some comments:=0A= =0A= - Why not just use the well-known and -accepted IKE groups from RFC 3526 fo= r=0A= this? In fact why invent entirely new groups (that don't even cover the=0A= existing range in RFC 3526) when there's already well-established ones=0A= available?=0A= =0A= - What's the thinking behind a 2432-bit group? 2048-bit I could understand= ,=0A= 2560 bits perhaps, but 2432?=0A= =0A= - Publishing the values of q (rather than just telling people how to calcul= ate=0A= them) would be good, since it'd provide known-correct values for them.=0A= =0A= In general though, we don't need yet another set of parameters, all that's= =0A= needed is a mechanism for specifying the existing RFC 3526 groups.=0A= =0A= Peter.= From nobody Thu Jul 24 11:01:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61F71A03C4 for ; Thu, 24 Jul 2014 11:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2Q_nIxlsQij for ; Thu, 24 Jul 2014 11:00:58 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A90DD1A019C for ; Thu, 24 Jul 2014 11:00:57 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id k48so3171678wev.40 for ; Thu, 24 Jul 2014 11:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vz/ldi/56oD/eUG1989xzoWMR5ZXoW078TYB++Fkx1A=; b=bLn0QKBVkhQfYCiPHoHC+Az/7ALeuMyLK0SV7TA+VgS0B6oKkKl1d0j3TIjSQzB6aR 7cIcWouWc1Q+G09NfSuJ36dMZ4YyPWb6skVtyICrwVz8y+a+lbBNoetQF9PD6oy3ygn4 XVc9YnxwcNjbsGkH9ChYdlVckKLFEQA88kv5thWKgKGQXmojcPVfJu/JG1Q8fF5dN/rU 7z4n8ABkEvwsYdbSu8NVLyzTsZGbAcvLwo1h9zFqFicXkdSZ18jNUfp/WNIS44ncpGcg zESp0YFcSWMC0cJ1wR3pmN5eMTR06PG7aECvHw2P/XTYUrNdco43RYd6+mhA4ppzC955 JYzQ== X-Received: by 10.180.218.12 with SMTP id pc12mr37697403wic.15.1406224856255; Thu, 24 Jul 2014 11:00:56 -0700 (PDT) Received: from wireless-v6.meeting.ietf.org ([2001:67c:370:160:98a4:b998:3a17:1e6f]) by mx.google.com with ESMTPSA id h13sm17810579wjs.2.2014.07.24.11.00.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 11:00:55 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738EFB003E@uxcn10-5.UoA.auckland.ac.nz> Date: Thu, 24 Jul 2014 14:00:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A043F3CF02CD34C8E74AC1594475C738EFB003E@uxcn10-5.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/x3Z48v6VsCjaKFESBYFgh72y5so Cc: "" Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:01:00 -0000 On Jul 24, 2014, at 10:53 AM, Peter Gutmann = wrote: > writes: >=20 >> Traditional finite-field-based Diffie-Hellman (DH) key exchange >> during the TLS handshake suffers from a number of security, >> interoperability, and efficiency shortcomings. These shortcomings >> arise from lack of clarity about which DH group parameters TLS >> servers should offer and clients should accept. This document = offers >> a solution to these shortcomings for compatible peers by = establishing >> a registry of DH parameters with known structure and a mechanism for >> peers to indicate support for these groups. >=20 > Some comments: >=20 > - Why not just use the well-known and -accepted IKE groups from RFC = 3526 for > this? In fact why invent entirely new groups (that don't even cover = the > existing range in RFC 3526) when there's already well-established ones > available? That=92s been asked at the meeting. No particular answer. > - What's the thinking behind a 2432-bit group? 2048-bit I could = understand, > 2560 bits perhaps, but 2432? I asked that at the meeting. The answer is that this number supposedly = exactly matches the 112-bit level of security.=20 > - Publishing the values of q (rather than just telling people how to = calculate > them) would be good, since it'd provide known-correct values for them. >=20 > In general though, we don't need yet another set of parameters, all = that's > needed is a mechanism for specifying the existing RFC 3526 groups. And that=92s assuming we even want FFC parameters (as opposed to ECC). Yoav From nobody Thu Jul 24 11:21:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05511B27B5 for ; Thu, 24 Jul 2014 11:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WutKIqYIjOWk for ; Thu, 24 Jul 2014 11:21:02 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557351B2797 for ; Thu, 24 Jul 2014 11:21:02 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id x48so3183029wes.17 for ; Thu, 24 Jul 2014 11:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=I8jjl8VIdY34+T9M1ewnSHsR5Zt7nDnAoAw6fl2NyW0=; b=ayZ1+6enROQrAbCChpzFkZVAxNP9yW51wOUFt1CajpANCoRgeQM4be+6vpgLrl0zOn ujazxgviR8zNSpDxvqw+FX9l1JkfvQspzFte0TnCnsLCQ6o3d84pNmsMfqxKdSrIIkV7 pX+7QnugXpQgNhySJq6phavm8VWHFgg6EdoICL7TFAp5ulWVfHDSGFm4Ep94rx/B+Pf1 C1QR1suOnhAlTQJF+eqEoPVwYjQT6EMIn+Km3e0d+P2cL7SF9KOEjeZZUWg+XYJ93ymb fv7Iwm6bTxpusaH+qTmrBdVti8+nGQQosZoPgmLMbDzihCIAfV5EMTU2BtvlVhqXXIbp 9ncg== MIME-Version: 1.0 X-Received: by 10.194.185.238 with SMTP id ff14mr14911811wjc.9.1406226060920; Thu, 24 Jul 2014 11:21:00 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Thu, 24 Jul 2014 11:21:00 -0700 (PDT) Date: Thu, 24 Jul 2014 11:21:00 -0700 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vfIPeAzLOBqIVWvXxLDVpm8bC5k Subject: [TLS] shibboleth and the nonce X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jul 2014 18:21:04 -0000 (No, that's not a proposed prog-synth-death-polka band name.) The arguments around the way that explicit/implicit nonces interact with certification were, I thought, already exhausted. So I'd like to see if some points can be clarified: As far as I am aware, there are no concrete concerns about implicit nonces from a straight-up security perspective. Is that right? If the concerns are solely around the certification of crypto modules, then we need more information to be able to make a rational decision here. If the static inputs are keys, and the per-record inputs are nonce + ad + plaintext, I see no problem. The previous response to suggestions that the nonce was a required input was to have a counter produce the nonce input, with a matching counter and validation in the module. The new information yesterday was that David McGrew suggested that the nonce needed to be arbitrary. In that case, do we actually need the input to be validated? Does the certification process check that the module produces different output for different nonces by starting separate module instances with the same values for all other inputs (keys, ad, and plaintext) then varying the input nonces? I'm sure that there are other concerns, but it's hard for me to make an assessment based on the information made available thus far. From nobody Thu Jul 24 12:05:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA041A0A98 for ; Thu, 24 Jul 2014 12:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKCdprrWdZ6K for ; Thu, 24 Jul 2014 12:05:06 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 458D81A0B15 for ; Thu, 24 Jul 2014 12:05:05 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id c11so2649584lbj.33 for ; Thu, 24 Jul 2014 12:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cLxn2YVoDzrkuw1BuiQby0Bt/OBchWhS2qzh8NWkgwE=; b=cqs1hUZIR/EBZyKrEm7Pfne/T1FxQlZ23yG7oUPY82J1Q5HmOrzt0Ihe1Y/riHUmU9 HvWTUsT2XwjPu/9dCOqMoCJxMpQK8cAvs6iw5PGMh6FDiEjrXXq8w1YuauKlwG9dk6yJ wzaFwNaaXPS0QNPp9SlijdAqYoetqeQMrtig1XaeifSpUGua33rxgbfih4h5vbUXCWTq SrKIgElWUQh586JSkgFaQ7W/NeohuVan8XjmXkFIgEYLaK8Fj7eDJ6si8Out7l38NYn8 6r6Q7RKhHgdPVUdPeU/NlM6CTYcCg387eejz5mbj6cx0VrIbm/c0fF8r0Yi+QuXRgaYa a15g== MIME-Version: 1.0 X-Received: by 10.152.3.65 with SMTP id a1mr11780340laa.76.1406228703573; Thu, 24 Jul 2014 12:05:03 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.170.37 with HTTP; Thu, 24 Jul 2014 12:05:03 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Jul 2014 12:05:03 -0700 X-Google-Sender-Auth: bTDCT9JUDMx1RzlXBsOkoNVBDVg Message-ID: From: Adam Langley To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/S2AXwDDh9sqOfGI5FoI3iTRyT28 Cc: "tls@ietf.org" Subject: Re: [TLS] shibboleth and the nonce X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jul 2014 19:05:07 -0000 On Thu, Jul 24, 2014 at 11:21 AM, Martin Thomson wrote: > As far as I am aware, there are no concrete concerns about implicit > nonces from a straight-up security perspective. Is that right? For polynomial MACs, no. (For CBC mode, yes.) > The previous response to suggestions that the nonce was a required > input was to have a counter produce the nonce input, with a matching > counter and validation in the module. > > The new information yesterday was that David McGrew suggested that the > nonce needed to be arbitrary. In that case, do we actually need the > input to be validated? Does the certification process check that the > module produces different output for different nonces by starting > separate module instances with the same values for all other inputs > (keys, ad, and plaintext) then varying the input nonces? > > I'm sure that there are other concerns, but it's hard for me to make > an assessment based on the information made available thus far. I'm not sure that I understand David McGrew's reported suggestion here. I thought that the concern was that the "crypto module" (being the thing that is validated) needs to ensure that nonces don't repeat because the security of the system should be a property of the crypto module alone. In that case, the module can either generate random nonces itself, or it can use a counter. In either case, the nonce isn't an input to the module when encrypting. If it were then, in order to establish uniqueness, the module would need to remember a list of all previous nonces. With AES-GCM, the nonces are explicit which allows the crypto module to generate them itself and report them to the TLS layer for transmission. With implicit nonces, the crypto module can use a counter and the counter keeps in sync with the TLS sequence number. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Thu Jul 24 13:45:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82411B28E7 for ; Thu, 24 Jul 2014 13:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmYU7piVtZNj for ; Thu, 24 Jul 2014 13:45:37 -0700 (PDT) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E26A71B28E8 for ; Thu, 24 Jul 2014 13:45:36 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id rd18so2847119iec.28 for ; Thu, 24 Jul 2014 13:45:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:message-id:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QrIS4t7/NegDf40QkTYZToYtLXLq7c7xhZoQIEnat0c=; b=eiU9wt+32B/nA3yjKQZRrsTM3T0MJDu1FiIhi9kKYurbu40B12OqBRcFc/H/dGUzZ+ MnC3fIZQKfB3XbVz7KCUmyX7tk3Q7EOq3/x/wa7l2jY4EfeiVJywed0ILVIiewm28v7+ dGbVzW/u9pkIgJGXCCxfLbIxH0yeQlc3cbAJRP+vqP3WpuTxCuVk08PD0PbWLoBh/CXI VcYi+kkakGo5HSRVKqPy5tVBcFlHkzOZZtLKoY1c7mpY+TcumncRvXq+q7xB8ntLVFdU mxQRMrCYHkO8XAUh2qbsRF+bZ9hg+bWMsm308C3fCa2k2jS91b1Zz4sn6+PNL5gqrmFZ j+Dw== X-Gm-Message-State: ALoCoQn4CaYQC0yeFkz4MDOLKiT5yKN5AcvPzcaXOM/LgTiun+7rwLkwwWfwWvAEs0GvtAipMF7O X-Received: by 10.50.110.103 with SMTP id hz7mr18692367igb.10.1406234736146; Thu, 24 Jul 2014 13:45:36 -0700 (PDT) Received: from [31.133.163.98] (dhcp-a362.meeting.ietf.org. [31.133.163.98]) by mx.google.com with ESMTPSA id il3sm26620536igb.1.2014.07.24.13.45.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 13:45:35 -0700 (PDT) Sender: Andrey Message-ID: <53D17069.9060501@brainhub.org> Date: Thu, 24 Jul 2014 16:45:29 -0400 From: Andrey Jivsov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C738EFB003E@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WuJhW7zcmmDEQHCNzXQcLZFeZuQ Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 20:45:38 -0000 On 7/24/2014 2:00 PM, Yoav Nir wrote: > On Jul 24, 2014, at 10:53 AM, Peter Gutmann wrote: > >> writes: >> >>> Traditional finite-field-based Diffie-Hellman (DH) key exchange >>> during the TLS handshake suffers from a number of security, >>> interoperability, and efficiency shortcomings. These shortcomings >>> arise from lack of clarity about which DH group parameters TLS >>> servers should offer and clients should accept. This document offers >>> a solution to these shortcomings for compatible peers by establishing >>> a registry of DH parameters with known structure and a mechanism for >>> peers to indicate support for these groups. >> Some comments: >> >> - Why not just use the well-known and -accepted IKE groups from RFC 3526 for >> this? In fact why invent entirely new groups (that don't even cover the >> existing range in RFC 3526) when there's already well-established ones >> available? > That’s been asked at the meeting. No particular answer. Pros: * a resourceful attacker will not be able to look for collisions within a single database of (key, key*G). He needs two, for IKE and TLS. * this adds one bit of security Cons: * It adds only one bit of security * an implementation that shares code between IKE and TLS will need to store an additional hardcoded prime. Most people will not have strong preferences here, I assume. >> - What's the thinking behind a 2432-bit group? 2048-bit I could understand, >> 2560 bits perhaps, but 2432? > I asked that at the meeting. The answer is that this number supposedly exactly matches the 112-bit level of security. IMO this comes down to alignment with other standards and practice. If 2048 RSA is being paired with dldhe2432, this would waste ~400 bits. More generally, deviating from 2048, 3072, 4096, etc will result in a similar waste of resources and add to uncertainty on how to match security. Second, the map between the bit security and modp size has been a dynamic quantity over the years. There bring another benefit to stick with a round number: longer shelf life of the document. >> - Publishing the values of q (rather than just telling people how to calculate >> them) would be good, since it'd provide known-correct values for them. >> >> In general though, we don't need yet another set of parameters, all that's >> needed is a mechanism for specifying the existing RFC 3526 groups. > And that’s assuming we even want FFC parameters (as opposed to ECC). There is a benefit for TLS 1.2 and earlier versions. It should be at least MAY in 1.3 to assure smooth transition. ( Although this only matters for reused KE parts, we get an exceptionally cheap validation that that the peer's part belongs to a large subgroup, almost for free. ) From nobody Thu Jul 24 14:13:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB501A035D for ; Thu, 24 Jul 2014 14:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyPA0KNr45CX for ; Thu, 24 Jul 2014 14:13:08 -0700 (PDT) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5283D1A0146 for ; Thu, 24 Jul 2014 14:13:08 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id ey11so4706528pad.38 for ; Thu, 24 Jul 2014 14:13:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KaxPNcDdxPR/g77ihirqOwX5QD1YhP37e5lpPpi4Vpk=; b=aIrOezNVudeL+U8ONvxdAzSmIB+Jx21F9G3sf5esDZ9BzW/794tADCXsqNR/2smET5 6bq4kPxSmzprZT3dSaFWWJ+s/QNxqtx6qL2s5v/1cwuSPxkqawXhguwLmR6YbueVl12y TCkqAyWN0b4/dChHlIMkzqXEtSJL+e67JI5NLvVJmTAMegyUhSUluFzkA8QjA2KMTQsm MaKejylJeIgpUEoDbWuoHPP1CehequcChuvq1+B/uXYfD7O+f+0SslNUXpJL+B4rUFP8 0XbDgs8ChHqrvWG/VkG9PGZKWEYY9x74urWRuyyc5LEVVSV1lWcyhN+55/nyd8UNMsd3 aHnw== X-Gm-Message-State: ALoCoQk4nAkGNdFLBQl0lT3cRn/vDh2t1zSC9UsrGtFq2znvE8CxIr9YoRRoAxY9YKKgw/b0RB0W X-Received: by 10.70.42.38 with SMTP id k6mr13932842pdl.120.1406236387724; Thu, 24 Jul 2014 14:13:07 -0700 (PDT) Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id be7sm8733282pdb.37.2014.07.24.14.13.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 14:13:06 -0700 (PDT) Message-ID: <53D176E0.7060002@amacapital.net> Date: Thu, 24 Jul 2014 14:13:04 -0700 From: Andy Lutomirski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Adam Langley , Martin Thomson References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/G6YYBhkKt06a2SOdZtZsKRhFB5Y Cc: "tls@ietf.org" Subject: Re: [TLS] shibboleth and the nonce X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jul 2014 21:13:09 -0000 On 07/24/2014 12:05 PM, Adam Langley wrote: > On Thu, Jul 24, 2014 at 11:21 AM, Martin Thomson > wrote: >> As far as I am aware, there are no concrete concerns about implicit >> nonces from a straight-up security perspective. Is that right? > > For polynomial MACs, no. (For CBC mode, yes.) > >> The previous response to suggestions that the nonce was a required >> input was to have a counter produce the nonce input, with a matching >> counter and validation in the module. >> >> The new information yesterday was that David McGrew suggested that the >> nonce needed to be arbitrary. In that case, do we actually need the >> input to be validated? Does the certification process check that the >> module produces different output for different nonces by starting >> separate module instances with the same values for all other inputs >> (keys, ad, and plaintext) then varying the input nonces? >> >> I'm sure that there are other concerns, but it's hard for me to make >> an assessment based on the information made available thus far. > > I'm not sure that I understand David McGrew's reported suggestion here. > > I thought that the concern was that the "crypto module" (being the > thing that is validated) needs to ensure that nonces don't repeat > because the security of the system should be a property of the crypto > module alone. > > In that case, the module can either generate random nonces itself, or > it can use a counter. In either case, the nonce isn't an input to the > module when encrypting. If it were then, in order to establish > uniqueness, the module would need to remember a list of all previous > nonces. > > With AES-GCM, the nonces are explicit which allows the crypto module > to generate them itself and report them to the TLS layer for > transmission. With implicit nonces, the crypto module can use a > counter and the counter keeps in sync with the TLS sequence number. Would it be practical for the crypto module to have an interface "encrypt this payload; choose your own nonce, but that nonce had better be X"? The implicit nonce (for AES-GCM, anyway) is a *counter*. Surely the crypto module and the TLS stack can agree on how to increment a number. --Andy From nobody Thu Jul 24 14:35:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBD81B28D1 for ; Thu, 24 Jul 2014 14:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImjHBdNVkehR for ; Thu, 24 Jul 2014 14:35:12 -0700 (PDT) Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41A351B280C for ; Thu, 24 Jul 2014 14:35:12 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id x48so3338033wes.19 for ; Thu, 24 Jul 2014 14:35:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mMMHkJc2dJlRAcZ7d0KgpFAvcYe3rfHw5JJrjGKpEbw=; b=EGpa8/i4KBKzHBi7NtGZmK2q8LMv0qaKEKBImBzrAVpy2IqEeuo6kjN9EYcBBuz9ZQ H1UBXZEefKm1NuyWgKKVczmK2BF9HGcz7pOhOIBafIFiVYaSEJ1raS/0WqRnu7hlQbZ/ jrKEA2oWkMDjUox7A2bxeWskPq1rsq5sOwftdyXDE56Nd6lS+rrL/d6RAL0rdiRF9ZlJ KLU46XLffIv82ULfvjcjeEjvcOzLQlsUVg8E4Mq8/kEI/Gp9s1pHKsluhKtgHFAs9W8U 9zOFPSiCnkVc8UOemeXXlERtmIxcjX1uEgY+JoT4JM05s6R7X9C5np6/pDvEB0n8iclt Vfxw== X-Gm-Message-State: ALoCoQnXSmo+u1m3xPeZZIGkrWiXKE32v9p/sBUhjN6t6bZFOy4J71sDTiwlUx65fUmuorzzNHbk X-Received: by 10.194.62.140 with SMTP id y12mr16352720wjr.27.1406237710909; Thu, 24 Jul 2014 14:35:10 -0700 (PDT) Received: from [31.133.166.226] (dhcp-a6e2.meeting.ietf.org. [31.133.166.226]) by mx.google.com with ESMTPSA id m3sm55854wik.7.2014.07.24.14.35.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 14:35:10 -0700 (PDT) Message-ID: <53D17BE5.8010905@nthpermutation.com> Date: Thu, 24 Jul 2014 17:34:29 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <53D176E0.7060002@amacapital.net> In-Reply-To: <53D176E0.7060002@amacapital.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BNjJCKxSXwch_DISvaDSAlhNeF4 Subject: Re: [TLS] shibboleth and the nonce X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 24 Jul 2014 21:35:13 -0000 On 7/24/2014 5:13 PM, Andy Lutomirski wrote: > I thought that the concern was that the "crypto module" (being the > >thing that is validated) needs to ensure that nonces don't repeat To be pedantic - it's important the the combination of key + nonce doesn't repeat. If you change the key, you can reuse the nonce and vice versa. Mike From nobody Thu Jul 24 21:10:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763311A0AC9 for ; Thu, 24 Jul 2014 21:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgON64DOJKiR for ; Thu, 24 Jul 2014 21:10:28 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4BF1A02DA for ; Thu, 24 Jul 2014 21:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1406261427; x=1437797427; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=kjBmzpxW8jlvXvhpCvDFuLRgz6Jrcm/Hth13jqyPbDY=; b=d335RbImGrtJFZWPlqUa6zMDSS6PNxAEqiE1DCCRctBCHCwzDblSAu9H yyAzOiSFGj5+V/Q5biL8pcvqcG1ojo/nb6UGaTaSNzWU+Lsp33dz7BYeH PID8pV9zsj0gzWiix8E9GfK9VXYgLoktNKH/HQEkFjSPpwUzZ3rV4i3Ru U=; X-IronPort-AV: E=Sophos;i="5.01,728,1399982400"; d="scan'208";a="265677144" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 25 Jul 2014 16:10:24 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.247]) by uxchange10-fe2.UoA.auckland.ac.nz ([169.254.27.86]) with mapi id 14.03.0174.001; Fri, 25 Jul 2014 16:10:24 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.txt Thread-Index: Ac+nvls5FHqclsepTsSPW3GIJ/RV6g== Date: Fri, 25 Jul 2014 04:10:23 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738EFB06D7@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/anv1ZP2l7gcmOL4Y_6iBvMQYfGg Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 04:10:35 -0000 Andrey Jivsov writes:=0A= =0A= >Cons:=0A= >* It adds only one bit of security=0A= >* an implementation that shares code between IKE and TLS will need to stor= e=0A= >an additional hardcoded prime.=0A= =0A= * The IKE values have been around since before IKE (in the form of Oakley),= =0A= nearly twenty years. These new values have been around since last Wednesda= y.=0A= This could mean a difference in anything from 0 to 1024, 2048, or whatever= =0A= bits of security (0 bits if they're no better or worse, the full bitsize if= =0A= they turn out to have some issue that the existing, well-proven ones don't)= .=0A= =0A= >Most people will not have strong preferences here, I assume.=0A= =0A= Well I do, the RFC 3526 values are already used in SSH (alongside IKE), and= =0A= I've been using them in TLS as well. I really don't want to have to implem= ent=0A= a whole new set of gratuitously incompatible parameters.=0A= =0A= All we need in order to deal with this is a signalling mechanism for which = set=0A= of parameters to use. The RFC should provide this, and reference a standar= d=0A= set of parameters, i.e. the IKE/SSH/whatever ones. Alongside this there co= uld=0A= be a second RFC, "Additional parameters for xxx", which contains the new=0A= parameters, although I can't see why anyone would want them.=0A= =0A= (OK, there's always the "as a spare in case the existing ones fail", it's a= =0A= pretty thin argument but I can accept it. Just make the standard RFC 3526= =0A= ones the default and have any new ones as a backup).=0A= =0A= Peter.= From nobody Thu Jul 24 21:33:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6AB1A0ADA for ; Thu, 24 Jul 2014 21:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffFKp99BJr19 for ; Thu, 24 Jul 2014 21:33:44 -0700 (PDT) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C57E91A0AD6 for ; Thu, 24 Jul 2014 21:33:44 -0700 (PDT) Received: by mail-yh0-f50.google.com with SMTP id v1so2573403yhn.23 for ; Thu, 24 Jul 2014 21:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qLLW0hhAY61zMyQbG6sgdYfRnu52eUNTn/uuwLsnL7s=; b=fUfR1GZYFVReS1SDJPAKotHwkDL5PDwruRL5Zcq2gWHYsr66pEVciI2SKE9RLxcgSA J558+mncoK639m2usKyzIgYvSWik4ey7KRyVBdJcpF4ncbZJDJd7yWIe2DEw98quviGj dLbshgCXP5h5IxYBN58jqRzqbXwo8DnnNROX0pb6JNsiQQNOC7QEthoqW3p4ZEJFIYT1 E6hLlnz4KYyYvy0l2uelX48Cqfhu4JIBVbOF45na1K6HKyqSu4Uh8VyxBlCWu9zcwZZQ xDsap66K24zI0pBVRYLqygAl7/4lqqcxx92IN663XFyXPQTD0bDhu7WaRmouIjB6ZyUW xIKQ== MIME-Version: 1.0 X-Received: by 10.236.88.225 with SMTP id a61mr19136839yhf.2.1406262824153; Thu, 24 Jul 2014 21:33:44 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Thu, 24 Jul 2014 21:33:44 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738EFB06D7@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C738EFB06D7@uxcn10-5.UoA.auckland.ac.nz> Date: Thu, 24 Jul 2014 21:33:44 -0700 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GIs9PYOvcMvhPJJrP7E4Q9JZm4Q Cc: "" Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 04:33:47 -0000 On Thu, Jul 24, 2014 at 9:10 PM, Peter Gutmann wrote: > Andrey Jivsov writes: > >>Cons: >>* It adds only one bit of security >>* an implementation that shares code between IKE and TLS will need to store >>an additional hardcoded prime. > > * The IKE values have been around since before IKE (in the form of Oakley), > nearly twenty years. These new values have been around since last Wednesday. > This could mean a difference in anything from 0 to 1024, 2048, or whatever > bits of security (0 bits if they're no better or worse, the full bitsize if > they turn out to have some issue that the existing, well-proven ones don't). What makes you think I sit around all day, looking at a particular prime, dreaming of ways to break that prime, and not others? The analogy to symmetric cryptanalysis is wrong: there is nothing "well-proven" about the Oakley primes. > >>Most people will not have strong preferences here, I assume. > > Well I do, the RFC 3526 values are already used in SSH (alongside IKE), and > I've been using them in TLS as well. I really don't want to have to implement > a whole new set of gratuitously incompatible parameters. I would love to know how your implementation manages to optimize arithmetic modulo a really nasty prime. The best strategy I can think of is Montgomery reduction, which requires a single per-prime table, so the logic is similar no matter what prime is used. (I don't care much one way or the other: IKE values would be fine). > > All we need in order to deal with this is a signalling mechanism for which set > of parameters to use. The RFC should provide this, and reference a standard > set of parameters, i.e. the IKE/SSH/whatever ones. Alongside this there could > be a second RFC, "Additional parameters for xxx", which contains the new > parameters, although I can't see why anyone would want them. > > (OK, there's always the "as a spare in case the existing ones fail", it's a > pretty thin argument but I can accept it. Just make the standard RFC 3526 > ones the default and have any new ones as a backup). The backup is ECC. The NFS is steadily improving, and harms all primes almost equally. Add that to the CPU consumption that keeps people from the higher bitlengths, and the days of prime group DH are numbered. Backups are only good if people use them: see the trouble with turning RC4 off. Sincerely, Watson Ladd > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Jul 24 22:13:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4861D1A0306 for ; Thu, 24 Jul 2014 22:13: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWf02KWcBXdN for ; Thu, 24 Jul 2014 22:13:29 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id B43531A0AD6 for ; Thu, 24 Jul 2014 22:13:29 -0700 (PDT) Received: from [10.0.1.131] (173-230-166-62.cable.teksavvy.com [173.230.166.62]) by che.mayfirst.org (Postfix) with ESMTPSA id 61476F984; Fri, 25 Jul 2014 01:13:26 -0400 (EDT) Message-ID: <53D1E776.40706@fifthhorseman.net> Date: Fri, 25 Jul 2014 01:13:26 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0 MIME-Version: 1.0 To: Peter Gutmann , "" References: <9A043F3CF02CD34C8E74AC1594475C738EFB003E@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738EFB003E@uxcn10-5.UoA.auckland.ac.nz> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cRNcwohmdvTLgj3jFDRjNNWGAQhMfSdaV" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-dYTlTLogRvRfKa71G3R65LYLTA Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 05:13:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cRNcwohmdvTLgj3jFDRjNNWGAQhMfSdaV Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/24/2014 10:53 AM, Peter Gutmann wrote: > - Why not just use the well-known and -accepted IKE groups from RFC 352= 6 for > this? In fact why invent entirely new groups (that don't even cover th= e > existing range in RFC 3526) when there's already well-established ones > available? There's a possibility that a very expensive (e.g. precomputation) attack exists that can be mounted against any given group. If we reuse the same group used by other mechanisms (e.g. ipsec) then the value for mounting such an expensive attack goes up. Selecting a different group forces an attacker to choose which group to attack. > - What's the thinking behind a 2432-bit group? 2048-bit I could unders= tand, > 2560 bits perhaps, but 2432? This was based on the 112-bit symmetric equivalence published by ECRYPT II. The ECRYPT document is referenced in the draft. > - Publishing the values of q (rather than just telling people how to ca= lculate > them) would be good, since it'd provide known-correct values for them. by q i think you mean (p-1)/2 -- i'm happy to document those values explicitly in the draft if you think that would be useful. Regards, --dkg --cRNcwohmdvTLgj3jFDRjNNWGAQhMfSdaV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJT0ed2XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcM90P/2DwlTgbA8YBemXkyxIs+gvz Sp+SA/hYJIIzRJuPfj7c56UtN/vu0eW8fOJ8aBTkauJyyDpoQmXJ85QpBMwgBEOV zDZyzaKCrFSpFp3vmq5nQP98mws2CUjNMEm/rLQqKgt/6LDsn/HKDTeOHUHWCG+A Xj5BugkCfaQ0Qn5ckjPCjfiv7OFC86xx/uNdVXQ3bX5YcLj71rR+2OphTADMHq8K 9jZwg3bYhVnfnVdeDXhhPJG+1TQYuOURk16rbDiezg13BQirANk4F6GDO3GECFMl f8e43AoDr2J5Egg1hujWEScZMkce5scbx4uaqx88Cy9t7JSEPVx7xcTYuUvtI6gQ V348LYOPSJT79XPXyCRFsaWFJI0hTpa7l1mG3yEdtqlu52i4YEycw5KDsn5m7qRF pake4M0BTasVkre4+uSohQKacpEMMqAyeIf0jlaN6Wy/rtdfx3HzkbDsnljBh10S okosN0/g5YZER1Xm3q2R0E8u4ZgpdkitUlx0+dpDkvrqKw8hZEBC7P/jOc0aKzxf BXLVws6L4kS2Qs6Sr5zInD/k2+gtKNiZPCLfaGB975+W8fDjA+sQKrYSj/Y3cmuS HNs9pgWboubkVd4Rd2cYePsLwPkus/qFvU/F+NcOeBp5aXuFcN7Az7bCC3xw7B1d 6fY/TlJuzo6riiQsTRPi =kdMl -----END PGP SIGNATURE----- --cRNcwohmdvTLgj3jFDRjNNWGAQhMfSdaV-- From nobody Fri Jul 25 09:10:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955791A0653 for ; Thu, 24 Jul 2014 10:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Y78zFihHRrq for ; Thu, 24 Jul 2014 10:32:00 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48ABC1A0016 for ; Thu, 24 Jul 2014 10:32:00 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id hu12so5456827vcb.20 for ; Thu, 24 Jul 2014 10:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=InZxq8x8loljA9k0bIzGYQ5xLQpmJEa3nqNx34K3lOY=; b=R0SfH/UXFwpdoeXuhHjAzUpc8oerqo2K3KzhMP3oT+sYMlPQEgjqx6eKyG9zlT54v3 kB9hzFGgAwCql18jvIws+iStjmfHdHw5gAeZyHSRyF5J6dTPaTxVNPHHX9lVUFT24eJd fuNl+CNZ+p1f5duAQ7M1eKdyIhusnpSxmG55tiXo42Oa1TI5v/Pci4m4lE/KYa0Pifx9 69PGrz9IQebBSn+IKpynpxd4MI4ezx3jjouE5Ewyy8I+pKOYKFZOPxaaYGEwY4ihi6ZG AM4L/1KbEOjPDNrjwU3SvphcpCNRL72q1jmzC+EjraQNLWBn2j/88geKmQFd7/eOkEhQ w4/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=InZxq8x8loljA9k0bIzGYQ5xLQpmJEa3nqNx34K3lOY=; b=gOZ1UudSGvJUWPBjvgP4zQDBLscO7ykZlT+I5eOwNb/HzJFiVqLqOs1wA7i01C4rBh EkaetIipFKgIvDvQfCKJp9xXoGkJ4dN5vjNERfw2ibKvZaP8CHyFwZtky5n1DlqNDXi+ VvonO/N+FcDXmrMryZrTdIf3h4eQYIzrfgDNIz5DeBSoYb7KF17176Cse7y9kEZFrQ21 Dot6JpSuOqENbnT6o+s+wSWT9L8efwxN/6QOfagP/uoao+6nT+ikE3vEei4jaITnp9+E mlqKZCW/8YgvcZOhCkOR8zGqGv1HB99hvy8C3it9b2WF7g+Fvos7z0ImD/EU9abBxJk8 taKQ== X-Gm-Message-State: ALoCoQncyRITAMGsMI04tOQ7sVLQTJ3fs4EUxc0HhLiVLLnIiEesAwVzrO9iu9UCFHdm/K+ut9s0 X-Received: by 10.220.49.10 with SMTP id t10mr14642511vcf.34.1406223119459; Thu, 24 Jul 2014 10:31:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.4.70 with HTTP; Thu, 24 Jul 2014 10:31:39 -0700 (PDT) In-Reply-To: References: <53B3F0D9.2010107@getjive.com> From: Justin Uberti Date: Thu, 24 Jul 2014 13:31:39 -0400 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=089e0163412c82cdec04fef3d5fb Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xsKLq6UkdKfmyElAdRc4z7MKo08 X-Mailman-Approved-At: Fri, 25 Jul 2014 09:10:23 -0700 Cc: "tls@ietf.org" , "tram@ietf.org" , "avt@ietf.org" Subject: Re: [TLS] [tram] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 17:32:01 -0000 --089e0163412c82cdec04fef3d5fb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I just sent a message to the TRAM list on this - I think the only real issue here is that the STUN demux procedure specific in 5764 is incorrect. When FINGERPRINT is used, which is mandatory for ICE, there is no issue with demuxing STUN from anything. And there has never been a demux issue for TURN channels, since packets from the TURN server will never be unencapsulated. Ergo, we don't need any changes to the STUN registries or TURN channels. We should just update 5764 to reference 5389, Section 7.3. I agree it would be nice to have a first-byte registry for generic data, e.g. RTP vs DTLS, to ensure that all application protocols can be properly demuxed from each other. On Wed, Jul 23, 2014 at 1:54 PM, Cullen Jennings (fluffy) wrote: > > Thank you for doing this - I=E2=80=99ve wanted to have this fixed for a l= ong time. > > I think this is good but some recommendations I would make. > > We should make a new IANA registry that keeps track of for each value of > the first byte, which protocol it is allocated to. I would suggest that i= t > require "Standards Action=E2=80=9D to allocate a new code point to a prot= ocol but > of course one allocated to that protocol, the protocol would manager it > within it=E2=80=99s existing IANA registry for that protocol with that pr= otocols > existing rules. > > The advantage of this is we can allocate the points as needed instead of > guessing if TLS or STUN or some new protocol will need a given number > points. There is no implementation problem for the demux because things > that use the new code points would know how to demux them. > > I think that STUN and TURN should use up the minimal number of code point= s > in the registry that they easily can. Later, if they need more code point= s, > they can co back registry to get more. > > I would suggest that 256 channels would be enough for TURN. If a given > TURN client needs more than that, it just needs to allocate a second loca= l > UDP port. So TURN probably needs 1 code point for now. > > It would be good to allocate one code point for experimental use. > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --089e0163412c82cdec04fef3d5fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I just sent a message to the TRAM list on this - I think t= he only real issue here is that the STUN demux procedure specific in 5764 i= s incorrect. When FINGERPRINT is used, which is mandatory for ICE, there is= no issue with demuxing STUN from anything.

And there has never been a demux issue for TURN channels, si= nce=C2=A0packet= s from the TURN server will never be unencapsulated.

Ergo, we don't need any changes to the STUN registries or TURN chann= els. We should just update 5764 to reference 5389, Section 7.3.

I a= gree it would be nice to have a first-byte registry for generic data, e.g. = RTP vs DTLS, to ensure that all application protocols can be properly demux= ed from each other.


On Wed,= Jul 23, 2014 at 1:54 PM, Cullen Jennings (fluffy) <fluffy@cisco.com>= ; wrote:

Thank you for doing this - I=E2=80=99ve wanted to have this fixed for a lon= g time.

I think this is good but some recommendations I would make.

We should make a new IANA registry that keeps track of for each value of th= e first byte, which protocol it is allocated to. I would suggest that it re= quire "Standards Action=E2=80=9D to allocate a new code point to a pro= tocol but of course one allocated to that protocol, the protocol would mana= ger it within it=E2=80=99s existing IANA registry for that protocol with th= at protocols existing rules.

The advantage of this is we can allocate the points as needed instead of gu= essing if TLS or STUN =C2=A0or some new protocol will need a given number p= oints. There is no implementation problem for the demux because things that= use the new code points would know how to demux them.

I think that STUN and TURN should use up the minimal number of code points = in the registry that they easily can. Later, if they need more code points,= they can co back registry to get more.

I would suggest that 256 channels would be enough for TURN. If a given TURN= client needs more than that, it just needs to allocate a second local UDP = port. So TURN probably needs 1 code point for now.

It would be good to allocate one code point for experimental use.


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--089e0163412c82cdec04fef3d5fb-- From nobody Fri Jul 25 10:37:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF851A03AD for ; Fri, 25 Jul 2014 10:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olR8B8V_i0Ef for ; Fri, 25 Jul 2014 10:37:30 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5791A037A for ; Fri, 25 Jul 2014 10:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=516; q=dns/txt; s=iport; t=1406309850; x=1407519450; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=SIWY1RUdz4tJ9i6WEcD4A/lY92oMMQhWeFoY5QKqVLI=; b=bkbc2oroOI0c46pvjAl2z+Kkc1LgSDF3zFM0pxxEaI16hHxf7lThrDEl 2hKVWOTUoh0LqeCmbN1ZqldrCfBz7ynPilsKluYiuynPb5QxdZghFZbcJ SvlSYPpi1bI0Q63oBWUrfuPm57ZTuloWo9MdAEgzOw+ZZ3xx62XLSFuTc I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FANuU0lOtJV2U/2dsb2JhbABZgw6BLdJlFneECjpRAT5CJwSIVZhnpkUXkwCBGwWbR5RKg0iCMQ X-IronPort-AV: E=Sophos;i="5.01,732,1400025600"; d="scan'208";a="342844834" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-2.cisco.com with ESMTP; 25 Jul 2014 17:37:30 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6PHbTEP018499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 25 Jul 2014 17:37:29 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.143]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Fri, 25 Jul 2014 12:37:00 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Encryption of TLS 1.3 content type Thread-Index: AQHPqC8baIxMzdBVrU6TDpjh9o/qpg== Date: Fri, 25 Jul 2014 17:37:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.85.164.221] Content-Type: text/plain; charset="us-ascii" Content-ID: <939F4B0B5CE96149B4E5759474F5FD6D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/p7vxvV67vGcYhgla1JIvRSNwsr8 Subject: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2014 17:37:34 -0000 At the interim meeting on July 20, 2014 there was general consensus to supp= ort the encryption of TLS 1.3 content type. The favored approach was to re= move the content type and version from the TLS record layer header and add = the content type to the encrypted data. The proposal is to update the dra= ft to document this approach and try to run some tests to see if this cause= s much grief with middle boxes. If you object to this proposal please resp= ond to the list by Friday, August 01, 2014. = From nobody Fri Jul 25 12:27:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAC31A03CA for ; Fri, 25 Jul 2014 12:27:42 -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, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFOCck2SohJ2 for ; Fri, 25 Jul 2014 12:27:41 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AE1F1A0195 for ; Fri, 25 Jul 2014 12:27:41 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id f12so5050479qad.17 for ; Fri, 25 Jul 2014 12:27:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UwD6R2z/iqIIalrbHy/6q5O/bEJOWaVZg8pPrnZxBsc=; b=f4MR1NXayeqXmvEqxWGW+pzqnd05xUfAqPLxVXqsRYwZ/rb0htsXJO0+mEmAEKClhe XqYXVCiGIbS+PTrg8hTZodyWnwiyOdUAiRpfVvUR/AHq2PCexUKP1HOiAnSxUBEWvK7W YfEa57JmVBz/lusNktg4qz8NAhAyesCBGF0X7c/zYtpmcTpYh1skd1niMIRhGsszmgo9 YXpEX2MgzeOpRdaRX5x/SY9BTBIrwdQP01wbs8Hx0y9nZvvhQF+H7P8UPXuhW6/NTZ5V xLr3x1H0W4WSpXP8NBwwxieqJt9iuD+iM3G0gdLRSHEkeSf24DdJrsbZ9E5uS+GwMJmJ g65g== MIME-Version: 1.0 X-Received: by 10.140.43.245 with SMTP id e108mr30048802qga.76.1406316460817; Fri, 25 Jul 2014 12:27:40 -0700 (PDT) Received: by 10.140.98.233 with HTTP; Fri, 25 Jul 2014 12:27:40 -0700 (PDT) In-Reply-To: <7C3D5CF9-2B17-4953-A13D-C5E7226D13E7@ieca.com> References: <7C3D5CF9-2B17-4953-A13D-C5E7226D13E7@ieca.com> Date: Fri, 25 Jul 2014 12:27:40 -0700 Message-ID: From: Robert Ransom To: Sean Turner Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9avb0iMQlXXavH6enm1ni7X-0uo Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tls 1.3: renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 19:27:42 -0000 On 7/21/14, Sean Turner wrote: > At the TLS interim meeting held on Sunday July 20th, 2014, there was > consensus to remove renegotiation on the assumption we will provide a > rekeying facility of some form and client initated client authentication. > This message serves to confirm that consensus. Please indicate by July > 25th, 2014 whether you disagree with this (and why). I oppose removal of renegotiation, for the following reasons: * Renegotiation is a single feature which serves many purposes. I believe that fixing the design, APIs, and implementations of renegotiation will be easier than designing the protocols, designing the APIs, and implementing every feature which would be needed to replace it. * The client-initiated client authentication feature will require a =E2=80=98channel binding=E2=80=99 to the existing TLS connection, which -= - as Nico Williams has pointed out -- is sufficient to work around renegotiation-based attacks at the protocol level, by binding the application data sent before renegotiation to the authentication performed during the renegotiation handshake. Adding a channel binding to renegotiation would not require as many changes to existing code as adding an entirely new client authentication feature would, and would provide less room for new implementation bugs to creep in. * Renegotiation can share most of its code with the implementation of the initial connection handshake, even after a channel binding is added to it. Each of the new features added in order to replace renegotiation is likely to share considerably less code with the initial handshake, and their implementations are likely to receive considerably less use and less testing than any piece of code used in implementing renegotiation. In addition, I believe that it is not possible for the WG to make an informed decision as to whether renegotiation should be removed at this time: * The rekeying feature and client-initiated client authentication feature have not been specified yet, even to the point of stating the requirements which each feature will meet. It is not possible for the WG to determine whether the features intended to replace these two uses of renegotiation will be fit for their intended purposes at this time. Robert Ransom From nobody Fri Jul 25 13:57:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCA11A0252 for ; Fri, 25 Jul 2014 13:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 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_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2HxpIPVCcTG for ; Fri, 25 Jul 2014 13:57:40 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7577F1A024E for ; Fri, 25 Jul 2014 13:57:40 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id hn18so1368186igb.9 for ; Fri, 25 Jul 2014 13:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0SIadBXYRONu1tIxk/noGULawT2GrzlnZWHtRhz4W7g=; b=XauyLmqaDAQfqn9akgD61Iw3DoE+Ci/uspgfPGZ6LJe/UMtGy9XgUXQE7UgFLstDkF FFELYDK/VgBil62eAQtPc38e7xg9IS2M8/iXEJoXVNkctZ4tbNAHrwIVJoyU0dLqiEFY UJ6sHEYgN41HgoavTQP64AKayPjgebmP6bOs3lxPZp90LZCreB9AjSkUVn6FH8IvXthq dYYKTb2nq20jyM45A5NQKNt4rLbtJTke9RfEdM8KgX01y/+/J+ThYFCrMyjrjw3GT0T4 3AmDLsNqP7jWuHNGpbgQPWI1oqsI7a56OiEqEJxelbWQJIO7S9wyPIJ+e9Xnd1uy7TgI mj+A== X-Received: by 10.42.47.140 with SMTP id o12mr2404413icf.4.1406321859709; Fri, 25 Jul 2014 13:57:39 -0700 (PDT) Received: from [10.205.142.219] ([209.226.201.241]) by mx.google.com with ESMTPSA id n10sm7901709igv.21.2014.07.25.13.57.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 13:57:38 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: Date: Fri, 25 Jul 2014 16:57:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <578C0CCE-DD3C-41B9-A8D7-19D5B799F643@gmail.com> References: To: "Joseph Salowey (jsalowey)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/N3skB7VbwCBZRDu_u_xQE-ggdYw Cc: "" Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2014 20:57:41 -0000 Hi. I believe that changing the 5-byte record header will cause us trouble. = Passive IDS/IPS devices follow TLS streams to detect certain attacks. = They will cut connections. I also believe that it is impossible to =93run = some tests=94 because there are literally dozens of different such = middleboxes, with multiple software/firmware versions available for each = type. I therefore support leaving the 5-byte header as it is, fixing the = ContentType value to 23 for all encrypted records, and having another = contentType byte within the encrypted record. Yoav On Jul 25, 2014, at 1:37 PM, Joseph Salowey (jsalowey) = wrote: > At the interim meeting on July 20, 2014 there was general consensus to = support the encryption of TLS 1.3 content type. The favored approach = was to remove the content type and version from the TLS record layer = header and add the content type to the encrypted data. The proposal is = to update the draft to document this approach and try to run some tests = to see if this causes much grief with middle boxes. If you object to = this proposal please respond to the list by Friday, August 01, 2014. =20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Jul 25 14:06:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2831A0392 for ; Fri, 25 Jul 2014 14:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgPBOPSEvVSX for ; Fri, 25 Jul 2014 14:06:20 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2061A1A0371 for ; Fri, 25 Jul 2014 14:06:19 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id bs8so1657196wib.9 for ; Fri, 25 Jul 2014 14:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=mCAiLtn4hdsCUkwVM0CeuoyviDuypxr9lD24dLI4l94=; b=qheiZfIksrENjhtGwymjd2OcWW8UKBL16F1aGGA6QQexbioOqlNGFlY1EEJ5euxp8Q K1WPUXzUxJswd+zONMxkG+YLrmDl0ExBPtoESQwnWokLZQSlKKEpPF7AB6adP+Ce2aaK uHOz1WPcQv2VuQIIZdySi7SlKlWeb49fVLkdQUOBcpH3z36YtbUiFuGSwnL6meZJMXuO LflYX+T1VDnKeg6UDGxPijKKxYOtmYgMB9i4j2Xk1FGSAu0XtZTk3BwlsQOwt3DcOxFF paBbzbVQk+TiY+fagoRUzDgmkRqZCh+rs3nccngHC2FEMIiHzQNTNLYtx6tgJAHhgKD1 mDEw== X-Received: by 10.194.6.101 with SMTP id z5mr25914490wjz.79.1406322378664; Fri, 25 Jul 2014 14:06:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.253.200 with HTTP; Fri, 25 Jul 2014 14:05:58 -0700 (PDT) In-Reply-To: <578C0CCE-DD3C-41B9-A8D7-19D5B799F643@gmail.com> References: <578C0CCE-DD3C-41B9-A8D7-19D5B799F643@gmail.com> From: Fabrice Gautier Date: Fri, 25 Jul 2014 14:05:58 -0700 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YNyvPG9ds8GEd9cpXDMmeRa7L14 Cc: "" Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2014 21:06:22 -0000 I also object this proposal I'm not too familiar with IETF process, but shouldn't we have test results first before we actually update the draft ? I know its just a draft and it can be probably be changed back if the test results are bad, but it seems it might be an uphill battle then. Also I haven't seen a discussion of what the tests would be, or what would be considered acceptable results. I didn't think the IETF process usually involve testing in any formal manner. I'm assuming that this would be up to individual contributors to test this with their own TLS 1.3 draft implementations and then raise issues if they appear later ? If thats correct, it seems that this proposal is to update the draft and see if anybody complains later based on actual tests. On Fri, Jul 25, 2014 at 1:57 PM, Yoav Nir wrote: > Hi. > > I believe that changing the 5-byte record header will cause us trouble. P= assive IDS/IPS devices follow TLS streams to detect certain attacks. They w= ill cut connections. I also believe that it is impossible to =E2=80=9Crun s= ome tests=E2=80=9D because there are literally dozens of different such mid= dleboxes, with multiple software/firmware versions available for each type. > > I therefore support leaving the 5-byte header as it is, fixing the Conten= tType value to 23 for all encrypted records, and having another contentType= byte within the encrypted record. > > Yoav > > On Jul 25, 2014, at 1:37 PM, Joseph Salowey (jsalowey) wrote: > >> At the interim meeting on July 20, 2014 there was general consensus to s= upport the encryption of TLS 1.3 content type. The favored approach was to= remove the content type and version from the TLS record layer header and a= dd the content type to the encrypted data. The proposal is to update the = draft to document this approach and try to run some tests to see if this ca= uses much grief with middle boxes. If you object to this proposal please r= espond to the list by Friday, August 01, 2014. >> _______________________________________________ >> 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 From nobody Fri Jul 25 14:12:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8C71A0362 for ; Fri, 25 Jul 2014 14:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IECcG9hvlCJY for ; Fri, 25 Jul 2014 14:12:15 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CEA01A0252 for ; Fri, 25 Jul 2014 14:12:14 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so4775007wgh.27 for ; Fri, 25 Jul 2014 14:12:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UxGNLmmvfVQ6nN0wTJQTbcA+y46WWbE3YWBwq31I5RA=; b=G4J24eaRo6OSW+ZUbeO8wJaAyuFlJgdjk9XoBFx9cTCXtmeJGdx/AVyCG0nn+giV2V ucNIiVntpglJqoEsUn46VIMP99agPUgrQ/diBIa4XyQGJQM5rYlTYyA7O9m+einxDA55 uUyDYochttWkRcw4NoYwIu+CzubgTIX6gYZqhxclwvU+5R7wxFHRV5tFHqT7kdeVD6df JbmlvqPNYKLiJpce5M6EfNGfeV3K4mCQoeVYLrux8vRoFdG5359s0mlwb0+AADBOTLhV dr8SMTRlujUO+bGnUoHd11r07aI+1PuJFKY1M+n62fJp2jf258WcXStuORKnTdXEeQVL /Ywg== X-Gm-Message-State: ALoCoQn1Bt102WoWm/EBaFWCJFkfQx9Crlzs4tkQCpxIYsKwG3oZ6gEAhlSH5YTiLFtSuOYyiK7H X-Received: by 10.194.184.166 with SMTP id ev6mr22306226wjc.61.1406322733262; Fri, 25 Jul 2014 14:12:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Fri, 25 Jul 2014 14:11:33 -0700 (PDT) X-Originating-IP: [2001:450:1f:232:6409:121d:1c49:1e9d] In-Reply-To: <578C0CCE-DD3C-41B9-A8D7-19D5B799F643@gmail.com> References: <578C0CCE-DD3C-41B9-A8D7-19D5B799F643@gmail.com> From: Eric Rescorla Date: Fri, 25 Jul 2014 14:11:33 -0700 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=047d7bae4932f4ca0704ff0b06fe Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TD3DtvGIjZLHQZZPSA39h8_eigk Cc: "" Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2014 21:12:17 -0000 --047d7bae4932f4ca0704ff0b06fe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 25, 2014 at 1:57 PM, Yoav Nir wrote: > Hi. > > I believe that changing the 5-byte record header will cause us trouble. > Passive IDS/IPS devices follow TLS streams to detect certain attacks. The= y > will cut connections. I also believe that it is impossible to =E2=80=9Cru= n some > tests=E2=80=9D because there are literally dozens of different such middl= eboxes, > with multiple software/firmware versions available for each type. > > I therefore support leaving the 5-byte header as it is, fixing the > ContentType value to 23 for all encrypted records, and having another > contentType byte within the encrypted record. Yoav, The tests I had in mind were having browsers form connections back to some central server and measure how it works. That's not perfect, but it lets us test with a large corpus. -Ekr > Yoav > > On Jul 25, 2014, at 1:37 PM, Joseph Salowey (jsalowey) > wrote: > > > At the interim meeting on July 20, 2014 there was general consensus to > support the encryption of TLS 1.3 content type. The favored approach was > to remove the content type and version from the TLS record layer header a= nd > add the content type to the encrypted data. The proposal is to update t= he > draft to document this approach and try to run some tests to see if this > causes much grief with middle boxes. If you object to this proposal plea= se > respond to the list by Friday, August 01, 2014. > > _______________________________________________ > > 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 > --047d7bae4932f4ca0704ff0b06fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 25, 2014 at 1:57 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
Hi.

I believe that changing the 5-byte record header will cause us trouble. Pas= sive IDS/IPS devices follow TLS streams to detect certain attacks. They wil= l cut connections. I also believe that it is impossible to =E2=80=9Crun som= e tests=E2=80=9D because there are literally dozens of different such middl= eboxes, with multiple software/firmware versions available for each type.
I therefore support leaving the 5-byte header as it is, fixing the ContentT= ype value to 23 for all encrypted records, and having another contentType b= yte within the encrypted record.

Yoav,

The tests I had in mind were having browsers form conne= ctions back to
some central server and measure how it works. That= 's not perfect, but
it lets us test with a large corpus.

-Ekr


Yoav

On Jul 25, 2014, at 1:37 PM, Joseph Salowey (jsalowey) <jsalowey@cisco.com> wrote:
> At the interim meeting on July 20, 2014 there was general consensus to= support the encryption of TLS 1.3 content type. =C2=A0The favored approach= was to remove the content type and version from the TLS record layer heade= r and add the content type to the encrypted data. =C2=A0 The proposal is to= update the draft to document this approach and try to run some tests to se= e if this causes much grief with middle boxes. =C2=A0If you object to this = proposal please respond to the list by Friday, August 01, 2014.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

--047d7bae4932f4ca0704ff0b06fe-- From nobody Sat Jul 26 10:43:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACA31B283A for ; Sat, 26 Jul 2014 10:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTvKBLmKMAau for ; Sat, 26 Jul 2014 10:43:20 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE2301A03AB for ; Sat, 26 Jul 2014 10:43:20 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id b6so3857088yha.0 for ; Sat, 26 Jul 2014 10:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IP/gRt17qtsyrNl5P7yUJQ6yaGkUAGcaSNiR7wWNh+c=; b=hFSUdYU3HhcS5BBUrCnN+RCD6hH562GgOALpuuMdjTd8PhH5AITt+CVprwe3+Uhcb5 3M3tbWA2O2X3l8h8aq1mBQhz6FWbuVam+GqD7EVilkeLJspylV7VBGGOIETFNndNKljm 6N28YK29wKK/Jk8fXD70lSbEGlbjKfQf/SlgtLjCeOkzRWf8fwcc9MlOa0ZOjGXIHyFO fQZ7UlLH48Iz68s6Ww2QVUvbapQToYUC1lA4U0TKxNnTAV0K69nqG0lHEsdfydMA+Msf FaWMlLkoyXV+u94Hn76T8WH9GLh+MhxwvHPiLi63n6LFkkWculSncZnRcavfrW1HDYTv /b8A== MIME-Version: 1.0 X-Received: by 10.236.45.10 with SMTP id o10mr34597150yhb.49.1406396600037; Sat, 26 Jul 2014 10:43:20 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Sat, 26 Jul 2014 10:43:19 -0700 (PDT) In-Reply-To: References: Date: Sat, 26 Jul 2014 10:43:19 -0700 Message-ID: From: Watson Ladd To: "Joseph Salowey (jsalowey)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LPlhjtjYJ9H8lBRFibdZUrl3Keg Cc: "" Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Jul 2014 17:43:22 -0000 This is a change with no rationale: the content type leaks extremely limited information. It complicates implementations that wish to keep a high degree of codepath similarity between TLS 1.2 and TLS 1.3. On Fri, Jul 25, 2014 at 10:37 AM, Joseph Salowey (jsalowey) wrote: > At the interim meeting on July 20, 2014 there was general consensus to su= pport the encryption of TLS 1.3 content type. The favored approach was to = remove the content type and version from the TLS record layer header and ad= d the content type to the encrypted data. The proposal is to update the d= raft to document this approach and try to run some tests to see if this cau= ses much grief with middle boxes. If you object to this proposal please re= spond to the list by Friday, August 01, 2014. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sat Jul 26 10:58:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626881A00D7 for ; Sat, 26 Jul 2014 10:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7D1h9Iak1_u for ; Sat, 26 Jul 2014 10:58:10 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0EF1A00BE for ; Sat, 26 Jul 2014 10:58:09 -0700 (PDT) Received: by mail-yk0-f175.google.com with SMTP id q200so3636335ykb.20 for ; Sat, 26 Jul 2014 10:58:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ZK/giULQAqMkglhp45uZvxFOHe/uvKmqg8RLHV2G330=; b=Zm9uSwDUAw58aq2wYx0CoZ1ivkiQlVMz9dOUxOCEKMGy6v9O++qGpgESgI5hYGMRBI Kkd7AobRQOaGn+ESRZYLDKcDiM8gTau082ei3na4JIAKlwpwq4pE9Oli/edkM0gLSi7y ZZHghWDfaRVQDqDmk15g4uhXpkC8VSRnNDFutnplAXGwHXv2Ez/wPXpBgwj0sMoUl325 qfNeslwEPAfVExOFBjNMOVOp9DXbBOPMBctag1vEAQmpJ8r87qhgZhdbbnEp37iq3tyu oSQI5P3Ovqqh7SyFRcRKIpIoSApJzWFuuxsEB93bJ/w+2yuxAtYCQcabNAiXhv99jI2N JpDA== MIME-Version: 1.0 X-Received: by 10.236.45.10 with SMTP id o10mr34702735yhb.49.1406397489299; Sat, 26 Jul 2014 10:58:09 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Sat, 26 Jul 2014 10:58:09 -0700 (PDT) Date: Sat, 26 Jul 2014 10:58:09 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" , "cfrg@irtf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BPPdj8PEYRh8XRxnmKCtPfIywIM Subject: [TLS] Unwarrented change to point formats X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Jul 2014 17:58:14 -0000 Dear all, Curve25519 was a draft. Curve25519 came back with good reviews from the CFRG. End of story? No: the TLS WG leadership has decided to ask for the choice of curves, on nebulous criteria, ignoring existing drafts, on the basis that the curves must be applicable "IETF wide". I don't see the reason for this, especially given that OpenSSH has implemented and deployed Curve25519 and Ed25519, complete with Montgomery form on the wire. Arguing that we need twisted Edwards point formats everywhere for consistency with existing libraries ignores what has already been deployed and widely adopted. Sincerely, Watson Ladd From nobody Sat Jul 26 10:59:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73501A00EB for ; Sat, 26 Jul 2014 10:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyRRt0Q1I69l for ; Sat, 26 Jul 2014 10:59:21 -0700 (PDT) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C901A010A for ; Sat, 26 Jul 2014 10:59:16 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id o6so6942787oag.25 for ; Sat, 26 Jul 2014 10:59:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qMgrLp2US0S8NLloLaV7O5rHuFX9myFWX9ovuuifKzI=; b=UAr0anCIQoaIx9XjdTqfZfiRVempQRjOXnmTkoLHsKoIRHSs6QyR6BcDRK8CXOZiVX cGdjN/WAXfQNuOEI+vIg4NLVWpldXsllCAnO+Zx5m1pAywoEiy1QmB7eN/f2geAPWZBs z3UQcS0+F7Kr9KkK198HtnH1WLwinBfTRlEcwgKVqc3ndfKWtPEgpn6plfXIb6vIWNqW rCN4797fDgLN6M1ZecXD1hcxzNoF84V95MNowavUmz701JhykCPJrJO6n2inpnvMVJei 3sb8psC0SgxHekd/qnI/I9eTEpC28L3qTKpN+rNssvl00ysXBOL/yOE0offNQlFWSbb+ UHBQ== X-Gm-Message-State: ALoCoQnyitFxOuiYRKwU5dSpOinzY6APwPohkoz947ila3JTIIYi0LyCFZ8aUHSqO/sFW5O29as/ MIME-Version: 1.0 X-Received: by 10.60.52.5 with SMTP id p5mr33362970oeo.55.1406397555374; Sat, 26 Jul 2014 10:59:15 -0700 (PDT) Received: by 10.76.10.198 with HTTP; Sat, 26 Jul 2014 10:59:15 -0700 (PDT) In-Reply-To: References: Date: Sat, 26 Jul 2014 10:59:15 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZDNE7Vz_9Inl4qXAVN8l7-MXzW0 Cc: "" Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 26 Jul 2014 17:59:24 -0000 Leaking alert messages has been a recurring theme common to several attacks; hindering a MITM's ability to discern alert messages seems like a rational rationale. On Sat, Jul 26, 2014 at 10:43 AM, Watson Ladd wrote= : > This is a change with no rationale: the content type leaks extremely > limited information. It complicates implementations that wish to keep > a high degree of codepath similarity between TLS 1.2 and TLS 1.3. > > On Fri, Jul 25, 2014 at 10:37 AM, Joseph Salowey (jsalowey) > wrote: >> At the interim meeting on July 20, 2014 there was general consensus to s= upport the encryption of TLS 1.3 content type. The favored approach was to= remove the content type and version from the TLS record layer header and a= dd the content type to the encrypted data. The proposal is to update the = draft to document this approach and try to run some tests to see if this ca= uses much grief with middle boxes. If you object to this proposal please r= espond to the list by Friday, August 01, 2014. >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > > > -- > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 Colm From nobody Sat Jul 26 14:14:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4E91A03A8 for ; Sat, 26 Jul 2014 14:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJU_hWyWpNxd for ; Sat, 26 Jul 2014 14:13:55 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC1161A031C for ; Sat, 26 Jul 2014 14:13:54 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ho1so2547383wib.4 for ; Sat, 26 Jul 2014 14:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=alYv5PnX6S0hIHyqkli/xt0KcQdCuluKwZwo5pTtzqs=; b=ukuSvMjhCndMCW/mCHjXPkdsGgd+Yqi39vh/VbXwRA3e/14IcMgU1U54m14nSKsJYC WWjl25T3eNkhCgqF8yeqSnMisA34BOrMNzTlKa82Wa7w231Gti8A5iMtu0EwYZvRvG7u SogOy0i7ud5mtzsMxUtmHFxXYxd4jsyohSlv7+H311VVNPxHaQAE6hBhXzqvyXdmrthz K26qy4vK4n27xZis2sAJMhs1nqovjrvUv2W+Rs8NQEVcBX7gv5aTHgJ4vaNkhbAsPAzS BSRYJwr2jC/Wsh6iV2OFn4JGUve4lXwFyr2RDfNa56rodoDgUjqs2edfyfsEMwBUaQoa ALwQ== X-Received: by 10.180.210.172 with SMTP id mv12mr15896909wic.14.1406409233346; Sat, 26 Jul 2014 14:13:53 -0700 (PDT) Received: from [192.168.1.199] ([109.253.142.212]) by mx.google.com with ESMTPSA id gd13sm11466168wic.6.2014.07.26.14.13.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Jul 2014 14:13:52 -0700 (PDT) Message-ID: <53D41993.4040602@gmail.com> Date: Sun, 27 Jul 2014 00:11:47 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , Peter Gutmann , "" References: <9A043F3CF02CD34C8E74AC1594475C738EFB003E@uxcn10-5.UoA.auckland.ac.nz> <53D1E776.40706@fifthhorseman.net> In-Reply-To: <53D1E776.40706@fifthhorseman.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LWS4KsVoubN-eu38LCo9rLx47a4 Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 21:13:57 -0000 On 07/25/2014 08:13 AM, Daniel Kahn Gillmor wrote: > On 07/24/2014 10:53 AM, Peter Gutmann wrote: >> - Why not just use the well-known and -accepted IKE groups from RFC 3526 for >> this? In fact why invent entirely new groups (that don't even cover the >> existing range in RFC 3526) when there's already well-established ones >> available? > > There's a possibility that a very expensive (e.g. precomputation) attack > exists that can be mounted against any given group. If we reuse the > same group used by other mechanisms (e.g. ipsec) then the value for > mounting such an expensive attack goes up. > > Selecting a different group forces an attacker to choose which group to > attack. > Both IKE and TLS are high value enough that (choose your favorite 3-letter acronym) would gladly spend the money to break either or both, if such an attack was possible. And actually the logical outcome of your argument is that we need 10 or 100 new named groups in TLS to minimize this risk. I don't think anybody is seriously considering that. Thanks, Yaron From nobody Sun Jul 27 11:26:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC911A0B10 for ; Sun, 27 Jul 2014 11:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMH4ZBanvcbQ for ; Sun, 27 Jul 2014 11:25:58 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0015.outbound.protection.outlook.com [213.199.154.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 273A51A0AE5 for ; Sun, 27 Jul 2014 11:25:58 -0700 (PDT) Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB381.eurprd03.prod.outlook.com (10.141.10.11) with Microsoft SMTP Server (TLS) id 15.0.995.14; Sun, 27 Jul 2014 18:25:55 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.00.0995.014; Sun, 27 Jul 2014 18:25:55 +0000 From: "Paterson, Kenny" To: Watson Ladd Thread-Topic: [TLS] Unwarrented change to point formats Thread-Index: AQHPqPtIfxZu0QqDV0qbT2QAUQQVkpu0PnH4 Date: Sun, 27 Jul 2014 18:25:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [78.146.58.177] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0285201563 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(24454002)(51704005)(74502001)(4396001)(74662001)(74482001)(83716003)(36756003)(77982001)(31966008)(15975445006)(76482001)(79102001)(82746002)(21056001)(46102001)(1411001)(101416001)(110136001)(2656002)(105586002)(107046002)(87936001)(86362001)(33656002)(95666004)(85306003)(99396002)(92726001)(92566001)(76176999)(83072002)(85852003)(54356999)(81542001)(50986999)(83322001)(80022001)(66066001)(106356001)(81342001)(64706001)(20776003)(19580395003)(19580405001)(106116001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR03MB381; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1Lrjie1q86O68LZF7DzCfxl2eJY Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] Unwarrented change to point formats X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jul 2014 18:26:00 -0000 Watson, There was certainly support for Curve25519 at the CFRG interim phone confer= ence, from my reading of the transcript.=20 I don't think the reasons for the TLS WG to ask for our input are nebulous,= as you put it. I'd say they were taking a responsible approach, charging u= s as experts to explore the alternatives carefully and make recommendations= . This choice will affect the future security of TLS for years - or decades= - to come. So we have to get it right.=20 That request to us does not mean anyone is ignoring existing drafts, as you= write. I am also not aware of this IETF-wide requirement that you mention.= I believe it's a "nice to have", but not a hard requirement. Can you point= to something more solid that is demonstrably a consensus view? You will note from my previous emails summarising the meeting in Toronto th= at backwards compatibility with the existing wire format is regarded as bei= ng desirable but not essential by the TLS WG leadership. If it can be done,= it will make adoption easier; if not, we can change it, but it will need s= ome careful drafting to make sure it's crystal clear.=20 The fact that the small group who run OpenSSH has adopted a couple of schem= es based on a particular curve does not necessarily make that curve the rig= ht choice for TLS. I also don't regard that as wide adoption, as you put it= . I'm not aware of a public, requirements-driven process behind their choic= e. That's what we are attempting here. =20 Your continued inputs to the process are most welcome.=20 Regards Kenny=20 > On 26 Jul 2014, at 18:59, "Watson Ladd" wrote: >=20 > Dear all, > Curve25519 was a draft. Curve25519 came back with good reviews from > the CFRG. End of story? No: the TLS WG leadership has decided to ask > for the choice of curves, on nebulous criteria, ignoring existing > drafts, on the basis that the curves must be applicable "IETF wide". >=20 > I don't see the reason for this, especially given that OpenSSH has > implemented and deployed Curve25519 and Ed25519, complete with > Montgomery form on the wire. Arguing that we need twisted Edwards > point formats everywhere for consistency with existing libraries > ignores what has already been deployed and widely adopted. >=20 > Sincerely, > Watson Ladd >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From nobody Sun Jul 27 11:45:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F11B1A0076 for ; Sun, 27 Jul 2014 11:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhHOtMrwUiqm for ; Sun, 27 Jul 2014 11:45:41 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 73BF91A0030 for ; Sun, 27 Jul 2014 11:45:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CAA87BE7D; Sun, 27 Jul 2014 19:45:40 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlR3uCUYVUVE; Sun, 27 Jul 2014 19:45:39 +0100 (IST) Received: from [10.87.48.11] (unknown [86.44.77.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5F8BDBE7B; Sun, 27 Jul 2014 19:45:39 +0100 (IST) Message-ID: <53D548D3.8030007@cs.tcd.ie> Date: Sun, 27 Jul 2014 19:45:39 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Paterson, Kenny" , Watson Ladd References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-OfZxnPUO5wlY8vFNrbaTTXtFiI Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Unwarrented change to point formats X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jul 2014 18:45:43 -0000 To clarify this bit... On 27/07/14 19:25, Paterson, Kenny wrote: > The fact that the small group who run OpenSSH has adopted a couple of > schemes based on a particular curve does not necessarily make that > curve the right choice for TLS. We provisionally allocated a code point for SSH use of Ed25519 to help with interop for their current running code. I'm AD sponsoring the draft for that [1] and awaiting a few changes from the author as a result of the IETF LC. A few of those comments made the point that the hash input format was not defined in the draft. I'm not sure if SM (the author) will be able to fix all that now, which could raise the possibility that we'll need another code-point when we have a standard format for representing Ed25519 public keys as input to the hash function here. But that's ok and none of IMO it impinges on the ask from TLS, nor on how CFRG should process that, except that if Ed25519 is one of the things CFRG do recommend, then it'd be nice if you could check whether or not the preferred and current SSH s/w public key formats are or are not commensurate. If they are, that's fine. If not, then we can allocate a new code point, which is also easy. So bottom line is there's no problem here I think. Cheers, S. [1] https://datatracker.ietf.org/doc/draft-moonesamy-sshfp-ed25519/ From nobody Sun Jul 27 12:24:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECCB1A010A for ; Sun, 27 Jul 2014 12:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LS1zrpSSR4LD for ; Sun, 27 Jul 2014 12:23:59 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EC6B1A00C2 for ; Sun, 27 Jul 2014 12:23:59 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id c41so4252905yho.26 for ; Sun, 27 Jul 2014 12:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=T8UYV/aBjkG/RHym4eBdsVyp3s/oeGK5LrTVUotDISw=; b=kT//FZoTgY17M9aqt+1y/ObW8HqbcWfcy/ai3REEQxLqXKCpWlJ+gJ21N56d8Pu9wE uE/jym0AIIIZ70zR3+gs0diVWaTWDs1DGpJKkWjTTp9cznFDh2+NjChO6PWDMWuPerzb eFqghuaNHLzffPWXfR6nWtjbN/IMub4h2oHqaKp57TDjf1NoNqLs8lESmJlslqsHhJva W88URmm1WovfebMbLeDMTtGOPFce3ALNynW0Pq1Gb037W7iHxd/SxK4s0sZ7sMSMsi3+ d7xPSlx2rwUgYFzOcYiElHWoR04uB60XnWa8fzyaITREu49oiVSoCHoyVIxYIG6syqz+ eDgw== MIME-Version: 1.0 X-Received: by 10.236.25.105 with SMTP id y69mr44829808yhy.33.1406489038458; Sun, 27 Jul 2014 12:23:58 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Sun, 27 Jul 2014 12:23:58 -0700 (PDT) In-Reply-To: References: Date: Sun, 27 Jul 2014 12:23:58 -0700 Message-ID: From: Watson Ladd To: "Paterson, Kenny" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/f-MvwP33rkFSS-fLhi3c1uen0Pc Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] Unwarrented change to point formats X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jul 2014 19:24:01 -0000 On Sun, Jul 27, 2014 at 11:25 AM, Paterson, Kenny wrote: > Watson, > > There was certainly support for Curve25519 at the CFRG interim phone conf= erence, from my reading of the transcript. > > I don't think the reasons for the TLS WG to ask for our input are nebulou= s, as you put it. I'd say they were taking a responsible approach, charging= us as experts to explore the alternatives carefully and make recommendatio= ns. This choice will affect the future security of TLS for years - or decad= es - to come. So we have to get it right. No one has indicated any weakness in any of the options: to a first-order approximation the choice will not impact security. (There is a second-order effect where the performance of 512-x vs 448-Goldilocks will influence choices about which security level to use, but it's second order, and I think we're sensitive enough to performance to minimize it) At the 128 level there is really nothing to get excited about. We're going to get it right: we can't get it wrong. (Assuming we've checked the curves independently) At the higher security levels the debate become slightly more interesting: we need E-521 as it's the most efficient curve above 2^512 (I'm ignoring the constant on Pollard rho, which everyone seems to do nowadays). The question becomes Ed448 vs Curve41417, where whichever is faster wins out. (Or the NUMS curve of intermediate size). (There is one question of point format: for odd reasons people seem to think ECDH and ECDSA keys should be interchangeable, and so want twisted Edwards everywhere. But we don't know anything about ECDSA that would let us do the analysis to say that is okay!) > > That request to us does not mean anyone is ignoring existing drafts, as y= ou write. I am also not aware of this IETF-wide requirement that you mentio= n. I believe it's a "nice to have", but not a hard requirement. Can you poi= nt to something more solid that is demonstrably a consensus view? I may have read too much into emails indicating possible wider adoption. > > You will note from my previous emails summarising the meeting in Toronto = that backwards compatibility with the existing wire format is regarded as b= eing desirable but not essential by the TLS WG leadership. If it can be don= e, it will make adoption easier; if not, we can change it, but it will need= some careful drafting to make sure it's crystal clear. This is (partially a) nonissue: RFC 4492 defines points as opaque bytevectors, and provides a set of point formats to describe their formating, so there is no formatting requirement on the point. There is one for signatures, but as we are not introducing new signatures we don't need to worry about it. > > The fact that the small group who run OpenSSH has adopted a couple of sch= emes based on a particular curve does not necessarily make that curve the r= ight choice for TLS. I also don't regard that as wide adoption, as you put = it. I'm not aware of a public, requirements-driven process behind their cho= ice. That's what we are attempting here. When is the last time you used SSH and it wasn't OpenSSH? Furthermore, they are not alone: most public greenfield crypto projects I have seen use Curve25519 or variants such as Curve41417. On what criteria can we possibly pick a curve? All the criteria we've mentioned are met by both sides. It will come down to narrow performance differences, which turns into a compiler tickling competition. (Automatic compiler ticklers are useful here). Maybe when we start measuring implementations there will be a clear set of choices, but I predict we will end up basically flipping a coin: so much for requirements-driven! Sincerely, Watson Ladd > > Your continued inputs to the process are most welcome. > > Regards > > Kenny > >> On 26 Jul 2014, at 18:59, "Watson Ladd" wrote: >> >> Dear all, >> Curve25519 was a draft. Curve25519 came back with good reviews from >> the CFRG. End of story? No: the TLS WG leadership has decided to ask >> for the choice of curves, on nebulous criteria, ignoring existing >> drafts, on the basis that the curves must be applicable "IETF wide". >> >> I don't see the reason for this, especially given that OpenSSH has >> implemented and deployed Curve25519 and Ed25519, complete with >> Montgomery form on the wire. Arguing that we need twisted Edwards >> point formats everywhere for consistency with existing libraries >> ignores what has already been deployed and widely adopted. >> >> Sincerely, >> Watson Ladd >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sun Jul 27 13:27:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2D51A0242 for ; Sun, 27 Jul 2014 13:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYjY5D-n608O for ; Sun, 27 Jul 2014 13:27:14 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8AA1A01D9 for ; Sun, 27 Jul 2014 13:27:13 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id n3so3391481wiv.5 for ; Sun, 27 Jul 2014 13:27:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XlmZlu4kgD9eyimWgxiaXBVB4SY1ryNqv/kVESNtMis=; b=iaaWMu2aavf+6tg9kicGIJ5Ieiv/1dAUvVFm+6viMYSwZlfthSfIbCECU/SylQCsC/ P285VeerZs+jRF+x8BV4DdczlO9txDWY7BS5KalR0DCQJeTIDvueXQBIGOmk131lle8C GCzD0FOCDetn90Al7LlUs3/TPzW6ti2bJExV6gWeyrIJl1kSzAl1WJWkcW8NOFHWy5LX y1ByfpEzIKBozFIijZkGMRWagQXdhXt/wAp6dQvwaJ/MnszNUitI4BHN+Pp5CznCwag4 uL4jmWlaFa+1o+CDanKzaXq07hKak1hP69ccYjjxXjBkl4ZLA9UT2jI79910lmFJSq/e 3d1A== X-Gm-Message-State: ALoCoQnLE/hPWKSLq0smMgZsROE6Gw3ymEkC7Ldsc2nbIuR3qyPahyOc7lW916ouPXzztpN8FIEH X-Received: by 10.180.86.225 with SMTP id s1mr23773693wiz.36.1406492832417; Sun, 27 Jul 2014 13:27:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Sun, 27 Jul 2014 13:26:32 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: From: Eric Rescorla Date: Sun, 27 Jul 2014 13:26:32 -0700 Message-ID: To: "Paterson, Kenny" Content-Type: multipart/alternative; boundary=f46d04428610a7e8ae04ff32a141 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eIAFC4zInowBCfmBNMNnyMuwKlk Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] Unwarrented change to point formats X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jul 2014 20:27:16 -0000 --f46d04428610a7e8ae04ff32a141 Content-Type: text/plain; charset=UTF-8 On Sun, Jul 27, 2014 at 11:25 AM, Paterson, Kenny wrote: > Watson, > > There was certainly support for Curve25519 at the CFRG interim phone > conference, from my reading of the transcript. > > I don't think the reasons for the TLS WG to ask for our input are > nebulous, as you put it. I'd say they were taking a responsible approach, > charging us as experts to explore the alternatives carefully and make > recommendations. This choice will affect the future security of TLS for > years - or decades - to come. So we have to get it right. > This reflects my understanding as well. > That request to us does not mean anyone is ignoring existing drafts, as > you write. I am also not aware of this IETF-wide requirement that you > mention. I believe it's a "nice to have", but not a hard requirement. Speaking only for myself, I don't think there's anything particularly mysterious here. The TLS WG is not chartered to do this kind of analysis so we've turned to the CFRG. It would clearly be most efficient if the IETF had a common set of cryptographic primitives where possible. It's true that TLS was the first WG to try to write down a specific request, but it seems likely that our needs are mostly common with other protocols. To take a specific set of cases. TLS has three major uses for public key crypto of this type: - Key establishment - Digital signatures over handshake messages (ServerKeyExchange, CertificateVerify, etc.) - Digital signatures over certificates. It seems likely that key establishment shares common requirements for multiple protocols. Similarly, it would be quite convenient if the signatures used in TLS were the same as those used for the certificates used for TLS, even though the latter are not defined in TLS. So, when I say an IETF-wide set of recommendations that's the kind of thing I mean. I wasn't aware that any of this was particularly controversial. -Ekr --f46d04428610a7e8ae04ff32a141 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sun, Jul 27, 2014 at 11:25 AM, Paterson, Kenny <Kenny.P= aterson@rhul.ac.uk> wrote:
Watson,

There was certainly support for Curve25519 at the CFRG interim phone confer= ence, from my reading of the transcript.

I don't think the reasons for the TLS WG to ask for our input are nebul= ous, as you put it. I'd say they were taking a responsible approach, ch= arging us as experts to explore the alternatives carefully and make recomme= ndations. This choice will affect the future security of TLS for years - or= decades - to come. So we have to get it right.

This reflects my understanding as well.

=C2=A0
That request to us does not mean anyone is ignoring existing drafts, as you= write. I am also not aware of this IETF-wide requirement that you mention.= I believe it's a "nice to have", but not a hard requirement.=

Speaking only for myself, I don't think there&= #39;s anything particularly
mysterious here. The TLS WG is not ch= artered to do this kind of analysis
so we've turned to the CF= RG. It would clearly be most efficient if the IETF
had a common set of cryptographic primitives where possible. It's = true
that TLS was the first WG to try to write down a specific re= quest, but it
seems likely that our needs are mostly common with = other protocols.

To take a specific set of cases. TLS has three major us= es for public key
crypto of this type:

-= Key establishment
- Digital signatures over handshake messages (= ServerKeyExchange,
=C2=A0 CertificateVerify, etc.)
- Digital signatures over ce= rtificates.

It seems likely that key establishment= shares common requirements for
multiple protocols. Similarly, it= would be quite convenient if the signatures
used in TLS were the same as those used for the certificates used for = TLS,
even though the latter are not defined in TLS. So, when I sa= y an IETF-wide
set of recommendations that's the kind of thin= g I mean.

I wasn't aware that any of this was particularly co= ntroversial.

-Ekr


=C2= =A0
--f46d04428610a7e8ae04ff32a141-- From nobody Sun Jul 27 13:40:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1991A0336 for ; Sun, 27 Jul 2014 13:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHKhlFQltpl9 for ; Sun, 27 Jul 2014 13:39:56 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DEAB1A02DF for ; Sun, 27 Jul 2014 13:39:56 -0700 (PDT) Received: by mail-yk0-f175.google.com with SMTP id q200so4161275ykb.34 for ; Sun, 27 Jul 2014 13:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uj/qtjEfpmVV17v2ZkjSKi0/IJjb0v9WA7Sq1KvOy0k=; b=uVTAKEwGhJLXbCJlC0P0cZZ5fv0A9XLRlbWcuTMw850JTM6VkL70xAKkC4T/eBKS4y 4METsbIQUi9KFUX3SkRaKBLW8QQFOtMf/75yNcvFYDNs2n4FRn/i6xUUA6UvL6dy2fn/ Gmq13YA7jW4yqtnRi8PhtNnB+epFO999X2EZeGRtUgBni3KKYy5tz41CTv5pTc124hJh 9DdsQoO8P67zb0208oLXHvu8La3FsdP8plZRfJpk01Z3ycSG5rxt1shTGGwxnsdyxiZB dmxlbRMH4M96N00OWhFGBSzmUKkxAX4dhf9xk0lAW950GRpm45M0qEeLG49zlJMTrkSg GEKA== MIME-Version: 1.0 X-Received: by 10.236.85.208 with SMTP id u56mr45316861yhe.48.1406493595862; Sun, 27 Jul 2014 13:39:55 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Sun, 27 Jul 2014 13:39:55 -0700 (PDT) In-Reply-To: References: Date: Sun, 27 Jul 2014 13:39:55 -0700 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FWoRIFwj2tCKeLlboJwTDgfMB3A Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] Unwarrented change to point formats X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jul 2014 20:39:58 -0000 On Sun, Jul 27, 2014 at 1:26 PM, Eric Rescorla wrote: > > > > On Sun, Jul 27, 2014 at 11:25 AM, Paterson, Kenny > wrote: >> >> Watson, >> >> There was certainly support for Curve25519 at the CFRG interim phone >> conference, from my reading of the transcript. >> >> I don't think the reasons for the TLS WG to ask for our input are >> nebulous, as you put it. I'd say they were taking a responsible approach, >> charging us as experts to explore the alternatives carefully and make >> recommendations. This choice will affect the future security of TLS for >> years - or decades - to come. So we have to get it right. > > > This reflects my understanding as well. > > >> >> That request to us does not mean anyone is ignoring existing drafts, as >> you write. I am also not aware of this IETF-wide requirement that you >> mention. I believe it's a "nice to have", but not a hard requirement. > > > Speaking only for myself, I don't think there's anything particularly > mysterious here. The TLS WG is not chartered to do this kind of analysis > so we've turned to the CFRG. It would clearly be most efficient if the IETF > had a common set of cryptographic primitives where possible. It's true > that TLS was the first WG to try to write down a specific request, but it > seems likely that our needs are mostly common with other protocols. This kind of analysis is much easier than the kind the TLS WG has to engage in to ensure no more surprises. In particular since a lot of the issues have to do with performance and uptake, it's not clear the CFRG knows more about them then the TLS WG. > > To take a specific set of cases. TLS has three major uses for public key > crypto of this type: > > - Key establishment > - Digital signatures over handshake messages (ServerKeyExchange, > CertificateVerify, etc.) > - Digital signatures over certificates. > > It seems likely that key establishment shares common requirements for > multiple protocols. Similarly, it would be quite convenient if the > signatures > used in TLS were the same as those used for the certificates used for TLS, > even though the latter are not defined in TLS. So, when I say an IETF-wide > set of recommendations that's the kind of thing I mean. > > I wasn't aware that any of this was particularly controversial. You had a draft in hand, got a reply that "yeah, looks good", and then went back to ask for a completely different design process, for reasons never discussed. It's the second round that's confusing me. What was wrong with the curve25519 draft? Sincerely, Watson Ladd > > -Ekr > > > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sun Jul 27 14:37:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1021A0368 for ; Sun, 27 Jul 2014 14:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2LaVZwMr5yM for ; Sun, 27 Jul 2014 14:37:50 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76E4C1A031A for ; Sun, 27 Jul 2014 14:37:50 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id f8so3416227wiw.1 for ; Sun, 27 Jul 2014 14:37:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=iSMpBBtigSRmJ4yXOvwywgsThw4a9x8F7vuOAoVxD0o=; b=RDFtpUsaaLo8TY+VhnwxgYLiIBf/PbZdOCfyqSxnwbQlMFzEbPYTTY1ClLaVOs4cL0 RMtYFael8cskez/WFwhT3wQY6Zmq572QuNpBeUt8cSfy/NqH3kWI7tTkoWwiVleYrfnu RcTIHfX7oVRY/ElRtfGQ0pSV1eCbNiwS29FUphpyL/NmGAbn+eNKnPqFrFup9ZT2DZhm 8ynSly/mHEM7m7prt81N9I2DtaKL8XrZ58m7yetY5OiJ9hTjgMcTuWvd+9SLxq9zxVw3 1hFrTiGV3mv3O6r16GY4+TTRJy957Ne2udyBpQxMeqE0OocsseENF9Oyt8M9F5tQuNLB F+tw== X-Gm-Message-State: ALoCoQkNDdpTPrbSlvZF0VxMC4O2L005VNZujAKPIbuubaXyFRPSyvTU8D7xJmgl3F3NoKzIeCyr X-Received: by 10.180.39.34 with SMTP id m2mr23580561wik.80.1406497069104; Sun, 27 Jul 2014 14:37:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Sun, 27 Jul 2014 14:37:09 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: From: Eric Rescorla Date: Sun, 27 Jul 2014 14:37:09 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=001a1134b5b82e9de804ff339e97 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_GQNceJK6EhZ-IP9B_yUq6W-T5o Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] Unwarrented change to point formats X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jul 2014 21:37:52 -0000 --001a1134b5b82e9de804ff339e97 Content-Type: text/plain; charset=UTF-8 On Sun, Jul 27, 2014 at 1:39 PM, Watson Ladd wrote: > On Sun, Jul 27, 2014 at 1:26 PM, Eric Rescorla wrote: > > > To take a specific set of cases. TLS has three major uses for public key > > crypto of this type: > > > > - Key establishment > > - Digital signatures over handshake messages (ServerKeyExchange, > > CertificateVerify, etc.) > > - Digital signatures over certificates. > > > > It seems likely that key establishment shares common requirements for > > multiple protocols. Similarly, it would be quite convenient if the > > signatures > > used in TLS were the same as those used for the certificates used for > TLS, > > even though the latter are not defined in TLS. So, when I say an > IETF-wide > > set of recommendations that's the kind of thing I mean. > > > > I wasn't aware that any of this was particularly controversial. > > You had a draft in hand, got a reply that "yeah, looks good", and then > went back to ask for > a completely different design process, for reasons never discussed. > It's the second round > that's confusing me. > This does not match my understanding of the history. Rather, here's my memory: 1. We asked the CFRG for a recommendation. 2. The CFRG held an interim discussion where a lot of good things were said about Curve25519 but the CFRG never made a recommendation to the TLS WG, but instead said it would come back and make a recommendation. 3. The TLS Chairs sent the CFRG chairs a written request to make such a recommendation (my memory is that they actually asked us to write something down, but I don't immediately see it in my mail.) Which brings us to the current process being run in CFRG. -Ekr --001a1134b5b82e9de804ff339e97 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Jul 27, 2014 at 1:39 PM, Watson Ladd <watsonbladd@gmail.com>= ; wrote:
On Sun, Jul 27, 2014 at 1:26= PM, Eric Rescorla <ekr@rtfm.com>= wrote:
=C2=A0
> To take a specific set of cases. TLS has three major uses for public= key
> crypto of this type:
>
> - Key establishment
> - Digital signatures over handshake messages (ServerKeyExchange,
> =C2=A0 CertificateVerify, etc.)
> - Digital signatures over certificates.
>
> It seems likely that key establishment shares common requirements for<= br> > multiple protocols. Similarly, it would be quite convenient if the
> signatures
> used in TLS were the same as those used for the certificates used for = TLS,
> even though the latter are not defined in TLS. So, when I say an IETF-= wide
> set of recommendations that's the kind of thing I mean.
>
> I wasn't aware that any of this was particularly controversial.
You had a draft in hand, got a reply that "yeah, looks good"= ;, and then
went back to ask for
a completely different design process, for reasons never discussed.
It's the second round
that's confusing me.

This does not = match my understanding of the history.

Rather, her= e's my memory:

1. We asked the CFRG for a reco= mmendation.

2. The CFRG held an interim discussion where a lot of g= ood things
were said about Curve25519 but the CFRG never made a r= ecommendation
to the TLS WG, but instead said it would come back = and make
a recommendation.

3. The TLS Chairs sent the = CFRG chairs a written request to make
such a recommendation (my m= emory is that they actually asked us
to write something down, but= I don't immediately see it in my mail.)

Which brings us to the current process being run in CFR= G.

-Ekr


<= /div>
--001a1134b5b82e9de804ff339e97-- From nobody Sun Jul 27 15:33:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCA31A0439 for ; Sun, 27 Jul 2014 15:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POW3P2ZYA7sa for ; Sun, 27 Jul 2014 15:33:16 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798ED1A044D for ; Sun, 27 Jul 2014 15:33:15 -0700 (PDT) Received: by mail-yk0-f179.google.com with SMTP id 142so4232768ykq.38 for ; Sun, 27 Jul 2014 15:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vBh6iBeDgFgUBCPjQsRswp8fBVq0yJ+ou2ogJYpgINA=; b=kr3vVx4WYsYA4vZGxz+DMsK/4bvwfzeago5Vu6/iD4Skg/XdfHa8a1QDb8p6L2hyzd 8pLJ3UtZ1b2krHy90FWUBBxO+ehzZK6I4KIl1VU7ox2RVp+1Kymwc4yDiogfhguem/yS tmAlGN/Ufhcq9aC9e3bTDqKcrej4Fx4oxrx0Xf9J4RweErR9sPfckCfHCpw8bH+81wM4 W8B+U16QWNRgxAM2Wi/3GG8DAHNKU4LPhS930rlgtA0Dq1IRvaU0Ahp+qKVbzkvNeOLX S5XU2SV1T8G2ejQ3D0Gm1g6sgDFZ4xeOEyBKX+6EUxV7mGgSHFceXXc72hC5XS601/M7 JyBQ== MIME-Version: 1.0 X-Received: by 10.236.51.228 with SMTP id b64mr46073920yhc.93.1406500394726; Sun, 27 Jul 2014 15:33:14 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Sun, 27 Jul 2014 15:33:14 -0700 (PDT) In-Reply-To: References: Date: Sun, 27 Jul 2014 15:33:14 -0700 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dN81aFcGTdlm7ugWQ0rrfq0FsJA Cc: "cfrg@irtf.org" , "tls@ietf.org" Subject: Re: [TLS] Unwarrented change to point formats X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Jul 2014 22:33:17 -0000 On Sun, Jul 27, 2014 at 2:37 PM, Eric Rescorla wrote: > On Sun, Jul 27, 2014 at 1:39 PM, Watson Ladd wrote: >> >> On Sun, Jul 27, 2014 at 1:26 PM, Eric Rescorla wrote: > > >> >> > To take a specific set of cases. TLS has three major uses for public key >> > crypto of this type: >> > >> > - Key establishment >> > - Digital signatures over handshake messages (ServerKeyExchange, >> > CertificateVerify, etc.) >> > - Digital signatures over certificates. >> > >> > It seems likely that key establishment shares common requirements for >> > multiple protocols. Similarly, it would be quite convenient if the >> > signatures >> > used in TLS were the same as those used for the certificates used for >> > TLS, >> > even though the latter are not defined in TLS. So, when I say an >> > IETF-wide >> > set of recommendations that's the kind of thing I mean. >> > >> > I wasn't aware that any of this was particularly controversial. >> >> You had a draft in hand, got a reply that "yeah, looks good", and then >> went back to ask for >> a completely different design process, for reasons never discussed. >> It's the second round >> that's confusing me. > > > This does not match my understanding of the history. > > Rather, here's my memory: > > 1. We asked the CFRG for a recommendation. > > 2. The CFRG held an interim discussion where a lot of good things > were said about Curve25519 but the CFRG never made a recommendation > to the TLS WG, but instead said it would come back and make > a recommendation. > > 3. The TLS Chairs sent the CFRG chairs a written request to make > such a recommendation (my memory is that they actually asked us > to write something down, but I don't immediately see it in my mail.) > > Which brings us to the current process being run in CFRG. And that's exactly the problem: instead of asking "is this proposed curve secure" or "are the arguments in favor of Curve25519 largely correct" you want CFRG to evaluate things it really can't. How do we know if uptake in TLS will be slowed by being non-Weierstrass? How do we evaluate if implementors want to implement Montgomery and twisted Edwards arithmetic vs. just one? I don't see why this couldn't have ended in March with "well, no security concerns were identified, so Curve25519 will be in TLS". Sincerely, Watson Ladd > > -Ekr > > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sun Jul 27 21:08:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7231A0072 for ; Sun, 27 Jul 2014 21:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDveEdukCsa5 for ; Sun, 27 Jul 2014 21:08:41 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 751651A0055 for ; Sun, 27 Jul 2014 21:08:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1406520522; x=1438056522; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=QBlAthxDB80DNMBAbzEJptvlr5MbMKcFucpm7XbHbOY=; b=E9JcExQ3nC1V14fZjPX46aF5AODfGyuj4yX+CNRQCsnoBettJ+xu5Q/P I3fu7qWltIUytRcuinUwo0RWBTDiRwU7jki9qwcHZWXEHeyu3GiXJ2Hul 3ESFTCvrUHhgnHYZusv3E8mFJTOx0wPmimviVpwTw8JW+AMaSjhK6r381 s=; X-IronPort-AV: E=Sophos;i="5.01,746,1399982400"; d="scan'208";a="265987150" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 28 Jul 2014 16:08:36 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.247]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Mon, 28 Jul 2014 16:08:35 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] Encryption of TLS 1.3 content type Thread-Index: Ac+qGZpc4i+lw1JpT8OTgodQhMzdfw== Date: Mon, 28 Jul 2014 04:08:35 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738EFB1969@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Io-KuN9otpcsY7aZhyg1Y2WFxcI Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2014 04:08:47 -0000 Yoav Nir writes:=0A= =0A= >I believe that changing the 5-byte record header will cause us trouble. = =0A= >Passive IDS/IPS devices follow TLS streams to detect certain attacks. They= =0A= >will cut connections. =0A= =0A= Is it really up to the TLS WG to break (or at least constrain) our designs= =0A= in order to accomodate broken middleboxes? They're not going to understand= =0A= any of TLS 1.3 anyway and will need to be updated when it comes along, so w= hy=0A= keep this legacy header just for them?=0A= =0A= Peter.= From nobody Mon Jul 28 00:41:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC971A017C for ; Mon, 28 Jul 2014 00:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9Pjn4GYdY-L for ; Mon, 28 Jul 2014 00:41:10 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4099C1A023F for ; Mon, 28 Jul 2014 00:41:09 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id bs8so3898000wib.3 for ; Mon, 28 Jul 2014 00:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PbKusKfDTZFM3AhJ9YGZK2LhVQXm8FdZQzM/kilOv+w=; b=A75cdf7bcVqg8boNs1QURMrWM1x1PetiZMEgxNvN1F5r7m4AGWHEdZYW28nw82D6y7 yRlx6MU+qA1MXP00TQBm6lxBypiM0OycPibgE3b8KicvS6B4+FzBzTdMo98v//kSXyLs 81GfWF2cbwwh3BEErb+q58e27GDEQiRS1sEtRkVWZj7xtchymcws4pIlRs9QM/C/Lk17 KNRPEPcO72GYFCpJwMNI/3z4XxOKLkDmj4OpgxyKmPiEsypAVI++cKCy0ECKh3a+cE8P QoTyDEgvCCVUtzTB50Y95vom1tu3dX491DC48rWypH4mP02agXCNBPAmj70bCPG8L9KI uJqQ== X-Received: by 10.180.149.161 with SMTP id ub1mr28390550wib.32.1406533267838; Mon, 28 Jul 2014 00:41:07 -0700 (PDT) Received: from [172.24.248.227] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id wu6sm47449118wjb.46.2014.07.28.00.41.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 00:41:07 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738EFB1969@uxcn10-5.UoA.auckland.ac.nz> Date: Mon, 28 Jul 2014 10:40:03 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <673161E8-BD26-47D5-B27B-1C6430DCD0BA@gmail.com> References: <9A043F3CF02CD34C8E74AC1594475C738EFB1969@uxcn10-5.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LhWzqaQWaZ51O5xSNaN71RQp4rI Cc: "" Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2014 07:41:12 -0000 On Jul 28, 2014, at 7:08 AM, Peter Gutmann = wrote: > Yoav Nir writes: >=20 >> I believe that changing the 5-byte record header will cause us = trouble.=20 >> Passive IDS/IPS devices follow TLS streams to detect certain attacks. = They=20 >> will cut connections.=20 >=20 > Is it really up to the TLS WG to break (or at least constrain) our = designs > in order to accomodate broken middleboxes? They're not going to = understand > any of TLS 1.3 anyway and will need to be updated when it comes along, = so why > keep this legacy header just for them? It is up to the TLS WG to design something that works on the Internet. = And the Internet is full of middleboxes. When they were updated to tolerate TLS 1.1/1.2, some may have version = tolerance for forward versions as long as the first byte in 0x03. In = looking for abnormally long or short records or for a malformed stream, = they may drop any new TLS 1.3 header that doesn=92t look like a TLS = header. That kind of thing made WebSockets far less viable than people = hoped. And these middleboxes are not always updated in a timely manner. Yoav From nobody Mon Jul 28 01:55:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85FE1A0311 for ; Mon, 28 Jul 2014 01:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.603 X-Spam-Level: X-Spam-Status: No, score=-6.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7GN3Eb3HkGw for ; Mon, 28 Jul 2014 01:55:56 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E9C01A02FF for ; Mon, 28 Jul 2014 01:55:56 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6S8trGZ021936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 28 Jul 2014 04:55:53 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6S8tpEj008686 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2014 04:55:52 -0400 Message-ID: <1406537753.2413.12.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Colm =?ISO-8859-1?Q?MacC=E1rthaigh?= Date: Mon, 28 Jul 2014 10:55:53 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MPovzgo1cTeNPo_hS0eRW2GRJzI Cc: "" Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2014 08:55:57 -0000 On Sat, 2014-07-26 at 10:59 -0700, Colm MacCárthaigh wrote: > On Sat, Jul 26, 2014 at 10:43 AM, Watson Ladd wrote: > > This is a change with no rationale: the content type leaks extremely > > limited information. It complicates implementations that wish to keep > > a high degree of codepath similarity between TLS 1.2 and TLS 1.3. > Leaking alert messages has been a recurring theme common to several > attacks; hindering a MITM's ability to discern alert messages seems > like a rational rationale. Are there any pointers to these attacks? Will these attacks be countered with such a change? I believe not as alert messages consist of only two bytes and will be distinct from any other higher protocol messages transferred by the TLS record protocol. Unless TLS 1.3 intended to include a length hiding mechanism I see this change as unnecessary and I agree with Watson on that. If we cannot avoid changes to TLS 1.3 charter, I believe that any new proposal comes with a concrete case for it and associated costs of implementing vs not-implementing. The initial agreement was for a small revision to TLS (even though I didn't agree on that), and that is now used as a vehicle to push unrelated to the charter major changes with no planning whatsoever. I'm afraid in the end the result will be an ISO-type of protocol. regards, Nikos From nobody Mon Jul 28 03:52:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E82B1A020A for ; Mon, 28 Jul 2014 03:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leBGIUUA5CVF for ; Mon, 28 Jul 2014 03:52:30 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2CA1A03EF for ; Mon, 28 Jul 2014 03:52:30 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so7265787wgg.16 for ; Mon, 28 Jul 2014 03:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UfR66JqOqlowVapzyizSKnMLsDxSx2Ywp2ay3/U6o2s=; b=vGYSxKFNBRvbY9oMw+KFpcwAk6Ph2xWb+4XoVitOocsMk9ygekoWX7CpMCBWJR1BBl Dae+RgHsza+L5gLgKXuPeSPLMeyWo+iRh2JIr9RGn3u9dB2AsKafPs0frbeFPLdUHq/s jGiRh+CINVJ8W1+PnAsUUdEzWn6JIZMUpG7doc5BGHIwlYeKGmcPZlLUJuobswjzYk1Y 8OSFTgIWuj9hhiDV7x6SwopORmoxY30GQZ7aa09Woqi5xheb1miNRiPsWNzK+7fjjre/ vjCuz34hqthaH8X9uKJtG+8yTMZcXLAu0vt9bUlC4hh6yGoEp34QL+ceTeKmln1sGpOW kZVg== X-Received: by 10.180.35.36 with SMTP id e4mr30843312wij.12.1406544746739; Mon, 28 Jul 2014 03:52:26 -0700 (PDT) Received: from [172.24.248.227] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id u7sm2134918wif.3.2014.07.28.03.52.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 03:52:26 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <1406537753.2413.12.camel@dhcp-2-127.brq.redhat.com> Date: Mon, 28 Jul 2014 13:52:22 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1406537753.2413.12.camel@dhcp-2-127.brq.redhat.com> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NtPHX57pC2SM1Nm7wKhHzo_z3eY Cc: "" Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2014 10:52:35 -0000 On Jul 28, 2014, at 11:55 AM, Nikos Mavrogiannopoulos = wrote: > On Sat, 2014-07-26 at 10:59 -0700, Colm MacC=E1rthaigh wrote: >> On Sat, Jul 26, 2014 at 10:43 AM, Watson Ladd > wrote: >>> This is a change with no rationale: the content type leaks extremely >>> limited information. It complicates implementations that wish to > keep >>> a high degree of codepath similarity between TLS 1.2 and TLS 1.3. >> Leaking alert messages has been a recurring theme common to several >> attacks; hindering a MITM's ability to discern alert messages seems >> like a rational rationale. >=20 > Are there any pointers to these attacks? Will these attacks be = countered > with such a change? I believe not as alert messages consist of only = two > bytes and will be distinct from any other higher protocol messages > transferred by the TLS record protocol. Unless TLS 1.3 intended to > include a length hiding mechanism I see this change as unnecessary and = I > agree with Watson on that. While no definite decisions were made, there was a positive response to = the idea of allowing arbitrary length padding to the plaintext in all = encrypted records, which can be used to hide alert messages.=20 Of course, non-fatal alerts are (1) rare, and (2) not always treated as = such, so it=92s easy to spot the alert record, because it=92s the one = before the FIN or RST. In DTLS alerts are mostly non-fatal, so it makes = more sense. So on balance, +1. > If we cannot avoid changes to TLS 1.3 charter, I believe that any new > proposal comes with a concrete case for it and associated costs of > implementing vs not-implementing. The initial agreement was for a = small > revision to TLS (even though I didn't agree on that), and that is now > used as a vehicle to push unrelated to the charter major changes with = no > planning whatsoever.=20 Our charter does say =93Develop a mode that encrypts as much of the = handshake as is possible=94 Yoav From nobody Mon Jul 28 06:58:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8161B27F9 for ; Mon, 28 Jul 2014 06:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJYJq6YrQ_dW for ; Mon, 28 Jul 2014 06:57:55 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3B21A0452 for ; Mon, 28 Jul 2014 06:57:55 -0700 (PDT) Received: from [10.70.10.76] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id A2852F984 for ; Mon, 28 Jul 2014 09:57:52 -0400 (EDT) Message-ID: <53D656D3.5050307@fifthhorseman.net> Date: Mon, 28 Jul 2014 09:57:39 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0 MIME-Version: 1.0 To: "" References: <1406537753.2413.12.camel@dhcp-2-127.brq.redhat.com> In-Reply-To: <1406537753.2413.12.camel@dhcp-2-127.brq.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fLlD9xjjqKreUkBCRMo9qI1ukDv5LhUsp" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IxNikQDxyMigzH9kYJHS0jn4Yrw Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2014 13:58:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fLlD9xjjqKreUkBCRMo9qI1ukDv5LhUsp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/28/2014 04:55 AM, Nikos Mavrogiannopoulos wrote: > Unless TLS 1.3 intended to include a length hiding mechanism > I see this change as unnecessary and I agree with Watson on that. One of the motivations to support this change is due to the possibility of length-hiding within TLS (which might be indicated by a new content-type), as well as leaving the door open to other future content types that might or might not be sensitive. It was a design error to ever leave this information in the clear in the first place, afaict. We should fix it. If we have to throw a dummy byte (or two, if we need to include the version) per (D)TLS record to appease middleboxes, we can do that, but that should be strictly for the sake of working around the ossified network stack. --dkg --fLlD9xjjqKreUkBCRMo9qI1ukDv5LhUsp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJT1lbTXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcwnMQAN+VISG0BwWW5z1xNN5zVo0Q u6u3LIPZcZ4R7X/4QASADSnp5Pf2Dol85ZhLrUCJumURlQ0udL4l+11AToCDnzTS o+NN+Yu4mVWUP1DDvSwUyXLC0qEMMuj0GuXilBlF5TSMrE43eQBpJsLLvvce3feo RYOikaFN2YeYy0FCKKZujqWg2J7tK/HBhTuRLxUC6QCypmomOmfiOIakB2YeJIhE 6sF8TqvoWUnNIhrp4gTR/brlvvEJFdnLAh16TVZkdlZd6MXeYwELgJ4KHc0Weo5H RKISIAIUktEdLN1uR2uL49dG5gdfzsFd4ZE6XvuJf3WETrijj9IDjai84ItZodi5 /nZYzejIY7cVsMCyDm3A7tVYcTik9bjNQG1cBs3591Akgq+ZoYmrx92Mg1j3dQoJ yTWuksqMc3kgT3yGSSczI9qe5i82vZMNz/L18/mwi9cfM/77zDd4y+BnNolRlwdW 71qmei1rYMadZf4fltynXZmDqDDaJKpgtwsMeeP7UCY9tKaMn1FRK3yKPYuL2Se6 WnWJFzmw/0vpwRfBcdb/MyqaQ6jK3mRyb7ihkP799C63iSBRjHSwKLOF1mSTJPA0 eNdk+g5sxvMFGqHLfhaXwK5oUT28RRfugbFVeuScnzDhsbLP9eVAt6nIUNnhGkrw BGezBblUeJAYRhAY98vV =lZTi -----END PGP SIGNATURE----- --fLlD9xjjqKreUkBCRMo9qI1ukDv5LhUsp-- From nobody Mon Jul 28 07:41:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3B61A0385 for ; Mon, 28 Jul 2014 07:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.252 X-Spam-Level: X-Spam-Status: No, score=-6.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Onfc3w8CZjKY for ; Mon, 28 Jul 2014 07:41:12 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E7A941A0292 for ; Mon, 28 Jul 2014 07:41:11 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s6SEdo9s021163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Jul 2014 16:39:50 +0200 (MEST) In-Reply-To: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Mon, 28 Jul 2014 16:39:50 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20140728143950.055491ADC9@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1xSVH0ZpdpmwkOme9X1VCqkc6t8 Cc: "" Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 14:41:13 -0000 I also object to the removal of the ContentInfo from the outer TLS record protocol. I'm not aware of the slightest rationale for this severe backwards incompatibility, that will not just break middle-boxes, but also applications that parse TLS records for the purpose of non-blocking operation. Colm MacC=E1rthaigh wrote: > > Leaking alert messages has been a recurring theme common to several > attacks; hindering a MITM's ability to discern alert messages seems > like a rational rationale. Which attacks do you have in mind? I'm actually not aware of any. The Bleichenbacher PKCS#1 decryption oracle happened during the cleartext phase (so this doesn't apply here), and while the CBC guessing happened in the encrypted phase, the attacker was in posession of the decryption key, could properly decrypt the alert, and use it to distinguish decryption failure from mac failure alerts. So in both situations, content hiding would not have had the slightest impact on these attacks. -Martin From nobody Mon Jul 28 07:54:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11151B285A for ; Mon, 28 Jul 2014 07:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mdFre2rLPqk for ; Mon, 28 Jul 2014 07:54:01 -0700 (PDT) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5211F1B2858 for ; Mon, 28 Jul 2014 07:54:01 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id j17so8945055oag.0 for ; Mon, 28 Jul 2014 07:54:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=emICU7JudqDgCAleBTeWAnCoXjAYnQ2Kr1888GbhLQM=; b=mSl+xn0jrS1hXFzg98Vcrbw7IFRKNDSxK5ocR1tDQPAUEUGp7bFN/S6kvS2XkfxK2u zrIC3OofKfd4CovuyK5KMi3jTRF2a+FFUEY4icefe+T3CxVhNPtQUDAt6FFjGBBDtQ4U P6tZwEs5lpI6LHWe0XTHXcOEwuJy+R3evtu5AmPK1E97iPVAqY1MmjqyIk6cpwbracna Iu8vRo8MegagNXuQYxBzx23htifWZFbzduGfugIwLud12q4m6au02MQ0gyqrBlsE7F5u 9zstMo/yXjIrTWLq+RYC7LCVG3nQqq+vdzvsQNmFzdGuht2Yh9gNTbZEnV7rCR65GFyo Kr3w== X-Gm-Message-State: ALoCoQnUWViz58vXpimKCPCWvnDipAmeJ7objAO3icXHCqV20cjHXjh5BjGUnf+ZwJgWUw5HG56z MIME-Version: 1.0 X-Received: by 10.60.62.234 with SMTP id b10mr6451786oes.3.1406559240667; Mon, 28 Jul 2014 07:54:00 -0700 (PDT) Received: by 10.76.10.198 with HTTP; Mon, 28 Jul 2014 07:54:00 -0700 (PDT) In-Reply-To: <1406537753.2413.12.camel@dhcp-2-127.brq.redhat.com> References: <1406537753.2413.12.camel@dhcp-2-127.brq.redhat.com> Date: Mon, 28 Jul 2014 07:54:00 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/P28iIFbv33_0_hEzM5QWxBWZgJw Cc: "" Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2014 14:54:02 -0000 On Mon, Jul 28, 2014 at 1:55 AM, Nikos Mavrogiannopoulos wrote: > Are there any pointers to these attacks? Will these attacks be countered > with such a change? I believe not as alert messages consist of only two > bytes and will be distinct from any other higher protocol messages > transferred by the TLS record protocol. This is not the case. Firstly, even with a stream cipher it doesn't distinguish the message from a 2 byte application data message. But most ciphers are block ciphers, and so the true length is fuzzed by about an order of magnitude. -- Colm From nobody Mon Jul 28 08:06:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CC41B2888 for ; Mon, 28 Jul 2014 08:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_Us5c1cyyuM for ; Mon, 28 Jul 2014 08:05:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360C01B2887 for ; Mon, 28 Jul 2014 08:05:55 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6SF5pna005920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 28 Jul 2014 11:05:52 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6SF5nIg014223 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2014 11:05:51 -0400 Message-ID: <1406559952.7750.14.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Daniel Kahn Gillmor Date: Mon, 28 Jul 2014 17:05:52 +0200 In-Reply-To: <53D656D3.5050307@fifthhorseman.net> References: <1406537753.2413.12.camel@dhcp-2-127.brq.redhat.com> <53D656D3.5050307@fifthhorseman.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GaJdPgSjMXsopnnpubG-BYYTPKY Cc: "" Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2014 15:06:00 -0000 On Mon, 2014-07-28 at 09:57 -0400, Daniel Kahn Gillmor wrote: > On 07/28/2014 04:55 AM, Nikos Mavrogiannopoulos wrote: > > Unless TLS 1.3 intended to include a length hiding mechanism > > I see this change as unnecessary and I agree with Watson on that. > One of the motivations to support this change is due to the possibility > of length-hiding within TLS (which might be indicated by a new > content-type), as well as leaving the door open to other future content > types that might or might not be sensitive. It was a design error to > ever leave this information in the clear in the first place, afaict. We > should fix it. I don't think so. The privacy concerns over the content type are minuscule(*) and the debugging information provided by them is priceless to a network engineer. (*): I understand the trend of encrypt as much as possible -indicated by the charter entry on handshake protocol and extended here to the record protocol-, but what is really the threat here? > If we have to throw a dummy byte (or two, if we need to include the > version) per (D)TLS record to appease middleboxes, we can do that, but > that should be strictly for the sake of working around the ossified > network stack. Such moves contribute to the complexity of TLS implementations and I don't see any immediate privacy enhancement here to justify that (note that TLS has different goals to TOR). Nevertheless, if we really need a TLS redesign to address new goals and requirements then let's just do that, name it TLS 2.0, gather all the requirements and design it from ground up, not with arbitrary un-coordinated actions during a maintenance release that has specific charter goals (and record layer modification was not in them). Or if that's not possible the interesting parties should proceed with a separate contribution that provides length hiding and content hiding if you consider that important. regards, Nikos From nobody Mon Jul 28 08:08:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D761B2899 for ; Mon, 28 Jul 2014 08:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kvXXMCtZwAk for ; Mon, 28 Jul 2014 08:08:36 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 740681B2866 for ; Mon, 28 Jul 2014 08:08:36 -0700 (PDT) Received: from [10.70.10.76] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id C9C27F984; Mon, 28 Jul 2014 11:08:33 -0400 (EDT) Message-ID: <53D66764.2040105@fifthhorseman.net> Date: Mon, 28 Jul 2014 11:08:20 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0 MIME-Version: 1.0 To: mrex@sap.com References: <20140728143950.055491ADC9@ld9781.wdf.sap.corp> In-Reply-To: <20140728143950.055491ADC9@ld9781.wdf.sap.corp> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="538W7jSUHokVixwoehCpd1SqOsVlUsaIK" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kn6bsbbL7qLy_AEOKzuyk2Rsf14 Cc: IETF TLS WG Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2014 15:08:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --538W7jSUHokVixwoehCpd1SqOsVlUsaIK Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/28/2014 10:39 AM, Martin Rex wrote: > I also object to the removal of the ContentInfo from the outer > TLS record protocol. I'm not aware of the slightest rationale for > this severe backwards incompatibility, that will not just break > middle-boxes, but also applications that parse TLS records for the > purpose of non-blocking operation. Parsing TLS records is still possible, since the length field will be present. I tried to highlight your concern about non-blocking applications to the TLS WG during the interim meeting last Sunday, but clearly failed to do it justice because none of those attending the interim (including myself) appeared to understand what specific toolchain you were trying to preserve. Can you provide more details? Applications that just look at the raw TLS records will still be able to tell when the communication shifts from cleartext to non-cleartext, but they should not be able to see more than that about the ciphertext. In what case is this a problem? --dkg --538W7jSUHokVixwoehCpd1SqOsVlUsaIK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJT1mdoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcVoUP/2D7fWeC6Yahou7LQKQ1su0w FSa8DfodFqbqe77nKXjxDu00yvYdTC4Y0bvkYmvCgo+29u6H1VIwR8d+t58Bqxb5 I85YW8XN/NuAfrqkfswDYseymPmUbXz2RA+if8OvLFwpbHdlTF7ZtwskcwJfZLB6 TsKJxkSVhieMHPn6adUcFp1xcjTLaAxdlMkkyoYGCX9j7J2NhO1bhIo3J7kppnWY mmPOjwEYabE4R4YcOwTgHDvJATTiPp78otxgZUiUR2yByspUCVio5Id9Irzfoeyp WwjGhAS9ptnWpm1hmvNtkDKUS3+vGNDImgbxZDj6YiypwIGpWyTCMAK1dOT+LGhn haQXLwpN7MvG6hL/3vx/Xwlz/0lS5apCvFO1nPHaTfg0DSCE7SXHCFwPngdwKIib dZL0YnFSFRN300oGKh3+Ijgziw34qRwIL191HW27vqi1GX67ABtmTYCTRcBK8Rhi v7xekDZqgARcIRXq9U0sG4egnXN6HQPLNTmRg2VgeBQCGTEBUJBVnWcQ9/wP3s2U 7+pGqaGQnxS2ygplZd8+ItMh6w+eU3bDKvMcZXRcH2WNjq4dKn64ylJNElsK1BWO VYacLZYg3U5ivLW3abJHPhbodXrWG1Y5I38CJr3m0/rDEGzGhkRtjGctPL5Tk9+K 3cUda20UHt37TYomSFt1 =Yl5R -----END PGP SIGNATURE----- --538W7jSUHokVixwoehCpd1SqOsVlUsaIK-- From nobody Mon Jul 28 08:14:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526B31B2883 for ; Mon, 28 Jul 2014 08:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.603 X-Spam-Level: X-Spam-Status: No, score=-6.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3vSBF6caRqs for ; Mon, 28 Jul 2014 08:14:17 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9569D1B287C for ; Mon, 28 Jul 2014 08:14:17 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6SFEGhW017000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 28 Jul 2014 11:14:16 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6SFEEVj017706 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 28 Jul 2014 11:14:15 -0400 Message-ID: <1406560456.7750.20.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Colm =?ISO-8859-1?Q?MacC=E1rthaigh?= Date: Mon, 28 Jul 2014 17:14:16 +0200 In-Reply-To: References: <1406537753.2413.12.camel@dhcp-2-127.brq.redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QdSzODbvKCgAFfQeovZK4kGSCnU Cc: tls@ietf.org Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2014 15:14:19 -0000 On Mon, 2014-07-28 at 07:54 -0700, Colm MacCárthaigh wrote: > On Mon, Jul 28, 2014 at 1:55 AM, Nikos Mavrogiannopoulos > wrote: > > Are there any pointers to these attacks? Will these attacks be countered > > with such a change? I believe not as alert messages consist of only two > > bytes and will be distinct from any other higher protocol messages > > transferred by the TLS record protocol. > > This is not the case. Firstly, even with a stream cipher it doesn't > distinguish the message from a 2 byte application data message. But > most ciphers are block ciphers, and so the true length is fuzzed by > about an order of magnitude. On the contrary, all _new_ ciphers are stream (GCM, CCM) and every future AEAD cipher will be a stream one (due to limitations of the AEAD construction in TLS). Furthermore, even if you assume that only AES-CBC is going to be used, do you really consider a 16-byte alert packet fuzzed? Do you know many application protocols that transfer such short packets? regards, Nikos From nobody Mon Jul 28 08:25:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBB51B28B9 for ; Mon, 28 Jul 2014 08:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7M1avOGJHPTI for ; Mon, 28 Jul 2014 08:25:35 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03BC21B28B5 for ; Mon, 28 Jul 2014 08:25:33 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 57F3A2AB2AE; Mon, 28 Jul 2014 15:25:26 +0000 (UTC) Date: Mon, 28 Jul 2014 15:25:26 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140728152526.GY15044@mournblade.imrryr.org> References: <1406537753.2413.12.camel@dhcp-2-127.brq.redhat.com> <1406560456.7750.20.camel@dhcp-2-127.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1406560456.7750.20.camel@dhcp-2-127.brq.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8CmQ7J0kw85Oe3OJDibhOjuGE74 Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 15:25:39 -0000 On Mon, Jul 28, 2014 at 05:14:16PM +0200, Nikos Mavrogiannopoulos wrote: > On the contrary, all _new_ ciphers are stream (GCM, CCM) and every > future AEAD cipher will be a stream one (due to limitations of the AEAD > construction in TLS). Furthermore, even if you assume that only AES-CBC > is going to be used, do you really consider a 16-byte alert packet > fuzzed? Do you know many application protocols that transfer such short > packets? [ Note, I far from convinced that encrypting the record type is useful ] Yes, some application application protocols do send short messages, for example SMTP an server may reply "250 2.0.0 OK\r\n". However, (fatal) alerts often terminate the connection and are easily distinguished from routine traffic. In chatty protocols, like SMTP, TLS masks the specific content, but not the overall flow or size of messages. One can often tell which application data messages carry "EHLO", "MAIL", "RCPT", "DATA" and the message payload, despite the use of TLS. The attacker does not learn very much, but may be able to estimate the recipient count, even with ESMTP PIPELINING and of course can estimate the message size fairly well. Defending against traffic analysis is very difficult, and I don't think that TLS can (or should attempt to) do the job. -- Viktor. From nobody Mon Jul 28 08:35:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C1F1B28A0 for ; Mon, 28 Jul 2014 08:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpm70cfKLdiU for ; Mon, 28 Jul 2014 08:35:06 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 96F481B289D for ; Mon, 28 Jul 2014 08:35:06 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C710C4742C; Mon, 28 Jul 2014 15:35:05 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 9EC404742E; Mon, 28 Jul 2014 15:35:05 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 8BB952026; Mon, 28 Jul 2014 15:35:05 +0000 (GMT) Received: from Tereva.local (172.19.46.109) by usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 28 Jul 2014 11:35:04 -0400 From: Brian Sniffen To: Yoav Nir , Nikos Mavrogiannopoulos In-Reply-To: References: <1406537753.2413.12.camel@dhcp-2-127.brq.redhat.com> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-apple-darwin12.4.0) Date: Mon, 28 Jul 2014 11:35:04 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/tls/myawod8_SW7lAnqRMMYAcbK_lf8 Cc: "" Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2014 15:35:10 -0000 Yoav Nir writes: > On Jul 28, 2014, at 11:55 AM, Nikos Mavrogiannopoulos wrote: > >> Are there any pointers to these attacks? Will these attacks be countered >> with such a change? I believe not as alert messages consist of only two >> bytes and will be distinct from any other higher protocol messages >> transferred by the TLS record protocol. Unless TLS 1.3 intended to >> include a length hiding mechanism I see this change as unnecessary and I >> agree with Watson on that. > > While no definite decisions were made, there was a positive response > to the idea of allowing arbitrary length padding to the plaintext in > all encrypted records, which can be used to hide alert messages. It's not clear to me that it can be used to hide alert messages, or the structure of the interaction at that level at all. Can you show me a model of a TLS 1.3 client state machine and a TLS 1.3 server state machine such that they both do padding, send messages on a clock, and otherwise take best-understood precautions against passive analysis---and then don't leak when there are alert messages? I expect closing a connection leaks quite a bit about what came just before the close. I expect timing leaks quite a bit---and an adversary who can be slightly active (e.g., opening his own connection to the server) can learn about timing differences between alerts and ordinary data. I don't see how to keep content-type secret without lock-step timing---which requires not just padding, but a habit of sending packets with no application data, just padding, on clock ticks. That's extremely expensive for performance, if we make a general practice of it. -Brian -- Brian Sniffen Information Security Akamai Technologies From nobody Mon Jul 28 08:57:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9A91B28E6 for ; Mon, 28 Jul 2014 08:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ao1KB4cLn5RL for ; Mon, 28 Jul 2014 08:57:12 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 69B611B28C4 for ; Mon, 28 Jul 2014 08:57:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 14F8FBE07 for ; Mon, 28 Jul 2014 16:57:10 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKefGps34png for ; Mon, 28 Jul 2014 16:57:09 +0100 (IST) Received: from [10.87.48.11] (unknown [86.44.64.225]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0C26BBE03 for ; Mon, 28 Jul 2014 16:57:09 +0100 (IST) Message-ID: <53D672D4.7050903@cs.tcd.ie> Date: Mon, 28 Jul 2014 16:57:08 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: tls@ietf.org References: <1406537753.2413.12.camel@dhcp-2-127.brq.redhat.com> <1406560456.7750.20.camel@dhcp-2-127.brq.redhat.com> <20140728152526.GY15044@mournblade.imrryr.org> In-Reply-To: <20140728152526.GY15044@mournblade.imrryr.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nshQVypKLOX5z8qj_CAvbgo0Qbg Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2014 15:57:20 -0000 I don't have a strong opinion on the topic in the subject line but... On 28/07/14 16:25, Viktor Dukhovni wrote: > Defending against traffic analysis is very difficult, and I don't > think that TLS can (or should attempt to) do the job. While traffic analysis mitigation is definitely hard and we probably do not yet have enough expertise in that space, I do think we should be trying to do as much as we can that might enable such mitigations as we learn more about 'em. In other words, I think we should be leaving extension points where we can that'd allow for traffic analysis mitigations to be defined later (or by implementers). That said, I'm not sure if this is useful enough in that respect or not. Cheers, S. From nobody Mon Jul 28 09:02:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45AA01A035D for ; Mon, 28 Jul 2014 09:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHUQzOgjgMzE for ; Mon, 28 Jul 2014 09:02:03 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C51F11A0322 for ; Mon, 28 Jul 2014 09:02:02 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id s7so7942985qap.9 for ; Mon, 28 Jul 2014 09:02:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=IIuWkQ8dLR3IOt0Q4dbtUExak/3Z41cXnhkmq+wB1QA=; b=jDiUBcETNhwwx0/kOI/IIS+DnnsDkqhfSP4SORYECimLHDjnFnAq0Rziz0arON5uYP OTbzj9tc8ASKni0cts0vbXbmVpQL/JD87Nc3jkM2DgIudG99Vlak5jsmG6MgViKd2Xqm bgF/KBgVasIZivDMsJl2Fqs06e1OMWBg24skRovHuJwXAUu8UZw84W6Rwj+Z57JHVoDn rhZqL86C+qv4/uAdpYA3uQU55xuPOXu26i4J0RIRkTwJ4zxCes8S3d5O6kWPL+cLcYqX PkI41KOI9sJ3U3C2qBZsqTMkl2pL72osR/pNSnLrt4GSvkBxqDVFdof3mjDB1pHa/P51 d6OA== X-Gm-Message-State: ALoCoQn69wlDbODDZ/l2H37MUQvRHnT4LVwwYIWbARa58pKzf02d9U1beiz3mzHAKMtPjrhljRLQ X-Received: by 10.224.114.74 with SMTP id d10mr50021138qaq.33.1406563320767; Mon, 28 Jul 2014 09:02:00 -0700 (PDT) Received: from [192.168.1.111] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id r2sm30256953qam.35.2014.07.28.09.01.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 09:02:00 -0700 (PDT) Message-ID: <53D673CB.1060703@nthpermutation.com> Date: Mon, 28 Jul 2014 12:01:15 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C738EFB1969@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738EFB1969@uxcn10-5.UoA.auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/y88kdwo1h7rkAVtl2Z4gpE9JkzY Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2014 16:02:20 -0000 On 7/28/2014 12:08 AM, Peter Gutmann wrote: > Yoav Nir writes: > >> I believe that changing the 5-byte record header will cause us trouble. >> Passive IDS/IPS devices follow TLS streams to detect certain attacks. They >> will cut connections. > Is it really up to the TLS WG to break (or at least constrain) our designs > in order to accomodate broken middleboxes? They're not going to understand > any of TLS 1.3 anyway and will need to be updated when it comes along, so why > keep this legacy header just for them? It depends on how widespread they are, and how deep they go into the packet. If this is something that consumer NAT routers do, then its a big problem. If this is something that commercial firewalls do, then its a big problem. If TLS1.3 does not work on the networks deployed today, I would doubt that TLS 1.3 would be deployed in any major way in any time less than a decade. I don't know the reality of whether or not this will be a problem, but simply saying that it's not our problem is probably not useful. Data would be helpful. Mike > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > From nobody Mon Jul 28 09:09:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0F91A0367 for ; Mon, 28 Jul 2014 09:09:35 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCygVdhuQUry for ; Mon, 28 Jul 2014 09:09:30 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 49FDD1A037B for ; Mon, 28 Jul 2014 09:09:30 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4F7FD47537 for ; Mon, 28 Jul 2014 16:09:28 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id C05DF47530 for ; Mon, 28 Jul 2014 16:09:27 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id BCFE18004A for ; Mon, 28 Jul 2014 16:09:27 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Mon, 28 Jul 2014 12:09:27 -0400 From: "Salz, Rich" To: "TLS@ietf.org (tls@ietf.org)" Date: Mon, 28 Jul 2014 12:09:26 -0400 Thread-Topic: Author change Thread-Index: Ac+qfdEzO5db1b1yT0eI9JqDk6wwOg== Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C718596FDD64@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C718596FDD64USMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fXBmPgd0rOXwqncfpJXqu_7r4iA Subject: [TLS] Author change X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2014 16:09:35 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C718596FDD64USMBX1msgcorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think we should instruct Eric to remove Tim as an editor and add him to t= he Contributors section as co-author of TLS 1.1 and TLS 1.2 I am sure modesty prevents Eric from doing this himself. :) -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz --_000_2A0EFB9C05D0164E98F19BB0AF3708C718596FDD64USMBX1msgcorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think we shoul= d instruct Eric to remove Tim as an editor and add him to the Contributors = section as co-author of TLS 1.1 and TLS 1.2

 

I am sure modesty prevents Er= ic from doing this himself. J<= o:p>

 

-- 

Principal Security Engineer<= o:p>

Akamai Technologies, Cambridge, MA<= /o:p>

IM: rsalz@= jabber.me; Twitter: RichSalz

&n= bsp;

= --_000_2A0EFB9C05D0164E98F19BB0AF3708C718596FDD64USMBX1msgcorp_-- From nobody Mon Jul 28 13:05:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74001A00FE for ; Mon, 28 Jul 2014 13:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7Li-sCZFXPj for ; Mon, 28 Jul 2014 13:04:51 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819771A00FF for ; Mon, 28 Jul 2014 13:04:50 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id m15so7889495wgh.29 for ; Mon, 28 Jul 2014 13:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/hSEtp3O6209NT/gisWxx4kd43D9JinCSLsp6XW+taQ=; b=NFGxNKSMHLzM90zb759Rvn/Uc+ueEQVILnXpTNGy2x9uVR5jRgJ5E2JOF7Pj99KHMY 2xuN1Xt4FUaudxWbyN5ym1Pe0EzTl0Ihm94MFNIR7IiakchF3KPejdssXCHalkYhKBsE zRzfr+ekL19YbcyMwORwkgJgd3ED2hoBeLFL21Jdit34GSWeGU1BveTiRrSxYgAYLZus i8H/fNTjTkhILuOAN0GQnI6cBya0JNaEpejbuKDWkV4qsk9uC3HpxSclA4eJ39p3JlCm /M54fDSGHJSOl3q1PqAvxypi50ZchYZU9QuxQzv9cf67t6QJ/+49m3xnO84UeKqrFBYl hQHw== X-Received: by 10.180.8.10 with SMTP id n10mr34850980wia.41.1406577888104; Mon, 28 Jul 2014 13:04:48 -0700 (PDT) Received: from [192.168.1.104] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id fs3sm34809730wic.20.2014.07.28.13.04.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 13:04:47 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: Date: Mon, 28 Jul 2014 23:04:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <58A6B704-89C8-48E1-9F87-E8BFCCA79089@gmail.com> References: <1406537753.2413.12.camel@dhcp-2-127.brq.redhat.com> To: Brian Sniffen X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/K8kYMasyPm9u16r6yHKR2a_rSNA Cc: "" Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2014 20:04:53 -0000 On Jul 28, 2014, at 6:35 PM, Brian Sniffen wrote: > Yoav Nir writes: >=20 >> On Jul 28, 2014, at 11:55 AM, Nikos Mavrogiannopoulos = wrote: >>=20 >>> Are there any pointers to these attacks? Will these attacks be = countered >>> with such a change? I believe not as alert messages consist of only = two >>> bytes and will be distinct from any other higher protocol messages >>> transferred by the TLS record protocol. Unless TLS 1.3 intended to >>> include a length hiding mechanism I see this change as unnecessary = and I >>> agree with Watson on that. >>=20 >> While no definite decisions were made, there was a positive response >> to the idea of allowing arbitrary length padding to the plaintext in >> all encrypted records, which can be used to hide alert messages. >=20 > It's not clear to me that it can be used to hide alert messages, or = the > structure of the interaction at that level at all. Can you show me a > model of a TLS 1.3 client state machine and a TLS 1.3 server state > machine such that they both do padding, send messages on a clock, and > otherwise take best-understood precautions against passive > analysis---and then don't leak when there are alert messages? Challenge accepted Assume that the path is deemed wide enough to carry 3 MB/s. We will = limit ourselves to slightly less than that, so let=92s say 2000 records = of 1400B plaintext a second in each direction. The sender (whether client or server) has two buffers, a system buffer = and a data buffer. The application writes to the data buffer. If there=92s= an error, or the application wishes to close, an alert is placed in the = system buffer. Every half millisecond, the TLS stack performs the following: * if the system buffer is not empty, retrieve an alert, pad to 1400 = bytes, encrypt, and send. * else if the data buffer is empty, generate a record with 1400 pad = bytes, encrypt and send. * else if the data buffer contains at least 1400 bytes, create a = 1400-byte record, remove 1400 bytes from the buffer, encrypt and send. * else create a record with all remaining data, pad to 1400 bytes, = encrypt and send. This is assuming that the attacker can=92t distinguish the number of = =93ifs=94 you ran through. Otherwise, don=92t send the record, but store = it and send it the next time the timer expires. That also takes care of = any timing side-channel you have in your encryption function. Note that I=92m not advocating doing this with TLS. IPsec has this = feature and to my knowledge nobody uses it. Yoav From nobody Mon Jul 28 13:11:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB30C1B28EA for ; Mon, 28 Jul 2014 13:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwj5pqrzE_3y for ; Mon, 28 Jul 2014 13:11:51 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F94C1B28EB for ; Mon, 28 Jul 2014 13:11:37 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB418.namprd03.prod.outlook.com (10.141.92.13) with Microsoft SMTP Server (TLS) id 15.0.995.14; Mon, 28 Jul 2014 20:11:33 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.0995.014; Mon, 28 Jul 2014 20:11:33 +0000 From: Andrei Popov To: Robert Ransom , Sean Turner Thread-Topic: [TLS] tls 1.3: renegotiation Thread-Index: AQHPpPeOOHAiusOfmU2fGY+VxmMv6puxMxAAgAS4VbA= Date: Mon, 28 Jul 2014 20:11:32 +0000 Message-ID: References: <7C3D5CF9-2B17-4953-A13D-C5E7226D13E7@ieca.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0286D7B531 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(479174003)(24454002)(377454003)(13464003)(31966008)(54356999)(19580405001)(92566001)(83322001)(87936001)(50986999)(19580395003)(83072002)(76176999)(46102001)(107046002)(86612001)(33646002)(86362001)(2656002)(76482001)(76576001)(85852003)(99396002)(74662001)(74502001)(101416001)(77982001)(81542001)(105586002)(79102001)(64706001)(74316001)(106116001)(80022001)(99286002)(21056001)(85306003)(4396001)(20776003)(106356001)(81342001)(95666004)(15975445006)(108616002)(3826002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB418; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hDsg5FxfqL6q1-dK4AzM7OyBiPs Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tls 1.3: renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 20:11:58 -0000 SSBhZ3JlZSB3aXRoIFJvYmVydCwgYW5kIG9wcG9zZSByZW1vdmFsIG9mIHJlbmVnb3RpYXRpb24g Zm9yIHRoZSByZWFzb25zIGxpc3RlZC4gDQoNCkFsc28sIHRoZSByZW1vdmFsIG9mIHJlbmVnb3Rp YXRpb24gd2lsbCBjb21wbGljYXRlIHRoZSBkZXBsb3ltZW50IG9mIFRMUzEuMyBhbmQgbGltaXQg aXRzIGFwcGxpY2FiaWxpdHkuIEUuZy4gaXQgaXMgbm90IGNsZWFyIHRvIG1lIGhvdyB0aGVzZSBj b25maWd1cmF0aW9ucyB3b3VsZCB3b3JrICh3aGVuIFRMUyBjbGllbnQgYXV0aCBpcyByZXF1aXJl ZCk6DQoxLiBUTFMgMS4zIHdpdGggYW4gZXhpc3RpbmcgSFRUUC8xLjEgc2VydmVyOw0KMi4gRXhp c3RpbmcgVExTIDEuMiBsaWJyYXJ5IHdpdGggSFRUUC8yIHN0YWNrIG9uIHRvcCBvZiBpdC4NCg0K SXQgbG9va3MgbGlrZSBvbmUgd291bGQgbmVlZCB0byBkZXBsb3kgIGJvdGggVExTMS4zIGFuZCBI VFRQLzIgYXQgdGhlIHNhbWUgdGltZS4gT25jZSBUTFMgMS4zIGFuZCBIVFRQLzIgYXJlIGRlcGxv eWVkLCB0aGUgd2F5IGEgc2l0ZSBpbXBsZW1lbnRzIFRMUyBjbGllbnQgYXV0aCB3aWxsIGRlcGVu ZCBvbiB0aGUgY29tYmluYXRpb24gb2YgVExTIHZlcnNpb24gYW5kIEhUVFAgdmVyc2lvbiBuZWdv dGlhdGVkOg0KVExTMS4zICsgSFRUUC8yIC0+IE5ldy1zdHlsZSBUTFMgY2xpZW50IGF1dGggKFRC RCkuDQpUTFMxLjMgKyBIVFRQLzEuMSAtPiBObyB3YXkgdG8gc3VwcG9ydCBUTFMgY2xpZW50IGF1 dGg/DQpUTFMxLjIgKyBIVFRQLzIgLT4gTm8gd2F5IHRvIHN1cHBvcnQgVExTIGNsaWVudCBhdXRo Pw0KVExTMS4yICsgSFRUUC8xLjEgLT4gVExTIGNsaWVudCBhdXRoIHZpYSByZW5lZ290aWF0aW9u Lg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb2JlcnQg UmFuc29tDQpTZW50OiBGcmlkYXksIEp1bHkgMjUsIDIwMTQgMTI6MjggUE0NClRvOiBTZWFuIFR1 cm5lcg0KQ2M6IFRMU0BpZXRmLm9yZyAodGxzQGlldGYub3JnKQ0KU3ViamVjdDogUmU6IFtUTFNd IHRscyAxLjM6IHJlbmVnb3RpYXRpb24NCg0KT24gNy8yMS8xNCwgU2VhbiBUdXJuZXIgPFR1cm5l clNAaWVjYS5jb20+IHdyb3RlOg0KPiBBdCB0aGUgVExTIGludGVyaW0gbWVldGluZyBoZWxkIG9u IFN1bmRheSBKdWx5IDIwdGgsIDIwMTQsIHRoZXJlIHdhcyANCj4gY29uc2Vuc3VzIHRvIHJlbW92 ZSByZW5lZ290aWF0aW9uIG9uIHRoZSBhc3N1bXB0aW9uIHdlIHdpbGwgcHJvdmlkZSBhIA0KPiBy ZWtleWluZyBmYWNpbGl0eSBvZiBzb21lIGZvcm0gYW5kIGNsaWVudCBpbml0YXRlZCBjbGllbnQg YXV0aGVudGljYXRpb24uDQo+IFRoaXMgbWVzc2FnZSBzZXJ2ZXMgdG8gY29uZmlybSB0aGF0IGNv bnNlbnN1cy4gIFBsZWFzZSBpbmRpY2F0ZSBieSANCj4gSnVseSAyNXRoLCAyMDE0IHdoZXRoZXIg eW91IGRpc2FncmVlIHdpdGggdGhpcyAoYW5kIHdoeSkuDQoNCkkgb3Bwb3NlIHJlbW92YWwgb2Yg cmVuZWdvdGlhdGlvbiwgZm9yIHRoZSBmb2xsb3dpbmcgcmVhc29uczoNCg0KKiBSZW5lZ290aWF0 aW9uIGlzIGEgc2luZ2xlIGZlYXR1cmUgd2hpY2ggc2VydmVzIG1hbnkgcHVycG9zZXMuICBJDQog IGJlbGlldmUgdGhhdCBmaXhpbmcgdGhlIGRlc2lnbiwgQVBJcywgYW5kIGltcGxlbWVudGF0aW9u cyBvZg0KICByZW5lZ290aWF0aW9uIHdpbGwgYmUgZWFzaWVyIHRoYW4gZGVzaWduaW5nIHRoZSBw cm90b2NvbHMsIGRlc2lnbmluZw0KICB0aGUgQVBJcywgYW5kIGltcGxlbWVudGluZyBldmVyeSBm ZWF0dXJlIHdoaWNoIHdvdWxkIGJlIG5lZWRlZCB0bw0KICByZXBsYWNlIGl0Lg0KDQoqIFRoZSBj bGllbnQtaW5pdGlhdGVkIGNsaWVudCBhdXRoZW50aWNhdGlvbiBmZWF0dXJlIHdpbGwgcmVxdWly ZSBhDQogIOKAmGNoYW5uZWwgYmluZGluZ+KAmSB0byB0aGUgZXhpc3RpbmcgVExTIGNvbm5lY3Rp b24sIHdoaWNoIC0tIGFzIE5pY28NCiAgV2lsbGlhbXMgaGFzIHBvaW50ZWQgb3V0IC0tIGlzIHN1 ZmZpY2llbnQgdG8gd29yayBhcm91bmQNCiAgcmVuZWdvdGlhdGlvbi1iYXNlZCBhdHRhY2tzIGF0 IHRoZSBwcm90b2NvbCBsZXZlbCwgYnkgYmluZGluZyB0aGUNCiAgYXBwbGljYXRpb24gZGF0YSBz ZW50IGJlZm9yZSByZW5lZ290aWF0aW9uIHRvIHRoZSBhdXRoZW50aWNhdGlvbg0KICBwZXJmb3Jt ZWQgZHVyaW5nIHRoZSByZW5lZ290aWF0aW9uIGhhbmRzaGFrZS4gIEFkZGluZyBhIGNoYW5uZWwN CiAgYmluZGluZyB0byByZW5lZ290aWF0aW9uIHdvdWxkIG5vdCByZXF1aXJlIGFzIG1hbnkgY2hh bmdlcyB0bw0KICBleGlzdGluZyBjb2RlIGFzIGFkZGluZyBhbiBlbnRpcmVseSBuZXcgY2xpZW50 IGF1dGhlbnRpY2F0aW9uDQogIGZlYXR1cmUgd291bGQsIGFuZCB3b3VsZCBwcm92aWRlIGxlc3Mg cm9vbSBmb3IgbmV3IGltcGxlbWVudGF0aW9uDQogIGJ1Z3MgdG8gY3JlZXAgaW4uDQoNCiogUmVu ZWdvdGlhdGlvbiBjYW4gc2hhcmUgbW9zdCBvZiBpdHMgY29kZSB3aXRoIHRoZSBpbXBsZW1lbnRh dGlvbiBvZg0KICB0aGUgaW5pdGlhbCBjb25uZWN0aW9uIGhhbmRzaGFrZSwgZXZlbiBhZnRlciBh IGNoYW5uZWwgYmluZGluZyBpcw0KICBhZGRlZCB0byBpdC4gIEVhY2ggb2YgdGhlIG5ldyBmZWF0 dXJlcyBhZGRlZCBpbiBvcmRlciB0byByZXBsYWNlDQogIHJlbmVnb3RpYXRpb24gaXMgbGlrZWx5 IHRvIHNoYXJlIGNvbnNpZGVyYWJseSBsZXNzIGNvZGUgd2l0aCB0aGUNCiAgaW5pdGlhbCBoYW5k c2hha2UsIGFuZCB0aGVpciBpbXBsZW1lbnRhdGlvbnMgYXJlIGxpa2VseSB0byByZWNlaXZlDQog IGNvbnNpZGVyYWJseSBsZXNzIHVzZSBhbmQgbGVzcyB0ZXN0aW5nIHRoYW4gYW55IHBpZWNlIG9m IGNvZGUgdXNlZA0KICBpbiBpbXBsZW1lbnRpbmcgcmVuZWdvdGlhdGlvbi4NCg0KDQpJbiBhZGRp dGlvbiwgSSBiZWxpZXZlIHRoYXQgaXQgaXMgbm90IHBvc3NpYmxlIGZvciB0aGUgV0cgdG8gbWFr ZSBhbiBpbmZvcm1lZCBkZWNpc2lvbiBhcyB0byB3aGV0aGVyIHJlbmVnb3RpYXRpb24gc2hvdWxk IGJlIHJlbW92ZWQgYXQgdGhpcyB0aW1lOg0KDQoqIFRoZSByZWtleWluZyBmZWF0dXJlIGFuZCBj bGllbnQtaW5pdGlhdGVkIGNsaWVudCBhdXRoZW50aWNhdGlvbg0KICBmZWF0dXJlIGhhdmUgbm90 IGJlZW4gc3BlY2lmaWVkIHlldCwgZXZlbiB0byB0aGUgcG9pbnQgb2Ygc3RhdGluZw0KICB0aGUg cmVxdWlyZW1lbnRzIHdoaWNoIGVhY2ggZmVhdHVyZSB3aWxsIG1lZXQuICBJdCBpcyBub3QgcG9z c2libGUNCiAgZm9yIHRoZSBXRyB0byBkZXRlcm1pbmUgd2hldGhlciB0aGUgZmVhdHVyZXMgaW50 ZW5kZWQgdG8gcmVwbGFjZQ0KICB0aGVzZSB0d28gdXNlcyBvZiByZW5lZ290aWF0aW9uIHdpbGwg YmUgZml0IGZvciB0aGVpciBpbnRlbmRlZA0KICBwdXJwb3NlcyBhdCB0aGlzIHRpbWUuDQoNCg0K Um9iZXJ0IFJhbnNvbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0K From nobody Mon Jul 28 14:02:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2891A0271 for ; Mon, 28 Jul 2014 14:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNlSIYfo0r3p for ; Mon, 28 Jul 2014 14:02:07 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC6811A0217 for ; Mon, 28 Jul 2014 14:02:06 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id bs8so5025506wib.8 for ; Mon, 28 Jul 2014 14:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hYeNNKSUxzkaWvJnwxkiph+0WcUAmmU8j0DNWySoM94=; b=bQ/R0YjZj2O3fP3FFXd9/6xZkhBnU/9lryOI7c0WCU7EDizNGGltQ4lBTFay4NmBrW QaVwifg6OqnV29FsEnQtg/z4vPyCoX2eAKljBChLf07t3vEtHfOUvksGl5rh2zXBaspi 9OokzJbcddMz8sZXP3EHqmxbIxXGpsFUXQxZy/fZ31Mg/V03gECmQERCWo5L/4OmjHsI G7Yp00z969/NsFmwgBC5AjHacV/aKRrzzc+miLRy0iWvCH3nyLZC1yRLuUsV0NPKbK6d iatLQNnc724zylrEo0r9krEGlE/FlG5VfpcQVwAjm2XNxezZ0z0siKF6iHte9F0Omttd jBSA== MIME-Version: 1.0 X-Received: by 10.180.187.197 with SMTP id fu5mr23753638wic.64.1406581323180; Mon, 28 Jul 2014 14:02:03 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Mon, 28 Jul 2014 14:02:03 -0700 (PDT) In-Reply-To: References: <7C3D5CF9-2B17-4953-A13D-C5E7226D13E7@ieca.com> Date: Mon, 28 Jul 2014 14:02:03 -0700 Message-ID: From: Martin Thomson To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OYMTw4Ol1IQ8dFdcT4zHjuoy1s8 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tls 1.3: renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 21:02:08 -0000 On 28 July 2014 13:11, Andrei Popov wrote: > It looks like one would need to deploy both TLS1.3 and HTTP/2 at the same time. Once TLS 1.3 and HTTP/2 are deployed, the way a site implements TLS client auth will depend on the combination of TLS version and HTTP version negotiated: > TLS1.3 + HTTP/2 -> New-style TLS client auth (TBD). > TLS1.3 + HTTP/1.1 -> No way to support TLS client auth? > TLS1.2 + HTTP/2 -> No way to support TLS client auth? > TLS1.2 + HTTP/1.1 -> TLS client auth via renegotiation. Client authentication is still possible, it just has to come in the opening handshake. Your concern is spontaneous client authentication. HTTP/2 forbids renegotiation entirely, but permits it before HTTP/2 starts (to allow for client certificate confidentiality, if that is desired). That means that for HTTP/2 at least, the need isn't there. They are already looking for alternatives. And it's not that alternatives don't exist, it's more the case that we disagree on the viability aspects, I think. From nobody Mon Jul 28 14:15:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2B61A01DC for ; Mon, 28 Jul 2014 14:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxFwZDaw6T4k for ; Mon, 28 Jul 2014 14:15:41 -0700 (PDT) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51E7D1A017F for ; Mon, 28 Jul 2014 14:15:41 -0700 (PDT) Received: by mail-oi0-f50.google.com with SMTP id a141so6575431oig.37 for ; Mon, 28 Jul 2014 14:15:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VvNqEcFKbytYsicfwtvgRFVAUhjvDc99a1/q6mvo0VI=; b=Qg2znJUJJ+1+gyBktqrrDN/VMKt8Muk3GsUaF6Wez+Tef27oiWXGsYr5FIge5lYmjS mUSka1GVNBIZ5p/PKWGmGPLZ1K/56zfbrING7HGas9fgz4WbkHrrWNgZGMEI6UAuYOCB B8X6tW2YkgK3cD/agT1CpJ4Iot2vlwDAES+pP8vZJVjLHkNYjfc72ofgfnGW+gIpA0it yvwDQ7iuAUPHiZ7OwfuZxvhDAX3QjlehZ/8ybO/h1tKDbo5foLO5EMMb9o/ZRLd3VQ3F R16Ik+ArD3YtYvyed/Fv3jTUkPCFUTW0azFiRBKKPMTAIaJcA2IvVJH9WJMsyEJZJ05N 16LA== X-Gm-Message-State: ALoCoQm3Po8KgJQnOK/MMLerFpKt85xqMcNVPQjy+0wn27QWyWalRiGYToohM/EffSnTHQEz33Za MIME-Version: 1.0 X-Received: by 10.60.146.198 with SMTP id te6mr53666879oeb.46.1406582140532; Mon, 28 Jul 2014 14:15:40 -0700 (PDT) Received: by 10.76.10.198 with HTTP; Mon, 28 Jul 2014 14:15:40 -0700 (PDT) In-Reply-To: <1406560456.7750.20.camel@dhcp-2-127.brq.redhat.com> References: <1406537753.2413.12.camel@dhcp-2-127.brq.redhat.com> <1406560456.7750.20.camel@dhcp-2-127.brq.redhat.com> Date: Mon, 28 Jul 2014 14:15:40 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/g5x4KfrjCBFADRhiOKHAcmDukJQ Cc: "tls@ietf.org" Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2014 21:15:42 -0000 On Mon, Jul 28, 2014 at 8:14 AM, Nikos Mavrogiannopoulos wrote: > On the contrary, all _new_ ciphers are stream (GCM, CCM) Now you've got me scratching my head, because both GCM and CCM are authentication modes for block ciphers, not stream. -- Colm From nobody Mon Jul 28 14:17:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B8D1A01E2 for ; Mon, 28 Jul 2014 14:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tc8U_8Br1ZHf for ; Mon, 28 Jul 2014 14:17:49 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0471A017F for ; Mon, 28 Jul 2014 14:17:48 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id bs8so5135530wib.3 for ; Mon, 28 Jul 2014 14:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yMoqK/dj94udtv26u2o9ACnq+yOc41TIhgn/NBKcPJM=; b=AGHHVGKJa0aZ2LYE6vVresxmLftJ5UX56PlOiXftF/Vv+FVdkbeTeGwpjxDtHYXAyd WlOOVzLd97dMSWG7tcowttN6EyeJdDwFwFwM7ugynMsDFcyHQxFGD6KRxKcn1K0iqRFv fp2PtoeGoVwAb+6GQzCP752EFIhBhaupCA1hcUGr0zUv3wigL/3Ut0cKe9m3yBzwr2Yg XB4mqW0ODH5eyyTYxTOD/SYA/eq3r6T7+RGks1bh1gxqDQG1N1od4Hoi6iSTKkvUaPIX CDLXD37ZqrNRcihi0NdRaK2IR+5NRFYU290S4XE22/+QZAeLoL68UhizELaJhfcdp23h a8mw== MIME-Version: 1.0 X-Received: by 10.194.185.238 with SMTP id ff14mr54101534wjc.9.1406582266466; Mon, 28 Jul 2014 14:17:46 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Mon, 28 Jul 2014 14:17:46 -0700 (PDT) In-Reply-To: References: <7C3D5CF9-2B17-4953-A13D-C5E7226D13E7@ieca.com> Date: Mon, 28 Jul 2014 14:17:46 -0700 Message-ID: From: Martin Thomson To: Robert Ransom Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/r23b0RDDC4VPOl9XFdzKWKo5KLI Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tls 1.3: renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 21:17:51 -0000 On 25 July 2014 12:27, Robert Ransom wrote: > In addition, I believe that it is not possible for the WG to make an > informed decision as to whether renegotiation should be removed at > this time: > > * The rekeying feature and client-initiated client authentication > feature have not been specified yet, even to the point of stating > the requirements which each feature will meet. It is not possible > for the WG to determine whether the features intended to replace > these two uses of renegotiation will be fit for their intended > purposes at this time. We had a good discussion about these in Toronto. On rekeying, there are concerns about how much we might want to make changeable; offline discussions about the complexity/value trade-off space between simple rekeying (as I have proposed) and something more complete like a full DH exchange was quite enlightening. We've talked quite a bit about spontaneous client authentication (though we might talk about client-initiated authentication, that implies a solution and so I think that is the wrong focus for the discussion). The problem as always is that the defense of renegotiation is largely based on its existence alone. That defense would be stronger if there it were based on use cases. I don't find arguments from inertia ("it exists", or "it's easy") to be at all persuasive. Saying "it can be fixed" is actively detrimental to the case. Arguments in the form "I need to do X and in order to do X I need renegotiation" are far better. They are testable. Andrei's concerns are a good example of this. We might disagree on the subjective elements, but that's a good starting point. From nobody Mon Jul 28 14:24:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2101A02E4 for ; Mon, 28 Jul 2014 14:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.821 X-Spam-Level: X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id groBCZy0GFvB for ; Mon, 28 Jul 2014 14:23:56 -0700 (PDT) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CDA51A02D0 for ; Mon, 28 Jul 2014 14:23:56 -0700 (PDT) Received: from [10.168.252.42] (85-76-53-79-nat.elisa-mobile.fi [85.76.53.79]) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id B6C7E20027; Tue, 29 Jul 2014 00:23:50 +0300 (EEST) Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (1.0) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Tue, 29 Jul 2014 00:23:50 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <49AFE121-7421-4FCE-B3D8-46B75581F5B2@iki.fi> References: <1406537753.2413.12.camel@dhcp-2-127.brq.redhat.com> <1406560456.7750.20.camel@dhcp-2-127.brq.redhat.com> To: =?GB2312?Q?Colm_MacC=A8=A2rthaigh?= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eW1WRLRMOdX0R6MaWzedVYaqVuc Cc: "tls@ietf.org" Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2014 21:23:58 -0000 > On 29.7.2014, at 0.15, Colm MacC=A8=A2rthaigh wrote: >=20 > On Mon, Jul 28, 2014 at 8:14 AM, Nikos Mavrogiannopoulos > wrote: >> On the contrary, all _new_ ciphers are stream (GCM, CCM) >=20 > Now you've got me scratching my head, because both GCM and CCM are > authentication modes for block ciphers, not stream. They are both authenticated counter modes for block ciphers, which means the= y behave like stream ciphers. Even though the output from the cipher comes i= n blocks, all redundant bytes in the end can be dropped, unlike in CBC mode.= =20 Therefore 2 byte alert encrypted with GCM or CCM is still 2 bytes plus the a= uthentication tag. I believe this is what Nikos meant. Juho From nobody Mon Jul 28 14:27:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A6D1A030C for ; Mon, 28 Jul 2014 14:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAHsx7H4-VuM for ; Mon, 28 Jul 2014 14:27:20 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 351DC1A02F7 for ; Mon, 28 Jul 2014 14:27:20 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so7920725wgg.4 for ; Mon, 28 Jul 2014 14:27:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VFG+3szhEUdpy0vSZN3B+1xfT8EF5d//3aulWMgmE0Y=; b=ReoG1Nk5fBUYO9HL3yhiwqzynkjkOxV/dbjSQe+uYKbHkQS6y+x4L0RhBW/VacR9WO b1QWLNMiIJpt+NccyXSyA/bBB6+W+tzJCno41HvxOV1/aG50OOA46U7UlKtkcM+sPLKO rnELcOylyZva2QBxhUihKs+SM2/DBZJKIIElPXVxFEjtQwzaCJpGfS5aRVSOsfv0jqMc tqQ3wcwHyAK+0VovAuJOnpmgODKnardTrzPVkLmkDaM++p5pKjiYvAnD1PehDWJLF+B/ rp5EsRqiTuGZDM3yCuUEv8irt12xj5EVmcOWvYEYRV9XrC0QrjkZAvKtpxDBCNXfGIRt +o6g== X-Gm-Message-State: ALoCoQkXGWLMUHGGOL+LQRjvLHiHt3ZCkjX3KN5LSL6p3bEtrZAzDf7nqjuUE7aAldNEm4LZfdB5 X-Received: by 10.180.37.77 with SMTP id w13mr9773439wij.78.1406582838841; Mon, 28 Jul 2014 14:27:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Mon, 28 Jul 2014 14:26:38 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:c9a7:3c2d:8df:866a] In-Reply-To: <49AFE121-7421-4FCE-B3D8-46B75581F5B2@iki.fi> References: <1406537753.2413.12.camel@dhcp-2-127.brq.redhat.com> <1406560456.7750.20.camel@dhcp-2-127.brq.redhat.com> <49AFE121-7421-4FCE-B3D8-46B75581F5B2@iki.fi> From: Eric Rescorla Date: Mon, 28 Jul 2014 14:26:38 -0700 Message-ID: To: =?UTF-8?B?SnVobyBWw6Row6QtSGVydHR1YQ==?= Content-Type: multipart/alternative; boundary=e89a8f64702174edac04ff479604 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JV7G4Fao3j1kYnZDL3G7uQjXMDQ Cc: "tls@ietf.org" Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2014 21:27:21 -0000 --e89a8f64702174edac04ff479604 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 28, 2014 at 2:23 PM, Juho V=C3=A4h=C3=A4-Herttua wrote: > > > On 29.7.2014, at 0.15, Colm MacC=C3=A1rthaigh wrote= : > > > > On Mon, Jul 28, 2014 at 8:14 AM, Nikos Mavrogiannopoulos > > wrote: > >> On the contrary, all _new_ ciphers are stream (GCM, CCM) > > > > Now you've got me scratching my head, because both GCM and CCM are > > authentication modes for block ciphers, not stream. > > They are both authenticated counter modes for block ciphers, which means > they behave like stream ciphers. Even though the output from the cipher > comes in blocks, all redundant bytes in the end can be dropped, unlike in > CBC mode. > FWIW, TLS has this idiosyncratic defn. of the term "stream cipher" that matches RC4 but not AEAD ciphers or even CTR mode... Hence comments about how we are deprecating stream ciphers but not GCM. -Ekr > Therefore 2 byte alert encrypted with GCM or CCM is still 2 bytes plus th= e > authentication tag. I believe this is what Nikos meant. > > > Juho > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --e89a8f64702174edac04ff479604 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Jul 28, 2014 at 2:23 PM, Juho V=C3=A4h=C3=A4-Herttua <juhovh@i= ki.fi> wrote:

> On 29.7.2014, at 0.15, Colm MacC=C3=A1rthaigh <colm@allcosts.net> wrote:
>
> On Mon, Jul 28, 2014 at 8:14 AM, Nikos Mavrogiannopoulos
> <nmav@redhat.com> wrote:<= br> >> On the contrary, all _new_ ciphers are stream (GCM, CCM)
>
> Now you've got me scratching my head, because both GCM and CCM are=
> authentication modes for block ciphers, not stream.

They are both authenticated counter modes for block ciphers, which me= ans they behave like stream ciphers. Even though the output from the cipher= comes in blocks, all redundant bytes in the end can be dropped, unlike in = CBC mode.

FWIW, TLS has this idiosyncratic defn. of = the term "stream cipher" that matches
RC4 but not AEAD = ciphers or even CTR mode... Hence comments about how
we are depre= cating stream ciphers but not GCM.

-Ekr
=C2=A0
Therefore 2 byte alert encrypted with GCM or CCM is still 2 bytes plus the = authentication tag. I believe this is what Nikos meant.


Juho

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

--e89a8f64702174edac04ff479604-- From nobody Mon Jul 28 15:03:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EFB1A008E for ; Mon, 28 Jul 2014 15:03:43 -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, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkQFUjzkCm_t for ; Mon, 28 Jul 2014 15:03:42 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 483941A0080 for ; Mon, 28 Jul 2014 15:03:42 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id v10so8588138qac.33 for ; Mon, 28 Jul 2014 15:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=t/8RFc8mEyg+a6pJaoWEkENHp80aNLhSJUf1LrwTJeE=; b=El/CwRXqEzRu7qvvuHOwQdJTRGjKuK7HD4H46KXde64ahwj2Pm5qf3Lk+IQTYaCCRc fKv2xhcgajAJTlZtiYfUKhs4FSKdt0AutnVXo4XJJLKbqKUpVGMDyurUFjQyW3MTdfP/ iL42A/aS6u6kh2qntB93dPowGSTHxExwn97lEu8JadLN/xFCxOK0q/d10Jd+CHQgzKeI AmUQQ7hChiBWNQnL9djfuASX+UttK5Z9p3fMNcg0IZCcY7Wh9FtYO5lDIJt7JRXagxGy yYY+PkZbvApAtGKDMl2YHna2vlLxyp22kGMekTYjMgJd+oWiy4fsEjATiGZlKz91TeDQ c6yg== MIME-Version: 1.0 X-Received: by 10.224.135.2 with SMTP id l2mr64460177qat.37.1406585016854; Mon, 28 Jul 2014 15:03:36 -0700 (PDT) Received: by 10.140.86.135 with HTTP; Mon, 28 Jul 2014 15:03:36 -0700 (PDT) In-Reply-To: References: <7C3D5CF9-2B17-4953-A13D-C5E7226D13E7@ieca.com> Date: Mon, 28 Jul 2014 15:03:36 -0700 Message-ID: From: Robert Ransom To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NcQ3hjAyI3Qog0YoZyqDraT_Q5s Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tls 1.3: renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 22:03:44 -0000 On 7/28/14, Martin Thomson wrote: > On 25 July 2014 12:27, Robert Ransom wrote: >> In addition, I believe that it is not possible for the WG to make an >> informed decision as to whether renegotiation should be removed at >> this time: >> >> * The rekeying feature and client-initiated client authentication >> feature have not been specified yet, even to the point of stating >> the requirements which each feature will meet. It is not possible >> for the WG to determine whether the features intended to replace >> these two uses of renegotiation will be fit for their intended >> purposes at this time. > > We had a good discussion about these in Toronto. On rekeying, there > are concerns about how much we might want to make changeable; offline > discussions about the complexity/value trade-off space between simple > rekeying (as I have proposed) and something more complete like a full > DH exchange was quite enlightening. I see. So you don't even have a consensus on what =E2=80=9Crekeying=E2=80= =9D will mean. > We've talked quite a bit about spontaneous client authentication > (though we might talk about client-initiated authentication, that > implies a solution and so I think that is the wrong focus for the > discussion). > > The problem as always is that the defense of renegotiation is largely > based on its existence alone. That defense would be stronger if there > it were based on use cases. I don't find arguments from inertia ("it > exists", or "it's easy") to be at all persuasive. Saying "it can be > fixed" is actively detrimental to the case. > > Arguments in the form "I need to do X and in order to do X I need > renegotiation" are far better. They are testable. Andrei's concerns > are a good example of this. We might disagree on the subjective > elements, but that's a good starting point. I gave a list of four use cases that can be (and are currently) addressed by renegotiation a while back. The responses can be summed up as =E2=80=9CBut we can add a separate ad-hoc feature to address each of those use cases!=E2=80=9D. I agree that each use of renegotiation can be replaced with a new protocol feature, which will require new protocol design effort, new implementation code, new testing, new API design effort, new application code, and new risk of introducing security bugs at each of those steps. I do not agree with your argument that such a replacement is desirable for every use of renegotiation -- or for *any* use of renegotiation at all. Renegotiation is a particularly elegant solution to several problems. It requires little extra code beyond what is already used to perform the initial handshake, and adding a (correctly designed) channel binding as input to the renegotiation process will add the security properties that some API and application developers had previously expected renegotiation to provide. I don't find arguments based on the prospect that new features might be added to TLS to be at all persuasive. Saying =E2=80=9CTLS-without-renegotiation can be fixed to support long-lived connections if we decide to add some sort of rekeying mechanism.=E2=80=9D o= r =E2=80=9CWe added a Heartbeat record type; now let's add a ClientAuthentica= te record type too!=E2=80=9D are actively detrimental to the case. Robert Ransom From nobody Mon Jul 28 15:24:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EB91A0304 for ; Mon, 28 Jul 2014 15:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wS9rZk3mWkm for ; Mon, 28 Jul 2014 15:24:12 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5983D1A028E for ; Mon, 28 Jul 2014 15:24:12 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB418.namprd03.prod.outlook.com (10.141.92.13) with Microsoft SMTP Server (TLS) id 15.0.995.14; Mon, 28 Jul 2014 22:24:10 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.0995.014; Mon, 28 Jul 2014 22:24:10 +0000 From: Andrei Popov To: Martin Thomson Thread-Topic: [TLS] tls 1.3: renegotiation Thread-Index: AQHPpPeOOHAiusOfmU2fGY+VxmMv6puxMxAAgAS4VbCAABkIgIAADBzg Date: Mon, 28 Jul 2014 22:24:09 +0000 Message-ID: <52de31491a51434ca4dc6cbbdda1d004@BL2PR03MB419.namprd03.prod.outlook.com> References: <7C3D5CF9-2B17-4953-A13D-C5E7226D13E7@ieca.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0286D7B531 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(199002)(189002)(377454003)(24454002)(74316001)(106116001)(81542001)(79102001)(105586002)(64706001)(21056001)(99286002)(80022001)(20776003)(85306003)(4396001)(106356001)(81342001)(95666004)(76176999)(86612001)(33646002)(110136001)(46102001)(107046002)(92566001)(93886003)(54356999)(19580405001)(31966008)(19580395003)(83072002)(83322001)(87936001)(50986999)(74502001)(77982001)(101416001)(85852003)(76482001)(76576001)(86362001)(2656002)(99396002)(74662001)(108616002)(24736002)(3826002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB418; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HraFk-EDQSLt2D5NKcCpvBpg2U4 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tls 1.3: renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 22:24:14 -0000 PiBDbGllbnQgYXV0aGVudGljYXRpb24gaXMgc3RpbGwgcG9zc2libGUsIGl0IGp1c3QgaGFzIHRv IGNvbWUgaW4gdGhlIG9wZW5pbmcgaGFuZHNoYWtlLiAgWW91ciBjb25jZXJuIGlzIHNwb250YW5l b3VzIGNsaWVudCBhdXRoZW50aWNhdGlvbi4NCkNvcnJlY3QsIEkgYW0gY29uY2VybmVkIGJlY2F1 c2UgYSBsb3Qgb2Ygc2l0ZXMgY2hvb3NlIHRvIHNlcnZlIGxhbmRpbmcgcGFnZXMgd2l0aG91dCBj bGllbnQgYXV0aCwgYW5kIHRoZW4gcmVxdWVzdCBjbGllbnQgYXV0aCB3aXRoIGFuIGFwcHJvcHJp YXRlIGNlcnQgb25jZSB0aGUgdXNlciBuYXZpZ2F0ZXMgdG8gYSBwYXJ0aWN1bGFyIHByb3RlY3Rl ZCByZXNvdXJjZS4gVGhpcyBzY2VuYXJpbyB3b3JrcyB0b2RheSwgYnV0IHNlZW1zIHRvIGJlIGhh cmQgKG9yIGltcG9zc2libGU/KSB0byBpbXBsZW1lbnQgd2hlbiBUTFMxLjMgYW5kIEhUVFAvMiBh cmUgbmVnb3RpYXRlZC4NCg0KPiBIVFRQLzIgZm9yYmlkcyByZW5lZ290aWF0aW9uIGVudGlyZWx5 LCBidXQgcGVybWl0cyBpdCBiZWZvcmUgSFRUUC8yIHN0YXJ0cyAodG8gYWxsb3cgZm9yIGNsaWVu dCBjZXJ0aWZpY2F0ZSBjb25maWRlbnRpYWxpdHksIGlmIHRoYXQgaXMgZGVzaXJlZCkuDQoNCj4g VGhhdCBtZWFucyB0aGF0IGZvciBIVFRQLzIgYXQgbGVhc3QsIHRoZSBuZWVkIGlzbid0IHRoZXJl LiAgVGhleSBhcmUgYWxyZWFkeSBsb29raW5nIGZvciBhbHRlcm5hdGl2ZXMuDQpBcmUgeW91IHNh eWluZyB0aGF0IGJlY2F1c2UgSFRUUC8yIGRlc2lnbmVycyBjaG9zZSB0byBiYW4gcmVuZWdvdGlh dGlvbiwgdGhlIGN1c3RvbWVycyBubyBsb25nZXIgbmVlZCB0byBwZXJmb3JtIFRMUyBjbGllbnQg YXV0aCBpbiB0aGUgbWlkZGxlIG9mIGEgY29ubmVjdGlvbj8gUGVyaGFwcyBJJ20gbWlzc2luZyB0 aGlzIHBvaW50Lg0KDQo+IEFuZCBpdCdzIG5vdCB0aGF0IGFsdGVybmF0aXZlcyBkb24ndCBleGlz dCwgaXQncyBtb3JlIHRoZSBjYXNlIHRoYXQgd2UgZGlzYWdyZWUgb24gdGhlIHZpYWJpbGl0eSBh c3BlY3RzLCBJIHRoaW5rLg0KVGhlIGFsdGVybmF0aXZlcyB3b3VsZCBuZWVkIHRvIGFkZHJlc3Mg YWxsIHRoZSBjb21iaW5hdGlvbnMgb2YgVExTIGFuZCBIVFRQIHZlcnNpb25zIChhbmQgSSBiZWxp ZXZlIHRoZSBhbHRlcm5hdGl2ZXMgcHJvcG9zZWQgc28gZmFyIGRvbid0KS4gQWxzbywgdGhlcmUg c2hvdWxkIGJlIHNvbWUgd2F5IHRvIGVuY2Fwc3VsYXRlIHRoZSBhbHRlcm5hdGl2ZXMgc3VjaCB0 aGF0IHNpdGVzIGRvbid0IG5lZWQgdG8gZm9yayBjbGllbnQgYXV0aCBjb2RlIGZvciBkaWZmZXJl bnQgVExTICsgSFRUUCB2ZXJzaW9uIGNvbWJpbmF0aW9ucy4gTmV4dCwgaXQgaXMgbm90IGRlc2ly YWJsZSB0byBhZGQgbGF0ZW5jeSBjb21wYXJlZCB3aXRoIHRoZSBleGlzdGluZyBzb2x1dGlvbi4g QW5kIGlmIHdlIGNhbiBnZXQgdGhpcyB0byB3b3JrIGZvciBhbGwgYXBwbGljYXRpb24gcHJvdG9j b2xzIChub3QganVzdCBIVFRQKSwgZXZlbiBiZXR0ZXIuIEhvcGVmdWxseSB0aGUgcmVzdWx0IHdp bGwgcHJvdmUgdG8gYmUgd29ydGggdGhlIGRlc2lnbiBhbmQgaW1wbGVtZW50YXRpb24gZWZmb3J0 OikuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4gVGhvbXNvbiBb bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0gDQpTZW50OiBNb25kYXksIEp1bHkgMjgs IDIwMTQgMjowMiBQTQ0KVG86IEFuZHJlaSBQb3Bvdg0KQ2M6IFJvYmVydCBSYW5zb207IFNlYW4g VHVybmVyOyBUTFNAaWV0Zi5vcmcgKHRsc0BpZXRmLm9yZykNClN1YmplY3Q6IFJlOiBbVExTXSB0 bHMgMS4zOiByZW5lZ290aWF0aW9uDQoNCk9uIDI4IEp1bHkgMjAxNCAxMzoxMSwgQW5kcmVpIFBv cG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+IEl0IGxvb2tzIGxpa2Ug b25lIHdvdWxkIG5lZWQgdG8gZGVwbG95ICBib3RoIFRMUzEuMyBhbmQgSFRUUC8yIGF0IHRoZSBz YW1lIHRpbWUuIE9uY2UgVExTIDEuMyBhbmQgSFRUUC8yIGFyZSBkZXBsb3llZCwgdGhlIHdheSBh IHNpdGUgaW1wbGVtZW50cyBUTFMgY2xpZW50IGF1dGggd2lsbCBkZXBlbmQgb24gdGhlIGNvbWJp bmF0aW9uIG9mIFRMUyB2ZXJzaW9uIGFuZCBIVFRQIHZlcnNpb24gbmVnb3RpYXRlZDoNCj4gVExT MS4zICsgSFRUUC8yIC0+IE5ldy1zdHlsZSBUTFMgY2xpZW50IGF1dGggKFRCRCkuDQo+IFRMUzEu MyArIEhUVFAvMS4xIC0+IE5vIHdheSB0byBzdXBwb3J0IFRMUyBjbGllbnQgYXV0aD8NCj4gVExT MS4yICsgSFRUUC8yIC0+IE5vIHdheSB0byBzdXBwb3J0IFRMUyBjbGllbnQgYXV0aD8NCj4gVExT MS4yICsgSFRUUC8xLjEgLT4gVExTIGNsaWVudCBhdXRoIHZpYSByZW5lZ290aWF0aW9uLg0KDQpD bGllbnQgYXV0aGVudGljYXRpb24gaXMgc3RpbGwgcG9zc2libGUsIGl0IGp1c3QgaGFzIHRvIGNv bWUgaW4gdGhlIG9wZW5pbmcgaGFuZHNoYWtlLiAgWW91ciBjb25jZXJuIGlzIHNwb250YW5lb3Vz IGNsaWVudCBhdXRoZW50aWNhdGlvbi4NCg0KSFRUUC8yIGZvcmJpZHMgcmVuZWdvdGlhdGlvbiBl bnRpcmVseSwgYnV0IHBlcm1pdHMgaXQgYmVmb3JlIEhUVFAvMiBzdGFydHMgKHRvIGFsbG93IGZv ciBjbGllbnQgY2VydGlmaWNhdGUgY29uZmlkZW50aWFsaXR5LCBpZiB0aGF0IGlzIGRlc2lyZWQp Lg0KDQpUaGF0IG1lYW5zIHRoYXQgZm9yIEhUVFAvMiBhdCBsZWFzdCwgdGhlIG5lZWQgaXNuJ3Qg dGhlcmUuICBUaGV5IGFyZSBhbHJlYWR5IGxvb2tpbmcgZm9yIGFsdGVybmF0aXZlcy4NCg0KQW5k IGl0J3Mgbm90IHRoYXQgYWx0ZXJuYXRpdmVzIGRvbid0IGV4aXN0LCBpdCdzIG1vcmUgdGhlIGNh c2UgdGhhdCB3ZSBkaXNhZ3JlZSBvbiB0aGUgdmlhYmlsaXR5IGFzcGVjdHMsIEkgdGhpbmsuDQo= From davemgarrett@gmail.com Mon Jul 28 13:24:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62A01A00EB for ; Mon, 28 Jul 2014 13:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CaeFdmsN2Rd for ; Mon, 28 Jul 2014 13:24:15 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71EC1B28FE for ; Mon, 28 Jul 2014 13:24:14 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id f51so9275958qge.18 for ; Mon, 28 Jul 2014 13:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=fYBc4JnZX5B53ABxlZBjdRWDEe15DaMDnXX7Fkfu/c4=; b=RU14NmkX7kr/wdsaJB8sFKl/pLIEs+5ih3Ovd9ft7V95nMAdUaBVBMa9I03+rKNyAr PjCHEk3Rrcn5bFq+gREE7gWxKN+xurohI6EytnwLycALAxbYkffVC+PKqkSf379MOw0D Ul4uKl2dS74O12ZAeHFSvmEaFuhj96BDzJs5V97yQlTD1h9Ba6rfNpshzoCdu3AYVk8M txSBBLrqTAR00nKDesq+d3/4FIUMdGVBsrvlusSmxYffXJ56Oyx8WOaCkceabt8cRViA PRBoloefFrM0+I9eEuPEfMit+PuYTmWWNFaVu9+Bfm2s0vilEr1+NtxkSeCj4ejNx6J6 yUsQ== X-Received: by 10.140.41.133 with SMTP id z5mr64966634qgz.99.1406579052575; Mon, 28 Jul 2014 13:24:12 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. [72.78.212.218]) by mx.google.com with ESMTPSA id c16sm31339540qae.49.2014.07.28.13.24.12 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 28 Jul 2014 13:24:12 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Mon, 28 Jul 2014 16:24:10 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-62-generic-pae; KDE/4.4.5; i686; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201407281624.10986.davemgarrett@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eEO2G_81b2vLLyScV2Hdl59vHqc X-Mailman-Approved-At: Mon, 28 Jul 2014 15:40:40 -0700 Subject: [TLS] PRF in 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 20:26:29 -0000 https://github.com/tlswg/tls13-spec/issues/26 Issue #26 notes complication with the usage of a negotiable PRF. The current suggestion mentioned was to consider removing PRF negotiation in favor of SHA-256, calling it "good enough" until the next protocol version. I agree that this is quite possibly the case, however I would like to suggest future proofing things a bit. Old versions of TLS used the strategy of dual hash algorithms "to ensure that non-catastrophic flaws in one algorithm will not break the overall protocol" [RFC4346 F.1.5]. TLS 1.1 used MD5+SHA1. For TLS 1.3, I would like to suggest SHA2-256+SHA3-256 or similar for consideration. Picking a single combo allows the removal of negotiation, fixing any issues that causes, provides a simpler spec for this feature, and allows both the current standard and new SHA functions to be used without having to rely 100% on either. Adoption rates of new TLS versions are less than ideal, so future proofing in manners like this that don't add a fantastic amount of additional complexity seems like an idea worth consideration. - Dave From nobody Mon Jul 28 15:46:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD971A02E2 for ; Mon, 28 Jul 2014 15:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XwBkfhFsgBB for ; Mon, 28 Jul 2014 15:46:21 -0700 (PDT) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EE691A0092 for ; Mon, 28 Jul 2014 15:46:21 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id rd3so11284406pab.14 for ; Mon, 28 Jul 2014 15:46:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3TDNZhR6gzuLTKcGs1ZupZEu+NUtpOquW/qgBou0jhA=; b=BGXBsKr1x17kj2l+qwaYSINPabGYDXWFjtlotfqi9inaTV/phoeV5Ha7O22iRU0AK6 IZuZ0xydG1goiEAW/G2mmUrKLlosrU+UnNDGIe36Dou8Hfft89N0j/TA2UH7Mej64R6m e2tWN+RT6DTBy6w32HrjTGKX6/d+ync4kv8ICSK6OW9vi45h1FrHgj0/kYpAD7s0KIXa 5tjMTadeavot/WTNPvsfP+IfOc2xs4OF5ZT+kJLiYq2koOAhjWz9s0zqj1d9wtysajKh QNcXJaUsZpsfNCBK3PyGQnNizltZYb/K+ZZln6Yd4yEX3BiNMT9fIYozSWU9MBSMSrb2 dggQ== X-Gm-Message-State: ALoCoQkMf8zCbShqxPJ28+QYwAl/dWUlXw7ZVw6nebau8hnSUQSLVObTJ68YE+Fw4tIGWfuJM6YL X-Received: by 10.66.152.171 with SMTP id uz11mr9219796pab.96.1406587581158; Mon, 28 Jul 2014 15:46:21 -0700 (PDT) Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id ml5sm70964638pab.10.2014.07.28.15.46.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 15:46:19 -0700 (PDT) Message-ID: <53D6D2BA.6010303@amacapital.net> Date: Mon, 28 Jul 2014 15:46:18 -0700 From: Andy Lutomirski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Yoav Nir , Nikos Mavrogiannopoulos References: <1406537753.2413.12.camel@dhcp-2-127.brq.redhat.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eABGJSDcurRHUyqgxuANnmSxni0 Cc: "" Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2014 22:46:23 -0000 On 07/28/2014 03:52 AM, Yoav Nir wrote: > > On Jul 28, 2014, at 11:55 AM, Nikos Mavrogiannopoulos wrote: > >> On Sat, 2014-07-26 at 10:59 -0700, Colm MacCárthaigh wrote: >>> On Sat, Jul 26, 2014 at 10:43 AM, Watson Ladd >> wrote: >>>> This is a change with no rationale: the content type leaks extremely >>>> limited information. It complicates implementations that wish to >> keep >>>> a high degree of codepath similarity between TLS 1.2 and TLS 1.3. >>> Leaking alert messages has been a recurring theme common to several >>> attacks; hindering a MITM's ability to discern alert messages seems >>> like a rational rationale. >> >> Are there any pointers to these attacks? Will these attacks be countered >> with such a change? I believe not as alert messages consist of only two >> bytes and will be distinct from any other higher protocol messages >> transferred by the TLS record protocol. Unless TLS 1.3 intended to >> include a length hiding mechanism I see this change as unnecessary and I >> agree with Watson on that. > > While no definite decisions were made, there was a positive response to the idea of allowing arbitrary length padding to the plaintext in all encrypted records, which can be used to hide alert messages. > > Of course, non-fatal alerts are (1) rare, and (2) not always treated as such, so it’s easy to spot the alert record, because it’s the one before the FIN or RST. In DTLS alerts are mostly non-fatal, so it makes more sense. > > So on balance, +1. To clarify the relationship between encrypted content types and padding: In order to pad messages, we need to encode the amount of padding somehow so that the receiver can strip the padding. That means that an unpadded message has to be distinguishable (by the peer) from a padded message. If we can steal a bit from the content type to indicate the presence of a nonzero amount of padding, then we can do this with no size overhead for unpadded messages. For this to work, the content type must be encrypted. --Andy From nobody Mon Jul 28 16:05:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B39A1A0347 for ; Mon, 28 Jul 2014 16:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMIx7uFtyDXZ for ; Mon, 28 Jul 2014 16:05:46 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0F0D1A0318 for ; Mon, 28 Jul 2014 16:05:45 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id n12so8128285wgh.9 for ; Mon, 28 Jul 2014 16:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QgpjcAps+CL8gXMyYpatptjjZ2YWoFZRxEwVZGf3BEU=; b=Ui6MHYdhQiXcB9KPy+EU+NpZbx2gyucnmkH0UtYS0LhiB+uNjcr3sLoLCqI3gMQD3t 5DiFS+hJt4tbrjcvLNZE4Y7nCl6RbkGbftTiG70+kItCtQREIFJatJemxqDYIi02Ists X1GQeUXJa7aEmumG0pD6ZuGsVfCe4SlMEsERBLXxdN0WToPJAp0+UVgrI2B8GWr51s05 LPx9DL8VQitf0NOWDxOVhMLZCwvB25vVxcvN/BV8HtuyzIk++IhnnVqwZHn2f8gf+Poz mtp9RmCeOCrWsbsdw1Zlb7dygKoXXHH3sGoNOnuMqACgefKk92d0YCIBtmsTWROf4EAp IQbg== MIME-Version: 1.0 X-Received: by 10.194.185.238 with SMTP id ff14mr54842263wjc.9.1406588744440; Mon, 28 Jul 2014 16:05:44 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Mon, 28 Jul 2014 16:05:44 -0700 (PDT) In-Reply-To: <52de31491a51434ca4dc6cbbdda1d004@BL2PR03MB419.namprd03.prod.outlook.com> References: <7C3D5CF9-2B17-4953-A13D-C5E7226D13E7@ieca.com> <52de31491a51434ca4dc6cbbdda1d004@BL2PR03MB419.namprd03.prod.outlook.com> Date: Mon, 28 Jul 2014 16:05:44 -0700 Message-ID: From: Martin Thomson To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2gG-uxqfKhG9PsOvZ0NhSLlIgrU Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tls 1.3: renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 23:05:47 -0000 On 28 July 2014 15:24, Andrei Popov wrote: > Are you saying that because HTTP/2 designers chose to ban renegotiation, = the customers no longer need to perform TLS client auth in the middle of a = connection? Perhaps I'm missing this point. > >> And it's not that alternatives don't exist, it's more the case that we d= isagree on the viability aspects, I think. > The alternatives would need to address all the combinations of TLS and HT= TP versions (and I believe the alternatives proposed so far don't). Also, t= here should be some way to encapsulate the alternatives such that sites don= 't need to fork client auth code for different TLS + HTTP version combinati= ons. That's fairly straightfoward. My strawman proposal is protocol-version-agnostic. > Next, it is not desirable to add latency compared with the existing solut= ion. And if we can get this to work for all application protocols (not just= HTTP), even better. Hopefully the result will prove to be worth the design= and implementation effort:). I'm less sensitive to latency in these cases. With a 0-RTT handshake, it could be that HTTP/2 on a new connection would be faster than what currently occurs, since from the point of HelloRequest, the server needs to wait for two RTT from the client before it can send data. (If the request contains a body that doesn't fit into the first flight congestion window, then I might concede that it is slower.) From nobody Mon Jul 28 16:20:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311C41A038D for ; Mon, 28 Jul 2014 16:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkEh8Qy60BJC for ; Mon, 28 Jul 2014 16:20:16 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C69681A0386 for ; Mon, 28 Jul 2014 16:20:15 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hi2so90543wib.5 for ; Mon, 28 Jul 2014 16:20:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wBq9glM3L51EMaDcQfkRQsgATVpSvAs2jDz7XTJJFwA=; b=SsRF2MnUxuvBv3vq6kzeqxtt+ZzdhpGKIpPG0u5tj3wSRJp37gBCqJq/tY1O6m2S2+ GxRw6taJcsmuZAqML5k5fozYU+1dqfjkpr5YAKpBi0tR+Zr9WZTB+lAa6eF2EyDcb8w3 LtfZjgViR0Uf6yi+gh6v1TedUbYkt2SCm3aKylByXF2lUEHrXRRqTSrNSOiqxA5q1z5W syZaXdKvuWc4oxJSVzT+UOjC67pKClqQ/tg42fZAJ2nXGW2h4mYHhy5feW/w2mX2nLes 9yhp9ySotUw7SaWzAG4GeN25aLspcpS2k1wk1QqZGs1F4bWKk0n5l/G1DFer3t4Y6LnZ TEXA== MIME-Version: 1.0 X-Received: by 10.180.103.74 with SMTP id fu10mr443930wib.47.1406589614412; Mon, 28 Jul 2014 16:20:14 -0700 (PDT) Received: by 10.194.110.6 with HTTP; Mon, 28 Jul 2014 16:20:14 -0700 (PDT) In-Reply-To: References: <7C3D5CF9-2B17-4953-A13D-C5E7226D13E7@ieca.com> Date: Mon, 28 Jul 2014 16:20:14 -0700 Message-ID: From: Martin Thomson To: Robert Ransom Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PPmbwBAX1s-gXl0kLV5_E8kNofE Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tls 1.3: renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 23:20:17 -0000 On 28 July 2014 15:03, Robert Ransom wrote: > So you don't even have a consensus on what =E2=80=9Crekeying=E2=80=9D wil= l mean. That's step 2. Do you think that this has a material impact on the outcome of this call? (I'm guessing not.) > I gave a list of four use cases that can be (and are currently) > addressed by renegotiation a while back. I can't find these. > Renegotiation is a particularly elegant solution to several problems. > It requires little extra code beyond what is already used to perform > the initial handshake, and adding a (correctly designed) channel > binding as input to the renegotiation process will add the security > properties that some API and application developers had previously > expected renegotiation to provide. It might be conceptually elegant, but it's certainly not free. Even within NSS, the number of "if we are renegotiating" branches is pretty large. And fixing NSS is relatively easy. It's the externalities renegotiation creates that are the larger problem. Because API and application developers don't look for particular properties, the problem is with the assumptions, once of which is generally immutability of various properties. From nobody Tue Jul 29 00:27:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2F31A026A for ; Tue, 29 Jul 2014 00:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-q_u7Qmy7ya for ; Tue, 29 Jul 2014 00:27:42 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5BC21A009E for ; Tue, 29 Jul 2014 00:27:42 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6T7RecB007481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 29 Jul 2014 03:27:40 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6T7RcVU008027 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 29 Jul 2014 03:27:40 -0400 Message-ID: <1406618858.31179.4.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Martin Thomson Date: Tue, 29 Jul 2014 09:27:38 +0200 In-Reply-To: References: <7C3D5CF9-2B17-4953-A13D-C5E7226D13E7@ieca.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tEyI6NIvFFo7ulGYhZdRH9os7s8 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tls 1.3: renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 07:27:44 -0000 On Mon, 2014-07-28 at 16:20 -0700, Martin Thomson wrote: > > Renegotiation is a particularly elegant solution to several problems. > > It requires little extra code beyond what is already used to perform > > the initial handshake, and adding a (correctly designed) channel > > binding as input to the renegotiation process will add the security > > properties that some API and application developers had previously > > expected renegotiation to provide. > It might be conceptually elegant, but it's certainly not free. Even > within NSS, the number of "if we are renegotiating" branches is pretty > large. > > And fixing NSS is relatively easy. It's the externalities > renegotiation creates that are the larger problem. Because API and > application developers don't look for particular properties, the > problem is with the assumptions, once of which is generally > immutability of various properties. Then please fix the provided by NSS API to make these assumptions explicit to the applications rather than arguing to change the protocol for everyone. regards, Nikos From nobody Tue Jul 29 05:48:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9571B2830 for ; Tue, 29 Jul 2014 05:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.332 X-Spam-Level: X-Spam-Status: No, score=0.332 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rFv5uRu8gef for ; Tue, 29 Jul 2014 05:48:55 -0700 (PDT) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [67.18.68.4]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB4A61A03EF for ; Tue, 29 Jul 2014 05:48:55 -0700 (PDT) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id E766B7249CC19; Tue, 29 Jul 2014 07:48:54 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 728F172496406 for ; Tue, 29 Jul 2014 07:48:29 -0500 (CDT) Received: from [96.231.227.95] (port=57526 helo=[192.168.1.18]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XC6pQ-0003c7-Pw for tls@ietf.org; Tue, 29 Jul 2014 07:48:29 -0500 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Tue, 29 Jul 2014 08:48:24 -0400 To: "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.227.95 X-Exim-ID: 1XC6pQ-0003c7-Pw X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.18]) [96.231.227.95]:57526 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/njky8Be3DYdXOlh-dp75j7BWOCk Subject: [TLS] WGLC: draft-ietf-tls-cached-info X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 12:48:57 -0000 This is the working group last call for draft-ietf-tls-cached-info: http://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ Please send comments on this draft to the TLS list before August 19, 2014. J&S From nobody Tue Jul 29 05:51:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4DF21A040B for ; Tue, 29 Jul 2014 05:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qN2MIiwtk_GK for ; Tue, 29 Jul 2014 05:51:23 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739FA1B2830 for ; Tue, 29 Jul 2014 05:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1406638282; x=1438174282; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=1rijapkFrOL/aELMHcYgjrx9XkrbHFfQHew+0n291C4=; b=u9LZM+LBS/YHnT4kBVYKDXqu1TOrRheCkzLd4w8jXcCQ2NnLm2vnx9wk HpC2TcS7nh7EvyWOwwuHjvEwUssskAD3Dny1bLUZmSJ2H49yjWCuU7EHo Si/IcuePVU5DUrCu5LY/ndkMQZ3pI+TDwrK8UYOtqHKWECsDrO3kaaQjn Q=; X-IronPort-AV: E=Sophos;i="5.01,757,1399982400"; d="scan'208";a="266220012" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 30 Jul 2014 00:51:21 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.247]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Wed, 30 Jul 2014 00:51:20 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] Encryption of TLS 1.3 content type Thread-Index: Ac+rK8swZviVcUl9RXmz16/tE10sdQ== Date: Tue, 29 Jul 2014 12:51:19 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738EFB2448@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/99AkbXpc4SXqGAvZOUN4RqKDlWw Subject: Re: [TLS] Encryption of TLS 1.3 content type X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Jul 2014 12:51:29 -0000 Viktor Dukhovni writes:=0A= =0A= >Yes, some application application protocols do send short messages, for=0A= >example SMTP an server may reply "250 2.0.0 OK\r\n". However, (fatal) ale= rts=0A= >often terminate the connection and are easily distinguished from routine= =0A= >traffic.=0A= >=0A= >In chatty protocols, like SMTP, TLS masks the specific content, but not th= e=0A= >overall flow or size of messages. One can often tell which application da= ta=0A= >messages carry "EHLO", "MAIL", "RCPT", "DATA" and the message payload,=0A= >despite the use of TLS. The attacker does not learn very much, but may be= =0A= >able to estimate the recipient count, even with ESMTP PIPELINING and of=0A= >course can estimate the message size fairly well.=0A= =0A= +1 (saves me typing up the same thing :-).=0A= =0A= Peter.= From nobody Tue Jul 29 06:10:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16881B288F for ; Tue, 29 Jul 2014 06:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_g7RiMzQfh4 for ; Tue, 29 Jul 2014 06:10:31 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4181B288C for ; Tue, 29 Jul 2014 06:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1406639431; x=1438175431; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=lk+ON9jvPtSY0dfiX4IyT3h2HaqCXlSEny7zuqYd0Co=; b=iVHbZWN27365ts0oJ+xrLv6s4IwF5jAzAOj1lBX0JOhi4eadnab5U1o1 JDB6LkCf2TuVSWYNUfvwkiY7SoFxMefU2iklug/8fWIqYHAljQOGWN/2t ZrcUJ5jQ5ouRXRWLWSoXOxd7jUv5unVdowhfkn6elva4mHisg0ZSutT1x U=; X-IronPort-AV: E=Sophos;i="5.01,757,1399982400"; d="scan'208";a="266221078" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 30 Jul 2014 01:10:29 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.247]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Wed, 30 Jul 2014 01:10:28 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.txt Thread-Index: Ac+rLneaIDKRPxLtSG2nX15VP8eJJw== Date: Tue, 29 Jul 2014 13:10:28 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C738EFB24A6@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uqlaHmQMBtBiNbCLBgqHPbCgwrk Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 13:10:36 -0000 Daniel Kahn Gillmor writes:=0A= =0A= >There's a possibility that a very expensive (e.g. precomputation) attack= =0A= >exists that can be mounted against any given group. If we reuse the same= =0A= >group used by other mechanisms (e.g. ipsec) then the value for mounting su= ch=0A= >an expensive attack goes up.=0A= >=0A= >Selecting a different group forces an attacker to choose which group to=0A= >attack.=0A= =0A= Yeah, I can see that, but it's a bit of a hypothetical attack, we have no w= ay=0A= to quantify the risk. For something like "don't use the same key to encryp= t=0A= and MAC" there's a clear, well-known threat, but for "don't use the same ke= y=0A= (DH group) for IPsec and TLS" it's really just speculation. Once you start= =0A= down this path, where do you stop?=0A= =0A= >This was based on the 112-bit symmetric equivalence published by ECRYPT II= .=0A= >The ECRYPT document is referenced in the draft.=0A= =0A= Is there really any good reason to want to match group size to algorithm ke= y=0A= sizes, and (I'm assuming for a 112-bit key) one for an obsolete (if still= =0A= widely-used) block cipher? I'd just pick some standard group sizes (1K, 2K= ,=0A= 3K, 4K) and go with those as general-purpose solutions rather than selectin= g=0A= oddball sizes to match some particular other algorithm.=0A= =0A= (Where did the fashion of specifically choosing the hat to match the shoes= =0A= come from in crypto? AFAIK it's NSA-originated from things like the origin= al=0A= DSA's hardcoding of the SHA-1 blocksize into the algorithm, and KEA and=0A= Skipjack key sizes. I've never been able to understand why something like = a=0A= particular cipher block size needs an entire range of fashion accessories t= o=0A= go with it, if an n-bit prime is good enough for a 256-bit symmetric algori= thm=0A= then it should also be good enough for 128 bits, 192 bits, and 77 1/2 bits)= .=0A= =0A= >by q i think you mean (p-1)/2 -- i'm happy to document those values=0A= >explicitly in the draft if you think that would be useful.=0A= =0A= Yes, thanks.=0A= =0A= Peter.= From nobody Tue Jul 29 07:09:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1241A02F3 for ; Tue, 29 Jul 2014 07:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.096 X-Spam-Level: X-Spam-Status: No, score=-0.096 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, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Eo1zCZADz8j for ; Tue, 29 Jul 2014 07:09:20 -0700 (PDT) Received: from smtp-01-out.s.azet.sk (smtp-07-out.s.azet.sk [91.235.53.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5EE1B2889 for ; Tue, 29 Jul 2014 07:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=azet.sk; s=azet; t=1406642931; bh=XCcAvq3jcRr68jN4gLjCxetCQYlsOoFmRcXX/awPDoM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=LIx6XlFfX6eTWi95hfDWOxG0bDkmmuEku+wI0ZiDgibesBBLEitH+BAXIBO4etbRx x8CuRzSp5G8Ntg8FB7YHQdxk/TIJWLVtLVFzHbu6jKH+hF2X2cpu+DILfBvnWU73Hg mzF7FZZj1DBJqf6H7RlIM9lDdYtNbPkABi6wtCO8= X-Virus-Scanned: by AntiSpam at azet.sk X-SenderID: Sendmail Sender-ID Filter v1.0.0 smtp.azet.sk CC6F08B Authentication-Results: smtp.azet.sk; sender-id=fail (NotPermitted) header.from=fedor.brunner@azet.sk; auth=pass (PLAIN); spf=fail (NotPermitted) smtp.mfrom=fedor.brunner@azet.sk Message-ID: <53D7AAEB.7090309@azet.sk> Date: Tue, 29 Jul 2014 14:08:43 +0000 From: Fedor Brunner MIME-Version: 1.0 To: tls@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C738EFB24A6@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738EFB24A6@uxcn10-5.UoA.auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/beWKXAhguDTpgSTLL1AtGaQI8Gc Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 14:09:22 -0000 Peter Gutmann: > Daniel Kahn Gillmor writes: > >> There's a possibility that a very expensive (e.g. precomputation) attack >> exists that can be mounted against any given group. If we reuse the same >> group used by other mechanisms (e.g. ipsec) then the value for mounting such >> an expensive attack goes up. >> >> Selecting a different group forces an attacker to choose which group to >> attack. > > Yeah, I can see that, but it's a bit of a hypothetical attack, we have no way > to quantify the risk. For something like "don't use the same key to encrypt > and MAC" there's a clear, well-known threat, but for "don't use the same key > (DH group) for IPsec and TLS" it's really just speculation. Once you start > down this path, where do you stop? > If we assume an attack exists for fixed DH group then not fixed DH groups generated for each server (as is current option in TLS) would make the attack much more expensive. In RFC 4253 (The Secure Shell (SSH) Transport Layer Protocol) 1024-bit MODP Group, 2048-bit MODP Group are used. But the newer RFC 4419 allows to use arbitrary safe primes. For example OpenSSH supplies a set of 40 DH groups for each 1023, 1535, 2047, 3071, 4095, 6143, 8191-bit primes . During key exchange one of these groups with desired size is selected in server by random. The OpenSSH server administrator can also generate his own set of DH parameters, for each prime length. OpenSSH supports also elliptic curve Diffie-Hellman key agreement using NIST curves and Curve25519. >> This was based on the 112-bit symmetric equivalence published by ECRYPT II. >> The ECRYPT document is referenced in the draft. > > Is there really any good reason to want to match group size to algorithm key > sizes, and (I'm assuming for a 112-bit key) one for an obsolete (if still > widely-used) block cipher? I'd just pick some standard group sizes (1K, 2K, > 3K, 4K) and go with those as general-purpose solutions rather than selecting > oddball sizes to match some particular other algorithm. > > (Where did the fashion of specifically choosing the hat to match the shoes > come from in crypto? AFAIK it's NSA-originated from things like the original > DSA's hardcoding of the SHA-1 blocksize into the algorithm, and KEA and > Skipjack key sizes. I've never been able to understand why something like a > particular cipher block size needs an entire range of fashion accessories to > go with it, if an n-bit prime is good enough for a 256-bit symmetric algorithm > then it should also be good enough for 128 bits, 192 bits, and 77 1/2 bits). > >> by q i think you mean (p-1)/2 -- i'm happy to document those values >> explicitly in the draft if you think that would be useful. > > Yes, thanks. > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Jul 29 10:37:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00611B2949 for ; Tue, 29 Jul 2014 10:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wa5acV6bHBMD for ; Tue, 29 Jul 2014 10:37:20 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0CF71B293E for ; Tue, 29 Jul 2014 10:37:19 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id ty20so6755528lab.4 for ; Tue, 29 Jul 2014 10:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oTuajWWGUBbzWsVqhYlmNkmi4itTtu1i/galbEME48E=; b=euD/u13q2T3JekoxBYtuFRdZmxfAw+BJA3j/UsuiHBgn/iOtp90542FF3ZcSsg388p MZu4fFYw7J5aFcydF3FLFousRWGYsmdxF+OZYPU1ajRMlgXsG7zDyXdmzbGqmV1wspfE /0+UuMsmotl2/t3A9mA6/HEbmn+2gP8eUblfjMmvbok39FVX83iQcz1auixU1JOAjE4a 5FtQvomc3g5G/L85lbxFAlr+e5Cx5WbZAteFcpTKDgndVbNUdzbTKFOs9/2btmAVdMV7 ijI1MK8b1uB2wowh7XFhH5G36b+7whEsmKDI0eCAYVyVPQ97V7za4pn+1KLgXbuO8hO6 KCSw== MIME-Version: 1.0 X-Received: by 10.112.63.168 with SMTP id h8mr3641383lbs.69.1406655437509; Tue, 29 Jul 2014 10:37:17 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.170.37 with HTTP; Tue, 29 Jul 2014 10:37:17 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Jul 2014 10:37:17 -0700 X-Google-Sender-Auth: hgOt_KcfMzLpBPwM42inEXlqyaQ Message-ID: From: Adam Langley To: Sean Turner Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/f5Zj05oZLm-zOeLjy4ivnSvkykQ Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WGLC: draft-ietf-tls-cached-info X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 17:37:24 -0000 On Tue, Jul 29, 2014 at 5:48 AM, Sean Turner wrote: > This is the working group last call for draft-ietf-tls-cached-info: > http://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ > Please send comments on this draft to the TLS list before August 19, 2014. It's been quite a while since this has appeared! As an implementer, I still think there are ambiguities in the draft, although I might just be dumb. If I'm not being dumb then I don't think this draft is ready. Can I send multiple CachedObjects with the same CachedInformationType? Nothing seems to forbid it and the draft hints that it's expected: > Note: If clients make use of the Server Name Indication [RFC6066] > then clients may need to cache multiple data items for a single > server since servers may host multiple 'virtual' servers at a single > underlying network address. That's cool, but if I offer multiple certificate_chain CachedObjects, how do I know which the server is using if it omits it? Does it echo the one that it wants to use in its CachedObjects? In that case, I assume that it's invalid for a server to send multiple CachedObjects with the same CachedInformationType? The draft suggests otherwise however: > By > returning the "cached_information" extension the server indicates > that it supports caching of each present CachedObject that matches > the specified hash value. That suggests to me that the server's CachedObjects are just indications about what types it supports. (But then why do they include hash values? Does a client have to echo the CachedObject exactly? I.e. with the same HashAlgorithm and hash value?) The draft also says: > Following a successful exchange of the "cached_information" > extensions in the client and server hello, the server omits sending > the corresponding handshake message. But it doesn't actually seem to. E.g. if the handshake is using cached certificates then the Certificate message isn't *omitted*, it's just altered: > How information is omitted from > the handshake message is defined per cached info type. Lastly, I think there are Triple Handshake worries in here: > The Finished message MUST be > calculated over the actual data exchanged in the handshake protocol. The triple handshake fix works by extending the master secret over the full handshake, including the server's identity. However, if the server's identity is being replaced with an MD5 hash (and MD5 is a value of HashAlgorithm[1]) then I think that might reintroduce the Triple Handshake problem. The draft says: > There is no requirement that this hash algorithm must > have strong collision resistance. I fear that this might be incorrect in the light of the Triple Handshake work. [1] https://tools.ietf.org/html/rfc5246#section-7.4.1.4.1 Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Tue Jul 29 11:45:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D7D1A0547 for ; Tue, 29 Jul 2014 11:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQNDsVHbTAlm for ; Tue, 29 Jul 2014 11:45:02 -0700 (PDT) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03D6A1A02DD for ; Tue, 29 Jul 2014 11:45:01 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id rd3so74227pab.28 for ; Tue, 29 Jul 2014 11:45:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=v/1HOUWSTb9BJWFRqcrEbhaEKq0uSVy458D9Fd6NgNE=; b=E2OaNRKpcfAlCpmX5xZijI/j7qJgL84nRhHVKdoII+UuL1tNgnSjfBcv4aYzvX6W+K LmXeEvxYIQeSZZch21/hSQ9FFEJDK6EC0wg2kYKZUEd87EJS+92xvTpIa/YaNiXXMop5 2TNaPiX0blBgjxv13+5LM4WlThD8jtoWP+Rv6vdXMJWwPRxGH6Sqa90WXVDd2/e+j832 sN1oMyp4CwzOb5Y1MfVOwR390LIEfzxt3TlNBaM/2gPNWxjW5OIJ8Bdk82cc+4No3br0 uI51JXKTUaTE8NfNv1sIJH5HU49AT2kvVpN/qE9wPaDLcaE8rYghZ6AQeh+gWNQU8Lq+ 1O5g== X-Gm-Message-State: ALoCoQmPZpnH/D2AD/HKVfDdNH43QgPPTSUrLAOD7Q71Zh/rE5YlUx35uayet3nI2X9SHDzPLN2F X-Received: by 10.70.98.232 with SMTP id el8mr3805537pdb.119.1406659501659; Tue, 29 Jul 2014 11:45:01 -0700 (PDT) Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id nt15sm30012552pdb.63.2014.07.29.11.44.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 11:45:00 -0700 (PDT) Message-ID: <53D7EBAA.1090705@amacapital.net> Date: Tue, 29 Jul 2014 11:44:58 -0700 From: Andy Lutomirski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dave Garrett , tls@ietf.org References: <201407281624.10986.davemgarrett@gmail.com> In-Reply-To: <201407281624.10986.davemgarrett@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Zgchb-P2J_zdbbLG79F3Pprb63g Subject: Re: [TLS] PRF in 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 18:45:04 -0000 On 07/28/2014 01:24 PM, Dave Garrett wrote: > https://github.com/tlswg/tls13-spec/issues/26 > > Issue #26 notes complication with the usage of a negotiable PRF. The > current suggestion mentioned was to consider removing PRF > negotiation in favor of SHA-256, calling it "good enough" until the next > protocol version. I agree that this is quite possibly the case, however > I would like to suggest future proofing things a bit. Old versions of TLS > used the strategy of dual hash algorithms "to ensure that > non-catastrophic flaws in one algorithm will not break the overall > protocol" [RFC4346 F.1.5]. TLS 1.1 used MD5+SHA1. For TLS 1.3, I > would like to suggest SHA2-256+SHA3-256 or similar for consideration. > Picking a single combo allows the removal of negotiation, fixing any issues > that causes, provides a simpler spec for this feature, and allows both the > current standard and new SHA functions to be used without having to > rely 100% on either. Adoption rates of new TLS versions are less than > ideal, so future proofing in manners like this that don't add a fantastic > amount of additional complexity seems like an idea worth consideration. I asked this on the CFRG list and didn't get too much of a response, but we could ask the CFRG to recommend a PRF. If so, I think that we should ask that it be a suitable hash combiner that provides whatever properties TLS needs (or would want for purpose of provable security) if *either* SHA3- or SHA2-256 is secure. There is a decent amount of literature on this, and the TLS 1.0 construction is *not* the way to do it. We could further request that the construction be immune to generic attacks even if SHA3 is completely broken. In particular, a SHA-3 break should not result in a length extension attack. I believe that there are multiple constructions here that would work. Also, IMO we should ask for it to be reasonably likely that breaking the PRF takes well over 2^128 effort to break, even with parallel attacks, and even with a quantum computer [1]. This particular part of TLS is easy to make post-quantum secure [2] and, if it can't be negotiated and we're considering using a new PRF, then let's get it right. In other words, I don't think it's time to fully specify how TLS 1.3 would work if the attackers have quantum computers, but we should be able to get decent-sized pieces of it right. That means at least using an appropriate PRF and having a mandatory-to-implement cipher with enough bits of key. [1] No 256-bit hash function is comfortably secure against collisions in a post-quantum world. There's a straightforward algorithm that will find a collision in 2^(256/3) hash queries. I suspect that there are similar issues with hash functions with smallish amounts of internal state. [2] As far as I know, and I did try to search the literature for it a couple years ago, there is no proof that *any* standard classical crypto construction still works against quantum adversaries. An n-bit random oracle indeed requires 2^(n/3) quantum queries to find a collision (the lower bound has a very nice proof), but there is no quantum analogue to, say, the Luby-Rackoff Theorem. On the other hand, there's no reason to suspect that anything better than generic oracle attacks against the entire PRF are particularly likely, so let's at least get that part right. --Andy From nobody Tue Jul 29 18:57:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1AC71B2A27 for ; Tue, 29 Jul 2014 18:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiXytPQicDqd for ; Tue, 29 Jul 2014 18:57:40 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9C31A0393 for ; Tue, 29 Jul 2014 18:57:40 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C5753165731 for ; Wed, 30 Jul 2014 01:57:39 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id B110216572D for ; Wed, 30 Jul 2014 01:57:39 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 8ACE098042 for ; Wed, 30 Jul 2014 01:57:39 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Tue, 29 Jul 2014 21:57:39 -0400 From: "Salz, Rich" To: "TLS@ietf.org (tls@ietf.org)" Date: Tue, 29 Jul 2014 21:57:37 -0400 Thread-Topic: SNI and ALPN -- which firsr? Thread-Index: Ac+rmUJS/ojzL4LKSxmvJQ1gYlxraw== Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C718599EDDDB@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C718599EDDDBUSMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zDRVYnkn3S99q1esycw9bIMIY4I Subject: [TLS] SNI and ALPN -- which firsr? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2014 01:57:41 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C718599EDDDBUSMBX1msgcorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is there a fixed order for processing a hello that has both ALPN and SNI? For example, if you do ALPN first, then the SNI might end up "pointing to" = a client with weaker ciphers than, say HTTP/2 allows. On the other hand, I can see the case that the SNI is protocol-specific, so= you should do ALPN first. Thoughts? Is this something we need to specify? Or give general advice fo= r the processing order of extzensions? -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rsalz@jabber.me Twitter: RichSalz --_000_2A0EFB9C05D0164E98F19BB0AF3708C718599EDDDBUSMBX1msgcorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is there a fixed= order for processing a hello that has both ALPN and SNI?

For example, if you do ALPN first, then the SNI might end= up “pointing to” a client with weaker ciphers than, say HTTP/2= allows.

On the other hand, I can see th= e case that the SNI is protocol-specific, so you should do ALPN first.=

 

Th= oughts?  Is this something we need to specify?  Or give general a= dvice for the processing order of extzensions?

 

-- 

Principal Security Engineer

Akamai Technologies, Cambridge MA

IM: rsalz@jabber.me Twitter: RichSa= lz

 

= --_000_2A0EFB9C05D0164E98F19BB0AF3708C718599EDDDBUSMBX1msgcorp_-- From nobody Tue Jul 29 22:22:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7EC1B2815 for ; Tue, 29 Jul 2014 22:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7b-__Z23QYDp for ; Tue, 29 Jul 2014 22:22:47 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 660BA1A0AFA for ; Tue, 29 Jul 2014 22:22:47 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s6U5MhSP003574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Jul 2014 07:22:43 +0200 (MEST) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C718599EDDDB@USMBX1.msg.corp.akamai.com> To: "Salz, Rich" Date: Wed, 30 Jul 2014 07:22:43 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140730052243.AF5081ADCB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ybo4ov2CYfGuzzVa3ez_BNw3y7M Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] SNI and ALPN -- which first? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 05:22:50 -0000 Salz, Rich wrote: > > Is there a fixed order for processing a hello that has both ALPN and SNI? No, I don't think so. > > For example, if you do ALPN first, then the SNI might end up "pointing to" > a client with weaker ciphers than, say HTTP/2 allows. > On the other hand, I can see the case that the SNI is protocol-specific, > so you should do ALPN first. > > Thoughts? Is this something we need to specify? > Or give general advice for the processing order of extensions? Technically, interference of protocol options could arise already between cipher suites and server certificates selected through SNI, or between Elliptic curves and server certificates selected through SNI, or a client's "Trusted CA" TLS extension http://tools.ietf.org/html/rfc3546#section-3.4 What you may want to offer depends on what you can describe and make configurable in a fashion that - your customers/consumers still understand the configuration - your clients/users still understand your server's behaviour - your support folks still have a chance to figure out what's going on if things don't work the way which users or admins expected it to. -Martin From nobody Wed Jul 30 07:02:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5084B1A0076 for ; Wed, 30 Jul 2014 07:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u84mQukFzB8K for ; Wed, 30 Jul 2014 07:02:07 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.93.126.20]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 776E81A007D for ; Wed, 30 Jul 2014 07:02:02 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id B8C71452B87C6; Wed, 30 Jul 2014 09:01:45 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 894FD452AFB88 for ; Wed, 30 Jul 2014 09:01:33 -0500 (CDT) Received: from [96.231.227.95] (port=60021 helo=[192.168.1.18]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XCURh-0006LT-0c for tls@ietf.org; Wed, 30 Jul 2014 09:01:33 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Wed, 30 Jul 2014 10:01:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0A94B681-AFAA-43FE-A814-0F2F4CE54FC7@ieca.com> References: <5A318D71-E491-490B-82D3-6D1BA3C60684@ieca.com> To: "TLS@ietf.org (tls@ietf.org)" X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.227.95 X-Exim-ID: 1XCURh-0006LT-0c X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.18]) [96.231.227.95]:60021 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0untnluTLuZyIFoTXA5BjEXp0Po Subject: Re: [TLS] adopted: draft-popov-tls-prohibiting-rc4-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2014 14:02:08 -0000 The one outstanding comment on the draft was to include the RC4 cipher = suites from the IANA registry. Andrei has now added that in Appendix A. = Is there anything else people need to have in this draft before it can = be progressed? spt On Jul 21, 2014, at 19:09, Andrei Popov = wrote: > Done. I've also updated Appendix A "RC4 Cipher Suites" with what I = believe is an exhaustive list of IANA-registered RC4 cipher suites. >=20 > Thanks, >=20 > Andrei >=20 > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Sean Turner > Sent: Monday, July 21, 2014 10:47 AM > To: TLS@ietf.org (tls@ietf.org) > Subject: [TLS] adopted: draft-popov-tls-prohibiting-rc4-02 >=20 > At the TLS interim held on 20140720, there wg consensus was = re-confirmed to adopt draft-popov-tls-prohibiting-rc4-02 . This is = consistent with the wg adoption call = (http://www.ietf.org/mail-archive/web/tls/current/msg11932.html). >=20 > Andrei, >=20 > Please submit your individual draft as = draft-ietf-tls-prohibiting-rc4-00. >=20 > spt > {for the chairs} > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Jul 30 07:09:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCEF1A0060 for ; Wed, 30 Jul 2014 07:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNCOqCgdrehO for ; Wed, 30 Jul 2014 07:09:42 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6A41A005D for ; Wed, 30 Jul 2014 07:09:42 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DC62048492; Wed, 30 Jul 2014 14:09:41 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id CFE2F4848E; Wed, 30 Jul 2014 14:09:41 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id AA44B98052; Wed, 30 Jul 2014 14:09:41 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Wed, 30 Jul 2014 10:09:41 -0400 From: "Salz, Rich" To: "mrex@sap.com" Date: Wed, 30 Jul 2014 10:09:40 -0400 Thread-Topic: [TLS] SNI and ALPN -- which first? Thread-Index: Ac+rtlAll1NtWrOLRLejs0AOnE6zLQASX03A Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C718599EDF28@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C718599EDDDB@USMBX1.msg.corp.akamai.com> <20140730052243.AF5081ADCB@ld9781.wdf.sap.corp> In-Reply-To: <20140730052243.AF5081ADCB@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EeKtQHhkWQRDtcAwGkUff32GloA Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] SNI and ALPN -- which first? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2014 14:09:44 -0000 > Technically, interference of protocol options could arise already Yes. I'm trying to find out if that's a general problem we should address. /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge MA IM: rsalz@jabber.me Twitter: RichSalz From nobody Wed Jul 30 07:57:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24551A016B for ; Wed, 30 Jul 2014 07:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JV1yXIoYfivk for ; Wed, 30 Jul 2014 07:57:24 -0700 (PDT) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBDB91A0111 for ; Wed, 30 Jul 2014 07:57:23 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id q107so1546542qgd.40 for ; Wed, 30 Jul 2014 07:57:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=Z8MXWdeL+5pEveAd3PSp4Lv98vlyBZp4v/5KsDote7M=; b=fwUA6k0uLWsvB+hKS00k/wWojz63/CO2Ze2cNVRaUCiPB+fc81rKmNcz3HhCUVZEeR opUki59qG4Fv1rOK6cjylXShD1n8qBoKuGiVdw5eIb8ZJIuDGYmER2pxbg4C/CLNwPqy IoFYjtZ9sRb9xFgd9gdhjKvX3z2SXqzquQTmf0C9cP/dQj1iEtcJBGkwjz2Pk33B9WNf 8O2g6RgHe8rF3QwEw3vtX57T7q4+lButfdkT1LamnfGiAWOlF4XyLSCFBXPqHsJhSfat r+zeE/WkUkPD/eKK6HyoqcnFjUO+1M7q5wyQQPEauh0jqk3aDxdBlkB/GzzF4iam6zZK 2XnQ== X-Gm-Message-State: ALoCoQlJbhnpJ9J5c8REZaMrZUN25fmIKTOWRH7Mi5+mIhgW/BwNgHq0XN2yg6P8cZTsPz2Cwo8Q X-Received: by 10.140.46.55 with SMTP id j52mr7268794qga.27.1406732242842; Wed, 30 Jul 2014 07:57:22 -0700 (PDT) Received: from [192.168.1.111] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id y8sm4380174qaf.33.2014.07.30.07.57.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 07:57:22 -0700 (PDT) Message-ID: <53D907B0.3000006@nthpermutation.com> Date: Wed, 30 Jul 2014 10:56:48 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "tls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eMQy40PHVy1UpzPt-mpJuE8i41Q Subject: [TLS] Premaster/Master convention X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2014 14:57:26 -0000 Given that TLS1.3 only does KeyAgreement, is there still any reason for the premaster -> master_secret derivation step? We do (KA)->premaster and then premaster -> master and then master->(session keys). We could probably do (KA)->master->(session keys) where the master secret is now the KA shared secret rather than premaster. 1) Is there any security reason for retaining the extra step given there is no longer a KeyTransport mechanism in TLS1.3? 2) Are there other *good* - non-security - reasons for retaining the extra step? Mike From nobody Wed Jul 30 08:02:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483631A0180 for ; Wed, 30 Jul 2014 08:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_0mdmOfG45Y for ; Wed, 30 Jul 2014 08:02:25 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 20A6B1A01BA for ; Wed, 30 Jul 2014 08:02:23 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A71EB165787; Wed, 30 Jul 2014 15:02:22 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 9C0F0165786; Wed, 30 Jul 2014 15:02:22 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 802E09805B; Wed, 30 Jul 2014 15:02:22 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Wed, 30 Jul 2014 11:02:22 -0400 From: "Gero, Charlie" To: 'Michael StJohns' , "tls@ietf.org" Date: Wed, 30 Jul 2014 11:02:20 -0400 Thread-Topic: [TLS] Premaster/Master convention Thread-Index: Ac+sBphYe7cjK6CITa2Kmo358gpmuQAAEcXQ Message-ID: References: <53D907B0.3000006@nthpermutation.com> In-Reply-To: <53D907B0.3000006@nthpermutation.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2phepUW4KWWwJWoxo6nsoq-iKM8 Subject: Re: [TLS] Premaster/Master convention X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2014 15:02:28 -0000 We have a number of technologies at Akamai that utilize the fact that the P= MS is split from the MS and that MS is produced in conjunction with the ran= doms. It allows us to do splitting between machines that have keys and tho= se that don't (machines in safe locales and those which are simply terminat= ors). I don't think we could use the same methods we use today without tha= t sub step. It would make it very difficult for Akamai to adopt 1.3. -----Original Message----- From: Michael StJohns [mailto:msj@nthpermutation.com]=20 Sent: Wednesday, July 30, 2014 10:57 AM To: tls@ietf.org Subject: [TLS] Premaster/Master convention Given that TLS1.3 only does KeyAgreement, is there still any reason for the= premaster -> master_secret derivation step? We do (KA)->premaster=20 and then premaster -> master and then master->(session keys). We could=20 probably do (KA)->master->(session keys) where the master secret is now the= KA shared secret rather than premaster. 1) Is there any security reason for retaining the extra step given there is= no longer a KeyTransport mechanism in TLS1.3? 2) Are there other *good* - non-security - reasons for retaining the extra = step? Mike _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Wed Jul 30 08:46:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC3A1A0190 for ; Wed, 30 Jul 2014 08:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSXv6gcPPUMk for ; Wed, 30 Jul 2014 08:45:56 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8AB1A0048 for ; Wed, 30 Jul 2014 08:45:55 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id a108so1713805qge.2 for ; Wed, 30 Jul 2014 08:45:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nOAvhUNGyP5UIwCVev3DNme41H7qDgwh3qFhugFDdfw=; b=KjDrEZUU5pr1Vyj9TgMqkP4jbt64Dl6Brncxr0/wjPZs4Ct2tRoVOk8wu1oxLwMiF6 yaXK1DxGviOIfCXPDKJMIopwY79lvodJMkvxqkLq11JGWWMa2Fde+VOhEtixoNIVEbXu DzP1mHcw2TJzcEryvbPHKl3Ak9nijBIfQO/9VMoT7EfyU8v29zd9kQt7KLBzQ6rgkj1x 6r6z3uS9EJxoP9jNZHYHxXALzgb0lBpeVGOfXWXyIn8XBLJvvUQI70TqvjbV8+LXHsnu OxEUFdge9cj/FHXxLdCUGi/rqu47gcwHD5rNt7urifj+YBdYhg/8siV30/8HVQUJg0PT 7LsQ== X-Gm-Message-State: ALoCoQmq0MnqFwgWhSsJS7nqC/W9vkJl+LRNejeOwDFCP3q6MqzFY2oMC6/P2LPR9bhVMaeUubrH X-Received: by 10.224.223.199 with SMTP id il7mr8455257qab.10.1406735154735; Wed, 30 Jul 2014 08:45:54 -0700 (PDT) Received: from [192.168.1.111] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id c16sm4557047qae.49.2014.07.30.08.45.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 08:45:53 -0700 (PDT) Message-ID: <53D91332.9070103@nthpermutation.com> Date: Wed, 30 Jul 2014 11:45:54 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Gero, Charlie" , "tls@ietf.org" References: <53D907B0.3000006@nthpermutation.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nJs3iBA8YP5Diu7z0xzbYyPSDFI Subject: Re: [TLS] Premaster/Master convention X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2014 15:45:59 -0000 On 7/30/2014 11:02 AM, Gero, Charlie wrote: > We have a number of technologies at Akamai that utilize the fact that the PMS is split from the MS and that MS is produced in conjunction with the randoms. It allows us to do splitting between machines that have keys and those that don't (machines in safe locales and those which are simply terminators). I don't think we could use the same methods we use today without that sub step. It would make it very difficult for Akamai to adopt 1.3. So you send the master secret from the handshaker machine out to several other machines which then do what with it? Couldn't you send the traffic keys instead? I'm not sure I understand the constraints you're working under. Could you expand on that? Thanks - Mike > > -----Original Message----- > From: Michael StJohns [mailto:msj@nthpermutation.com] > Sent: Wednesday, July 30, 2014 10:57 AM > To: tls@ietf.org > Subject: [TLS] Premaster/Master convention > > Given that TLS1.3 only does KeyAgreement, is there still any reason for the premaster -> master_secret derivation step? We do (KA)->premaster > and then premaster -> master and then master->(session keys). We could > probably do (KA)->master->(session keys) where the master secret is now the KA shared secret rather than premaster. > > 1) Is there any security reason for retaining the extra step given there is no longer a KeyTransport mechanism in TLS1.3? > 2) Are there other *good* - non-security - reasons for retaining the extra step? > > Mike > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > From nobody Wed Jul 30 08:52:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C59D1A00E9 for ; Wed, 30 Jul 2014 08:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcgFCkVd4umB for ; Wed, 30 Jul 2014 08:52:06 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B7F51A00D8 for ; Wed, 30 Jul 2014 08:52:06 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id f51so1743407qge.18 for ; Wed, 30 Jul 2014 08:52:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DRKmhhGAWtnR05KFXkqUrvkM4UhVColGAz9Q94CuhQI=; b=AMCEPYfpz/7HvnZOmno9u8grotd9F+TeyE3bq7QDNWBNpv0yrHkdMKejtWB/S9qgn1 AgSVnmBfm7Dbwo4YCT1JvMLS/I4Hwi60sducjwaQ7OfuFIiStFjLy0CIryHQ/5M1NA4B bGr4XLZMlD/A6Z7l95jwmg3jOHXsRvTQeV1V39GSO/J6Go4uz4TnyQBCuIqWJblYtymr d8UOuB0RR+iLOzszAICheeR9UoGUImnZkaRt734thEF46UvwUiWDW+CUmulEMBLaxGxy mf3z2LQg4XLmo/lIND3jgndCt+mi5YosExuPRzjxqLp+U2f0k5IT2enGfVmzBY3DOYFW u94g== X-Gm-Message-State: ALoCoQl/w0jZZs0c4KK3kWUShd6N8NOR+Ht/YiCtE/9NWw38xYmNk0i7Y+otSiMx6MkTH5zEOXqh X-Received: by 10.140.88.243 with SMTP id t106mr5505428qgd.12.1406735525138; Wed, 30 Jul 2014 08:52:05 -0700 (PDT) Received: from [192.168.1.111] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id s11sm4623743qag.12.2014.07.30.08.52.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 08:52:04 -0700 (PDT) Message-ID: <53D9147B.1080203@nthpermutation.com> Date: Wed, 30 Jul 2014 11:51:23 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <201407281624.10986.davemgarrett@gmail.com> In-Reply-To: <201407281624.10986.davemgarrett@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VWLl9Ezdb9Gp7x9y1U_5KiXmXNI Subject: Re: [TLS] PRF in 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 15:52:12 -0000 On 7/28/2014 4:24 PM, Dave Garrett wrote: > https://github.com/tlswg/tls13-spec/issues/26 > > Issue #26 notes complication with the usage of a negotiable PRF. The > current suggestion mentioned was to consider removing PRF > negotiation in favor of SHA-256, calling it "good enough" until the next > protocol version. I agree that this is quite possibly the case, however > I would like to suggest future proofing things a bit. Old versions of TLS > used the strategy of dual hash algorithms "to ensure that > non-catastrophic flaws in one algorithm will not break the overall > protocol" [RFC4346 F.1.5]. TLS 1.1 used MD5+SHA1. For TLS 1.3, I > would like to suggest SHA2-256+SHA3-256 or similar for consideration. > Picking a single combo allows the removal of negotiation, fixing any issues > that causes, provides a simpler spec for this feature, and allows both the > current standard and new SHA functions to be used without having to > rely 100% on either. Adoption rates of new TLS versions are less than > ideal, so future proofing in manners like this that don't add a fantastic > amount of additional complexity seems like an idea worth consideration. I don't believe this is the right place to start asking the questions. Instead, let's look at where the PRF is used and in what context, and then figure out whether or not what we have is good enough. TLS uses three (or four) logical constructs during handshaking - a key derivation function (1) to derive the master secret from the premaster, and the session keys from the master secret; a MAC function (2) to "sign" the handshake (Finished message verify_data), and a pseudo-random data generator (PRDG) (3) to generate coordinated IVs and nonces for some crypto suites. There's also the hash function (4) used to summarize the handshake prior to it being signed. (3), in TLS1.2 and before, is a generated as part of key stream derived from the master secret. All of these constructs except the hash use the keyed TLS PRF (a keyed recursive HMAC PRDG function), but the hash function is currently the same as the underlying hash function for HMAC in the TLS PRF. So breaking it down: Is (1) secure enough to derive keys? The construct used in TLS is similar to the section 5.2 construct of NIST SP800-108. But the SP800 construct has one extra piece missing from this one - the L parameter which ensures that the key stream changes if the number of output bits change. There's also expanded guidance on the context field - the equivalent values in TLS are currently just the client and server random. I've got some issues with that - see http://tools.ietf.org/html/draft-stjohns-tls-tls13-crypto-infra-00, and I would add information about the types and lengths of the keys to be derived from the key stream to the context. With those changes, a recursive based HMAC PRDG at the heart of the KDF is probably sufficiently secure for key derivation going forward. Is (2) secure enough to sign the handshake? (2) is probably overkill in its current state. It also uses the TLS PRF and should instead just use the HMAC - there's no added security using the TLS PRF. There is another issue with the fact that the master secret is used to key both (1) and (2) - that's generally considered bad cryptographic practice. Is (3) secure enough to generate IV and nonce data? (3) is probably overkill. It uses the master secret to key the PRDG. Discussions with various folks as well as perusing the literature suggest that a key of '0's used with the client and server random as context data is sufficient as all is needed is an extraction of entropy from other random values. This is NOT a random data source in the general cryptographic meaning, but a way of getting the same public data out on both sides simultaneously without needing to include them in the handshake. There is a current issue with this in that the master secret is used to key this function as well as (1) and (2). In general, (1), (2), and (3) are probably secure if the TLS PRF recursive HMAC is secure, and that's probably secure (if the issues above are addressed) assuming (4) is secure. Is (4) secure enough? The general comment is that you can negotiate a better one if (4) isn't secure. However, the hash is necessary to summarize the handshake because the key for (2) isn't available to the server until a substantial portion of the handshake has been sent/received. If the client is trying to negotiate a new hash, then the client will need to maintain separate hash contexts until it gets the server acknowledgement of the hash (PRF) selection and can throw the ones it won't use for that away. The requirements for (2) (key not available until later) argues that the TLS PRF has to continue to be built on a hash function unless the data signed by (2) changes. The discussion for (4) suggests that we can't just say that SHA256 will always be the value. Mike > > > - Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > From nobody Wed Jul 30 08:54:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7667F1A0193 for ; Wed, 30 Jul 2014 08:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3p3VRG9AMfy3 for ; Wed, 30 Jul 2014 08:54:03 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35881A0048 for ; Wed, 30 Jul 2014 08:53:58 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id f51so1749786qge.18 for ; Wed, 30 Jul 2014 08:53:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DRKmhhGAWtnR05KFXkqUrvkM4UhVColGAz9Q94CuhQI=; b=YfD/c8B5nihafql6QX4OQ6OP61UfHMUBnFwjnKbHlI3E843FRH7uxh5xUhA/jr2Uyx kI0NlA2BAqdN6RBI7vNsOet1s1UEzFd1/oQgboPiOnQEdKgwsPvFH2pgHb2p2FgqCOs+ cANE7RP3GtkeBhm2IKgE+zlcxecGg8nFLX71y5D84d+uBUIa9y2UYo6PaCOBF690O2uz 4NWEjbuhXx5NP8hGECtZEbhdIl2MR38HQt3z1r39w8u5CkJTYY6hC7j8B7IjFqkVfPPV YwuWdmhJznZY8WvH+ECfOZGbpMuGn7caObEECz3uw4tR0p42pJp+3DLdH3Zormd72e2Y sYPQ== X-Gm-Message-State: ALoCoQlP4KMYu9EVFhEwr4p6MWR32tnYji+Rc67ImOzNxkSbCB27Bejq05H7RCZ2dmVw1oGNIETX X-Received: by 10.140.96.85 with SMTP id j79mr7872522qge.5.1406735636796; Wed, 30 Jul 2014 08:53:56 -0700 (PDT) Received: from [192.168.1.111] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id 103sm2897630qgi.39.2014.07.30.08.53.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 08:53:56 -0700 (PDT) Message-ID: <53D91515.1010508@nthpermutation.com> Date: Wed, 30 Jul 2014 11:53:57 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <201407281624.10986.davemgarrett@gmail.com> In-Reply-To: <201407281624.10986.davemgarrett@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Gjj9Kd8B8OGh4o1w-GN_brq2QqA Subject: Re: [TLS] PRF in 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 15:54:09 -0000 On 7/28/2014 4:24 PM, Dave Garrett wrote: > https://github.com/tlswg/tls13-spec/issues/26 > > Issue #26 notes complication with the usage of a negotiable PRF. The > current suggestion mentioned was to consider removing PRF > negotiation in favor of SHA-256, calling it "good enough" until the next > protocol version. I agree that this is quite possibly the case, however > I would like to suggest future proofing things a bit. Old versions of TLS > used the strategy of dual hash algorithms "to ensure that > non-catastrophic flaws in one algorithm will not break the overall > protocol" [RFC4346 F.1.5]. TLS 1.1 used MD5+SHA1. For TLS 1.3, I > would like to suggest SHA2-256+SHA3-256 or similar for consideration. > Picking a single combo allows the removal of negotiation, fixing any issues > that causes, provides a simpler spec for this feature, and allows both the > current standard and new SHA functions to be used without having to > rely 100% on either. Adoption rates of new TLS versions are less than > ideal, so future proofing in manners like this that don't add a fantastic > amount of additional complexity seems like an idea worth consideration. I don't believe this is the right place to start asking the questions. Instead, let's look at where the PRF is used and in what context, and then figure out whether or not what we have is good enough. TLS uses three (or four) logical constructs during handshaking - a key derivation function (1) to derive the master secret from the premaster, and the session keys from the master secret; a MAC function (2) to "sign" the handshake (Finished message verify_data), and a pseudo-random data generator (PRDG) (3) to generate coordinated IVs and nonces for some crypto suites. There's also the hash function (4) used to summarize the handshake prior to it being signed. (3), in TLS1.2 and before, is a generated as part of key stream derived from the master secret. All of these constructs except the hash use the keyed TLS PRF (a keyed recursive HMAC PRDG function), but the hash function is currently the same as the underlying hash function for HMAC in the TLS PRF. So breaking it down: Is (1) secure enough to derive keys? The construct used in TLS is similar to the section 5.2 construct of NIST SP800-108. But the SP800 construct has one extra piece missing from this one - the L parameter which ensures that the key stream changes if the number of output bits change. There's also expanded guidance on the context field - the equivalent values in TLS are currently just the client and server random. I've got some issues with that - see http://tools.ietf.org/html/draft-stjohns-tls-tls13-crypto-infra-00, and I would add information about the types and lengths of the keys to be derived from the key stream to the context. With those changes, a recursive based HMAC PRDG at the heart of the KDF is probably sufficiently secure for key derivation going forward. Is (2) secure enough to sign the handshake? (2) is probably overkill in its current state. It also uses the TLS PRF and should instead just use the HMAC - there's no added security using the TLS PRF. There is another issue with the fact that the master secret is used to key both (1) and (2) - that's generally considered bad cryptographic practice. Is (3) secure enough to generate IV and nonce data? (3) is probably overkill. It uses the master secret to key the PRDG. Discussions with various folks as well as perusing the literature suggest that a key of '0's used with the client and server random as context data is sufficient as all is needed is an extraction of entropy from other random values. This is NOT a random data source in the general cryptographic meaning, but a way of getting the same public data out on both sides simultaneously without needing to include them in the handshake. There is a current issue with this in that the master secret is used to key this function as well as (1) and (2). In general, (1), (2), and (3) are probably secure if the TLS PRF recursive HMAC is secure, and that's probably secure (if the issues above are addressed) assuming (4) is secure. Is (4) secure enough? The general comment is that you can negotiate a better one if (4) isn't secure. However, the hash is necessary to summarize the handshake because the key for (2) isn't available to the server until a substantial portion of the handshake has been sent/received. If the client is trying to negotiate a new hash, then the client will need to maintain separate hash contexts until it gets the server acknowledgement of the hash (PRF) selection and can throw the ones it won't use for that away. The requirements for (2) (key not available until later) argues that the TLS PRF has to continue to be built on a hash function unless the data signed by (2) changes. The discussion for (4) suggests that we can't just say that SHA256 will always be the value. Mike > > > - Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > From nobody Wed Jul 30 09:00:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6FF1A0264 for ; Wed, 30 Jul 2014 09:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQjxSjKSkvpN for ; Wed, 30 Jul 2014 09:00:49 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92821A023E for ; Wed, 30 Jul 2014 09:00:48 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hi2so7835408wib.10 for ; Wed, 30 Jul 2014 09:00:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=CBZ/nbs2WQ2Ei8aItqBP5PWoAP6BDKSQuKwZ4ZRA9SI=; b=XhXJuBG46QWiyQ9nezk8fLmmMwkVLDeoLv5aRxym4YQ+sIXSDdB32LtjwMOyhj6lDM pRrxej97JGNDH4B3mrr/2gwFCT5nPRpFK1V9RnFs6ZS0yPqSowEimk8WlA1cQmguXb1M 4c/Ea5bKI41eAKlYpNWFiQGYtM3N9LEPDxoGaEttxEeUVhdbDieekniSqzz99UVUQJBx vYAQQUqGSBqq0Fr2am4H/g3FRQO+CwcErn7z7wFZ7C2thCb9ibyVxDP/0qvseIwUu4tu IJqcWdJoZ5z4GBFzyRh7ctOINJAyohSS7yKGj2Y1xUG+EUuN5W3kQMN4TsmsRa39ylSX lbWw== X-Gm-Message-State: ALoCoQk4JGPNOVR54cEFKNYHVU2+i4AmNOw+9L9MMO7lz+9z+mtx4C78icDkyCjCiLmNbVL16tjv X-Received: by 10.180.75.49 with SMTP id z17mr7221540wiv.80.1406736046486; Wed, 30 Jul 2014 09:00:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Wed, 30 Jul 2014 09:00:06 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <53D907B0.3000006@nthpermutation.com> References: <53D907B0.3000006@nthpermutation.com> From: Eric Rescorla Date: Wed, 30 Jul 2014 09:00:06 -0700 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=f46d0438953358128304ff6b423e Archived-At: http://mailarchive.ietf.org/arch/msg/tls/COzW-XDXfkrHvoMq_-r8Mt20xOw Cc: "tls@ietf.org" Subject: Re: [TLS] Premaster/Master convention X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2014 16:00:53 -0000 --f46d0438953358128304ff6b423e Content-Type: text/plain; charset=UTF-8 As discussed in the interim we are going to want to roll over the MS periodically. Life will be a lot easier if it has a uniform structure. Moreover, just because we aren't using key transport doesn't mean there aren't other mechanisms with funky shared secrets, e.g., PSK. -Ekr On Wed, Jul 30, 2014 at 7:56 AM, Michael StJohns wrote: > Given that TLS1.3 only does KeyAgreement, is there still any reason for > the premaster -> master_secret derivation step? We do (KA)->premaster and > then premaster -> master and then master->(session keys). We could > probably do (KA)->master->(session keys) where the master secret is now the > KA shared secret rather than premaster. > > 1) Is there any security reason for retaining the extra step given there > is no longer a KeyTransport mechanism in TLS1.3? > 2) Are there other *good* - non-security - reasons for retaining the extra > step? > > Mike > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d0438953358128304ff6b423e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As discussed in the interim we are going to want to roll o= ver the
MS periodically. Life will be a lot easier if it has a uniform = structure.

Moreover, just because we aren't us= ing key transport doesn't mean
there aren't other mechanisms with funky shared secrets, e.g.,
PSK.

-Ekr



On Wed, Jul 30, 2014= at 7:56 AM, Michael StJohns <msj@nthpermutation.com> w= rote:
Given that TLS1.3 only does KeyAgreement, is= there still any reason for the premaster -> master_secret derivation st= ep? =C2=A0We do (KA)->premaster and then premaster -> master and then= master->(session keys). =C2=A0 We could probably do (KA)->master->= ;(session keys) where the master secret is now the KA shared secret rather = than premaster.

1) Is there any security reason for retaining the extra step given there is= no longer a KeyTransport mechanism in TLS1.3?
2) Are there other *good* - non-security - reasons for retaining the extra = step?

Mike



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

--f46d0438953358128304ff6b423e-- From nobody Wed Jul 30 09:22:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357831A028A for ; Wed, 30 Jul 2014 09:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmbIo-DarFbe for ; Wed, 30 Jul 2014 09:21:52 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B551A0250 for ; Wed, 30 Jul 2014 09:21:52 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id f51so1811314qge.4 for ; Wed, 30 Jul 2014 09:21:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=qnWyvFfz8PPwDaCZ01c3Sh9pMXRx5BRRi9xpbYA85Tk=; b=cdngbq//5HnIakcFUUrWclr84iNeHcU8PZxshlw3M6sfI4mrqj4gF5MYVK4W7gOt5f UWhj4HfLiKRqUqMm506kVY2QKicIDFV0ZIya9zvq9vUAcVfXG5Gvlkc/czFWULy9xaQ7 n0/GX+00VeXO4r/CRBfMkoiXmoiuTnjh43ZcdrwG0J45ISkeikBdKtaKMOOb3neUH1OB vaHYwlqMsQ9qe3nxWyZ+iE/YzrDUq2xmaiLjoEGr0jQdJjBTbs6IQWSvJv5Jf7KtHlZm 3JhMNomPZPS+xNrqMD8xnP6sO6160Rna7LOEwVyYg368k4aFjI63iGf/iY1QxFqHOgpc hrQA== X-Gm-Message-State: ALoCoQkdvEiNaDE3SCOPlP4K9tbpjpaWWbzUbjdNWf34ewsGABHwqFLGLib3O++JaGIYFhWY/Qsf X-Received: by 10.224.71.198 with SMTP id i6mr8623378qaj.76.1406737309280; Wed, 30 Jul 2014 09:21:49 -0700 (PDT) Received: from [192.168.1.111] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id i2sm2975031qge.27.2014.07.30.09.21.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 09:21:48 -0700 (PDT) Message-ID: <53D91B89.3020506@nthpermutation.com> Date: Wed, 30 Jul 2014 12:21:29 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Eric Rescorla References: <53D907B0.3000006@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080809040904080001040201" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hb8kJnkT8sKocA36sMERUbjDjE0 Cc: "tls@ietf.org" Subject: Re: [TLS] Premaster/Master convention X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2014 16:21:58 -0000 This is a multi-part message in MIME format. --------------080809040904080001040201 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 7/30/2014 12:00 PM, Eric Rescorla wrote: > As discussed in the interim we are going to want to roll over the > MS periodically. Life will be a lot easier if it has a uniform structure. > > Moreover, just because we aren't using key transport doesn't mean > there aren't other mechanisms with funky shared secrets, e.g., > PSK. I don't think either of these are show stoppers - although I don't know exactly what you mean by "uniform structure" here. Do you mean "because that's the way its done in TLS1.2 and before and we want backwards compatibility"? In the former case, its pretty simple to do: (KA)->master_secret -> next_master_secret - either as part of the first context call (to derive the session and handshake keys), or as a separate context call (to specifically generate a new master secret. E.g. the derive looks like: (KA) -> master_secret -> next_master_secret -> handshake key -> client_write_AEAD -> server_write_AEAD next_master_secret -> next_master_secret -> handshake_key -> client_write_AEAD -> server_write_AEAD Or it looks like (KA) -> master_secret (key expand) -> handshake key -> client_write_AEAD -> server_write_AEAD master_secret (nextmaster) -> next_master_secret (where key expand and nextmaster are differing labels and KDF contexts). In the PSK case, with key transport, doing the pre_master->master derive allows you to mix in random data from both sides so that the master_secret isn't only chosen by one side so there's some security benefit there. In the PSK model, that's not an issue as both sides have already agreed upon a key. Mike > > -Ekr > > > > On Wed, Jul 30, 2014 at 7:56 AM, Michael StJohns > > wrote: > > Given that TLS1.3 only does KeyAgreement, is there still any > reason for the premaster -> master_secret derivation step? We do > (KA)->premaster and then premaster -> master and then > master->(session keys). We could probably do > (KA)->master->(session keys) where the master secret is now the KA > shared secret rather than premaster. > > 1) Is there any security reason for retaining the extra step given > there is no longer a KeyTransport mechanism in TLS1.3? > 2) Are there other *good* - non-security - reasons for retaining > the extra step? > > Mike > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --------------080809040904080001040201 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 7/30/2014 12:00 PM, Eric Rescorla wrote:
As discussed in the interim we are going to want to roll over the
MS periodically. Life will be a lot easier if it has a uniform structure.

Moreover, just because we aren't using key transport doesn't mean
there aren't other mechanisms with funky shared secrets, e.g.,
PSK.

I don't think either of these are show stoppers - although I don't know exactly what you mean by "uniform structure" here.  Do you mean "because that's the way its done in TLS1.2 and before and we want backwards compatibility"?

In the former case, its pretty simple to do:

(KA)->master_secret -> next_master_secret  - either as part of the first context call (to derive the session and handshake keys), or as a separate context call (to specifically generate a new master secret.

E.g. the derive looks like:

(KA) -> master_secret
                 -> next_master_secret
                 -> handshake key
                 -> client_write_AEAD
                 -> server_write_AEAD

next_master_secret
         -> next_master_secret
         -> handshake_key
         -> client_write_AEAD
         -> server_write_AEAD

Or it looks like

(KA) -> master_secret (key expand)
         -> handshake key
         -> client_write_AEAD
         -> server_write_AEAD

master_secret (nextmaster)
      -> next_master_secret

(where key expand and nextmaster are differing labels and KDF contexts).

In the PSK case, with key transport, doing the pre_master->master derive allows you to mix in random data from both sides so that the master_secret isn't only chosen by one side so there's some security benefit there.  In the PSK model, that's not an issue as both sides have already agreed upon a key.

Mike



-Ekr



On Wed, Jul 30, 2014 at 7:56 AM, Michael StJohns <msj@nthpermutation.com> wrote:
Given that TLS1.3 only does KeyAgreement, is there still any reason for the premaster -> master_secret derivation step?  We do (KA)->premaster and then premaster -> master and then master->(session keys).   We could probably do (KA)->master->(session keys) where the master secret is now the KA shared secret rather than premaster.

1) Is there any security reason for retaining the extra step given there is no longer a KeyTransport mechanism in TLS1.3?
2) Are there other *good* - non-security - reasons for retaining the extra step?

Mike



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


--------------080809040904080001040201-- From nobody Wed Jul 30 09:22:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B0C1A02B9 for ; Wed, 30 Jul 2014 09:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mADCRGRVvoAP for ; Wed, 30 Jul 2014 09:22:44 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BC651A028A for ; Wed, 30 Jul 2014 09:22:44 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so1446561wgg.28 for ; Wed, 30 Jul 2014 09:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Rmrlqb3LhV1FjeUJROjmweqmLAf4xzT2/wqhMoOIIJ8=; b=M4lZjzWnSdw2XLlztlK+uLYn1r6KnhxbSncD2kFGREWuY0/XQJPNxhNmNG0WjuVEFa idQBFC8r+3CljA5TfF59/R7hkpVDS5KaygC8pSpooUMBRr//81KDlVlpaDeZE9uFuim0 HKIwAoje0GHao9l6/Oy40K73QMVLx+E3WTqvcCjs3Uo5zV9BC6+X8bjUev5SZQ79ALBN lLAZKAz8Hme7ltOXj0+dNmUJ0EEUL4f2RR+JnYpSBNm4iEm1DDns5WJ7tp+h4ZF/p6+x L5pD96UBj0Pm3VJeE3nc67/YHrB8an9vP/ltf4CWNyoXKWM4TvFunaOnVihs5BqsB3Bt cc/Q== MIME-Version: 1.0 X-Received: by 10.194.91.228 with SMTP id ch4mr7735811wjb.59.1406737362292; Wed, 30 Jul 2014 09:22:42 -0700 (PDT) Received: by 10.194.169.10 with HTTP; Wed, 30 Jul 2014 09:22:42 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C718599EDDDB@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C718599EDDDB@USMBX1.msg.corp.akamai.com> Date: Wed, 30 Jul 2014 09:22:42 -0700 Message-ID: From: Martin Thomson To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RG3vGon0bBSEkgwJcOXdrMzpWrE Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] SNI and ALPN -- which firsr? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2014 16:22:48 -0000 On 29 July 2014 18:57, Salz, Rich wrote: > Is there a fixed order for processing a hello that has both ALPN and SNI? > > For example, if you do ALPN first, then the SNI might end up =E2=80=9Cpoi= nting to=E2=80=9D a > client with weaker ciphers than, say HTTP/2 allows. > > On the other hand, I can see the case that the SNI is protocol-specific, = so > you should do ALPN first. I don't think that order of processing needs to be fixed, or the same for different deployments. I can imagine that some deployments might want to have a table that uses both inputs simultaneously. Specifying a fixed processing order removes some flexibility. Is there a particular reason that a fixed order would be of an advantage? From nobody Wed Jul 30 09:26:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B091A02D9 for ; Wed, 30 Jul 2014 09:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3AAJLYrlkUK for ; Wed, 30 Jul 2014 09:26:11 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E531A02D2 for ; Wed, 30 Jul 2014 09:26:11 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id x48so1496986wes.31 for ; Wed, 30 Jul 2014 09:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/cO2m87Ety3t4YwkZIpS/bCC88VZdY8q4GBVWTf9rEw=; b=lqXCIomJBEdBwxmS8LjYZzDvYb66Da295wcg0ymq4nGU3ZEA6HB8/IuGmalkd27uKT ClBxL9+SJfOD/zcpSr82vHEbOSDchsgBrBj58zDhDC4+ytUwlq+pSvv/2mVuPSrZu42J 5wJoBJXXluhGA/Ld7nYdTt8xoqNTpeWMMvFYX6fPeNWKyF0+Mb1E/TE1pjNXFL2UPl89 lXGa31bDp9oDFDhdZLoLDH12CtajmknP5j4T1YsRkofBm0RbS62bV9BKlqtipnjSQ98O ZvWwErzpCyaaRPVaHiFhmrw/bBv6BTe5Pgg/hqD5AedHOugo3xBAwIkGB01p+H1AwwU6 yQTg== MIME-Version: 1.0 X-Received: by 10.180.104.42 with SMTP id gb10mr8270575wib.65.1406737569817; Wed, 30 Jul 2014 09:26:09 -0700 (PDT) Received: by 10.194.169.10 with HTTP; Wed, 30 Jul 2014 09:26:09 -0700 (PDT) In-Reply-To: <0A94B681-AFAA-43FE-A814-0F2F4CE54FC7@ieca.com> References: <5A318D71-E491-490B-82D3-6D1BA3C60684@ieca.com> <0A94B681-AFAA-43FE-A814-0F2F4CE54FC7@ieca.com> Date: Wed, 30 Jul 2014 09:26:09 -0700 Message-ID: From: Martin Thomson To: Sean Turner Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yqa7fUa2IoABU8T6GUsM3McpomI Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] adopted: draft-popov-tls-prohibiting-rc4-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2014 16:26:12 -0000 On 30 July 2014 07:01, Sean Turner wrote: > The one outstanding comment on the draft was to include the RC4 cipher suites from the IANA registry. Andrei has now added that in Appendix A. Is there anything else people need to have in this draft before it can be progressed? The draft is ready. It's concise, correct and the right thing to do. From nobody Wed Jul 30 09:27:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E921A0197 for ; Wed, 30 Jul 2014 09:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbtMJHKSiUfl for ; Wed, 30 Jul 2014 09:27:04 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC8221A01DD for ; Wed, 30 Jul 2014 09:27:03 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id n3so7925211wiv.17 for ; Wed, 30 Jul 2014 09:27:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zSeaCQANQCkDZGy3xpwmSN1bWmhWuei+PyISMuPuqu8=; b=RjGt73TRw6YbKRfq8ZKRI/+Gs2fyzxZqyO2zq0L73jdxtzpcYloN/HYkIdvbG+j4Ao 5em+CRFOW23UlGRBuuhLjbWkM1K6bB8cXdJhaJwnzfcyV8s443OfkLS6gv4XAcJd76LP 6LmMyfrvMQwsgxtyA/K67A221UB6DABS+q2C2i+seH2Dgu1GEp3PvfSbd/crZifXe2oI Xppb0ZAGHV8JM3Eb5dh8TuTKgMlzQk9VDoumVCWstfr1XI8jyal78YePNaymomJAIIX3 +SSYeUwT1N3B1C+1Zq2YrDuYA9QxOIbkYbZN2AzPURc/gupd7Su4HDuGGLPNM6NLFnYe mVrA== X-Gm-Message-State: ALoCoQnmgJWpBjqz3BbbHAbuvX7iS9nQsAvk1+UQNFHyJeRzBBWUsePhfcmTY5zLfzZDAlZwjdru X-Received: by 10.180.37.77 with SMTP id w13mr7478100wij.78.1406737622237; Wed, 30 Jul 2014 09:27:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Wed, 30 Jul 2014 09:26:22 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <53D91B89.3020506@nthpermutation.com> References: <53D907B0.3000006@nthpermutation.com> <53D91B89.3020506@nthpermutation.com> From: Eric Rescorla Date: Wed, 30 Jul 2014 09:26:22 -0700 Message-ID: To: Michael StJohns Content-Type: multipart/alternative; boundary=e89a8f64702144164004ff6ba099 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XSKZMrmP7rnGNBRvExBer4e3uVE Cc: "tls@ietf.org" Subject: Re: [TLS] Premaster/Master convention X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2014 16:27:06 -0000 --e89a8f64702144164004ff6ba099 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 30, 2014 at 9:21 AM, Michael StJohns wrote: > On 7/30/2014 12:00 PM, Eric Rescorla wrote: > > As discussed in the interim we are going to want to roll over the > MS periodically. Life will be a lot easier if it has a uniform structure. > > Moreover, just because we aren't using key transport doesn't mean > there aren't other mechanisms with funky shared secrets, e.g., > PSK. > > > I don't think either of these are show stoppers - although I don't know > exactly what you mean by "uniform structure" here. Do you mean "because > that's the way its done in TLS1.2 and before and we want backwards > compatibility"? > I mean always have the secret you use for key derivation be the same size and unstructured and get to it the same way, regardless of the starting secret. Thus, I would prefer to stick with the same PMS->MS flow. -Ekr > In the former case, its pretty simple to do: > > (KA)->master_secret -> next_master_secret - either as part of the first > context call (to derive the session and handshake keys), or as a separate > context call (to specifically generate a new master secret. > > E.g. the derive looks like: > > (KA) -> master_secret > -> next_master_secret > -> handshake key > -> client_write_AEAD > -> server_write_AEAD > > next_master_secret > -> next_master_secret > -> handshake_key > -> client_write_AEAD > -> server_write_AEAD > > Or it looks like > > (KA) -> master_secret (key expand) > -> handshake key > -> client_write_AEAD > -> server_write_AEAD > > master_secret (nextmaster) > -> next_master_secret > > (where key expand and nextmaster are differing labels and KDF contexts). > > In the PSK case, with key transport, doing the pre_master->master derive > allows you to mix in random data from both sides so that the master_secret > isn't only chosen by one side so there's some security benefit there. In > the PSK model, that's not an issue as both sides have already agreed upon a > key. > > Mike > > > > > -Ekr > > > > On Wed, Jul 30, 2014 at 7:56 AM, Michael StJohns > wrote: > >> Given that TLS1.3 only does KeyAgreement, is there still any reason for >> the premaster -> master_secret derivation step? We do (KA)->premaster and >> then premaster -> master and then master->(session keys). We could >> probably do (KA)->master->(session keys) where the master secret is now the >> KA shared secret rather than premaster. >> >> 1) Is there any security reason for retaining the extra step given there >> is no longer a KeyTransport mechanism in TLS1.3? >> 2) Are there other *good* - non-security - reasons for retaining the >> extra step? >> >> Mike >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > --e89a8f64702144164004ff6ba099 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 30, 2014 at 9:21 AM, Michael StJohns = <msj@nthperm= utation.com> wrote:
=20 =20 =20
On 7/30/2014 12:00 PM, Eric Rescorla wrote:
As discussed in the interim we are going to want to roll over the
MS periodically. Life will be a lot easier if it has a uniform structure.

Moreover, just because we aren't using key transport doesn't mean
there aren't other mechanisms with funky shared secrets, e.g.,
PSK.

I don't think either of these are show stoppers - although I don= 9;t know exactly what you mean by "uniform structure" here.=C2=A0= Do you mean "because that's the way its done in TLS1.2 and before and we w= ant backwards compatibility"?

I mean always have the secret you use for key derivation be
the= same size and unstructured and get to it the same way,
regardles= s of the starting secret.

Thus, I would prefer to stick with the same PMS->MS = flow.

-Ekr


In the former case, its pretty simple to do:

(KA)->master_secret -> next_master_secret=C2=A0 - either as part = of the first context call (to derive the session and handshake keys), or as a separate context call (to specifically generate a new master secret.

E.g. the derive looks like:

(KA) -> master_secret
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 -> next_master_secret
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 -> handshake key
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 -> client_write_AEAD
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 -> server_write_AEAD

next_master_secret
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> next_master_secr= et
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> handshake_key =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> client_write_AEA= D
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> server_write_AEA= D

Or it looks like

(KA) -> master_secret (key expand)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> handshake key =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> client_write_AEA= D
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> server_write_AEA= D

master_secret (nextmaster)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> next_master_secret

(where key expand and nextmaster are differing labels and KDF contexts).

In the PSK case, with key transport, doing the pre_master->master derive allows you to mix in random data from both sides so that the master_secret isn't only chosen by one side so there's some sec= urity benefit there.=C2=A0 In the PSK model, that's not an issue as both = sides have already agreed upon a key.

Mike




-Ekr



On Wed, Jul 30, 2014 at 7:56 AM, Michael StJohns <msj@nthpermutation.com> wrote:
Given that TLS1.3 only does KeyAgreement, is there still any reason for the premaster -> master_secret derivation step? =C2=A0We do (KA)->premaster and then premaster -> master and then master->(session keys). =C2=A0 We could probably do (KA)->master->(session keys) where the master secret is now the KA shared secret rather than premaster.

1) Is there any security reason for retaining the extra step given there is no longer a KeyTransport mechanism in TLS1.3? 2) Are there other *good* - non-security - reasons for retaining the extra step?

Mike



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



--e89a8f64702144164004ff6ba099-- From nobody Wed Jul 30 09:27:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E1A1A027C for ; Wed, 30 Jul 2014 09:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCQS1Fdsazzp for ; Wed, 30 Jul 2014 09:27:56 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 04EBA1A0273 for ; Wed, 30 Jul 2014 09:27:55 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8D0451657AB; Wed, 30 Jul 2014 16:27:55 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 82664165667; Wed, 30 Jul 2014 16:27:55 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 69ED71E045; Wed, 30 Jul 2014 16:27:55 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Wed, 30 Jul 2014 12:27:54 -0400 From: "Gero, Charlie" To: 'Michael StJohns' , "tls@ietf.org" Date: Wed, 30 Jul 2014 12:27:54 -0400 Thread-Topic: [TLS] Premaster/Master convention Thread-Index: Ac+sDVyy0wcwqIUbSoKWRULtWugFAAABa3Ww Message-ID: References: <53D907B0.3000006@nthpermutation.com> <53D91332.9070103@nthpermutation.com> In-Reply-To: <53D91332.9070103@nthpermutation.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/l_raoFvDOb527W2Rn3661Zmc3ho Subject: Re: [TLS] Premaster/Master convention X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2014 16:27:57 -0000 I can't go into details around it at this time. Suffice to say, we definit= ely do rely on the two being split. -----Original Message----- From: Michael StJohns [mailto:msj@nthpermutation.com]=20 Sent: Wednesday, July 30, 2014 11:46 AM To: Gero, Charlie; tls@ietf.org Subject: Re: [TLS] Premaster/Master convention On 7/30/2014 11:02 AM, Gero, Charlie wrote: > We have a number of technologies at Akamai that utilize the fact that the= PMS is split from the MS and that MS is produced in conjunction with the r= andoms. It allows us to do splitting between machines that have keys and t= hose that don't (machines in safe locales and those which are simply termin= ators). I don't think we could use the same methods we use today without t= hat sub step. It would make it very difficult for Akamai to adopt 1.3. So you send the master secret from the handshaker machine out to several ot= her machines which then do what with it? Couldn't you send the traffic key= s instead? I'm not sure I understand the constraints you're working under. Could you e= xpand on that? Thanks - Mike > > -----Original Message----- > From: Michael StJohns [mailto:msj@nthpermutation.com] > Sent: Wednesday, July 30, 2014 10:57 AM > To: tls@ietf.org > Subject: [TLS] Premaster/Master convention > > Given that TLS1.3 only does KeyAgreement, is there still any reason for t= he premaster -> master_secret derivation step? We do (KA)->premaster > and then premaster -> master and then master->(session keys). We could > probably do (KA)->master->(session keys) where the master secret is now t= he KA shared secret rather than premaster. > > 1) Is there any security reason for retaining the extra step given there = is no longer a KeyTransport mechanism in TLS1.3? > 2) Are there other *good* - non-security - reasons for retaining the extr= a step? > > Mike > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > From nobody Wed Jul 30 09:29:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638B41A0301 for ; Wed, 30 Jul 2014 09:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQ4p9IP8Lrka for ; Wed, 30 Jul 2014 09:29:31 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 568DD1A0300 for ; Wed, 30 Jul 2014 09:29:31 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id EFBF0484C5; Wed, 30 Jul 2014 16:29:30 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id E4BA0484C3; Wed, 30 Jul 2014 16:29:30 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id CDB2A9804A; Wed, 30 Jul 2014 16:29:30 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Wed, 30 Jul 2014 12:29:30 -0400 From: "Salz, Rich" To: Martin Thomson Date: Wed, 30 Jul 2014 12:29:29 -0400 Thread-Topic: [TLS] SNI and ALPN -- which firsr? Thread-Index: Ac+sEn6VGsT7FFs5TuGANc/2njqY8QAAJ5iQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C718599EE035@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C718599EDDDB@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UTp_hEI-DynXypGdQf6wJNXho_I Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] SNI and ALPN -- which firsr? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2014 16:29:37 -0000 PiBJcyB0aGVyZSBhIHBhcnRpY3VsYXIgcmVhc29uIHRoYXQgYSBmaXhlZCBvcmRlciB3b3VsZCBi ZSBvZiBhbiBhZHZhbnRhZ2U/DQoNCkEgZml4ZWQgb3JkZXIgb2YgcHJlY2VkZW5jZSBpcyBnZW5l cmFsbHkgYSBnb29kIHRoaW5nLiAgQW1vbmcgb3RoZXIgdGhpbmdzLCBpdCBmb3JjZXMgeW91IHRv IHRoaW5rIGFib3V0ICB0aGUgaW50ZXJhY3Rpb25zIGFuZCBlbmNvdXJhZ2VzIGNvbnNpc3RlbnQg YmVoYXZpb3IuICBGb3IgZXhhbXBsZSwgd2hpY2ggZG8gWU9VIHRoaW5rIHNob3VsZCBiZSBkb25l IGZpcnN0Pw0KDQpCdXQgSSdtIG5vdCBnb25uYSBsb3NlIGFueSBzbGVlcCBvdmVyIGl0IGlmIHRo ZSBXRyBmZWVscyBvdGhlcndpc2UuDQoNCi0tICANClByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVl cg0KQWthbWFpIFRlY2hub2xvZ2llcywgQ2FtYnJpZGdlIE1BDQpJTTogcnNhbHpAamFiYmVyLm1l IFR3aXR0ZXI6IFJpY2hTYWx6DQo= From nobody Wed Jul 30 09:42:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D181A0242 for ; Wed, 30 Jul 2014 09:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXNBszDzJCPE for ; Wed, 30 Jul 2014 09:42:18 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891B41A0197 for ; Wed, 30 Jul 2014 09:42:18 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hi2so7860567wib.4 for ; Wed, 30 Jul 2014 09:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1zafjxogWOrGvLsPlzlGeCLKSe4815s9qet41k7+OU4=; b=zk2lrKJxxBBN6wmJjq5wj9omBvu+ND1iXc3BNYxNGdBMpzyRXw1FXFPTuVGVzwSxA0 kgUhGFf8diRl04scZnwBkUzE0Y9VqdI+bYKXExxkBAzO55g7sqpKB6FyBE5PaNDhA5tf e+GllX7P1yIQUumdjdo6kLvFcWl0w30p2aqtTnAsqDeYb4Z0j6BuU44xQN35wVV+KZAh 21dIX0VZ/JoPxGdxR/uDupMmV8LKg21lQKCR01dG/up7AUUl/hc+wy4G+qkk6DRNB19n bTR4bNbqZmcuCK7ZVxYlss6z8bJqykt59HEGpbXbmIkTOPs3XQVWX2JQgnNZLFCtnPUL AytQ== MIME-Version: 1.0 X-Received: by 10.180.104.42 with SMTP id gb10mr8398451wib.65.1406738537119; Wed, 30 Jul 2014 09:42:17 -0700 (PDT) Received: by 10.194.169.10 with HTTP; Wed, 30 Jul 2014 09:42:17 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C718599EE035@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C718599EDDDB@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C718599EE035@USMBX1.msg.corp.akamai.com> Date: Wed, 30 Jul 2014 09:42:17 -0700 Message-ID: From: Martin Thomson To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bF9fVSa-mrbJ6a-CNSohhnEnSn4 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] SNI and ALPN -- which firsr? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2014 16:42:22 -0000 On 30 July 2014 09:29, Salz, Rich wrote: > A fixed order of precedence is generally a good thing. Among other things, it forces you to think about the interactions and encourages consistent behavior. For example, which do YOU think should be done first? I can imagine several different, but equally valid deployment configurations that suggest either. You could divide back-end servers by protocol. Each of them can handle the complete set of names that are served (images.example.com, www.example.com, accounts.example.com, etc...), but one pool does HTTP/1.1 and the other does HTTP/2. In that case, you would route on ALPN. This is even more important if we start seeing clients connect with an "xmpp" token rather than an "h2" or "http/1.1" token. This might help with the very different connection management profiles of different protocol versions. An alternative, which I'd consider preferable in the HTTP case, divides back-end machines by function (static.example.com, www.example.com, billing.example.com) and all hosts can handle all the application protocols. Or you might combine these. For instance, xmpp.example.com is a host that responds to SNI for that name, or an "xmpp" ALPN for an unqualified example.com. Other hosts could use any of the other configurations. Where order of processing becomes relevant is where there are errors generated by both extensions. Which error do you report? Honestly, I'd rather not mandate anything in a standard here, though I might appreciate that determinism is valuable when developing a test plan for a product. From nobody Wed Jul 30 09:51:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C8C1A01D0 for ; Wed, 30 Jul 2014 09:51:33 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oom7OS8Kvyq9 for ; Wed, 30 Jul 2014 09:51:31 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1523F1A01F2 for ; Wed, 30 Jul 2014 09:51:31 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 721252862D; Wed, 30 Jul 2014 16:51:30 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 422172861C; Wed, 30 Jul 2014 16:51:30 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id D07C62026; Wed, 30 Jul 2014 16:51:29 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Wed, 30 Jul 2014 12:51:29 -0400 From: "Salz, Rich" To: Martin Thomson Date: Wed, 30 Jul 2014 12:51:28 -0400 Thread-Topic: [TLS] SNI and ALPN -- which firsr? Thread-Index: Ac+sFUYgWLs5ntykSOq6OJ2udv8gfAAAStZg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C718599EE048@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C718599EDDDB@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C718599EE035@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/F_tk58lfcX1rL8Xy2web3IMMnFA Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] SNI and ALPN -- which firsr? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2014 16:51:33 -0000 PiBJIGNhbiBpbWFnaW5lIHNldmVyYWwgZGlmZmVyZW50LCBidXQgZXF1YWxseSB2YWxpZCBkZXBs b3ltZW50IGNvbmZpZ3VyYXRpb25zDQo+IHRoYXQgc3VnZ2VzdCBlaXRoZXIuDQoNCldoaWNoIGlz IHdoYXQgSSBzYWlkIGF0IHRoZSBiZWdpbm5pbmcgOikNCg0KLS0gIA0KUHJpbmNpcGFsIFNlY3Vy aXR5IEVuZ2luZWVyDQpBa2FtYWkgVGVjaG5vbG9naWVzLCBDYW1icmlkZ2UgTUENCklNOiByc2Fs ekBqYWJiZXIubWUgVHdpdHRlcjogUmljaFNhbHoNCg0K From nobody Wed Jul 30 12:47:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CABC1A01AA for ; Wed, 30 Jul 2014 12:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sE1k2NGPrt25 for ; Wed, 30 Jul 2014 12:47:24 -0700 (PDT) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C93D1A0158 for ; Wed, 30 Jul 2014 12:47:24 -0700 (PDT) Received: from [10.179.65.225] (85-76-114-234-nat.elisa-mobile.fi [85.76.114.234]) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 2A6424000F; Wed, 30 Jul 2014 22:47:16 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Wed, 30 Jul 2014 22:47:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6BC86E7B-B601-4077-A499-8C551A9C5529@iki.fi> References: <53D907B0.3000006@nthpermutation.com> To: "Gero, Charlie" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AFpY3yKpxSNGywjJVJWWysZupTA Cc: "tls@ietf.org" Subject: Re: [TLS] Premaster/Master convention X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2014 19:47:27 -0000 > On 30.7.2014, at 18.02, "Gero, Charlie" wrote: >=20 > We have a number of technologies at Akamai that utilize the fact that the P= MS is split from the MS and that MS is produced in conjunction with the rand= oms. It allows us to do splitting between machines that have keys and those= that don't (machines in safe locales and those which are simply terminators= ). I don't think we could use the same methods we use today without that su= b step. It would make it very difficult for Akamai to adopt 1.3. Without going much into details, are you sure that you can still use these m= ethods, or that these methods are still relevant, without the RSA key exchan= ge? With ephemeral (EC)DH only things done with the certificate private key is s= igning and verifying, and that doesn't involve the randoms. So I can't figur= e out how PMS->MS separation helps there, although I can see how it helps in= the RSA key exchange. But I'll take your word for it if you say so. Juho From nobody Wed Jul 30 13:43:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C5B1A0125 for ; Wed, 30 Jul 2014 13:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e16X4inB-4zI for ; Wed, 30 Jul 2014 13:43:29 -0700 (PDT) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7942A1A0146 for ; Wed, 30 Jul 2014 13:43:28 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id q108so2587392qgd.23 for ; Wed, 30 Jul 2014 13:43:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=50wHh1onqG18i7aL5ce169sCfHptrzoJrejzRofX7uE=; b=cR+VxawO+6rI04E7e5j3Py5ihFbWquDd/OqYd95hXRgNUbXtBsVBl2Wu+gjxaaCiuw 1zM31z1H6qYUKaYzXNanBh0d7CqTTX4vdtcZuE7o2u2CIdDd2cWi9GH1sAvsmBnMuWX2 JYR98cY5tC4DRoyGr+1SJ/ok4YwWlz7rZNzs2RwW1VkhfwR9HsfQB18h2SLUUQUh8PIf dn0unszIy6dOQ/uuPVcsztQ5OFRmSTMNZApgZ4eolJPzsIMWdNrTtKQcmCIjVwo3W/Kr kX4MHa6TK2OwQfPQct0ae6u7C94qXJrtZO/3hGHUsmPD6yFVyE5Xr06uZtX4U2NIGkIL MfSA== X-Gm-Message-State: ALoCoQnGHS6w7VheYztnDaEn0FCI09Z6tYNDs6gGJTrr/A37HaT1TNr5u1d3N6Eggq+cuoMKXnX3 X-Received: by 10.140.50.133 with SMTP id s5mr10255802qga.33.1406753007761; Wed, 30 Jul 2014 13:43:27 -0700 (PDT) Received: from [172.27.7.54] (75-104-68-185.mobility.exede.net. [75.104.68.185]) by mx.google.com with ESMTPSA id c6sm5763143qag.36.2014.07.30.13.43.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 13:43:27 -0700 (PDT) Message-ID: <53D958E8.6080907@nthpermutation.com> Date: Wed, 30 Jul 2014 16:43:20 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Eric Rescorla References: <53D907B0.3000006@nthpermutation.com> <53D91B89.3020506@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090505080707040208060905" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NagIZQQdf8RmcNh_ANLM7X1E8ns Cc: "tls@ietf.org" Subject: Re: [TLS] Premaster/Master convention X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2014 20:43:32 -0000 This is a multi-part message in MIME format. --------------090505080707040208060905 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 7/30/2014 12:26 PM, Eric Rescorla wrote: > > > > On Wed, Jul 30, 2014 at 9:21 AM, Michael StJohns > > wrote: > > On 7/30/2014 12:00 PM, Eric Rescorla wrote: >> As discussed in the interim we are going to want to roll over the >> MS periodically. Life will be a lot easier if it has a uniform >> structure. >> >> Moreover, just because we aren't using key transport doesn't mean >> there aren't other mechanisms with funky shared secrets, e.g., >> PSK. > > I don't think either of these are show stoppers - although I don't > know exactly what you mean by "uniform structure" here. Do you > mean "because that's the way its done in TLS1.2 and before and we > want backwards compatibility"? > > > I mean always have the secret you use for key derivation be > the same size and unstructured and get to it the same way, > regardless of the starting secret. > > Thus, I would prefer to stick with the same PMS->MS flow. You already have a disconnect in size on with respect to the premaster secret - it's going to be 32 bytes for P256 ECDH, something larger for DH depending on the group. (random length) -> (48 bytes) You also have a disconnect on the output - any number of keys of any size. (48 bytes) -> (random sizes) So why you think that its important to have an impedence match of (random size} -> 48 bytes -> (random sizes) is unclear to me. Is there a specific technical issue with {random length} -> { random lengths} that you can see? I understand you have a preference, I'm asking if you can see a reason why this would weaken security? There's the final issue that - as I read the HMAC document and the precursor technical papers - you don't really get anything with respect to security using keys over the native output length of the underlying hash, and that you weaken security if you use less bits than that. So 48 bytes is fine up to a hash of 384 bits, but is the possibly limiting security factor for anything larger. I don't know that we're going to be going to anything above 192 bits of (to include 384 bit hash functions) any time soon, but I would hate for this 48 bit legacy value to be the unforeseen security ceiling. *My* preference is for the input keys and the output keys to be matched to the needs of the cryptographic suite. That 384 bits of premaster secret is good up to SHA384, but may represent a smaller security strength for non-NIST hashes. I *think* this 48 octet value is the last fixed length security key in the standard. Mike > > -Ekr > > > In the former case, its pretty simple to do: > > (KA)->master_secret -> next_master_secret - either as part of the > first context call (to derive the session and handshake keys), or > as a separate context call (to specifically generate a new master > secret. > > E.g. the derive looks like: > > (KA) -> master_secret > -> next_master_secret > -> handshake key > -> client_write_AEAD > -> server_write_AEAD > > next_master_secret > -> next_master_secret > -> handshake_key > -> client_write_AEAD > -> server_write_AEAD > > Or it looks like > > (KA) -> master_secret (key expand) > -> handshake key > -> client_write_AEAD > -> server_write_AEAD > > master_secret (nextmaster) > -> next_master_secret > > (where key expand and nextmaster are differing labels and KDF > contexts). > > In the PSK case, with key transport, doing the pre_master->master > derive allows you to mix in random data from both sides so that > the master_secret isn't only chosen by one side so there's some > security benefit there. In the PSK model, that's not an issue as > both sides have already agreed upon a key. > > Mike > > > >> >> -Ekr >> >> >> >> On Wed, Jul 30, 2014 at 7:56 AM, Michael StJohns >> > wrote: >> >> Given that TLS1.3 only does KeyAgreement, is there still any >> reason for the premaster -> master_secret derivation step? >> We do (KA)->premaster and then premaster -> master and then >> master->(session keys). We could probably do >> (KA)->master->(session keys) where the master secret is now >> the KA shared secret rather than premaster. >> >> 1) Is there any security reason for retaining the extra step >> given there is no longer a KeyTransport mechanism in TLS1.3? >> 2) Are there other *good* - non-security - reasons for >> retaining the extra step? >> >> Mike >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > > --------------090505080707040208060905 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 7/30/2014 12:26 PM, Eric Rescorla wrote:



On Wed, Jul 30, 2014 at 9:21 AM, Michael StJohns <msj@nthpermutation.com> wrote:
On 7/30/2014 12:00 PM, Eric Rescorla wrote:
As discussed in the interim we are going to want to roll over the
MS periodically. Life will be a lot easier if it has a uniform structure.

Moreover, just because we aren't using key transport doesn't mean
there aren't other mechanisms with funky shared secrets, e.g.,
PSK.

I don't think either of these are show stoppers - although I don't know exactly what you mean by "uniform structure" here.  Do you mean "because that's the way its done in TLS1.2 and before and we want backwards compatibility"?

I mean always have the secret you use for key derivation be
the same size and unstructured and get to it the same way,
regardless of the starting secret.

Thus, I would prefer to stick with the same PMS->MS flow.

You already have a disconnect in size on with respect to the premaster secret - it's going to be 32 bytes for P256 ECDH, something larger for DH depending on the group. (random length) -> (48 bytes)

You also have a disconnect on the output - any number of keys of any size.  (48 bytes) -> (random sizes)

So why you think that its important to have an impedence match of  (random size} -> 48 bytes -> (random sizes) is unclear to me.

Is there a specific technical issue with {random length} -> { random lengths} that you can see?  I understand you have a preference, I'm asking if you can see a reason why this would weaken security?

There's the final issue that  - as I read the HMAC document and the precursor technical papers - you don't really get anything with respect to security using keys over the native output length of the underlying hash, and that you weaken security if you use less bits than that.  So 48 bytes is fine up to a hash of 384 bits, but is the possibly limiting security factor for anything larger.  I don't know that we're going to be going to anything above 192 bits of (to include 384 bit hash functions) any time soon, but I would hate for this 48 bit legacy value to be the unforeseen security ceiling.

*My* preference is for the input keys and the output keys to be matched to the needs of the cryptographic suite.  That 384 bits of premaster secret is good up to SHA384, but may represent a smaller security strength for non-NIST hashes.   I *think* this 48 octet value is the last fixed length security key in the standard.

Mike


-Ekr


In the former case, its pretty simple to do:

(KA)->master_secret -> next_master_secret  - either as part of the first context call (to derive the session and handshake keys), or as a separate context call (to specifically generate a new master secret.

E.g. the derive looks like:

(KA) -> master_secret
                 -> next_master_secret
                 -> handshake key
                 -> client_write_AEAD
                 -> server_write_AEAD

next_master_secret
         -> next_master_secret
         -> handshake_key
         -> client_write_AEAD
         -> server_write_AEAD

Or it looks like

(KA) -> master_secret (key expand)
         -> handshake key
         -> client_write_AEAD
         -> server_write_AEAD

master_secret (nextmaster)
      -> next_master_secret

(where key expand and nextmaster are differing labels and KDF contexts).

In the PSK case, with key transport, doing the pre_master->master derive allows you to mix in random data from both sides so that the master_secret isn't only chosen by one side so there's some security benefit there.  In the PSK model, that's not an issue as both sides have already agreed upon a key.

Mike




-Ekr



On Wed, Jul 30, 2014 at 7:56 AM, Michael StJohns <msj@nthpermutation.com> wrote:
Given that TLS1.3 only does KeyAgreement, is there still any reason for the premaster -> master_secret derivation step?  We do (KA)->premaster and then premaster -> master and then master->(session keys).   We could probably do (KA)->master->(session keys) where the master secret is now the KA shared secret rather than premaster.

1) Is there any security reason for retaining the extra step given there is no longer a KeyTransport mechanism in TLS1.3?
2) Are there other *good* - non-security - reasons for retaining the extra step?

Mike



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




--------------090505080707040208060905-- From nobody Wed Jul 30 13:58:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835F31A041F for ; Wed, 30 Jul 2014 13:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aavAvCUDo7HD for ; Wed, 30 Jul 2014 13:58:21 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2799C1A040A for ; Wed, 30 Jul 2014 13:58:20 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id w62so1794209wes.22 for ; Wed, 30 Jul 2014 13:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=4ho8uY73aBd22qJJUHqNfTvtaLkuLnnuzXw19tVIzHo=; b=lXX4HRRWTrAx88jS7XR849Dvz1fcNL1pFeIQ+0zIYHd/t7j0HMUnzqZdeiBax8S3LE Nzct8YhD0lUNCg0Lxg7aKnqDy/0Pad2+3JU2Pcj+ctl6q1V4wGoY8+4mqcKMlyu4m1Zj ZR1oIL7Godm0PVo76Y2tQmjcdtpNOoMSgMWsdW66WQl1kchLWQKNqGNCbyL4ycI0fddA ouFT+P4ziuPetM6sq5Wn15FKHbpR2rn9qxvjqRnRWGfu0Oi6W/KVoIjhxZxZ35NMPtM7 zwqurjMfUNhTvfD2JsPpwSpzMVT4OXIGAXssuc+KDSGAqvu7Gee+wXL0fg8D7KB5SakY UnXA== MIME-Version: 1.0 X-Received: by 10.180.73.6 with SMTP id h6mr9338760wiv.65.1406753899578; Wed, 30 Jul 2014 13:58:19 -0700 (PDT) Received: by 10.194.169.10 with HTTP; Wed, 30 Jul 2014 13:58:19 -0700 (PDT) Date: Wed, 30 Jul 2014 13:58:19 -0700 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sfwdlWg08MYMv8EevLdvNrSgxd4 Subject: [TLS] Key derivation processes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2014 20:58:23 -0000 We've had a bit of discussion thus far about the role of the PRF and its form. I think that having a map that describes what material goes where might help understanding the process. Here's how I think we should try to structure the flow of keying material: The handshake determines the PMS. That's not any different from TLS 1.2. >From the PMS, we derive a set of other keys and material derived from those keys. How that material is subsequently protected can vary depending on the requirements around its usage. - A client read/server write encryption key - A client read/server write IV - A client write/server read encryption key - A client write/server read IV - Input for calculating the Finished message - A TLS extractor [RFC5705] primitive to be used in place of the MS - A TLS unique [RFC5929] value - A resumption key that is used as input to the PMS of a resumed connection Then the PMS is discarded. This design is basically TLS extractor, which is no coincidence. The function that is used to derive each of these doesn't matter at this level of the description. The constraints here are well-known (triple handshake, etc...). That means that inputs probably include PMS (which is the resumption key if that's what is going on), plus everything that appears in the handshake prior to the start of encryption: version, client random, server random, cipher suite offer and selection (including group), and DH shares. I think that this addresses the concerns Mike StJohns has raised with the current read/write/IV generation function by having independent streams for keying material and IVs. I'll note that from the TLS extractor primitive you could derive several of these items rather than rely on the PMS. That would allow their creation to be deferred. The input to Finished is one possibility. TLS unique is another good candidate for this since it isn't intrinsic to the protocol; though we may want to wait until after we decide the fate of Finished before we determine the fate of TLS unique. That said, you really don't want to derive anything secret from the TLS extractor key, like the encryption keys, since that creates a nasty validation problem for extractor. Rekeying of the form that I proposed simply requires the application of a one-way function - which might be the same function as above - to the encryption keys (and IVs) in the affected direction. From nobody Wed Jul 30 13:58:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516911A0450 for ; Wed, 30 Jul 2014 13:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57YuMv1DlUr8 for ; Wed, 30 Jul 2014 13:58:49 -0700 (PDT) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E61DD1A041D for ; Wed, 30 Jul 2014 13:58:48 -0700 (PDT) Received: by mail-ig0-f178.google.com with SMTP id uq10so3661491igb.17 for ; Wed, 30 Jul 2014 13:58:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tPIE53c8XS/dWKD0TNFZwJbmmLdKQUKoc19NU03JjmY=; b=MZzafd3b6jnaWkiH1ZPvaDkBmvaH3Qy2B81Y8hVYK6mSVKBoyET4ZCns4n7TihzP6u FqhKprDo7myH39hCWZPSBV6wyM04dDj/gx4evQ+WgMDhscc/Ys7Ld3Q5+IZRgdFWSpfh CMJlv31qNLhq/sfoosTD3Img1WFS1G9sTr7uPTyMk8iH0Lp3CpaUXw161XuusMDySGgj v2SOjgt1R7JcKy8O09JY8s2ur4rT6BhWvyEOKWBTjFFOaZzCWkDdctNyFeARpjBPZIT9 bFfY0SPJ+2doPYNlfQHEPQNcbS4yuafqvmxkJY24uH3uD1RrZPhFpNJJ8Qlljl/Dhf7X zjQg== X-Gm-Message-State: ALoCoQmlowNxkBBbiLLFy2zdhZPj0oMUrat02E0dnCEfdQWTjOO6496IFI64SJnDwWouf2tir/2E X-Received: by 10.42.70.200 with SMTP id g8mr9143358icj.92.1406753927177; Wed, 30 Jul 2014 13:58:47 -0700 (PDT) Received: from [172.27.7.54] (75-104-68-185.mobility.exede.net. [75.104.68.185]) by mx.google.com with ESMTPSA id l6sm17433861igv.4.2014.07.30.13.58.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 13:58:46 -0700 (PDT) Message-ID: <53D95C7D.9060408@nthpermutation.com> Date: Wed, 30 Jul 2014 16:58:37 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Gero, Charlie" , "tls@ietf.org" References: <53D907B0.3000006@nthpermutation.com> <53D91332.9070103@nthpermutation.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hiNe59MdW5rjO3RCiIA_NzfqBGg Subject: Re: [TLS] Premaster/Master convention X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2014 20:58:52 -0000 On 7/30/2014 12:27 PM, Gero, Charlie wrote: > I can't go into details around it at this time. Suffice to say, we definitely do rely on the two being split. Hi Charlie - If someone said - "we depend on the packet formats to be predictable" I'd say they'd have a case for reliance and backwards compatibility. Saying that you did something that will break that is totally and completely opaque to the on-the-wire protocol spec and expecting the protocol spec not to change (assuming proper on-the-wire negotiation to describe said changes) seems to be pushing your luck. That said, the more details you can share, the better chance we have of doing something that won't annoy you. For example, would your system break if the master secret were no longer 48 octets? Would it break if the PRF were not based on SHA256? Would it break if the PRF were a CMAC vs an HMAC? I have no idea where this idea will go. It may go nowhere, in which case you're safe - for now. It may go into the protocol. I think if I were at akamai, I'd be looking at why this could be an issue, and how to remediate it even if it doesn't make it in. But that's just me. Mike > > -----Original Message----- > From: Michael StJohns [mailto:msj@nthpermutation.com] > Sent: Wednesday, July 30, 2014 11:46 AM > To: Gero, Charlie; tls@ietf.org > Subject: Re: [TLS] Premaster/Master convention > > On 7/30/2014 11:02 AM, Gero, Charlie wrote: >> We have a number of technologies at Akamai that utilize the fact that the PMS is split from the MS and that MS is produced in conjunction with the randoms. It allows us to do splitting between machines that have keys and those that don't (machines in safe locales and those which are simply terminators). I don't think we could use the same methods we use today without that sub step. It would make it very difficult for Akamai to adopt 1.3. > So you send the master secret from the handshaker machine out to several other machines which then do what with it? Couldn't you send the traffic keys instead? > > I'm not sure I understand the constraints you're working under. Could you expand on that? > > Thanks - Mike > > >> -----Original Message----- >> From: Michael StJohns [mailto:msj@nthpermutation.com] >> Sent: Wednesday, July 30, 2014 10:57 AM >> To: tls@ietf.org >> Subject: [TLS] Premaster/Master convention >> >> Given that TLS1.3 only does KeyAgreement, is there still any reason for the premaster -> master_secret derivation step? We do (KA)->premaster >> and then premaster -> master and then master->(session keys). We could >> probably do (KA)->master->(session keys) where the master secret is now the KA shared secret rather than premaster. >> >> 1) Is there any security reason for retaining the extra step given there is no longer a KeyTransport mechanism in TLS1.3? >> 2) Are there other *good* - non-security - reasons for retaining the extra step? >> >> Mike >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > > From nobody Wed Jul 30 14:04:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE231A050E for ; Wed, 30 Jul 2014 14:04:21 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWM_x6QOQ3v4 for ; Wed, 30 Jul 2014 14:04:19 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id C283E1A04C2 for ; Wed, 30 Jul 2014 14:04:19 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 411A228637; Wed, 30 Jul 2014 21:04:19 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 2D53428605; Wed, 30 Jul 2014 21:04:19 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id EDF818003C; Wed, 30 Jul 2014 21:04:18 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Wed, 30 Jul 2014 17:04:18 -0400 From: "Salz, Rich" To: Michael StJohns , "Gero, Charlie" , "tls@ietf.org" Date: Wed, 30 Jul 2014 17:04:17 -0400 Thread-Topic: [TLS] Premaster/Master convention Thread-Index: Ac+sORqG6ciLzx1TT5KoZO1u72LP5gAAKPyg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C718599EE1A6@USMBX1.msg.corp.akamai.com> References: <53D907B0.3000006@nthpermutation.com> <53D91332.9070103@nthpermutation.com> <53D95C7D.9060408@nthpermutation.com> In-Reply-To: <53D95C7D.9060408@nthpermutation.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JiAT1M86stOVFvHHKX5peq7S_cY Subject: Re: [TLS] Premaster/Master convention X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2014 21:04:21 -0000 > changes) seems to be pushing your luck. Duly noted, and we don't disagree. /r$ -- =20 Principal Security Engineer Akamai Technologies, Cambridge MA IM: rsalz@jabber.me Twitter: RichSalz From nobody Wed Jul 30 14:30:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAFD1A05C0 for ; Wed, 30 Jul 2014 14:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmnEBXYpf9vf for ; Wed, 30 Jul 2014 14:30:56 -0700 (PDT) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DE951A049F for ; Wed, 30 Jul 2014 14:30:56 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id rp18so2360811iec.5 for ; Wed, 30 Jul 2014 14:30:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=xijQeA0YUK2ymm5/hkOMysv3IJq+A12khMBg6BGTNok=; b=X7+/teH6Rb1sMN+PlQFnv2FD675A+zVr7zUtE+ZWQOzt+6mGFZKUZkKb73/WjuE3x2 jtj3wSjmhKfi340B+dDXYNAfsD3XTUfjFT6FYFkS43z3LAPbj/cST8wAbKJDqhTJEJxk TZ96EmFTTdmZvra9RhABoVexO3d2FT1uTgNrc2xOBXvjd/zXDFBwiRBP6BpPIYc72Jto iV/pLXJgAZ/4q0XHWCSuD4wJJjGLRNTKhrmM7OvyaJWKV3NfA+kF+QjUs1lWNJU/y83F /gn9Bkxa3mgqR2AY5CmZ8b8XByXAcBiy8o4a9lSN+mKCLBhs9xDcsstnMbb0UlvogSxK Z/0g== X-Gm-Message-State: ALoCoQkkg9t8hWd8wv+5frU8hVDkWFl8GZ0MZZBLuez8fqGjOzrp4na4ItSze9O42eqQheAvQYb+ X-Received: by 10.43.149.200 with SMTP id kl8mr9202312icc.52.1406755855893; Wed, 30 Jul 2014 14:30:55 -0700 (PDT) Received: from [172.27.7.54] (75-104-68-185.mobility.exede.net. [75.104.68.185]) by mx.google.com with ESMTPSA id j5sm52877796ige.12.2014.07.30.14.30.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 14:30:55 -0700 (PDT) Message-ID: <53D96408.1060101@nthpermutation.com> Date: Wed, 30 Jul 2014 17:30:48 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "tls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IwROhTsF_ZChIU7irlZ97I-6660 Subject: [TLS] HMAC vs HASH X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 21:30:58 -0000 Hi - Slightly different topic from before. The signature over the finished messages is TLS-PRF(HASH (handshake messages)). My question - assuming the HASH and TLS-PRF both use SHA256 - what is the security strength of that signature function? I note that back in the archive that Marsh Ray from Microsoft took a swing at this (https://www.ietf.org/mail-archive/web/tls/current/msg10584.html) and concluded it wasn't an issue, but he was looking at it from the viewpoint of recovery of the HMAC key, but I'm not sure this is the worst case viewpoint. As I read the guidance, HMAC-SHA256 is 256 bit secure, but SHA256 is only 128 bit secure with respect to signatures. If that's the case, is the handshake finished message signature security any stronger than the signature strength of the hash function? E.g. 128 bits for a SHA256 hash? Note that I'm not having a discussion about whether or not 128 bits is sufficient, but whether or not SHA256 as the summary hash function represents the weakest part of the cipher suite for suites with bit strengths above 128 bits. Mike From nobody Wed Jul 30 17:44:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD1F1A05C0 for ; Wed, 30 Jul 2014 17:44:12 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPWesw0KknWF for ; Wed, 30 Jul 2014 17:44:09 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 97D4D1A03BA for ; Wed, 30 Jul 2014 17:44:07 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D4D9F28677; Thu, 31 Jul 2014 00:44:05 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id C126628676; Thu, 31 Jul 2014 00:44:05 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id B625A2026; Thu, 31 Jul 2014 00:44:05 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Wed, 30 Jul 2014 20:44:04 -0400 From: "Gero, Charlie" To: Michael StJohns Date: Wed, 30 Jul 2014 20:44:03 -0400 Thread-Topic: [TLS] Premaster/Master convention Thread-Index: Ac+sWIeUWftYBT0kSqGydt3KXn/TLg== Message-ID: <6ECEF2D7-A1AE-4AC4-90C5-62A38075B0BF@akamai.com> References: <53D907B0.3000006@nthpermutation.com> <53D91332.9070103@nthpermutation.com> <53D95C7D.9060408@nthpermutation.com> In-Reply-To: <53D95C7D.9060408@nthpermutation.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6ECEF2D7A1AE4AC490C562A38075B0BFakamaicom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gaMGsiM9xRLTGOXx49-s7DuvoqU Cc: "tls@ietf.org" Subject: Re: [TLS] Premaster/Master convention X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Jul 2014 00:44:12 -0000 --_000_6ECEF2D7A1AE4AC490C562A38075B0BFakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWljaGFlbCwNCg0KUmVzcGVjdGZ1bGx5LCB0aGVyZSBhcmUgdGhpbmdzIHRoYXQgd2UgY2FuIGFu ZCBjYW4gbm90IGRpdnVsZ2UuICBJIHdpbGwgY29udGludWUgdG8gbW9uaXRvciB0aGlzIHBhdGgg YW5kIHdpbGwgdXBkYXRlIGFzIG5lY2Vzc2FyeSBpZiByZW1vdmFsIG9mIHRoZSBQTVMgdG8gTVMg c3RlcCBsb29rcyBsaWtlIGl0IGlzIGdhaW5pbmcgdHJhY3Rpb24uICBJJ20gbm90IHN1cmUgaXQg aXMuICBDZXJ0YWlubHksIEFrYW1haSByZXByZXNlbnRzIGEgc2lnbmlmaWNhbnQgYW1vdW50IG9m IFNTTCB0cmFmZmljIG9uIHRoZSBJbnRlcm5ldCwgc28gd2Ugd2FudCB0byBtYWtlIHN1cmUgd2Ug ZnV0dXJlIHByb29mIG91ciBkZXNpZ25zLiAgTXkgbm90IHRlbGxpbmcgeW91IG9mIGhvdyB0aGUg aW50ZXJuYWxzIHdvcmsgc2hvdWxkIG5vdCBiZSBjb25zdHJ1ZWQgdGhhdCB3ZSdyZSBub3QgdHJ5 aW5nIHRvIGd1YXJkIGFnYWluc3QgdGhpcyBhbmQgb3RoZXIgcG9zc2libGUgY2hhbmdlcy4gIEl0 IGlzIHNpbXBseSByZWxheWluZyB0byB5b3UgYSByZWFsIHdvcmxkIGZhY3Qgd2l0aG91dCBkaXZ1 bGdpbmcgd2hhdCBJIGNhbiBub3QgZGl2dWxnZS4NCg0KQ2hhcmxpZSBHZXJvDQpTZW5pb3IgUHJp bmNpcGFsIFN5c3RlbSBTb2Z0d2FyZSBFbmdpbmVlcg0KVGVhbSBMZWFkIEVuZ2luZWVyaW5nIC0g QWthbWFpIExhYnMNCjYxNy40NDQuMzk0MA0KDQpPbiBKdWwgMzAsIDIwMTQsIGF0IDQ6NTkgUE0s ICJNaWNoYWVsIFN0Sm9obnMiIDxtc2pAbnRocGVybXV0YXRpb24uY29tPG1haWx0bzptc2pAbnRo cGVybXV0YXRpb24uY29tPj4gd3JvdGU6DQoNCk9uIDcvMzAvMjAxNCAxMjoyNyBQTSwgR2Vybywg Q2hhcmxpZSB3cm90ZToNCkkgY2FuJ3QgZ28gaW50byBkZXRhaWxzIGFyb3VuZCBpdCBhdCB0aGlz IHRpbWUuICBTdWZmaWNlIHRvIHNheSwgd2UgZGVmaW5pdGVseSBkbyByZWx5IG9uIHRoZSB0d28g YmVpbmcgc3BsaXQuDQpIaSBDaGFybGllIC0NCg0KDQpJZiBzb21lb25lIHNhaWQgLSAid2UgZGVw ZW5kIG9uIHRoZSBwYWNrZXQgZm9ybWF0cyB0byBiZSBwcmVkaWN0YWJsZSINCkknZCBzYXkgdGhl eSdkIGhhdmUgYSBjYXNlIGZvciByZWxpYW5jZSBhbmQgYmFja3dhcmRzIGNvbXBhdGliaWxpdHku DQpTYXlpbmcgdGhhdCB5b3UgZGlkIHNvbWV0aGluZyB0aGF0IHdpbGwgYnJlYWsgdGhhdCBpcyB0 b3RhbGx5IGFuZA0KY29tcGxldGVseSBvcGFxdWUgdG8gdGhlIG9uLXRoZS13aXJlIHByb3RvY29s IHNwZWMgYW5kIGV4cGVjdGluZyB0aGUNCnByb3RvY29sIHNwZWMgbm90IHRvIGNoYW5nZSAoYXNz dW1pbmcgcHJvcGVyIG9uLXRoZS13aXJlIG5lZ290aWF0aW9uIHRvDQpkZXNjcmliZSBzYWlkIGNo YW5nZXMpIHNlZW1zIHRvIGJlIHB1c2hpbmcgeW91ciBsdWNrLg0KDQpUaGF0IHNhaWQsIHRoZSBt b3JlIGRldGFpbHMgeW91IGNhbiBzaGFyZSwgdGhlIGJldHRlciBjaGFuY2Ugd2UgaGF2ZSBvZg0K ZG9pbmcgc29tZXRoaW5nIHRoYXQgd29uJ3QgYW5ub3kgeW91LiAgRm9yIGV4YW1wbGUsIHdvdWxk IHlvdXIgc3lzdGVtDQpicmVhayBpZiB0aGUgbWFzdGVyIHNlY3JldCB3ZXJlIG5vIGxvbmdlciA0 OCBvY3RldHM/ICBXb3VsZCBpdCBicmVhayBpZg0KdGhlIFBSRiB3ZXJlIG5vdCBiYXNlZCBvbiBT SEEyNTY/ICBXb3VsZCBpdCBicmVhayBpZiB0aGUgUFJGIHdlcmUgYSBDTUFDDQp2cyBhbiBITUFD Pw0KDQpJIGhhdmUgbm8gaWRlYSB3aGVyZSB0aGlzIGlkZWEgd2lsbCBnby4gIEl0IG1heSBnbyBu b3doZXJlLCBpbiB3aGljaA0KY2FzZSB5b3UncmUgc2FmZSAtIGZvciBub3cuICBJdCBtYXkgZ28g aW50byB0aGUgcHJvdG9jb2wuICBJIHRoaW5rIGlmIEkNCndlcmUgYXQgYWthbWFpLCBJJ2QgYmUg bG9va2luZyBhdCB3aHkgdGhpcyBjb3VsZCBiZSBhbiBpc3N1ZSwgYW5kIGhvdyB0bw0KcmVtZWRp YXRlIGl0IGV2ZW4gaWYgaXQgZG9lc24ndCBtYWtlIGl0IGluLiAgQnV0IHRoYXQncyBqdXN0IG1l Lg0KDQpNaWtlDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNaWNo YWVsIFN0Sm9obnMgW21haWx0bzptc2pAbnRocGVybXV0YXRpb24uY29tXQ0KU2VudDogV2VkbmVz ZGF5LCBKdWx5IDMwLCAyMDE0IDExOjQ2IEFNDQpUbzogR2VybywgQ2hhcmxpZTsgdGxzQGlldGYu b3JnPG1haWx0bzp0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1RMU10gUHJlbWFzdGVyL01h c3RlciBjb252ZW50aW9uDQoNCk9uIDcvMzAvMjAxNCAxMTowMiBBTSwgR2VybywgQ2hhcmxpZSB3 cm90ZToNCldlIGhhdmUgYSBudW1iZXIgb2YgdGVjaG5vbG9naWVzIGF0IEFrYW1haSB0aGF0IHV0 aWxpemUgdGhlIGZhY3QgdGhhdCB0aGUgUE1TIGlzIHNwbGl0IGZyb20gdGhlIE1TIGFuZCB0aGF0 IE1TIGlzIHByb2R1Y2VkIGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIHJhbmRvbXMuICBJdCBhbGxv d3MgdXMgdG8gZG8gc3BsaXR0aW5nIGJldHdlZW4gbWFjaGluZXMgdGhhdCBoYXZlIGtleXMgYW5k IHRob3NlIHRoYXQgZG9uJ3QgKG1hY2hpbmVzIGluIHNhZmUgbG9jYWxlcyBhbmQgdGhvc2Ugd2hp Y2ggYXJlIHNpbXBseSB0ZXJtaW5hdG9ycykuICBJIGRvbid0IHRoaW5rIHdlIGNvdWxkIHVzZSB0 aGUgc2FtZSBtZXRob2RzIHdlIHVzZSB0b2RheSB3aXRob3V0IHRoYXQgc3ViIHN0ZXAuICBJdCB3 b3VsZCBtYWtlIGl0IHZlcnkgZGlmZmljdWx0IGZvciBBa2FtYWkgdG8gYWRvcHQgMS4zLg0KU28g eW91IHNlbmQgdGhlIG1hc3RlciBzZWNyZXQgZnJvbSB0aGUgaGFuZHNoYWtlciBtYWNoaW5lIG91 dCB0byBzZXZlcmFsIG90aGVyIG1hY2hpbmVzIHdoaWNoIHRoZW4gZG8gd2hhdCB3aXRoIGl0PyAg Q291bGRuJ3QgeW91IHNlbmQgdGhlIHRyYWZmaWMga2V5cyBpbnN0ZWFkPw0KDQpJJ20gbm90IHN1 cmUgSSB1bmRlcnN0YW5kIHRoZSBjb25zdHJhaW50cyB5b3UncmUgd29ya2luZyB1bmRlci4gQ291 bGQgeW91IGV4cGFuZCBvbiB0aGF0Pw0KDQpUaGFua3MgLSBNaWtlDQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IE1pY2hhZWwgU3RKb2hucyBbbWFpbHRvOm1zakBudGhwZXJt dXRhdGlvbi5jb21dDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMzAsIDIwMTQgMTA6NTcgQU0NClRv OiB0bHNAaWV0Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFtUTFNdIFByZW1h c3Rlci9NYXN0ZXIgY29udmVudGlvbg0KDQpHaXZlbiB0aGF0IFRMUzEuMyBvbmx5IGRvZXMgS2V5 QWdyZWVtZW50LCBpcyB0aGVyZSBzdGlsbCBhbnkgcmVhc29uIGZvciB0aGUgcHJlbWFzdGVyIC0+ IG1hc3Rlcl9zZWNyZXQgZGVyaXZhdGlvbiBzdGVwPyAgV2UgZG8gKEtBKS0+cHJlbWFzdGVyDQph bmQgdGhlbiBwcmVtYXN0ZXIgLT4gbWFzdGVyIGFuZCB0aGVuIG1hc3Rlci0+KHNlc3Npb24ga2V5 cykuICAgV2UgY291bGQNCnByb2JhYmx5IGRvIChLQSktPm1hc3Rlci0+KHNlc3Npb24ga2V5cykg d2hlcmUgdGhlIG1hc3RlciBzZWNyZXQgaXMgbm93IHRoZSBLQSBzaGFyZWQgc2VjcmV0IHJhdGhl ciB0aGFuIHByZW1hc3Rlci4NCg0KMSkgSXMgdGhlcmUgYW55IHNlY3VyaXR5IHJlYXNvbiBmb3Ig cmV0YWluaW5nIHRoZSBleHRyYSBzdGVwIGdpdmVuIHRoZXJlIGlzIG5vIGxvbmdlciBhIEtleVRy YW5zcG9ydCBtZWNoYW5pc20gaW4gVExTMS4zPw0KMikgQXJlIHRoZXJlIG90aGVyICpnb29kKiAt IG5vbi1zZWN1cml0eSAtIHJlYXNvbnMgZm9yIHJldGFpbmluZyB0aGUgZXh0cmEgc3RlcD8NCg0K TWlrZQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg0KDQoNCg0KDQo= --_000_6ECEF2D7A1AE4AC490C562A38075B0BFakamaicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+TWljaGFl bCw8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlJlc3BlY3RmdWxseSwgdGhlcmUgYXJlIHRoaW5n cyB0aGF0IHdlIGNhbiBhbmQgY2FuIG5vdCBkaXZ1bGdlLiAmbmJzcDtJIHdpbGwgY29udGludWUg dG8gbW9uaXRvciB0aGlzIHBhdGggYW5kIHdpbGwgdXBkYXRlIGFzIG5lY2Vzc2FyeSBpZiByZW1v dmFsIG9mIHRoZSBQTVMgdG8gTVMgc3RlcCBsb29rcyBsaWtlIGl0IGlzIGdhaW5pbmcgdHJhY3Rp b24uICZuYnNwO0knbSBub3Qgc3VyZSBpdCBpcy4gJm5ic3A7Q2VydGFpbmx5LCBBa2FtYWkgcmVw cmVzZW50cyBhIHNpZ25pZmljYW50IGFtb3VudCBvZiBTU0wgdHJhZmZpYyBvbiB0aGUgSW50ZXJu ZXQsIHNvIHdlIHdhbnQgdG8gbWFrZSBzdXJlIHdlIGZ1dHVyZSBwcm9vZiBvdXIgZGVzaWducy4g Jm5ic3A7TXkgbm90IHRlbGxpbmcgeW91IG9mIGhvdyB0aGUgaW50ZXJuYWxzIHdvcmsgc2hvdWxk IG5vdCBiZSBjb25zdHJ1ZWQgdGhhdCB3ZSdyZSBub3QgdHJ5aW5nIHRvIGd1YXJkIGFnYWluc3Qg dGhpcyBhbmQgb3RoZXIgcG9zc2libGUgY2hhbmdlcy4gJm5ic3A7SXQgaXMgc2ltcGx5IHJlbGF5 aW5nIHRvIHlvdSBhIHJlYWwgd29ybGQgZmFjdCB3aXRob3V0IGRpdnVsZ2luZyB3aGF0IEkgY2Fu IG5vdCBkaXZ1bGdlLjwvZGl2PjxkaXY+PGJyPjxiPkNoYXJsaWUgR2VybzwvYj48ZGl2PlNlbmlv ciBQcmluY2lwYWwgU3lzdGVtIFNvZnR3YXJlIEVuZ2luZWVyPC9kaXY+PGRpdj5UZWFtIExlYWQg RW5naW5lZXJpbmcgLSBBa2FtYWkgTGFiczwvZGl2PjxkaXY+PC9kaXY+PGRpdj42MTcuNDQ0LjM5 NDA8L2Rpdj48L2Rpdj48ZGl2Pjxicj5PbiBKdWwgMzAsIDIwMTQsIGF0IDQ6NTkgUE0sICJNaWNo YWVsIFN0Sm9obnMiICZsdDs8YSBocmVmPSJtYWlsdG86bXNqQG50aHBlcm11dGF0aW9uLmNvbSI+ bXNqQG50aHBlcm11dGF0aW9uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj48YnI+PC9kaXY+PGRpdj48 c3Bhbj5PbiA3LzMwLzIwMTQgMTI6MjcgUE0sIEdlcm8sIENoYXJsaWUgd3JvdGU6PC9zcGFuPjxi cj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5JIGNhbid0IGdvIGludG8gZGV0YWlscyBh cm91bmQgaXQgYXQgdGhpcyB0aW1lLiAmbmJzcDtTdWZmaWNlIHRvIHNheSwgd2UgZGVmaW5pdGVs eSBkbyByZWx5IG9uIHRoZSB0d28gYmVpbmcgc3BsaXQuPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+ PHNwYW4+SGkgQ2hhcmxpZSAtPC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPjwvc3Bh bj48YnI+PHNwYW4+SWYgc29tZW9uZSBzYWlkIC0gIndlIGRlcGVuZCBvbiB0aGUgcGFja2V0IGZv cm1hdHMgdG8gYmUgcHJlZGljdGFibGUiIDwvc3Bhbj48YnI+PHNwYW4+SSdkIHNheSB0aGV5J2Qg aGF2ZSBhIGNhc2UgZm9yIHJlbGlhbmNlIGFuZCBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eS4gJm5i c3A7PC9zcGFuPjxicj48c3Bhbj5TYXlpbmcgdGhhdCB5b3UgZGlkIHNvbWV0aGluZyB0aGF0IHdp bGwgYnJlYWsgdGhhdCBpcyB0b3RhbGx5IGFuZCA8L3NwYW4+PGJyPjxzcGFuPmNvbXBsZXRlbHkg b3BhcXVlIHRvIHRoZSBvbi10aGUtd2lyZSBwcm90b2NvbCBzcGVjIGFuZCBleHBlY3RpbmcgdGhl IDwvc3Bhbj48YnI+PHNwYW4+cHJvdG9jb2wgc3BlYyBub3QgdG8gY2hhbmdlIChhc3N1bWluZyBw cm9wZXIgb24tdGhlLXdpcmUgbmVnb3RpYXRpb24gdG8gPC9zcGFuPjxicj48c3Bhbj5kZXNjcmli ZSBzYWlkIGNoYW5nZXMpIHNlZW1zIHRvIGJlIHB1c2hpbmcgeW91ciBsdWNrLjwvc3Bhbj48YnI+ PHNwYW4+PC9zcGFuPjxicj48c3Bhbj5UaGF0IHNhaWQsIHRoZSBtb3JlIGRldGFpbHMgeW91IGNh biBzaGFyZSwgdGhlIGJldHRlciBjaGFuY2Ugd2UgaGF2ZSBvZiA8L3NwYW4+PGJyPjxzcGFuPmRv aW5nIHNvbWV0aGluZyB0aGF0IHdvbid0IGFubm95IHlvdS4gJm5ic3A7Rm9yIGV4YW1wbGUsIHdv dWxkIHlvdXIgc3lzdGVtIDwvc3Bhbj48YnI+PHNwYW4+YnJlYWsgaWYgdGhlIG1hc3RlciBzZWNy ZXQgd2VyZSBubyBsb25nZXIgNDggb2N0ZXRzPyAmbmJzcDtXb3VsZCBpdCBicmVhayBpZiA8L3Nw YW4+PGJyPjxzcGFuPnRoZSBQUkYgd2VyZSBub3QgYmFzZWQgb24gU0hBMjU2PyAmbmJzcDtXb3Vs ZCBpdCBicmVhayBpZiB0aGUgUFJGIHdlcmUgYSBDTUFDIDwvc3Bhbj48YnI+PHNwYW4+dnMgYW4g SE1BQz88L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+SSBoYXZlIG5vIGlkZWEgd2hl cmUgdGhpcyBpZGVhIHdpbGwgZ28uICZuYnNwO0l0IG1heSBnbyBub3doZXJlLCBpbiB3aGljaCA8 L3NwYW4+PGJyPjxzcGFuPmNhc2UgeW91J3JlIHNhZmUgLSBmb3Igbm93LiAmbmJzcDtJdCBtYXkg Z28gaW50byB0aGUgcHJvdG9jb2wuICZuYnNwO0kgdGhpbmsgaWYgSSA8L3NwYW4+PGJyPjxzcGFu PndlcmUgYXQgYWthbWFpLCBJJ2QgYmUgbG9va2luZyBhdCB3aHkgdGhpcyBjb3VsZCBiZSBhbiBp c3N1ZSwgYW5kIGhvdyB0byA8L3NwYW4+PGJyPjxzcGFuPnJlbWVkaWF0ZSBpdCBldmVuIGlmIGl0 IGRvZXNuJ3QgbWFrZSBpdCBpbi4gJm5ic3A7QnV0IHRoYXQncyBqdXN0IG1lLjwvc3Bhbj48YnI+ PHNwYW4+PC9zcGFuPjxicj48c3Bhbj5NaWtlPC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxz cGFuPjwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxicj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48 c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bh bj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPkZyb206IE1pY2hhZWwgU3RKb2hucyBbPGEgaHJlZj0i bWFpbHRvOm1zakBudGhwZXJtdXRhdGlvbi5jb20iPm1haWx0bzptc2pAbnRocGVybXV0YXRpb24u Y29tPC9hPl08L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48 c3Bhbj5TZW50OiBXZWRuZXNkYXksIEp1bHkgMzAsIDIwMTQgMTE6NDYgQU08L3NwYW4+PGJyPjwv YmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5UbzogR2VybywgQ2hhcmxp ZTsgPGEgaHJlZj0ibWFpbHRvOnRsc0BpZXRmLm9yZyI+dGxzQGlldGYub3JnPC9hPjwvc3Bhbj48 YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPlN1YmplY3Q6IFJl OiBbVExTXSBQcmVtYXN0ZXIvTWFzdGVyIGNvbnZlbnRpb248L3NwYW4+PGJyPjwvYmxvY2txdW90 ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5PbiA3LzMwLzIwMTQgMTE6MDIgQU0sIEdlcm8s IENoYXJsaWUgd3JvdGU6PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+V2UgaGF2ZSBhIG51bWJlciBvZiB0 ZWNobm9sb2dpZXMgYXQgQWthbWFpIHRoYXQgdXRpbGl6ZSB0aGUgZmFjdCB0aGF0IHRoZSBQTVMg aXMgc3BsaXQgZnJvbSB0aGUgTVMgYW5kIHRoYXQgTVMgaXMgcHJvZHVjZWQgaW4gY29uanVuY3Rp b24gd2l0aCB0aGUgcmFuZG9tcy4gJm5ic3A7SXQgYWxsb3dzIHVzIHRvIGRvIHNwbGl0dGluZyBi ZXR3ZWVuIG1hY2hpbmVzIHRoYXQgaGF2ZSBrZXlzIGFuZCB0aG9zZSB0aGF0IGRvbid0IChtYWNo aW5lcyBpbiBzYWZlIGxvY2FsZXMgYW5kIHRob3NlIHdoaWNoIGFyZSBzaW1wbHkgdGVybWluYXRv cnMpLiAmbmJzcDtJIGRvbid0IHRoaW5rIHdlIGNvdWxkIHVzZSB0aGUgc2FtZSBtZXRob2RzIHdl IHVzZSB0b2RheSB3aXRob3V0IHRoYXQgc3ViIHN0ZXAuICZuYnNwO0l0IHdvdWxkIG1ha2UgaXQg dmVyeSBkaWZmaWN1bHQgZm9yIEFrYW1haSB0byBhZG9wdCAxLjMuPC9zcGFuPjxicj48L2Jsb2Nr cXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPlNvIHlvdSBz ZW5kIHRoZSBtYXN0ZXIgc2VjcmV0IGZyb20gdGhlIGhhbmRzaGFrZXIgbWFjaGluZSBvdXQgdG8g c2V2ZXJhbCBvdGhlciBtYWNoaW5lcyB3aGljaCB0aGVuIGRvIHdoYXQgd2l0aCBpdD8gJm5ic3A7 Q291bGRuJ3QgeW91IHNlbmQgdGhlIHRyYWZmaWMga2V5cyBpbnN0ZWFkPzwvc3Bhbj48YnI+PC9i bG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9j a3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPkknbSBub3Qgc3VyZSBJIHVuZGVy c3RhbmQgdGhlIGNvbnN0cmFpbnRzIHlvdSdyZSB3b3JraW5nIHVuZGVyLiBDb3VsZCB5b3UgZXhw YW5kIG9uIHRoYXQ/PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PHNwYW4+VGhhbmtzIC0gTWlrZTwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPkZyb206IE1pY2hhZWwgU3RKb2hu cyBbPGEgaHJlZj0ibWFpbHRvOm1zakBudGhwZXJtdXRhdGlvbi5jb20iPm1haWx0bzptc2pAbnRo cGVybXV0YXRpb24uY29tPC9hPl08L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+U2Vu dDogV2VkbmVzZGF5LCBKdWx5IDMwLCAyMDE0IDEwOjU3IEFNPC9zcGFuPjxicj48L2Jsb2NrcXVv dGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPjxzcGFuPlRvOiA8YSBocmVmPSJtYWlsdG86dGxzQGlldGYub3JnIj50bHNAaWV0Zi5v cmc8L2E+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPlN1YmplY3Q6IFtUTFNdIFBy ZW1hc3Rlci9NYXN0ZXIgY29udmVudGlvbjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2tx dW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bh bj48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+R2l2ZW4gdGhhdCBUTFMxLjMgb25s eSBkb2VzIEtleUFncmVlbWVudCwgaXMgdGhlcmUgc3RpbGwgYW55IHJlYXNvbiBmb3IgdGhlIHBy ZW1hc3RlciAtJmd0OyBtYXN0ZXJfc2VjcmV0IGRlcml2YXRpb24gc3RlcD8gJm5ic3A7V2UgZG8g KEtBKS0mZ3Q7cHJlbWFzdGVyPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPmFuZCB0 aGVuIHByZW1hc3RlciAtJmd0OyBtYXN0ZXIgYW5kIHRoZW4gbWFzdGVyLSZndDsoc2Vzc2lvbiBr ZXlzKS4gJm5ic3A7Jm5ic3A7V2UgY291bGQ8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2Nr cXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNw YW4+cHJvYmFibHkgZG8gKEtBKS0mZ3Q7bWFzdGVyLSZndDsoc2Vzc2lvbiBrZXlzKSB3aGVyZSB0 aGUgbWFzdGVyIHNlY3JldCBpcyBub3cgdGhlIEtBIHNoYXJlZCBzZWNyZXQgcmF0aGVyIHRoYW4g cHJlbWFzdGVyLjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPjwv YmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PHNwYW4+MSkgSXMgdGhlcmUgYW55IHNlY3VyaXR5IHJlYXNvbiBmb3Ig cmV0YWluaW5nIHRoZSBleHRyYSBzdGVwIGdpdmVuIHRoZXJlIGlzIG5vIGxvbmdlciBhIEtleVRy YW5zcG9ydCBtZWNoYW5pc20gaW4gVExTMS4zPzwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxv Y2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48 c3Bhbj4yKSBBcmUgdGhlcmUgb3RoZXIgKmdvb2QqIC0gbm9uLXNlY3VyaXR5IC0gcmVhc29ucyBm b3IgcmV0YWluaW5nIHRoZSBleHRyYSBzdGVwPzwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxv Y2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48 c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+TWlrZTwvc3Bhbj48YnI+PC9i bG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9z cGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwv YmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwv c3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5UTFMgbWFpbGluZyBsaXN0PC9zcGFuPjxi cj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRM U0BpZXRmLm9yZzwvYT48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPC9hPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwv YmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij48c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Js b2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bh bj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48 YnI+PC9ibG9ja3F1b3RlPjxzcGFuPjwvc3Bhbj48YnI+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_6ECEF2D7A1AE4AC490C562A38075B0BFakamaicom_-- From nobody Wed Jul 30 18:19:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1851A016D for ; Wed, 30 Jul 2014 18:18:59 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DCvgJkcrq1Y for ; Wed, 30 Jul 2014 18:18:56 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 5282D1A0076 for ; Wed, 30 Jul 2014 18:18:56 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CB7EF1657B0; Thu, 31 Jul 2014 01:18:55 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id C07211657AF; Thu, 31 Jul 2014 01:18:55 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 938CD1E043; Thu, 31 Jul 2014 01:18:55 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Wed, 30 Jul 2014 21:18:55 -0400 From: "Gero, Charlie" To: Michael StJohns Date: Wed, 30 Jul 2014 21:18:53 -0400 Thread-Topic: [TLS] Premaster/Master convention Thread-Index: Ac+sXWU5nP7LaK9qQEWoYQO380mTGw== Message-ID: References: <53D907B0.3000006@nthpermutation.com> <53D91332.9070103@nthpermutation.com> <53D95C7D.9060408@nthpermutation.com> <6ECEF2D7-A1AE-4AC4-90C5-62A38075B0BF@akamai.com> In-Reply-To: <6ECEF2D7-A1AE-4AC4-90C5-62A38075B0BF@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BD06808028544EBAA96E1030CB7C1CFFakamaicom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eZ5Gj3elZ4ur3NXVMCc5CBZVsFM Cc: "tls@ietf.org" Subject: Re: [TLS] Premaster/Master convention X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Jul 2014 01:18:59 -0000 --_000_BD06808028544EBAA96E1030CB7C1CFFakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnkgZm9yIHRoZSBzZWNvbmQgbGF0ZSByZXNwb25zZS4gIEhlY3RpYyBkYXkuICBIZXJlJ3Mg YSBmb2xsb3cgdXAgZnJvbSB0aGUgcHJldmlvdXMuDQoNCk1pc3NlZCBhbnN3ZXJpbmcgeW91ciBv cmlnaW5hbCBxdWVzdGlvbnM6DQpXb3VsZCB5b3VyIHN5c3RlbSBicmVhayBpZiB0aGUgbWFzdGVy IHNlY3JldCB3ZXJlIG5vIGxvbmdlciA0OCBvY3RldHM/IE5vLg0KV291bGQgaXQgYnJlYWsgaWYg dGhlIFBSRiB3ZXJlIG5vdCBiYXNlZCBvbiBTSEEyNTY/ICBOby4NCldvdWxkIGl0IGJyZWFrIGlm IHRoZSBQUkYgd2VyZSBhIENNQUMgdnMgYW4gSE1BQz8gTm8uDQoNCkluIGFkZGl0aW9uLCBhcyBs b25nIGFzIFRMUyAxLjMga2VlcHMgc3RhdGljIFJTQSBrZXkgZXhjaGFuZ2UgYW5kIHJlbmVnb3Rp YXRpb24gb3V0IGFzIHdlbGwgYXMgb25seSByZW1vdmluZyBQTVMgdG8gTVMgaW4gMS4zIGFuZCBs YXRlciwgd2Ugc2hvdWxkIGJlIG9rLiAgQXMgc29tZW9uZSBhZGVwdGx5IGluZmVycmVkIGVhcmxp ZXIsIHRoaXMgaXMgd2hlcmUgdGhpbmdzIHdvdWxkIGdldCBoYWlyeSBmb3IgdXMgaWYgYW55IG9m IHRoZXNlIGNvbnN0cmFpbnRzIGFyZSB2aW9sYXRlZC4NCg0KQWdhaW4sIEknbSBub3Qgc3VyZSB0 aGlzIGhhcyBzdGVhbSBiZWhpbmQgaXQgb3Igbm90IChvbmx5IHRpbWUgd2lsbCB0ZWxsKSBidXQg d2Ugc2hvdWxkIGJlIGFibGUgdG8gd29yayBvdXQgdGhpbmdzIGdpdmVuIHRob3NlIGNvbnN0cmFp bnRzLg0KDQpSZWdhcmRzLA0KQ2hhcmxpZQ0KDQpPbiBKdWwgMzAsIDIwMTQsIGF0IDg6NDQgUE0s ICJHZXJvLCBDaGFybGllIiA8Y2dlcm9AYWthbWFpLmNvbTxtYWlsdG86Y2dlcm9AYWthbWFpLmNv bT4+IHdyb3RlOg0KDQpNaWNoYWVsLA0KDQpSZXNwZWN0ZnVsbHksIHRoZXJlIGFyZSB0aGluZ3Mg dGhhdCB3ZSBjYW4gYW5kIGNhbiBub3QgZGl2dWxnZS4gIEkgd2lsbCBjb250aW51ZSB0byBtb25p dG9yIHRoaXMgcGF0aCBhbmQgd2lsbCB1cGRhdGUgYXMgbmVjZXNzYXJ5IGlmIHJlbW92YWwgb2Yg dGhlIFBNUyB0byBNUyBzdGVwIGxvb2tzIGxpa2UgaXQgaXMgZ2FpbmluZyB0cmFjdGlvbi4gIEkn bSBub3Qgc3VyZSBpdCBpcy4gIENlcnRhaW5seSwgQWthbWFpIHJlcHJlc2VudHMgYSBzaWduaWZp Y2FudCBhbW91bnQgb2YgU1NMIHRyYWZmaWMgb24gdGhlIEludGVybmV0LCBzbyB3ZSB3YW50IHRv IG1ha2Ugc3VyZSB3ZSBmdXR1cmUgcHJvb2Ygb3VyIGRlc2lnbnMuICBNeSBub3QgdGVsbGluZyB5 b3Ugb2YgaG93IHRoZSBpbnRlcm5hbHMgd29yayBzaG91bGQgbm90IGJlIGNvbnN0cnVlZCB0aGF0 IHdlJ3JlIG5vdCB0cnlpbmcgdG8gZ3VhcmQgYWdhaW5zdCB0aGlzIGFuZCBvdGhlciBwb3NzaWJs ZSBjaGFuZ2VzLiAgSXQgaXMgc2ltcGx5IHJlbGF5aW5nIHRvIHlvdSBhIHJlYWwgd29ybGQgZmFj dCB3aXRob3V0IGRpdnVsZ2luZyB3aGF0IEkgY2FuIG5vdCBkaXZ1bGdlLg0KDQpDaGFybGllIEdl cm8NClNlbmlvciBQcmluY2lwYWwgU3lzdGVtIFNvZnR3YXJlIEVuZ2luZWVyDQpUZWFtIExlYWQg RW5naW5lZXJpbmcgLSBBa2FtYWkgTGFicw0KNjE3LjQ0NC4zOTQwDQoNCk9uIEp1bCAzMCwgMjAx NCwgYXQgNDo1OSBQTSwgIk1pY2hhZWwgU3RKb2hucyIgPG1zakBudGhwZXJtdXRhdGlvbi5jb208 bWFpbHRvOm1zakBudGhwZXJtdXRhdGlvbi5jb20+PiB3cm90ZToNCg0KT24gNy8zMC8yMDE0IDEy OjI3IFBNLCBHZXJvLCBDaGFybGllIHdyb3RlOg0KSSBjYW4ndCBnbyBpbnRvIGRldGFpbHMgYXJv dW5kIGl0IGF0IHRoaXMgdGltZS4gIFN1ZmZpY2UgdG8gc2F5LCB3ZSBkZWZpbml0ZWx5IGRvIHJl bHkgb24gdGhlIHR3byBiZWluZyBzcGxpdC4NCkhpIENoYXJsaWUgLQ0KDQoNCklmIHNvbWVvbmUg c2FpZCAtICJ3ZSBkZXBlbmQgb24gdGhlIHBhY2tldCBmb3JtYXRzIHRvIGJlIHByZWRpY3RhYmxl Ig0KSSdkIHNheSB0aGV5J2QgaGF2ZSBhIGNhc2UgZm9yIHJlbGlhbmNlIGFuZCBiYWNrd2FyZHMg Y29tcGF0aWJpbGl0eS4NClNheWluZyB0aGF0IHlvdSBkaWQgc29tZXRoaW5nIHRoYXQgd2lsbCBi cmVhayB0aGF0IGlzIHRvdGFsbHkgYW5kDQpjb21wbGV0ZWx5IG9wYXF1ZSB0byB0aGUgb24tdGhl LXdpcmUgcHJvdG9jb2wgc3BlYyBhbmQgZXhwZWN0aW5nIHRoZQ0KcHJvdG9jb2wgc3BlYyBub3Qg dG8gY2hhbmdlIChhc3N1bWluZyBwcm9wZXIgb24tdGhlLXdpcmUgbmVnb3RpYXRpb24gdG8NCmRl c2NyaWJlIHNhaWQgY2hhbmdlcykgc2VlbXMgdG8gYmUgcHVzaGluZyB5b3VyIGx1Y2suDQoNClRo YXQgc2FpZCwgdGhlIG1vcmUgZGV0YWlscyB5b3UgY2FuIHNoYXJlLCB0aGUgYmV0dGVyIGNoYW5j ZSB3ZSBoYXZlIG9mDQpkb2luZyBzb21ldGhpbmcgdGhhdCB3b24ndCBhbm5veSB5b3UuICBGb3Ig ZXhhbXBsZSwgd291bGQgeW91ciBzeXN0ZW0NCmJyZWFrIGlmIHRoZSBtYXN0ZXIgc2VjcmV0IHdl cmUgbm8gbG9uZ2VyIDQ4IG9jdGV0cz8gIFdvdWxkIGl0IGJyZWFrIGlmDQp0aGUgUFJGIHdlcmUg bm90IGJhc2VkIG9uIFNIQTI1Nj8gIFdvdWxkIGl0IGJyZWFrIGlmIHRoZSBQUkYgd2VyZSBhIENN QUMNCnZzIGFuIEhNQUM/DQoNCkkgaGF2ZSBubyBpZGVhIHdoZXJlIHRoaXMgaWRlYSB3aWxsIGdv LiAgSXQgbWF5IGdvIG5vd2hlcmUsIGluIHdoaWNoDQpjYXNlIHlvdSdyZSBzYWZlIC0gZm9yIG5v dy4gIEl0IG1heSBnbyBpbnRvIHRoZSBwcm90b2NvbC4gIEkgdGhpbmsgaWYgSQ0Kd2VyZSBhdCBh a2FtYWksIEknZCBiZSBsb29raW5nIGF0IHdoeSB0aGlzIGNvdWxkIGJlIGFuIGlzc3VlLCBhbmQg aG93IHRvDQpyZW1lZGlhdGUgaXQgZXZlbiBpZiBpdCBkb2Vzbid0IG1ha2UgaXQgaW4uICBCdXQg dGhhdCdzIGp1c3QgbWUuDQoNCk1pa2UNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IE1pY2hhZWwgU3RKb2hucyBbbWFpbHRvOm1zakBudGhwZXJtdXRhdGlvbi5jb21d DQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMzAsIDIwMTQgMTE6NDYgQU0NClRvOiBHZXJvLCBDaGFy bGllOyB0bHNAaWV0Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVExT XSBQcmVtYXN0ZXIvTWFzdGVyIGNvbnZlbnRpb24NCg0KT24gNy8zMC8yMDE0IDExOjAyIEFNLCBH ZXJvLCBDaGFybGllIHdyb3RlOg0KV2UgaGF2ZSBhIG51bWJlciBvZiB0ZWNobm9sb2dpZXMgYXQg QWthbWFpIHRoYXQgdXRpbGl6ZSB0aGUgZmFjdCB0aGF0IHRoZSBQTVMgaXMgc3BsaXQgZnJvbSB0 aGUgTVMgYW5kIHRoYXQgTVMgaXMgcHJvZHVjZWQgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgcmFu ZG9tcy4gIEl0IGFsbG93cyB1cyB0byBkbyBzcGxpdHRpbmcgYmV0d2VlbiBtYWNoaW5lcyB0aGF0 IGhhdmUga2V5cyBhbmQgdGhvc2UgdGhhdCBkb24ndCAobWFjaGluZXMgaW4gc2FmZSBsb2NhbGVz IGFuZCB0aG9zZSB3aGljaCBhcmUgc2ltcGx5IHRlcm1pbmF0b3JzKS4gIEkgZG9uJ3QgdGhpbmsg d2UgY291bGQgdXNlIHRoZSBzYW1lIG1ldGhvZHMgd2UgdXNlIHRvZGF5IHdpdGhvdXQgdGhhdCBz dWIgc3RlcC4gIEl0IHdvdWxkIG1ha2UgaXQgdmVyeSBkaWZmaWN1bHQgZm9yIEFrYW1haSB0byBh ZG9wdCAxLjMuDQpTbyB5b3Ugc2VuZCB0aGUgbWFzdGVyIHNlY3JldCBmcm9tIHRoZSBoYW5kc2hh a2VyIG1hY2hpbmUgb3V0IHRvIHNldmVyYWwgb3RoZXIgbWFjaGluZXMgd2hpY2ggdGhlbiBkbyB3 aGF0IHdpdGggaXQ/ICBDb3VsZG4ndCB5b3Ugc2VuZCB0aGUgdHJhZmZpYyBrZXlzIGluc3RlYWQ/ DQoNCkknbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhlIGNvbnN0cmFpbnRzIHlvdSdyZSB3b3Jr aW5nIHVuZGVyLiBDb3VsZCB5b3UgZXhwYW5kIG9uIHRoYXQ/DQoNClRoYW5rcyAtIE1pa2UNCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWljaGFlbCBTdEpvaG5zIFttYWls dG86bXNqQG50aHBlcm11dGF0aW9uLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgSnVseSAzMCwgMjAx NCAxMDo1NyBBTQ0KVG86IHRsc0BpZXRmLm9yZzxtYWlsdG86dGxzQGlldGYub3JnPg0KU3ViamVj dDogW1RMU10gUHJlbWFzdGVyL01hc3RlciBjb252ZW50aW9uDQoNCkdpdmVuIHRoYXQgVExTMS4z IG9ubHkgZG9lcyBLZXlBZ3JlZW1lbnQsIGlzIHRoZXJlIHN0aWxsIGFueSByZWFzb24gZm9yIHRo ZSBwcmVtYXN0ZXIgLT4gbWFzdGVyX3NlY3JldCBkZXJpdmF0aW9uIHN0ZXA/ICBXZSBkbyAoS0Ep LT5wcmVtYXN0ZXINCmFuZCB0aGVuIHByZW1hc3RlciAtPiBtYXN0ZXIgYW5kIHRoZW4gbWFzdGVy LT4oc2Vzc2lvbiBrZXlzKS4gICBXZSBjb3VsZA0KcHJvYmFibHkgZG8gKEtBKS0+bWFzdGVyLT4o c2Vzc2lvbiBrZXlzKSB3aGVyZSB0aGUgbWFzdGVyIHNlY3JldCBpcyBub3cgdGhlIEtBIHNoYXJl ZCBzZWNyZXQgcmF0aGVyIHRoYW4gcHJlbWFzdGVyLg0KDQoxKSBJcyB0aGVyZSBhbnkgc2VjdXJp dHkgcmVhc29uIGZvciByZXRhaW5pbmcgdGhlIGV4dHJhIHN0ZXAgZ2l2ZW4gdGhlcmUgaXMgbm8g bG9uZ2VyIGEgS2V5VHJhbnNwb3J0IG1lY2hhbmlzbSBpbiBUTFMxLjM/DQoyKSBBcmUgdGhlcmUg b3RoZXIgKmdvb2QqIC0gbm9uLXNlY3VyaXR5IC0gcmVhc29ucyBmb3IgcmV0YWluaW5nIHRoZSBl eHRyYSBzdGVwPw0KDQpNaWtlDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnPG1haWx0bzpU TFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0K DQoNCg0KDQoNCg== --_000_BD06808028544EBAA96E1030CB7C1CFFakamaicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+U29ycnkg Zm9yIHRoZSBzZWNvbmQgbGF0ZSByZXNwb25zZS4gJm5ic3A7SGVjdGljIGRheS4gJm5ic3A7SGVy ZSdzIGEgZm9sbG93IHVwIGZyb20gdGhlIHByZXZpb3VzLjwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+TWlzc2VkIGFuc3dlcmluZyB5b3VyIG9yaWdpbmFsIHF1ZXN0aW9uczo8L2Rpdj48ZGl2Pldv dWxkIHlvdXIgc3lzdGVtJm5ic3A7YnJlYWsgaWYgdGhlIG1hc3RlciBzZWNyZXQgd2VyZSBubyBs b25nZXIgNDggb2N0ZXRzPyBOby48L2Rpdj48ZGl2PldvdWxkIGl0IGJyZWFrIGlmJm5ic3A7dGhl IFBSRiB3ZXJlIG5vdCBiYXNlZCBvbiBTSEEyNTY/ICZuYnNwO05vLjwvZGl2PjxkaXY+V291bGQg aXQgYnJlYWsgaWYgdGhlIFBSRiB3ZXJlIGEgQ01BQyZuYnNwO3ZzIGFuIEhNQUM/IE5vLjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+SW4gYWRkaXRpb24sIGFzIGxvbmcgYXMgVExTIDEuMyBrZWVw cyBzdGF0aWMgUlNBIGtleSBleGNoYW5nZSBhbmQgcmVuZWdvdGlhdGlvbiBvdXQgYXMgd2VsbCBh cyBvbmx5IHJlbW92aW5nIFBNUyB0byBNUyBpbiAxLjMgYW5kIGxhdGVyLCB3ZSBzaG91bGQgYmUg b2suICZuYnNwO0FzIHNvbWVvbmUgYWRlcHRseSBpbmZlcnJlZCBlYXJsaWVyLCB0aGlzIGlzIHdo ZXJlIHRoaW5ncyB3b3VsZCBnZXQgaGFpcnkgZm9yIHVzIGlmIGFueSBvZiB0aGVzZSBjb25zdHJh aW50cyBhcmUgdmlvbGF0ZWQuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5BZ2FpbiwgSSdtIG5v dCBzdXJlIHRoaXMgaGFzIHN0ZWFtIGJlaGluZCBpdCBvciBub3QgKG9ubHkgdGltZSB3aWxsIHRl bGwpIGJ1dCB3ZSBzaG91bGQgYmUgYWJsZSB0byB3b3JrIG91dCB0aGluZ3MgZ2l2ZW4gdGhvc2Ug Y29uc3RyYWludHMuPGJyPjxicj5SZWdhcmRzLDwvZGl2PjxkaXY+Q2hhcmxpZTwvZGl2PjxkaXY+ PGJyPk9uIEp1bCAzMCwgMjAxNCwgYXQgODo0NCBQTSwgIkdlcm8sIENoYXJsaWUiICZsdDs8YSBo cmVmPSJtYWlsdG86Y2dlcm9AYWthbWFpLmNvbSI+Y2dlcm9AYWthbWFpLmNvbTwvYT4mZ3Q7IHdy b3RlOjxicj48YnI+PC9kaXY+PGRpdj48bWV0YSBodHRwLWVxdWl2PSJjb250ZW50LXR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+PGRpdj5NaWNoYWVsLDwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+UmVzcGVjdGZ1bGx5LCB0aGVyZSBhcmUgdGhpbmdzIHRoYXQgd2UgY2Fu IGFuZCBjYW4gbm90IGRpdnVsZ2UuICZuYnNwO0kgd2lsbCBjb250aW51ZSB0byBtb25pdG9yIHRo aXMgcGF0aCBhbmQgd2lsbCB1cGRhdGUgYXMgbmVjZXNzYXJ5IGlmIHJlbW92YWwgb2YgdGhlIFBN UyB0byBNUyBzdGVwIGxvb2tzIGxpa2UgaXQgaXMgZ2FpbmluZyB0cmFjdGlvbi4gJm5ic3A7SSdt IG5vdCBzdXJlIGl0IGlzLiAmbmJzcDtDZXJ0YWlubHksIEFrYW1haSByZXByZXNlbnRzIGEgc2ln bmlmaWNhbnQgYW1vdW50IG9mIFNTTCB0cmFmZmljIG9uIHRoZSBJbnRlcm5ldCwgc28gd2Ugd2Fu dCB0byBtYWtlIHN1cmUgd2UgZnV0dXJlIHByb29mIG91ciBkZXNpZ25zLiAmbmJzcDtNeSBub3Qg dGVsbGluZyB5b3Ugb2YgaG93IHRoZSBpbnRlcm5hbHMgd29yayBzaG91bGQgbm90IGJlIGNvbnN0 cnVlZCB0aGF0IHdlJ3JlIG5vdCB0cnlpbmcgdG8gZ3VhcmQgYWdhaW5zdCB0aGlzIGFuZCBvdGhl ciBwb3NzaWJsZSBjaGFuZ2VzLiAmbmJzcDtJdCBpcyBzaW1wbHkgcmVsYXlpbmcgdG8geW91IGEg cmVhbCB3b3JsZCBmYWN0IHdpdGhvdXQgZGl2dWxnaW5nIHdoYXQgSSBjYW4gbm90IGRpdnVsZ2Uu PC9kaXY+PGRpdj48YnI+PGI+Q2hhcmxpZSBHZXJvPC9iPjxkaXY+U2VuaW9yIFByaW5jaXBhbCBT eXN0ZW0gU29mdHdhcmUgRW5naW5lZXI8L2Rpdj48ZGl2PlRlYW0gTGVhZCBFbmdpbmVlcmluZyAt IEFrYW1haSBMYWJzPC9kaXY+PGRpdj48L2Rpdj48ZGl2PjYxNy40NDQuMzk0MDwvZGl2PjwvZGl2 PjxkaXY+PGJyPk9uIEp1bCAzMCwgMjAxNCwgYXQgNDo1OSBQTSwgIk1pY2hhZWwgU3RKb2hucyIg Jmx0OzxhIGhyZWY9Im1haWx0bzptc2pAbnRocGVybXV0YXRpb24uY29tIj5tc2pAbnRocGVybXV0 YXRpb24uY29tPC9hPiZndDsgd3JvdGU6PGJyPjxicj48L2Rpdj48ZGl2PjxzcGFuPk9uIDcvMzAv MjAxNCAxMjoyNyBQTSwgR2VybywgQ2hhcmxpZSB3cm90ZTo8L3NwYW4+PGJyPjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxzcGFuPkkgY2FuJ3QgZ28gaW50byBkZXRhaWxzIGFyb3VuZCBpdCBhdCB0 aGlzIHRpbWUuICZuYnNwO1N1ZmZpY2UgdG8gc2F5LCB3ZSBkZWZpbml0ZWx5IGRvIHJlbHkgb24g dGhlIHR3byBiZWluZyBzcGxpdC48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48c3Bhbj5IaSBDaGFy bGllIC08L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj5J ZiBzb21lb25lIHNhaWQgLSAid2UgZGVwZW5kIG9uIHRoZSBwYWNrZXQgZm9ybWF0cyB0byBiZSBw cmVkaWN0YWJsZSIgPC9zcGFuPjxicj48c3Bhbj5JJ2Qgc2F5IHRoZXknZCBoYXZlIGEgY2FzZSBm b3IgcmVsaWFuY2UgYW5kIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5LiAmbmJzcDs8L3NwYW4+PGJy PjxzcGFuPlNheWluZyB0aGF0IHlvdSBkaWQgc29tZXRoaW5nIHRoYXQgd2lsbCBicmVhayB0aGF0 IGlzIHRvdGFsbHkgYW5kIDwvc3Bhbj48YnI+PHNwYW4+Y29tcGxldGVseSBvcGFxdWUgdG8gdGhl IG9uLXRoZS13aXJlIHByb3RvY29sIHNwZWMgYW5kIGV4cGVjdGluZyB0aGUgPC9zcGFuPjxicj48 c3Bhbj5wcm90b2NvbCBzcGVjIG5vdCB0byBjaGFuZ2UgKGFzc3VtaW5nIHByb3BlciBvbi10aGUt d2lyZSBuZWdvdGlhdGlvbiB0byA8L3NwYW4+PGJyPjxzcGFuPmRlc2NyaWJlIHNhaWQgY2hhbmdl cykgc2VlbXMgdG8gYmUgcHVzaGluZyB5b3VyIGx1Y2suPC9zcGFuPjxicj48c3Bhbj48L3NwYW4+ PGJyPjxzcGFuPlRoYXQgc2FpZCwgdGhlIG1vcmUgZGV0YWlscyB5b3UgY2FuIHNoYXJlLCB0aGUg YmV0dGVyIGNoYW5jZSB3ZSBoYXZlIG9mIDwvc3Bhbj48YnI+PHNwYW4+ZG9pbmcgc29tZXRoaW5n IHRoYXQgd29uJ3QgYW5ub3kgeW91LiAmbmJzcDtGb3IgZXhhbXBsZSwgd291bGQgeW91ciBzeXN0 ZW0gPC9zcGFuPjxicj48c3Bhbj5icmVhayBpZiB0aGUgbWFzdGVyIHNlY3JldCB3ZXJlIG5vIGxv bmdlciA0OCBvY3RldHM/ICZuYnNwO1dvdWxkIGl0IGJyZWFrIGlmIDwvc3Bhbj48YnI+PHNwYW4+ dGhlIFBSRiB3ZXJlIG5vdCBiYXNlZCBvbiBTSEEyNTY/ICZuYnNwO1dvdWxkIGl0IGJyZWFrIGlm IHRoZSBQUkYgd2VyZSBhIENNQUMgPC9zcGFuPjxicj48c3Bhbj52cyBhbiBITUFDPzwvc3Bhbj48 YnI+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj5JIGhhdmUgbm8gaWRlYSB3aGVyZSB0aGlzIGlkZWEg d2lsbCBnby4gJm5ic3A7SXQgbWF5IGdvIG5vd2hlcmUsIGluIHdoaWNoIDwvc3Bhbj48YnI+PHNw YW4+Y2FzZSB5b3UncmUgc2FmZSAtIGZvciBub3cuICZuYnNwO0l0IG1heSBnbyBpbnRvIHRoZSBw cm90b2NvbC4gJm5ic3A7SSB0aGluayBpZiBJIDwvc3Bhbj48YnI+PHNwYW4+d2VyZSBhdCBha2Ft YWksIEknZCBiZSBsb29raW5nIGF0IHdoeSB0aGlzIGNvdWxkIGJlIGFuIGlzc3VlLCBhbmQgaG93 IHRvIDwvc3Bhbj48YnI+PHNwYW4+cmVtZWRpYXRlIGl0IGV2ZW4gaWYgaXQgZG9lc24ndCBtYWtl IGl0IGluLiAmbmJzcDtCdXQgdGhhdCdzIGp1c3QgbWUuPC9zcGFuPjxicj48c3Bhbj48L3NwYW4+ PGJyPjxzcGFuPk1pa2U8L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxi cj48c3Bhbj48L3NwYW4+PGJyPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48 YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+PHNwYW4+RnJvbTogTWljaGFlbCBTdEpvaG5zIFs8YSBocmVmPSJtYWlsdG86bXNqQG50 aHBlcm11dGF0aW9uLmNvbSI+bWFpbHRvOm1zakBudGhwZXJtdXRhdGlvbi5jb208L2E+XTwvc3Bh bj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPlNlbnQ6IFdl ZG5lc2RheSwgSnVseSAzMCwgMjAxNCAxMTo0NiBBTTwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPlRvOiBHZXJvLCBDaGFybGllOyA8YSBocmVmPSJt YWlsdG86dGxzQGlldGYub3JnIj50bHNAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj48L2Jsb2NrcXVv dGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+U3ViamVjdDogUmU6IFtUTFNdIFByZW1h c3Rlci9NYXN0ZXIgY29udmVudGlvbjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxzcGFuPk9uIDcvMzAvMjAxNCAxMTowMiBBTSwgR2VybywgQ2hhcmxpZSB3cm90 ZTo8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5XZSBoYXZlIGEgbnVtYmVyIG9mIHRlY2hub2xvZ2llcyBh dCBBa2FtYWkgdGhhdCB1dGlsaXplIHRoZSBmYWN0IHRoYXQgdGhlIFBNUyBpcyBzcGxpdCBmcm9t IHRoZSBNUyBhbmQgdGhhdCBNUyBpcyBwcm9kdWNlZCBpbiBjb25qdW5jdGlvbiB3aXRoIHRoZSBy YW5kb21zLiAmbmJzcDtJdCBhbGxvd3MgdXMgdG8gZG8gc3BsaXR0aW5nIGJldHdlZW4gbWFjaGlu ZXMgdGhhdCBoYXZlIGtleXMgYW5kIHRob3NlIHRoYXQgZG9uJ3QgKG1hY2hpbmVzIGluIHNhZmUg bG9jYWxlcyBhbmQgdGhvc2Ugd2hpY2ggYXJlIHNpbXBseSB0ZXJtaW5hdG9ycykuICZuYnNwO0kg ZG9uJ3QgdGhpbmsgd2UgY291bGQgdXNlIHRoZSBzYW1lIG1ldGhvZHMgd2UgdXNlIHRvZGF5IHdp dGhvdXQgdGhhdCBzdWIgc3RlcC4gJm5ic3A7SXQgd291bGQgbWFrZSBpdCB2ZXJ5IGRpZmZpY3Vs dCBmb3IgQWthbWFpIHRvIGFkb3B0IDEuMy48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2Nr cXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+U28geW91IHNlbmQgdGhlIG1hc3Rl ciBzZWNyZXQgZnJvbSB0aGUgaGFuZHNoYWtlciBtYWNoaW5lIG91dCB0byBzZXZlcmFsIG90aGVy IG1hY2hpbmVzIHdoaWNoIHRoZW4gZG8gd2hhdCB3aXRoIGl0PyAmbmJzcDtDb3VsZG4ndCB5b3Ug c2VuZCB0aGUgdHJhZmZpYyBrZXlzIGluc3RlYWQ/PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+SSdtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB0aGUgY29u c3RyYWludHMgeW91J3JlIHdvcmtpbmcgdW5kZXIuIENvdWxkIHlvdSBleHBhbmQgb24gdGhhdD88 L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3Nw YW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5UaGFua3Mg LSBNaWtlPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNw YW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PHNwYW4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L3NwYW4+PGJy PjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+RnJvbTogTWljaGFlbCBTdEpvaG5zIFs8YSBocmVmPSJt YWlsdG86bXNqQG50aHBlcm11dGF0aW9uLmNvbSI+bWFpbHRvOm1zakBudGhwZXJtdXRhdGlvbi5j b208L2E+XTwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5TZW50OiBXZWRuZXNkYXks IEp1bHkgMzAsIDIwMTQgMTA6NTcgQU08L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVv dGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ VG86IDxhIGhyZWY9Im1haWx0bzp0bHNAaWV0Zi5vcmciPnRsc0BpZXRmLm9yZzwvYT48L3NwYW4+ PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+U3ViamVjdDogW1RMU10gUHJlbWFzdGVyL01hc3Rl ciBjb252ZW50aW9uPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+ PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5HaXZlbiB0aGF0IFRMUzEuMyBvbmx5IGRvZXMgS2V5QWdy ZWVtZW50LCBpcyB0aGVyZSBzdGlsbCBhbnkgcmVhc29uIGZvciB0aGUgcHJlbWFzdGVyIC0mZ3Q7 IG1hc3Rlcl9zZWNyZXQgZGVyaXZhdGlvbiBzdGVwPyAmbmJzcDtXZSBkbyAoS0EpLSZndDtwcmVt YXN0ZXI8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+YW5kIHRoZW4gcHJlbWFzdGVy IC0mZ3Q7IG1hc3RlciBhbmQgdGhlbiBtYXN0ZXItJmd0OyhzZXNzaW9uIGtleXMpLiAmbmJzcDsm bmJzcDtXZSBjb3VsZDwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5wcm9iYWJseSBk byAoS0EpLSZndDttYXN0ZXItJmd0OyhzZXNzaW9uIGtleXMpIHdoZXJlIHRoZSBtYXN0ZXIgc2Vj cmV0IGlzIG5vdyB0aGUgS0Egc2hhcmVkIHNlY3JldCByYXRoZXIgdGhhbiBwcmVtYXN0ZXIuPC9z cGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwv YmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij48c3Bhbj4xKSBJcyB0aGVyZSBhbnkgc2VjdXJpdHkgcmVhc29uIGZvciByZXRhaW5pbmcgdGhl IGV4dHJhIHN0ZXAgZ2l2ZW4gdGhlcmUgaXMgbm8gbG9uZ2VyIGEgS2V5VHJhbnNwb3J0IG1lY2hh bmlzbSBpbiBUTFMxLjM/PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjIpIEFyZSB0 aGVyZSBvdGhlciAqZ29vZCogLSBub24tc2VjdXJpdHkgLSByZWFzb25zIGZvciByZXRhaW5pbmcg dGhlIGV4dHJhIHN0ZXA/PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48 YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5NaWtlPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9i bG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPjwvYmxv Y2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj48L2Js b2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxzcGFuPlRMUyBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPjwvYmxvY2txdW90 ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+PHNwYW4+PGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGlldGYub3JnPC9h Pjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJj aXRlIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90bHM8L2E+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bh bj48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48L2Js b2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2Nr cXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVv dGU+PHNwYW4+PC9zcGFuPjxicj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_BD06808028544EBAA96E1030CB7C1CFFakamaicom_-- From nobody Wed Jul 30 19:51:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935C11A0451 for ; Wed, 30 Jul 2014 19:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O_Zq3pCpzpM7 for ; Wed, 30 Jul 2014 19:51:25 -0700 (PDT) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F25C1A01EB for ; Wed, 30 Jul 2014 19:51:25 -0700 (PDT) Received: by mail-yh0-f48.google.com with SMTP id i57so1283574yha.35 for ; Wed, 30 Jul 2014 19:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HZDNsNQWoq/UqwGHCcvjLDBARNlOguv12QmhJe6zA5k=; b=t9/3YR48VQVkr9WJDsGHus2scEQ16igZJW+pfpvjdASNxacwdcZd7HyvYQ1qhQUjCz vgNdGOdHNBTFolF5etIWrT8OZ81OQ6ViXj00ZQDLv/Iy1vJafplsvx4ETxovGcYeh4Dt /RMxxF5SQgts/eP+zaGiZoT5NVWbSMQnhqLHa9BfOCRFyofT0sABvB1DX3y8cCe2MI3E AAJeiQQRAgbIQXfDiO44vRlBnfRh8wzmg4xqaPDF4VA3PPCzgB/Eec+Y/cEJvLvIZCsy bf7sdhJ/omdVQX/SOU2yi5xm18+ZHiJmM2flbvByC08M4Mq4ROPj7iJxGxOz9tO9gNPG kUEg== MIME-Version: 1.0 X-Received: by 10.236.79.230 with SMTP id i66mr1711441yhe.136.1406775084973; Wed, 30 Jul 2014 19:51:24 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Wed, 30 Jul 2014 19:51:24 -0700 (PDT) In-Reply-To: <53D907B0.3000006@nthpermutation.com> References: <53D907B0.3000006@nthpermutation.com> Date: Wed, 30 Jul 2014 19:51:24 -0700 Message-ID: From: Watson Ladd To: Michael StJohns Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4CR_pldkXOPyz2ttyz9F_GjPiIE Cc: "tls@ietf.org" Subject: Re: [TLS] Premaster/Master convention X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Jul 2014 02:51:27 -0000 On Wed, Jul 30, 2014 at 7:56 AM, Michael StJohns wrote: > Given that TLS1.3 only does KeyAgreement, is there still any reason for the > premaster -> master_secret derivation step? We do (KA)->premaster and then > premaster -> master and then master->(session keys). We could probably do > (KA)->master->(session keys) where the master secret is now the KA shared > secret rather than premaster. > > 1) Is there any security reason for retaining the extra step given there is > no longer a KeyTransport mechanism in TLS1.3? > 2) Are there other *good* - non-security - reasons for retaining the extra > step? Ideally the handshake would simply supply key material to a transport protocol, and meet standard security conditions. (some CK variant, and I've not included renegotiation). To do this the premaster->master step is fine, but the Finished message needs to be changed. (Yes, miTLS exists. It has to do all sort of nonstandard assumptions to work). Sincerely, Watson Ladd > > Mike > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Jul 31 08:31:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5FC1A00D7; Thu, 31 Jul 2014 08:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -113.902 X-Spam-Level: X-Spam-Status: No, score=-113.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gl4TNWuO7l0L; Thu, 31 Jul 2014 08:30:55 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A18651A00AB; Thu, 31 Jul 2014 08:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2511; q=dns/txt; s=iport; t=1406820654; x=1408030254; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7Mx8Mf/Q4t4V3KcaHhJ6/ppgjt39tjh0Wsg5E5tu9nk=; b=Rke4XeqSYHBHAqj+iiDU038jJhMwoTWIWhK4+MgJ+Worzaa1vzbdGP2H wEo/QOUHPLbK1oPr+ND+sE7/Pn/UB4L1rXYViMLGPORIMXHYmvBcfy7N7 IRoBPaM3rCK8/RugzGHhb/3uHM4t0PH6Yqb66qs9azuCZSP61/GKOTUY3 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAOlf2lOtJA2L/2dsb2JhbABagw5SVwTLL4dJAYEHFneEAwEBAQECASdSBQsCAQgYLjIlAgQOBYg6CA2/dxeOewEBHDMCBYMvgRsFm2SBUpMBg0lsAYELOQ X-IronPort-AV: E=Sophos;i="5.01,772,1400025600"; d="scan'208";a="344186002" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-6.cisco.com with ESMTP; 31 Jul 2014 15:30:53 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s6VFUreg013865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 15:30:53 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.120]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Thu, 31 Jul 2014 10:30:53 -0500 From: "Cullen Jennings (fluffy)" To: "mrex@sap.com" Thread-Topic: [tram] [TLS] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00 Thread-Index: AQHPpp82fjgNGTILOE6Hla7Sj7WHspuuY6YAgAxLyoA= Date: Thu, 31 Jul 2014 15:30:52 +0000 Message-ID: References: <20140723194438.EC4C71ADB9@ld9781.wdf.sap.corp> In-Reply-To: <20140723194438.EC4C71ADB9@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.167] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/23BUai3MOuqC3LhhxOckraFA4zk Cc: "tls@ietf.org" , "avt@ietf.org" , "tram@ietf.org" Subject: Re: [TLS] [tram] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 15:30:57 -0000 On Jul 23, 2014, at 12:44 PM, Martin Rex wrote: > Cullen Jennings (fluffy) wrote: >>=20 >> We should make a new IANA registry that keeps track of for each value >> of the first byte, which protocol it is allocated to. I would suggest >> that it require "Standards Action? to allocate a new code point to a >> protocol but of course one allocated to that protocol, the protocol >> would manager it within it?s existing IANA registry for that protocol >> with that protocols existing rules.=20 >>=20 >> The advantage of this is we can allocate the points as needed instead >> of guessing if TLS or STUN or some new protocol will need a given >> number points. There is no implementation problem for the demux because >> things that use the new code points would know how to demux them.=20 >=20 > I'm slightly confused. Is that first byte in Figure 3: >=20 > http://tools.ietf.org/html/draft-petithuguenin-avtcore-rfc5764-mux-fixes-= 00#page-6 >=20 > +----------------+ > | 127 < B < 192 -+--> forward to RTP > | | > packet --> | 19 < B < 64 -+--> forward to DTLS > | | > | B < 2 -+--> forward to STUN > +----------------+ >=20 > Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. > Here the field B denotes the leading byte of the packet. >=20 > the actual "ContentType" byte of the (D)TLS record protocol, > which happens to currently be visible on the outside of the (D)TLS > record protocol with a fairly small set of values: >=20 > enum { > change_cipher_spec(20), alert(21), handshake(22), > application_data(23), (255) > } ContentType; >=20 >=20 > There has been a proposal to hide the ContentType for TLSv1.3 > and break lots of existing software that relies on being able > to parse TLS records: >=20 > https://www.ietf.org/mail-archive/web/tls/current/msg13055.html >=20 >=20 > Will rfc5764 have to be added to the list of things that would break > by such a (needless) TLSv1.3 change? >=20 my understanding of the proposal would be they would use and existing recor= d or create a new code point but that code point would be in the 19 to 64 r= ange so I don=92t think RFC 5764 would be broken by the proposal. The prop= osal might still be sort of lame but I don=92t think it breaks this demux.= =20 From nobody Thu Jul 31 09:23:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40D21A0194 for ; Thu, 31 Jul 2014 09:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFf2Jnh1jvVS for ; Thu, 31 Jul 2014 09:23:38 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4F41A0180 for ; Thu, 31 Jul 2014 09:23:37 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s6VGMmqM016462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Jul 2014 18:22:48 +0200 (MEST) In-Reply-To: <201407281624.10986.davemgarrett@gmail.com> To: Dave Garrett Date: Thu, 31 Jul 2014 18:22:47 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140731162247.6D6301ADDA@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uRjTRatq-ivUGDZaftmF4cGqnzI Cc: tls@ietf.org Subject: Re: [TLS] PRF in 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 16:23:40 -0000 Dave Garrett wrote: > > https://github.com/tlswg/tls13-spec/issues/26 > > Issue #26 notes complication with the usage of a negotiable PRF. The > current suggestion mentioned was to consider removing PRF > negotiation in favor of SHA-256, calling it "good enough" until the next > protocol version. The PRF was already negotiable (i.e. depending on the cipher suite) in TLSv1.0. While this isn't spelled out in the TLSv1.0 spec, it is clear from the TLS WG discussions about TLSv1.0 and there is nothing in the TLSv1.0 spec that precludes it. There are implementations in active use with GOST-based TLS cipher suites, which replace the TLS PRF (and the hashes used within), and this is used with TLSv1.0. The I-D describing the cipher suites has never been completed, though: http://tools.ietf.org/html/draft-chudov-cryptopro-cptls-04 and there also exist no code point assignments in the TLS registry, so using this with TLSv1.2 is not possible (only TLSv1.0 and TLSv1.1). The GOST signature algorithms described in that I-D have also been superseded by more recent ones, but there currently is no description for those either. Our TLS (v1.0) implementation contains a plugin interface which can replace the TLS PRF, just like Microsoft Windows XP(!) has such an interface. AFAIK, OpenSSL 1.0.0 also had support for GOST ciphersuites from the above draft. -Martin From nobody Thu Jul 31 10:28:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11AAC1A0310 for ; Thu, 31 Jul 2014 10:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7KowhYZpMWt for ; Thu, 31 Jul 2014 10:28:21 -0700 (PDT) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12371A0099 for ; Thu, 31 Jul 2014 10:28:21 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id rp18so4181478iec.33 for ; Thu, 31 Jul 2014 10:28:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=ezub7ns19AwxdmVDbMxiYQP+sjfGNtm+TzqOBi7eZtI=; b=CRxVqJzoaSlHDC4KmDf/hmjLZBO9+FHZRlhrcnIYTOL14dlqCqpOFGSVtOWudTNR7Z JuGyJ3azvnWAwLddcUV4AQzeDuY8eMmD7KOg13mCntN/5eAsyTEsvujRhUa3fU37J6W4 JkVnX9JybkFaYoCfM/mHbits/WSFfgu9R+xMPRA5RUm9pJuf58CcziliWGPo4GhO3vSw G0PEmBFb7tKZB4xQIU70bA5jU2uK/sF8+8d0bIt3F0OjyjSr0xBfv5V8PLniBywimkx9 l+smhLUnjj4iRB0AqOEWPsZPLep1OgbiIrkH6Zofq0kT43hzHlOT8Kyv+dZ7EFhuqk/x SjSw== X-Gm-Message-State: ALoCoQkl1MtHobKlu3rPHScgwAgaSOKY0H6TcDF93wOtoemBu17tL80LJvHrTrTpXWiQiIwCmtPM X-Received: by 10.50.33.100 with SMTP id q4mr75248igi.8.1406827700907; Thu, 31 Jul 2014 10:28:20 -0700 (PDT) Received: from [10.90.197.183] (edge-gw-rwc.silverspringnet.com. [74.121.22.10]) by mx.google.com with ESMTPSA id e1sm13217345igx.21.2014.07.31.10.28.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jul 2014 10:28:20 -0700 (PDT) Message-ID: <53DA7CB6.6030400@nthpermutation.com> Date: Thu, 31 Jul 2014 13:28:22 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Gero, Charlie" References: <53D907B0.3000006@nthpermutation.com> <53D91332.9070103@nthpermutation.com> <53D95C7D.9060408@nthpermutation.com> <6ECEF2D7-A1AE-4AC4-90C5-62A38075B0BF@akamai.com> In-Reply-To: <6ECEF2D7-A1AE-4AC4-90C5-62A38075B0BF@akamai.com> Content-Type: multipart/alternative; boundary="------------000101050903040202010502" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fr1D3fBPmGyAm3lBg5m85j5ocAQ Cc: "tls@ietf.org" Subject: Re: [TLS] Premaster/Master convention X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Jul 2014 17:28:24 -0000 This is a multi-part message in MIME format. --------------000101050903040202010502 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 7/30/2014 8:44 PM, Gero, Charlie wrote: > Michael, > > Respectfully, there are things that we can and can not divulge. I > will continue to monitor this path and will update as necessary if > removal of the PMS to MS step looks like it is gaining traction. I'm > not sure it is. Certainly, Akamai represents a significant amount of > SSL traffic on the Internet, so we want to make sure we future proof > our designs. My not telling you of how the internals work should not > be construed that we're not trying to guard against this and other > possible changes. It is simply relaying to you a real world fact > without divulging what I can not divulge. Hi Charlie - No problems. I understand the painful master that is NDA. That said, pretend for a minute that all that's left of TLS1.2 in TLS1.3 is the version negotiation and basic record format. Think about the gotcha's that might pop up with your stuff the longer the TLS WG twiddles with the protocol. Figure out if you can tell us anything about them. If you can't - you can't. Unfortunately, the corollary of "if you can't explain what's wrong, we can't do anything to fix it" probably applies. Mike > > *Charlie Gero* > Senior Principal System Software Engineer > Team Lead Engineering - Akamai Labs > 617.444.3940 > > On Jul 30, 2014, at 4:59 PM, "Michael StJohns" > wrote: > > On 7/30/2014 12:27 PM, Gero, Charlie wrote: >> I can't go into details around it at this time. Suffice to say, we >> definitely do rely on the two being split. > Hi Charlie - > > > If someone said - "we depend on the packet formats to be predictable" > I'd say they'd have a case for reliance and backwards compatibility. > Saying that you did something that will break that is totally and > completely opaque to the on-the-wire protocol spec and expecting the > protocol spec not to change (assuming proper on-the-wire negotiation to > describe said changes) seems to be pushing your luck. > > That said, the more details you can share, the better chance we have of > doing something that won't annoy you. For example, would your system > break if the master secret were no longer 48 octets? Would it break if > the PRF were not based on SHA256? Would it break if the PRF were a CMAC > vs an HMAC? > > I have no idea where this idea will go. It may go nowhere, in which > case you're safe - for now. It may go into the protocol. I think if I > were at akamai, I'd be looking at why this could be an issue, and how to > remediate it even if it doesn't make it in. But that's just me. > > Mike > > > >> >> -----Original Message----- >> From: Michael StJohns [mailto:msj@nthpermutation.com] >> Sent: Wednesday, July 30, 2014 11:46 AM >> To: Gero, Charlie; tls@ietf.org >> Subject: Re: [TLS] Premaster/Master convention >> >> On 7/30/2014 11:02 AM, Gero, Charlie wrote: >>> We have a number of technologies at Akamai that utilize the fact >>> that the PMS is split from the MS and that MS is produced in >>> conjunction with the randoms. It allows us to do splitting between >>> machines that have keys and those that don't (machines in safe >>> locales and those which are simply terminators). I don't think we >>> could use the same methods we use today without that sub step. It >>> would make it very difficult for Akamai to adopt 1.3. >> So you send the master secret from the handshaker machine out to >> several other machines which then do what with it? Couldn't you send >> the traffic keys instead? >> >> I'm not sure I understand the constraints you're working under. Could >> you expand on that? >> >> Thanks - Mike >> >> >>> -----Original Message----- >>> From: Michael StJohns [mailto:msj@nthpermutation.com] >>> Sent: Wednesday, July 30, 2014 10:57 AM >>> To: tls@ietf.org >>> Subject: [TLS] Premaster/Master convention >>> >>> Given that TLS1.3 only does KeyAgreement, is there still any reason >>> for the premaster -> master_secret derivation step? We do >>> (KA)->premaster >>> and then premaster -> master and then master->(session keys). We could >>> probably do (KA)->master->(session keys) where the master secret is >>> now the KA shared secret rather than premaster. >>> >>> 1) Is there any security reason for retaining the extra step given >>> there is no longer a KeyTransport mechanism in TLS1.3? >>> 2) Are there other *good* - non-security - reasons for retaining the >>> extra step? >>> >>> Mike >>> >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> >> > --------------000101050903040202010502 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 7/30/2014 8:44 PM, Gero, Charlie wrote:
Michael,

Respectfully, there are things that we can and can not divulge.  I will continue to monitor this path and will update as necessary if removal of the PMS to MS step looks like it is gaining traction.  I'm not sure it is.  Certainly, Akamai represents a significant amount of SSL traffic on the Internet, so we want to make sure we future proof our designs.  My not telling you of how the internals work should not be construed that we're not trying to guard against this and other possible changes.  It is simply relaying to you a real world fact without divulging what I can not divulge.

Hi Charlie -

No problems.  I understand the painful master that is NDA.    That said, pretend for a minute that all that's left of TLS1.2 in TLS1.3 is the version negotiation and basic record format.  Think about the gotcha's that might pop up with your stuff the longer the TLS WG twiddles with the protocol.  Figure out if you can tell us anything about them.

If you can't - you can't.   Unfortunately, the corollary of  "if you can't explain what's wrong, we can't do anything to fix it" probably applies.

Mike






Charlie Gero
Senior Principal System Software Engineer
Team Lead Engineering - Akamai Labs
617.444.3940

On Jul 30, 2014, at 4:59 PM, "Michael StJohns" <msj@nthpermutation.com> wrote:

On 7/30/2014 12:27 PM, Gero, Charlie wrote:
I can't go into details around it at this time.  Suffice to say, we definitely do rely on the two being split.
Hi Charlie -


If someone said - "we depend on the packet formats to be predictable"
I'd say they'd have a case for reliance and backwards compatibility.  
Saying that you did something that will break that is totally and
completely opaque to the on-the-wire protocol spec and expecting the
protocol spec not to change (assuming proper on-the-wire negotiation to
describe said changes) seems to be pushing your luck.

That said, the more details you can share, the better chance we have of
doing something that won't annoy you.  For example, would your system
break if the master secret were no longer 48 octets?  Would it break if
the PRF were not based on SHA256?  Would it break if the PRF were a CMAC
vs an HMAC?

I have no idea where this idea will go.  It may go nowhere, in which
case you're safe - for now.  It may go into the protocol.  I think if I
were at akamai, I'd be looking at why this could be an issue, and how to
remediate it even if it doesn't make it in.  But that's just me.

Mike




-----Original Message-----
From: Michael StJohns [mailto:msj@nthpermutation.com]
Sent: Wednesday, July 30, 2014 11:46 AM
To: Gero, Charlie; tls@ietf.org
Subject: Re: [TLS] Premaster/Master convention

On 7/30/2014 11:02 AM, Gero, Charlie wrote:
We have a number of technologies at Akamai that utilize the fact that the PMS is split from the MS and that MS is produced in conjunction with the randoms.  It allows us to do splitting between machines that have keys and those that don't (machines in safe locales and those which are simply terminators).  I don't think we could use the same methods we use today without that sub step.  It would make it very difficult for Akamai to adopt 1.3.
So you send the master secret from the handshaker machine out to several other machines which then do what with it?  Couldn't you send the traffic keys instead?

I'm not sure I understand the constraints you're working under. Could you expand on that?

Thanks - Mike


-----Original Message-----
From: Michael StJohns [mailto:msj@nthpermutation.com]
Sent: Wednesday, July 30, 2014 10:57 AM
To: tls@ietf.org
Subject: [TLS] Premaster/Master convention

Given that TLS1.3 only does KeyAgreement, is there still any reason for the premaster -> master_secret derivation step?  We do (KA)->premaster
and then premaster -> master and then master->(session keys).   We could
probably do (KA)->master->(session keys) where the master secret is now the KA shared secret rather than premaster.

1) Is there any security reason for retaining the extra step given there is no longer a KeyTransport mechanism in TLS1.3?
2) Are there other *good* - non-security - reasons for retaining the extra step?

Mike



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






--------------000101050903040202010502-- From nobody Thu Jul 31 10:34:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7491B293C for ; Thu, 31 Jul 2014 10:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxdUc-36iYQT for ; Thu, 31 Jul 2014 10:34:32 -0700 (PDT) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C67E81B2948 for ; Thu, 31 Jul 2014 10:34:32 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id g10so3881250pdj.12 for ; Thu, 31 Jul 2014 10:34:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=T9z9KWjlu/XVYaSL769bK1JWTbj5Ue5/TA659KzBF8Y=; b=VBY5Fxy0ZAEdkBjmpCTJl4+5GH1/HuKPtS36HKtEWcRgmi6h7IdwlFxeM+YQbh6jOl 2akk+Vs/GgwEltglboUTJKJc4ddKo+UV3vGUiXvpWzMiBHLjhelDVurWTT2o/zECDa9K Y26Ciw7gXWbm7ToancLHxBnaWlm/4NK2Ps5FwUnRTNEDjYw46RK+Sn0x5lnMT3eLzmaT tz8kjTrOvbiQF+D9xyz6iD7Rkzd3jic6pPNr+DEZ4oQCwVxGF2FgsTnKlMsZtZ4uG9u1 ZHANdHl9x++HfsWQBmkq1yQu/p2XDNcFxZFAw4S6WpzOl8cFEUJTsPpxMgkKADO4fgvn 5X0w== X-Gm-Message-State: ALoCoQn2jCcOnH+wP8/1t95OHnjDszBkAB3t3qOsziF0BMTJW+oftLAUqTvqpBR1EChPer/ko8sa X-Received: by 10.66.100.200 with SMTP id fa8mr6123957pab.23.1406828072362; Thu, 31 Jul 2014 10:34:32 -0700 (PDT) Received: from [10.90.197.183] (soi.silverspringnet.com. [74.121.22.10]) by mx.google.com with ESMTPSA id h17sm7040245pdj.52.2014.07.31.10.34.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jul 2014 10:34:31 -0700 (PDT) Message-ID: <53DA7E2A.50905@nthpermutation.com> Date: Thu, 31 Jul 2014 13:34:34 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Gero, Charlie" References: <53D907B0.3000006@nthpermutation.com> <53D91332.9070103@nthpermutation.com> <53D95C7D.9060408@nthpermutation.com> <6ECEF2D7-A1AE-4AC4-90C5-62A38075B0BF@akamai.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030406030401050901070608" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iG8LVBr2maKgMATMs-Q1r-B5s4E Cc: "tls@ietf.org" Subject: Re: [TLS] Premaster/Master convention X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 31 Jul 2014 17:34:39 -0000 This is a multi-part message in MIME format. --------------030406030401050901070608 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 7/30/2014 9:18 PM, Gero, Charlie wrote: > Sorry for the second late response. Hectic day. Here's a follow up > from the previous. > No probs > > In addition, as long as TLS 1.3 keeps static RSA key exchange and > renegotiation out as well as only removing PMS to MS in 1.3 and later, > we should be ok. As someone adeptly inferred earlier, this is where > things would get hairy for us if any of these constraints are violated. > > I couldn't parse this very well - too many missing commas. Did you mean?: "In addition, as long as TLS1.3 only removes static RSA key exchange and renegotiation we should be ok" - and - "If removing the pre-master secret only applies to TLS1.3 and later we should be ok" I thought removing the pre-master regardless of rev was the issue? Mike --------------030406030401050901070608 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 7/30/2014 9:18 PM, Gero, Charlie wrote:
Sorry for the second late response.  Hectic day.  Here's a follow up from the previous.

No probs

In addition, as long as TLS 1.3 keeps static RSA key exchange and renegotiation out as well as only removing PMS to MS in 1.3 and later, we should be ok.  As someone adeptly inferred earlier, this is where things would get hairy for us if any of these constraints are violated.



I couldn't parse this very well - too many missing commas.  Did you mean?:

"In addition, as long as TLS1.3 only removes static RSA key exchange and renegotiation we should be ok"

- and -

"If removing the pre-master secret only applies to TLS1.3 and later we should be ok"

I thought removing the pre-master regardless of rev was the issue?

Mike

--------------030406030401050901070608-- From nobody Thu Jul 31 18:46:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF871A0318 for ; Thu, 31 Jul 2014 18:46:28 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVvsP5a0XTjF for ; Thu, 31 Jul 2014 18:46:26 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4C09C1A02FC for ; Thu, 31 Jul 2014 18:46:25 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DE6D61657B7; Fri, 1 Aug 2014 01:46:24 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id D3C1E1657B5; Fri, 1 Aug 2014 01:46:24 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id B01771E051; Fri, 1 Aug 2014 01:46:24 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Thu, 31 Jul 2014 21:46:23 -0400 From: "Gero, Charlie" To: Michael StJohns Date: Thu, 31 Jul 2014 21:46:25 -0400 Thread-Topic: [TLS] Premaster/Master convention Thread-Index: Ac+tKmaLKOUYao3pQRaS/XVKE9b3Wg== Message-ID: References: <53D907B0.3000006@nthpermutation.com> <53D91332.9070103@nthpermutation.com> <53D95C7D.9060408@nthpermutation.com> <6ECEF2D7-A1AE-4AC4-90C5-62A38075B0BF@akamai.com> <53DA7E2A.50905@nthpermutation.com> In-Reply-To: <53DA7E2A.50905@nthpermutation.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C1079511D7A545D0A552529FB9D306D5akamaicom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OeRJF5G6C7VW9zIN91ptv1B_RMU Cc: "tls@ietf.org" Subject: Re: [TLS] Premaster/Master convention X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Aug 2014 01:46:28 -0000 --_000_C1079511D7A545D0A552529FB9D306D5akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnkgZm9yIHRoZSBsYWNrIG9mIGNsYXJpdHkuICBXaGF0IEkgbWVhbiBpcywgSSB0aGluayBB a2FtYWkgd2lsbCBiZSBhYmxlIHRvIGtlZXAgb3VyIGN1cnJlbnQgc3lzdGVtIHdvcmtpbmcgZXZl biB3aXRoIFBNUyB0byBNUyByZW1vdmVkIGdpdmVuOg0KDQoxLiBSZW1vdmFsIG9mIHRoZSBQTVMg dG8gTVMgc3RlcCBpcyBkb25lIGluIDEuMyBhbmQgZm9yd2FyZCBvbmx5ICh0aGlzIHNlZW1zIG9i dmlvdXMsIGJ1dCBpbiB0aGUgYXJndW1lbnQgb2YgZXhwbGljaXRuZXNzLi4uKQ0KDQpBTkQNCg0K Mi4gVExTIDEuMyByZW1vdmVzIHN0YXRpYyBSU0Ega2V5IGV4Y2hhbmdlLg0KDQpBTkQNCg0KMy4g VExTIDEuMyByZW1vdmVzIHJlbmVnb3RpYXRpb24uDQoNCklmIGFueSBvZiB0aG9zZSBjb25zdHJh aW50cyBicmVhaywgb3VyIGN1cnJlbnQgYXJjaGl0ZWN0dXJlIHdpbGwgcmVxdWlyZSBzaWduaWZp Y2FudCBjaGFuZ2UuDQoNClJlZ2FyZHMsDQpDaGFybGllIEdlcm8NClNlbmlvciBQcmluY2lwYWwg U3lzdGVtIFNvZnR3YXJlIEVuZ2luZWVyDQpUZWFtIExlYWQgRW5naW5lZXJpbmcgLSBBa2FtYWkg TGFicw0KNjE3LjQ0NC4zOTQwDQoNCk9uIEp1bCAzMSwgMjAxNCwgYXQgMTozNCBQTSwgIk1pY2hh ZWwgU3RKb2hucyIgPG1zakBudGhwZXJtdXRhdGlvbi5jb208bWFpbHRvOm1zakBudGhwZXJtdXRh dGlvbi5jb20+PiB3cm90ZToNCg0KT24gNy8zMC8yMDE0IDk6MTggUE0sIEdlcm8sIENoYXJsaWUg d3JvdGU6DQpTb3JyeSBmb3IgdGhlIHNlY29uZCBsYXRlIHJlc3BvbnNlLiAgSGVjdGljIGRheS4g IEhlcmUncyBhIGZvbGxvdyB1cCBmcm9tIHRoZSBwcmV2aW91cy4NCg0KTm8gcHJvYnMNCg0KSW4g YWRkaXRpb24sIGFzIGxvbmcgYXMgVExTIDEuMyBrZWVwcyBzdGF0aWMgUlNBIGtleSBleGNoYW5n ZSBhbmQgcmVuZWdvdGlhdGlvbiBvdXQgYXMgd2VsbCBhcyBvbmx5IHJlbW92aW5nIFBNUyB0byBN UyBpbiAxLjMgYW5kIGxhdGVyLCB3ZSBzaG91bGQgYmUgb2suICBBcyBzb21lb25lIGFkZXB0bHkg aW5mZXJyZWQgZWFybGllciwgdGhpcyBpcyB3aGVyZSB0aGluZ3Mgd291bGQgZ2V0IGhhaXJ5IGZv ciB1cyBpZiBhbnkgb2YgdGhlc2UgY29uc3RyYWludHMgYXJlIHZpb2xhdGVkLg0KDQoNCg0KSSBj b3VsZG4ndCBwYXJzZSB0aGlzIHZlcnkgd2VsbCAtIHRvbyBtYW55IG1pc3NpbmcgY29tbWFzLiAg RGlkIHlvdSBtZWFuPzoNCg0KIkluIGFkZGl0aW9uLCBhcyBsb25nIGFzIFRMUzEuMyBvbmx5IHJl bW92ZXMgc3RhdGljIFJTQSBrZXkgZXhjaGFuZ2UgYW5kIHJlbmVnb3RpYXRpb24gd2Ugc2hvdWxk IGJlIG9rIg0KDQotIGFuZCAtDQoNCiJJZiByZW1vdmluZyB0aGUgcHJlLW1hc3RlciBzZWNyZXQg b25seSBhcHBsaWVzIHRvIFRMUzEuMyBhbmQgbGF0ZXIgd2Ugc2hvdWxkIGJlIG9rIg0KDQpJIHRo b3VnaHQgcmVtb3ZpbmcgdGhlIHByZS1tYXN0ZXIgcmVnYXJkbGVzcyBvZiByZXYgd2FzIHRoZSBp c3N1ZT8NCg0KTWlrZQ0KDQo= --_000_C1079511D7A545D0A552529FB9D306D5akamaicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+U29ycnkg Zm9yIHRoZSBsYWNrIG9mIGNsYXJpdHkuICZuYnNwO1doYXQgSSBtZWFuIGlzLCBJIHRoaW5rIEFr YW1haSB3aWxsIGJlIGFibGUgdG8ga2VlcCBvdXIgY3VycmVudCBzeXN0ZW0gd29ya2luZyBldmVu IHdpdGggUE1TIHRvIE1TIHJlbW92ZWQgZ2l2ZW46PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4x LiBSZW1vdmFsIG9mIHRoZSBQTVMgdG8gTVMgc3RlcCBpcyBkb25lIGluIDEuMyBhbmQgZm9yd2Fy ZCBvbmx5ICh0aGlzIHNlZW1zIG9idmlvdXMsIGJ1dCBpbiB0aGUgYXJndW1lbnQgb2YgZXhwbGlj aXRuZXNzLi4uKTwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+QU5EPC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj4yLiBUTFMgMS4zIHJlbW92ZXMgc3RhdGljIFJTQSBrZXkgZXhjaGFuZ2UuPC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj5BTkQ8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjMuIFRMUyAx LjMgcmVtb3ZlcyByZW5lZ290aWF0aW9uLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SWYgYW55 IG9mIHRob3NlIGNvbnN0cmFpbnRzIGJyZWFrLCBvdXIgY3VycmVudCBhcmNoaXRlY3R1cmUgd2ls bCByZXF1aXJlIHNpZ25pZmljYW50IGNoYW5nZS48L2Rpdj48ZGl2Pjxicj5SZWdhcmRzLDxicj48 Yj5DaGFybGllIEdlcm88L2I+PGRpdj5TZW5pb3IgUHJpbmNpcGFsIFN5c3RlbSBTb2Z0d2FyZSBF bmdpbmVlcjwvZGl2PjxkaXY+VGVhbSBMZWFkIEVuZ2luZWVyaW5nIC0gQWthbWFpIExhYnM8L2Rp dj48ZGl2PjwvZGl2PjxkaXY+NjE3LjQ0NC4zOTQwPC9kaXY+PC9kaXY+PGRpdj48YnI+T24gSnVs IDMxLCAyMDE0LCBhdCAxOjM0IFBNLCAiTWljaGFlbCBTdEpvaG5zIiAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1zakBudGhwZXJtdXRhdGlvbi5jb20iPm1zakBudGhwZXJtdXRhdGlvbi5jb208L2E+Jmd0 OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxkaXY+DQogIA0KICAgIDxtZXRhIGNvbnRlbnQ9InRleHQv aHRtbDsgY2hhcnNldD1VVEYtOCIgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIj4NCiAgDQogIA0K ICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gNy8zMC8yMDE0IDk6MTggUE0sIEdl cm8sIENoYXJsaWUNCiAgICAgIHdyb3RlOjxicj4NCiAgICA8L2Rpdj4NCiAgICA8YmxvY2txdW90 ZSBjaXRlPSJtaWQ6QkQwNjgwODAtMjg1NC00RUJBLUE5NkUtMTAzMENCN0MxQ0ZGQGFrYW1haS5j b20iIHR5cGU9ImNpdGUiPg0KICAgICAgPG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBj b250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPg0KICAgICAgPGRpdj5Tb3JyeSBmb3Ig dGhlIHNlY29uZCBsYXRlIHJlc3BvbnNlLiAmbmJzcDtIZWN0aWMgZGF5LiAmbmJzcDtIZXJlJ3Mg YQ0KICAgICAgICBmb2xsb3cgdXAgZnJvbSB0aGUgcHJldmlvdXMuPC9kaXY+DQogICAgICA8YnI+ DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIE5vIHByb2JzPGJyPg0KICAgIDxibG9ja3F1b3RlIGNp dGU9Im1pZDpCRDA2ODA4MC0yODU0LTRFQkEtQTk2RS0xMDMwQ0I3QzFDRkZAYWthbWFpLmNvbSIg dHlwZT0iY2l0ZSI+DQogICAgICA8ZGl2Pjxicj4NCiAgICAgIDwvZGl2Pg0KICAgICAgPGRpdj5J biBhZGRpdGlvbiwgYXMgbG9uZyBhcyBUTFMgMS4zIGtlZXBzIHN0YXRpYyBSU0Ega2V5IGV4Y2hh bmdlDQogICAgICAgIGFuZCByZW5lZ290aWF0aW9uIG91dCBhcyB3ZWxsIGFzIG9ubHkgcmVtb3Zp bmcgUE1TIHRvIE1TIGluIDEuMw0KICAgICAgICBhbmQgbGF0ZXIsIHdlIHNob3VsZCBiZSBvay4g Jm5ic3A7QXMgc29tZW9uZSBhZGVwdGx5IGluZmVycmVkDQogICAgICAgIGVhcmxpZXIsIHRoaXMg aXMgd2hlcmUgdGhpbmdzIHdvdWxkIGdldCBoYWlyeSBmb3IgdXMgaWYgYW55IG9mDQogICAgICAg IHRoZXNlIGNvbnN0cmFpbnRzIGFyZSB2aW9sYXRlZC48L2Rpdj4NCiAgICAgIDxkaXY+PGJyPg0K ICAgICAgPC9kaXY+DQogICAgICA8YnI+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxicj4NCiAg ICBJIGNvdWxkbid0IHBhcnNlIHRoaXMgdmVyeSB3ZWxsIC0gdG9vIG1hbnkgbWlzc2luZyBjb21t YXMuJm5ic3A7IERpZCB5b3UNCiAgICBtZWFuPzogPGJyPg0KICAgIDxicj4NCiAgICAiSW4gYWRk aXRpb24sIGFzIGxvbmcgYXMgVExTMS4zIG9ubHkgcmVtb3ZlcyBzdGF0aWMgUlNBIGtleSBleGNo YW5nZQ0KICAgIGFuZCByZW5lZ290aWF0aW9uIHdlIHNob3VsZCBiZSBvayI8YnI+DQogICAgPGJy Pg0KICAgIC0gYW5kIC0gPGJyPg0KICAgIDxicj4NCiAgICAiSWYgcmVtb3ZpbmcgdGhlIHByZS1t YXN0ZXIgc2VjcmV0IG9ubHkgYXBwbGllcyB0byBUTFMxLjMgYW5kIGxhdGVyDQogICAgd2Ugc2hv dWxkIGJlIG9rIjxicj4NCiAgICA8YnI+DQogICAgSSB0aG91Z2h0IHJlbW92aW5nIHRoZSBwcmUt bWFzdGVyIHJlZ2FyZGxlc3Mgb2YgcmV2IHdhcyB0aGUgaXNzdWU/PGJyPg0KICAgIDxicj4NCiAg ICBNaWtlPGJyPg0KICAgIDxicj4NCiAgDQoNCjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_C1079511D7A545D0A552529FB9D306D5akamaicom_-- From nobody Thu Jul 31 21:15:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92A51A03CA for ; Thu, 31 Jul 2014 21:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9YwtzGFlmFE for ; Thu, 31 Jul 2014 21:15:54 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B13D31A03C9 for ; Thu, 31 Jul 2014 21:15:54 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id v10so3357582qac.26 for ; Thu, 31 Jul 2014 21:15:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=y3qygTuNryYQb7QvmONehG96jPpejvyGAp2HBMHk6RI=; b=jGtY5hRHwoy8hnBauP/EeYdkO8qwzFj+LUtKWcvPsiH52OiDo/AYAHed+0D1idvuWr hvpEYFRmjoZSrnewerZ/387mxd6X8vqbjrmNokysabINZ/vWdbumhVQib5YWcMEf998Z M2GTe/BVy6yqBddQ1vbwL+sLk8VIfYWEAFPrEWqPLYzfEnxgOV5ubXZj0iP8Hui8hXcn Jtz7iAIPcSNvR0NrXFXoyCp5A3VMmiFd5Fp9O8OaP11stV7YKz9rqs+ncqfjQkpWji6L /patldzjxq7jQzQaDSmdajkWy1FoYaukUH0X2dhr7+MKOf/9rekTR+uJwxU2XYmVQL1X RYTA== X-Gm-Message-State: ALoCoQmVRqbtMfz+Qph/sZzUQAciQbay5yDNBFaZETy/F80x/hSceyg9ky5WFWpqRs6inUIzgGSO MIME-Version: 1.0 X-Received: by 10.140.50.50 with SMTP id r47mr4140056qga.96.1406866553796; Thu, 31 Jul 2014 21:15:53 -0700 (PDT) Received: by 10.140.108.6 with HTTP; Thu, 31 Jul 2014 21:15:53 -0700 (PDT) X-Originating-IP: [64.134.236.22] In-Reply-To: References: <53D907B0.3000006@nthpermutation.com> <53D91332.9070103@nthpermutation.com> <53D95C7D.9060408@nthpermutation.com> <6ECEF2D7-A1AE-4AC4-90C5-62A38075B0BF@akamai.com> <53DA7E2A.50905@nthpermutation.com> Date: Fri, 1 Aug 2014 00:15:53 -0400 Message-ID: From: "StJohns, Michael" To: "Gero, Charlie" Content-Type: multipart/alternative; boundary=001a11351d9e2fb63404ff89a59c Archived-At: http://mailarchive.ietf.org/arch/msg/tls/j-MnlS_46RDnzWdG_wuAIcZmbO8 Cc: "tls@ietf.org" Subject: Re: [TLS] Premaster/Master convention X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Aug 2014 04:15:57 -0000 --001a11351d9e2fb63404ff89a59c Content-Type: text/plain; charset=UTF-8 Got it. Thanks for the clarification. On Thursday, July 31, 2014, Gero, Charlie wrote: > Sorry for the lack of clarity. What I mean is, I think Akamai will be > able to keep our current system working even with PMS to MS removed given: > > 1. Removal of the PMS to MS step is done in 1.3 and forward only (this > seems obvious, but in the argument of explicitness...) > > AND > > 2. TLS 1.3 removes static RSA key exchange. > > AND > > 3. TLS 1.3 removes renegotiation. > > If any of those constraints break, our current architecture will require > significant change. > > Regards, > *Charlie Gero* > Senior Principal System Software Engineer > Team Lead Engineering - Akamai Labs > 617.444.3940 > > On Jul 31, 2014, at 1:34 PM, "Michael StJohns" > wrote: > > On 7/30/2014 9:18 PM, Gero, Charlie wrote: > > Sorry for the second late response. Hectic day. Here's a follow up from > the previous. > > No probs > > > In addition, as long as TLS 1.3 keeps static RSA key exchange and > renegotiation out as well as only removing PMS to MS in 1.3 and later, we > should be ok. As someone adeptly inferred earlier, this is where things > would get hairy for us if any of these constraints are violated. > > > > I couldn't parse this very well - too many missing commas. Did you mean?: > > "In addition, as long as TLS1.3 only removes static RSA key exchange and > renegotiation we should be ok" > > - and - > > "If removing the pre-master secret only applies to TLS1.3 and later we > should be ok" > > I thought removing the pre-master regardless of rev was the issue? > > Mike > > --001a11351d9e2fb63404ff89a59c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Got it. =C2=A0Thanks for the clarification. =C2=A0

On Thursday, July= 31, 2014, Gero, Charlie <cgero@akam= ai.com> wrote:
Sorry for the lack of clarity. =C2=A0What I mean is,= I think Akamai will be able to keep our current system working even with P= MS to MS removed given:

1. Removal of the PMS to M= S step is done in 1.3 and forward only (this seems obvious, but in the argu= ment of explicitness...)

AND

2. TLS 1.3 removes static = RSA key exchange.

AND

3. = TLS 1.3 removes renegotiation.

If any of those con= straints break, our current architecture will require significant change.

Regards,
Charlie Gero
Senior Principal System Softwa= re Engineer
Team Lead Engineering - Akamai Labs
<= div>617.444.3940

On Jul 31, 2014, at 1:34 PM, "Mic= hael StJohns" <msj@nthpermutation.com= > wrote:

=20 =20 =20 =20
On 7/30/2014 9:18 PM, Gero, Charlie wrote:
=20
Sorry for the second late response. =C2=A0Hectic day. =C2=A0Here= 's a follow up from the previous.

No probs

In addition, as long as TLS 1.3 keeps static RSA key exchange and renegotiation out as well as only removing PMS to MS in 1.3 and later, we should be ok. =C2=A0As someone adeptly inferred earlier, this is where things would get hairy for us if any of these constraints are violated.



I couldn't parse this very well - too many missing commas.=C2=A0 Di= d you mean?:

"In addition, as long as TLS1.3 only removes static RSA key exchan= ge and renegotiation we should be ok"

- and -

"If removing the pre-master secret only applies to TLS1.3 and late= r we should be ok"

I thought removing the pre-master regardless of rev was the issue?

Mike

=20
--001a11351d9e2fb63404ff89a59c--