From jsalowey@cisco.com Tue May 7 20:11:41 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9A621F87FE for ; Tue, 7 May 2013 20:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afoMRCbCaGpI for ; Tue, 7 May 2013 20:11:36 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 649AA21F859A for ; Tue, 7 May 2013 20:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10008; q=dns/txt; s=iport; t=1367982696; x=1369192296; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=r56sQqsIxwtRzNJ9LejRREIlm/t59F/ln6RrUxBMLhk=; b=Q66OhHtxyN6XfxuUfy9VatX5SnBKtnXekktofVseiqZY/RofPD2un2FF fNlL9QqH3sv+WAR0DI+PeRXguTa38aBJNQPMgqe9SQReq5VbFB2fYM7Vc JGKLxT33tqjppCy61LPkPmHUYH+P9GeT+n19bHsu8jF/mE7wnp9App+Tm Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FABTBiVGtJV2Y/2dsb2JhbABHCYMHN78RgQQWdIIfAQEBAwEBAQE3NAEKBQsCAQgiFBAnCyUCBA4FCId+Bgy0VoxaBI1tgQgCMQeCdGEDk1uVBIMBDYFrJBg X-IronPort-AV: E=Sophos;i="4.87,631,1363132800"; d="scan'208";a="207671423" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 08 May 2013 03:11:35 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r483BZQP001427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 May 2013 03:11:35 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.125]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 7 May 2013 22:11:34 -0500 From: "Joseph Salowey (jsalowey)" To: Sean Turner Thread-Topic: [TLS] AD review of draft-ietf-tls-oob-pubkey Thread-Index: AQHOOquXB6gmMdKeDUqi+SEmVk8DaZj7EfaA Date: Wed, 8 May 2013 03:11:33 +0000 Message-ID: References: <516D5ADE.3050506@ieca.com> In-Reply-To: <516D5ADE.3050506@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.202] Content-Type: text/plain; charset="us-ascii" Content-ID: <578EEBD575B2C143A7F5CADF95DE4029@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [TLS] AD review of draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 03:11:41 -0000 Most of these look reasonable to me, a few comments inline at the end.=20 Thanks, Joe On Apr 16, 2013, at 7:06 AM, Sean Turner wrote: > I'd like to discuss some of these before issuing an IETF LC. There's no = implied importance based on the order. >=20 > 0) abstract: I'd delete the 2nd paragraph it really sounds like marketing= . The third paragraph is also a repeat of what's in the 1st paragraph - I'= d just delete it. Finally, need to be clear that you're also defining two = new TLS extensions: >=20 > This document specifies a new certificate type and two TLS extensions, > one for the client and one for the server, for exchanging raw > public keys in Transport Layer Security (TLS) and Datagram Transport > Layer Security (DTLS) for use with out-of-band public key validation. >=20 > 1) s1 does a good job of motivating the need for server side keys but fal= ls a little short on client keys. Why does the intro to the bullet list me= ntion how the client can get the server's certificate with the last bullet = also talking about the client's key? Also, is the paragraph after the bull= ets just an explicit example of the last bullet? >=20 > Seems like the first sentence should be: >=20 > Traditionally, TLS client and server public keys ... >=20 > and then maybe: >=20 > Alternative methods are available that allow a TLS clients/servers > to obtain the TLS servers/client public key: >=20 > o TLS clients can obtain the TLS server public key from a > DNSSEC secured resource records using DANE [RFC6698]. >=20 > o The TLS client or server public key is obtained from a > [PKIX] certificate chain from an Lightweight Directory > Access Protocol (LDAP) [LDAP] server or web page. >=20 > o The TLS client and server public key is provisioned into > the operating system firmware image, and updated via > software updates. For example: >=20 > * Some smart objects use the UDP-based Constrained > Application Protocol (CoAP) [I-D.ietf-core-coap] to > interact with a Web server to upload sensor data at > a regular intervals, such as temperature readings. > CoAP [I-D.ietf-core-coap] can utilize DTLS for securing > the client-to-server communication. As part of the > manufacturing process, the embeded device may be > configured with the address and the public key of > a dedicated CoAP server, as well as a public key for > the client itself. >=20 > 2) s1: The last paragraph needs to indicate that this document defines tw= o new certificate extensions: >=20 > This document registers a new value to the IANA certificate > types registry for the support of raw public keys. It also > defines two new TLS extensions, "client_certificate_type" and > "server_certificate_type". >=20 > 3) I think the introduction needs to make it very clear that without the = out-of-band binding between the public key and the entity that no authentic= ation is actually being performed. Add something like the following to the= end of s1: >=20 > The mechanism defined herein only provides authentication when > an out-of-band mechanism is also used to bind the public key > to the entity presenting the key. >=20 > 4) s3: r/raw public key certificates/raw public keys >=20 > 5) wrt Figure 3 maybe we can just list the ones we know about? And, RFC 5= 480 updated 3279 wrt ECDSA public keys so it needs to point there: >=20 > [RFC3279] and [RFC5480] define the following OIDs: >=20 > Key Type | Document | OID > ---------------------+----------------------------+------------------- > RSA | Section 2.3.1 of RFC 3279 | 1.2.840.113549.1.1 > .....................|............................|................... > Digital Signature | | > Algorithm (DSS) | Section 2.3.2 of RFC 3279 | 1.2.840.10040.4.1 > .....................|............................|................... > Elliptic Curve | | > Digital Signature | | > Algorithm (ECDSA) | Section 2.1.1 of RFC 5480 | 1.2.840.10045.2.1 > ---------------------+----------------------------+------------------- >=20 > Figure 3: Example Algorithm Identifiers. >=20 > and add 5480 as reference. >=20 > Grumble: would have listed RSASSA-PSS but it's not supported. >=20 > 6) And on those references, I think the references for 3279 and 5480 end = up normative. All are standards track so no downref issues. >=20 > 7) s3: I think it's not just an algorithm it sometimes includes additiona= l parameters. Also need to include the AlgorithmIdentifier syntax. I think= that means some slight tweaking: >=20 > The SubjectPublicKeyInfo structure is defined in Section 4.1 of RFC > 5280 [PKIX] and does not only contain the raw keys, such as the > public exponent and the modulus of an RSA public key, but also an > algorithm identifier. The algorithm identifier can also include > parameters. The structure, as shown in Figure 2, is > encoded in an ASN.1 format and therefore contains length information > as well. An example is provided in Appendix A. >=20 > SubjectPublicKeyInfo ::=3D SEQUENCE { > algorithm AlgorithmIdentifier, > subjectPublicKey BIT STRING } >=20 > AlgorithmIdentifier ::=3D SEQUENCE { > algorithm OBJECT IDENTIFIER, > parameters ANY DEFINED BY algorithm OPTIONAL } >=20 > Figure 2: SubjectPublicKeyInfo ASN.1 Structure. >=20 > ref: >=20 > [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, > "Elliptic Curve Cryptography Subject Public Key > Information", RFC 5480, March 2009. >=20 > 8) I'm thinking we need to say DER encoded in the above as well: >=20 > an DER encoded ASN.1 [X.690] format >=20 > here's the reference: >=20 > [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, > Information technology - ASN.1 encoding rules: > Specification of Basic Encoding Rules (BER), Canonical > Encoding Rules (CER) and Distinguished Encoding Rules > (DER). >=20 > 9) s4.1: Are some words missing from the following: >=20 > In order to indicate the support of out-of-band raw public keys, > clients MUST include the 'client_certificate_type' and > 'server_certificate_type' extensions extended client hello message. >=20 > extensions "in an" extended client hello message? >=20 > 10) s4.2: Maybe reword this slightly: >=20 > OLD: >=20 > If the client indicated the support of raw public keys in the > 'client_certificate_type' extension in the client hello and the > server is able to provide such raw public key then the TLS server > MUST place the SubjectPublicKeyInfo structure into the Certificate > payload. >=20 > NEW: >=20 > If the client hello indicates support of raw public keys in the > 'client_certificate_type' extension and the > server also supports raw public keys then the TLS server > MUST place the SubjectPublicKeyInfo structure into the Certificate > payload. >=20 > But, a more important question is the meaning of that paragraph above. Do= esn't that override the "sorted by client preference" from s3? >=20 [Joe] I think this should probably say something like: "If the client hello indicates support of raw public keys in the 'client_certificate_type' extension and the server chooses to use raw public keys then the TLS server MUST place the SubjectPublicKeyInfo structure into the Certificate payload. > 11) s6: Got some questions about the following: >=20 > This information will be needed to make > authorization decisions. Without a secure binding, > man-in-the-middle attacks may be the consequence. >=20 > 1st isn't that authentication. 2nd isn't it masquerade attacks? 3rd it'= s not really a may it's more an is likely to be? >=20 [Joe] I'm not sure binding a key to a name is exactly authentication. I'd= probably reword it something like: "Without a secure binding between identity and key the protocol will be vul= nerable to masquerade and man-in-the-middle attacks. " > 12) In s6, it indicates: >=20 > This document assumes that such > binding can be made out-of-band and we list a few examples in > Section 1. >=20 > This statement begs the question as to whether there needs to be a requir= ement on protocols that use this extension to specify the method used to pr= ovide the out-of-band binding. In other words something like: >=20 > Specifications that make use of the extension MUST specify the > mechanism by which the identity and the public key are bound. > Otherwise, authentication is not possible. >=20 [Joe] Or maybe=20 "In order to address these vulnerabilities, specifications that make use of= the extension MUST specify how the identity and public key are bound."=20 > 13) How are we supposed to check whether key is still considered "good"? = If you can't that might be okay, but you need to mention that there's no m= echanism to support this yet or that that also needs to be done out-of-band= . >=20 [Joe] I think we need to state this is done out of band as well. =20 > 14) Are there any other extensions that don't make sense to negotiate if = raw keys are chosen? For example, if the the client and server settle on r= aw keys do either of the ocsp stapling extensions make sense anymore? >=20 [Joe] At least the multi-ocsp extension could be extended to support other = Status mechanisms.=20 > 15) In s7, ask IANA to point the Certificate's Type Registry to this draf= t. >=20 > spt > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From gswaru@gmail.com Tue May 7 20:57:28 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0062621F8B18 for ; Tue, 7 May 2013 20:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNFb51OdwXbV for ; Tue, 7 May 2013 20:57:23 -0700 (PDT) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id D5E6B21F8ADF for ; Tue, 7 May 2013 20:57:22 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id j1so1528075oag.41 for ; Tue, 07 May 2013 20:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=jGDk09BibZLViqb6pL9g7ubeGAovJlPG7DYZBAAF7D0=; b=dRQc9xWVlRiXwzEsObcVK8vdegA5l/FCmLlOXdzUHasVQEicv5rKJVP3ddEJA/r2wK 5exqiSSbkRl0wqoEn+UJd38ersXSSf9vyQP/UsIs+ofiEfwXAguC6LCOszaSdK0mkfrm K+Ko+A01PksAXYE7pS1vdO3/UGd5g/Am57g2aEhe0nQurjeq4InaHmzJ9h1GUXcKXleZ F0aMosLEFev0Q4BOfeRGPIqTpazk9zVceIyC5P5tTWHWm6GfdB5BVMHD0ZvzAfwISW5+ oFZtpfDEo1C4xE40HGN3cQGdZQWjhQ8KPsDt5SA37QPh6pk8NES+J5KCuQHm4kXifQDD mjWA== MIME-Version: 1.0 X-Received: by 10.60.115.103 with SMTP id jn7mr1409020oeb.136.1367985442430; Tue, 07 May 2013 20:57:22 -0700 (PDT) Received: by 10.60.35.102 with HTTP; Tue, 7 May 2013 20:57:22 -0700 (PDT) Date: Wed, 8 May 2013 09:27:22 +0530 Message-ID: From: Swarupa To: tls@ietf.org Content-Type: multipart/alternative; boundary=089e01161b485aa30b04dc2ceee1 Subject: [TLS] ECC key exchange messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 03:57:28 -0000 --089e01161b485aa30b04dc2ceee1 Content-Type: text/plain; charset=ISO-8859-1 Hi , I am working on an ECC project, so I wanted to check packet capture for ECC key exchange,but when I run s_server with cipher as ECDH_RSA cipher set and try to connect from s_client,I see alert instead of server hello from server. What is the issue. How can I get openssl to use EDCH ciphers. Thanks and Regards, Swarupa --089e01161b485aa30b04dc2ceee1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi ,
I am working on an ECC project, so I wanted to ch= eck packet capture for ECC key exchange,but when I run s_server with cipher= as ECDH_RSA cipher set and try to connect from s_client,I see alert instea= d of server hello from server. What is the issue. How can I get openssl to = use EDCH ciphers.

