http://permalink.gmane.org/gmane.ietf.tls hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.tls/10351 <pre>Thanks! I can answer a few of the techincal questions. I'll leave your comments on the wording and such to Dirk. 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. 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. I think it's primarily a privacy concern. 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. Yes. Yes. It's certainly expected that the client would use the same public key (i.e. (x, y) pair), yes. Yes. No, the Channel I</pre> Adam Langley 2013-05-14T20:57:23 http://permalink.gmane.org/gmane.ietf.tls/10350 <pre> Joe you read my mind. I'm also okay without the MUST. 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 </pre> Sean Turner 2013-05-14T19:20:44 http://permalink.gmane.org/gmane.ietf.tls/10349 <pre> 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 </pre> Sean Turner 2013-05-14T18:48:13 http://permalink.gmane.org/gmane.ietf.tls/10348 <pre>_______________________________________________ TLS mailing list TLS&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/tls </pre> Hannes Tschofenig 2013-05-14T11:18:05 http://permalink.gmane.org/gmane.ietf.tls/10347 <pre>[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</pre> Bert Greevenbosch 2013-05-14T03:30:57 http://permalink.gmane.org/gmane.ietf.tls/10346 <pre> On May 9, 2013, at 12:53 PM, Daniel Kahn Gillmor &lt;dkg&lt; at &gt;fifthhorseman.net&gt; wrote: [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] 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 thin</pre> Joseph Salowey (jsalowey 2013-05-10T03:19:34 http://permalink.gmane.org/gmane.ietf.tls/10345 <pre> 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? 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 _______________________________________________ TLS mailing list TLS&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/tls </pre> Daniel Kahn Gillmor 2013-05-09T19:53:47 http://permalink.gmane.org/gmane.ietf.tls/10344 <pre> 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 certificate 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 session, this works for "traditional" RSA certificates that contain no ECDH keys. Juho </pre> Juho Vähä-Herttua 2013-05-08T05:38:42 http://permalink.gmane.org/gmane.ietf.tls/10343 <pre>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 _______________________________________________ TLS mailing list TLS&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/tls </pre> Swarupa 2013-05-08T03:57:22 http://permalink.gmane.org/gmane.ietf.tls/10342 <pre>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 &lt;turners&lt; at &gt;ieca.com&gt; wrote: [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. [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. " [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." [Joe] I think we need to state this is done out of band as well. [Joe] At least the multi-ocsp extension could be extended to support other Status mech</pre> Joseph Salowey (jsalowey 2013-05-08T03:11:33 http://permalink.gmane.org/gmane.ietf.tls/10341 <pre>[ for best results use a fixed-pitch font ] Here's some comments on draft-balfanz-tls-channelid, I hope they're helpful. =JeffH ------ High-level comments: 1. EncryptedExtensions modification to the TLS handshake ought to be split out into a separate spec. 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? 3. In my view, this spec defines how a TLS client generates and subsequently wields a unique client identifier/key with a particular TLS server over multiple TLS connections (in parallel and serially). Thus it is more about creating a "security association" between the client and server (eg, see definitions for the latter, as well as "channel", in RFC4949). Thus I would not use the term "channel" for this mechanism. Also, TLS unto itself is creating a cryptographic channel between client and server and thus using the</pre> =JeffH 2013-05-01T00:11:21 http://permalink.gmane.org/gmane.ietf.tls/10340 <pre>AGL replied.. &gt; On Tue, Apr 30, 2013 at 5:01 PM, =JeffH &lt;Jeff.Hodges&lt; at &gt;kingsmountain.com&gt; wrote: &gt;&gt; After perusing both draft-agl-tls-nextprotoneg and &gt;&gt; draft-balfanz-tls-channelid, &gt;&gt; I tend to agree with PaulH that EncryptedExtensions ought to be a &gt;&gt; stand-alone spec that is referenced by TLS extension specs as needed. &gt; &gt; I think the feeling at Orlando was that people didn't want to do &gt; EncryptedExtensions. Rather they wanted something more general. hm, i had the impression during that discussion that the overall concern was with having (specifically) next-proto-negotiation in the clear, rather than objections to EncryptedExtensions per se. =JeffH </pre> =JeffH 2013-04-30T21:28:14 http://permalink.gmane.org/gmane.ietf.tls/10339 <pre> I think the feeling at Orlando was that people didn't want to do EncryptedExtensions. Rather they wanted something more general. -- Adam Langley agl&lt; at &gt;imperialviolet.org http://www.imperialviolet.org </pre> Adam Langley 2013-04-30T21:05:38 http://permalink.gmane.org/gmane.ietf.tls/10338 <pre>AGL replied.. &gt; On Sun, Nov 11, 2012 at 8:30 PM, Paul Hoffman &lt;paul.hoffman&lt; at &gt;vpnc.org&gt; wrote: &gt;&gt; &gt;&gt; Is is possible for you to do a separate Internet-Draft on &gt;&gt; EncryptedExtensions, and then point to it from draft-balfanz-tls-channelid? &gt;&gt; I ask because there are probably other future extensions that will want to &gt;&gt; use that extension... &gt; &gt; EncryptedExtensions is also used in the NPN. I'd be happy to split it off if &gt; the WG were to adopt something that required it. So whither draft-agl-tls-nextprotoneg (in light of draft-ietf-tls-applayerprotoneg)? Informational? After perusing both draft-agl-tls-nextprotoneg and draft-balfanz-tls-channelid, I tend to agree with PaulH that EncryptedExtensions ought to be a stand-alone spec that is referenced by TLS extension specs as needed. HTH, =JeffH </pre> =JeffH 2013-04-30T21:01:56 http://permalink.gmane.org/gmane.ietf.tls/10337 <pre> Having a standard curve one can rely on promotes interoperability, but that cannot be easily done on a single ciphersuite. That is because this mandatory curve applies to the certificate as well, and it is often not feasible to require multiple certificates for each ciphersuite (assuming another ciphersuite will define a different set of mandatory curves). For that it could be more useful if the suggested curves were published as an update to RFC4492. As such I am not in favor for this specific ciphersuite to select a mandatory curve, but rather to define a smaller set of mandatory curves that apply for all TLS ciphersuites. regards, Nikos </pre> Nikos Mavrogiannopoulos 2013-04-30T13:12:00 http://permalink.gmane.org/gmane.ietf.tls/10336 <pre> +1 -Regards, Joseph Hi Sean, I too agree with the comments provided by Paul Hoffman, Russ, David and Paul Duffy and also feel the conservative MTI curves specified in the draft promote interoperability. Robert On 24/04/2013 06:23, Paul Duffy wrote: Hi Sean I agree with the comments offered by Paul, Russ, and David. FYI, whatever normative dependency exists between CoAP and this draft, several efforts of the Zigbee Alliance also have normative references to this draft (Zigbee IP and Smart Energy Profile 2). The draft was triggered by SEP2's extensive vetting for an ECC standard for LLNs. The Zigbee products are undergoing certification and initial deployments are expected to begin this year. Cheers On 4/23/2013 5:05 PM, Russ Housley wrote: Sean: I do not think this out to include the MTI curve. I would greatly prefer that COAP make use of one of the curves that is already specified. I think a strong reason is needed to specify more curves; the specification of too many will reduce interoperabi</pre> Reddy, Joseph 2013-04-24T22:54:41 http://permalink.gmane.org/gmane.ietf.tls/10335 <pre>Hello, As more and more applications being migrated over TLS, besides encoding /decoding cost and additional RTT on the network, I am wondering how much additional byte are created roughly by encrypting the clear text over TLS compared to HTTP? There must be some work already done from this angle but hardly to find it on the web. Could you share some good references or white papers for this KPI? Sorry to bother you in this mail list. But this is where the most expertise is. Appreciate your help! Dan _______________________________________________ TLS mailing list TLS&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/tls </pre> Dan Sun 2013-04-23T01:57:31 http://permalink.gmane.org/gmane.ietf.tls/10334 <pre>We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit t</pre> hammondjohnson< at >hushmail.com 2013-04-27T17:52:31 http://permalink.gmane.org/gmane.ietf.tls/10332 <pre>Hi Bert, You may be interested in TACK [1]. TACK allows a client to verify a server's identity based on client knowledge of a "TACK signing key" which signs the server's TLS key(s). These signatures are presented in the TLS handshake along with an expiration time and revocation info for earlier signatures. This enables the server operator to use a "more-secure" offline signing key to revoke and replace the "more-exposed" TLS keys, akin to your OCSP-lite proposal. TACK was designed to be compact and simple to verify, and requires no X.509 certs, so it would work well with draft-ietf-tls-oob-pubkey. Trevor [1] http://datatracker.ietf.org/doc/draft-perrin-tls-tack/ On Thu, Apr 25, 2013 at 1:19 AM, Bert Greevenbosch &lt; Bert.Greevenbosch&lt; at &gt;huawei.com&gt; wrote: _______________________________________________ TLS mailing list TLS&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/tls </pre> Trevor Perrin 2013-04-26T01:59:25 http://permalink.gmane.org/gmane.ietf.tls/10331 <pre>We have posted a new revision of draft-ietf-tls-applayerprotoneg-01. Changes to this version include: 1. Revised Introduction 2. Addition of HTTP/2 in the references section 3. Removal of paragraph on hash calculations (in response to WG feedback) 4. Clean up of some references within the document and reference formats 5. Addition of Adam Langley from Google as a co-author 6. Addition of Emile Stephan from France Telecom - Orange as a co-author We are very interested in any review comments or feedback that we can use to further improve the draft. Best Wishes, Stephan Friedl _______________________________________________ TLS mailing list TLS&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/tls </pre> Stephan Friedl (sfriedl 2013-04-25T21:19:05 http://permalink.gmane.org/gmane.ietf.tls/10330 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension Author(s) : Stephan Friedl Andrei Popov Adam Langley Emile Stephan Filename : draft-ietf-tls-applayerprotoneg-01.txt Pages : 8 Date : 2013-04-25 Abstract: This document describes a Transport Layer Security (TLS) extension for application layer protocol negotiation within the TLS handshake. For instances in which the TLS connection is established over a well known TCP/IP port not associated with the desired application layer protocol, this extension allows the application layer to negotiate which protocol will be used within the TLS session. The IETF datatracker status page for this draft is: https://datatracker.</pre> internet-drafts< at >ietf.org 2013-04-25T21:08:23 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.tls