Thanks and Regards,
Swarupa
--089e01161b485aa30b04dc2ceee1-- From juhovh@iki.fi Tue May 7 22:38:52 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EDB21F8E6E for ; Tue, 7 May 2013 22:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.303 X-Spam-Level: X-Spam-Status: No, score=-0.303 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_83=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJ50ZyK0q+cN for ; Tue, 7 May 2013 22:38:47 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id C56B221F8E5B for ; Tue, 7 May 2013 22:38:45 -0700 (PDT) Received: from [10.48.184.65] (188.238.59.65) by jenni2.inet.fi (8.5.140.03) id 5163F0F201A66385; Wed, 8 May 2013 08:38:43 +0300 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B329) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= Date: Wed, 8 May 2013 08:38:42 +0300 To: Swarupa Cc: "tls@ietf.org" Subject: Re: [TLS] ECC key exchange messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 05:38:53 -0000 On 8.5.2013, at 6.57, Swarupa wrote: > Hi , > I am working on an ECC project, so I wanted to check packet capture for EC= C key exchange,but when I run s_server with cipher as ECDH_RSA cipher set an= d try to connect from s_client,I see alert instead of server hello from serv= er. What is the issue. How can I get openssl to use EDCH ciphers. This might be an irrelevant question, but are you sure you want ECDH_RSA and= not ECDHE_RSA? ECDH is a fixed-ECDH cipher suite and requires a server cert= ificate that is signed with RSA and contains an ECDH public key. ECDHE is an= ephemeral suite where the keys are generated separately for each new sessio= n, this works for "traditional" RSA certificates that contain no ECDH keys. Juho= From dkg@fifthhorseman.net Thu May 9 12:54:02 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF8821F914C for ; Thu, 9 May 2013 12:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCuWeBsP25jp for ; Thu, 9 May 2013 12:53:57 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id CCA3B21F8CE2 for ; Thu, 9 May 2013 12:53:56 -0700 (PDT) Received: from [192.168.13.156] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 04F65F979; Thu, 9 May 2013 15:53:50 -0400 (EDT) Message-ID: <518BFECB.8050501@fifthhorseman.net> Date: Thu, 09 May 2013 15:53:47 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130413 Icedove/17.0.5 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <516D5ADE.3050506@ieca.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2ALMHJBSEFRHEXJXDHHRN" Cc: "" , "" Subject: Re: [TLS] AD review of draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 19:54:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2ALMHJBSEFRHEXJXDHHRN Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/07/2013 11:11 PM, Joseph Salowey (jsalowey) wrote: >> 12) In s6, it indicates: >> >> This document assumes that such >> binding can be made out-of-band and we list a few examples in >> Section 1. >> >> This statement begs the question as to whether there needs to be a req= uirement on protocols that use this extension to specify the method used = to provide the out-of-band binding. In other words something like: >> >> Specifications that make use of the extension MUST specify the >> mechanism by which the identity and the public key are bound. >> Otherwise, authentication is not possible. >> > [Joe] Or maybe=20 > "In order to address these vulnerabilities, specifications that make us= e of the extension MUST specify how the identity and public key are bound= =2E"=20 Why is this a MUST? What would be wrong with a specification that makes use of the extension and declines to mandate a specific OOB mechanism (e.g. leaves that choice of selection up to the service administrator or local configuration or something else)? Being deliberately agnostic about corners of a protocol that you don't want to constrain is pretty healthy. If a spec for some new service comes out that uses OOB keys, and then later someone publishes a novel (and useful) mechanism for verifying the binding between those keys and identities, do we want that spec to be considered invalid when used in combination with the new verification mechanism? >> 14) Are there any other extensions that don't make sense to negotiate = if raw keys are chosen? For example, if the the client and server settle= on raw keys do either of the ocsp stapling extensions make sense anymore= ? >=20 > [Joe] At least the multi-ocsp extension could be extended to support ot= her Status mechanisms.=20 I'm not convinced that this extension of an extension should be coupled into the same draft as oob-pubkey itself. It seems likely to make it harder to reach consensus on oob-pubkey without providing a significant benefit. --dkg ------enig2ALMHJBSEFRHEXJXDHHRN 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.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJRi/7LXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcEDkP/2c1IXHIh46XGQdJogUtDw1L 6lI5x+uZJdKsdcgAFyt4B9RxeH5Pza2P9At7NT3HAy25YUSMPvIdX1cYjj9Mhodc VT+ZHwQEmquqAyfIh4hGsz8NX4Sa+FsLqdhdBqXunyVcYkv5nO29DFb3r6Lr0vQi gyCPAA6U8wBoxR5dM3jwc7t/TfWhTW7tqGymQWrzfuzA/n15Qnrak2hUFYujyAXg eJI17UbL3yRH94DMLfz0bZQADHHkaYi4vV3vvUQ1s9KwKtCFdwoGNf9xALrGJInF 91+z+XYK67hfRa+ohijMVNacqoyWehMJEvBPmi0kcx+IlCe1i8wbjC7New5h5dD7 xyZ+imIEufB5ROG/uOXBvqK8eSA6cJagupYezxudf27yX3a4SF5X1QAuA+xtOdAK W+/YdSVTSKolvyY6jvpdYS8S4adgZoN5S9lAVsa2/ugkOu7Y76EqbBhBantGa78A 2qawT5ofcoz/FgmwsO+4/sCVa48QEneXnmWDZIVXFuJd1aFWkZTFdVVkXdREGAuQ DO40O8eBrMmDP2DIG+nk/dQamOK4ak1/088MBHTr5JQfbQsEeVl9DTFswYmfYxhl pYoz5bPyXapDrWETq9a73BCsmfD7zDAhTP6cKn1gjjhufHK3UOYAmbY9XUNaKrKQ /oALRPRh54fG1WkldAna =O8x2 -----END PGP SIGNATURE----- ------enig2ALMHJBSEFRHEXJXDHHRN-- From jsalowey@cisco.com Thu May 9 20:19:45 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B8D21F8ED8 for ; Thu, 9 May 2013 20:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.392 X-Spam-Level: X-Spam-Status: No, score=-110.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIdqsHRs6mX9 for ; Thu, 9 May 2013 20:19:39 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B78AE21F8EB5 for ; Thu, 9 May 2013 20:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3681; q=dns/txt; s=iport; t=1368155980; x=1369365580; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=T9LkWp7yvLAgLwVlX2dKgWrmUsqjJ94JVS4M5IOhzGE=; b=k4sdWd9SelTv0CVtVP9dQCv02dX0rr0cqYlDReAx1rHlZqbYfcswdi50 jzmQPpJiat5irLvB3fzbsh+jXsyV6fnPCXZX5l5znKHToXW09CDaKI8Of kET1Bz9gXpviA34JKEEft3lbniWLsMsW6XWQY4QZXT6NOeph2FKDDnh/w 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAF5mjFGtJXG9/2dsb2JhbABJCYMHwD9+FnSCHwEBAQMBOj8FCwIBCBgKFBAyJQIEDgUIh34Gvg6NbYEIAjEHgnRhA5NdlQSDD4In X-IronPort-AV: E=Sophos;i="4.87,645,1363132800"; d="scan'208";a="208644256" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 10 May 2013 03:19:35 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4A3JZW6011639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 May 2013 03:19:35 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.125]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Thu, 9 May 2013 22:19:34 -0500 From: "Joseph Salowey (jsalowey)" To: Daniel Kahn Gillmor Thread-Topic: [TLS] AD review of draft-ietf-tls-oob-pubkey Thread-Index: AQHOOquXB6gmMdKeDUqi+SEmVk8DaZj7EfaAgAKqWoCAAHyNAA== Date: Fri, 10 May 2013 03:19:34 +0000 Message-ID: References: <516D5ADE.3050506@ieca.com> <518BFECB.8050501@fifthhorseman.net> In-Reply-To: <518BFECB.8050501@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.202] Content-Type: text/plain; charset="us-ascii" Content-ID: <9BA13E3AC2E16047B4C999A117CA779A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [TLS] AD review of draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 03:19:45 -0000 On May 9, 2013, at 12:53 PM, Daniel Kahn Gillmor wr= ote: > On 05/07/2013 11:11 PM, Joseph Salowey (jsalowey) wrote: >=20 >>> 12) In s6, it indicates: >>>=20 >>> This document assumes that such >>> binding can be made out-of-band and we list a few examples in >>> Section 1. >>>=20 >>> This statement begs the question as to whether there needs to be a requ= irement on protocols that use this extension to specify the method used to = provide the out-of-band binding. In other words something like: >>>=20 >>> Specifications that make use of the extension MUST specify the >>> mechanism by which the identity and the public key are bound. >>> Otherwise, authentication is not possible. >>>=20 >> [Joe] Or maybe=20 >> "In order to address these vulnerabilities, specifications that make use= of the extension MUST specify how the identity and public key are bound."= =20 >=20 > Why is this a MUST? What would be wrong with a specification that makes > use of the extension and declines to mandate a specific OOB mechanism > (e.g. leaves that choice of selection up to the service administrator or > local configuration or something else)? >=20 > Being deliberately agnostic about corners of a protocol that you don't > want to constrain is pretty healthy. If a spec for some new service > comes out that uses OOB keys, and then later someone publishes a novel > (and useful) mechanism for verifying the binding between those keys and > identities, do we want that spec to be considered invalid when used in > combination with the new verification mechanism? >=20 [Joe] In order for this specification to be used securely this binding mus= t be done. A document using this specification could possibly leave this u= p to administrative configuration if that was OK for their environment. Th= ey could also specify a separate interoperable mechanism for achieving the = binding. If a new mechanism is develop then that new mechanism would hav= e to be specified somewhere and documents would need to be updated to descr= ibe how to use that mechanism in an interoperable way. =20 In any case I would be OK with removing the normative MUST and saying somet= hing like: "Specifications that make use of this extension need to describe how the id= entity and the public key are bound. Without this binding, authentication is not possible. "=20 >>> 14) Are there any other extensions that don't make sense to negotiate i= f raw keys are chosen? For example, if the the client and server settle on= raw keys do either of the ocsp stapling extensions make sense anymore? >>=20 >> [Joe] At least the multi-ocsp extension could be extended to support oth= er Status mechanisms.=20 >=20 > I'm not convinced that this extension of an extension should be coupled > into the same draft as oob-pubkey itself. It seems likely to make it > harder to reach consensus on oob-pubkey without providing a significant > benefit. >=20 [Joe] I agree, but to your point above would you want to restrict the use = of an extension that could easily be extended to use a different mechanism = in the future? I think here we would probably want to add text to the doc= ument to say that this document does not cover how revocation either.=20 "Revocation of keys is not covered by this document. Specifications that m= ake use of this extension need to describe if and how revocation of keys is= performed. At the time of this document's publication, OCSP does not supp= ort the revocation of raw public keys so [TLS-OCSP] and [TLS-MULTI_OCSP] d= o not apply. "=20 > --dkg >=20 From Bert.Greevenbosch@huawei.com Mon May 13 20:31:15 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CC011E80E8 for ; Mon, 13 May 2013 20:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.347 X-Spam-Level: X-Spam-Status: No, score=-3.347 tagged_above=-999 required=5 tests=[AWL=3.252, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LagumSTN4NRp for ; Mon, 13 May 2013 20:31:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3A011E80E9 for ; Mon, 13 May 2013 20:31:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARI79413; Tue, 14 May 2013 03:31:07 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 14 May 2013 04:30:38 +0100 Received: from SZXEML460-HUB.china.huawei.com (10.82.67.203) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 14 May 2013 04:31:05 +0100 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.35]) by szxeml460-hub.china.huawei.com ([10.82.67.203]) with mapi id 14.01.0323.007; Tue, 14 May 2013 11:30:58 +0800 From: Bert Greevenbosch To: "Joseph Salowey (jsalowey)" , Daniel Kahn Gillmor Thread-Topic: [TLS] AD review of draft-ietf-tls-oob-pubkey Thread-Index: AQHOOquXB6gmMdKeDUqi+SEmVk8DaZj7EfaAgAHQbICAAHyNAIAGzRgA Date: Tue, 14 May 2013 03:30:57 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D7272A9@szxeml558-mbx.china.huawei.com> References: <516D5ADE.3050506@ieca.com> <518BFECB.8050501@fifthhorseman.net> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" , "" Subject: Re: [TLS] AD review of draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 03:31:16 -0000 [Joe] I agree, but to your point above would you want to restrict the use = of an extension that could easily be extended to use a different mechanism = in the future? I think here we would probably want to add text to the doc= ument to say that this document does not cover how revocation either.=20 "Revocation of keys is not covered by this document. Specifications that m= ake use of this extension need to describe if and how revocation of keys is= performed. At the time of this document's publication, OCSP does not supp= ort the revocation of raw public keys so [TLS-OCSP] and [TLS-MULTI_OCSP] d= o not apply. "=20 [Bert] I wonder if it would make sense to add some kind of a meta field as = follows: SubjectPublicKeyInfo ::=3D SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING =20 meta OCTET STRING } This could then be used to provide meta information about the public key, e= .g. information that may be needed by an out of band authentication method.= The field could be ignored by default, unless the particular trust model r= equires differently. I guess DER encoding also allows addition of unspecified fields, but I am n= ot sure if they will be ignored or lead to exceptions. From hannes.tschofenig@gmx.net Tue May 14 04:18:15 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D24A21F8DD5 for ; Tue, 14 May 2013 04:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.676 X-Spam-Level: X-Spam-Status: No, score=-100.676 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTo7oGf8+fnO for ; Tue, 14 May 2013 04:18:10 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id F17B421F8FDB for ; Tue, 14 May 2013 04:18:06 -0700 (PDT) Received: from 3capp-gmx-bs48.server.lan ([172.19.170.101]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Llby5-1U3yUE3jWh-00bHEH for ; Tue, 14 May 2013 13:18:05 +0200 Received: from [194.251.119.198] by 3capp-gmx-bs48.server.lan with HTTP; Tue May 14 13:18:05 CEST 2013 MIME-Version: 1.0 Message-ID: From: "Hannes Tschofenig" To: "" Content-Type: text/html; charset=UTF-8 Date: Tue, 14 May 2013 13:18:05 +0200 (CEST) Importance: normal Sensitivity: Normal X-Priority: 3 X-Provags-ID: V03:K0:MbUcUI09+IhvjOJLTEE+4qYD0PEtrmerlioHyoTraGP JWzpDhN88WfmlxYptfbunoqgmEpPHs/GC5YgkzERd38L2Ga/vU zV9rWs4PtgPP2mjxwnT4ibWoDzimjbOEyBkunDfA4E5zdLPRGf dAz4dJyFd0ctB9R2EzYk7T006UYOLwIVfYXuLKhquOd/X/1fpl iFxJNlhTzxxdM5r/EdSzgFj/R4gnFHIngX8KOeEOQ9qwS/A0ne rkJxHjpne+rocKZuk+VjHGvXnvrVpBmfAlJi31dyI1FxbiRgIr tlJmio= Subject: [TLS] TLS Cached Info Status X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 11:18:15 -0000
Hi all, 
 
I thought it would be a good idea to let the group know what the status of the TLS Cached Info draft is (since Rob just asked me a few minutes ago). 
 
You may recall that we had a discussion about the ability to not only cache a single OCSP response (as defined with RFC 6066) but also OCSP responses of intermediate CA certs, which is functionality http://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension/ provides. Rob raised this issue in his review, see http://www.ietf.org/mail-archive/web/tls/current/msg09352.html. 
 
To me it sounds reasonable to add the requested functionality and the pros & cons had been discussed on the list. 
 
When I met Ekr at the recent NIST workshop we briefly spoke about the TLS Cached Info document and how to progress it. He came up with the idea to use the Firefox telemetry feature to gather some data so that we can estimage the cache hit/miss ratio. With data we would obviously be in a much better position to make an informed decision. 
 
I hope that we get that data soon. If we cannot get it then we have to switch to plan B. 
 
Ciao
Hannes
 
 
From turners@ieca.com Tue May 14 11:48:24 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FE421F901B for ; Tue, 14 May 2013 11:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.965 X-Spam-Level: X-Spam-Status: No, score=-100.965 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50EtAulC00bJ for ; Tue, 14 May 2013 11:48:16 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [69.93.164.14]) by ietfa.amsl.com (Postfix) with ESMTP id 41ABC21F9007 for ; Tue, 14 May 2013 11:48:16 -0700 (PDT) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id CA0F93C99EDE2; Tue, 14 May 2013 13:48:15 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway06.websitewelcome.com (Postfix) with ESMTP id BCB293C99EDBE for ; Tue, 14 May 2013 13:48:15 -0500 (CDT) Received: from [198.180.150.142] (port=51147 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UcKGl-0000xp-Cx; Tue, 14 May 2013 13:48:15 -0500 Message-ID: <519286ED.4050304@ieca.com> Date: Tue, 14 May 2013 19:48:13 +0100 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Bert Greevenbosch References: <516D5ADE.3050506@ieca.com> <518BFECB.8050501@fifthhorseman.net> <46A1DF3F04371240B504290A071B4DB63D7272A9@szxeml558-mbx.china.huawei.com> In-Reply-To: <46A1DF3F04371240B504290A071B4DB63D7272A9@szxeml558-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.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: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [198.180.150.142]:51147 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 8 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "" , "" Subject: Re: [TLS] AD review of draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 18:48:24 -0000 On 5/14/13 4:30 AM, Bert Greevenbosch wrote: > [Joe] I agree, but to your point above would you want to restrict the use of an extension that could easily be extended to use a different mechanism in the future? I think here we would probably want to add text to the document to say that this document does not cover how revocation either. > > "Revocation of keys is not covered by this document. Specifications that make use of this extension need to describe if and how revocation of keys is performed. At the time of this document's publication, OCSP does not support the revocation of raw public keys so [TLS-OCSP] and [TLS-MULTI_OCSP] do not apply. " > > [Bert] I wonder if it would make sense to add some kind of a meta field as follows: > > SubjectPublicKeyInfo ::= SEQUENCE { > algorithm AlgorithmIdentifier, > subjectPublicKey BIT STRING > meta OCTET STRING > } > > This could then be used to provide meta information about the public key, e.g. information that may be needed by an out of band authentication method. The field could be ignored by default, unless the particular trust model requires differently. > > I guess DER encoding also allows addition of unspecified fields, but I am not sure if they will be ignored or lead to exceptions. Please don't add the meta field there. The idea was that the SubjectPublciKey might just be grabbed from a certificate and that field's not there in a certificate. Further, I think the DANE structures require that SubjectPublicKeyInfo be as specified in RFC 5280 (i.e., sans meta). spt From turners@ieca.com Tue May 14 12:21:23 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4798121F8F24 for ; Tue, 14 May 2013 12:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.713 X-Spam-Level: X-Spam-Status: No, score=-100.713 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGU4U6EEGTAK for ; Tue, 14 May 2013 12:20:59 -0700 (PDT) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [74.52.223.144]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF0921F8C4C for ; Tue, 14 May 2013 12:20:55 -0700 (PDT) Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id A4EF2CF4430CF; Tue, 14 May 2013 14:20:46 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway03.websitewelcome.com (Postfix) with ESMTP id 7606ECF442FF7 for ; Tue, 14 May 2013 14:20:46 -0500 (CDT) Received: from [198.180.150.142] (port=51298 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UcKmE-00063m-5U; Tue, 14 May 2013 14:20:46 -0500 Message-ID: <51928E8C.7070905@ieca.com> Date: Tue, 14 May 2013 20:20:44 +0100 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <516D5ADE.3050506@ieca.com> <518BFECB.8050501@fifthhorseman.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.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: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [198.180.150.142]:51298 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "" , "" Subject: Re: [TLS] AD review of draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 19:21:27 -0000 On 5/10/13 4:19 AM, Joseph Salowey (jsalowey) wrote: > > On May 9, 2013, at 12:53 PM, Daniel Kahn Gillmor wrote: > >> On 05/07/2013 11:11 PM, Joseph Salowey (jsalowey) wrote: >> >>>> 12) In s6, it indicates: >>>> >>>> This document assumes that such >>>> binding can be made out-of-band and we list a few examples in >>>> Section 1. >>>> >>>> This statement begs the question as to whether there needs to be a requirement on protocols that use this extension to specify the method used to provide the out-of-band binding. In other words something like: >>>> >>>> Specifications that make use of the extension MUST specify the >>>> mechanism by which the identity and the public key are bound. >>>> Otherwise, authentication is not possible. >>>> >>> [Joe] Or maybe >>> "In order to address these vulnerabilities, specifications that make use of the extension MUST specify how the identity and public key are bound." >> >> Why is this a MUST? What would be wrong with a specification that makes >> use of the extension and declines to mandate a specific OOB mechanism >> (e.g. leaves that choice of selection up to the service administrator or >> local configuration or something else)? >> >> Being deliberately agnostic about corners of a protocol that you don't >> want to constrain is pretty healthy. If a spec for some new service >> comes out that uses OOB keys, and then later someone publishes a novel >> (and useful) mechanism for verifying the binding between those keys and >> identities, do we want that spec to be considered invalid when used in >> combination with the new verification mechanism? >> > > [Joe] In order for this specification to be used securely this binding must be done. A document using this specification could possibly leave this up to administrative configuration if that was OK for their environment. They could also specify a separate interoperable mechanism for achieving the binding. If a new mechanism is develop then that new mechanism would have to be specified somewhere and documents would need to be updated to describe how to use that mechanism in an interoperable way. > > In any case I would be OK with removing the normative MUST and saying something like: > > "Specifications that make use of this extension need to describe how the identity and the public key are bound. > Without this binding, authentication is not possible. " Joe you read my mind. I'm also okay without the MUST. >>>> 14) Are there any other extensions that don't make sense to negotiate if raw keys are chosen? For example, if the the client and server settle on raw keys do either of the ocsp stapling extensions make sense anymore? >>> >>> [Joe] At least the multi-ocsp extension could be extended to support other Status mechanisms. >> >> I'm not convinced that this extension of an extension should be coupled >> into the same draft as oob-pubkey itself. It seems likely to make it >> harder to reach consensus on oob-pubkey without providing a significant >> benefit. >> > > [Joe] I agree, but to your point above would you want to restrict the use of an extension that could easily be extended to use a different mechanism in the future? I think here we would probably want to add text to the document to say that this document does not cover how revocation either. > > "Revocation of keys is not covered by this document. Specifications that make use of this extension need to describe if and how revocation of keys is performed. At the time of this document's publication, OCSP does not support the revocation of raw public keys so [TLS-OCSP] and [TLS-MULTI_OCSP] do not apply. " Not thrilled with this answer but I could live with it. How about adding a new section that groups these two issues together and call it "What specifications that use this document must specify" or something like that. spt From agl@google.com Tue May 14 13:57:29 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8451921F8FED for ; Tue, 14 May 2013 13:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuPO9f5aMX0B for ; Tue, 14 May 2013 13:57:24 -0700 (PDT) Received: from mail-gh0-f180.google.com (mail-gh0-f180.google.com [209.85.160.180]) by ietfa.amsl.com (Postfix) with ESMTP id 332FD21F8FEB for ; Tue, 14 May 2013 13:57:23 -0700 (PDT) Received: by mail-gh0-f180.google.com with SMTP id f18so202476ghb.39 for ; Tue, 14 May 2013 13:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lGhoBwLZdc8imoy8LIvZbtvw0ubLyBNMXABWUJTz+Tw=; b=cD564rrnx5AvvJQNAy/D+86hShg/do5h+v19ZPtQTu4oKR+QPk+tinOjtrNq/pzP63 xL+vL9JV0mPzy9e0mReWiJJTaMyBe6n9Dz7qQyLtii2SGSGTRb2dZVpyjRSZi0CQDbj+ xtCvlELQbUJ2WLX20KlzAP73rbGE1ayuc6Oo7idr8z5CvNfjK2QFWAeVll77jhcVS75X AMLNvLyKdx5uSJCPnEMU9RKTrLAtg2UMiNfhJ8/61ghaqQnfdOdsu2IeeGTfmfAFfQY4 AqpwsTXtVwPRjCvKnAz4oqv268aDHXy/H3a//okQt6zlCJck5Gn7pOkDS67s+2Jk1Jg/ creA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=lGhoBwLZdc8imoy8LIvZbtvw0ubLyBNMXABWUJTz+Tw=; b=IKJxxSv40F2HANWkihPFRRkCFQs5cJQHIjSFX+ukXflif+PnQJIniK8SU6Ghbn6EIz JcbnmH3RHCedo4zn0uiy0r7a+4Uvm+YMhViSe+YqmB1m5D5NDsKmR2drPTdkWmX0D6YY ItviU1GB0VZqLb8D8ntNcKnZZ+6B3cCZmfqRVP0aSaJxDq1h5q7sPEyaXco9O3iGD/ej TqOe4IWvqCnKR8SDtPT+ILzgF8etSF3F5/brsbdwCEnRXy9PLMZoS5jODd1fG+LDLF+x RKgMyeITPTPou1Y0XaTL3Fgz3DQtsjb5MkEqRTlcJYZtZefYjBfS8/gldIbY/K1vrB2q kS6A== MIME-Version: 1.0 X-Received: by 10.236.135.206 with SMTP id u54mr5695513yhi.31.1368565043538; Tue, 14 May 2013 13:57:23 -0700 (PDT) Received: by 10.231.162.202 with HTTP; Tue, 14 May 2013 13:57:23 -0700 (PDT) In-Reply-To: <51805DA9.8000606@KingsMountain.com> References: <51805DA9.8000606@KingsMountain.com> Date: Tue, 14 May 2013 16:57:23 -0400 Message-ID: From: Adam Langley To: "=JeffH" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlgopfGNqX93TcNn7cA19dcnXPV47DSVZdJp/1pR+ngUFIZFB2KKzVgp8yAejZ7lBu3G75XIx0xrWqLM5OnEaemrdHgzaPtfk+4WIF/qo+aM/JdiUDXgPRAtclu7XRwIxj4iI8A4+csb5cV18x2xGvnAalJPYeqk6PzIlCAnrh597/HOLdEUQ3UOuyyOhlDvdNCUgBT Cc: IETF TLS WG Subject: Re: [TLS] comments on draft-balfanz-tls-channelid X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 20:57:29 -0000 Thanks! I can answer a few of the techincal questions. I'll leave your comments on the wording and such to Dirk. > 2. What are the ramifications if the TLS WG does not adopt an > EncryptedExtensions mechanism? I.e., what are the downsides to the "channel > id" being publicly exposed, i.e., the security ones as well as the privacy > implications? It would mean that clients send, in the clear, a unique identifier for each eTLD+1. This would allow TLS connections to be deanonymised etc. > 6. This mechanism should be compared/contrasted with TLS Channel Binding > RFC5929. They don't appear to be mutually exclusive on first thought. What > are the semantics if they are both employed by an application? For what > might one employ one or the other or both concurrently? They are certainly related. Something like ChannelIDs could be implemented at the application layer by signing channel binding values. I think channel bindings were designed to provide exactly this, but to the application. > what are the threats if a long-term, asymmetric-key-based client identifier > is sent in the clear during TLS handshake? Is it mostly a privacy concern? > Or is it because of anticipated use cases of binding app-layer info to the > TLS layer? I think it's primarily a privacy concern. > ..so I'm not sure how "session resumption secrets" are "equivalent bearer > tokens" ? The session resumption information is sufficient to authenticate with a given client certificate. That is, if the client certificate is in a hardware token and signs a TLS handshake, then by stealing the session resumption information (from either end of the connection), an attacker steals something equivalent to the client-cert private key in some sense. > you mean that the "x" and "y" fields (of the ChannelIDExtension struct) > contain the affine coordinates of a P-256 [DSS] curve point comprising an > ECC public key "Q" ? Yes. > hashes of both the client-sent and server-sent handshake messages, as seen > by the client? Yes. > but presumably the same (long-lived?) TLS client identifier Q = (x,y) used > and only (r,s) are different ? It's certainly expected that the client would use the same public key (i.e. (x, y) pair), yes. > why? simply for privacy reasons? Yes. > Or is the main concern that the "channel id" will be used by app layers, eg > in HTTP cookies, in order to bind objects to a particular TLS client-server > pair, and thus the "channel id" should be protected as a secret? No, the Channel ID isn't a security secret. We wouldn't want to broadcast it for privacy reasons but, since one has to prove possession of the private key in order to use it, just the public key isn't sensitive. >> We do this by sending a >> constant-length Channel ID under encryption. However, since the >> Channel ID may be transmitted before the server's Finished message is >> received, it's possible that the server isn't in possession of the >> certificate that it presented. > > do you mean in possession of the corresponding private key (to the cert it > presented) ? Yes. > We assume that TLS provides sufficient security to prevent these attackers > from being able to hijack the TLS connection. Yes. >> However, as the signature >> covers the handshake hashes, and therefore the server's certificate, >> it wouldn't be accepted by the true server. > > this essentially means that a attacker server with a mis-issued certificate > cannot act as a real-time TLS proxy between the TLS client and legit server, > yes? > > But otherwise such an attacker could potentially mount an impersonation of > the legitimate server, yes? Yes, but the worry is that the attacker could impersonate the /client/, not the server. >> Against an attacker with the legitimate server's private key we can >> provide the second guarantee only if the legitimate server uses a >> forward-secret cipher suite, otherwise the attacker can hijack the >> connection. > > > here "connection" means the long-lived "security association" between TLS > client and legit server, yes? I think connection means connection in this case. The attacker could derive the session resumption information, but I don't think that helps them any more than simply hijacking the connection. Cheers AGL From ulrich@herberg.name Mon May 20 13:47:11 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1632F21F965C for ; Mon, 20 May 2013 13:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtTdie9q3SP4 for ; Mon, 20 May 2013 13:47:10 -0700 (PDT) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 20C7821F9654 for ; Mon, 20 May 2013 13:47:09 -0700 (PDT) Received: by mail-vb0-f53.google.com with SMTP id i3so4146251vbh.12 for ; Mon, 20 May 2013 13:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=GencEU9eo1qcngfQk4Fhi2VcE5L3G0ckdIvPlLoFf1A=; b=rCQ37SC2nKHV9+ijmIjFRCQefCfJ+0QhyiKU14L36orKarIeBsaTzLHxpW7DbS3Knk wrS9b2RgRxo1sRhL+5CpQcnS4yhs8UcQHBuwroSrVtafHnDnnd4Dy8ksXiZHisJ86dPe pwS+9XegIEsHr9o8ozsn7UJAXjXUWaO4Y/8p0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=GencEU9eo1qcngfQk4Fhi2VcE5L3G0ckdIvPlLoFf1A=; b=SwBglDHPl7nNXqWmFuNh9xUap1eSotpKCoq2Wn6fzAY1LapUg4H9BT13VTcG1Ua8wP /TqgsLX6M3fC1rbpzHSgzdjAsTZXLJyyX1x9GwRSR377b9/wsaku8nonrAz0k3GV0Erb 3xdXIOy72L79NcdXveoAm0TfCw0+T7s2hjcrR2xkFTeVE7s7gTppqZTYdo6dpMHkyvpC bafZzShYban5yy55GkauQhMlp5eSoeTOQopTf3S1KW17pFXTi9ztRzOEP+dO0qR4FcpK /dAG71j1yVHiBV7mE/d4Rq3qtoX12op3RmxEuQ53LQkaDicncrEo8JZIqI4iUENG+JGn hoSA== MIME-Version: 1.0 X-Received: by 10.52.165.76 with SMTP id yw12mr11635061vdb.93.1369082828940; Mon, 20 May 2013 13:47:08 -0700 (PDT) Received: by 10.220.195.134 with HTTP; Mon, 20 May 2013 13:47:08 -0700 (PDT) Date: Mon, 20 May 2013 13:47:08 -0700 Message-ID: From: Ulrich Herberg To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlBzMBvgRwYE0PLd9Hft4AJeNliZDvv1j19f8MVBuLbpsUa6gUAQLOghRZN0Tb4zv23nzEU Subject: [TLS] TLS1.2 vs TLS1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 20:47:11 -0000 Hi, I have not followed this WG, so please forgive me if a similar question has already been discussed. I am participating in another SDO on a standard for automated Demand Response, called OpenADR (www.openadr.org), an application for the smart grid. The application is basically a web service, exchanging XML over HTTP over public networks, and using TLS (with RSA and ECDSA / SHA1 ciphers for TLS 1.0 and SHA2 for TLS1.2). Currently, the draft allows for TLS1.0 and 1.1, but recommends using 1.2 (and requires vendors to provide a migration plan in case TLS1.0 is obsoleted) . TLS1.0 and 1.1 RFCs have been obsoleted by the IETF; but I am not sure about the best current practice. Is it absolutely discouraged to use them? The argument in the OpenADR alliance is that many libraries and programming languages do not support TLS1.2, so they recommend to start the handshake with 1.2 and then downgrade - if required - to 1.0. I read that NIST disallows SHA1 after 2013; which would also affect TLS1.0, which does not support SHA2. What would be your recommendation in this case? Mandate TLS1.2 and disallow TLS1.0? Or just strongly recommend ("SHOULD") to use TLS1.2 and SHA2 ciphers, and otherwise to use TLS1.0? Best regards Ulrich From paduffy@cisco.com Mon May 20 14:43:50 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D13221F9698 for ; Mon, 20 May 2013 14:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2T3hy4uBG8kC for ; Mon, 20 May 2013 14:43:46 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id CCCCE21F9699 for ; Mon, 20 May 2013 14:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1683; q=dns/txt; s=iport; t=1369086226; x=1370295826; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=eIwvMwsmTv7RhKNA6+ZToujsVNxkgXwZlbsdMEkO2ic=; b=DYE3FHLw15cIlkOz0asRdXbg1b8Fe3RjFpy/A17jG3U+vuZ/ShRVyd3d FPtXwUUCNnndnKUyzny06Jzr6a8McQlYyucqpf1lEf2GE6l/UyD4uTx47 Ml9jMEzbPMz8Fb0oKejaOyGZjJ+X21+27nefNg0+IHBGulvivW3vJ/zau I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAFAAOYmlGtJV2d/2dsb2JhbABagwgwwU2BBBZ0gh8BAQEEAQEBNTYKARALGAkWDwkDAgECARUwBg0BBQIBAYgJDLxDjyEHg1QDlziGHosigysg X-IronPort-AV: E=Sophos;i="4.87,709,1363132800"; d="scan'208";a="212820203" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 20 May 2013 21:43:45 +0000 Received: from [10.86.244.127] ([10.86.244.127]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4KLhi8t015361; Mon, 20 May 2013 21:43:44 GMT Message-ID: <519A9910.1060001@cisco.com> Date: Mon, 20 May 2013 17:43:44 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ulrich Herberg References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] TLS1.2 vs TLS1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 21:43:50 -0000 Hi Ulrich IMO mandate TLS 1.2 (as SEP2 did). For all of the reasons you mentioned below. With OpenADR, we are talking about an app that impacts the electric grid. Cheers On 5/20/2013 4:47 PM, Ulrich Herberg wrote: > Hi, > > I have not followed this WG, so please forgive me if a similar > question has already been discussed. > > I am participating in another SDO on a standard for automated Demand > Response, called OpenADR (www.openadr.org), an application for the > smart grid. The application is basically a web service, exchanging XML > over HTTP over public networks, and using TLS (with RSA and ECDSA / > SHA1 ciphers for TLS 1.0 and SHA2 for TLS1.2). Currently, the draft > allows for TLS1.0 and 1.1, but recommends using 1.2 (and requires > vendors to provide a migration plan in case TLS1.0 is obsoleted) . > TLS1.0 and 1.1 RFCs have been obsoleted by the IETF; but I am not sure > about the best current practice. Is it absolutely discouraged to use > them? The argument in the OpenADR alliance is that many libraries and > programming languages do not support TLS1.2, so they recommend to > start the handshake with 1.2 and then downgrade - if required - to > 1.0. I read that NIST disallows SHA1 after 2013; which would also > affect TLS1.0, which does not support SHA2. > > What would be your recommendation in this case? Mandate TLS1.2 and > disallow TLS1.0? Or just strongly recommend ("SHOULD") to use TLS1.2 > and SHA2 ciphers, and otherwise to use TLS1.0? > > Best regards > Ulrich > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From robert.cragie@gridmerge.com Tue May 21 00:05:24 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BFF21F9729 for ; Tue, 21 May 2013 00:05: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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WShUu-OA00l0 for ; Tue, 21 May 2013 00:05:20 -0700 (PDT) Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id ADF4521F8A14 for ; Tue, 21 May 2013 00:05:19 -0700 (PDT) Received: from [94.117.43.132] (helo=[10.38.241.94]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) id 1UegdK-00089X-7z for tls@ietf.org; Tue, 21 May 2013 08:05:18 +0100 Message-ID: <519B1CB0.60107@gridmerge.com> Date: Tue, 21 May 2013 08:05:20 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: tls@ietf.org References: <519A9910.1060001@cisco.com> In-Reply-To: <519A9910.1060001@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020006070602090406040800" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [TLS] TLS1.2 vs TLS1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.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, 21 May 2013 07:05:24 -0000 This is a cryptographically signed message in MIME format. --------------ms020006070602090406040800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable +1. TLS 1.2 also opens up use of the AEAD ciphers. Robert On 20/05/2013 22:43, Paul Duffy wrote: > Hi Ulrich > > IMO mandate TLS 1.2 (as SEP2 did). > > For all of the reasons you mentioned below. > > With OpenADR, we are talking about an app that impacts the electric gri= d. > > Cheers > > > > On 5/20/2013 4:47 PM, Ulrich Herberg wrote: >> Hi, >> >> I have not followed this WG, so please forgive me if a similar >> question has already been discussed. >> >> I am participating in another SDO on a standard for automated Demand >> Response, called OpenADR (www.openadr.org), an application for the >> smart grid. The application is basically a web service, exchanging XML= >> over HTTP over public networks, and using TLS (with RSA and ECDSA / >> SHA1 ciphers for TLS 1.0 and SHA2 for TLS1.2). Currently, the draft >> allows for TLS1.0 and 1.1, but recommends using 1.2 (and requires >> vendors to provide a migration plan in case TLS1.0 is obsoleted) . >> TLS1.0 and 1.1 RFCs have been obsoleted by the IETF; but I am not sure= >> about the best current practice. Is it absolutely discouraged to use >> them? The argument in the OpenADR alliance is that many libraries and >> programming languages do not support TLS1.2, so they recommend to >> start the handshake with 1.2 and then downgrade - if required - to >> 1.0. I read that NIST disallows SHA1 after 2013; which would also >> affect TLS1.0, which does not support SHA2. >> >> What would be your recommendation in this case? Mandate TLS1.2 and >> disallow TLS1.0? Or just strongly recommend ("SHOULD") to use TLS1.2 >> and SHA2 ciphers, and otherwise to use TLS1.0? >> >> Best regards >> Ulrich >> _______________________________________________ >> 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 > --------------ms020006070602090406040800 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA1MjEwNzA1MjBaMCMGCSqGSIb3DQEJBDEWBBSfTDcsIY4PIBNIg/uxd8wTI7pyejBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAAJS/FbUQ3CA/a+mv9wGCZgXWHVQjTx6GyPL/9c4ykg118kq Fx9/XGL3NM5kyVxlI3WilXUTt5DOlcD/M1ID+onhYUgPrxS4lcZ38TnTZ8uttYakiz+VUeHj cMLs+wq9DM8r0UizNskGzlHvtkeeLBw0sYGhkPLlgbot5ClNDZfNpkv5ehoBhXw/bBVaFFP9 xCYqQV2Fnyrv75HGJfwar8A/WYLzegxgLGYY1rQiDHMfr76APbckQmphqvW9tWZKPOdyf/8S +sjIlGMR/8Er3QaWzIBFmN/PdnKOob03m+JqkOg32yk9C22dzvcM8axsSYvGPP0bLdgOtrLk fVxsEzwAAAAAAAA= --------------ms020006070602090406040800-- From n.mavrogiannopoulos@gmail.com Tue May 21 01:12:26 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB3221F979C for ; Tue, 21 May 2013 01:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFWLOfM49NZr for ; Tue, 21 May 2013 01:12:24 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id C5B7821F8A0C for ; Tue, 21 May 2013 01:12:21 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id ar20so666704iec.25 for ; Tue, 21 May 2013 01:12:21 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KqM2Ps0VIUd4nAWjG+wm2NAOYTAgetREMTrYUwfzauA=; b=Q4NRXR/tAS4Ue/I6Vw2oxHZmS5H8ekLel4puFtMviXnM7VCD6U5FINWbk2i6uy3QNp hJbCgbpXFK75zAPw1AauRW4veec8+Mk9h8EHsE9jb7XD/4fXSfYT5fLhYcyFvT+Yv7Td +1tSpSC/0p/KUAmwWCkX62cVHZnc99LMDRITlGFnirZ21W0RHrs96C73uqWYfKef8kVz d+VzwsklWoHB8s59G8REV81BzVkB+tpUeg7+/5GM19ICzqEdhuhvRP+PsMMvUAjix60n GX8lTciWrYVuCcpYwhbhHKAhJWj2a5AXW4RKA/PUDf9p8CCCLzmA2Eb40zZYi3vO16lI PLKg== MIME-Version: 1.0 X-Received: by 10.50.70.99 with SMTP id l3mr760285igu.91.1369123941373; Tue, 21 May 2013 01:12:21 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.231.138.69 with HTTP; Tue, 21 May 2013 01:12:21 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 May 2013 10:12:21 +0200 X-Google-Sender-Auth: nudQNwStmJDTG8Gbkal0odhmKF8 Message-ID: From: Nikos Mavrogiannopoulos To: Ulrich Herberg Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] TLS1.2 vs TLS1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 08:12:26 -0000 On Mon, May 20, 2013 at 10:47 PM, Ulrich Herberg wrote: > Hi, > I have not followed this WG, so please forgive me if a similar > question has already been discussed. > I am participating in another SDO on a standard for automated Demand > Response, called OpenADR (www.openadr.org), an application for the > smart grid. The application is basically a web service, exchanging XML > over HTTP over public networks, and using TLS (with RSA and ECDSA / > SHA1 ciphers for TLS 1.0 and SHA2 for TLS1.2). Currently, the draft > allows for TLS1.0 and 1.1, but recommends using 1.2 (and requires > vendors to provide a migration plan in case TLS1.0 is obsoleted) . >From a practical perspective using this suggestion implementers are expected to support 3 protocols. TLS 1.0, TLS 1.1 and TLS 1.2. Except from the fact that this requires more code, given the incompatibilities we see on the web between implementations, the implementations of your protocol may end-up only using TLS 1.0. > TLS1.0 and 1.1 RFCs have been obsoleted by the IETF; but I am not sure > about the best current practice. Is it absolutely discouraged to use > them? There are known issues in TLS 1.0 which have been fixed in later versions (the issues in CBC ciphersuites comes to mind, there may be more). Moreover TLS 1.0 and 1.1 only support the RC4 and CBC ciphersuites, and there are known attacks on both (which may affect your protocol or not). > The argument in the OpenADR alliance is that many libraries and > programming languages do not support TLS1.2, Many also do. > What would be your recommendation in this case? Mandate TLS1.2 and > disallow TLS1.0? Or just strongly recommend ("SHOULD") to use TLS1.2 > and SHA2 ciphers, and otherwise to use TLS1.0? If what you specify is something new, IMO, there are not many reasons to allow legacy protocols. regards, Nikos From hanno@hboeck.de Tue May 21 01:27:01 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1012521F969F for ; Tue, 21 May 2013 01:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1Mgd1l8fB0w for ; Tue, 21 May 2013 01:26:56 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) by ietfa.amsl.com (Postfix) with ESMTP id 2315121F97B2 for ; Tue, 21 May 2013 01:26:55 -0700 (PDT) Received: from melee (91-64-53-146-dynip.superkabel.de [::ffff:91.64.53.146]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, AES128-SHA) by zucker.schokokeks.org with ESMTPSA; Tue, 21 May 2013 10:26:54 +0200 id 0000000000000090.00000000519B2FCE.00004E7F Date: Tue, 21 May 2013 10:26:47 +0200 From: Hanno =?ISO-8859-1?B?QvZjaw==?= To: tls@ietf.org Message-ID: <20130521102647.402e695e@melee> In-Reply-To: References: X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.18; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA256; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-20095-1369124814-0001-2" Subject: Re: [TLS] TLS1.2 vs TLS1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 08:27:01 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-20095-1369124814-0001-2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, 20 May 2013 13:47:08 -0700 Ulrich Herberg wrote: > I am participating in another SDO on a standard for automated Demand > Response, called OpenADR (www.openadr.org), an application for the > smart grid. The application is basically a web service, exchanging XML > over HTTP over public networks, and using TLS (with RSA and ECDSA / > SHA1 ciphers for TLS 1.0 and SHA2 for TLS1.2). Currently, the draft > allows for TLS1.0 and 1.1, but recommends using 1.2 (and requires > vendors to provide a migration plan in case TLS1.0 is obsoleted) . > TLS1.0 and 1.1 RFCs have been obsoleted by the IETF; but I am not sure > about the best current practice. Is it absolutely discouraged to use > them? The argument in the OpenADR alliance is that many libraries and > programming languages do not support TLS1.2, so they recommend to > start the handshake with 1.2 and then downgrade - if required - to > 1.0. I read that NIST disallows SHA1 after 2013; which would also > affect TLS1.0, which does not support SHA2. >=20 > What would be your recommendation in this case? Mandate TLS1.2 and > disallow TLS1.0? Or just strongly recommend ("SHOULD") to use TLS1.2 > and SHA2 ciphers, and otherwise to use TLS1.0? The biggest security issue with TLS 1.0/1.1 is less the use of sha1 and more the use of CBC+hmac in a very wacky combination. =46rom what I'm aware, the use of SHA1 in HMAC shouldn't affect its security. Still it's a good idea to avoid sha1 - it just isn't the most pressing security issue. You should definitely require TLS 1.2 and avoid CBC-ciphersuites if possible if you want high security. The AEAD-ciphersuites (i.e. everything with AES-GCM) in TLS 1.2 are the thing you want to use. The issue with libraries not supporting TLS 1.2 isn't as severe as it may seem. OpenSSL supports TLS 1.2 since a while, GnuTLS also does, the MS-provided ssl libs since Windows 7 as well. nss has no support yet, but there are experimental patches and it's expected to come quite soon. So unless you have a very strong need to use outdated versions of crypto libraries (which is generally not a good idea), it shouldn't be much of an issue. cu, --=20 Hanno B=F6ck mail/jabber: hanno@hboeck.de GPG: BBB51E42 http://www.hboeck.de/ --=_zucker.schokokeks.org-20095-1369124814-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBCAAGBQJRmy/JAAoJEKWIAHK7tR5CbJ0QAJDJ819l9WYiaoMh4vymoLJi Hp2Aqs5y3+wHCW2ORP9tFGOkNdiP94zUwfmj5eSzX2yBaGn7txysz0Ik8K1iDvjL tRtHQtRjEuozI4t8FmpesiZM0EUekEzcCB+OAcUbhf4XhwYGf3QeBgkYQyHeJwuh NYJnMrn6+cFJtrfG54onq2yntk1ptJUvSJ0rq7Nugr4Mf2cL7H419dH/o7KPowxy NfF8Hetzo6ABtJeQhDWXRIQ6PaXhjPp0Fvg7EFkSFDqu2VsRWZE7fH07N2u5C9Ck wfSWcTXjIxQ7IpyumqXsmQNDy/Gi3L3j0Xx0fyNcrW5DrSgKOVQnwucAXYKNbMHI AZjLpay7a8RYG3+83t1+p6C+UEBVuI6yeLlKBBWW0FvKpoHsq31gqTl2PREkV9Io c44FUX0IsfJiWKczSNPZnhSJnteUmLynj9qOqxenbnnMuu1XR7Op9lfiwyjNQTMx zbxgJxCg3rYEz++eFFQJS7LKpLZpmOjOkUdi91lCSuMjNvvdKWL/eDCC/iXG1512 6dyyy3Di0n2y9X3k7iAFXA3DP1HGsCPvfjI5LWICQr2sjUnRhbKdIFMdTIYNGSPT bCW9ioqqkMLKLWH63uS51w2yXUJsOQmV2NSqtXNppmBW8H11e5gsrIY4gXFehWRQ 3quAnxq3f5nERSyCHnOc =+dX+ -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-20095-1369124814-0001-2-- From mcgrew@cisco.com Tue May 21 04:05:45 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F5521F8EA8 for ; Tue, 21 May 2013 04:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TF+I4L0dbUCI for ; Tue, 21 May 2013 04:05:40 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A2C9721F8E93 for ; Tue, 21 May 2013 04:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2439; q=dns/txt; s=iport; t=1369134340; x=1370343940; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9xm6QmEyX2qnFWnL2xK/qJicA8eHtGvXo18pVGv7SEw=; b=L62yXuNG6a9RATPWLojFx0rnhiY6sdC4CWSm70vnI2aD07kBfjWEK3Ny jWOYpNVWoaUFTDpoxjuukty6ujIDDaapud0d3fOX8yAprgURR+HzXleF/ KEDkwfm1bTqQV4OQSC7CSrVS/JD/MM4XGuBW8S1JN2uIIoZIVYxB6NMaD 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocGAGhUm1GtJXG9/2dsb2JhbABZgwgwwVOBCRZtB4IfAQEBBHkSAQgYClYXAQ0CBA4FCIgFvBmNb4EBMQeCc2EDiGegEYMPgXE1 X-IronPort-AV: E=Sophos;i="4.87,714,1363132800"; d="scan'208";a="212853927" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 21 May 2013 11:05:34 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4LB5Y51010241 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 May 2013 11:05:34 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Tue, 21 May 2013 06:05:34 -0500 From: "David McGrew (mcgrew)" To: "ulrich@herberg.name" Thread-Topic: [TLS] TLS1.2 vs TLS1.0 Thread-Index: AQHOVZs3gi3LqK1iMUmZ07SpyuoHgJkPonmA///pSYA= Date: Tue, 21 May 2013 11:05:33 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B184539B6@xmb-rcd-x04.cisco.com> In-Reply-To: <20130521102647.402e695e@melee> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.2 vs TLS1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 11:05:45 -0000 +1 to what Hanno said. David On 5/21/13 4:26 AM, "Hanno B=F6ck" wrote: >On Mon, 20 May 2013 13:47:08 -0700 >Ulrich Herberg wrote: > >> I am participating in another SDO on a standard for automated Demand >> Response, called OpenADR (www.openadr.org), an application for the >> smart grid. The application is basically a web service, exchanging XML >> over HTTP over public networks, and using TLS (with RSA and ECDSA / >> SHA1 ciphers for TLS 1.0 and SHA2 for TLS1.2). Currently, the draft >> allows for TLS1.0 and 1.1, but recommends using 1.2 (and requires >> vendors to provide a migration plan in case TLS1.0 is obsoleted) . >> TLS1.0 and 1.1 RFCs have been obsoleted by the IETF; but I am not sure >> about the best current practice. Is it absolutely discouraged to use >> them? The argument in the OpenADR alliance is that many libraries and >> programming languages do not support TLS1.2, so they recommend to >> start the handshake with 1.2 and then downgrade - if required - to >> 1.0. I read that NIST disallows SHA1 after 2013; which would also >> affect TLS1.0, which does not support SHA2. >>=20 >> What would be your recommendation in this case? Mandate TLS1.2 and >> disallow TLS1.0? Or just strongly recommend ("SHOULD") to use TLS1.2 >> and SHA2 ciphers, and otherwise to use TLS1.0? > >The biggest security issue with TLS 1.0/1.1 is less the use of sha1 and >more the use of CBC+hmac in a very wacky combination. >From what I'm aware, the use of SHA1 in HMAC shouldn't affect its >security. Still it's a good idea to avoid sha1 - it just isn't the most >pressing security issue. > >You should definitely require TLS 1.2 and avoid CBC-ciphersuites if >possible if you want high security. The AEAD-ciphersuites (i.e. >everything with AES-GCM) in TLS 1.2 are the thing you want to use. > >The issue with libraries not supporting TLS 1.2 isn't as severe as it >may seem. OpenSSL supports TLS 1.2 since a while, GnuTLS also does, >the MS-provided ssl libs since Windows 7 as well. nss has no support >yet, but there are experimental patches and it's expected to come quite >soon. So unless you have a very strong need to use outdated versions of >crypto libraries (which is generally not a good idea), it shouldn't be >much of an issue. > >cu, >--=20 >Hanno B=F6ck mail/jabber: hanno@hboeck.de >GPG: BBB51E42 http://www.hboeck.de/ From mrex@sap.com Tue May 21 06:47:54 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D912B21F936E for ; Tue, 21 May 2013 06:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pkJkrRKvymA for ; Tue, 21 May 2013 06:47:50 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1508321F93BD for ; Tue, 21 May 2013 06:47:44 -0700 (PDT) Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r4LDlgeo005162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 May 2013 15:47:42 +0200 (MEST) In-Reply-To: To: Ulrich Herberg Date: Tue, 21 May 2013 15:47:42 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130521134742.4B1371A759@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS1.2 vs TLS1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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, 21 May 2013 13:47:55 -0000 Ulrich Herberg wrote: > > I am participating in another SDO on a standard for automated Demand > Response, called OpenADR (www.openadr.org), an application for the > smart grid. The application is basically a web service, exchanging XML > over HTTP over public networks, and using TLS (with RSA and ECDSA / > SHA1 ciphers for TLS 1.0 and SHA2 for TLS1.2). Currently, the draft > allows for TLS1.0 and 1.1, but recommends using 1.2 (and requires > vendors to provide a migration plan in case TLS1.0 is obsoleted). > TLS1.0 and 1.1 RFCs have been obsoleted by the IETF; but I am not sure > about the best current practice. Please ignore the "obsolete" tagging on rfc2246 and rfc4346, they're formally provable clerical errors. The IETF "obsoleted" tag is about documents obsoleting each other, and that has not happened. > > Is it absolutely discouraged to use them? Just the opposite. TLSv1.0 and TLSv1.1 are still perfectly fine for use, and TLSv1.2 itself has a number of open problems, beside a poor track record of backwards interop. The alleged (confidentiality) problems that have been demonstrated so far are about design-flawed communication peers that require an attacker to be able to insert data into the beginning of the TLS-protected communication an repeat the request a few thousand times (or more) in order to perform plaintext recovery on allegedley confidential data that the attacked communication peer willingly inserted into the same TLS channel following the data provided by the attacker. This problem primarily affects Web Browsers, which essentially are huge security design-flaws by themselves, and to some extent VPNs that multiplex data from different sources over a single TLS-protected communication channel. Datagram TLS (DTLS) is another can of worms, because it has an unreasonable requirement to ignore unlimited amounts of MAC-failing DTLS records on a DTLS connection, but that is a defect from which the stream-oriented regular TLS protocols do not suffer. -Martin From Kenny.Paterson@rhul.ac.uk Tue May 21 07:02:22 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166D121F8F0E for ; Tue, 21 May 2013 07:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjfkRKy1cPNk for ; Tue, 21 May 2013 07:02:14 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id B36AD21F9768 for ; Tue, 21 May 2013 07:02:12 -0700 (PDT) Received: from mail140-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 May 2013 14:02:11 +0000 Received: from mail140-va3 (localhost [127.0.0.1]) by mail140-va3-R.bigfish.com (Postfix) with ESMTP id 70AC5E00B0 for ; Tue, 21 May 2013 14:02:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:134.219.208.107; KIP:(null); UIP:(null); IPV:NLI; H:EXCH-HUB01.cc.rhul.local; RD:exch-hub01.rhul.ac.uk; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz98dIzz1f42h1ee6h1de0h1d18h1fdah1202h1e76h1d1ah1d2ah1fc6hzzz2dh2a8h683h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1d0ch1d2eh1d3fh1155h) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.248.133; KIP:(null); UIP:(null); (null); H:AMXPRD0310HT002.eurprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail140-va3 (localhost.localdomain [127.0.0.1]) by mail140-va3 (MessageSwitch) id 1369144925755972_1670; Tue, 21 May 2013 14:02:05 +0000 (UTC) Received: from VA3EHSMHS032.bigfish.com (unknown [10.7.14.245]) by mail140-va3.bigfish.com (Postfix) with ESMTP id 81AC7160069 for ; Tue, 21 May 2013 14:02:05 +0000 (UTC) Received: from EXCH-HUB01.cc.rhul.local (134.219.208.107) by VA3EHSMHS032.bigfish.com (10.7.99.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 May 2013 14:02:02 +0000 Received: from ch1outboundpool.messaging.microsoft.com (134.219.208.67) by hybrid.rhul.ac.uk (134.219.208.107) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 21 May 2013 15:02:00 +0100 Received: from mail11-ch1-R.bigfish.com (10.43.68.233) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 May 2013 14:01:59 +0000 Received: from mail11-ch1 (localhost [127.0.0.1]) by mail11-ch1-R.bigfish.com (Postfix) with ESMTP id D560BA0DF9 for ; Tue, 21 May 2013 14:01:59 +0000 (UTC) Received: from mail11-ch1 (localhost.localdomain [127.0.0.1]) by mail11-ch1 (MessageSwitch) id 1369144873863106_3813; Tue, 21 May 2013 14:01:13 +0000 (UTC) Received: from CH1EHSMHS015.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.235]) by mail11-ch1.bigfish.com (Postfix) with ESMTP id CFFE73C0049; Tue, 21 May 2013 14:01:13 +0000 (UTC) Received: from AMXPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.133) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 May 2013 14:01:12 +0000 Received: from AMXPRD0310MB377.eurprd03.prod.outlook.com ([169.254.2.223]) by AMXPRD0310HT002.eurprd03.prod.outlook.com ([10.255.55.37]) with mapi id 14.16.0311.000; Tue, 21 May 2013 14:01:12 +0000 From: "Paterson, Kenny" To: "tls@ietf.org" Thread-Topic: [TLS] TLS1.2 vs TLS1.0 Thread-Index: AQHOVZuG72FMFJCqDE20fa/zDrAuEJkPqFAAgAADxYA= Date: Tue, 21 May 2013 14:01:11 +0000 Message-ID: <662E9209-1BE8-4403-BD6F-F502E0DDAC5B@rhul.ac.uk> References: <20130521134742.4B1371A759@ld9781.wdf.sap.corp> In-Reply-To: <20130521134742.4B1371A759@ld9781.wdf.sap.corp> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.55.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <424B7B79E5320A42891542180CC5F995@eurprd03.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%36694$Dn%IETF.ORG$RO%2$TLS%5$FQDN%hybrid.rhul.ac.uk$TlsDn%hybrid.rhul.ac.uk X-FOPE-CONNECTOR: Id%36694$Dn%SAP.COM$RO%2$TLS%5$FQDN%hybrid.rhul.ac.uk$TlsDn%hybrid.rhul.ac.uk X-FOPE-CONNECTOR: Id%36694$Dn%HERBERG.NAME$RO%2$TLS%5$FQDN%hybrid.rhul.ac.uk$TlsDn%hybrid.rhul.ac.uk X-OriginatorOrg: rhul.ac.uk Subject: Re: [TLS] TLS1.2 vs TLS1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 14:02:22 -0000 Hi On 21 May 2013, at 14:47, Martin Rex wrote: > The alleged (confidentiality) problems that have been demonstrated so far > are about design-flawed communication peers that require an attacker > to be able to insert data into the beginning of the TLS-protected > communication an repeat the request a few thousand times (or more) > in order to perform plaintext recovery on allegedley confidential > data that the attacked communication peer willingly inserted into > the same TLS channel following the data provided by the attacker. This is an incorrect representation of the known attacks on confidentiality= (as I understand them, at least). - The attacker-injected data does not have to be at the start of the TLS-pr= otected communication. - The peer-inserted data does not have to follow the attacker-provided data= . > Datagram TLS (DTLS) is another can of worms, because it has an unreasonab= le > requirement to ignore unlimited amounts of MAC-failing DTLS records on a > DTLS connection, but that is a defect from which the stream-oriented > regular TLS protocols do not suffer. True. Though the spec for DTLS does allow DTLS implementations to terminate= a connection in the event of errors.=20 It's just that most (all?) implementations don't. Cheers! Kenny= From mrex@sap.com Tue May 21 07:37:22 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7542021F9833 for ; Tue, 21 May 2013 07:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLZrdy7PGQes for ; Tue, 21 May 2013 07:37:14 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 08E3121F97D6 for ; Tue, 21 May 2013 07:37:13 -0700 (PDT) Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r4LEbAVh028327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 May 2013 16:37:10 +0200 (MEST) In-Reply-To: <662E9209-1BE8-4403-BD6F-F502E0DDAC5B@rhul.ac.uk> To: "Paterson, Kenny" Date: Tue, 21 May 2013 16:37:10 +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: <20130521143710.5B3E21A75A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.2 vs TLS1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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, 21 May 2013 14:37:22 -0000 Paterson, Kenny wrote: > Hi > > On 21 May 2013, at 14:47, Martin Rex wrote: > > > The alleged (confidentiality) problems that have been demonstrated so far > > are about design-flawed communication peers that require an attacker > > to be able to insert data into the beginning of the TLS-protected > > communication an repeat the request a few thousand times (or more) > > in order to perform plaintext recovery on allegedley confidential > > data that the attacked communication peer willingly inserted into > > the same TLS channel following the data provided by the attacker. > > This is an incorrect representation of the known attacks on > confidentiality (as I understand them, at least). > > - The attacker-injected data does not have to be at the start of the > TLS-protected communication. > - The peer-inserted data does not have to follow the attacker-provided data. True. Technically, attacks (on CBC) become possible whenever the attacker can force data of his choice to be processed along with a block of unknown data under the same block cipher key and observe differences in the resulting behaviour. Being able to insert plaintext before the unknown data can be used to attack the senders encryption oracle (what BEAST did), which may allow blackholing the resulting output in order to avoid alarm bells going off on the peer (original receiver). For the more generic attacks on CBC-Padding using the receivers decryption oracle it would be sufficient if the attacker can entice the client to repeat essentially the same request (i.e. with the same interesting data at a known or predictable position) sufficiently often (typically a few thousand to a few million times), then rearranging the network data that the receiver is going to process will be sufficient. The large number of failed reciever-side processing might eventually set off receiver-side alarm-bells. > > > Datagram TLS (DTLS) is another can of worms, because it has an unreasonable > > requirement to ignore unlimited amounts of MAC-failing DTLS records on a > > DTLS connection, but that is a defect from which the stream-oriented > > regular TLS protocols do not suffer. > > True. Though the spec for DTLS does allow DTLS implementations to > terminate a connection in the event of errors. > > It's just that most (all?) implementations don't. Now that you mention it, I hadn't noticed that DTLS gives actual two _different_ guidances (MAY abort on MAC error and MUST discard records with MAC error are mutually exclusive) http://tools.ietf.org/html/rfc4347#section-4.1.2.1 4.1.2.1 MAC (last paragraph): In general, DTLS implementations SHOULD silently discard data with bad MACs. If a DTLS implementation chooses to generate an alert when it receives a message with an invalid MAC, it MUST generate bad_record_mac alert with level fatal and terminate its connection state. http://tools.ietf.org/html/rfc4347#section-4.1.2.5 4.1.2.5 Anti-replay (last paragraph): If the received record falls within the window and is new, or if the packet is to the right of the window, then the receiver proceeds to MAC verification. If the MAC validation fails, the receiver MUST discard the received record as invalid. The receive window is updated only if the MAC verification succeeds. -Martin From ulrich@herberg.name Tue May 21 09:26:01 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A2821F985F for ; Tue, 21 May 2013 09:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kYBJB+ynsCt for ; Tue, 21 May 2013 09:26:00 -0700 (PDT) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id AB90421F9867 for ; Tue, 21 May 2013 09:25:59 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id jw11so630864veb.14 for ; Tue, 21 May 2013 09:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3cdgOK8+oRQIUCWo60la/OoG1CnsG7Q1DhKB3recBG0=; b=Cbpkhj+W5p1C21bCxRe9ASyHhLOfuHMKqPVcy8BQfbUIXwbO81M8pX1QskJv2Fjwof yXTGoyqVntIGF7oAjfQKTHXDVzmqMghqDNijmmzunJX23nEbUDMS8ctHXeGh1qc7yjcp vEthy7kKtGBGM0rjVzDfLXmHiW/RQagzIYDME= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=3cdgOK8+oRQIUCWo60la/OoG1CnsG7Q1DhKB3recBG0=; b=eqas5L/xLhdg0ddhFMoe5iKZfLfYYEv1bLICF5/Uznk5ldf2KI99ignb/C5JkApF7j 9JvH/WXlLIcXnfz5FwrIN4JL2UzskGZ44MQay5QE3XQLvBfsH/MlSpmwjiGmK+ZykLjF dUrMnl9+l7q4iQIB+SKvbujY221KPqmtsHCH+7i+wsuxyjKwUNUFUPp5Qdv+9B+qXttm TAAXDWgKMhRJsM80aeSZSP0TWySbirQ1+LlIpP485egPO9F2dzsJb+B/s3jlvxm3UK4L Pg9kWJdn42wvFp24x36kBHoAOaNnXbpXyggHgtN6JgshB8PY8vlMw9RbbLy22tk1fiCl AWCA== MIME-Version: 1.0 X-Received: by 10.52.233.34 with SMTP id tt2mr1019896vdc.70.1369153553314; Tue, 21 May 2013 09:25:53 -0700 (PDT) Received: by 10.220.195.134 with HTTP; Tue, 21 May 2013 09:25:53 -0700 (PDT) In-Reply-To: <20130521143710.5B3E21A75A@ld9781.wdf.sap.corp> References: <662E9209-1BE8-4403-BD6F-F502E0DDAC5B@rhul.ac.uk> <20130521143710.5B3E21A75A@ld9781.wdf.sap.corp> Date: Tue, 21 May 2013 09:25:53 -0700 Message-ID: From: Ulrich Herberg To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkPOeHeat1EM5nuJsaT8Otez0Kez0w4yAlV+aQUiko9OrElP8Fqp3XEQqiCvoIv4baZHflV Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.2 vs TLS1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 16:26:01 -0000 Thank you very much for the comments so far. This is a useful discussion, and I pointed the OpenADR alliance to this conversation. Ulrich On Tue, May 21, 2013 at 7:37 AM, Martin Rex wrote: > Paterson, Kenny wrote: >> Hi >> >> On 21 May 2013, at 14:47, Martin Rex wrote: >> >> > The alleged (confidentiality) problems that have been demonstrated so far >> > are about design-flawed communication peers that require an attacker >> > to be able to insert data into the beginning of the TLS-protected >> > communication an repeat the request a few thousand times (or more) >> > in order to perform plaintext recovery on allegedley confidential >> > data that the attacked communication peer willingly inserted into >> > the same TLS channel following the data provided by the attacker. >> >> This is an incorrect representation of the known attacks on >> confidentiality (as I understand them, at least). >> >> - The attacker-injected data does not have to be at the start of the >> TLS-protected communication. >> - The peer-inserted data does not have to follow the attacker-provided data. > > True. Technically, attacks (on CBC) become possible whenever the attacker > can force data of his choice to be processed along with a block of unknown > data under the same block cipher key and observe differences in the > resulting behaviour. > > Being able to insert plaintext before the unknown data can be used to > attack the senders encryption oracle (what BEAST did), which may allow > blackholing the resulting output in order to avoid alarm bells > going off on the peer (original receiver). > > For the more generic attacks on CBC-Padding using the receivers decryption > oracle it would be sufficient if the attacker can entice the client to > repeat essentially the same request (i.e. with the same interesting data > at a known or predictable position) sufficiently often (typically a few > thousand to a few million times), then rearranging the network data > that the receiver is going to process will be sufficient. The large > number of failed reciever-side processing might eventually set off > receiver-side alarm-bells. > > >> >> > Datagram TLS (DTLS) is another can of worms, because it has an unreasonable >> > requirement to ignore unlimited amounts of MAC-failing DTLS records on a >> > DTLS connection, but that is a defect from which the stream-oriented >> > regular TLS protocols do not suffer. >> >> True. Though the spec for DTLS does allow DTLS implementations to >> terminate a connection in the event of errors. >> >> It's just that most (all?) implementations don't. > > > Now that you mention it, I hadn't noticed that DTLS gives actual two > _different_ guidances (MAY abort on MAC error and MUST discard records > with MAC error are mutually exclusive) > > http://tools.ietf.org/html/rfc4347#section-4.1.2.1 > > 4.1.2.1 MAC (last paragraph): > > In general, DTLS implementations SHOULD silently discard data with > bad MACs. If a DTLS implementation chooses to generate an alert when > it receives a message with an invalid MAC, it MUST generate > bad_record_mac alert with level fatal and terminate its connection > state. > > http://tools.ietf.org/html/rfc4347#section-4.1.2.5 > > 4.1.2.5 Anti-replay (last paragraph): > > If the received record falls within the window and is new, or if the > packet is to the right of the window, then the receiver proceeds to > MAC verification. If the MAC validation fails, the receiver MUST > discard the received record as invalid. The receive window is > updated only if the MAC verification succeeds. > > > -Martin From X.Wu@F5.com Tue May 21 10:16:32 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1AB21F97DE for ; Tue, 21 May 2013 10:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GG4k+GleTL+L for ; Tue, 21 May 2013 10:16:28 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED1E21F92A5 for ; Tue, 21 May 2013 10:16:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=X.Wu@f5.com; q=dns/txt; s=seattle; t=1369156588; x=1400692588; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=01GZ6y5NAMa3DMqSqvWXvqA9wfe5IgOCnTuBtT9Ovvs=; b=p04l9CdHD7TV6cjZ4vWbQgV7ofWfsY0AR/5f/jzoeNjcjXCdeAdHPSql zx7EtdvD8hiQS4djn3406TlXJ4/AbWd+nnWAVK35WhSIIvPHNEclBd8Uq lF7qHOWm9KrD0wt6LA6KEyguLjPQnrVGxQ/2mmHoUdDVxdy6d2WSeDCg4 4=; X-IronPort-AV: E=Sophos;i="4.87,715,1363132800"; d="scan'208";a="70381951" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.240]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 21 May 2013 17:16:22 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS03.olympus.F5Net.com ([::1]) with mapi id 14.03.0123.003; Tue, 21 May 2013 10:16:21 -0700 From: Xiaoyong Wu To: "Paterson, Kenny" , "tls@ietf.org" Thread-Topic: [TLS] TLS1.2 vs TLS1.0 Thread-Index: AQHOVZuG72FMFJCqDE20fa/zDrAuEJkPqFAAgAADxYCAADS2oA== Date: Tue, 21 May 2013 17:16:20 +0000 Message-ID: References: <20130521134742.4B1371A759@ld9781.wdf.sap.corp> <662E9209-1BE8-4403-BD6F-F502E0DDAC5B@rhul.ac.uk> In-Reply-To: <662E9209-1BE8-4403-BD6F-F502E0DDAC5B@rhul.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.200] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS1.2 vs TLS1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 17:16:32 -0000 > True. Though the spec for DTLS does allow DTLS implementations to > terminate a connection in the event of errors. > > It's just that most (all?) implementations don't. > >From a practical point of view, terminating on MAC error is prone to a simp= le attack, especially on IPv4 network. An attacker would only need to forge= a UDP packet to either the client/server to get the connection terminated. -Xiaoyong > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > Paterson, Kenny > Sent: Tuesday, May 21, 2013 7:01 AM > To: tls@ietf.org > Subject: Re: [TLS] TLS1.2 vs TLS1.0 >=20 > Hi >=20 > On 21 May 2013, at 14:47, Martin Rex wrote: >=20 > > The alleged (confidentiality) problems that have been demonstrated so > > far are about design-flawed communication peers that require an > > attacker to be able to insert data into the beginning of the > > TLS-protected communication an repeat the request a few thousand times > > (or more) in order to perform plaintext recovery on allegedley > > confidential data that the attacked communication peer willingly > > inserted into the same TLS channel following the data provided by the > attacker. >=20 > This is an incorrect representation of the known attacks on confidentiali= ty (as > I understand them, at least). >=20 > - The attacker-injected data does not have to be at the start of the TLS- > protected communication. > - The peer-inserted data does not have to follow the attacker-provided da= ta. >=20 > > Datagram TLS (DTLS) is another can of worms, because it has an > > unreasonable requirement to ignore unlimited amounts of MAC-failing > > DTLS records on a DTLS connection, but that is a defect from which the > > stream-oriented regular TLS protocols do not suffer. >=20 > True. Though the spec for DTLS does allow DTLS implementations to > terminate a connection in the event of errors. >=20 > It's just that most (all?) implementations don't. >=20 > Cheers! >=20 > Kenny >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From ekr@rtfm.com Tue May 21 15:43:17 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1970A21F8F0C for ; Tue, 21 May 2013 15:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.431 X-Spam-Level: X-Spam-Status: No, score=-99.431 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jv-mKseAHzKi for ; Tue, 21 May 2013 15:43:13 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 888921F0D23 for ; Tue, 21 May 2013 15:43:08 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id z1so716832qcx.3 for ; Tue, 21 May 2013 15:43:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=3dIxBRNiYIAvaWRGOHUbn7VEA5ReKBz2pdXoFSHHkZw=; b=gW9n4yFRv5HXbIvXV6vihS/+qAWmIW29XOunsGcYl95Rp4OQJU2cJYd5JKeCB5l/Ww d4kDzBYeDjbZstsgZDTskcrf5c3fBkNk3sFvfWd8qVZcR4ZcFGMq+dRzfEpbphPxDzZj oSFDQafiTwrxJPr0ah2PoeiPdxjib3PZkJZ5PraGG3NPENm6UwKylT1wDKCwwgozx4+4 sjOaEGqfz5I71RYtufJkn9ESTzVbIWw5vzr8LC/CjrtgBwz4JQ+BgmjkBhUozr7rQqDV 0a68ulX0zRqtRdkRx79CthX1XnXxkqls5T0AawOfcS1+4QHrMii9Qynvo/Hh1mO1tEI1 XoVA== X-Received: by 10.224.164.205 with SMTP id f13mr4579187qay.16.1369176187744; Tue, 21 May 2013 15:43:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.52.33 with HTTP; Tue, 21 May 2013 15:42:27 -0700 (PDT) X-Originating-IP: [203.69.99.17] In-Reply-To: <20130521143710.5B3E21A75A@ld9781.wdf.sap.corp> References: <662E9209-1BE8-4403-BD6F-F502E0DDAC5B@rhul.ac.uk> <20130521143710.5B3E21A75A@ld9781.wdf.sap.corp> From: Eric Rescorla Date: Tue, 21 May 2013 15:42:27 -0700 Message-ID: To: mrex@sap.com Content-Type: multipart/alternative; boundary=089e0158bac24e44cd04dd422cd5 X-Gm-Message-State: ALoCoQnp5TXErLZQU+FbgZJ5pwowAV28OmsunLnL036SWMfdq4cqHybOtVsaGLJMdH07mza16+7B Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.2 vs TLS1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 22:43:17 -0000 --089e0158bac24e44cd04dd422cd5 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 21, 2013 at 7:37 AM, Martin Rex wrote: > Paterson, Kenny wrote: > > Hi > > > > On 21 May 2013, at 14:47, Martin Rex wrote: > > > Datagram TLS (DTLS) is another can of worms, because it has an > unreasonable > > > requirement to ignore unlimited amounts of MAC-failing DTLS records on > a > > > DTLS connection, but that is a defect from which the stream-oriented > > > regular TLS protocols do not suffer. > > > > True. Though the spec for DTLS does allow DTLS implementations to > > terminate a connection in the event of errors. > > > > It's just that most (all?) implementations don't. > > > Now that you mention it, I hadn't noticed that DTLS gives actual two > _different_ guidances (MAY abort on MAC error and MUST discard records > with MAC error are mutually exclusive) > > http://tools.ietf.org/html/rfc4347#section-4.1.2.1 > > 4.1.2.1 MAC (last paragraph): > > In general, DTLS implementations SHOULD silently discard data with > bad MACs. If a DTLS implementation chooses to generate an alert when > it receives a message with an invalid MAC, it MUST generate > bad_record_mac alert with level fatal and terminate its connection > state. > > http://tools.ietf.org/html/rfc4347#section-4.1.2.5 > > 4.1.2.5 Anti-replay (last paragraph): > > If the received record falls within the window and is new, or if the > packet is to the right of the window, then the receiver proceeds to > MAC verification. If the MAC validation fails, the receiver MUST > discard the received record as invalid. The receive window is > updated only if the MAC verification succeeds. > Hmm.... I'm not sure these are contradictory. If you get a packet with a MAC error you MUST discard the packet (i.e., not process it.) You may either *silently* discard it (i.e.., proceed as if you had not received it) or terminate the connection with an alert. -Ekr --089e0158bac24e44cd04dd422cd5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, May 21, 2013 at 7:37 AM, Martin Rex <<= a href=3D"mailto:mrex@sap.com" target=3D"_blank">mrex@sap.com> wrote:
Paterson, Kenny wrote:
> Hi
>
> On 21 May 2013, at 14:47, Martin Rex wrote:
> > Datagram TLS (DTLS) is another can of worms, because it has an un= reasonable
> > requirement to ignore unlimited amounts of MAC-failing DTLS recor= ds on a
> > DTLS connection, but that is a defect from which the stream-orien= ted
> > regular TLS protocols do not suffer.
>
> True. Though the spec for DTLS does allow DTLS implementations to
> terminate a connection in the event of errors.
>
> It's just that most (all?) implementations don't.


Now that you mention it, I hadn't noticed that DTLS gives actual = two
_different_ guidances (MAY abort on MAC error and MUST discard records
with MAC error are mutually exclusive)

http://tools.ietf.org/html/rfc4347#section-4.1.2.1

=A0 =A04.1.2.1 =A0MAC =A0(last paragraph):

=A0 =A0In general, DTLS implementations SHOULD silently discard data with =A0 =A0bad MACs. =A0If a DTLS implementation chooses to generate an alert w= hen
=A0 =A0it receives a message with an invalid MAC, it MUST generate
=A0 =A0bad_record_mac alert with level fatal and terminate its connection =A0 =A0state.

http://tools.ietf.org/html/rfc4347#section-4.1.2.5

=A0 =A04.1.2.5 =A0Anti-replay =A0(last paragraph):

=A0 =A0If the received record falls within the window and is new, or if the=
=A0 =A0packet is to the right of the window, then the receiver proceeds to<= br> =A0 =A0MAC verification. =A0If the MAC validation fails, the receiver MUST<= br> =A0 =A0discard the received record as invalid. =A0The receive window is
=A0 =A0updated only if the MAC verification succeeds.
=
Hmm.... I'm not sure these are contradictory.

If you get a packet with a MAC error you M= UST discard the packet (i.e.,
not process it.) You may either *silently* discard it (i.e.., pr= oceed as if
you had not received it) or terminate the conne= ction with an alert.

-Ekr


--089e0158bac24e44cd04dd422cd5-- From ulrich@herberg.name Tue May 21 16:45:21 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE71911E80BA for ; Tue, 21 May 2013 16:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcJ-MjQqHums for ; Tue, 21 May 2013 16:45:15 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C7E0611E80A4 for ; Tue, 21 May 2013 16:45:15 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id hf12so885858vcb.31 for ; Tue, 21 May 2013 16:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MjsdBUX6AbLW7mc4UVviF09M7V5ckcyI1GKGNUYU8Tg=; b=RJlh8AoBQFHFri/KbejebyZrmyHy4MX9Z2xwRSdwCVRZGp0oxSgrvOUL0nvRsHdUcx ckJDaS397qVfCDwzqTKOdBXqG1mz7vOLmwUPC4b/TCe0sM4HQBK3VIdHqFqFJNNzEPAk D2VdGHWxCnu5fSDq1jkoInj1hKh3CcQJ0ZiDE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=MjsdBUX6AbLW7mc4UVviF09M7V5ckcyI1GKGNUYU8Tg=; b=fORYR8DJoJHiijC6ixipT77JyEvW9cys79U+lxUUQzDvTqF5h2ATT2W1dJzIdxbecS AKIOZnAA5oyh/SVz21hm51FA1hx3LMxwgwqxS+bko196GhnglZrz063ntA5TyUIDZdF3 NcU/3orC9JFj4o0NJGKxog4iJ/wFCldGGMITALE+oBBm7Mj80AnNIK8IOC7Xbzv5dkUw 5XfEq4o1IHSzmXsZR9+E91jJs60fRUXU2cN+4US81R6AjaRXF2eJkMdz9OGUxeNrzmRd uXQoQFzwKOtWwyxC6DNB5ZCqEo2znFfiOXz579CHRf9p7ei9Eg+1SjPHEaq0BYyPqrtQ Mjug== MIME-Version: 1.0 X-Received: by 10.52.17.81 with SMTP id m17mr1557434vdd.18.1369179914699; Tue, 21 May 2013 16:45:14 -0700 (PDT) Received: by 10.220.195.134 with HTTP; Tue, 21 May 2013 16:45:14 -0700 (PDT) In-Reply-To: <20130521102647.402e695e@melee> References: <20130521102647.402e695e@melee> Date: Tue, 21 May 2013 16:45:14 -0700 Message-ID: From: Ulrich Herberg To: =?ISO-8859-1?Q?Hanno_B=F6ck?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQntb7GUcjS449kz/tXIP2axkbIxaFGoXk5Hi6VGrkBMtTsz0hdxKtb4I5gT6lurds2HLCEL Cc: tls@ietf.org Subject: Re: [TLS] TLS1.2 vs TLS1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 23:45:21 -0000 Hi Hanno, thank you for the recommendations. Please see below: On Tue, May 21, 2013 at 1:26 AM, Hanno B=F6ck wrote: [...] > The biggest security issue with TLS 1.0/1.1 is less the use of sha1 and > more the use of CBC+hmac in a very wacky combination. > From what I'm aware, the use of SHA1 in HMAC shouldn't affect its > security. Still it's a good idea to avoid sha1 - it just isn't the most > pressing security issue. > > You should definitely require TLS 1.2 and avoid CBC-ciphersuites if > possible if you want high security. The AEAD-ciphersuites (i.e. > everything with AES-GCM) in TLS 1.2 are the thing you want to use. I see. Are the CBC ciphersuites considered unsecure? I have found the following paper that seems to claim that there are possible attacks: http://www.isg.rhul.ac.uk/tls/TLStiming.pdf And a draft with an alternative (claiming that AEAD has performance issues)= : http://tools.ietf.org/html/draft-josefsson-salsa20-tls-02 Was that discussed in this WG? Best regards Ulrich > > The issue with libraries not supporting TLS 1.2 isn't as severe as it > may seem. OpenSSL supports TLS 1.2 since a while, GnuTLS also does, > the MS-provided ssl libs since Windows 7 as well. nss has no support > yet, but there are experimental patches and it's expected to come quite > soon. So unless you have a very strong need to use outdated versions of > crypto libraries (which is generally not a good idea), it shouldn't be > much of an issue. > > cu, > -- > Hanno B=F6ck mail/jabber: hanno@hboeck.de > GPG: BBB51E42 http://www.hboeck.de/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From ulrich@herberg.name Tue May 21 17:13:28 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE7221F937A for ; Tue, 21 May 2013 17:13:28 -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=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pI7eUn5p9xQk for ; Tue, 21 May 2013 17:13:27 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 05D4721F9374 for ; Tue, 21 May 2013 17:13:26 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id m1so1001011ves.30 for ; Tue, 21 May 2013 17:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+Z4pt2ap9HVjp00SDBRbh0haOiKaGjeiZM2OU4dvYA4=; b=qBNMSgtS6dfSgF7aAhCwJsRsq/TVs3+Up0XOgqefUJeUaulzs/nowazSAGkYR6ZruC I4DR/Hcl2ytmQI9CgGYLtk2gsswiUjSy0fOkjvat5Nvw8j3s2Hc1c+ZHGg/jBX+OZTvN wm0AG1x/odbTjnTKsa2RbwR6qS54KyUaO7+Sg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=+Z4pt2ap9HVjp00SDBRbh0haOiKaGjeiZM2OU4dvYA4=; b=TXvqN00gRKIC3bGph7f8PEEDAI/zqhBKT18i1aY5BgwTwmsfjbz7ahdcqo6/Bnv76S jopU4oCbtn7dOJ8Nv4KWLZCliwTEseuEa/rfhHZsmvB01vOCuIdIw307s4QWucWweFUJ Numt+8XwvJTsn8B32fkN+khr2lZAOuCa4IVUG0x9wBKDvkKyHF0wIVhP2CKKqyOYN2JC +Psz5DbM6DYU5P7eiWpvT3t6nVwuLdDoI2Sx1AkVBO6qOA3QEK/ll9YE5VUQuItWv9ya DYXdqF5Lito5NRf9RSz1vR6NPlS2UjJF78SgM6o9pU08GXk0NMR6Amea6zI8reSwoWMN ryCA== MIME-Version: 1.0 X-Received: by 10.52.65.238 with SMTP id a14mr1436189vdt.24.1369181605988; Tue, 21 May 2013 17:13:25 -0700 (PDT) Received: by 10.220.195.134 with HTTP; Tue, 21 May 2013 17:13:25 -0700 (PDT) In-Reply-To: References: <20130521102647.402e695e@melee> Date: Tue, 21 May 2013 17:13:25 -0700 Message-ID: From: Ulrich Herberg To: =?ISO-8859-1?Q?Hanno_B=F6ck?= Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk+E/h0cNncY9ba9clX1/KP7RrgDIDf070mIF4rF5hOvzt0oZaKgzS2yHlyAdriMITpyYux Cc: tls@ietf.org Subject: Re: [TLS] TLS1.2 vs TLS1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 00:13:28 -0000 P.S. I see that the draft I mentioned has been discussed on the mailing lis= t. Is there any recommendation in which cases the use of CBC ciphersuites would actually cause any (practical) risk so that we can evaluate whether we should use alternatives to CBC like AEAD? Is current support for AEAD cipher suites in common TLS1.2 implementations as good as for CBC cipher suites? Is there any drawback for using AEAD ciphers? Is there any sort of best practice or similar document where a user designing an application can make a choice which TLS version / cipher suites to use? Currently, the OpenADR protocol mandates to use: for TLS1.0 (only if a device does not support higher versions of TLS): ECC =96 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA RSA =96 TLS_RSA_WITH_AES_128_CBC_SHA for TLS1.2 (default): ECC =96 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 RSA =96 TLS_RSA_WITH_AES_128_CBC_SHA256 The messages that are exchanged are XML documents within HTTP POST. Thanks Ulrich On Tue, May 21, 2013 at 4:45 PM, Ulrich Herberg wrote= : [...] > I see. Are the CBC ciphersuites considered unsecure? I have found the > following paper that seems to claim that there are possible attacks: > http://www.isg.rhul.ac.uk/tls/TLStiming.pdf > And a draft with an alternative (claiming that AEAD has performance issue= s): > http://tools.ietf.org/html/draft-josefsson-salsa20-tls-02 > > Was that discussed in this WG? > > Best regards > Ulrich > > > >> >> The issue with libraries not supporting TLS 1.2 isn't as severe as it >> may seem. OpenSSL supports TLS 1.2 since a while, GnuTLS also does, >> the MS-provided ssl libs since Windows 7 as well. nss has no support >> yet, but there are experimental patches and it's expected to come quite >> soon. So unless you have a very strong need to use outdated versions of >> crypto libraries (which is generally not a good idea), it shouldn't be >> much of an issue. >> >> cu, >> -- >> Hanno B=F6ck mail/jabber: hanno@hboeck.de >> GPG: BBB51E42 http://www.hboeck.de/ >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> From geoffk@geoffk.org Tue May 21 17:38:29 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A0211E80AD for ; Tue, 21 May 2013 17:38:28 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NK4sZLAdiXbf for ; Tue, 21 May 2013 17:38:23 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id CA30421F9371 for ; Tue, 21 May 2013 17:38:23 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id AC97C33D095; Wed, 22 May 2013 00:38:19 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Ulrich Herberg References: <20130521102647.402e695e@melee> From: Geoffrey Keating Date: 21 May 2013 17:38:19 -0700 In-Reply-To: Message-ID: Lines: 37 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tls@ietf.org Subject: Re: [TLS] TLS1.2 vs TLS1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 00:38:29 -0000 Ulrich Herberg writes: > Is there any recommendation in which cases the use of CBC ciphersuites > would actually cause any (practical) risk so that we can evaluate > whether we should use alternatives to CBC like AEAD? I believe you'd need to very carefully evaluate the entire system you would plan to use the CBC ciphersuites for applicability of known attacks such as: - The issue fixed in TLS 1.1, use of a predictable IV - The timing issue(s) discussed in the "Lucky Thirteen" paper - Information disclosure due to use of compression Each of these may or may not apply to a particular system or implementation. For example, timing issues can be a big problem if you have small embedded devices---or no problem at all because communication always happens at particular scheduled times and the messages are prepared earlier. > Is current support for AEAD cipher suites in common TLS1.2 > implementations as good as for CBC cipher suites? No, alas. But it's pretty good and getting better. > Is there any drawback for using AEAD ciphers? Not that I know of. > Is there any sort of best practice or similar document where > a user designing an application can make a choice which TLS version / > cipher suites to use? I think any situation that forces you to use earlier versions of TLS or cipher suites that aren't AEAD is pushing you out of "best practice" and into the jungle of "whatever needs to happen to make this work". From mrex@sap.com Wed May 22 15:52:38 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E9C11E813A for ; Wed, 22 May 2013 15:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ahv-pZgXiJQL for ; Wed, 22 May 2013 15:52:34 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id A740611E814B for ; Wed, 22 May 2013 15:52:33 -0700 (PDT) Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r4MMqQhI007962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 May 2013 00:52:26 +0200 (MEST) In-Reply-To: To: Geoffrey Keating Date: Thu, 23 May 2013 00:52:25 +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: <20130522225225.F2AD01A76F@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS1.2 vs TLS1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 22:52:38 -0000 Geoffrey Keating wrote: > Ulrich Herberg writes: > > > > Is there any recommendation in which cases the use of CBC ciphersuites > > would actually cause any (practical) risk so that we can evaluate > > whether we should use alternatives to CBC like AEAD? > > I believe you'd need to very carefully evaluate the entire system you > would plan to use the CBC ciphersuites for applicability of known > attacks such as: > > - The issue fixed in TLS 1.1, use of a predictable IV Which matters only when you let the attacker provide plaintext that is encrypted along with information that the attacker is not supposed to know, and let the attacker retry this guessing game with the same unknown information often enough. Can be mitigated with 1/(n-1) record splitting. See e.g. http://www.educatedguesswork.org/comsec/ > > - The timing issue(s) discussed in the "Lucky Thirteen" paper ... which affects CBC cipher suites in TLSv1.1 and TLSv1.2 as well. and was previously dicussed _and_ solved in Serge Vaudenay's 2001 paper, however for some mysterious reason, Serge's recommendation didn't make it into the 2006 TLSv1.1 or 2008 TLSv1.2 updates... (section 6.5) http://infoscience.epfl.ch/record/52417/files/IC_TECH_REPORT_200150.pdf > > - Information disclosure due to use of compression Which affects *ALL* cipher suites (including AEAD) in all TLS protocol versions, and was pointed out clearly in the Wagner&Schneier 1996 SSLv3.0 Protocol Analysis (Section 3.2): http://www.schneier.com/paper-ssl.html > > Each of these may or may not apply to a particular system or > implementation. For example, timing issues can be a big problem if > you have small embedded devices---or no problem at all because > communication always happens at particular scheduled times and the > messages are prepared earlier. Whether "timing" provides an attack surface depends on several factors. Timing may enable a decryption oracle when either there are variations in processing dependent on low-entropy crypto padding (such as CBC-padding for symmetric block ciphers (Vaudenay) or padding schemes used by assymetric crypto private key operations, e.g. PKCS#1 v1.5 padding for RSA key exchange (Bleichenbacher) as used by TLS. > > > Is current support for AEAD cipher suites in common TLS1.2 > > implementations as good as for CBC cipher suites? > > No, alas. But it's pretty good and getting better. The arbitrary (and totally needless) decision to limit AES-CCM & AES-GCM ciphersuites to TLSv1.2 is significantly slowing its adoption. > > > Is there any drawback for using AEAD ciphers? > > Not that I know of. It should be glaring obvious that the integrity protection will be cryptographically weaker than with any reasonable HMAC scheme (just by comparing the size of the internal state of the algorithms). But it seems to be "good enough" (strong enough) for a number of folks. -Martin From mrex@sap.com Wed May 22 17:51:52 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146AE21F92E7 for ; Wed, 22 May 2013 17:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6geroLwciH69 for ; Wed, 22 May 2013 17:51:47 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8314021F92BB for ; Wed, 22 May 2013 17:51:46 -0700 (PDT) Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r4N0pjbj000520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 May 2013 02:51:45 +0200 (MEST) In-Reply-To: To: Eric Rescorla Date: Thu, 23 May 2013 02:51:45 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130523005145.1C3DC1A76F@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.2 vs TLS1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 00:51:52 -0000 Eric Rescorla wrote: > Martin Rex wrote: > > > > Paterson, Kenny wrote: > > > > > > True. Though the spec for DTLS does allow DTLS implementations to > > > terminate a connection in the event of errors. > > > > > > It's just that most (all?) implementations don't. > > > > Now that you mention it, I hadn't noticed that DTLS gives actual two > > _different_ guidances (MAY abort on MAC error and MUST discard records > > with MAC error are mutually exclusive) > > > > http://tools.ietf.org/html/rfc4347#section-4.1.2.1 > > > > 4.1.2.1 MAC (last paragraph): > > > > In general, DTLS implementations SHOULD silently discard data with > > bad MACs. If a DTLS implementation chooses to generate an alert when > > it receives a message with an invalid MAC, it MUST generate > > bad_record_mac alert with level fatal and terminate its connection > > state. > > > > http://tools.ietf.org/html/rfc4347#section-4.1.2.5 > > > > 4.1.2.5 Anti-replay (last paragraph): > > > > If the received record falls within the window and is new, or if the > > packet is to the right of the window, then the receiver proceeds to > > MAC verification. If the MAC validation fails, the receiver MUST > > discard the received record as invalid. The receive window is > > updated only if the MAC verification succeeds. > > > > Hmm.... I'm not sure these are contradictory. > > If you get a packet with a MAC error you MUST discard the packet (i.e., > not process it.) You may either *silently* discard it (i.e.., proceed as if > you had not received it) or terminate the connection with an alert. Silently discarding it = proceed as if you had not received it non-silently discarding it = log an error and proceed as if you had not not received it Terminating the connection with an alert means "processing it". So yes, there is a contradiction. -Martin From mrex@sap.com Wed May 22 18:20:30 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C0B21F8FBA for ; Wed, 22 May 2013 18:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncwVXRrNcLx7 for ; Wed, 22 May 2013 18:20:25 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7E221F8F1E for ; Wed, 22 May 2013 18:20:23 -0700 (PDT) Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r4N1KM0t000420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 May 2013 03:20:22 +0200 (MEST) In-Reply-To: <20130523005145.1C3DC1A76F@ld9781.wdf.sap.corp> To: mrex@sap.com Date: Thu, 23 May 2013 03:20:22 +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: <20130523012022.76C171A76F@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.2 vs TLS1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 01:20:30 -0000 Martin Rex wrote: > Eric Rescorla wrote: > > Martin Rex wrote: > > > > > > Paterson, Kenny wrote: > > > > > > > > True. Though the spec for DTLS does allow DTLS implementations to > > > > terminate a connection in the event of errors. > > > > > > > > It's just that most (all?) implementations don't. > > > > > > Now that you mention it, I hadn't noticed that DTLS gives actual two > > > _different_ guidances (MAY abort on MAC error and MUST discard records > > > with MAC error are mutually exclusive) > > > > > > http://tools.ietf.org/html/rfc4347#section-4.1.2.1 > > > > > > 4.1.2.1 MAC (last paragraph): > > > > > > In general, DTLS implementations SHOULD silently discard data with > > > bad MACs. If a DTLS implementation chooses to generate an alert when > > > it receives a message with an invalid MAC, it MUST generate > > > bad_record_mac alert with level fatal and terminate its connection > > > state. > > > > > > http://tools.ietf.org/html/rfc4347#section-4.1.2.5 > > > > > > 4.1.2.5 Anti-replay (last paragraph): > > > > > > If the received record falls within the window and is new, or if the > > > packet is to the right of the window, then the receiver proceeds to > > > MAC verification. If the MAC validation fails, the receiver MUST > > > discard the received record as invalid. The receive window is > > > updated only if the MAC verification succeeds. > > > > > > > Hmm.... I'm not sure these are contradictory. > > > > If you get a packet with a MAC error you MUST discard the packet (i.e., > > not process it.) You may either *silently* discard it (i.e.., proceed as if > > you had not received it) or terminate the connection with an alert. > > Silently discarding it = proceed as if you had not received it > > non-silently discarding it = log an error and proceed as if you had not > not received it > > Terminating the connection with an alert means "processing it". > > So yes, there is a contradiction. For comparison, look at the more elaborate discussion in the successor DTLS document: http://tools.ietf.org/html/rfc6347#section-4.1.2.7 4.1.2.7. Handling Invalid Records Unlike TLS, DTLS is resilient in the face of invalid records (e.g., invalid formatting, length, MAC, etc.). In general, invalid records SHOULD be silently discarded, thus preserving the association; however, an error MAY be logged for diagnostic purposes. Implementations which choose to generate an alert instead, MUST generate fatal level alerts to avoid attacks where the attacker repeatedly probes the implementation to see how it responds to various types of error. Where you can see the two variants of discarding ("silently" and logging an error) that preserves the association, and the behaviour "Implementations which choose to generate an alert instead", being explicitly characterized as distinct to discarding. btw. there is another contradiction within rfc4347 section 4.1.2.1 MAC between paragraph 3 and 4 (which is reproduced in rfc6347): http://tools.ietf.org/html/rfc4347#section-4.1.2.1 http://tools.ietf.org/html/rfc6347#section-4.1.2.1 Note that one important difference between DTLS and TLS MAC handling is that in TLS MAC errors must result in connection termination. In DTLS, the receiving implementation MAY simply discard the offending record and continue with the connection. This change is possible because DTLS records are not dependent on each other in the way that TLS records are. In general, DTLS implementations SHOULD silently discard data with bad MACs. If a DTLS implementation chooses to generate an alert when it receives a message with an invalid MAC, it MUST generate bad_record_mac alert with level fatal and terminate its connection state. Paragraph 3 says "MAY simply discard the offending record and continue with the connection", whereas paragraph 4 says "DTLS implementations SHOULD silently discard data with bad MACs.". You can not use two distinct imperatives (MAY and SHOULD) for the very same behaviour, that is a contradiction. You can only use one or the other. Maybe the document (co-)authors should be using the "MAY WISH TO" http://tools.ietf.org/html/rfc6919#section-6 keyword instead of the rfc2119 SHOULD in paragraph 4 of rfc4347 section 4.1.2.1. ;-) There are some folks in the IETF security area (in particular over at PKIX) that feel very strongly about SHOULDs. -Martin From ekr@rtfm.com Wed May 22 18:30:41 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8728011E8182 for ; Wed, 22 May 2013 18:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.525 X-Spam-Level: X-Spam-Status: No, score=-96.525 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, RELAY_IS_220=2.118, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwArZUvEAsa9 for ; Wed, 22 May 2013 18:30:37 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 31BA011E8181 for ; Wed, 22 May 2013 18:30:37 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id hu16so1367545qab.20 for ; Wed, 22 May 2013 18:30:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=WjFUhtqDoc1ocz/48bHQ2yFAwHj7EXyw3k1cz/PSrbs=; b=jtPuTCdKumW5PkGpeYdlF+JNuotzUKfqAKiQZhIUSEcOXPDPOQBMFIiVlh8F0cs8RH TSdidS3+d+cG/BP3xGdPsjZl+e1djMdRsmsAWhqlPshrf5b3jKOY83nGJgxB4mJplQcs MNMH5OKPflZ6B8H2H7rXScQRxb0ySMBDWeK32SQUtj6I/rvPKAQ6fbdb3QvjDorLcZOG eKZsepa0hLI1dcAPkstQW6PhhK5u4eAyw7LZ7BcwoO83oa8d/B85QDNhkfn6vt6wHhfB ZLV04t1oGAcoBweMn30IGFOnRaPg0EJuarOJEVusEPVK/LlvUfdJ+nOWNrDDXtrr4vQ+ 4fyQ== X-Received: by 10.224.201.198 with SMTP id fb6mr9525235qab.68.1369272636567; Wed, 22 May 2013 18:30:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.52.33 with HTTP; Wed, 22 May 2013 18:29:55 -0700 (PDT) X-Originating-IP: [220.136.14.43] In-Reply-To: <20130523005145.1C3DC1A76F@ld9781.wdf.sap.corp> References: <20130523005145.1C3DC1A76F@ld9781.wdf.sap.corp> From: Eric Rescorla Date: Wed, 22 May 2013 18:29:55 -0700 Message-ID: To: mrex@sap.com Content-Type: multipart/alternative; boundary=20cf3005dc481a97f904dd58a135 X-Gm-Message-State: ALoCoQkPQ/uIZXsALECvfBL3mBXQVk6XtAOnzQbyDDUfS/bI31MpdKUs9WtGKu8QYl6EE2KAAQ7J Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.2 vs TLS1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 01:30:41 -0000 --20cf3005dc481a97f904dd58a135 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 22, 2013 at 5:51 PM, Martin Rex wrote: > Eric Rescorla wrote: > > Martin Rex wrote: > > > > > > Paterson, Kenny wrote: > > > > > > > > True. Though the spec for DTLS does allow DTLS implementations to > > > > terminate a connection in the event of errors. > > > > > > > > It's just that most (all?) implementations don't. > > > > > > Now that you mention it, I hadn't noticed that DTLS gives actual two > > > _different_ guidances (MAY abort on MAC error and MUST discard records > > > with MAC error are mutually exclusive) > > > > > > http://tools.ietf.org/html/rfc4347#section-4.1.2.1 > > > > > > 4.1.2.1 MAC (last paragraph): > > > > > > In general, DTLS implementations SHOULD silently discard data with > > > bad MACs. If a DTLS implementation chooses to generate an alert > when > > > it receives a message with an invalid MAC, it MUST generate > > > bad_record_mac alert with level fatal and terminate its connection > > > state. > > > > > > http://tools.ietf.org/html/rfc4347#section-4.1.2.5 > > > > > > 4.1.2.5 Anti-replay (last paragraph): > > > > > > If the received record falls within the window and is new, or if the > > > packet is to the right of the window, then the receiver proceeds to > > > MAC verification. If the MAC validation fails, the receiver MUST > > > discard the received record as invalid. The receive window is > > > updated only if the MAC verification succeeds. > > > > > > > Hmm.... I'm not sure these are contradictory. > > > > If you get a packet with a MAC error you MUST discard the packet (i.e., > > not process it.) You may either *silently* discard it (i.e.., proceed as > if > > you had not received it) or terminate the connection with an alert. > > Silently discarding it = proceed as if you had not received it > > non-silently discarding it = log an error and proceed as if you had not > not received it > > Terminating the connection with an alert means "processing it". > Unsurprisingly, I don't agree with this interpretation. -Ekr --20cf3005dc481a97f904dd58a135 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, May 22, 2013 at 5:51 PM, Martin Rex <<= a href=3D"mailto:mrex@sap.com" target=3D"_blank">mrex@sap.com> wrote:
Eric Rescorla wrote:
> Martin Rex <mrex@sap.com> wr= ote:
> >
> > Paterson, Kenny wrote:
> > >
> > > True. Though the spec for DTLS = does allow DTLS implementations to
> > > terminate a connection in the event of errors.
> > >
> > > It's just that most (all?) implementations don't. > >
> > Now that you mention it, I hadn't noticed that DTLS gives act= ual two
> > _different_ guidances (MAY abort on MAC error and MUST discard re= cords
> > with MAC error are mutually exclusive)
> >
> > http://tools.ietf.org/html/rfc4347#section-4.1.2.1
> >
> > =A0 =A04.1.2.1 =A0MAC =A0(last paragraph):
> >
> > =A0 =A0In general, DTLS implementations SHOULD silently discard d= ata with
> > =A0 =A0bad MACs. =A0If a DTLS implementation chooses to generate = an alert when
> > =A0 =A0it receives a message with an invalid MAC, it MUST generat= e
> > =A0 =A0bad_record_mac alert with level fatal and terminate its co= nnection
> > =A0 =A0state.
> >
> > http://tools.ietf.org/html/rfc4347#section-4.1.2.5
> >
> > =A0 =A04.1.2.5 =A0Anti-replay =A0(last paragraph):
> >
> > =A0 =A0If the received record falls within the window and is new,= or if the
> > =A0 =A0packet is to the right of the window, then the receiver pr= oceeds to
> > =A0 =A0MAC verification. =A0If the MAC validation fails, the rece= iver MUST
> > =A0 =A0discard the received record as invalid. =A0The receive win= dow is
> > =A0 =A0updated only if the MAC verification succeeds.
> >
>
> Hmm.... I'm not sure these are contradictory.
>
> If you get a packet with a MAC error you MUST discard the packet (i.e.= ,
> not process it.) You may either *silently* discard it (i.e.., proceed = as if
> you had not received it) or terminate the connection with an alert.
Silently discarding it =A0 =A0 =3D proceed as if you had not re= ceived it

non-silently discarding it =3D log an error and proceed as if you had not =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0not received it<= br>
Terminating the connection with an alert means "processing it".

Unsurprisingly, I don't agree = with this interpretation.

-Ekr

--20cf3005dc481a97f904dd58a135-- From DPKemp@missi.ncsc.mil Thu May 23 12:57:36 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE1121F95D7 for ; Thu, 23 May 2013 12:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1fpBF-8KLm4 for ; Thu, 23 May 2013 12:57:22 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5118421F8EE8 for ; Thu, 23 May 2013 12:18:18 -0700 (PDT) Received: from clavin.missi.ncsc.mil (odysseus.missi.ncsc.mil [144.51.60.172]) by stingray.missi.ncsc.mil with ESMTP id r4NJIHrD029590 for ; Thu, 23 May 2013 15:18:17 -0400 (EDT) Received: from SQUID.missi.ncsc.mil ([fe80::e032:d4c7:c51f:85ec]) by odysseus.missi.ncsc.mil ([144.51.60.172]) with mapi id 14.03.0123.003; Thu, 23 May 2013 15:18:17 -0400 From: "Kemp, David P." To: "tls@ietf.org" Thread-Topic: [TLS] TLS1.2 vs TLS1.0 Thread-Index: AQHOVZs53iDEMC3avE2NikpA/eST2pkP618AgAADxICAAAoOAIAAh5aAgAG2dYCAAAqqgIAA2xOA Date: Thu, 23 May 2013 19:18:16 +0000 Message-ID: <5B1D7E570380A64989D4C069F7D14BC8880645BF@SQUID.missi.ncsc.mil> References: <20130523005145.1C3DC1A76F@ld9781.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.51.56.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS1.2 vs TLS1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 19:57:37 -0000 There is no contradiction - in both sections a record with a bad MAC MUST b= e discarded. 4.1.2.1 specifies two subcases of discarding: do nothing else (silently dis= card) or discard then alert/terminate). Those subcases do not conflict wit= h 4.1.2.5. I disagree with the SHOULD in 4.1.2.1, because that says the IETF disapprov= es of generating fatal alerts. Unless there is good justification for sayi= ng applications SHOULD NOT alert and terminate, the SHOULD should be MAY. Logging is independent of processing, not a third alternative. Silently di= scard (with or without logging) is one processing action, and alert and ter= minate (with or without logging) is the other. "Bad MAC discard without lo= gging" is not a separate action from "Bad MAC discard with logging". "Bad = MAC discard" is a single action with some level (debug/info/error) that may= or may not result in a log record being generated. Dave -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Eric = Rescorla Sent: Wednesday, May 22, 2013 9:30 PM To: mrex@sap.com Cc: tls@ietf.org Subject: Re: [TLS] TLS1.2 vs TLS1.0 On Wed, May 22, 2013 at 5:51 PM, Martin Rex wrote: Eric Rescorla wrote: > Martin Rex wrote: > > > > Paterson, Kenny wrote: > > > =09 > > > True. Though the spec for DTLS does allow DTLS implementations to > > > terminate a connection in the event of errors. > > > > > > It's just that most (all?) implementations don't. > > > > Now that you mention it, I hadn't noticed that DTLS gives actual two > > _different_ guidances (MAY abort on MAC error and MUST discard records > > with MAC error are mutually exclusive) > > > > http://tools.ietf.org/html/rfc4347#section-4.1.2.1 > > > > 4.1.2.1 MAC (last paragraph): > > > > In general, DTLS implementations SHOULD silently discard data with > > bad MACs. If a DTLS implementation chooses to generate an alert wh= en > > it receives a message with an invalid MAC, it MUST generate > > bad_record_mac alert with level fatal and terminate its connection > > state. > > > > http://tools.ietf.org/html/rfc4347#section-4.1.2.5 > > > > 4.1.2.5 Anti-replay (last paragraph): > > > > If the received record falls within the window and is new, or if th= e > > packet is to the right of the window, then the receiver proceeds to > > MAC verification. If the MAC validation fails, the receiver MUST > > discard the received record as invalid. The receive window is > > updated only if the MAC verification succeeds. > > > > Hmm.... I'm not sure these are contradictory. > > If you get a packet with a MAC error you MUST discard the packet (i.e., > not process it.) You may either *silently* discard it (i.e.., proceed as= if > you had not received it) or terminate the connection with an alert. =09 =09 Silently discarding it =3D proceed as if you had not received it =09 non-silently discarding it =3D log an error and proceed as if you had not not received it =09 Terminating the connection with an alert means "processing it". =09 Unsurprisingly, I don't agree with this interpretation. -Ekr From pgut001@cs.auckland.ac.nz Thu May 23 18:01:32 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF0621F90F4 for ; Thu, 23 May 2013 18:01: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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeUphxUi7+Dd for ; Thu, 23 May 2013 18:01:27 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1DB21F9425 for ; Thu, 23 May 2013 18:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1369357287; x=1400893287; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=medqPky35SdWteKXG5KsxwJl0qDRTW6Mm2W4kaRxJaA=; b=m7JrNgEkauZtu61Q+a6CIa7y3BecijS2I0OazgcYuusAAKBi0bsHeCgc 2nvBnpNKIlHVLLvkPpMEOEPhCWTclH7+x3s3Rfk/K3bNNYzqpdYiz1uNz fF+ar82qDM2Z/7747gBjKuMgDjGDgRZhsxZbp6T41FImhvigO5zQywCrx 4=; X-IronPort-AV: E=Sophos;i="4.87,730,1363086000"; d="scan'208";a="188926774" 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; 24 May 2013 13:01:26 +1200 Received: from UXCN10-TDC02.UoA.auckland.ac.nz ([169.254.8.4]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Fri, 24 May 2013 13:01:25 +1200 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] TLS1.2 vs TLS1.0 Thread-Index: Ac5YGjZ77+Wh7qWRQu6SucTDfFkrPw== Date: Fri, 24 May 2013 01:01:24 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D51012@uxcn10-tdc02.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 Subject: Re: [TLS] TLS1.2 vs TLS1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 01:01:33 -0000 Ulrich Herberg writes:=0A= =0A= >What would be your recommendation in this case? Mandate TLS1.2 and disallo= w=0A= >TLS1.0? Or just strongly recommend ("SHOULD") to use TLS1.2 and SHA2 ciphe= rs,=0A= >and otherwise to use TLS1.0?=0A= =0A= I would mandate TLS 1.1 with the encrypt-then-MAC fix. TLS 1.2 is erratica= lly=0A= deployed and supported while 1.1 is pretty universal (and even if a vendor= =0A= doesn't do it yet, it's a minor tweak on 1.0 while 1.2 is a massive rewrite= ).=0A= Also TLS 1.2 is actually weaker than TLS 1.1-with-MAC-fix (unless you use A= EAD=0A= ciphers, which have their own issues).=0A= =0A= Peter.=0A= From turners@ieca.com Fri May 24 10:14:14 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099EA21F967F for ; Fri, 24 May 2013 10:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.264 X-Spam-Level: X-Spam-Status: No, score=-102.264 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9IrzVFJ2Z5u for ; Fri, 24 May 2013 10:14:07 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.207.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE6F21F9682 for ; Fri, 24 May 2013 10:14:05 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 5BBE925B152C8; Fri, 24 May 2013 12:13:41 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 4B99A25B15296 for ; Fri, 24 May 2013 12:13:41 -0500 (CDT) Received: from [173.73.135.101] (port=62923 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UfvZ5-0006nB-MB; Fri, 24 May 2013 12:14:03 -0500 Message-ID: <519F9FDA.7080103@ieca.com> Date: Fri, 24 May 2013 13:14:02 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <516D5ADE.3050506@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.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: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:62923 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "" , "" Subject: Re: [TLS] AD review of draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 17:14:14 -0000 I think I didn't yet respond to some of these. On 5/7/13 11:11 PM, Joseph Salowey (jsalowey) wrote: > Most of these look reasonable to me, a few comments inline at the end. > > Thanks, > > Joe > On Apr 16, 2013, at 7:06 AM, Sean Turner wrote: >> 10) s4.2: Maybe reword this slightly: >> >> OLD: >> >> If the client indicated the support of raw public keys in the >> 'client_certificate_type' extension in the client hello and the >> server is able to provide such raw public key then the TLS server >> MUST place the SubjectPublicKeyInfo structure into the Certificate >> payload. >> >> NEW: >> >> If the client hello indicates support of raw public keys in the >> 'client_certificate_type' extension and the >> server also supports raw public keys then the TLS server >> MUST place the SubjectPublicKeyInfo structure into the Certificate >> payload. >> >> But, a more important question is the meaning of that paragraph above. Doesn't that override the "sorted by client preference" from s3? >> > > [Joe] I think this should probably say something like: > > "If the client hello indicates support of raw public keys in the > 'client_certificate_type' extension and the > server chooses to use raw public keys then the TLS server > MUST place the SubjectPublicKeyInfo structure into the Certificate > payload. Yep that's what I was thinking. >> 11) s6: Got some questions about the following: >> >> This information will be needed to make >> authorization decisions. Without a secure binding, >> man-in-the-middle attacks may be the consequence. >> >> 1st isn't that authentication. 2nd isn't it masquerade attacks? 3rd it's not really a may it's more an is likely to be? >> > > [Joe] I'm not sure binding a key to a name is exactly authentication. I'd probably reword it something like: > > "Without a secure binding between identity and key the protocol will be vulnerable to masquerade and man-in-the-middle attacks." I could live with that. >> 13) How are we supposed to check whether key is still considered "good"? If you can't that might be okay, but you need to mention that there's no mechanism to support this yet or that that also needs to be done out-of-band. >> > > [Joe] I think we need to state this is done out of band as well. Yeah all I'm looking for here is a warning that there's currently no mechanism to support this. I was going to go and say that the application needs to define who this might be done, but after talking it over with a couple of folks what it's going to come down to is asking those applications when we see them calling out use of this document if they really want status checking. spt From ben@digicert.com Tue May 28 10:11:44 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE76E11E80D7 for ; Tue, 28 May 2013 10:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.184 X-Spam-Level: X-Spam-Status: No, score=-4.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlYfMj51kQqK for ; Tue, 28 May 2013 10:11:39 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id CF77011E80D2 for ; Tue, 28 May 2013 10:11:34 -0700 (PDT) Received: from BWILSONL1 (unknown [64.78.193.228]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 586578FE01E for ; Tue, 28 May 2013 11:11:34 -0600 (MDT) From: "Ben Wilson" To: Date: Tue, 28 May 2013 11:11:33 -0600 Organization: DigiCert Message-ID: <01af01ce5bc6$67b9b8c0$372d2a40$@digicert.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B0_01CE5B94.1D20F670" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5bxlmu9J6+rg6dTlaoKwUeEUlcxA== Content-Language: en-us Subject: [TLS] draft-hallambaker-tlsfeature-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ben@digicert.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, 28 May 2013 17:11:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01B0_01CE5B94.1D20F670 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit What if the CA / Browser Forum were to add an optional provision for the certificate profile of End Entity TLS Certificates that said the following? TLS Feature Extension (optional) Subscriber Certificates MAY contain the TLS Feature Extension advertising that the status_request feature of OCSP stapling is available and supported by the subscriber. If present, this field MUST NOT be marked critical. See http://tools.ietf.org/html/draft-hallambaker-tlsfeature-02 ------=_NextPart_000_01B0_01CE5B94.1D20F670 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What if = the CA / Browser Forum were to add an optional provision for the = certificate profile of End Entity TLS Certificates that said the = following?

TLS Feature = Extension (optional)

Subscriber = Certificates MAY contain the TLS Feature Extension advertising that the = status_request feature of OCSP stapling is available and supported by = the subscriber.  If present, this field MUST NOT be marked = critical.

See http:= //tools.ietf.org/html/draft-hallambaker-tlsfeature-02 =

 

------=_NextPart_000_01B0_01CE5B94.1D20F670-- From n.mavrogiannopoulos@gmail.com Wed May 29 00:58:12 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E591121F9133 for ; Wed, 29 May 2013 00:58:12 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvoQMQW+GG-x for ; Wed, 29 May 2013 00:58:12 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0307321F8756 for ; Wed, 29 May 2013 00:58:11 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id p58so6168553wes.35 for ; Wed, 29 May 2013 00:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=PWzD4/ZIdoktGdsExxN+C48XbVMXX8legs/JeI+5BaE=; b=luGZidd99xft/UurXWu6QrK+M40BU778jqKm7AtPYnIzU8ZL73DnE33y+trC9r+V7X 68nXVSUZ9uoWO752xKZMr3AV1v/C72y42rm8G7Kbah/s1zCYVYZOEgyZ2oewiR57/lFz dKiLdHj4oFQo8BXjsGWliNNs37PmI8a2i3q4dINP4a5BYjZCaXWD17jB1Nqa4kmhmylc tYJIKi1h9sGY3NDhW5qmTZ9RUxmstX/hYvzHJbRFeSGDjK1QOLssRbSAgHZEKwS2MQpW nyHm0fzIHBcJ8B3OM65lmuHuCfe4bFyoxC4k5maA4uLRaUHRE0hrK0mY8v4Ar7EPk/MA 1jpw== X-Received: by 10.194.8.163 with SMTP id s3mr1220015wja.41.1369814291141; Wed, 29 May 2013 00:58:11 -0700 (PDT) Received: from [10.100.2.17] (94-224-103-174.access.telenet.be. [94.224.103.174]) by mx.google.com with ESMTPSA id eq15sm29362138wic.4.2013.05.29.00.58.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 May 2013 00:58:10 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <51A5B50B.8080205@gnutls.org> Date: Wed, 29 May 2013 09:58:03 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: tls@ietf.org References: <01af01ce5bc6$67b9b8c0$372d2a40$@digicert.com> In-Reply-To: <01af01ce5bc6$67b9b8c0$372d2a40$@digicert.com> X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] draft-hallambaker-tlsfeature-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 07:58:13 -0000 On 05/28/2013 07:11 PM, Ben Wilson wrote: > What if the CA / Browser Forum were to add an optional provision for the > certificate profile of End Entity TLS Certificates that said the following? > > TLS Feature Extension (optional) > > Subscriber Certificates MAY contain the TLS Feature Extension advertising > that the status_request feature of OCSP stapling is available and supported > by the subscriber. If present, this field MUST NOT be marked critical. > See http://tools.ietf.org/html/draft-hallambaker-tlsfeature-02 What is the actual problem the TLS extension on this draft solves? A client doesn't need an extension to drop the connection if an OCSP reply cannot be obtained. Moreover there are very few cases where a server would like to force the client to disconnect if such a reply is not available since the CA's OCSP server is typically outside its control, and which server administrator would like his site to go down every time the CA's server goes down. For the latter if the server is really concerned about the client getting the OCSP replies, he can send them in-band anyway using the status request extension (and if the server doesn't support this extension - as mentioned in the draft - why would it support the new one?) regards, Nikos From tom@ritter.vg Wed May 29 09:22:39 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C11521F9017 for ; Wed, 29 May 2013 09:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gl6NHDH6R0Sz for ; Wed, 29 May 2013 09:22:38 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF4921F9670 for ; Wed, 29 May 2013 09:22:34 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id mc17so9382426pbc.32 for ; Wed, 29 May 2013 09:22:25 -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=fxcLL9fRKfMkGllHvT9jqLBQ2jZQ5MhIIeRf2Y6dLAU=; b=SuaFe5n5MYgc3IOVjKmAuQ2W7nJCs/6XYOT4DD22FpBIZTKjU4M8f1+x9rBlMaB/t3 RoVymYS5LUtDL/kSmDzpUuUKB7koaT2v2f9eW9x/JaZMoTV21MTXFs72dlgLyloTtxwf 0/zA3UBs66kdf2QKhOT72oY3baler1QxCDIrg= X-Google-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:x-gm-message-state; bh=fxcLL9fRKfMkGllHvT9jqLBQ2jZQ5MhIIeRf2Y6dLAU=; b=TnY235rWpwxH5JqkAyuOQ1/1RFLVn+sRLq9PkFYhiP1mOTw/zceYqmBepvQc6Yv1pP +fkYHmFPZVdcyTPto68RibPW2vfSNDuRqHLqWSennQjBqHeHqLYtuk/9dKsYOa7rB6cV gWDj8/w6U4U53ZimiNBBWAYCg/37vHgzACtOcPAVxG6o5pB+K2RI+/vb1hsCMxI2SNri 57AgQ45d1VG3/teCCG61kDzciw176qurXq+502InXhhxE1VB8vjpG41dBc05Zjfl9o3/ sihr/U72UgPqLT2nS3NE9UCk8aPcbzCbe0IWtiTwieXWfpV4ky+p4MG2PGVManfjHeeb vViw== X-Received: by 10.66.146.232 with SMTP id tf8mr4321220pab.32.1369844545361; Wed, 29 May 2013 09:22:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.94.196 with HTTP; Wed, 29 May 2013 09:22:04 -0700 (PDT) In-Reply-To: <51A5B50B.8080205@gnutls.org> References: <01af01ce5bc6$67b9b8c0$372d2a40$@digicert.com> <51A5B50B.8080205@gnutls.org> From: Tom Ritter Date: Wed, 29 May 2013 12:22:04 -0400 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnnOY0RguUBHj6W05PuEkrKciPVbkdsl6Q0WL/+iMsmCuA+Moijvhr164os4b2kh+nHwZRv Cc: "tls@ietf.org" Subject: Re: [TLS] draft-hallambaker-tlsfeature-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 16:22:39 -0000 On 29 May 2013 03:58, Nikos Mavrogiannopoulos wrote: > A client doesn't need an extension to drop the connection if an OCSP > reply cannot be obtained. It also doesn't need to be told to not downgrade TLS versions, or to require revocation informatton at all - but they don't do those things. > Moreover there are very few cases where a > server would like to force the client to disconnect if such a reply is > not available since the CA's OCSP server is typically outside its > control, and which server administrator would like his site to go down > every time the CA's server goes down. "Very few" is probably accurate, but this is explicitly for those cases. > For the latter if the server is really concerned about the client > getting the OCSP replies, he can send them in-band anyway using the > status request extension (and if the server doesn't support this > extension - as mentioned in the draft - why would it support the new one?) Exactly, the server will do that. > On 05/28/2013 07:11 PM, Ben Wilson wrote: > What is the actual problem the TLS extension on this draft solves? The problem is that every web browser and client will happily continue on without revocation information if it is given an x.509 certificate in a TLS handshake. By placing a flag in the certificate, the clients who recognize the flag will know they should not (MUST NOT?) continue without revocation information. If clients were to flip that switch for every single certificate it saw - vast swathes of HTTPS site would not work. So clients will not do it. But this flag is a way for a site to signal to a client that it does not want to be bug-compatible with the rest of the Internet, and wants to hold itself to the correct standard. An opt-in mechanism. And clients can flip that switch and hold sites to a higher standard if it is an opt-in mechanism. -tom From simon@josefsson.org Thu May 30 14:31:28 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E490021F93BC for ; Thu, 30 May 2013 14:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.112 X-Spam-Level: X-Spam-Status: No, score=-100.112 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_SE=0.35, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRguqPM09Y1S for ; Thu, 30 May 2013 14:31:23 -0700 (PDT) Received: from duva.sjd.se (static-213-115-179-179.sme.bredbandsbolaget.se [213.115.179.179]) by ietfa.amsl.com (Postfix) with ESMTP id 03FF721F93B9 for ; Thu, 30 May 2013 14:31:19 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r4ULV0Gl012345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 30 May 2013 23:31:02 +0200 From: Simon Josefsson To: mrex@sap.com (Martin Rex) References: <20130521134742.4B1371A759@ld9781.wdf.sap.corp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130530:ulrich@herberg.name::sKDKvEWrAix45+04:7JGy X-Hashcash: 1:22:130530:mrex@sap.com::+18YVybm+u2KYKTl:SsVr X-Hashcash: 1:22:130530:tls@ietf.org::smL6qjXB47p9PBIW:ll7n Date: Thu, 30 May 2013 23:30:58 +0200 In-Reply-To: <20130521134742.4B1371A759@ld9781.wdf.sap.corp> (Martin Rex's message of "Tue, 21 May 2013 15:47:42 +0200 (CEST)") Message-ID: <87obbs17fx.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Cc: tls@ietf.org Subject: Re: [TLS] TLS1.2 vs TLS1.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 21:31:29 -0000 mrex@sap.com (Martin Rex) writes: >> Is it absolutely discouraged to use them? > > Just the opposite. TLSv1.0 and TLSv1.1 are still perfectly fine for use, I believe a statement like that should be qualified a bit: it is _possible_ to implement TLSv1.0 and TLSv1.1 securely, but if you only follow RFC 2246 and RFC 4346 you will run into issues. Thus, for an external organisation wishing to reference a document describing secure implementation and use of TLS, I would say that referencing TLSv1.2 and requiring a AEAD mode is the only safe approach today. One alternative would be to reference TLSv1.0 and/or TLSv1.1 and also to reference all published attacks (e.g., CBC and compression) which usually contains a recommendation for implementers. Another alternative is for this WG to take on revising the TLSv1.0 and TLSv1.1 documents to recommend what is necessary in order to end up with a secure TLSv1.0 and TLSv1.1 implementation. Is there any interest in this? /Simon