From henry.story@bblfish.net Tue May 1 01:12:21 2012 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 3437421F84CE for ; Tue, 1 May 2012 01:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 2rVCYVbKXf92 for ; Tue, 1 May 2012 01:12:19 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 40A0721F84BF for ; Tue, 1 May 2012 01:12:18 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2836967bku.31 for ; Tue, 01 May 2012 01:12:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=UZyUSUmvaaI+N4xYXQradW13AKRdvgKL5+HbNhHhZbw=; b=DFKi/60+DG7BLAjnVuOG8a3Ez9JdEUp0zh4VMW7v4hhFv+55F8B0LD3g87foEi4io8 xTyMNK+qHWYyND1408RIOooV82eyUWFsILSSox4CiOmvfXx0mH4szmDwhzzgZAaUBBpj /rvqSj3vTfPNQ0s/p0xIcvJfL1G1DNmTEfHEgWVpLXStzxx+jxkpApUZkmX4zNZa8/qS HmAfa38yq/dlKaULIIewHH5Y+59/99mIuWAWaYZmJXbdxOOz5VkOPho+MybzmVkV625A 9rXzdxktDLsYh066Vhy0Csg4vfikVvpV+fLaSywoc0z+XeLbzK5SM9VdLr/YUjO4nn6A JlIw== Received: by 10.204.154.140 with SMTP id o12mr6552540bkw.139.1335859938036; Tue, 01 May 2012 01:12:18 -0700 (PDT) Received: from [192.168.1.33] (dslb-088-075-077-030.pools.arcor-ip.net. [88.75.77.30]) by mx.google.com with ESMTPS id f11sm31110807bkw.6.2012.05.01.01.12.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 May 2012 01:12:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: Date: Tue, 1 May 2012 10:12:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <721E54BA-FD27-4BAC-98D5-87EC33A09C21@bblfish.net> References: <37860D94-8750-40F9-9388-07057B4E6ECD@bblfish.net> To: Geoffrey Keating X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnjVoa/PeoPWlgcJgKKb5hMAZOWlK0m2ctyHLCJwVrUnHXdORXm3/dtvdZkpjdxh6N0bWOU Cc: "tls@ietf.org List" , public-webid Subject: Re: [TLS] Fixing TLS Trust 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, 01 May 2012 08:12:21 -0000 On 1 May 2012, at 05:03, Geoffrey Keating wrote: > Henry Story writes: >=20 >> TLS currently helps one know that when opens a connection to a >> service (domain:port pair) one is actually connected to the machine >> that officially owns that domain. It does not give one the big >> picture of what kind of entity one is actually connected to: ie. it >> does not answer the following questions: >>=20 >> - is this a legal entity? >> - which country is it based in (or which legal framework is it = responsible to) >> - who are the owners >> - what kind of organisation is it? (individual, bank, commerce, = school, university, charity...) >=20 > Isn't this mostly covered by EV certificates? >=20 > - The 'is this a legal entity' part is answered with 'yes'. >=20 > - The country/legal framework part is the > jurisdictionOfIncorporationCountryName field and similar. yes. >=20 > - It doesn't describe the owners, but of course that information could > change between the time the connection is opened and the packets > reach the other end; except in the case where a certificate is > issued to a sole proprietor, in which case that individual is named > in the certificate. In the case of a company it does provide > sufficient information to track down the company and find its owners > if they are publicly available. This is the advantage of placing this information on the web rather than in the certificate. A Web page (enriched with RDFa or with a content = negotiated RDF representation such as Turtle, RDF/XML, or JSON-LD) can be updated = much=20 more easily and readily than a certificate. So if the management changes the certificates of the company does not have to change in step. This is similar to the argument for using WebID for distributed social = networks. Where PGP and X509 tend to place the information about the entity in a = signed certificate that cannot be changed, WebID places the information about a = user and his social network on the web in such a way that information can be = partially revealed using access control depending on the user connecting = (authenticated with WebID) = http://www.w3.org/wiki/Foaf%2Bssl/FAQ#How_does_this_improve_over_X.509_or_= GPG_Certificates.3F >=20 > - The kind of organisation is covered by the businessCategory field. Thanks for filling that in. I think the RDF linked data web can be = complimentary to the role played by the EV Certificates, which can continue to provide = this=20 information. What would be possible would be for a much richer set of = relations to be expressed then in RDF, that have furthermore much clearer = semantics, and are much easier to read and write for a much larger body of people that = the ASN.1 expertise required to work with X509 certificates. In fact it would = probably=20 be an interesting exercise to provide RDF semantics for X509, making = X509 just a another RDF serialisation. (the way GRDDL allows any XML format to be = thought of as a serialisation of RDF http://www.w3.org/TR/grddl/ ) Certificate organisations may be very well placed to provide such a = service=20 ( a profile document for each of the organisations they certify = containing richer information ) given that they understand the security space, = could=20 easily acquire the linked data knowledge, and are aware of the need to=20= evolve their business model.=20 But certificate authorities need not be the only ones to participate in = this=20 process. Other organisations such as local authorities could certify = local=20 businesses for example, which they have a much closer relation to than = the=20 current certificate authorities. (Of course it will take presumably a = lot lot longer before the knowledge, and processes develop for how to do this = trickles=20 down to that level (I'd guess 10-15 years or so). >=20 > The presentation seemed interesting. Thanks :-)=20 Beside the overlap between the EV Certificates and the richer model available from the linked data web, there is another part of the = presentation that shows how this can be used by banks to create account certificates = for=20 their users, which could then be used for commercial transactions. There = again the richness of the semantic web, makes it easy to see how account = profiles can link to payment forms/collections that can be used to automate payments. = IBM and others have done some very interesting work here to put in place some = framework for this in the Linked Data Profile submission which will soon form a = W3C=20 working group. http://www.w3.org/Submission/2012/02/ This essentially = specifies how RESTful semantic services can be described. Henry Social Web Architect http://bblfish.net/ From henry.story@bblfish.net Tue May 1 02:55:29 2012 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 1002F21F8743 for ; Tue, 1 May 2012 02:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 PTXyjQ1afRVM for ; Tue, 1 May 2012 02:55:26 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D781821F8741 for ; Tue, 1 May 2012 02:55:25 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2881530bku.31 for ; Tue, 01 May 2012 02:55:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=jVkNFbjq8rPtpHMGerVZ9/wojzqO5uCcOSFph1EzeNU=; b=PsM5b21UuMdSXqjQPYNTWGx/7+pq0YubGoqQVK3HMkz9jbMDRSf8oS6urSvTzO+WRa QZOmC1W7eIQD0JWgMuZqClumpJbJpbhujJXOjHALSDRaimkdNZiE5m2G/CF4DZ5fP37A w5SqYgcgAoYm+j4FrDUtRlFQ9rUtJAMMFH7IGTC7xhG8PjJK9wzwsm8SUEw9bRszshlG cHsaumMPvezhTzxZx+6ySc2BTcTEg+9hkm2mE9eS++2AMmBzrEbYo3dp5oDYnvd3LeNV uxjpL2s3bP9/Iu45v8FRKOLssohwU4lneUqfTq5yNCiRdEQ5fjH4IM4ax2kKiuJonZMg B6dQ== Received: by 10.205.128.8 with SMTP id hc8mr2164596bkc.17.1335866124587; Tue, 01 May 2012 02:55:24 -0700 (PDT) Received: from [192.168.1.33] (dslb-088-075-077-030.pools.arcor-ip.net. [88.75.77.30]) by mx.google.com with ESMTPS id u8sm2378065bks.0.2012.05.01.02.55.20 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 May 2012 02:55:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: Date: Tue, 1 May 2012 11:55:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <19D1E4D9-1864-42BE-B16A-861F45AD4612@bblfish.net> References: <37860D94-8750-40F9-9388-07057B4E6ECD@bblfish.net> <07B7828B-DF75-446E-AF6E-6A16BD9F9146@bblfish.net> To: Nico Williams X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlsmI8HsVAaPk6GEbVPtHReAqNUpdXJq3CZuog+9LiS+cE/y/hs+ywpzn+EJBGi9reZg4Kl Cc: "tls@ietf.org List" , public-webid Subject: Re: [TLS] Fixing TLS Trust 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, 01 May 2012 09:55:29 -0000 On 30 Apr 2012, at 21:57, Nico Williams wrote: > On Mon, Apr 30, 2012 at 2:24 PM, Henry Story = wrote: >> On 30 Apr 2012, at 19:31, Nico Williams wrote: >>> In the on-line world some of these questions are more interesting, = but >>> only because trust is harder to establish. And anyways, we don't = get >>> answers to these questions on-line, not most users anyways. The = trick >>> is to get domain names to reflect the same things that brick and >>> mortar sites do. >>=20 >> yes, but a domain name can be reached by clicking a page that is not >> behind https, and so a man in the middle attack could have changed >> the originating link, even if it came from a trusted source. Also >> [...] >=20 > That problem doesn't go away. We can't just use HTTPS (no matter how > much some people insist that we should only use HTTPS). DNSSEC > wouldn't help either since usign HTTP (no S) means that there can > always be an MITM in TCP. The only solution here is to train users to > know when to insist on HTTPS, and the UIs really have to not suck (as > long as we allow HTTP_no_S for some things this will be a problem). I agree that http won't go away (easily). What is possible though is = that=20 browsers be enhanced by the vendors or plugin writers or even with external applications to fetch metadata about a web site and its owners and its position in a legal framework from the linked data web. So imagine a non-internet-technical-person, Alice, is somehow reading a = very=20 good blog served with http about some excellent Swiss watchmaker, who=20 has a little shop up in the mountains in calm isolation from the hectic=20= hustle and bustle of most mortal men's lives, the calm giving him the = serenity=20 to make the most amazing devices. This reader could click on the link and two things could happen 1. the page was man-in-the-middled first to send him to some fake site. The browser takes that domain name and tries to from a number of linked data trust points to find the official metadata about that site. Perhaps it finds very little information about it, which=20 should be a warning sign. Perhaps it finds that the company owners are incorporated in some other country. Alice finds this suspect, and calls her techy friend to help her verify what is going on. 2. the page was not man-in-the-middled and Alice ends up on the swiss watch makers https protected site (the swiss are very good at security) That site is server with a certificate placed in DNS-SEC using DANE = with a WebID in the SAN. That WebID also confirms the public key of the = watch maker and points to the local Swiss Watch Maker's authority page and to = the local canton's business registry which each points back to the swiss watch makers WebID (and so indirectly to his profile). Both of those = are=20 linked to by the swiss Identity registry, which itself is pointed to=20 by the equivalent US registry. The browser plugin uses this web of data to give our non-technical-user=20= an interface that she can inspect, and that she can drill down into to=20= find exactly which registry said what if she wanted to. Ok it is true that this still leaves open the possibility that the man in the middle not just change the URL to the watch maker, but also = changes the text and the description. But if this is not going to be obvious = through inconsistencies - one part of the text describing switzerland, the other part describing some hot country in south america - then the text will = need very careful man-in-the-middleing. Perhaps the man in the middle is = another Swiss watch maker in a nearby canton, whose linked data network also = resolves well. But then in any case Alice would get a watch, and she would know=20= which watch maker had man-in-the-middled her if she had a complaint = later. Furthermore one can imagine consumer associations emerging that would=20 be able to create services to enhance the metadata for a site with other satisfaction reports, these consumer associations forming a = network themselves covering the globe (so as to always be close to the = businesses that they were reporting on, and so able to take local context into = account) I think this very clearly shows a big improvement over the current=20 situation. >=20 >>> No matter what we're still talking about how to establish trust. >>> That's the hard part. How do I trust that such and such corporation >>> owns some website? I have to know who is making that statement, and >>> for that I must authenticate them, and I've to decide if they can = make >>> that statement authoritatively, and whether I trust them (even if I >>> can authenticate them). >>=20 >> yes. All businesses tend to be registered somewhere: be it either = with the >> local authority, or with some tax office, or with the stock = exchange,... >=20 > I'm not sure that's true. In the U.S. in some/many?/most? states it's > possible to start a sole proprietorship without having to first > register anywhere -- sure, these are going to be small businesses, and > they will eventually have to pay taxes and therefore register, I did not know that. Thanks for pointing this out. > but even then, there's too many governments you'd have to go check to = find > out about random companies, at least in the U.S. Who's going to do it? = =20 This is an organisational issue that is not something that I can solve here. For everything but "sole proprietorship" companies the = institutions already exist. It should be possible to have something that helps those = smaller companies too. In my presentation I start with banks, as those are = heavily regulated and as they have the finance to put things in motion. Perhaps they could provide the service for those smaller businesses.... > I can't think of a random web customer caring to check the tax > records of a sole proprietorship or corporation, or caring to know > immediately that someone else has checked. The important thing is that the data be available so that User = Interfaces tuned to the particular software in use can be built. I would expect = some=20 lightweight signalling to be made visible to the user, which he/she can = go into more detail when required. This is user interface design work, and=20= experts like Aza Raskin are the people to employ for this task https://blogs.oracle.com/bblfish/entry/identity_in_the_browser_firefox >=20 >>> Assuming the TLS server PKI works then you're right, this is simple = to >>> add as a *protocol*. Though you'd still need to get someone to do = the >>> vouching: it won't be governments, since there are some many ones = that >>> are authoritative at some level that users could not really = authorize >>> them to make these statements, so it has to be some commercial >>> operation, or a national-level agency. >>=20 >> yes. >>=20 >>> That sounds so difficult to pull off, and likely to provide so = little >>> value that I don't think it can happen. >>=20 >> I think the value is quite big in fact, and it would not be that = difficult >> to do technically. Getting all of these institutions to coordinate = would >> be more difficult to do I agree, and one would have to start = somewhere where >> the value and the will is there: perhaps the stock exchanges or = banks. >=20 > Again, protocol-wise: trivial, but business-wise: very much > non-trivial. "Not that difficult to do technically" is not enough, > and you do have to be careful what you mean by "technically", because > to me this is "technically" quite difficult when we include anything > other than "protocol details" in "technically". Completely agree. The work here is one of convention and = standardisation, which is as much a social project as a technical one. A lot of the standards are already in place though: - HTTP, HTML - TLS/SSL - DNS-SEC + DANE - RDF and serialisations (RDFa, turtle, rdf/xml, json/ld) - ontologies and basic object reasoning=20 - linked data http://linkeddata.org/=20 with a standardisation process being started at the W3 with the=20 Linked Data profiles submission by IBM, Oracle, Red Hat, and others http://www.w3.org/Submission/2012/02/ - tools in every programming language to do most of the above So it is not as if everything has to be invented. One would need to choose some interesting and feasible use case and interested parties,=20 get some running code, get it to interoperate, and produce and publish ontologies and how to guides. That IS a lot of work. But it is not at all in the realm of pure speculation. Building a prototype with fake banks should be something that is very feasible, and then trying it out in some real use cases is not that far off.=20 In any case I think it is quite clear that this is where the Trust=20 story has to go. It is decentralised enough to make every state and player happy, and it is flexible enough to be able to extended to even the most unusual use cases. >=20 >>> But on a smaller scale it could happen, and, indeed, it does = already. >>> What I have in mind is federations of like companies. Sites like >>> Amazon, eBay, and Yahoo! already have, effectively, federations of >>> vendors. I'd like to see a federation of banks. >>=20 >> Yes. That's the example I used. In Switzerland it was suggested that >> companies such as Swatch that have a lot of resellers that are always >> changing might also have a need for something like this. This is why >> I think that attacking this from both the social networking side and = the >> more formal institutional side is useful. The institutional side = helps >> people see how trust can work in a distributed manner - it always = has. >> It is just that we tend to think of governments as central agencies, >> whereas in reality they are distributed: each state is a peer in the = social >> network of states. >=20 > Governments are too distributed to help with this problem, unless we > could get all these governments (or at least the ones that matter, or > enough that the ones that do can be the ones that end up mattering) to > have all these databases online. That's a political problem. > Political processes can be very slow -- much slower than IETF > processes. Watch out. My conception of federations sidesteps that > problem. And as I said: it's already happening on some scale. I agree there. The reason in my presentation I mention governments and institutions is that this helps anchor people's understanding of trust. But of course to get going smaller projects will be needed. Having the bigger picture in mind can nevertheless help co-ordinate projects=20 developing in parallel. >=20 > With respect to banks... the business model there looks significantly > different than Amazon's/eBay's/Yahoo!'s -- the latter act as a > directory/middleman to the vendors, while there should be no middleman > when it comes to banking, and people do not purchase banking > products/services from random banks as often as they do trinkets from > random vendors, which limits the usefulness of a directory of banks. > So I'm not sure what we can do there. There are not that many banks in the world, so it would be easy to start with a single list of co-operating banks to get things going. The registry of banks would just help vendors of any size do purchases directly with the banks. >=20 > Basically I'm skeptical. For my money the certificate transparency > proposal is our best bet in the short-term. Longer-term, if there's > any way to bring user authentication mechanisms that can do mutual > authentication into the web, then that will help enormously when it > comes to banking, but I think there's a lot of barriers to improving > user authentication on the web. We'll see. Thanks for your feedback. I was hoping just to open up a new space of possibilities. A lot of the pieces are already in place. Trying it out in vitro would be the next step. :-) > (That reminds me, I > should write something up for HTTPbis.) >=20 > Nico > -- Social Web Architect http://bblfish.net/ From chris@randomnonce.org Tue May 1 04:46:00 2012 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 0B67921F85AE for ; Tue, 1 May 2012 04:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 DWJ1Qi3+7vtO for ; Tue, 1 May 2012 04:45:59 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 76B4C21F8599 for ; Tue, 1 May 2012 04:45:59 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so2404655obb.31 for ; Tue, 01 May 2012 04:45:58 -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:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=z9Uzv3ahyZHMfWFyldFUP75ck9AODAe5f87BZup2Jos=; b=k/V3OVKFvq17g4dote+ddsE6IN9JAF1ibrqU1J4VYcAcKscXtJxuVOUecDpIPA1DMi bruUeu2ilHspJ2Hk0YAlr32fENLeBczqJlbNXsJk+JEP0yc5h2sDFhA6IXyzJK6q25Ek wRaTmggYB9qef2lhy6p0UFQx96jO2RGD3q7obDrvyssDJQhnGOIG2uNa3k0cLRL1u5lx BHEBa/272iqRuZjr+km3Ow3Hl1DHnWY5hyDrH7E7aLJQaFXJpVeLffivfPUzMBEcnLvc JLWM3HNlrkoPaMUx6MdzYYAGbwEosiixFyWrhn7KPNI+IaxDtIbqrsH4OGW21K9tygMX 7eiw== MIME-Version: 1.0 Received: by 10.182.172.100 with SMTP id bb4mr9260755obc.22.1335872758806; Tue, 01 May 2012 04:45:58 -0700 (PDT) Received: by 10.182.69.138 with HTTP; Tue, 1 May 2012 04:45:58 -0700 (PDT) X-Originating-IP: [203.47.135.74] Date: Tue, 1 May 2012 21:45:58 +1000 Message-ID: From: Chris Richardson To: "tls@ietf.org List" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlwAIo0sFaQ1W+4DcQ3U6l7s5XetShDpVOy0yhy9bdNIaJ/HzU8Hr/AY7mZaOkJW5qQakvF Subject: [TLS] RFC 2818 wildcard rationale 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, 01 May 2012 11:46:00 -0000 RFC 2818 states: Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. I was trying to figure out the rationale behind this, but have been unable to do so. I was hoping someone could enlighten me. Suppose that: (1): *.example.com matched a.b.example.com (2): *.example.com matched example.com. What security problems exist with (1) and/or (2) that are solved by following the rules of 2818? Anything more than preventing a single * from matching the entire internet? -- Chris From yngve@opera.com Tue May 1 05:06:30 2012 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 4128021E8048 for ; Tue, 1 May 2012 05:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.789 X-Spam-Level: ** X-Spam-Status: No, score=2.789 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SPOOF_COM2COM=2.536, SARE_SPOOF_COM2OTH=2.536, SPOOF_COM2COM=2.272, SPOOF_COM2OTH=2.044] 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 oJtdnTjuFNIu for ; Tue, 1 May 2012 05:06:29 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1166C21F855A for ; Tue, 1 May 2012 05:06:21 -0700 (PDT) Received: from acorna.invalid.invalid (106.170.202.84.customer.cdi.no [84.202.170.106]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q41C6Gun010879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 1 May 2012 12:06:17 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org References: Date: Tue, 01 May 2012 14:06:19 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: User-Agent: Opera Mail/10.63 (Win32) Subject: Re: [TLS] RFC 2818 wildcard rationale 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, 01 May 2012 12:06:30 -0000 On Tue, 01 May 2012 13:45:58 +0200, Chris Richardson wrote: > RFC 2818 states: > > Names may contain the wildcard > character * which is considered to match any single domain name > component or component fragment. E.g., *.a.com matches foo.a.com but > not bar.foo.a.com. > > I was trying to figure out the rationale behind this, but have been > unable to do so. I was hoping someone could enlighten me. > > Suppose that: > (1): *.example.com matched a.b.example.com > (2): *.example.com matched example.com. > > What security problems exist with (1) and/or (2) that are solved by > following the rules of 2818? Anything more than preventing a single * > from matching the entire internet? Regarding #1, if * matched multiple labels, it would match www.yourbank.com.whatever.example.com, which would be a very bad thing since it can mislead users into thinking that they are visiting "www.yourbank.com". Regarding #2, I don't think that would introduce any real badness, except having to edit the rulestring, which make already complex logic more complex, and more likely to fail an unsecure manner (there is also the fact that you can have "f*.example.com", which should not allow #2 to be generated, causing more complexity). However, adding a separate rule for "example.com" in the SAN field is very simple. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 ******************************************************************** From stpeter@stpeter.im Thu May 3 15:04:08 2012 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 728C021F863D for ; Thu, 3 May 2012 15:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.904 X-Spam-Level: X-Spam-Status: No, score=-97.904 tagged_above=-999 required=5 tests=[AWL=-4.693, BAYES_00=-2.599, SARE_SPOOF_COM2COM=2.536, SARE_SPOOF_COM2OTH=2.536, SPOOF_COM2COM=2.272, SPOOF_COM2OTH=2.044, 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 T4gyz7A0aJNB for ; Thu, 3 May 2012 15:04:07 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7233921F8686 for ; Thu, 3 May 2012 15:04:07 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 63FEC40058; Thu, 3 May 2012 16:19:09 -0600 (MDT) Message-ID: <4FA300D6.5060709@stpeter.im> Date: Thu, 03 May 2012 16:04:06 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Yngve N. Pettersen (Developer Opera Software ASA)" References: In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] RFC 2818 wildcard rationale 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, 03 May 2012 22:04:08 -0000 On 5/1/12 6:06 AM, Yngve N. Pettersen (Developer Opera Software ASA) wrote: > On Tue, 01 May 2012 13:45:58 +0200, Chris Richardson > wrote: > >> RFC 2818 states: >> >> Names may contain the wildcard >> character * which is considered to match any single domain name >> component or component fragment. E.g., *.a.com matches foo.a.com but >> not bar.foo.a.com. >> >> I was trying to figure out the rationale behind this, but have been >> unable to do so. I was hoping someone could enlighten me. >> >> Suppose that: >> (1): *.example.com matched a.b.example.com >> (2): *.example.com matched example.com. >> >> What security problems exist with (1) and/or (2) that are solved by >> following the rules of 2818? Anything more than preventing a single * >> from matching the entire internet? > > Regarding #1, if * matched multiple labels, it would match > www.yourbank.com.whatever.example.com, which would be a very bad thing > since it can mislead users into thinking that they are visiting > "www.yourbank.com". True. But * matches only the left-most label, so a.b.example.com doesn't match *.example.com. Peter -- Peter Saint-Andre https://stpeter.im/ From chris@randomnonce.org Thu May 3 21:22:03 2012 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 2449121F86BE for ; Thu, 3 May 2012 21:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.867 X-Spam-Level: ** X-Spam-Status: No, score=2.867 tagged_above=-999 required=5 tests=[AWL=-5.844, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-1, SARE_SPOOF_COM2COM=2.536, SARE_SPOOF_COM2OTH=2.536, SPOOF_COM2COM=2.272, SPOOF_COM2OTH=2.044] 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 KAQJzSATT80W for ; Thu, 3 May 2012 21:22:01 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 515CD21F8566 for ; Thu, 3 May 2012 21:22:01 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so4032242obb.31 for ; Thu, 03 May 2012 21:22:01 -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:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=oRKNEY2sBZhjJ6aN65KW8uOXYAmbevIYwHXvoKt8j1w=; b=KHLxxotYNBnHkNhqI4DQKrBydajELBFCA7mL6p5l1R1xafrc+nchCipsUXIz7JX86O KJVYC0R8kc5VUXDZYgTBMY9/ObiYYarG5HpcOGWM1vnNLWS/HxPaQb7By5aWWzFX0jdP HKvxEx6m6FAJvKuggvexHxHKTbcBJSiNGAXGP4Btplzw40IIvy9vl66vxmWc8Yz6WvOx 6RfnDGeEEK339EIAq1rbCbKobjfkNTu2au9kCRFZofq0ks9TKt7MJRWRcUJImW+/9FZo 95tDgUPjv7JYjMtafBjP4/gBaS9VI187fSrYfleW2guYgaUgWYJ+xK/2l2XdVpSmsjMC g3TA== MIME-Version: 1.0 Received: by 10.60.22.234 with SMTP id h10mr3779353oef.54.1336105320977; Thu, 03 May 2012 21:22:00 -0700 (PDT) Received: by 10.182.69.138 with HTTP; Thu, 3 May 2012 21:22:00 -0700 (PDT) X-Originating-IP: [203.47.135.74] In-Reply-To: References: Date: Fri, 4 May 2012 14:22:00 +1000 Message-ID: From: Chris Richardson To: "Yngve N. Pettersen (Developer Opera Software ASA)" , "tls@ietf.org List" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlGcu567gGKaPg9YL5jLftmUgoIhOCVdQJkGD/dyoOOOBLpeiqQcjOddWQ22NlZTdV8fdEZ Subject: Re: [TLS] RFC 2818 wildcard rationale 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, 04 May 2012 04:22:03 -0000 > Regarding #1, if * matched multiple labels, it would match > www.yourbank.com.whatever.example.com, which would be a very bad thing since > it can mislead users into thinking that they are visiting > "www.yourbank.com". Are there any circumstances under which an (individual/organization) is authorized to have a certificate for *.example.com, but is not authorized to have a certificate for www.yourbank.com.whatever.example.com? > Regarding #2, I don't think that would introduce any real badness, except > having to edit the rulestring, which make already complex logic more > complex, and more likely to fail an unsecure manner (there is also the fact > that you can have "f*.example.com", which should not allow #2 to be > generated, causing more complexity). However, adding a separate rule for > "example.com" in the SAN field is very simple. If both (1) and (2) were allowed, that would eliminate the need for wildcards which should simplify the logic. And out of curiousity, are there any real examples of f*.example.com certificates? Are there any circumstances under which that is a good idea? From marsh@extendedsubset.com Fri May 4 09:21:11 2012 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 C6DF221F85B8 for ; Fri, 4 May 2012 09:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.297, 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 CrxBI1WJrCyP for ; Fri, 4 May 2012 09:21:10 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id A1EE521F8577 for ; Fri, 4 May 2012 09:21:10 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SQLFm-000OlY-6Y for tls@ietf.org; Fri, 04 May 2012 16:21:10 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 62DEB6067 for ; Fri, 4 May 2012 16:21:09 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/MIQgtE84A73Lfb+OXn7ixl8nMqRDOVak= Message-ID: <4FA401F7.5060003@extendedsubset.com> Date: Fri, 04 May 2012 11:21:11 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 04 May 2012 16:21:11 -0000 I would appreciate it if the participants of the TLS WG will give this draft a reading and serious consideration to taking it up as a work item: ------------------------------ http://datatracker.ietf.org/doc/draft-ray-tls-encrypted-handshake/ A new version of I-D, draft-ray-tls-encrypted-handshake-00.txt has been successfully submitted by Marsh Ray and posted to the IETF repository. Filename: draft-ray-tls-encrypted-handshake Revision: 00 Title: Transport Layer Security (TLS) Encrypted Handshake Creation date: 2012-05-04 WG ID: Individual Submission Number of pages: 18 Abstract: This specification defines a Transport Layer Security (TLS) extension which allows endpoints to negotiate the use of encryption with forward secrecy at the beginning of the handshake. Two levels of functionality are defined. Implementations are free to support one or both levels, with the first level incurring no additional computational or round-trip overhead. The TLS cryptographic calculations are unchanged. ------------------------------ This draft is motivated by the discussions in recent weeks, when some related issues came up in a similar context: * AGL et al. have some particular requirements for the handshake when using the NP(N)/SPDY feature. They really need confidentiality in negotiating the next protocol but they cannot afford the overhead of even one extra round trip (let alone renegotiation). I would like for them to be able to implement NP(N) in an RFC-defined way. * When coupled with the RFC 4680 'TLS Handshake Message for Supplemental Data' that Martin Rex pointed out, it provides a powerful and very general way of negotiating features under encryption. It could possible enable new features. * Alternatively, we could view this as a round-trip-saving optimization for certain handshake operations that really do need encryption. * It allows to encrypt the client certificate without renegotiation, magic cipher suite values, or a bunch of new protocol that isn't useful for anything else. * I watched a fascinating presentation from the Tor project https://www.youtube.com/watch?v=GwMr8Xl7JMQ Unfortunately, they are having to minimize their dependence on TLS because it's so easy to DoS selectively. I don't know if this proposal will make TLS suitable for Tor again, but I do think it represents a shortcoming of the protocol which deserves fixing. * There's simply no reason TLS needs to leak so much plaintext. * I believe it may help a little with the issue Nikos Mavrogiannopoulos and I were discussing, where an attacker is able to trick the client into interpreting the server's signed key exchange parameters as the wrong type of structure. * To the implementers in the group: don't be fooled, it's not as big a change as it looks! I just tried to be extra careful to describe it step-by-step in the spec. Did I mention it doesn't change the crypto calculations? Thanks, - Marsh From agl@google.com Fri May 4 09:45:37 2012 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 418F021F861B for ; Fri, 4 May 2012 09:45:37 -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 mmVZdYmJv9RN for ; Fri, 4 May 2012 09:45:36 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 60C1521F861A for ; Fri, 4 May 2012 09:45:36 -0700 (PDT) Received: by yhq56 with SMTP id 56so3558635yhq.31 for ; Fri, 04 May 2012 09:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=+QOdJZn7d5fO5X0iD+CbZvr5JNLA4pNB9xaQm54goMI=; b=JQ7UDVT3m8pIpTGN7nmJlTk32DWDBZ+T5YAC2I6NRwKdMiEo+WxECMI/O55V1j64Fd GvHhcKRZWw+6aFh/KM47SF+YYfQM69WHoISFjWhUmvWIwS5z886yafGwfWXsEYZxfCVl ntMS9UMAGYf63v9oZJZ+vlZK1+VjnVOITTeQNzz2Wpt8kMdLcsJMaOzrydx2rIK+BfCl KWBnkexgiG09P/QXqUdMVztHOuJEkWfYa7GvKnZYldTzvXm0eWrMkhGBytRgcqXMX1xU WBFt81Gf0PWt8p1qWyh3/bdCnG+wfKOmF5+s6v0H1OgtVAt9jez1it08hPIb7GhuVKA9 fbow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=+QOdJZn7d5fO5X0iD+CbZvr5JNLA4pNB9xaQm54goMI=; b=C/sTNhpf/Bu2oWc1tsPeFn1JhW46uDos3j9fOkYXm1qvPefAcBF5mIk7WA1BojH4p2 IWYJa/N30lydw4kjU9WneaIz9fynt5gdDLPJyyM45/FG1Bro+PNDfHF6CH0j+E1hnYyX RuPHZmUfqX366YN03lzZ/iKG85wqGAzriVzX/OMUJ8OZQU752DPnEq49uylJTFvTccMY JUDofp2lL03FKr9xfFhr8YNIu5l1vwlYcb2dRmRdNlrAOFv7Gioqf/1lFd9ANm30JDWs aqIcQKcevPTPXk/ZLTzsJhTak9z6krzIJrfWJvT+cYHHaFLkfkclCxboJGowkciWbf8Z tDNw== Received: by 10.60.3.34 with SMTP id 2mr926605oez.27.1336149440691; Fri, 04 May 2012 09:37:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.3.34 with SMTP id 2mr926598oez.27.1336149440591; Fri, 04 May 2012 09:37:20 -0700 (PDT) Sender: agl@google.com Received: by 10.182.98.193 with HTTP; Fri, 4 May 2012 09:37:20 -0700 (PDT) In-Reply-To: <4FA401F7.5060003@extendedsubset.com> References: <4FA401F7.5060003@extendedsubset.com> Date: Fri, 4 May 2012 12:37:20 -0400 X-Google-Sender-Auth: _vF_c9Gtc-00gKnTA_P4pYEIfc4 Message-ID: From: Adam Langley To: Marsh Ray Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmBWGPXg/w9heQcKYZMhtFlyAxb8IlWPnhjrm3RIUoLW7mwhSUgmqoKi6TE1akL36Od+8nFm0cK4SuXxCOYZZIBHtmD8QjMreBZh4G2eWZYwdILhl/6EWIC4SSkN2orlXurNqp4 Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 04 May 2012 16:45:37 -0000 On Fri, May 4, 2012 at 12:21 PM, Marsh Ray wrote: > I would appreciate it if the participants of the TLS WG will give this draft > a reading and serious consideration to taking it up as a work item: Marsh was good enough to share an early draft of this with me. For now I would like to gloss over the details of the proposal in order to concentrate on the intention: I believe that this would be beneficial. It rather neatly solves the encrypted client certificates problem and, probably, others in the future. It would allow NPN to encrypt both the server's protocols and the client's selection without additional round trips. I would like to commend the idea to the working group. Cheers AGL From mrex@sap.com Fri May 4 10:51:18 2012 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 2611A21F8570 for ; Fri, 4 May 2012 10:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.284 X-Spam-Level: X-Spam-Status: No, score=-4.284 tagged_above=-999 required=5 tests=[AWL=-5.723, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_OFF=2.3, RCVD_IN_DNSWL_HI=-8, SARE_SPOOF_COM2COM=2.536, SARE_SPOOF_COM2OTH=2.536, SPOOF_COM2COM=2.272, SPOOF_COM2OTH=2.044] 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 Snr15k9S2tVt for ; Fri, 4 May 2012 10:51:17 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 273CF21F856F for ; Fri, 4 May 2012 10:51:16 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q44HpEWR010655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 19:51:14 +0200 (MEST) From: Martin Rex Message-Id: <201205041751.q44HpEKf014471@fs4113.wdf.sap.corp> To: chris@randomnonce.org (Chris Richardson) Date: Fri, 4 May 2012 19:51:14 +0200 (MEST) In-Reply-To: from "Chris Richardson" at May 4, 12 02:22:00 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] RFC 2818 wildcard rationale 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: Fri, 04 May 2012 17:51:18 -0000 Chris Richardson wrote: > > > Regarding #1, if * matched multiple labels, it would match > > www.yourbank.com.whatever.example.com, which would be a very bad thing since > > it can mislead users into thinking that they are visiting > > "www.yourbank.com". > > Are there any circumstances under which an (individual/organization) > is authorized to have a certificate for *.example.com, but is not > authorized to have a certificate for > www.yourbank.com.whatever.example.com? That is an "interesting question" (not on DANE's radar so far). Being authorized (as being the domain owner) does not mean that every commercial/public CA will issue a TLS server certificate for such a name. AFAIK, at least some of the CAs will refuse to issue TLS server certs to owners of domains that could be used for typo-squatting high-profile sites/domains. The issue that Yngve mentioned is about the common behaviour of DNS resolvers to have a "default domain" or "searchlist" which they use to complete a hostname that does not have a trailing dot before trying to resolve that name via DNS. > > > Regarding #2, I don't think that would introduce any real badness, except > > having to edit the rulestring, which make already complex logic more > > complex, and more likely to fail an unsecure manner (there is also the fact > > that you can have "f*.example.com", which should not allow #2 to be > > generated, causing more complexity). However, adding a separate rule for > > "example.com" in the SAN field is very simple. > > If both (1) and (2) were allowed, that would eliminate the need for > wildcards which should simplify the logic. > > And out of curiousity, are there any real examples of f*.example.com > certificates? Are there any circumstances under which that is a good > idea? There is a huge variety of different behaviour in the installed base with respect to wildcard matching from rfc2818 Section 3.1 server endpoint identification. Adding more options at this point would only lead to further divergence of the behaviour (=less predictable) in the installed base, so I consider it a bad idea. Limiting the options to what is easy to understand and explain, and supported by a significant fraction of the installed base, seems much more reasonable at this point. -Martin From paul.hoffman@vpnc.org Fri May 4 10:58:28 2012 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 E712521F859A for ; Fri, 4 May 2012 10:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, 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 m8MM+Ng6no8G for ; Fri, 4 May 2012 10:58:27 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CCD9821F8596 for ; Fri, 4 May 2012 10:58:26 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q44HwPY7037803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 4 May 2012 10:58:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: Date: Fri, 4 May 2012 10:58:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1947EFE2-8850-43C3-9590-1D3D44B4B4AA@vpnc.org> References: To: tls@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [TLS] WGLC for draft-ietf-tls-oob-pubkey-03.txt 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, 04 May 2012 17:58:28 -0000 On Apr 25, 2012, at 5:35 PM, Joe Salowey wrote: > This is an announcement of working group last call for = draft-ietf-tls-oob-pubkey-03.txt. Please complete reviews and send = comments to the TLS list by Friday May 18, 2012. =20 I support this document moving forwards, but it requires some = significant changes first. First, the document needs to say "Updates: 6091" because it very much = updates 6091. More importantly, the client auth text added in the last round was: 3.5. Client authentication Client authentication by the TLS server is supported only through authentication of the received client SubjectPublicKeyInfo via an out-of-band method This is both wrong and insufficient. It is wrong in that the server might also authenticate the client = through a future TLSA-type protocol that handles user certificates, and = might also authenticate the client through LDAP. The entire sentence can = be removed. It is insufficient because it does not say how the client should respond = if RawPublicKey certificates have been selected but the client does not = have a raw client certificate. I believe that an equivalent of the "empty_cert" used in RFC 6091 is = needed to be defined here and then used in wording such as: Therefore, this section should probably instead say: 3.5. Client Certificate This message is only sent in response to the certificate request message. The client certificate message is sent using the same formatting as the server certificate message, and it is also required to present a certificate that matches the negotiated certificate type. If RawPublicKey certificates have been selected and no = certificate is available from the client, then a certificate structure of type "empty_cert" that contains an RawPublicKey value MUST be sent. The server SHOULD respond with a "handshake_failure" fatal alert if client authentication is required. I hope this helps. --Paul Hoffman From paul.hoffman@vpnc.org Fri May 4 11:01:05 2012 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 B2F1221F859A for ; Fri, 4 May 2012 11:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, 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 SHpWQz3Dt-g9 for ; Fri, 4 May 2012 11:01:05 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2F42921F8566 for ; Fri, 4 May 2012 11:01:05 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q44I127V038095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 4 May 2012 11:01:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Fri, 4 May 2012 11:01:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <929471CE-9D7F-4497-8933-B64A56D0E20A@vpnc.org> References: <87pqauq4v6.fsf@latte.josefsson.org> To: Paul Wouters X-Mailer: Apple Mail (2.1257) Cc: Simon Josefsson , tls@ietf.org Subject: Re: [TLS] WGLC for draft-ietf-tls-oob-pubkey-03.txt 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, 04 May 2012 18:01:05 -0000 On Apr 26, 2012, at 10:57 AM, Paul Wouters wrote: > On Thu, 26 Apr 2012, Simon Josefsson wrote: >=20 >> Major concerns: >>=20 >> 1) Section 3.1 and 3.2 more or less duplicate section 3.1 and 3.2 of = RFC >> 6091. Wouldn't it be better to describe the RawPublicKey >> CertificateType alone, rather than duplicating the entire >> CertificateType extension? >=20 > I think you are right. This was originally done because it started as > a new TLS extension, and then also covered what has now been moved to > cached-objects. However, there is a good reason to leave the text as-is: this draft is = meant to be on standards track and RFC 6091 is an Informational RFC. In = order to make this document standards track, it probably needs to define = the format again. Alternately, the WG could simultaneously try to get RFC 6091 made = standards track and eliminate the duplication. I don't know if anyone = cares enough about OpenPGP certificates to do so; I certainly don't, = given that the OpenPGP WG never bothered to do specify enrollment = procedures for them. --Paul Hoffman From mike-list@pobox.com Fri May 4 11:49:21 2012 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 F2BA621F8575 for ; Fri, 4 May 2012 11:49:20 -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 bSC1qcHJuZ9F for ; Fri, 4 May 2012 11:49:20 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [74.115.168.62]) by ietfa.amsl.com (Postfix) with ESMTP id 05FD621F856F for ; Fri, 4 May 2012 11:49:19 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 163E496D3; Fri, 4 May 2012 14:49:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=+OdH86yA0aJv PGp6+8gY4/+fEvU=; b=duLbIcB2DhfNXioHWVSGn56w9VGkfC35y1TfYQVt6LQY l0D9w7ruKO1oS7Qsy59w1vmKTSQBRx0ekfGTOH4oQAMPB6MbTJTfDRLeA39cJj9l ehSsjTxnMzsMcrLuFDXZJVJGBHApf3l3S9LCjLY5826HTWHMMBQ7sl/RtV7aYY8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=w8cloq xAWSaTfCg9shMp+mQoBCJNqE2p6bQninIudVRrflliRMWQhHfkunTybSwPhggp/g sySVYTW4Moz379TuyTnIxCyCdW1OWtRB2Hk8EWtYE1jETblGCSqFbBNwZ8KoQsAB Lzu0hFdDYNfhLwRZsBmkWcPOGw3XaNtv3ueV0= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 0E5AC96D2; Fri, 4 May 2012 14:49:18 -0400 (EDT) Received: from iMac.local (unknown [68.104.126.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 4845296D1; Fri, 4 May 2012 14:49:17 -0400 (EDT) Message-ID: <4FA424A3.2010409@pobox.com> Date: Fri, 04 May 2012 11:49:07 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Marsh Ray References: <4FA401F7.5060003@extendedsubset.com> In-Reply-To: <4FA401F7.5060003@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: DA130642-9619-11E1-8C7B-8BEB728A0A4D-38729857!a-pb-sasl-sd.pobox.com Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 04 May 2012 18:49:21 -0000 Was it intentional to leave out the ChangeCipherSpecs that immediately precede Finished? I think they still need to be there. Mike Marsh Ray wrote: > > I would appreciate it if the participants of the TLS WG will give this > draft a reading and serious consideration to taking it up as a work item: > > ------------------------------ > http://datatracker.ietf.org/doc/draft-ray-tls-encrypted-handshake/ > > A new version of I-D, draft-ray-tls-encrypted-handshake-00.txt has been > successfully submitted by Marsh Ray and posted to the IETF repository. > > Filename: draft-ray-tls-encrypted-handshake > Revision: 00 > Title: Transport Layer Security (TLS) Encrypted Handshake > Creation date: 2012-05-04 > WG ID: Individual Submission > Number of pages: 18 > Abstract: > This specification defines a Transport Layer Security (TLS) extension > which allows endpoints to negotiate the use of encryption with > forward secrecy at the beginning of the handshake. Two levels of > functionality are defined. Implementations are free to support one > or both levels, with the first level incurring no additional > computational or round-trip overhead. The TLS cryptographic > calculations are unchanged. > ------------------------------ > > This draft is motivated by the discussions in recent weeks, when some > related issues came up in a similar context: > > * AGL et al. have some particular requirements for the handshake when > using the NP(N)/SPDY feature. They really need confidentiality in > negotiating the next protocol but they cannot afford the overhead of > even one extra round trip (let alone renegotiation). I would like for > them to be able to implement NP(N) in an RFC-defined way. > > * When coupled with the RFC 4680 'TLS Handshake Message for Supplemental > Data' that Martin Rex pointed out, it provides a powerful and very > general way of negotiating features under encryption. It could possible > enable new features. > > * Alternatively, we could view this as a round-trip-saving optimization > for certain handshake operations that really do need encryption. > > * It allows to encrypt the client certificate without renegotiation, > magic cipher suite values, or a bunch of new protocol that isn't useful > for anything else. > > * I watched a fascinating presentation from the Tor project > https://www.youtube.com/watch?v=GwMr8Xl7JMQ > Unfortunately, they are having to minimize their dependence on TLS > because it's so easy to DoS selectively. I don't know if this proposal > will make TLS suitable for Tor again, but I do think it represents a > shortcoming of the protocol which deserves fixing. > > * There's simply no reason TLS needs to leak so much plaintext. > > * I believe it may help a little with the issue Nikos Mavrogiannopoulos > and I were discussing, where an attacker is able to trick the client > into interpreting the server's signed key exchange parameters as the > wrong type of structure. > > * To the implementers in the group: don't be fooled, it's not as big a > change as it looks! I just tried to be extra careful to describe it > step-by-step in the spec. Did I mention it doesn't change the crypto > calculations? > > Thanks, > > - Marsh From marsh@extendedsubset.com Fri May 4 11:56:04 2012 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 A6B4A21F8567 for ; Fri, 4 May 2012 11:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, 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 mVlL5qBKF-pA for ; Fri, 4 May 2012 11:56:04 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF0021F8566 for ; Fri, 4 May 2012 11:56:04 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SQNff-000NLr-QB; Fri, 04 May 2012 18:56:03 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id CA4986082; Fri, 4 May 2012 18:56:02 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+0bhB0Al9LSeAY+TkYE/Nkzb6wkLr/Yx0= Message-ID: <4FA4264A.7070406@extendedsubset.com> Date: Fri, 04 May 2012 13:56:10 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Michael D'Errico References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> In-Reply-To: <4FA424A3.2010409@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 04 May 2012 18:56:04 -0000 On 05/04/2012 01:49 PM, Michael D'Errico wrote: > Was it intentional to leave out the ChangeCipherSpecs that immediately > precede Finished? I think they still need to be there. The intent was to move the CCS from late in the handshake to as soon as practical in the handshake without changing their meaning. So, yes. Are you saying just the CCS records still need to be there, or we really should plan to change the cipher a second time? Why? - Marsh From nico@cryptonector.com Fri May 4 12:22:33 2012 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 9FCA821F85D0 for ; Fri, 4 May 2012 12:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 8wlSLr1n5YlA for ; Fri, 4 May 2012 12:22:32 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id C632221F85CE for ; Fri, 4 May 2012 12:22:32 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 5488A778142 for ; Fri, 4 May 2012 12:22:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=hfeZBNWKYDRFf70Dtiwite5zzXSYGACfAKaM85+dYDRX b/pbVgGyCUG4Ad/9qwReUrVc/aFWisx342ti/pgbEVPQSRoPj1yk36mTPTR+t2ym 6pdsEDQG9LbfFjtOaLgK/Sf7zIW1TneghVi9Fhe9gZH7HnN4Pugd0E0YP3fOzVs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=iPuZJ0tx5+vbFLDJlKr8/sSHHzw=; b=WvTovs53TT+ mHpC9KHMYhIPWgtRKeXgvNSIhau2go6jSIq0svotV6oFc+7iWw7fDj8rm86Szabm MA8U7Y48JiVhIcgsZ+4Y4qhXI4YEfvmUviScU4lID+3ILfFBKHpwrmaHM4awBUFS UQldLoozuJ+ZoDzR07cYzwUEyHigLk98= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 4440477813B for ; Fri, 4 May 2012 12:22:32 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so4295168pbc.31 for ; Fri, 04 May 2012 12:22:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.71 with SMTP id ic7mr21763828pbc.34.1336159351903; Fri, 04 May 2012 12:22:31 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Fri, 4 May 2012 12:22:31 -0700 (PDT) In-Reply-To: <4FA424A3.2010409@pobox.com> References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> Date: Fri, 4 May 2012 14:22:31 -0500 Message-ID: From: Nico Williams To: "Michael D'Errico" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 04 May 2012 19:22:33 -0000 On Fri, May 4, 2012 at 1:49 PM, Michael D'Errico wrot= e: > Was it intentional to leave out the ChangeCipherSpecs that immediately > precede Finished? =C2=A0I think they still need to be there. It's not left out. It's moved earlier in the exchange, and that's the whole point: encrypt as early as possible. Nico -- From ynir@checkpoint.com Fri May 4 14:13:28 2012 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 13C4721F8472 for ; Fri, 4 May 2012 14:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.357 X-Spam-Level: X-Spam-Status: No, score=-10.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 o1A8BhG8Y12h for ; Fri, 4 May 2012 14:13:27 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B936921F844F for ; Fri, 4 May 2012 14:13:26 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q44LDIHu030592; Sat, 5 May 2012 00:13:19 +0300 X-CheckPoint: {4FA4542A-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sat, 5 May 2012 00:13:17 +0300 From: Yoav Nir To: Marsh Ray Date: Sat, 5 May 2012 00:13:20 +0300 Thread-Topic: [TLS] draft-ray-tls-encrypted-handshake-00.txt Thread-Index: Ac0qOrkwcQrdq1C1TDuqeI7+GCLPbw== Message-ID: <6296DC06-A0A4-4A75-9FCC-AE0B402CBD20@checkpoint.com> References: <4FA401F7.5060003@extendedsubset.com> In-Reply-To: <4FA401F7.5060003@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11f30c4be1fa5f8968fc57728da2aada2d93cd1c5e Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 04 May 2012 21:13:28 -0000 Hi Marsh. Interesting stuff. There have been several ideas for moving parts of the ha= ndshake to after the CCS. There's NPN, identity protection, and even the EA= P-in-TLS draft. Your draft takes care of the identity protection, but accep= ting it would also make the others easier. I think this moves TLS to be more like IKE, where encryption of the IKE pro= tocol precedes everything else (authentication, configuration, and IPsec se= tup) IMO this is a huge change to the TLS state machine. Much bigger than the di= ff between TLS 1.1 and 1.0, and bigger than the difference between 1.2 and = 1.1. This should not be an extension but a new version number. You would st= ill need an extension to carry the extra information (if we want backwards = compatibility), but negotiating this capability should be done at the versi= on level. Yoav On May 4, 2012, at 7:21 PM, Marsh Ray wrote: >=20 > I would appreciate it if the participants of the TLS WG will give this=20 > draft a reading and serious consideration to taking it up as a work item: >=20 > ------------------------------ > http://datatracker.ietf.org/doc/draft-ray-tls-encrypted-handshake/ >=20 > A new version of I-D, draft-ray-tls-encrypted-handshake-00.txt has been=20 > successfully submitted by Marsh Ray and posted to the IETF repository. >=20 > Filename: draft-ray-tls-encrypted-handshake > Revision: 00 > Title: Transport Layer Security (TLS) Encrypted Handshake Creation=20 > date: 2012-05-04 > WG ID: Individual Submission > Number of pages: 18 > Abstract: > This specification defines a Transport Layer Security (TLS) extension > which allows endpoints to negotiate the use of encryption with > forward secrecy at the beginning of the handshake. Two levels of > functionality are defined. Implementations are free to support one > or both levels, with the first level incurring no additional > computational or round-trip overhead. The TLS cryptographic > calculations are unchanged. > ------------------------------ >=20 > This draft is motivated by the discussions in recent weeks, when some=20 > related issues came up in a similar context: >=20 > * AGL et al. have some particular requirements for the handshake when=20 > using the NP(N)/SPDY feature. They really need confidentiality in=20 > negotiating the next protocol but they cannot afford the overhead of=20 > even one extra round trip (let alone renegotiation). I would like for=20 > them to be able to implement NP(N) in an RFC-defined way. >=20 > * When coupled with the RFC 4680 'TLS Handshake Message for Supplemental= =20 > Data' that Martin Rex pointed out, it provides a powerful and very=20 > general way of negotiating features under encryption. It could possible=20 > enable new features. >=20 > * Alternatively, we could view this as a round-trip-saving optimization=20 > for certain handshake operations that really do need encryption. >=20 > * It allows to encrypt the client certificate without renegotiation,=20 > magic cipher suite values, or a bunch of new protocol that isn't useful=20 > for anything else. >=20 > * I watched a fascinating presentation from the Tor project > https://www.youtube.com/watch?v=3DGwMr8Xl7JMQ > Unfortunately, they are having to minimize their dependence on TLS=20 > because it's so easy to DoS selectively. I don't know if this proposal=20 > will make TLS suitable for Tor again, but I do think it represents a=20 > shortcoming of the protocol which deserves fixing. >=20 > * There's simply no reason TLS needs to leak so much plaintext. >=20 > * I believe it may help a little with the issue Nikos Mavrogiannopoulos=20 > and I were discussing, where an attacker is able to trick the client=20 > into interpreting the server's signed key exchange parameters as the=20 > wrong type of structure. >=20 > * To the implementers in the group: don't be fooled, it's not as big a=20 > change as it looks! I just tried to be extra careful to describe it=20 > step-by-step in the spec. Did I mention it doesn't change the crypto=20 > calculations? >=20 > Thanks, >=20 > - Marsh > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 > Scanned by Check Point Total Security Gateway. From nico@cryptonector.com Fri May 4 14:53:47 2012 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 3202521F84EF for ; Fri, 4 May 2012 14:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 PH0bpYl6DURt for ; Fri, 4 May 2012 14:53:46 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id B2AAC21F84EB for ; Fri, 4 May 2012 14:53:46 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 520841DE060 for ; Fri, 4 May 2012 14:53:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=f8J4mjheb04LlE+0yLrF+HotfBLwPxj7bGD9Qfw2xqNW gJmSv4QSNUqW8EU1/n/K1Rf6J0GAkA229XoDQzILDG5/PaY9GyLggdvcJX9iYtAI 3a5T+7BPMrf7F7Mgj7mb1bbmy1L0xmE86/uleoG8j8uOIJS2EbBXAG4Y2CaE2oE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=Ghm03S7kkV0VvlT1x0n+Hw3ckVU=; b=af9mmDkFjV7 BaGf5+Ps5TCko4vI/bpQtp46UeeNWbcBBxvNX1PbTEkHzfiwAyA+cKoPFFCJGu1L 7hJgk5bijYs8ObIjGsMjd4RND3iUBeQPvkQhodvXYb24vOcaCuVZC5d9H/v1wWJv JKWvcATaeV+lYb8SsdiAAmRTWrnZTLsY= Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 593FF1DE070 for ; Fri, 4 May 2012 14:53:45 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2817838vbb.31 for ; Fri, 04 May 2012 14:53:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.155.131 with SMTP id s3mr933913vcw.15.1336168424646; Fri, 04 May 2012 14:53:44 -0700 (PDT) Received: by 10.220.7.65 with HTTP; Fri, 4 May 2012 14:53:44 -0700 (PDT) In-Reply-To: <6296DC06-A0A4-4A75-9FCC-AE0B402CBD20@checkpoint.com> References: <4FA401F7.5060003@extendedsubset.com> <6296DC06-A0A4-4A75-9FCC-AE0B402CBD20@checkpoint.com> Date: Fri, 4 May 2012 16:53:44 -0500 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 04 May 2012 21:53:47 -0000 On Fri, May 4, 2012 at 4:13 PM, Yoav Nir wrote: > IMO this is a huge change to the TLS state machine. Much bigger than the = diff between TLS 1.1 and 1.0, and bigger than the difference between 1.2 an= d 1.1. This should not be an extension but a new version number. You would = still need an extension to carry the extra information (if we want backward= s compatibility), but negotiating this capability should be done at the ver= sion level. But the experience we've had with new versions doesn't fill one with confidence that a new version can be deployed quickly at all. Extensions have been much less problematic. I think it'd be best to introduce new versions only for dramatic changes that require downgrade protection. (I realize that's not a great description of the rule I have in mind.) Nico -- From nico@cryptonector.com Fri May 4 14:58:57 2012 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 1C6D421F84E1 for ; Fri, 4 May 2012 14:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 tUszPqHAlNLy for ; Fri, 4 May 2012 14:58:56 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6387121F84D8 for ; Fri, 4 May 2012 14:58:56 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 1B335264005 for ; Fri, 4 May 2012 14:58:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=P710ZO6sVfylZvjr0HwHn0pNzHYEpDXhc1FMYtdI2DGo LYkierl9EozJ3RbC4ECTtJ+tOxs6UfgrKd0cvds0vTzerq06CU9cqWFYBw+EeSgJ +ImQq5ix+5m8IwMQiTqWuMv+P3gV5YO3k+/SSLeC1VIcUezu7E2KDGJy3axs7P0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=SxsqcPQBWLu9/Mf3TYk4HTEobzY=; b=AtxyhGw5LU4 lbr+zN46NEBGo6gLOOk5jK50OLmJ4lZtY02mKz23gJYr6eO33e4lx7koOXKHUIfy wS+eOqpdYlJy4LMGJjfIXVxQ59tv9zpz3O/Yv1l6sj8Ml+pupmvvktW+p1ULHPXK WtxMDQiXb2tNtLrnM7ZU+lfPKcBdOvAk= Received: from mail-vx0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id E3D3326405D for ; Fri, 4 May 2012 14:58:55 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2823060vcb.31 for ; Fri, 04 May 2012 14:58:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.4.75 with SMTP id 11mr4872708vcq.61.1336168735307; Fri, 04 May 2012 14:58:55 -0700 (PDT) Received: by 10.220.7.65 with HTTP; Fri, 4 May 2012 14:58:54 -0700 (PDT) In-Reply-To: References: <201204190356.q3J3uSbT023588@fs4113.wdf.sap.corp> <4F96B94B.8050900@free.fr> Date: Fri, 4 May 2012 16:58:54 -0500 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance on multi-stapling 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, 04 May 2012 21:58:57 -0000 On Tue, Apr 24, 2012 at 1:14 PM, Yoav Nir wrote: > On Apr 24, 2012, at 5:39 PM, Nico Williams wrote: >> On Tue, Apr 24, 2012 at 9:31 AM, Jean-Marc Desperrier w= rote: >>> They make time synchronization problems at lot more acute. >>> This can be interpreted as "causing them to choke", I'd expect the scal= e of >>> the problem to be larger than the one with false start. >> >> They don't have to be short-lived, just fresh. > > I don't understand the distinction. If a relying party (in our case, the = browser) requires that certificates are at most 24 hours old (presumably ca= lculated by subtracting the current time from the notBefore field), what di= fference does it make if the notAfter field is 5 years in the future? You're right. But you know, we're talking about freshness requirements measured in days. I don't care about clients whose clocks are that far out of sync. A client whose clock is way behind current time would find many certs appear as post-dated -- a great clue to tell the user to check the clock. A client whose clock is way ahead of current time would find many certs to be insufficiently fresh, and if those certs had an extension indicating the intention to use them only while fresh then that too would be a great clue to tell the user to check the clock. I think fresh certs have significant advantages over OCSP stapling. Nico --=20 Nico -- From mrex@sap.com Fri May 4 15:00:51 2012 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 9FE6A21F84E1 for ; Fri, 4 May 2012 15:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.065 X-Spam-Level: X-Spam-Status: No, score=-10.065 tagged_above=-999 required=5 tests=[AWL=0.184, 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 75c9o9boWlgT for ; Fri, 4 May 2012 15:00: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 7DF5121F84D8 for ; Fri, 4 May 2012 15:00:50 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q44M0k9m009192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 May 2012 00:00:46 +0200 (MEST) From: Martin Rex Message-Id: <201205042200.q44M0jY0028398@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Sat, 5 May 2012 00:00:45 +0200 (MEST) In-Reply-To: <1947EFE2-8850-43C3-9590-1D3D44B4B4AA@vpnc.org> from "Paul Hoffman" at May 4, 12 10:58:25 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] WGLC for draft-ietf-tls-oob-pubkey-03.txt 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: Fri, 04 May 2012 22:00:51 -0000 Paul Hoffman wrote: > > More importantly, the client auth text added in the last round was: > > 3.5. Client authentication > > Client authentication by the TLS server is supported only through > authentication of the received client SubjectPublicKeyInfo via an > out-of-band method > > This is both wrong and insufficient. I believe it is acceptable and more correct than your proposed alternative. RFC6091 does _not_ permit different certificates types for client and server, so this will not fit into the extensibility provided by rfc6091. If you want to allow an assymetric authentication scheme (i.e. Server->client OOB in combination with client->server X.509), then it will be additionally necessary either to seperately negotiate the type of client "certificate" and require to redefine both, the CertificateRequest handshake message and the client's Certificate Handshake message to distinguish which client certificate type(s) the server is offering and which client "certificate" type the client has chosen to use. ... at which point it is no longer possible to make this an extension to rfc6091. -Martin From paul.hoffman@vpnc.org Fri May 4 15:07:00 2012 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 5DD5721F8552 for ; Fri, 4 May 2012 15:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, 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 PTVRLCIZRdZS for ; Fri, 4 May 2012 15:07:00 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DF31321F8551 for ; Fri, 4 May 2012 15:06:59 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q44M6wcU062177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 4 May 2012 15:06:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201205042200.q44M0jY0028398@fs4113.wdf.sap.corp> Date: Fri, 4 May 2012 15:06:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <62F11982-64E4-4EDE-B8E3-E26F898D9763@vpnc.org> References: <201205042200.q44M0jY0028398@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1257) Cc: tls@ietf.org Subject: Re: [TLS] WGLC for draft-ietf-tls-oob-pubkey-03.txt 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, 04 May 2012 22:07:00 -0000 On May 4, 2012, at 3:00 PM, Martin Rex wrote: > Paul Hoffman wrote: >>=20 >> More importantly, the client auth text added in the last round was: >>=20 >> 3.5. Client authentication >>=20 >> Client authentication by the TLS server is supported only through >> authentication of the received client SubjectPublicKeyInfo via an >> out-of-band method >>=20 >> This is both wrong and insufficient. >=20 > I believe it is acceptable and more correct than your proposed > alternative. >=20 > RFC6091 does _not_ permit different certificates types for > client and server, so this will not fit into the extensibility = provided > by rfc6091. Ummmm, I never said that it did. My proposed alternative wording was to = deal with exactly the case of both sides using raw keys. Why did you = think different? > If you want to allow an assymetric authentication scheme... I do not. --Paul Hoffman From mrex@sap.com Fri May 4 16:34:14 2012 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 0C7B121F84FF for ; Fri, 4 May 2012 16:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.071 X-Spam-Level: X-Spam-Status: No, score=-10.071 tagged_above=-999 required=5 tests=[AWL=0.178, 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 oJrTmkjlSFdD for ; Fri, 4 May 2012 16:34:13 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 37D5121F8539 for ; Fri, 4 May 2012 16:34:12 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q44NYBPU002424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 May 2012 01:34:11 +0200 (MEST) From: Martin Rex Message-Id: <201205042334.q44NY9go003966@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Sat, 5 May 2012 01:34:09 +0200 (MEST) In-Reply-To: <62F11982-64E4-4EDE-B8E3-E26F898D9763@vpnc.org> from "Paul Hoffman" at May 4, 12 03:06:58 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] WGLC for draft-ietf-tls-oob-pubkey-03.txt 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: Fri, 04 May 2012 23:34:14 -0000 Paul Hoffman wrote: > > Martin Rex wrote: > > > > I believe it is acceptable and more correct than your proposed > > alternative. > > > > RFC6091 does _not_ permit different certificates types for > > client and server, so this will not fit into the extensibility provided > > by rfc6091. > > Ummmm, I never said that it did. > My proposed alternative wording was to deal with exactly the case of > both sides using raw keys. Why did you think different? Ooops, I'm sorry. Your proposed replacement text is actually much less problematic than the description heading it (and which I had better quoted): >>> >>> This is both wrong and insufficient. >>> >>> It is wrong in that the server might also authenticate the client >>> through a future TLSA-type protocol that handles user certificates, >>> and might also authenticate the client through LDAP. The entire >>> sentence can be removed. [...] >>> 3.5. Client Certificate >>> >>> This message is only sent in response to the certificate request >>> message. The client certificate message is sent using the same >>> formatting as the server certificate message, and it is also required >>> to present a certificate that matches the negotiated certificate >>> type. If RawPublicKey certificates have been selected and no certificate >>> is available from the client, then a certificate structure of type >>> "empty_cert" that contains an RawPublicKey value MUST be sent. >>> The server SHOULD respond with a "handshake_failure" fatal alert if >>> client authentication is required. What is confusing in your description is "empty_cert" that contains a RawPublicKey value I believe wie need another codepoint in the rfc6091 enumerator OpenPGPCertDescriptorType: enum { empty_cert(1), subkey_cert(2), subkey_cert_fingerprint(3), + x509_spki(4), (255) } OpenPGPCertDescriptorType; because "empty_cert" is not meant to be extensible in rfc6091: uint24 OpenPGPEmptyCert = 0; struct { OpenPGPCertDescriptorType descriptorType; select (descriptorType) { case empty_cert: OpenPGPEmptyCert; case subkey_cert: OpenPGPSubKeyCert; case subkey_cert_fingerprint: OpenPGPSubKeyCertFingerprint; } } Certificate; Btw. -oob Section 3.3 should be modified similar to rfc6091 section 3.4: current: 3.3. Certificate Request The semantics of this message remain the same as in the TLS specification. new: 3.3. Certificate Request The semantics of this message remain the same as in the TLS specification. However, if this message is sent, and the negotiated certificate type is RawPublicKey, then the "certificate_authorities" list MUST be empty. -Martin From mrex@sap.com Fri May 4 16:49:30 2012 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 3191D21F84BF for ; Fri, 4 May 2012 16:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.073 X-Spam-Level: X-Spam-Status: No, score=-10.073 tagged_above=-999 required=5 tests=[AWL=0.176, 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 kkedEAozfDUk for ; Fri, 4 May 2012 16:49:29 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6E54521F84B9 for ; Fri, 4 May 2012 16:49:29 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q44NnR1M023283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 May 2012 01:49:27 +0200 (MEST) From: Martin Rex Message-Id: <201205042349.q44NnLe9004778@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Sat, 5 May 2012 01:49:21 +0200 (MEST) In-Reply-To: <201205042334.q44NY9go003966@fs4113.wdf.sap.corp> from "Martin Rex" at May 5, 12 01:34:09 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [TLS] WGLC for draft-ietf-tls-oob-pubkey-03.txt 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: Fri, 04 May 2012 23:49:30 -0000 following up to myself... Martin Rex wrote: > > Paul Hoffman wrote: > > > > Martin Rex wrote: > > > > > > I believe it is acceptable and more correct than your proposed > > > alternative. > > > > > > RFC6091 does _not_ permit different certificates types for > > > client and server, so this will not fit into the extensibility provided > > > by rfc6091. > > > > Ummmm, I never said that it did. > > My proposed alternative wording was to deal with exactly the case of > > both sides using raw keys. Why did you think different? > > Ooops, I'm sorry. > > Your proposed replacement text is actually much less problematic > than the description heading it (and which I had better quoted): > > >>> > >>> This is both wrong and insufficient. > >>> > >>> It is wrong in that the server might also authenticate the client > >>> through a future TLSA-type protocol that handles user certificates, > >>> and might also authenticate the client through LDAP. The entire > >>> sentence can be removed. > > [...] > > >>> 3.5. Client Certificate > >>> > >>> This message is only sent in response to the certificate request > >>> message. The client certificate message is sent using the same > >>> formatting as the server certificate message, and it is also required > >>> to present a certificate that matches the negotiated certificate > >>> type. If RawPublicKey certificates have been selected and no certificate > >>> is available from the client, then a certificate structure of type > >>> "empty_cert" that contains an RawPublicKey value MUST be sent. > >>> The server SHOULD respond with a "handshake_failure" fatal alert if > >>> client authentication is required. > > > What is confusing in your description is > "empty_cert" that contains a RawPublicKey value > > I believe wie need another codepoint in the rfc6091 enumerator > OpenPGPCertDescriptorType: Actually, the whole section defining the exact contents of the Certificate structure (->rfc6091 section 3.3) and its dependency/interaction with the TLS key exchange method is missing in tls-oob-pubkey-03. While it is certainly possible to create a simpler Certificate structure than rfc6091 section 3.3 (omitting the additional descriptor type) and selection, reusing that from 6091 would facilitate merging this extension and the PGP extension into a single document. -Martin From mike-list@pobox.com Fri May 4 21:36:56 2012 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 0BA9F21F845A for ; Fri, 4 May 2012 21:36:56 -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 OySB7UMsVwd0 for ; Fri, 4 May 2012 21:36:54 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [74.115.168.62]) by ietfa.amsl.com (Postfix) with ESMTP id 92F2521F844E for ; Fri, 4 May 2012 21:36:52 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id EFD7F60C6; Sat, 5 May 2012 00:36:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=uCxiZAfgt1Zq jDBXJRYsv7nYyJU=; b=daGMvitKmLZvUVdBxyvxZKddxtQyMZfSppc0nGIDglcX nWyDkOZ0vN59wvbSI2ykPIaYYwI40yqkmCa7yqR+yyr8yrrmMRHs7/WLvYYQzUPP Q4siuTX6GLkguKLvHOW2scR2ZeSWRxIeEOV1MpWo/+veeaCmzSQ9R3RIpkWFxMs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=fAZYrn qCvP08Tyl6yTowsBSQMs1cYX5/DAgRyB8QQpDEDUCpNG6ClHwZwieo3kqkREtoo6 V6MzeuwLratdZ6PPB3EjiT1SkyqpE0xzllH6dHhMhMpsUsgLqNMIQJ46+aOgC7XS 8F0RCHhQznJXP5ejjVQr8e8Aqs/tvbt+RwAF4= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id E240A60C5; Sat, 5 May 2012 00:36:51 -0400 (EDT) Received: from iMac.local (unknown [68.104.126.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 45B5760C4; Sat, 5 May 2012 00:36:51 -0400 (EDT) Message-ID: <4FA4AE62.20506@pobox.com> Date: Fri, 04 May 2012 21:36:50 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Marsh Ray References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> In-Reply-To: <4FA4264A.7070406@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: EF16F916-966B-11E1-A36A-8BEB728A0A4D-38729857!a-pb-sasl-sd.pobox.com Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sat, 05 May 2012 04:36:56 -0000 Marsh Ray wrote: > On 05/04/2012 01:49 PM, Michael D'Errico wrote: >> Was it intentional to leave out the ChangeCipherSpecs that immediately >> precede Finished? I think they still need to be there. > > The intent was to move the CCS from late in the handshake to as soon as > practical in the handshake without changing their meaning. So, yes. If you don't perform a second CCS prior to Finished, then there are two problems I see: - you can not use RSA key exchange anymore; how about PSK or SRP? - multi-homing is hindered -- different virtual servers on the same machine could prefer different bulk encryption and MAC algorithms Sending a second CCS solves both problems, and is not expensive either in network overhead or running the PRF again. In cases where a non-DH key exchange is preferred, the first exchange could be the same as DH_anon. Mike From nico@cryptonector.com Fri May 4 21:44:54 2012 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 49AA021F845F for ; Fri, 4 May 2012 21:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 2hcf+UybHxQt for ; Fri, 4 May 2012 21:44:53 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id E226021F845D for ; Fri, 4 May 2012 21:44:52 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 74B8F2AC064 for ; Fri, 4 May 2012 21:44:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=E9OqCei090j5EbQHRZTlJsY2z7/Bs4CnRYKnIXbNULw1 MfVO31/UmCxr79xYGbfYzqasTAKnKu2ntZHkJExNrOdbckrTF4ingcFza5L9hfHR 27BGlmlsCkpVBrtsH7ZJBR4KJjvTe+tTUpeFXup2ZD3tcNOI/2dTmMrsmMcaTf8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=VlNLkqsJBfOV8wDq0qEYPEFgBtA=; b=B8km5iD4CQQ dD1PBsjBRRo1dNuk+uhol80lQKiVnK3+N0frP9s8gkhiyF7ooCr6hvsO7lU9J+u5 B2GdPSQwynfogr1MVh98QuK9JBTTpCj5gZqPzYCtUHThNdHmGcEeDaVm50DcDuK5 4vIuzQy7sG8UbbS2Soq56Eheq81uNGFU= Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 5B15C2AC005 for ; Fri, 4 May 2012 21:44:52 -0700 (PDT) Received: by dadz9 with SMTP id z9so5823795dad.39 for ; Fri, 04 May 2012 21:44:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.71 with SMTP id ic7mr25169152pbc.34.1336193091922; Fri, 04 May 2012 21:44:51 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Fri, 4 May 2012 21:44:51 -0700 (PDT) In-Reply-To: <4FA4AE62.20506@pobox.com> References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> Date: Fri, 4 May 2012 23:44:51 -0500 Message-ID: From: Nico Williams To: "Michael D'Errico" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sat, 05 May 2012 04:44:54 -0000 On Fri, May 4, 2012 at 11:36 PM, Michael D'Errico wro= te: > Marsh Ray wrote: > If you don't perform a second CCS prior to Finished, then there are > two problems I see: > > =C2=A0- you can not use RSA key exchange anymore; how about PSK or SRP? > =C2=A0- multi-homing is hindered -- different virtual servers on the same > =C2=A0 =C2=A0machine could prefer different bulk encryption and MAC algor= ithms > > Sending a second CCS solves both problems, and is not expensive either > in network overhead or running the PRF again. > > In cases where a non-DH key exchange is preferred, the first exchange > could be the same as DH_anon. Ah, that makes sense. I'd earlier (off-list) proposed to Marsh to just keep the CCSes in the messages they were already in, just move them up. But there's value to encrypting things as early as possible. Nico -- From ynir@checkpoint.com Sat May 5 06:41:49 2012 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 A9A4C21F8585 for ; Sat, 5 May 2012 06:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.371 X-Spam-Level: X-Spam-Status: No, score=-10.371 tagged_above=-999 required=5 tests=[AWL=0.228, 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 ek4GcSpIk1-K for ; Sat, 5 May 2012 06:41:49 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 07B0521F856C for ; Sat, 5 May 2012 06:41:43 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q45DfagU024192; Sat, 5 May 2012 16:41:36 +0300 X-CheckPoint: {4FA53BC1-2-1B221DC2-2FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 5 May 2012 16:41:36 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 5 May 2012 16:41:34 +0300 From: Yoav Nir To: "Michael D'Errico" Date: Sat, 5 May 2012 16:41:32 +0300 Thread-Topic: [TLS] draft-ray-tls-encrypted-handshake-00.txt Thread-Index: Ac0qxMkkTaFTvDdCTBSm3dKyp0pBuw== Message-ID: References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> In-Reply-To: <4FA4AE62.20506@pobox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11869edec629a92f48bcff53694611c0a88ba69f5f Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled X-KSE-Antivirus-Interceptor-Info: scan successful X-KSE-Antivirus-Info: Clean Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sat, 05 May 2012 13:41:49 -0000 On May 5, 2012, at 7:36 AM, Michael D'Errico wrote: > Marsh Ray wrote: >> On 05/04/2012 01:49 PM, Michael D'Errico wrote: >>> Was it intentional to leave out the ChangeCipherSpecs that immediately >>> precede Finished? I think they still need to be there. >>=20 >> The intent was to move the CCS from late in the handshake to as soon as= =20 >> practical in the handshake without changing their meaning. So, yes. >=20 > If you don't perform a second CCS prior to Finished, then there are > two problems I see: >=20 > - you can not use RSA key exchange anymore; how about PSK or SRP? That is a feature. With this draft, the server has to perform two asymmetri= c operations anyway: one for the key exchange (most likely D-H), and then i= t still has to do another one as proof of possession of the private key (or= for SRP). The only advantage of RSA keying was that you got both in one op= eration, and that's gone anyway. > - multi-homing is hindered -- different virtual servers on the same > machine could prefer different bulk encryption and MAC algorithms Agree. > Sending a second CCS solves both problems, and is not expensive either > in network overhead or running the PRF again. The PRF is not expensive. It's the operation used to generate the seed for = the PRF that is expensive. It should be noted that this is a disadvantage o= f this proposal. > In cases where a non-DH key exchange is preferred, the first exchange > could be the same as DH_anon. Yoav= From paul.hoffman@vpnc.org Sat May 5 06:44:14 2012 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 5DC9721F8569 for ; Sat, 5 May 2012 06:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, 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 fvfCoHBnDArF for ; Sat, 5 May 2012 06:44:14 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D60F821F847F for ; Sat, 5 May 2012 06:44:13 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q45DiAVM055804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 5 May 2012 06:44:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <6296DC06-A0A4-4A75-9FCC-AE0B402CBD20@checkpoint.com> Date: Sat, 5 May 2012 06:44:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1C0D79B7-D6A9-4326-854F-44B1985190B6@vpnc.org> References: <4FA401F7.5060003@extendedsubset.com> <6296DC06-A0A4-4A75-9FCC-AE0B402CBD20@checkpoint.com> To: tls@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sat, 05 May 2012 13:44:14 -0000 On May 4, 2012, at 2:13 PM, Yoav Nir wrote: > IMO this is a huge change to the TLS state machine. Much bigger than = the diff between TLS 1.1 and 1.0, and bigger than the difference between = 1.2 and 1.1. This should not be an extension but a new version number. = You would still need an extension to carry the extra information (if we = want backwards compatibility), but negotiating this capability should be = done at the version level. It is a huge change in the TLS state machine, but only when both parties = fully understand the change, as signaled by the extension. There is no = need to change the version number: there is no chance one party won't = know what is going on. --Paul Hoffman From marsh@extendedsubset.com Sat May 5 08:48:49 2012 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 C37C221F85E4 for ; Sat, 5 May 2012 08:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] 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 o3jBVXBrWszd for ; Sat, 5 May 2012 08:48:48 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id D6D0321F859F for ; Sat, 5 May 2012 08:48:48 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SQhE0-000EYZ-DH; Sat, 05 May 2012 15:48:48 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 8C52C6067; Sat, 5 May 2012 15:48:45 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/SohwCa8jSJdJ8HAEZasT458X+V+vTxsU= Message-ID: <4FA54BDB.2070106@extendedsubset.com> Date: Sat, 05 May 2012 10:48:43 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <4FA401F7.5060003@extendedsubset.com> <6296DC06-A0A4-4A75-9FCC-AE0B402CBD20@checkpoint.com> <1C0D79B7-D6A9-4326-854F-44B1985190B6@vpnc.org> In-Reply-To: <1C0D79B7-D6A9-4326-854F-44B1985190B6@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sat, 05 May 2012 15:48:49 -0000 On 05/05/2012 08:44 AM, Paul Hoffman wrote: > > It is a huge change in the TLS state machine, but only when both > parties fully understand the change, as signaled by the extension. It is a change, whether or not it's "huge" probably depends on what kind of implementation you maintain? As the EH designer/author, the adjective I was trying for is "minimal". TLS isn't rigorously defined in terms of a state machine, but it's natural to speak of it in terms of one. However what we mean by that can vary quite a bit. For example, the OpenSSL codebase seems to use two states for every handshake message but the basic state machine representation is much simpler: Basic TLS handshake, server side without EH EH level one ---------- ------------ | | | | v | v state 'start' | state 'start' | | | | | | event: received ClientHello | event: received ClientHello | | | | | | v | v state 'handshake_a': | state 'handshake_a': on entry: send ServerHello, | on entry: send ServerHello1a, Cert*, ServerKeyExch*, | [ChangeCipherSpec], SH1b, CertReq*, ServerHelloDone | Cert*, ServerKeyExch*, | | CertReq*, ServerHelloDone | | | | | | event: received Cert*, | event: received ClientKeyExch, | [ChangeCipherSpec], CertVerify*, | Cert*, ClientKeyExch, [ChangeCipherSpec], | CertVerify*, Finished | Finished | | | | | | v | v state 'handshake_complete': | state 'handshake_complete': on entry: | on entry: send [ChangeCipherSpec], | send [ChangeCipherSpec], Finished | Finished | So for EH level one there's not really a change in the number of states or transitions in the 'TLS state machine' per se. EH level two introduces one new transition to one new state. This why EH support is split into two implementation levels. > There is no need to change the version number: there is no chance one > party won't know what is going on. As Nico pointed out, the TLS version number is for when you need rollback protection. It has to be incremented when changing the hash/MAC/PRF algorithm because that's the thing which authenticates the handshake negotiation itself. But most other changes should be negotiable via extensions, as long as they do not negatively affect the process of generating and validating the Finished messages. - Marsh From mike-list@pobox.com Sat May 5 09:17:34 2012 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 CEFEF21F8543 for ; Sat, 5 May 2012 09:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 Mr1Q6z8B+67z for ; Sat, 5 May 2012 09:17:34 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [74.115.168.62]) by ietfa.amsl.com (Postfix) with ESMTP id 1282321F8541 for ; Sat, 5 May 2012 09:17:32 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id CFB9695EC; Sat, 5 May 2012 12:17:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=jKVJqQn6x3UA ECuaSLdtZCfGO2k=; b=OrLvXG7lww940eYdgOWz1PIhzP3+u1YV5EVcIQmcI5d9 NyLFiGsBf6rPLkhYPgPoQxOIaeZyMrTdYdYNABPp54j1moizH3DlWl2behuLy8wZ s45GJVwWj/LZN8ttS/XnKvWpQ6BbOygx8tyEQMziqTyC/LtHxs1iakdNQXUp2e8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=XOD7HX rbOQgLb4guo6psAm+xcM/gqFWXZj/bFEGcuPA2geBSf4007oD8myFMz3KPPg3c44 KFLmoKk+ZJX3+k0sa/d67qEaEgO/Z/Bb7VFw7Rjbh1GrsSmacfTN4MYDpLXnkiFP s6SSlbNZcEZ3ggPWXzhfH46Zduc0SlTR6Cq24= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id C94DC95EB; Sat, 5 May 2012 12:17:31 -0400 (EDT) Received: from iMac.local (unknown [68.104.126.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id EE79A95EA; Sat, 5 May 2012 12:17:29 -0400 (EDT) Message-ID: <4FA55298.9010203@pobox.com> Date: Sat, 05 May 2012 09:17:28 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Yoav Nir References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: D0286848-96CD-11E1-B0B1-8BEB728A0A4D-38729857!a-pb-sasl-sd.pobox.com Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sat, 05 May 2012 16:17:34 -0000 Yoav Nir wrote: > On May 5, 2012, at 7:36 AM, Michael D'Errico wrote: > >> If you don't perform a second CCS prior to Finished, then there are >> two problems I see: >> >> - you can not use RSA key exchange anymore; how about PSK or SRP? > > That is a feature. With this draft, the server has to perform two asymmetric operations anyway: one for the key exchange (most likely D-H), and then it still has to do another one as proof of possession of the private key (or for SRP). The only advantage of RSA keying was that you got both in one operation, and that's gone anyway. I don't see that as a feature. Telling people that they can't do things the way they've been doing them for a decade doesn't go over well. Why throw away all of the TLS_RSA_xxx, TLS_PSK_xxx, TLS_SRP_xxx, (and TLS_KRB5_xxx ?) cipher suites in one shot? Wrapping them in anon DH adds forward secrecy (attackers can't see the RSA encrypted secret, for example). People get to do things more or less the same as they've always done, but get more security "for free". >> Sending a second CCS solves both problems, and is not expensive either >> in network overhead or running the PRF again. > > The PRF is not expensive. It's the operation used to generate the seed for the PRF that is expensive. It should be noted that this is a disadvantage of this proposal. In cases where the second CCS would produce the same key material as the first CCS (i.e. the master secret hasn't changed), an implementation can optimize away the second one. Mike From paul.hoffman@vpnc.org Sat May 5 09:25:14 2012 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 2286B21F8499 for ; Sat, 5 May 2012 09:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, 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 VzvuHE07JZQE for ; Sat, 5 May 2012 09:25:13 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9365C21F8497 for ; Sat, 5 May 2012 09:25:13 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q45GP9M9074438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 5 May 2012 09:25:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4FA55298.9010203@pobox.com> Date: Sat, 5 May 2012 09:25:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <65A74BBD-AA6D-447C-898D-8CB8C5966943@vpnc.org> References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> <4FA55298.9010203@pobox.com> To: "Michael D'Errico" X-Mailer: Apple Mail (2.1257) Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sat, 05 May 2012 16:25:14 -0000 On May 5, 2012, at 9:17 AM, Michael D'Errico wrote: > I don't see that as a feature. Telling people that they can't do = things > the way they've been doing them for a decade doesn't go over well. It is hard to tell if you are criticizing the idea of encrypting the = handshake early, or the first draft of the document. If the former, I = would disagree: this seems like very useful work. If the latter, a = different way to say this is "I really hope there will be a way to also = authenticate with current forms of TLS authentication if the parties = want that". A second, optional authentication seems like a reasonable thing to add = to the -01 draft, at least to me. --Paul Hoffman From mike-list@pobox.com Sat May 5 10:04:50 2012 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 216E421F85ED for ; Sat, 5 May 2012 10:04:50 -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=[AWL=0.000, 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 KT3Ped1v2ISr for ; Sat, 5 May 2012 10:04:49 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [74.115.168.62]) by ietfa.amsl.com (Postfix) with ESMTP id 3B70021F84C9 for ; Sat, 5 May 2012 10:04:49 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 9BAB79879; Sat, 5 May 2012 13:04:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=FD5WWwPPMat9 h4kx4p8D/ZcPgcI=; b=Ex6rji7oUYDE7DDdXTwRJ+Y5TbRxSugzwgR35Af0pEsa BhDHJAg92TaEuTfWABzY4jmOOEdOAMiYfeDhxDfuRAy65CDOJQJA51AojlzBzIQ+ aDmF9zIhISucRsNTH0JWrCoiU/6Vf5q2q6Dj+XnknM+unKcWjMhOrhBtUX6B1hs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=hVWotm LTkHSFO4tbh4os0WF+WEpUUm71GLeSJ2eW0eDMTUgWE91v0lPw/SsAsHLLRovOAg WyCIP9c29wZEhBzFMTBRRu3brLxIVCJ7aVxDhCN0gVDJ0wlQQXhd4HJqsl393fcs NbijM0S4X0IUCRUJg5Qhy5fYk8qLDVkPHXsTk= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 9302D9877; Sat, 5 May 2012 13:04:48 -0400 (EDT) Received: from iMac.local (unknown [68.104.126.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id B83CF9875; Sat, 5 May 2012 13:04:47 -0400 (EDT) Message-ID: <4FA55DAE.8020909@pobox.com> Date: Sat, 05 May 2012 10:04:46 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Paul Hoffman References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> <4FA55298.9010203@pobox.com> <65A74BBD-AA6D-447C-898D-8CB8C5966943@vpnc.org> In-Reply-To: <65A74BBD-AA6D-447C-898D-8CB8C5966943@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 6B927C14-96D4-11E1-9B85-8BEB728A0A4D-38729857!a-pb-sasl-sd.pobox.com Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sat, 05 May 2012 17:04:50 -0000 Paul Hoffman wrote: > On May 5, 2012, at 9:17 AM, Michael D'Errico wrote: > >> I don't see that as a feature. Telling people that they can't do things >> the way they've been doing them for a decade doesn't go over well. > > It is hard to tell if you are criticizing the idea of encrypting the handshake early, or the first draft of the document. If the former, I would disagree: this seems like very useful work. If the latter, a different way to say this is "I really hope there will be a way to also authenticate with current forms of TLS authentication if the parties want that". I'm sorry if I wasn't clear. I was responding to the idea that allowing this new extension to be incompatible with TLS_RSA_xxx cipher suites was a feature. I am in favor of encrypting the handshake early, but not if the new mechanism is incompatible with the way things are done today (many sites prefer TLS_RSA_xxx cipher suites). Adoption will be much faster if server operators don't need to do anything but upgrade their software. Many have inherited working configurations and are not expert in cipher suites and key exchange algorithms. > A second, optional authentication seems like a reasonable thing to add to the -01 draft, at least to me. That can be achieved by adding a second CCS just prior to Finished, allowing the use of all existing cipher suites defined today. When a DH-based cipher suite is negotiated, an implementation can treat the 2nd CCS as a NOOP as an optimization. Mike From n.mavrogiannopoulos@gmail.com Sat May 5 11:10:30 2012 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 7743321F85C0 for ; Sat, 5 May 2012 11:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 PYmmErjv3r5a for ; Sat, 5 May 2012 11:10:24 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1988721F85BD for ; Sat, 5 May 2012 11:10:23 -0700 (PDT) Received: by eabd1 with SMTP id d1so672036eab.31 for ; Sat, 05 May 2012 11:10:23 -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:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=+bLsfnAUeQfsJRFvaDRLWVz2PkksVp7Prp5frHucnsk=; b=SCYpUIae6o+95ontM2L7rLwscOYMJjvpemajAOv+n/PCk3Uu2CngYu+RXOEe4ZERpn 0rlSR1iq2DQGp5goYzPY9rAkesGdD7ejpm8DFfLygvlOaNTvpOrPG9wmVXSD+LOWhTYh 29iDgzqvBIAlSs2JCtiotgqaUX5U5CiKSkq2nbCyWK19kNmUUU+7cy/3LbPAYhQXD0K3 FCjG/DaXaJmaZQiqUcAzNTIPJKQtJqlyCF0WBvnVUei1he0UZ42sqO9gnx/xbMBrxYvT cOnF4dEXOBVMzF3U8WtIyezXxZ4iy2PUsL2Ph07twvql55rnK9TrZj80h596B9GC0dyR fbUg== Received: by 10.14.40.84 with SMTP id e60mr404511eeb.75.1336241423217; Sat, 05 May 2012 11:10:23 -0700 (PDT) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id u10sm43602495eem.1.2012.05.05.11.10.22 (version=SSLv3 cipher=OTHER); Sat, 05 May 2012 11:10:22 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4FA56D09.4030101@gnutls.org> Date: Sat, 05 May 2012 20:10:17 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: Michael D'Errico References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> <4FA55298.9010203@pobox.com> <65A74BBD-AA6D-447C-898D-8CB8C5966943@vpnc.org> <4FA55DAE.8020909@pobox.com> In-Reply-To: <4FA55DAE.8020909@pobox.com> X-Enigmail-Version: 1.4 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sat, 05 May 2012 18:10:30 -0000 On 05/05/2012 07:04 PM, Michael D'Errico wrote: > I'm sorry if I wasn't clear. I was responding to the idea that allowing > this new extension to be incompatible with TLS_RSA_xxx cipher suites was > a feature. > > I am in favor of encrypting the handshake early, but not if the new > mechanism is incompatible with the way things are done today (many sites > prefer TLS_RSA_xxx cipher suites). I don't see that as a valid reason to introduce extra complexity to the current draft. Are there any real benefits from the usage of TLS_RSA_xxx? In any case the sites that prefer the TLS_RSA_xxx would still prefer it even after this draft. Only sites that want to provide encrypted parts in the handshake will use the new draft with the required ciphersuites. > Adoption will be much faster if server operators don't need to do anything > but upgrade their software. Many have inherited working configurations > and are not expert in cipher suites and key exchange algorithms. Why this isn't possible with the current draft? regards, Nikos From paul.hoffman@vpnc.org Sat May 5 11:22:05 2012 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 3D1E821F85F1 for ; Sat, 5 May 2012 11:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, 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 mx4SQaWdem5h for ; Sat, 5 May 2012 11:22:04 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A579921F85D9 for ; Sat, 5 May 2012 11:22:04 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q45IM0gI089492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 5 May 2012 11:22:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: <4FA55DAE.8020909@pobox.com> Date: Sat, 5 May 2012 11:22:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <508C47AD-7999-46EB-832A-4D66AAC87118@vpnc.org> References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> <4FA55298.9010203@pobox.com> <65A74BBD-AA6D-447C-898D-8CB8C5966943@vpnc.org> <4FA55DAE.8020909@pobox.com> To: "Michael D'Errico" X-Mailer: Apple Mail (2.1257) Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sat, 05 May 2012 18:22:05 -0000 On May 5, 2012, at 10:04 AM, Michael D'Errico wrote: > Paul Hoffman wrote: >> On May 5, 2012, at 9:17 AM, Michael D'Errico wrote: >>> I don't see that as a feature. Telling people that they can't do = things >>> the way they've been doing them for a decade doesn't go over well. >> It is hard to tell if you are criticizing the idea of encrypting the = handshake early, or the first draft of the document. If the former, I = would disagree: this seems like very useful work. If the latter, a = different way to say this is "I really hope there will be a way to also = authenticate with current forms of TLS authentication if the parties = want that". >=20 > I'm sorry if I wasn't clear. I was responding to the idea that = allowing > this new extension to be incompatible with TLS_RSA_xxx cipher suites = was > a feature. That might have been Yoav being glib (but he might have actually have = meant it...). > I am in favor of encrypting the handshake early, but not if the new > mechanism is incompatible with the way things are done today (many = sites > prefer TLS_RSA_xxx cipher suites). >=20 > Adoption will be much faster if server operators don't need to do = anything > but upgrade their software. Many have inherited working = configurations > and are not expert in cipher suites and key exchange algorithms. I don't read the draft as possibly being implemented with only upgrading = software. The server would need to also have a (EC)DH certificate to = authenticate the first CCS. >> A second, optional authentication seems like a reasonable thing to = add to the -01 draft, at least to me. >=20 > That can be achieved by adding a second CCS just prior to Finished, = allowing > the use of all existing cipher suites defined today. When a DH-based = cipher > suite is negotiated, an implementation can treat the 2nd CCS as a NOOP = as an > optimization. I would propose that, if the WG likes this work and goes with the option = of a second authentication, that it either be signaled in the original = extension, or that it always be mandatory but in the case where it is = not needed, it is done with small packets saying to the effect of "I'm = not authenticating a second time" and "yes, I know". --Paul Hoffman From marsh@extendedsubset.com Sat May 5 12:04:47 2012 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 C534021F851B for ; Sat, 5 May 2012 12:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 oLH-P34cVe+j for ; Sat, 5 May 2012 12:04:47 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id F212C21F850C for ; Sat, 5 May 2012 12:04:46 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SQkHe-000ERl-HE; Sat, 05 May 2012 19:04:46 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 8918E693D; Sat, 5 May 2012 19:04:44 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/qoYuyCDtarhwRSpe/+x/vj+fBthZWwhw= Message-ID: <4FA579CA.8090104@extendedsubset.com> Date: Sat, 05 May 2012 14:04:42 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Michael D'Errico References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> <4FA55298.9010203@pobox.com> In-Reply-To: <4FA55298.9010203@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sat, 05 May 2012 19:04:47 -0000 On 05/05/2012 11:17 AM, Michael D'Errico wrote: > > I don't see that as a feature. Telling people that they can't do things > the way they've been doing them for a decade doesn't go over well. I don't want to tell anybody they can't do things their way. It's a totally optional extension, nobody has to use it. That said, I think it would be great if eveybody did use it. :-) Like Yoav said: On 05/04/2012 04:13 PM, Yoav Nir wrote: > I think this moves TLS to be more like IKE, where encryption of the > IKE protocol precedes everything else (authentication, configuration, > and IPsec setup) SSH2 is another example of a protocol that starts off encryption with DH as early as possible. The goal here is to update TLS to look a bit more like those newer protocols. In fact, we can do it even better than SSH2. Imagine, before even one full round-trip has completed, few hundred bytes into the server's initial reply, we are already forward-secretly encrypted from that point on! All it takes to make this possible is to include some (EC)DH parameters in the Client Hello. The rest the spec is just working out the details. :-) > Why throw away all of the TLS_RSA_xxx, TLS_PSK_xxx, TLS_SRP_xxx, (and > TLS_KRB5_xxx ?) cipher suites in one shot? Wrapping them in anon DH > adds forward secrecy (attackers can't see the RSA encrypted secret, for > example). People get to do things more or less the same as they've > always done, but get more security "for free". I'm not opposed to it in principle, but I chose not to support RSA key exchange mainly because it looked like it would increase the complexity significantly. The fact that it wouldn't have the forward secrecy property didn't seem to help either. With RSA key exchange the client sends the premaster secret to server. In order to do this, he has to know the server's public key. So if the server sends the cert in the clear we end up with basically the same full handshake we have now. If the client were to somehow already know the server's public key perhaps he could send the RSA-encrypted premaster secret in the Client Hello. But server public keys change regularly, so this info could not be cached very long. If the extension only worked in cases where the client had had recent contact with the same server, well, we could just use session resumption for those cases now. If what you're suggesting is starting out EH with a DHE key exchange and then switching to the RSA-negotiated key at the usual point before the Finished messages, maybe that could work. It brings a few challenges: * The client and server now need to negotiate and use *two* cipher suites instead of just one. * They would need separate random_datas for the (EC)DHE and the RSA key exchanges * We lose the ability of the client to verify the ServerHello2a dh_params using a simple memcmp() with the *signed* structure in the ServerKeyExchange, and vice versa for the ClientKeyExchange. This may not be such a big deal today because some implementations don't even check that until the Finished message anyway. I think it may reduce some of the extra integrity protection we might get by encrypting and MACing more of the handshake, but I didn't claim any of that as a selling point of the proposal because I wasn't prepared to quantify it. * I didn't want to shock everyone so thoroughly with the complexity of the proposal that the WG wouldn't want to take it up. We all have a fuzzy line beyond which we say "hmm, that really ought to be implemented as a different protocol". For me, that line is currently somewhere between EH level two and Snap Start. So, again, I'm open to modifications but at the end of the day, (EC)DHE is just a much more elegant key exchange method when the goal is to begin encrypting after a minimum of message passing. >>> Sending a second CCS solves both problems, and is not expensive either >>> in network overhead or running the PRF again. >> >> The PRF is not expensive. It's the operation used to generate the seed >> for the PRF that is expensive. It should be noted that this is a >> disadvantage of this proposal. Yes, the benefits of (EC)DHE do not come for free (unless perhaps you use certs with fixed-DH parameters). But if you are already using some form of DH key exchange, you *do* get Encrypted Handshake level one for free. > In cases where the second CCS would produce the same key material as the > first CCS (i.e. the master secret hasn't changed), an implementation can > optimize away the second one. We can't let the same key material be used for multiple plaintexts. That would be bad. - Marsh From marsh@extendedsubset.com Sat May 5 12:12:20 2012 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 E033821F85E1 for ; Sat, 5 May 2012 12:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, 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 M5VlBhxsoLV3 for ; Sat, 5 May 2012 12:12:20 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6986821F85D5 for ; Sat, 5 May 2012 12:12:20 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SQkOu-000Jp5-Pp; Sat, 05 May 2012 19:12:16 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 1C753693E; Sat, 5 May 2012 19:12:16 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/XeP5PmBDnxS7dp/qgp7uB8zUtnpa09lc= Message-ID: <4FA57B8D.9030409@extendedsubset.com> Date: Sat, 05 May 2012 14:12:13 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> <4FA55298.9010203@pobox.com> <65A74BBD-AA6D-447C-898D-8CB8C5966943@vpnc.org> <4FA55DAE.8020909@pobox.com> <508C47AD-7999-46EB-832A-4D66AAC87118@vpnc.org> In-Reply-To: <508C47AD-7999-46EB-832A-4D66AAC87118@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sat, 05 May 2012 19:12:21 -0000 On 05/05/2012 01:22 PM, Paul Hoffman wrote: > > I don't read the draft as possibly being implemented with only > upgrading software. The server would need to also have a (EC)DH > certificate to authenticate the first CCS. Hmm, does it? I tried to make it so any endpoint that could do ephemeral key exchange today could begin encrypting handshakes, just possibly needing a little config change. - Marsh From mbadra@gmail.com Sat May 5 13:49:58 2012 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 07BA021F8609 for ; Sat, 5 May 2012 13:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Xz8vPoltTbGU for ; Sat, 5 May 2012 13:49:57 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6979821F8608 for ; Sat, 5 May 2012 13:49:57 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3240921vbb.31 for ; Sat, 05 May 2012 13:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+q70zcljo3zq2ooC0Pgn7RUJRsQDiYF+ZtTevc/j7ms=; b=eIhsyY4ai/KRPz6O5zK4jLQZeUl5gNQMof+UxZh4pWifAvTK2bvMo46L23qg0rJN6R 5klYxA31riG4S1ZeN3egS6+IRNGV0NDk0eDs5kl14qsTm1i5gEoFpjwLvDrxa+TbG2HH GN46wR50nGpqQe5xxIzlZlRkeDr9lcrQUsHawlZhaiYLVdGHjlKR9HUywa4Ob8BDKcq7 PvyFZk/xqw8zOkaTZsc92js9mh56r9rnJKbubBZvN68fZJdu29OFoqBtutp6pyBPAFjz /7t4YEV/6s0OH/lbZvSsbCAmpyWw2BVAEkvfyYu2TP0iFhZkwju5pjzcC0lm2kX9xah6 NV0g== MIME-Version: 1.0 Received: by 10.52.72.138 with SMTP id d10mr4323492vdv.80.1336250996969; Sat, 05 May 2012 13:49:56 -0700 (PDT) Received: by 10.220.5.20 with HTTP; Sat, 5 May 2012 13:49:56 -0700 (PDT) In-Reply-To: <4FA579CA.8090104@extendedsubset.com> References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> <4FA55298.9010203@pobox.com> <4FA579CA.8090104@extendedsubset.com> Date: Sat, 5 May 2012 22:49:56 +0200 Message-ID: From: Mohamad Badra To: tls@ietf.org Content-Type: multipart/alternative; boundary=20cf3071cfd601519b04bf502e94 Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sat, 05 May 2012 20:49:58 -0000 --20cf3071cfd601519b04bf502e94 Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 5, 2012 at 9:04 PM, Marsh Ray wrote: > On 05/05/2012 11:17 AM, Michael D'Errico wrote: > >> >> On 05/04/2012 04:13 PM, Yoav Nir wrote: > > I think this moves TLS to be more like IKE, where encryption of the > > IKE protocol precedes everything else (authentication, configuration, > > and IPsec setup) > TLS has its own key exchange, but if we really want to move TLS to be more like IKE, so I think it could be wise to study the case of integrating the IKE key exchange into the TLS handshake. A couple of years ago, there was a proposal to integrate ISAKMP into the handshake: I. Hajjeh et al, "ISAKMP handshake for SSL/TLS" Digital Object Identifier: 10.1109/GLOCOM.2003.1258484 Best regards, Badra --20cf3071cfd601519b04bf502e94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, May 5, 2012 at 9:04 PM,= Marsh Ray <marsh@extendedsubset.com> wrote:
On 05/05/2012 11:17 AM, Michael D'Errico wrote:

On 05/04/2012 04:13 PM, Yoav Nir wrote:
> I think this moves TLS to be more like IKE, where encryption of the > IKE protocol precedes everything else (authentication, configuration,<= br> > and IPsec setup)


<= div>TLS has its own key exchange, but if we really want to move TLS to be m= ore like IKE, so I think it could be wise to study the case of integrating = the IKE key exchange into the TLS handshake.

A couple of years ago, there was a proposal to int= egrate ISAKMP=A0into the handshake:
I. Hajjeh et al, &= quot;ISAKMP handshake for SSL/TLS"
Digital Object Identifier= : 10.1109/GLOCOM.2003.1258484

Best regards,
Badra
--20cf3071cfd601519b04bf502e94-- From paul.hoffman@vpnc.org Sat May 5 14:34:51 2012 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 A56ED21F8593 for ; Sat, 5 May 2012 14:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, 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 tuTPscXvqxea for ; Sat, 5 May 2012 14:34:51 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AB62B21F856C for ; Sat, 5 May 2012 14:34:50 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q45LYjq2014080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 5 May 2012 14:34:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4FA4AE62.20506@pobox.com> Date: Sat, 5 May 2012 14:34:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> To: "Michael D'Errico" X-Mailer: Apple Mail (2.1257) Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sat, 05 May 2012 21:34:51 -0000 On May 4, 2012, at 9:36 PM, Michael D'Errico wrote: > If you don't perform a second CCS prior to Finished, then there are > two problems I see: >=20 > - you can not use RSA key exchange anymore; how about PSK or SRP? Note that you can still use RSA with dhe_rsa. So, you are not doing RSA = key exchange, but you are still doing RSA authentication. I propose that = less than 1% of web site operators would care about the difference. > - multi-homing is hindered -- different virtual servers on the same > machine could prefer different bulk encryption and MAC algorithms How many web hosting providers let their individual customers make those = choices? Isn't this also in the 1%ish range? --Paul Hoffman From nico@cryptonector.com Sat May 5 15:00:26 2012 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 6636621F8568 for ; Sat, 5 May 2012 15:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 zRR+bhNK0PIj for ; Sat, 5 May 2012 15:00:25 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id A38A621F8531 for ; Sat, 5 May 2012 15:00:25 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id B8B841F0081 for ; Sat, 5 May 2012 15:00:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Wuuo086z1s3hj4+0p/R8Dg0bpVYa6BG45vCCByq2VqFJ dz69+HrEszIrpSTlKMVRkub4Ue87RBXrjoOR3EIBSFC/PnBbht2vklGua8m0YDDm ikTnPa14yte1LBUlvEKjCKlgpBynMZ7g5ge/gcCvmYezvPwUhedA7q8xC2ZJ5Z4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=SIIg/Bu8UMmsv4wbx+MVa08PBGI=; b=VNeG/kHDXTe g/ddWZOObQCCpUJNzC6DfDXURoEX823djk5GuX2urejvT+YrDxWZueq2JvrmOMTa c1SaPUvyeshVJilTdz9t6kLT99j3a23xMtyQXkG/mI8JYXxOr96gsYS/vbVC+37y IF1im8FQUSLlg9aVyD2keO0qxcL+bod0= Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 98C921F007C for ; Sat, 5 May 2012 15:00:24 -0700 (PDT) Received: by dadz9 with SMTP id z9so6930514dad.39 for ; Sat, 05 May 2012 15:00:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.233.103 with SMTP id tv7mr13256691pbc.97.1336255223108; Sat, 05 May 2012 15:00:23 -0700 (PDT) Received: by 10.68.216.199 with HTTP; Sat, 5 May 2012 15:00:23 -0700 (PDT) In-Reply-To: References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> Date: Sat, 5 May 2012 17:00:23 -0500 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sat, 05 May 2012 22:00:26 -0000 On Sat, May 5, 2012 at 8:41 AM, Yoav Nir wrote: > On May 5, 2012, at 7:36 AM, Michael D'Errico wrote: >> Marsh Ray wrote: >>> On 05/04/2012 01:49 PM, Michael D'Errico wrote: >>>> Was it intentional to leave out the ChangeCipherSpecs that immediately >>>> precede Finished? I think they still need to be there. >>> >>> The intent was to move the CCS from late in the handshake to as soon as >>> practical in the handshake without changing their meaning. So, yes. >> >> If you don't perform a second CCS prior to Finished, then there are >> two problems I see: >> >> =C2=A0 - you can not use RSA key exchange anymore; how about PSK or SRP? I think it'd be easy enough to allow those in addition to the initial DH key exchange. >> Sending a second CCS solves both problems, and is not expensive either >> in network overhead or running the PRF again. > > The PRF is not expensive. It's the operation used to generate the seed fo= r the PRF that is expensive. It should be noted that this is a disadvantage= of this proposal. But note that re-negotiation (which is needed to gain some privacy for the client) also involves two key exchanges and PRFs. This approach does not do worse, and it reduces round-trips. So that's a win. Now, DH with server signature of its parameters is more expensive than RSA key transport, certainly, but I think we're at the point where we can accept that extra cost (particularly with ECDH in the picture). Nico -- From n.mavrogiannopoulos@gmail.com Sun May 6 00:38:07 2012 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 9A72E21F84B9 for ; Sun, 6 May 2012 00:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 lMtFRhN1udPc for ; Sun, 6 May 2012 00:38:06 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6F15B21F849D for ; Sun, 6 May 2012 00:38:06 -0700 (PDT) Received: by eekd4 with SMTP id d4so27551eek.31 for ; Sun, 06 May 2012 00:38:05 -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:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=S5WKcQdYgQQUdePM2YGS6v/so3K4BbaTIF+kmYEONMo=; b=fAumDSFn36+/++2u0MJTXB7dVPkZy24EBESuuO1tXwbwFa6esfAGpov9nrWRjyNXzj ssm7pLXaKrwkiNjH6SK03CD6gzCQqkxtl03ae3u0N0YXAHGn7Kh2mPw/CZUphZHk6deW dGDM/QwAC5shyZWky0pSNGq5hdd9U9+r8O8gDlGvmL6LH+1kl8qK8K4hxDr7Kr8OeGsI LGMPuIo12nRi48lrl4ZqgbrBqFU3+bU0YuUuNu7SNpjxd7lqSBu3ZhikfRueZmS+XusO +nuQz89M+LDAPWjAMP21qKrdNpjMygRSVQoshoxZbO8P9lOPAgI8jD0TbvKjIaONzmv0 N86w== Received: by 10.14.28.16 with SMTP id f16mr2057951eea.115.1336289885616; Sun, 06 May 2012 00:38:05 -0700 (PDT) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id n52sm60403792eef.6.2012.05.06.00.38.04 (version=SSLv3 cipher=OTHER); Sun, 06 May 2012 00:38:04 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4FA62A5B.8090507@gnutls.org> Date: Sun, 06 May 2012 09:38:03 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: Nico Williams References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> In-Reply-To: X-Enigmail-Version: 1.4 OpenPGP: id=96865171 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sun, 06 May 2012 07:38:07 -0000 On 05/06/2012 12:00 AM, Nico Williams wrote: > Now, DH with server signature of its parameters is more expensive than > RSA key transport, certainly, but I think we're at the point where we > can accept that extra cost (particularly with ECDH in the picture). Moreover there are several optimizations in plain DH that could be done for performance. The fact for example that TLS doesn't send the subgroup size, harms DH's performance. I was experimenting [0] with a server that operates on a subgroup and got a performance boost. If both the server and the client were aware of the subgroup the performance may have been comparable to ECDH. regards, Nikos [0]. http://nikmav.blogspot.com/2011/12/generating-diffie-hellman-parameters.html From ynir@checkpoint.com Sun May 6 00:51:08 2012 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 C2E4421F8443 for ; Sun, 6 May 2012 00:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.375 X-Spam-Level: X-Spam-Status: No, score=-10.375 tagged_above=-999 required=5 tests=[AWL=0.224, 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 5LTZykKfGk1Y for ; Sun, 6 May 2012 00:51:08 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9729E21F8427 for ; Sun, 6 May 2012 00:51:07 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q467p1fJ025877; Sun, 6 May 2012 10:51:05 +0300 X-CheckPoint: {4FA63B0C-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 6 May 2012 10:50:59 +0300 From: Yoav Nir To: "'Paul Hoffman'" , "Michael D'Errico" Date: Sun, 6 May 2012 10:50:58 +0300 Thread-Topic: [TLS] draft-ray-tls-encrypted-handshake-00.txt Thread-Index: Ac0q7AKMZPutIcYWT8ODwOEpTZUEPgAcHb4g Message-ID: <006FEB08D9C6444AB014105C9AEB133F017A7C056C48@il-ex01.ad.checkpoint.com> References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> <4FA55298.9010203@pobox.com> <65A74BBD-AA6D-447C-898D-8CB8C5966943@vpnc.org> <4FA55DAE.8020909@pobox.com> <508C47AD-7999-46EB-832A-4D66AAC87118@vpnc.org> In-Reply-To: <508C47AD-7999-46EB-832A-4D66AAC87118@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11940d6e7b3b03e98a3b4d70511e75732d643d3772 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sun, 06 May 2012 07:51:08 -0000 I was mostly being glib, but I think RSA keying has just one advantage: tha= t a single private key operation gets you both server authentication and ke= y exchange. Once the EH extension gets in the way, you are doing two operat= ions anyway, so they might as well be anonymous (EC)DH and a digital signat= ure, regardless of the algorithm. And there's no need to have an (EC)DH certificate to authenticate the first= CCS. The authentication comes later with a digital signature. Yoav=20 -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Paul = Hoffman Sent: 05 May 2012 21:22 To: Michael D'Errico Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt On May 5, 2012, at 10:04 AM, Michael D'Errico wrote: > Paul Hoffman wrote: >> On May 5, 2012, at 9:17 AM, Michael D'Errico wrote: >>> I don't see that as a feature. Telling people that they can't do=20 >>> things the way they've been doing them for a decade doesn't go over wel= l. >> It is hard to tell if you are criticizing the idea of encrypting the han= dshake early, or the first draft of the document. If the former, I would di= sagree: this seems like very useful work. If the latter, a different way to= say this is "I really hope there will be a way to also authenticate with c= urrent forms of TLS authentication if the parties want that". >=20 > I'm sorry if I wasn't clear. I was responding to the idea that=20 > allowing this new extension to be incompatible with TLS_RSA_xxx cipher=20 > suites was a feature. That might have been Yoav being glib (but he might have actually have meant= it...). > I am in favor of encrypting the handshake early, but not if the new=20 > mechanism is incompatible with the way things are done today (many=20 > sites prefer TLS_RSA_xxx cipher suites). >=20 > Adoption will be much faster if server operators don't need to do=20 > anything but upgrade their software. Many have inherited working=20 > configurations and are not expert in cipher suites and key exchange algor= ithms. I don't read the draft as possibly being implemented with only upgrading so= ftware. The server would need to also have a (EC)DH certificate to authenti= cate the first CCS. >> A second, optional authentication seems like a reasonable thing to add t= o the -01 draft, at least to me. >=20 > That can be achieved by adding a second CCS just prior to Finished,=20 > allowing the use of all existing cipher suites defined today. When a=20 > DH-based cipher suite is negotiated, an implementation can treat the=20 > 2nd CCS as a NOOP as an optimization. I would propose that, if the WG likes this work and goes with the option of= a second authentication, that it either be signaled in the original extens= ion, or that it always be mandatory but in the case where it is not needed,= it is done with small packets saying to the effect of "I'm not authenticat= ing a second time" and "yes, I know". --Paul Hoffman _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls Scanned by Check Point Total Security Gateway. From mbadra@gmail.com Sun May 6 00:56:21 2012 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 B100921F844D for ; Sun, 6 May 2012 00:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 G9eC7meSX8Oc for ; Sun, 6 May 2012 00:56:21 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4FC21F844B for ; Sun, 6 May 2012 00:56:21 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3377411vbb.31 for ; Sun, 06 May 2012 00:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VewIMpZHgFmx35zc44sHlr9y69GMa896nEQz5ro6axQ=; b=eYkeKWRoacpRtCj+DrviRUf0yNsPpmprF2K+mrS9hMCWUdKRVNBzaMv9CqCijuczkq VsI0SZ/O6KVmjz+EWhR/NjOdS14zvhIzTeQwuE3aqpE+cWx0aDGBVswBUO86z2Ko4uqX fx0ZGoeptzStm9ZP8R1TMl/sSA/4mlQ8nHfGKSoy3XHxJGO/CpJafjMtvMZBsUDz8XIg 02abs7GGu/9fP1ItLjR3LM5Vmm3qc3DWhr2CdRpcGTGWyW/uzUTYCtSy0UWcZE76x/FN eIiwphxJBCNKhS90iidrdZP1tq2+rPQyS1uwD3PmHr/gKa9/xAvSj6SMDZJH5IZigJFW wwLQ== MIME-Version: 1.0 Received: by 10.220.218.136 with SMTP id hq8mr7431538vcb.68.1336290980625; Sun, 06 May 2012 00:56:20 -0700 (PDT) Received: by 10.220.5.20 with HTTP; Sun, 6 May 2012 00:56:20 -0700 (PDT) In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F017A7C056C48@il-ex01.ad.checkpoint.com> References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> <4FA55298.9010203@pobox.com> <65A74BBD-AA6D-447C-898D-8CB8C5966943@vpnc.org> <4FA55DAE.8020909@pobox.com> <508C47AD-7999-46EB-832A-4D66AAC87118@vpnc.org> <006FEB08D9C6444AB014105C9AEB133F017A7C056C48@il-ex01.ad.checkpoint.com> Date: Sun, 6 May 2012 11:56:20 +0400 Message-ID: From: Mohamad Badra To: Yoav Nir Content-Type: multipart/alternative; boundary=14dae9cfccb4377e8f04bf597d07 Cc: Paul Hoffman , "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sun, 06 May 2012 07:56:21 -0000 --14dae9cfccb4377e8f04bf597d07 Content-Type: text/plain; charset=ISO-8859-1 On Sun, May 6, 2012 at 11:50 AM, Yoav Nir wrote: > > And there's no need to have an (EC)DH certificate to authenticate the > first CCS. The authentication comes later with a digital signature. > How then you will be protected against active attacks? Best regards Badra --14dae9cfccb4377e8f04bf597d07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sun, May 6, 2012 at = 11:50 AM, Yoav Nir <ynir@checkpoint.com> wrote:

And there's no need to have an (EC)DH certificate to authenticate the f= irst CCS. The authentication comes later with a digital signature.


How then you will be protected against active= attacks?
Best regards
Badra
--14dae9cfccb4377e8f04bf597d07-- From ynir@checkpoint.com Sun May 6 01:05:03 2012 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 1A89321F847E for ; Sun, 6 May 2012 01:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.379 X-Spam-Level: X-Spam-Status: No, score=-10.379 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 lWNitxvEqQlw for ; Sun, 6 May 2012 01:05:02 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D7CB021F847A for ; Sun, 6 May 2012 01:05:01 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q4684tCm028336; Sun, 6 May 2012 11:04:55 +0300 X-CheckPoint: {4FA63E4E-3-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 6 May 2012 11:04:53 +0300 From: Yoav Nir To: Mohamad Badra Date: Sun, 6 May 2012 11:04:56 +0300 Thread-Topic: [TLS] draft-ray-tls-encrypted-handshake-00.txt Thread-Index: Ac0rXurMfStZQdb8TAyqZZr/ybdw7A== Message-ID: <5B46AA77-90A1-4BC8-92E7-B4533B36F78D@checkpoint.com> References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> <4FA55298.9010203@pobox.com> <65A74BBD-AA6D-447C-898D-8CB8C5966943@vpnc.org> <4FA55DAE.8020909@pobox.com> <508C47AD-7999-46EB-832A-4D66AAC87118@vpnc.org> <006FEB08D9C6444AB014105C9AEB133F017A7C056C48@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11bf376c9e60e93aa54dabc659054a71d56c787c53 Content-Type: multipart/alternative; boundary="_000_5B46AA7790A14BC892E7B4533B36F78Dcheckpointcom_" MIME-Version: 1.0 Cc: Paul Hoffman , "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sun, 06 May 2012 08:05:03 -0000 --_000_5B46AA7790A14BC892E7B4533B36F78Dcheckpointcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On May 6, 2012, at 10:56 AM, Mohamad Badra wrote: On Sun, May 6, 2012 at 11:50 AM, Yoav Nir > wrote: And there's no need to have an (EC)DH certificate to authenticate the first= CCS. The authentication comes later with a digital signature. How then you will be protected against active attacks? Best regards Badra It depends on what the signature covers. If it covers the unencrypted clien= tHello and serverHello, and is signed with the private key associated with = the server certificate, what can an active attacker do? They can complete = the handshake with the client, and a separate handshake with the server, bu= t they can either copy the client's DH public key, in which case they won't= have the master secret, or they can generate their own, in which case the = signature won't verify. Yoav --_000_5B46AA7790A14BC892E7B4533B36F78Dcheckpointcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
On May 6, 20= 12, at 10:56 AM, Mohamad Badra wrote:



On Sun, May 6, 2012 at 11:50 AM, Yoav Nir <= ynir@checkpoint.co= m> wrote:

And there's no need to have an (EC)DH certificate to authenticate the first= CCS. The authentication comes later with a digital signature.


How then you will be protected against active= attacks?
Best regards
Badra

It depends on what the signature covers. If it = covers the unencrypted clientHello and serverHello, and is signed with the = private key associated with the server certificate, what can an active atta= cker do?  They can complete the handshake with the client, and a separ= ate handshake with the server, but they can either copy the client's DH pub= lic key, in which case they won't have the master secret, or they can gener= ate their own, in which case the signature won't verify.

Yoav

= --_000_5B46AA7790A14BC892E7B4533B36F78Dcheckpointcom_-- From n.mavrogiannopoulos@gmail.com Sun May 6 01:36:39 2012 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 3F5C521F8473 for ; Sun, 6 May 2012 01:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 pGm6CqQgGRPo for ; Sun, 6 May 2012 01:36:38 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 45C7621F845F for ; Sun, 6 May 2012 01:36:38 -0700 (PDT) Received: by eabd1 with SMTP id d1so735402eab.31 for ; Sun, 06 May 2012 01:36:37 -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=ZwBc4x/67qiy4Ca9kK2EMXBRYmf28GSKrESyZXkBXxE=; b=Z/6/ryXn5E7wEU7zGvFJv/5cruNc7zsAmsrL1lRatBpIwDwvw3ginZMyXnP0GKjLVn kHRFCrcW0jYzXNHQmMW9EywAN8TKn1nGskkHdMY16AOUcb0kbzL5ddgO99BFjoh2ym/S ZTE1OhQmAS8ghKEY4KEjA5iQ4YztpsaQlKzKwvC6sOy6PW6lo4xToZdlN2DU/nL/3boA 5Zm6T9oHTIL/D4GfCL//+7KSWdYPPgjIxWCztKBaFdLZ0BiE0Y32axuXkrck4jBdUE4S mQGxxVKGYewisiXF8U4yh64P71ynqSuY4oUpTLnbtrmkArYQ7ePRcf//uwYevQJalGQ2 Lm2w== Received: by 10.14.149.148 with SMTP id x20mr2085731eej.44.1336293397232; Sun, 06 May 2012 01:36:37 -0700 (PDT) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id f16sm37155886eec.2.2012.05.06.01.36.36 (version=SSLv3 cipher=OTHER); Sun, 06 May 2012 01:36:36 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4FA63814.8010405@gnutls.org> Date: Sun, 06 May 2012 10:36:36 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: "tls@ietf.org" References: <4FA401F7.5060003@extendedsubset.com> In-Reply-To: <4FA401F7.5060003@extendedsubset.com> X-Enigmail-Version: 1.4 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sun, 06 May 2012 08:36:39 -0000 On 05/04/2012 06:21 PM, Marsh Ray wrote: > > I would appreciate it if the participants of the TLS WG will give this > draft a reading and serious consideration to taking it up as a work item Hello, I like the draft and I support having it as a WG item. Some questions: * client_required, client_requested, Instead of those two fields, why not just sending a single list with all acceptable levels? * conditional_extensions, I think this is complicated. Why not assume that the extensions present in the hello are valid? * cipher_suites in ClientDHParamSet Wouldn't it be beneficial to define all the ciphersuites this extension can be used with? As far as I understand most/all of the SRP, (EC)DHE-PSK, and (EC)DHE are valid. > * I believe it may help a little with the issue Nikos Mavrogiannopoulos and I were discussing, where an attacker is able to trick the client into interpreting the server's signed key exchange parameters as the wrong type of structure. In an unexpected way though. The signature on the server again only covers the parameters but not the keyExchangeAlgorithm, but this time the parameters are sent by the client and only repeated by the server. (I don't know whether this is sufficient to prevent all such attacks, but this isn't the goal of this draft anyways) regards, Nikos From mbadra@gmail.com Sun May 6 01:49:37 2012 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 9BDBE21F849A for ; Sun, 6 May 2012 01:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 1KNw3aZdNvK9 for ; Sun, 6 May 2012 01:49:37 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F2DB721F8499 for ; Sun, 6 May 2012 01:49:36 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3388532vbb.31 for ; Sun, 06 May 2012 01:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eAUXOZntVZ11FvzNAFnQg2AMAR54B5FTjzvj13VoMBk=; b=ENSLyKo4/+zR/RBLktXMVxmn8YEVziv36JzwKtIEE2i1TRxlUTP/akkD/TeAppMKLd siMCfOxrKMJCM/vc5cIIa6Bc4/B7wg/dmQdsjqTJ2ZIUT4tqj+Jbuv+DtNga2rXphevB Cb6X0wm4psmU5H1Mbe5oLZpVH4dBHv1KDim9U1gcA1vcUUXLkkbKj42KQHiShfEH5fmO JC2djH+eAgeN4QD2FXRl8rwUcrzbkuO03XYJtL97kiOR5fn7razOha1EZuplycjXSbzi yoeZ209qR71ri8vFhY/ddvQwANU7/6zPPy1mRr8ME2lt0cuQ6KzRDFpxxYLunP6dzXYc NHUg== MIME-Version: 1.0 Received: by 10.52.90.225 with SMTP id bz1mr1135234vdb.92.1336294176448; Sun, 06 May 2012 01:49:36 -0700 (PDT) Received: by 10.220.5.20 with HTTP; Sun, 6 May 2012 01:49:36 -0700 (PDT) In-Reply-To: <5B46AA77-90A1-4BC8-92E7-B4533B36F78D@checkpoint.com> References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> <4FA55298.9010203@pobox.com> <65A74BBD-AA6D-447C-898D-8CB8C5966943@vpnc.org> <4FA55DAE.8020909@pobox.com> <508C47AD-7999-46EB-832A-4D66AAC87118@vpnc.org> <006FEB08D9C6444AB014105C9AEB133F017A7C056C48@il-ex01.ad.checkpoint.com> <5B46AA77-90A1-4BC8-92E7-B4533B36F78D@checkpoint.com> Date: Sun, 6 May 2012 12:49:36 +0400 Message-ID: From: Mohamad Badra To: Yoav Nir Content-Type: multipart/alternative; boundary=20cf307d010cb3e23a04bf5a3bc0 Cc: Paul Hoffman , "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sun, 06 May 2012 08:49:37 -0000 --20cf307d010cb3e23a04bf5a3bc0 Content-Type: text/plain; charset=ISO-8859-1 On Sun, May 6, 2012 at 12:04 PM, Yoav Nir wrote: > > On May 6, 2012, at 10:56 AM, Mohamad Badra wrote: > > > > On Sun, May 6, 2012 at 11:50 AM, Yoav Nir wrote: > >> >> And there's no need to have an (EC)DH certificate to authenticate the >> first CCS. The authentication comes later with a digital signature. >> > > > How then you will be protected against active attacks? > Best regards > Badra > > > It depends on what the signature covers. If it covers the unencrypted > clientHello and serverHello, and is signed with the private key associated > with the server certificate, what can an active attacker do? They can > complete the handshake with the client, and a separate handshake with the > server, but they can either copy the client's DH public key, in which case > they won't have the master secret, or they can generate their own, in which > case the signature won't verify. > I was reading "no need to have an (EC)DH certificate to authenticate the first CCS". In that case, active attacks are possible. Best regards Badra --20cf307d010cb3e23a04bf5a3bc0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sun, May 6, 2012 at 12:04 PM, Yoav Nir <yn= ir@checkpoint.com> wrote:

On May 6, 2012, at 10:56 AM, Mohamad Badra wrote:



On Sun, May 6, 2012 at 11:50 AM, Yoav Nir <yn= ir@checkpoint.com> wrote:

And there's no need to have a= n (EC)DH certificate to authenticate the first CCS. The authentication come= s later with a digital signature.


How then you will be protected against active attacks?
Best regards
Badra

It depends on what the signature covers. If it covers the unencrypted = clientHello and serverHello, and is signed with the private key associated = with the server certificate, what can an active attacker do? =A0They can co= mplete the handshake with the client, and a separate handshake with the ser= ver, but they can either copy the client's DH public key, in which case= they won't have the master secret, or they can generate their own, in = which case the signature won't verify.
=A0
=A0
I was reading "no need to have an (EC)DH certificate to authentic= ate the first CCS". In that case, active attacks are possible.
=A0
Best regards
Badra
--20cf307d010cb3e23a04bf5a3bc0-- From marsh@extendedsubset.com Sun May 6 09:00:11 2012 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 4B63C21F84D2 for ; Sun, 6 May 2012 09:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 GHPN5j7HTYxm for ; Sun, 6 May 2012 09:00:10 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id CCD1421F84D0 for ; Sun, 6 May 2012 09:00:09 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SR3sX-000KIo-CN; Sun, 06 May 2012 16:00:09 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 3029167A6; Sun, 6 May 2012 16:00:08 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19PIoAnUl45jx0fHHohqdL0yNbJKqumYz4= Message-ID: <4FA6A005.7010001@extendedsubset.com> Date: Sun, 06 May 2012 11:00:05 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: <4FA401F7.5060003@extendedsubset.com> <4FA63814.8010405@gnutls.org> In-Reply-To: <4FA63814.8010405@gnutls.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sun, 06 May 2012 16:00:12 -0000 On 05/06/2012 03:36 AM, Nikos Mavrogiannopoulos wrote: > > * client_required, client_requested, Instead of those two fields, > why not just sending a single list with all acceptable levels? That could work too. There are just three levels including "zero". I don't know how likely it is that there will ever be more. A list would likely take as much or more space and as a variable length field it would be slightly more complex to process securely. My sense is that having two fields, requested and required, gives the negotiation a little more flexibility, like hard and soft limits for a resource quota system. By setting the required level higher than requested, it also gives a neat way to query the server for what he can support. I can envision a website admin thinking "I don't want to enable this new feature for everyone by default because I heard it costs an extra 5 ms CPU". But there are clients who would like to indicate that they "really do need at least level one" because they expect to use a client cert or the browser is in some type of enhanced privacy configuration. It could be beneficial for the server to have a way to indicate requested and required as well. For example, a high-security latency-tolerant server may wish to require level two at all times. Such an application may be better off requiring renegotiation though. Alternatively, there may be a consensus that this is all just unnecessary complexity. One early reviewer has expressed a preference to have the client simply request a level and if he didn't get what he requires the handshake fails. > * conditional_extensions, I think this is complicated. Why not > assume that the extensions present in the hello are valid? The idea behind this is that there may be extensions which the client is willing to send the CH extension in the clear when level one may be negotiated, but strongly prefers that the server not send his SH extension reply in the clear. I don't know which (if any) existing extensions might benefit from this. NP(N) may be such an extension, if it worked one of the ways being discussed. That was where the NP Client Hello extension is basically empty to signal support for the feature but the Server Hello extension contains a list of protocols the server supports for the client to select from in a subsequent message. If this list is sent in the clear and contains only one protocol (and who isn't going to set up a websockets or spdy.example.com?) then that's nearly equivalent to sending the next protocol in the clear. Again there may be a consensus that this is all just unnecessary complexity. It may be that no currently defined extensions would benefit from this and extensions defined in the future could simply require EH level one. > * cipher_suites in ClientDHParamSet Wouldn't it be beneficial to > define all the ciphersuites this extension can be used with? As far > as I understand most/all of the SRP, (EC)DHE-PSK, and (EC)DHE are > valid. I don't really know, others in [TLS] would have a better sense of this than I do. I thought it might be beneficial to define it without regard to any specific cipher suites so new cipher suites could be defined in the future without needing to update the EH. But the format of the DH params were defined as part of TLS. So the 'select's for DH param format in the definition of the EH extension and the ServerHello2a represent a combination of the corresponding structure from RFC 5246 (TLS 1.2) and RFC 4492 (ECC). - Marsh From marsh@extendedsubset.com Sun May 6 09:54:00 2012 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 49DCC21F84F0 for ; Sun, 6 May 2012 09:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=0.198, 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 ZC8JKoS0WNhw for ; Sun, 6 May 2012 09:53:59 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 67A4E21F84EB for ; Sun, 6 May 2012 09:53:59 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SR4ic-000FvW-KE; Sun, 06 May 2012 16:53:58 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 0D04B6081; Sun, 6 May 2012 16:53:57 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/X8PT31iY6hqRuwIpW4MKNvQOuUhQy8AI= Message-ID: <4FA6ACA1.8080603@extendedsubset.com> Date: Sun, 06 May 2012 11:53:53 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mohamad Badra References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> <4FA55298.9010203@pobox.com> <65A74BBD-AA6D-447C-898D-8CB8C5966943@vpnc.org> <4FA55DAE.8020909@pobox.com> <508C47AD-7999-46EB-832A-4D66AAC87118@vpnc.org> <006FEB08D9C6444AB014105C9AEB133F017A7C056C48@il-ex01.ad.checkpoint.com> <5B46AA77-90A1-4BC8-92E7-B4533B36F78D@checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sun, 06 May 2012 16:54:00 -0000 On 05/06/2012 03:49 AM, Mohamad Badra wrote: > > I was reading "no need to have an (EC)DH certificate to authenticate the > first CCS". In that case, active attacks are possible. Right, EH does not resist active attacks. It is possible for an active attacker to learn what the client or server would have sent in the handshake. But any such attack causes the handshake to fail in all the scenarios where TLS currently provides integrity protection, i.e., everywhere except for anon-anon DH connections or a pwned trusted root CA. It may be possible to get better guarantees for messages that are sent after the Client Key Exchange or Server Key exchange (such as RFC 4680 'Supplemental Data' messages). But some TLS implementations reportedly do not check these signatures until the Finished messages and many non-browser clients do not even look at the name on the server cert until the handshake is complete. This means that the protections offered by EH to client certs is limited. Applications requiring serious security for the content of client certs should still use renegotiation. If the client has an interest in protecting the client cert he MUST NOT transmit the client cert until he's fully authenticated the server. Generally this requires renegotiation, but many servers will not allow the client to initiate that. Consequently, general purpose clients like web browsers can be tricked into transmitting the client cert to an active attacker. The only thing that can fix that is to change the client behavior to be more strict. In order to avoid breaking existing applications, clients can only become more strict if they are given positive indication to do so. Most forms of negotiation can be falsified by an active attacker at the point the client cert must be sent. So AFAICT the only way that a client cert used by web browsers can be protected from active attackers is to encode a positive indication in the client cert itself to require such protection. This must take the form of an authorization mechanism defining which server identities are allowed to receive the plaintext client cert and how they may be authenticated. If such a mechanism is ever put in place, EH may be able to optimize out the renegotiation. But we would have to approach that very carefully because the signature on the Server Key Exchange does not provide the same security properties as that of the server Finished. - Marsh From stephen.farrell@cs.tcd.ie Sun May 6 10:05:21 2012 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 A13E221F84F8 for ; Sun, 6 May 2012 10:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 Xxo6XF3dxlIl for ; Sun, 6 May 2012 10:05:20 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 9F44E21F84F0 for ; Sun, 6 May 2012 10:05:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 776231714FF; Sun, 6 May 2012 18:05:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1336323914; bh=QoSyoygGU1jyl/ Jn67mKX9Rmanb1FgKDyVFVW4lSS1Y=; b=UkLMJ6XinnJcoJhRWU8+U0ChgPa1ts iFNasLE4iqYG1wpGCtRLvhYAovdxGtYbQxG1UzHboqg0Lw2hEJgg/u56GsKP4tVh 4IY1A9W6JYwS9F2b7EsBJphAk/6Tt+8SjgvjsmMPj/FH5eztqrNrHqQogH5puCW3 Ni3Yq/hlA5WpYw9oLuW8LtLVriOqWnQLYkI5RM64weMD+9nN08PZZi3C9S9yV5/A 6dUD/rzTfDHxMAx72G/I+T27uhjMJy1AYsDG372f09/ohizQ/dn1+e+FauqJsyXi Wuxa2xTSzggoXh5aPJkysbV+7jBVGUzdqQr3qReIQ6wDnvnwebQjyq6A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id E3WWQsg7g7Ej; Sun, 6 May 2012 18:05:14 +0100 (IST) Received: from [10.87.48.9] (unknown [86.44.65.213]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 598211714FC; Sun, 6 May 2012 18:05:13 +0100 (IST) Message-ID: <4FA6AF48.3070906@cs.tcd.ie> Date: Sun, 06 May 2012 18:05:12 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Marsh Ray References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> <4FA55298.9010203@pobox.com> <65A74BBD-AA6D-447C-898D-8CB8C5966943@vpnc.org> <4FA55DAE.8020909@pobox.com> <508C47AD-7999-46EB-832A-4D66AAC87118@vpnc.org> <006FEB08D9C6444AB014105C9AEB133F017A7C056C48@il-ex01.ad.checkpoint.com> <5B46AA77-90A1-4BC8-92E7-B4533B36F78D@checkpoint.com> <4FA6ACA1.8080603@extendedsubset.com> In-Reply-To: <4FA6ACA1.8080603@extendedsubset.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sun, 06 May 2012 17:05:21 -0000 Probably too complex to be worth it, but I guess a client could send encrypted forms of values like NPN, client-cert, using a symmetric key that the client generates but only exposes to the server after the handshake has succeeded. If a generic approach for early encryption is worth it, it could be (though I doubt it) that only allowing deciphering of those values after the h/s succeeds might also be worth it. That'd force the mitm to complete the h/s to get at the private info and would increase accountability maybe and also remove some obvious unauthenticated mitm possibilities. S On 05/06/2012 05:53 PM, Marsh Ray wrote: > On 05/06/2012 03:49 AM, Mohamad Badra wrote: >> >> I was reading "no need to have an (EC)DH certificate to authenticate the >> first CCS". In that case, active attacks are possible. > > Right, EH does not resist active attacks. It is possible for an active > attacker to learn what the client or server would have sent in the > handshake. But any such attack causes the handshake to fail in all the > scenarios where TLS currently provides integrity protection, i.e., > everywhere except for anon-anon DH connections or a pwned trusted root CA. > > It may be possible to get better guarantees for messages that are sent > after the Client Key Exchange or Server Key exchange (such as RFC 4680 > 'Supplemental Data' messages). But some TLS implementations reportedly > do not check these signatures until the Finished messages and many > non-browser clients do not even look at the name on the server cert > until the handshake is complete. > > This means that the protections offered by EH to client certs is > limited. Applications requiring serious security for the content of > client certs should still use renegotiation. > > If the client has an interest in protecting the client cert he MUST NOT > transmit the client cert until he's fully authenticated the server. > Generally this requires renegotiation, but many servers will not allow > the client to initiate that. > > Consequently, general purpose clients like web browsers can be tricked > into transmitting the client cert to an active attacker. The only thing > that can fix that is to change the client behavior to be more strict. In > order to avoid breaking existing applications, clients can only become > more strict if they are given positive indication to do so. Most forms > of negotiation can be falsified by an active attacker at the point the > client cert must be sent. > > So AFAICT the only way that a client cert used by web browsers can be > protected from active attackers is to encode a positive indication in > the client cert itself to require such protection. This must take the > form of an authorization mechanism defining which server identities are > allowed to receive the plaintext client cert and how they may be > authenticated. > > If such a mechanism is ever put in place, EH may be able to optimize out > the renegotiation. But we would have to approach that very carefully > because the signature on the Server Key Exchange does not provide the > same security properties as that of the server Finished. > > - Marsh > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > From ynir@checkpoint.com Sun May 6 11:00:53 2012 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 CE46921F8534 for ; Sun, 6 May 2012 11:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.384 X-Spam-Level: X-Spam-Status: No, score=-10.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 26wYv+nA79xY for ; Sun, 6 May 2012 11:00:53 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C7F3921F84F8 for ; Sun, 6 May 2012 11:00:52 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q46I0gAs015115; Sun, 6 May 2012 21:00:43 +0300 X-CheckPoint: {4FA6C9EC-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 6 May 2012 21:00:41 +0300 From: Yoav Nir To: Marsh Ray Date: Sun, 6 May 2012 21:00:36 +0300 Thread-Topic: [TLS] draft-ray-tls-encrypted-handshake-00.txt Thread-Index: Ac0rsiXRYf0yoC0NRPCXyGBDFD+E1g== Message-ID: <55D3931D-2F6F-4749-A45E-6027021A1468@checkpoint.com> References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> <4FA55298.9010203@pobox.com> <65A74BBD-AA6D-447C-898D-8CB8C5966943@vpnc.org> <4FA55DAE.8020909@pobox.com> <508C47AD-7999-46EB-832A-4D66AAC87118@vpnc.org> <006FEB08D9C6444AB014105C9AEB133F017A7C056C48@il-ex01.ad.checkpoint.com> <5B46AA77-90A1-4BC8-92E7-B4533B36F78D@checkpoint.com> <4FA6ACA1.8080603@extendedsubset.com> In-Reply-To: <4FA6ACA1.8080603@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11e83128f69608a32ef3454544c8a63f9c39156825 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Hoffman , "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sun, 06 May 2012 18:00:53 -0000 On May 6, 2012, at 7:53 PM, Marsh Ray wrote: > On 05/06/2012 03:49 AM, Mohamad Badra wrote: >>=20 >> I was reading "no need to have an (EC)DH certificate to authenticate the >> first CCS". In that case, active attacks are possible. >=20 > Right, EH does not resist active attacks. It is possible for an active=20 > attacker to learn what the client or server would have sent in the=20 > handshake. But any such attack causes the handshake to fail in all the=20 > scenarios where TLS currently provides integrity protection, i.e.,=20 > everywhere except for anon-anon DH connections or a pwned trusted root CA= . >=20 > It may be possible to get better guarantees for messages that are sent=20 > after the Client Key Exchange or Server Key exchange (such as RFC 4680=20 > 'Supplemental Data' messages). But some TLS implementations reportedly=20 > do not check these signatures until the Finished messages and many=20 > non-browser clients do not even look at the name on the server cert=20 > until the handshake is complete. >=20 > This means that the protections offered by EH to client certs is=20 > limited. Applications requiring serious security for the content of=20 > client certs should still use renegotiation. >=20 > If the client has an interest in protecting the client cert he MUST NOT=20 > transmit the client cert until he's fully authenticated the server.=20 > Generally this requires renegotiation, but many servers will not allow=20 > the client to initiate that. >=20 > Consequently, general purpose clients like web browsers can be tricked=20 > into transmitting the client cert to an active attacker. The only thing=20 > that can fix that is to change the client behavior to be more strict. In= =20 > order to avoid breaking existing applications, clients can only become=20 > more strict if they are given positive indication to do so. Most forms=20 > of negotiation can be falsified by an active attacker at the point the=20 > client cert must be sent. I must be missing something. Here's your modified handshake, and I'm assumi= ng (EC)DHE_RSA or (EC)DHE_ECDSA Client Server ClientHello (with EH ext) --------> ServerHello2a [ChangeCipherSpec] ServerHello2b Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone [ChangeCipherSpec] Certificate* ClientKeyExchange CertificateVerify* Finished --------> <-------- Finished Application Data <-------> Application Data An active attacker can either move DH public keys between the client and se= rver, but in that case it won't have the shared secret, and so - no certifi= cate So the active attacker has to perform a different DH with each side. But th= at means that the ServerKeyExchange from the server signs a different publi= c key from the one the client saw, so that's not valid, and the attacker ca= n't generate one that is appropriate, because it doesn't have the private k= ey for the server certificate. So regardless of whether ECDSA or RSA keys are used, how can the attacker g= et the certificate? Yoav From marsh@extendedsubset.com Sun May 6 11:09:50 2012 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 6D9DB21F853F for ; Sun, 6 May 2012 11:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 SdAHdgxgJqub for ; Sun, 6 May 2012 11:09:49 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id C653721F844F for ; Sun, 6 May 2012 11:09:49 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SR5u0-000ILT-UK; Sun, 06 May 2012 18:09:48 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 213956081; Sun, 6 May 2012 18:09:47 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19xMaM9iR/lSLl9R7V+YseoR6odgTQrQ+A= Message-ID: <4FA6BE67.3080109@extendedsubset.com> Date: Sun, 06 May 2012 13:09:43 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Yoav Nir References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> <4FA55298.9010203@pobox.com> <65A74BBD-AA6D-447C-898D-8CB8C5966943@vpnc.org> <4FA55DAE.8020909@pobox.com> <508C47AD-7999-46EB-832A-4D66AAC87118@vpnc.org> <006FEB08D9C6444AB014105C9AEB133F017A7C056C48@il-ex01.ad.checkpoint.com> <5B46AA77-90A1-4BC8-92E7-B4533B36F78D@checkpoint.com> <4FA6ACA1.8080603@extendedsubset.com> <55D3931D-2F6F-4749-A45E-6027021A1468@checkpoint.com> In-Reply-To: <55D3931D-2F6F-4749-A45E-6027021A1468@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sun, 06 May 2012 18:09:50 -0000 On 05/06/2012 01:00 PM, Yoav Nir wrote: > > So regardless of whether ECDSA or RSA keys are used, how can the attacker get the certificate? He simply tells the client that the server doesn't support EH at all. - Marsh From ynir@checkpoint.com Sun May 6 11:28:28 2012 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 9F1FD21F851B for ; Sun, 6 May 2012 11:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.388 X-Spam-Level: X-Spam-Status: No, score=-10.388 tagged_above=-999 required=5 tests=[AWL=0.211, 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 e4MpFDBKl6Xr for ; Sun, 6 May 2012 11:28:28 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id BE54C21F84E6 for ; Sun, 6 May 2012 11:28:27 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q46ISEFx017025; Sun, 6 May 2012 21:28:14 +0300 X-CheckPoint: {4FA6D05E-1-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 6 May 2012 21:28:13 +0300 From: Yoav Nir To: Marsh Ray Date: Sun, 6 May 2012 21:28:08 +0300 Thread-Topic: [TLS] draft-ray-tls-encrypted-handshake-00.txt Thread-Index: Ac0rtf6tOKUVU3NZQc28IPCDz8MuKg== Message-ID: <3D09371F-81DC-4C60-93DB-5055EB7102A7@checkpoint.com> References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> <4FA55298.9010203@pobox.com> <65A74BBD-AA6D-447C-898D-8CB8C5966943@vpnc.org> <4FA55DAE.8020909@pobox.com> <508C47AD-7999-46EB-832A-4D66AAC87118@vpnc.org> <006FEB08D9C6444AB014105C9AEB133F017A7C056C48@il-ex01.ad.checkpoint.com> <5B46AA77-90A1-4BC8-92E7-B4533B36F78D@checkpoint.com> <4FA6ACA1.8080603@extendedsubset.com> <55D3931D-2F6F-4749-A45E-6027021A1468@checkpoint.com> <4FA6BE67.3080109@extendedsubset.com> In-Reply-To: <4FA6BE67.3080109@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11d4c3248fec40d14e0a25faf1e34f2e0ff187965e Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Hoffman , "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sun, 06 May 2012 18:28:28 -0000 On May 6, 2012, at 9:09 PM, Marsh Ray wrote: > On 05/06/2012 01:00 PM, Yoav Nir wrote: >>=20 >> So regardless of whether ECDSA or RSA keys are used, how can the attacke= r get the certificate? >=20 > He simply tells the client that the server doesn't support EH at all. Right. I see. That's what I was missing. > So AFAICT the only way that a client cert used by web browsers can be=20 > protected from active attackers is to encode a positive indication in=20 > the client cert itself to require such protection. This must take the=20 > form of an authorization mechanism defining which server identities are=20 > allowed to receive the plaintext client cert and how they may be=20 > authenticated. Wouldn't it be better to encode this indication in the server certificate? = That way, the question of whether to send the certificate in the clear to a= non-supporting server can be left to the client's local policy. Yoav From marsh@extendedsubset.com Sun May 6 11:59:44 2012 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 7020921F854A for ; Sun, 6 May 2012 11:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 xKHnQoo+0qcG for ; Sun, 6 May 2012 11:59:43 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id CFC7C21F8549 for ; Sun, 6 May 2012 11:59:43 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SR6gI-000DNi-T1; Sun, 06 May 2012 18:59:42 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 5BB256081; Sun, 6 May 2012 18:59:41 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+hgegVNG4qJ/tAq0Enuh35/0eZivpWClY= Message-ID: <4FA6CA1A.9010202@extendedsubset.com> Date: Sun, 06 May 2012 13:59:38 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Yoav Nir References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> <4FA55298.9010203@pobox.com> <65A74BBD-AA6D-447C-898D-8CB8C5966943@vpnc.org> <4FA55DAE.8020909@pobox.com> <508C47AD-7999-46EB-832A-4D66AAC87118@vpnc.org> <006FEB08D9C6444AB014105C9AEB133F017A7C056C48@il-ex01.ad.checkpoint.com> <5B46AA77-90A1-4BC8-92E7-B4533B36F78D@checkpoint.com> <4FA6ACA1.8080603@extendedsubset.com> <55D3931D-2F6F-4749-A45E-6027021A1468@checkpoint.com> <4FA6BE67.3080109@extendedsubset.com> <3D09371F-81DC-4C60-93DB-5055EB7102A7@checkpoint.com> In-Reply-To: <3D09371F-81DC-4C60-93DB-5055EB7102A7@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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: Sun, 06 May 2012 18:59:44 -0000 On 05/06/2012 01:28 PM, Yoav Nir wrote: > > On May 6, 2012, at 9:09 PM, Marsh Ray wrote: >> So AFAICT the only way that a client cert used by web browsers can >> be protected from active attackers is to encode a positive >> indication in the client cert itself to require such protection. >> This must take the form of an authorization mechanism defining >> which server identities are allowed to receive the plaintext client >> cert and how they may be authenticated. > > Wouldn't it be better to encode this indication in the server > certificate? That way, the question of whether to send the > certificate in the clear to a non-supporting server can be left to > the client's local policy. With RSA key exchange, the client has no way to verify that the party on the end of the wire is in possession of the private key to the cert until he receives and validates the server's Finished message. Even with DHE key exchange where the parameters are signed in the Server Key Exchange message it could be simply a relay of a signature the MitM collected from the legitimate server after presenting the same Client Hello random. Without EH, the client sends the client cert in the clear. With EH the client cert would be sent encrypted, but except for the randoms and the server dh params every other part of the handshake is subject to modification by the attacker. So it's a tricky proposition to prove that there is no possible way for an active attacker to construct a set of messages that, when combined with the server's signed SKE message, would allow the attacker to decrypt the client cert. I suspect that's not possible to prove in the general case, because new cipher suites could be defined in the future that allow the attacker to give new meanings to whatever the server signs. Current applications expect the client to send his client cert upon request, so it really seems like the client will need some permission before he can refuse such a request. I don't think we can realistically expect browser users to configure their browser into strict-client-cert mode before going online. So the only way (I can think of) for a useful policy to get implemented is for the client cert itself to contain a critical attribute to authorize a server's request for it. - Marsh From ekr@rtfm.com Sun May 6 12:25:15 2012 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 AA8E521F8554 for ; Sun, 6 May 2012 12:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.869 X-Spam-Level: X-Spam-Status: No, score=-102.869 tagged_above=-999 required=5 tests=[AWL=0.108, 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 GTWb-4kYeTXz for ; Sun, 6 May 2012 12:25:15 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id F2DE321F8552 for ; Sun, 6 May 2012 12:25:14 -0700 (PDT) Received: by vcge1 with SMTP id e1so168270vcg.31 for ; Sun, 06 May 2012 12:25:14 -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:content-type:x-gm-message-state; bh=9smspPswgIeOPhoNE9HKQXxM81i6vmIlXSd2tsBe2iA=; b=YvCwu64nvdHSRshzx7fPoMAXsJyziGKdVslhQjo7pc12NmoTfbSqfxjQtBwCLXszQ8 DjZcJODS4gUFqlGhd1iAnxrDC+P/YsNGcUOqa4h9WNx3UC7o4Ph76C3BEWm3OCGJ9wXa vrHX51jQ1KVqVNRQfxRqM67N370Q/daDPcCfvgh62XQKi23BY1F3nVdgNj52iJbirFt0 VbG0JeWdNfGUbRyQTidp6DaD+8hw9Wj1CvN/gaf3BEnvCz1hThvu/CpYBlIJhnSrkPDD 1blU1eNZhnKc/69Fkf5gbfDX0YWRJvoQPLBTR30X/oETGbcETj5+dBO+3nPEDbxYrwwE Gk7Q== Received: by 10.220.239.81 with SMTP id kv17mr4311011vcb.2.1336332314504; Sun, 06 May 2012 12:25:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Sun, 6 May 2012 12:24:34 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Sun, 6 May 2012 12:24:34 -0700 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkKMPzOpjcL8dHpG2jIFGduPRhmT054UehBUmUJ4GIAeAjgYFyNxfFf7ox1753SybtjIUeV Subject: Re: [TLS] Call for acceptance on multi-stapling 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: Sun, 06 May 2012 19:25:15 -0000 The chairs have gone over the list discussion and have concluded that there is rough consensus to accept this document as a WG item. We have asked Yngve to prepare a new draft and submit. -Ekr [For the chairs.] On Wed, Apr 18, 2012 at 2:02 PM, Eric Rescorla wrote: > WG members, > > At the meeting in Paris there was broad consensus to adopt Yngve's > TLS Multi-Stapling draft > (http://www.ietf.org/id/draft-pettersen-tls-ext-multiple-ocsp-03.txt). > > The WG chairs would like to confirm this consensus. Please send any > comments by Wednesday April 25. > > -Ekr > [For the chairs] From ehimawan@gmail.com Sun May 6 21:51:53 2012 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 C38B521F84AA for ; Sun, 6 May 2012 21:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ZR5zWTJoR4rp for ; Sun, 6 May 2012 21:51:52 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7782421F844F for ; Sun, 6 May 2012 21:51:52 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so2524823wib.13 for ; Sun, 06 May 2012 21:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ADCDMdIMAY67DN+M6ykSGJHHa/Wnue9lbEeN7ptXcxg=; b=vkJsjWY8Ycn8ncD/1hbOpjK5bZ4SLKA6hBe3T+tVWJ5WQWBHJjgawXOWwbO0ltEnoc pWHFlzJ6PO22vUN7RFSYfjsonZK5sPK4gRRcWzwvP2yME68cJYcmaNKmUfLYwNYtADAq poZ3UKOVD65pE8MZoSaWpyqpPXR0/Y57KeAx8VfBqDZXxrCK24FAsXDVL31b3boTN4/u lHmCxqzUIsIqWHqI1mgTpjY9nDnH24Sguq4HFI+R5AmkvuTsaksBxNkkTICJ5fQ57cqi TgH64qqEz5wDUYKEzFwgElM9e5qk5YNmGEJvhQnLEMW6c2xqMCD9adYmTVc31vDXPB/r YioQ== MIME-Version: 1.0 Received: by 10.216.143.200 with SMTP id l50mr6965190wej.58.1336366311700; Sun, 06 May 2012 21:51:51 -0700 (PDT) Received: by 10.216.185.201 with HTTP; Sun, 6 May 2012 21:51:51 -0700 (PDT) Date: Sun, 6 May 2012 23:51:51 -0500 Message-ID: From: Erwin Himawan To: tls@ietf.org Content-Type: multipart/alternative; boundary=0016e6dedd8c4c778104bf6b07b3 Subject: [TLS] Compression for DTLS 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, 07 May 2012 04:51:54 -0000 --0016e6dedd8c4c778104bf6b07b3 Content-Type: text/plain; charset=ISO-8859-1 Hi Folks, Is there any compression techniques for DTLS "application data". My "application data" is mostly ASCII, so I would hope, with compression technique, I could effectively transfer more text in one UDP segment. Of course, assuming no IP fragmentation. Thanks, Erwin --0016e6dedd8c4c778104bf6b07b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Folks,

Is there any compression techniques for DTLS &= quot;application data". My "application data" is mostly ASCI= I, so I would hope, with compression technique, I could effectively transfe= r more text in one UDP segment. =A0Of course, assuming no IP fragmentation.=

Thanks,
Erwin
--0016e6dedd8c4c778104bf6b07b3-- From peter.sylvester@edelweb.fr Mon May 7 00:16:33 2012 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 E8A1721F8498 for ; Mon, 7 May 2012 00:16:33 -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 A3yZ0Wc6q6eS for ; Mon, 7 May 2012 00:16:33 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5F33A21F848B for ; Mon, 7 May 2012 00:16:33 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id A58817DB8 for ; Mon, 7 May 2012 09:16:31 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id D2FDF7D67FD for ; Mon, 7 May 2012 09:09:22 +0200 (CEST) Received: from [192.168.0.28] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTPSA id CCFC2236372 for ; Mon, 7 May 2012 03:10:16 -0400 (EDT) Message-ID: <4FA776CF.1080700@edelweb.fr> Date: Mon, 07 May 2012 09:16:31 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: tls@ietf.org References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> <4FA55298.9010203@pobox.com> <65A74BBD-AA6D-447C-898D-8CB8C5966943@vpnc.org> <4FA55DAE.8020909@pobox.com> <508C47AD-7999-46EB-832A-4D66AAC87118@vpnc.org> <006FEB08D9C6444AB014105C9AEB133F017A7C056C48@il-ex01.ad.checkpoint.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F017A7C056C48@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 07 May 2012 07:16:34 -0000 Hi, which currently defined extensions are worth to be "protected". the draft says: Before the Server Name Indication (SNI) extension [RFC 6066], it was not possible to serve multiple HTTPS sites from a single IP address, so the specific site to which the user was connecting was effectively already known. Does that mean that the authors considers the servername as information that should be protected? what happens when IPV6 comes in? Is it unlikely to have one IPV6 adress per server? If the SNI is not send in the initial clienthello, what is a client supposed to do when the serverhello does not indicate support for the new method? If no EH extension is present, the negotiated EH level is zero server continues the TLS connection as usual. The remainder of this section does not apply. how does the client "continue" as usual since it has not send all desired extensions? regards /PS From n.mavrogiannopoulos@gmail.com Mon May 7 00:47:40 2012 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 B79C821F84CF for ; Mon, 7 May 2012 00:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 ZwsPEQOpTmaZ for ; Mon, 7 May 2012 00:47:39 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 84FF321F84B3 for ; Mon, 7 May 2012 00:47:39 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so3238926wgb.13 for ; Mon, 07 May 2012 00:47:38 -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=OUIOGieXEJvxU2nQR4iHtt7JW4959OdI9RW+OGzapFg=; b=G+K7A3O8GzE4FdRD/527jnoqc51wUj8iMe4qknSEpxT6XztataG8+ZyiCgcKpLxXml 3NneLzG4rAVI5BT8m5dcbPcUFGw3X0vZYGFdTSzQp66m4kKgXHA2Zv70QSqrU9uoQhWU Xw29lggiZo4Y64NjDRbNYqCapPWKreQfydIMdOnEScJUJ+2OgCOfODGa1zVtFhvRp4oR DJV+A3/ATL/GUD4l/bgpA58xDY7kCUTO8YG5XQgM9x7JkRtfOjM5YJ4QGWxq2NDoBY36 tddaKHQjvwqv27aCcg0ShIusPybNTcajM1k609bAt4HN2OjZIxaIjeqE2/vhqGwprKxE Kdzg== MIME-Version: 1.0 Received: by 10.180.94.7 with SMTP id cy7mr11453362wib.3.1336376858620; Mon, 07 May 2012 00:47:38 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.180.146.74 with HTTP; Mon, 7 May 2012 00:47:38 -0700 (PDT) In-Reply-To: <4FA6A005.7010001@extendedsubset.com> References: <4FA401F7.5060003@extendedsubset.com> <4FA63814.8010405@gnutls.org> <4FA6A005.7010001@extendedsubset.com> Date: Mon, 7 May 2012 09:47:38 +0200 X-Google-Sender-Auth: nAvhPJqf0EhLMR9xmJAXMgeXqPU Message-ID: From: Nikos Mavrogiannopoulos To: Marsh Ray Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 07 May 2012 07:47:40 -0000 On Sun, May 6, 2012 at 6:00 PM, Marsh Ray wrote: >> * client_required, client_requested, Instead of those two fields, >> why not just sending a single list with all acceptable levels? > That could work too. There are just three levels including "zero". I > don't know how likely it is that there will ever be more. A list would > likely take as much or more space and as a variable length field it > would be slightly more complex to process securely. > My sense is that having two fields, requested and required, gives the > negotiation a little more flexibility, like hard and soft limits for a > resource quota system. By setting the required level higher than > requested, it also gives a neat way to query the server for what he can > support. There is a similar issue in TLS protocol negotiation, where the client only indicates his highest version. Now if an implementation indicates 1.2 it is not clear whether it supports 1.1, and to what version the server would fallback. Even with the three levels supported (zero, one, two), if a client advertises required zero, requested two, should the server assume that he supports one? What if the client only supports level two and zero? >> * conditional_extensions, I think this is complicated. Why not >> assume that the extensions present in the hello are valid? > The idea behind this is that there may be extensions which the client is > willing to send the CH extension in the clear when level one may be > negotiated, but strongly prefers that the server not send his SH > extension reply in the clear. I'd suggest that this should be extension specific. I.e. each extension should specify the behavior on each level. Otherwise it looks like each implementation would assume its own defaults and there will be no consistent privacy level for each extension. For the currently defined extensions that specify no default behaviors I think this document should define it. This would avoid both the complexity, and the implementation specific privacy-level (and a user would know that in level two the extensions XYZ and ZZY are protected while XXY isn't etc). > I don't really know, others in [TLS] would have a better sense > of this than I do. > > I thought it might be beneficial to define it without regard to any > specific cipher suites so new cipher suites could be defined in the > future without needing to update the EH. Future ciphersuites should mention how they should be used with EH. The ones defined past this point cannot do that, and this document should make things clear, or everything should be left on implementors (e.g. I can think a way SRP can be used with this draft, but someone on another implementation may have a different idea). regards, Nikos From marsh@extendedsubset.com Mon May 7 11:34:04 2012 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 54D6D21F86B1 for ; Mon, 7 May 2012 11:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 EQlFXtQQzbeq for ; Mon, 7 May 2012 11:34:03 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id 304FB21F86B0 for ; Mon, 7 May 2012 11:34:00 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SRSkx-000CCc-Jg; Mon, 07 May 2012 18:33:59 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 7FDE567A4; Mon, 7 May 2012 18:33:58 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19b77Py896MrUW1GHhhMfoLttPqy+Eh0nM= Message-ID: <4FA81592.9000205@extendedsubset.com> Date: Mon, 07 May 2012 13:33:54 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Peter Sylvester References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> <4FA55298.9010203@pobox.com> <65A74BBD-AA6D-447C-898D-8CB8C5966943@vpnc.org> <4FA55DAE.8020909@pobox.com> <508C47AD-7999-46EB-832A-4D66AAC87118@vpnc.org> <006FEB08D9C6444AB014105C9AEB133F017A7C056C48@il-ex01.ad.checkpoint.com> <4FA776CF.1080700@edelweb.fr> In-Reply-To: <4FA776CF.1080700@edelweb.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 07 May 2012 18:34:04 -0000 On 05/07/2012 02:16 AM, Peter Sylvester wrote: > Hi, > > which currently defined extensions are worth to be "protected". > the draft says: > > Before the Server Name > Indication (SNI) extension [RFC 6066], it was not possible to serve > multiple HTTPS sites from a single IP address, so the specific site > to which the user was connecting was effectively already known. The EH extension provides a defined method by which a client and server MAY transfer certain handshake data under encryption. EH level one does not encrypt Client Hello extensions, EH level two will probably be able to encrypt all but a few. SNI is tricky since in theory a server could use it to route to different vhosts, each with different allowed cipher suites. I don't know how likely such a setup will be in reality. If SNI needs to be sent under encryption to such a site, here are some ideas: * Servers requiring SNI may support EH level two, but they still require the SNI to be sent on the first ClientHello. * Servers requiring SNI don't allow arbitrary per-vhost configuration of the ciphersuites. * Servers requiring SNI with a client requiring EH level two begin the handshake using the settings of the default vhost. After the SNI arrives on ClientHello2, if the negotiated cipher suite is supported by the target vhost then the handshake completes as a normal EH level two. If the negotiated cipher suite is not supported by the target vhost, an anon-anon DH handshake is completed and the server initiates a renegotiation with the target vhost's allowed cipher suites. * The server selects the ciphersuite from the union of all the sets of ciphersuites of all the vhosts. A problem with this least-common-denominator approach is it effectively allows one one vhost to downgrade the ciphersuites of all the others. > Does that mean that the authors considers the servername as > information that should be protected? My personal opinion is that SNI looks like it may contain interesting information and it would be beneficial for EH to be able to provide encryption for clients that wanted it. It's just a matter of consistentizing the configuration, this should be a solvable problem. I suspect in practice, today, eavesdroppers near the client who are in position to see the SNI are also in position to see the client's DNS query. Eavesdroppers near the server will get a pretty good idea of the list of sites hosted from the non-EH level two clients. If the hostnames and certs presented by different vhosts are of different lengths then the TLS handshake record sizes may distinguish them. > what happens when IPV6 > comes in? Is it unlikely to have one IPV6 adress per server? I don't know. I think many folks have given up trying to predict when IPv6 will show up on the server side. > If the SNI is not send in the initial clienthello, what is a client > supposed to do when the serverhello does not indicate > support for the new method? Like support for any other optional feature, the client has a decision to make. We may never get to a point where client can require EH level two on first contact with a random server. But for those do who want to handshake that way, we can give them a well defined way to do it. >> If no EH extension is present, the negotiated EH level is zero >> server continues the TLS connection as usual. The remainder >> of this section does not apply. Looks like I have a missing fragment here. I'll probably do an editing pass soon since the -00 text is pretty rough in some places. > how does the client "continue" as usual since it has not send all > desired extensions? The client and server each decide based on their configuration how the lack of certain extensions affects the completion of the handshake and what happens at the application layer afterwards, just like they do now. It's pretty rare for handshakes between well maintained devices to fail for such a reason. Nevertheless, web browsers tend to have fallback logic to handle it. Story: I read in an SSL survey that something like 99.99% of servers support TLS 1.0. So I unchecked the "Allow SSL 3.0" box in Firefox. Well, a few days later I came across a server without support for TLS. It was my little home Wifi router configuration interface. - Marsh From marsh@extendedsubset.com Mon May 7 11:50:21 2012 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 2D20C21F8534 for ; Mon, 7 May 2012 11:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 nismX5PQoF83 for ; Mon, 7 May 2012 11:50:20 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id A348B21F84E6 for ; Mon, 7 May 2012 11:50:20 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SRT0m-000Kib-9O; Mon, 07 May 2012 18:50:20 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id E963260A1; Mon, 7 May 2012 18:50:18 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+bzhfFMB4D0e/+iZMny7Ds3oBxAd0XVeI= Message-ID: <4FA81966.8060604@extendedsubset.com> Date: Mon, 07 May 2012 13:50:14 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: <4FA401F7.5060003@extendedsubset.com> <4FA63814.8010405@gnutls.org> <4FA6A005.7010001@extendedsubset.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 07 May 2012 18:50:21 -0000 On 05/07/2012 02:47 AM, Nikos Mavrogiannopoulos wrote: > > Even with the three levels supported (zero, > one, two), if a client advertises required zero, requested two, should > the server assume that he supports one? What if the client only > supports level two and zero? I think that EH level one is such a clear subset of level two that it doesn't make sense to implement level two but not level one. Would we ever define more levels such that implementation support for them could sensibly be non-contiguous? It doesn't seem too likely to me, but should the need arise we'd probably have a new extension ID anyway. > I'd suggest that this should be extension specific. I.e. each > extension should specify the behavior on each level. Otherwise it > looks like each implementation would assume its own defaults and there > will be no consistent privacy level for each extension. For the > currently defined extensions that specify no default behaviors I think > this document should define it. This would avoid both the complexity, > and the implementation specific privacy-level (and a user would know > that in level two the extensions XYZ and ZZY are protected while XXY > isn't etc). > > Future ciphersuites should mention how they should be used with EH. > The ones defined past this point cannot do that, and this document > should make things clear, or everything should be left on implementors > (e.g. I can think a way SRP can be used with this draft, but someone > on another implementation may have a different idea). Agree. I'd be happy to add those sections to the ID, but I will need to rely on the subject matter experts here in the WG for many of the specifics. - Marsh From peter.sylvester@edelweb.fr Tue May 8 01:04:21 2012 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 D761C21F8606 for ; Tue, 8 May 2012 01:04:21 -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 db58xBZb5iPu for ; Tue, 8 May 2012 01:04:21 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id AE3F421F862B for ; Tue, 8 May 2012 01:04:20 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id A76007DBA; Tue, 8 May 2012 10:04:10 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 49F0978D607; Tue, 8 May 2012 09:56:48 +0200 (CEST) Received: from [192.168.0.28] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTPSA id 17BCC23664C; Tue, 8 May 2012 03:57:51 -0400 (EDT) Message-ID: <4FA8D37A.7020200@edelweb.fr> Date: Tue, 08 May 2012 10:04:10 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Marsh Ray References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> <4FA55298.9010203@pobox.com> <65A74BBD-AA6D-447C-898D-8CB8C5966943@vpnc.org> <4FA55DAE.8020909@pobox.com> <508C47AD-7999-46EB-832A-4D66AAC87118@vpnc.org> <006FEB08D9C6444AB014105C9AEB133F017A7C056C48@il-ex01.ad.checkpoint.com> <4FA776CF.1080700@edelweb.fr> <4FA81592.9000205@extendedsubset.com> In-Reply-To: <4FA81592.9000205@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 08 May 2012 08:04:22 -0000 On 05/07/2012 08:33 PM, Marsh Ray wrote: > On 05/07/2012 02:16 AM, Peter Sylvester wrote: >> Hi, >> >> which currently defined extensions are worth to be "protected". >> the draft says: >> >> Before the Server Name >> Indication (SNI) extension [RFC 6066], it was not possible to serve >> multiple HTTPS sites from a single IP address, so the specific site >> to which the user was connecting was effectively already known. > > The EH extension provides a defined method by which a client and server MAY transfer certain > handshake data under encryption. EH level one does not encrypt Client Hello extensions, EH level > two will probably be able to encrypt all but a few. > > SNI is tricky since in theory a server could use it to route to different vhosts, each with > different allowed cipher suites. I don't know how likely such a setup will be in reality. > > If SNI needs to be sent under encryption to such a site, here are some ideas: > > * Servers requiring SNI may support EH level two, but they still require the SNI to be sent on the > first ClientHello. > > * Servers requiring SNI don't allow arbitrary per-vhost configuration of the ciphersuites. > > * Servers requiring SNI with a client requiring EH level two begin the handshake using the > settings of the default vhost. After the SNI arrives on ClientHello2, if the negotiated cipher > suite is supported by the target vhost then the handshake completes as a normal EH level two. If > the negotiated cipher suite is not supported by the target vhost, an anon-anon DH handshake is > completed and the server initiates a renegotiation with the target vhost's allowed cipher suites. > > * The server selects the ciphersuite from the union of all the sets of ciphersuites of all the > vhosts. A problem with this least-common-denominator approach is it effectively allows one one > vhost to downgrade the ciphersuites of all the others. > >> Does that mean that the authors considers the servername as >> information that should be protected? > > My personal opinion is that SNI looks like it may contain interesting information and it would be > beneficial for EH to be able to provide encryption for clients that wanted it. It's just a matter > of consistentizing the configuration, this should be a solvable problem. > > I suspect in practice, today, eavesdroppers near the client who are in position to see the SNI are > also in position to see the client's DNS query. Eavesdroppers near the server will get a pretty > good idea of the list of sites hosted from the non-EH level two clients. If the hostnames and > certs presented by different vhosts are of different lengths then the TLS handshake record sizes > may distinguish them. > >> what happens when IPV6 >> comes in? Is it unlikely to have one IPV6 adress per server? > > I don't know. I think many folks have given up trying to predict when IPv6 will show up on the > server side. ok, I was assuming the sentence about SNI on page 3 be an indication about SNI being something worth to be protected. with ipv6 you most likely have one address per hostname again. > >> If the SNI is not send in the initial clienthello, what is a client >> supposed to do when the serverhello does not indicate >> support for the new method? > > Like support for any other optional feature, the client has a decision to make. We may never get > to a point where client can require EH level two on first contact with a random server. > > But for those do who want to handshake that way, we can give them a well defined way to do it. so this would most likely require some management at the client level to select the feature. > > >>> If no EH extension is present, the negotiated EH level is zero >>> server continues the TLS connection as usual. The remainder >>> of this section does not apply. > > Looks like I have a missing fragment here. I'll probably do an editing pass soon since the -00 > text is pretty rough in some places. if there is nothing for the second client hello, the client can continue. if the client wanted level 2, you need to abandon and restart with a new clienthello srp has a similar situation when srp suite are proposed without a client name. > >> how does the client "continue" as usual since it has not send all >> desired extensions? > > The client and server each decide based on their configuration how the lack of certain extensions > affects the completion of the handshake and what happens at the application layer afterwards, just > like they do now. > > It's pretty rare for handshakes between well maintained devices to fail for such a reason. > Nevertheless, web browsers tend to have fallback logic to handle it. ... > > Story: I read in an SSL survey that something like 99.99% of servers support TLS 1.0. So I > unchecked the "Allow SSL 3.0" box in Firefox. Well, a few days later I came across a server > without support for TLS. It was my little home Wifi router configuration interface. > nice. > - Marsh From ynir@checkpoint.com Tue May 8 02:15:51 2012 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 8A69E21F857F for ; Tue, 8 May 2012 02:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.395 X-Spam-Level: X-Spam-Status: No, score=-10.395 tagged_above=-999 required=5 tests=[AWL=0.204, 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 0evqUJO5ZhDT for ; Tue, 8 May 2012 02:15:50 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2F121F84E6 for ; Tue, 8 May 2012 02:15:50 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q489FiPd008647; Tue, 8 May 2012 12:15:45 +0300 X-CheckPoint: {4FA8F1CA-5-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 8 May 2012 12:15:43 +0300 From: Yoav Nir To: Peter Sylvester Date: Tue, 8 May 2012 12:15:43 +0300 Thread-Topic: [TLS] draft-ray-tls-encrypted-handshake-00.txt Thread-Index: Ac0s+yRz2rpcKhwFRxqYj4+MxIFuLg== Message-ID: <10F32AF2-4C01-4679-B6A5-182A9B3E5031@checkpoint.com> References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> <4FA55298.9010203@pobox.com> <65A74BBD-AA6D-447C-898D-8CB8C5966943@vpnc.org> <4FA55DAE.8020909@pobox.com> <508C47AD-7999-46EB-832A-4D66AAC87118@vpnc.org> <006FEB08D9C6444AB014105C9AEB133F017A7C056C48@il-ex01.ad.checkpoint.com> <4FA776CF.1080700@edelweb.fr> <4FA81592.9000205@extendedsubset.com> <4FA8D37A.7020200@edelweb.fr> In-Reply-To: <4FA8D37A.7020200@edelweb.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 08 May 2012 09:15:51 -0000 On May 8, 2012, at 11:04 AM, Peter Sylvester wrote: >>> what happens when IPV6 >>> comes in? Is it unlikely to have one IPV6 adress per server? >>=20 >> I don't know. I think many folks have given up trying to predict when IP= v6 will show up on the=20 >> server side. > ok, I was assuming the sentence about SNI on page 3 be an indication abou= t SNI being > something worth to be protected. with ipv6 you most likely have one addre= ss per hostname > again. I highly doubt that. The reason for colocating web servers is to lower the = administrative cost, not because of the scarcity of IPv4 addresses. Giving = a single interface multiple IP addresses and tying each to a service makes = for a higher administrative cost, and the mechanisms for multiple services,= both in HTTP and in TLS are already there. I think it would be much simple= r to keep things the way they are. Yoav= From marsh@extendedsubset.com Tue May 8 08:23:34 2012 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 58D1911E8080 for ; Tue, 8 May 2012 08:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 lP8ocNzhEwU0 for ; Tue, 8 May 2012 08:23:28 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id AFA2F21F855F for ; Tue, 8 May 2012 08:23:28 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SRmG7-0006pt-OU; Tue, 08 May 2012 15:23:27 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 287FF6081; Tue, 8 May 2012 15:23:26 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+QHIj8KfjvgWTRfZkHVqolhlUSiLcB1+I= Message-ID: <4FA93A6D.9000203@extendedsubset.com> Date: Tue, 08 May 2012 10:23:25 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Yoav Nir References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> <4FA55298.9010203@pobox.com> <65A74BBD-AA6D-447C-898D-8CB8C5966943@vpnc.org> <4FA55DAE.8020909@pobox.com> <508C47AD-7999-46EB-832A-4D66AAC87118@vpnc.org> <006FEB08D9C6444AB014105C9AEB133F017A7C056C48@il-ex01.ad.checkpoint.com> <4FA776CF.1080700@edelweb.fr> <4FA81592.9000205@extendedsubset.com> <4FA8D37A.7020200@edelweb.fr> <10F32AF2-4C01-4679-B6A5-182A9B3E5031@checkpoint.com> In-Reply-To: <10F32AF2-4C01-4679-B6A5-182A9B3E5031@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 08 May 2012 15:23:35 -0000 On 05/08/2012 04:15 AM, Yoav Nir wrote: > > On May 8, 2012, at 11:04 AM, Peter Sylvester wrote: >> >> ok, I was assuming the sentence about SNI on page 3 be an >> indication about SNI being something worth to be protected. with >> ipv6 you most likely have one address per hostname again. > > I highly doubt that. The reason for colocating web servers is to > lower the administrative cost, Or to share the costs of high-bandwith connectivity with the rest of the datacenter. > not because of the scarcity of IPv4 addresses. We have a weird situation today where the scarcity of IPv4 addresses has provided a source of revenue for some lucky ISPs. So they are disincentivized to promote IPv6. Even still, a server can't abandon IPv4 until all its clients can talk to it over IPv6. I think it will be a long time before that happens for most public servers. > Giving a single interface multiple IP addresses and tying > each to a service makes for a higher administrative cost, and the > mechanisms for multiple services, both in HTTP and in TLS are already > there. I think it would be much simpler to keep things the way they > are. I agree that EH should not attempt to change SNI. Even if we had an infinite address space, SNI with EH level two could, under the right circumstances, offer some advantage of encrypting even the name of the server being connected to. Ideally you'd have a large number of unrelated sites served via the same set of SSL terminators, e.g., Akamai. - Marsh From Jeff.Hodges@KingsMountain.com Tue May 8 12:05:32 2012 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 55EAB21F85A8 for ; Tue, 8 May 2012 12:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.414 X-Spam-Level: X-Spam-Status: No, score=-99.414 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 odtxizFxnpdo for ; Tue, 8 May 2012 12:05:31 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 8BAEA21F85CE for ; Tue, 8 May 2012 12:05:27 -0700 (PDT) Received: (qmail 797 invoked by uid 0); 8 May 2012 19:05:26 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 8 May 2012 19:05:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=rZI3a5dyfYp0m90GE+P0G1oRBM9lFnjNr6yiqqfCKtw=; b=A74Eh+yDYX8Y651zWMZ88dz7xlMX7gRh4bEeiJoP7weTrCZVRnJL+NZJDKXh69pQsQiPHS973mhibFQeNaJUYIJf7z0g75RhEMOsgoA5n4jjAGSuQbYIDIbVnKWiBP2p; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.90]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SRpiw-0002pu-Gl for tls@ietf.org; Tue, 08 May 2012 13:05:26 -0600 Message-ID: <4FA96E75.60408@KingsMountain.com> Date: Tue, 08 May 2012 12:05:25 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: IETF TLS WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [TLS] WGLC for draft-ietf-tls-oob-pubkey-03.txt 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, 08 May 2012 19:05:32 -0000 I have a comment on -tls-oob-pubkey-03 itself, and then a followup to the client certificate comments... ### 3.1. Client Hello . . The [RFC6091] defined CertificateTypeExtension is extended as follows: enum { client, server } ClientOrServerExtension; enum { X.509(0), OpenPGP(1), RawPublicKey([TBD]), (255) } CertificateType; struct { select(ClientOrServerExtension) case client: CertificateType certificate_types<1..2^8-1>; case server: CertificateType certificate_type; } } CertificateTypeExtension; . . What the difference is between the above and RFC6091 is not immediately apparent (it's only the addition of RawPublicKey([TBD]) to the CertificateType enum). This difference should be noted explicitly in the prose and perhaps -tls-oob-pubkey should only show the CertificateType enum definition, unless ClientOrServerExtension and CertificateTypeExtension are better delineated as unchanged and presented for exposition only (or if some form of merge with RFC6091 is done as mentioned by Martin Rex). ### Martin Rex replied: > >>> Paul Hoffman suggested including this modified version of S 3.5 from >>> RFC6091 >>> >>>> 3.5. Client Certificate >>>> >>>> This message is only sent in response to the certificate request >>>> message. The client certificate message is sent using the same >>>> formatting as the server certificate message, and it is also required >>>> to present a certificate that matches the negotiated certificate >>>> type. If RawPublicKey certificates have been selected and no certificate >>>> is available from the client, then a certificate structure of type >>>> "empty_cert" that contains an RawPublicKey value MUST be sent. >>>> The server SHOULD respond with a "handshake_failure" fatal alert if >>>> client authentication is required. > > > What is confusing in your description is [this phrase:] > > "empty_cert" that contains a RawPublicKey value > > I believe [we] need another codepoint in the rfc6091 enumerator > OpenPGPCertDescriptorType: > > enum { > empty_cert(1), > subkey_cert(2), > subkey_cert_fingerprint(3), > + x509_spki(4), > (255) > } OpenPGPCertDescriptorType; > > because "empty_cert" is not meant to be extensible in rfc6091: > > uint24 OpenPGPEmptyCert = 0; > > struct { > OpenPGPCertDescriptorType descriptorType; > select (descriptorType) { > case empty_cert: OpenPGPEmptyCert; > case subkey_cert: OpenPGPSubKeyCert; > case subkey_cert_fingerprint: > OpenPGPSubKeyCertFingerprint; > } > } Certificate; Actually, in looking at S 3.3 of RFC6091, it appears that other than the first paragraph, that section (in RFC6091) is specific to the OpenPGP certificate type. Shouldn't -tls-oob-pubkey more properly define it's own equivalent structures rather than attempt to re-use the apparently OpenPGP-specific ones there in S 3.3 of RFC6091 (if PaulH's suggestion is adopted)? fwiw, I agree with PaulH's comments (and with Simon Josefsson's also). ### HTH, =JeffH From ynir@checkpoint.com Tue May 8 13:22:01 2012 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 E312621F8463 for ; Tue, 8 May 2012 13:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.402 X-Spam-Level: X-Spam-Status: No, score=-10.402 tagged_above=-999 required=5 tests=[AWL=0.197, 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 MD4bl0REWCtf for ; Tue, 8 May 2012 13:22:01 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 00EC621F8460 for ; Tue, 8 May 2012 13:22:00 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q48KLi6L031163; Tue, 8 May 2012 23:21:47 +0300 X-CheckPoint: {4FA98DDB-4-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 8 May 2012 23:21:42 +0300 From: Yoav Nir To: Marsh Ray Date: Tue, 8 May 2012 23:21:42 +0300 Thread-Topic: [TLS] draft-ray-tls-encrypted-handshake-00.txt Thread-Index: Ac0tWC52FlsipaNBRwGmeGDm6QbI0g== Message-ID: References: <4FA401F7.5060003@extendedsubset.com> <4FA424A3.2010409@pobox.com> <4FA4264A.7070406@extendedsubset.com> <4FA4AE62.20506@pobox.com> <4FA55298.9010203@pobox.com> <65A74BBD-AA6D-447C-898D-8CB8C5966943@vpnc.org> <4FA55DAE.8020909@pobox.com> <508C47AD-7999-46EB-832A-4D66AAC87118@vpnc.org> <006FEB08D9C6444AB014105C9AEB133F017A7C056C48@il-ex01.ad.checkpoint.com> <4FA776CF.1080700@edelweb.fr> <4FA81592.9000205@extendedsubset.com> <4FA8D37A.7020200@edelweb.fr> <10F32AF2-4C01-4679-B6A5-182A9B3E5031@checkpoint.com> <4FA93A6D.9000203@extendedsubset.com> In-Reply-To: <4FA93A6D.9000203@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 08 May 2012 20:22:02 -0000 On May 8, 2012, at 6:23 PM, Marsh Ray wrote: > We have a weird situation today where the scarcity of IPv4 addresses has= =20 > provided a source of revenue for some lucky ISPs. So they are=20 > disincentivized to promote IPv6. Even still, a server can't abandon IPv4= =20 > until all its clients can talk to it over IPv6. I think it will be a=20 > long time before that happens for most public servers. Yes, the home user who uses web, email and some P2P software can go all IPv= 6 (or at least no external IPv4 address) much easier than content providers= . Google and www.ietf.org will have an IPv4 address long after the vast major= ity of consumers don't have it anymore.= From n.mavrogiannopoulos@gmail.com Tue May 8 13:57:43 2012 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 9C59D21F852B for ; Tue, 8 May 2012 13:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 O34MXlyQg3lH for ; Tue, 8 May 2012 13:57:43 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id CFB2D21F84FF for ; Tue, 8 May 2012 13:57:42 -0700 (PDT) Received: by eekd4 with SMTP id d4so869702eek.31 for ; Tue, 08 May 2012 13:57:42 -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:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=U63iMpK2sfWA6McHZJ9vXHc9DNcKDobo3CGMtJqmqgY=; b=X00aObczHT2aIlgwYmdU+D3mXULnhYCXSpb83EQ/I56m3eAGOz08XqcdkVSyJQpfTg 7UN4IjseC7p3QaCiSldctR9hL9CwC/+mfinUiNfATJQvtOBq5GblYym19BmnahP68PsH krUut9AcQjq4QuaaReNDlhbRd9haCREm0hgkj1cjehSgvtRN64H6ATtTElo6kToDkadp LHAcgokGKjinh7g3NKEo65rwOUyTIUx1SfEegcYAenU/+SmMMh/8MGmn4q2CmRnMH7s4 j/F0aJXJmADL9RroOqepidghsABoEiObZWzz3KdR3noJAc6/TRUWtNrbptcJNB06BLZX EjSQ== Received: by 10.213.14.15 with SMTP id e15mr112542eba.8.1336510661989; Tue, 08 May 2012 13:57:41 -0700 (PDT) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id y54sm2057203eef.10.2012.05.08.13.57.40 (version=SSLv3 cipher=OTHER); Tue, 08 May 2012 13:57:41 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4FA988BF.3060509@gnutls.org> Date: Tue, 08 May 2012 22:57:35 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: Marsh Ray References: <4FA401F7.5060003@extendedsubset.com> <4FA63814.8010405@gnutls.org> <4FA6A005.7010001@extendedsubset.com> <4FA81966.8060604@extendedsubset.com> In-Reply-To: <4FA81966.8060604@extendedsubset.com> X-Enigmail-Version: 1.4 OpenPGP: id=96865171 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 08 May 2012 20:57:43 -0000 On 05/07/2012 08:50 PM, Marsh Ray wrote: > On 05/07/2012 02:47 AM, Nikos Mavrogiannopoulos wrote: >> >> Even with the three levels supported (zero, >> one, two), if a client advertises required zero, requested two, should >> the server assume that he supports one? What if the client only >> supports level two and zero? > I think that EH level one is such a clear subset of level two that it > doesn't make sense to implement level two but not level one. In that case, it should be clearly forbidden by this draft not to implement one if two is implemented, and pretty much mention that only the options 0, 1, 2 will ever be available. Otherwise if 10 years from now sbd adds 3 which is independent of 1,2 it may make sense to support 3 but not 2. I'd prefer however if the draft is flexible to allow future updates. > Would we ever define more levels such that implementation support for > them could sensibly be non-contiguous? It doesn't seem too likely to me, > but should the need arise we'd probably have a new extension ID anyway. I don't know. The future is hard to predict, so it may be better to be safe than sorry :) regards, Nikos From paul.hoffman@vpnc.org Tue May 8 14:13:21 2012 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 C0E2F21F85B1 for ; Tue, 8 May 2012 14:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, 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 0Frij1VoVhJa for ; Tue, 8 May 2012 14:13:20 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7B75021F85AF for ; Tue, 8 May 2012 14:13:20 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q48LDEXa092419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 May 2012 14:13:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 8 May 2012 14:13:14 -0700 Message-Id: <02928776-0AB5-416F-8BA5-F5BA1BCFEEC6@vpnc.org> To: Eric Rescorla , Joe Salowey Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: tls@ietf.org Subject: [TLS] draft-ietf-tls-oob-pubkey and updating RFC 6091: a proposed solution 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, 08 May 2012 21:13:21 -0000 Greetings again. A few of us commenting on draft-ietf-tls-oob-pubkey = have had an issue that this draft is meant to be on standards track, but = it is updating (and relying on parts of) RFC 6091. We have suggested = some ways of changing draft-ietf-tls-oob-pubkey to maybe make this work, = hoping that this is OK. A much simpler method would simply be to move RFC 6091 to standards = track. This can be done without a new Internet Draft version of RFC = 6019, and even without a full WG Last Call. The WG chairs (that's the = two folks on the To: line) can simply ask the AD (that's the person on = the Cc:) to make this happen. This is fully allowed by the IETF = procedures (see RFC 2026, section 6.1.1), and the most process-obsessed = member of the IESG has told me that this would be just fine. WG chairs: please consider asking the AD to do this. It would make = draft-ietf-tls-oob-pubkey much cleaner, and would really harm no one. --Paul Hoffman From paul@nohats.ca Tue May 8 22:16:53 2012 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 88B2121F85B5 for ; Tue, 8 May 2012 22:16:53 -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 H786twrUkIkT for ; Tue, 8 May 2012 22:16:52 -0700 (PDT) Received: from letoams.cypherpunks.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFCA21F85B4 for ; Tue, 8 May 2012 22:16:52 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 782FF853FC; Wed, 9 May 2012 01:16:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 6A459853FB; Wed, 9 May 2012 01:16:47 -0400 (EDT) Date: Wed, 9 May 2012 01:16:47 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: <02928776-0AB5-416F-8BA5-F5BA1BCFEEC6@vpnc.org> Message-ID: References: <02928776-0AB5-416F-8BA5-F5BA1BCFEEC6@vpnc.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-oob-pubkey and updating RFC 6091: a proposed solution 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, 09 May 2012 05:16:53 -0000 On Tue, 8 May 2012, Paul Hoffman wrote: > A much simpler method would simply be to move RFC 6091 to standards track. This can be done without a new Internet Draft version of RFC 6019, and even without a full WG Last Call. The WG chairs (that's the two folks on the To: line) can simply ask the AD (that's the person on the Cc:) to make this happen. This is fully allowed by the IETF procedures (see RFC 2026, section 6.1.1), and the most process-obsessed member of the IESG has told me that this would be just fine. > > WG chairs: please consider asking the AD to do this. It would make draft-ietf-tls-oob-pubkey much cleaner, and would really harm no one. That would indeed be nice. I'll wait with a draft update until we hear back regarding this. Thanks Paul, Paul From internet-drafts@ietf.org Wed May 9 08:35:14 2012 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 2896921F8532; Wed, 9 May 2012 08:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, 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 vHEwaLS+tHj9; Wed, 9 May 2012 08:35:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59B421F8522; Wed, 9 May 2012 08:35:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120509153513.11861.32080.idtracker@ietfa.amsl.com> Date: Wed, 09 May 2012 08:35:13 -0700 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-multiple-cert-status-extension-00.txt 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, 09 May 2012 15:35:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Grou= p of the IETF. Title : The TLS Multiple Certificate Status Request Extension Author(s) : Yngve N. Pettersen Filename : draft-ietf-tls-multiple-cert-status-extension-00.txt Pages : 9 Date : 2012-05-09 This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support multiple certificate status methods. Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information not just about the server's own certificate, but also the status of intermediate certificates in the chain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-multiple-cert-status-ext= ension-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-multiple-cert-status-exte= nsion-00.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extens= ion/ From mrex@sap.com Thu May 10 15:23:57 2012 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 5196221F85C3 for ; Thu, 10 May 2012 15:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.786 X-Spam-Level: X-Spam-Status: No, score=-9.786 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, 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 cAefg7q-wOSb for ; Thu, 10 May 2012 15:23:56 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7A17621F85C0 for ; Thu, 10 May 2012 15:23:56 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q4AMNiRC029024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 May 2012 00:23:44 +0200 (MEST) From: Martin Rex Message-Id: <201205102223.q4AMNiIL015866@fs4113.wdf.sap.corp> To: ynir@checkpoint.com (Yoav Nir) Date: Fri, 11 May 2012 00:23:44 +0200 (MEST) In-Reply-To: from "Yoav Nir" at May 8, 12 11:21:42 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 10 May 2012 22:23:57 -0000 Yoav Nir wrote: > > Marsh Ray wrote: > > > > We have a weird situation today where the scarcity of IPv4 addresses has > > provided a source of revenue for some lucky ISPs. So they are > > disincentivized to promote IPv6. Even still, a server can't abandon IPv4 > > until all its clients can talk to it over IPv6. I think it will be a > > long time before that happens for most public servers. > > Yes, the home user who uses web, email and some P2P software can go > all IPv6 (or at least no external IPv4 address) much easier than > content providers. Except that lots of home equipment does not support IPv6 at all (the majority of the installed base of home DSL&WLAN routers, Nintendo WII, Nintendo DS, My 2-year-old Sony LED 40" Flatscreen, my WD HomeNAS, my DVB-s receiver ...) to name a few. And with IPv6 one would loose the added privacy protection of dynamic IPv4 addresses. At the same time, getting IPv6 provides ZERO benefit. http://www.theregister.co.uk/2012/05/08/ipv6_coming_next_month/ -Martin From stpeter@stpeter.im Thu May 10 15:27:18 2012 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 EA0FF21F852E for ; Thu, 10 May 2012 15:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, 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 4lCAdUXgDtRU for ; Thu, 10 May 2012 15:27:18 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 73DDC21F852B for ; Thu, 10 May 2012 15:27:18 -0700 (PDT) Received: from [192.168.0.9] (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A71E440058; Thu, 10 May 2012 16:42:42 -0600 (MDT) Message-ID: <4FAC40C6.308@stpeter.im> Date: Thu, 10 May 2012 16:27:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: mrex@sap.com References: <201205102223.q4AMNiIL015866@fs4113.wdf.sap.corp> In-Reply-To: <201205102223.q4AMNiIL015866@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 10 May 2012 22:27:19 -0000 On 5/10/12 4:23 PM, Martin Rex wrote: > Except that lots of home equipment does not support IPv6 at all So? We could say the same (or worse) about TLS 1.1/1.2 :P From peter.sylvester@edelweb.fr Thu May 10 23:29:47 2012 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 9E7EA21F8629 for ; Thu, 10 May 2012 23:29:47 -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 TtD9CfZMlz80 for ; Thu, 10 May 2012 23:29:47 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1893421F8621 for ; Thu, 10 May 2012 23:29:47 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id B03847DB3 for ; Fri, 11 May 2012 08:29:45 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 3A7647DAE01 for ; Fri, 11 May 2012 08:21:44 +0200 (CEST) Received: from [192.168.0.27] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTPSA id 1C87A236373 for ; Fri, 11 May 2012 02:23:12 -0400 (EDT) Message-ID: <4FACB1D8.5020308@edelweb.fr> Date: Fri, 11 May 2012 08:29:44 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: tls@ietf.org References: <201205102223.q4AMNiIL015866@fs4113.wdf.sap.corp> <4FAC40C6.308@stpeter.im> In-Reply-To: <4FAC40C6.308@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 11 May 2012 06:29:47 -0000 On 05/11/2012 12:27 AM, Peter Saint-Andre wrote: > On 5/10/12 4:23 PM, Martin Rex wrote: > >> Except that lots of home equipment does not support IPv6 at all > > So? We could say the same (or worse) about TLS 1.1/1.2 :P > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls I mentioned ipv6 yo ask whether SNI would benefit from being used in an encrypted client hello in level 2 or not. From n.mavrogiannopoulos@gmail.com Wed May 16 04:56:22 2012 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 6942C21F8700 for ; Wed, 16 May 2012 04:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 YhRwnmi1MQJl for ; Wed, 16 May 2012 04:56:22 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id B766F21F86FD for ; Wed, 16 May 2012 04:56:21 -0700 (PDT) Received: by wibhj8 with SMTP id hj8so3280026wib.13 for ; Wed, 16 May 2012 04:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=tMSAurIeOGJFv84FHdNm4BNbO9o7eQ/CpM+Z75SIc7U=; b=v933eUEvdJJErrBwJzZWQ962GLJ2zKLkbxoF+K+z0/31euCJ+7M6oO1cPb14eY+fh9 h1ZsEN40FIk3SHcsNN56AxiVp6OkciM7QIfgW1pmyvjRqLkkMUBmAO3iamgAEzbNbDkk HllJ74h2Uitv1Dgoa1l7Z16Ey2x23EEIFOwt2BTwbhsxhgJq0G+Y8tetEjXLbG1dq3Pu OqoEtLCcPd2EckH0UewHUIDf+e0PBIaF8qf2bq27zxE/OnvmIQ2raJjjo7juIzkqWti5 kwSzdplAtCgygWIomrlPYlwYR4JScOjiA0vZPzu85GpdxC1yZDolCRZZtpdhIFnwVaZb LRvA== MIME-Version: 1.0 Received: by 10.180.105.69 with SMTP id gk5mr41847486wib.3.1337169380888; Wed, 16 May 2012 04:56:20 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.180.103.228 with HTTP; Wed, 16 May 2012 04:56:20 -0700 (PDT) Date: Wed, 16 May 2012 13:56:20 +0200 X-Google-Sender-Auth: kl1Mx_15ECk_heD1UPpyGsqbiAY Message-ID: From: Nikos Mavrogiannopoulos To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [TLS] Preventing cross-protocol attacks in TLS protocol 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, 16 May 2012 11:56:22 -0000 Hello, I've submitted a proposal on how to prevent attacks similar in nature with the Wagner and Schneier's one, at: http://www.ietf.org/id/draft-mavrogiannopoulos-tls-server-key-exchage-00.txt Please consider adopting this or any other protection for the protocol. regards, Nikos From tom@ritter.vg Wed May 16 05:49:53 2012 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 31B4A21F853B for ; Wed, 16 May 2012 05:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.882 X-Spam-Level: X-Spam-Status: No, score=-2.882 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 HeXpXsEwF-wL for ; Wed, 16 May 2012 05:49:52 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 757C921F8533 for ; Wed, 16 May 2012 05:49:52 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so1237407obb.31 for ; Wed, 16 May 2012 05:49:52 -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 :content-type; bh=TiuzWqBn5iltbais9Xipu7Tvpdj3Ur0PHI0pTK6foQw=; b=x6PUzOChN4egf9Okip+hRKyVYWmUIZ5GnNVlGVFKi+Mj9uU/X7Hk0TM6VBhmBEX/KQ h3QVT03MemveUVGO08gdbvoWDfvn1i6dO637YwPPOLt3pBiNNRRoccbB8DSFkhl3QLF7 Jrmgljse6EcT5bsCg9vPiywTPFvxaPSm9eooY= 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 :content-type:x-gm-message-state; bh=TiuzWqBn5iltbais9Xipu7Tvpdj3Ur0PHI0pTK6foQw=; b=I/sVMws89aN2C034+iNJySkymCJLgZIFM175Da9SuMQY1SqdovoH00yaEJUte7AlXc 4tJ+rOCCIH7yDJqNdwsZK2V98UsUlr9Va9DxLQxq6br9XMOppdZJCxVy9xrAKVrCpT0E LPGMvYOsEUCE7UVzP1HXsdrK76BAhJb7VD4I04dp8R/SZmwWI9gopVmppwvc4WjF/BgC 8nJxSQg5iJx6a+6MlwgkdmQSJWvloXexg0+B8RXL31P6UniAk5h3qHNoVnCpNG4jLxb8 VpFfMADzV4iaB65r6TphIcy+OwwiGXsRyOvrsrHoNhv/1hBG52erMgIEw1B5HJOTQrq1 /wbQ== Received: by 10.182.167.104 with SMTP id zn8mr2582685obb.62.1337172591942; Wed, 16 May 2012 05:49:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.63.197 with HTTP; Wed, 16 May 2012 05:49:31 -0700 (PDT) In-Reply-To: <4FA401F7.5060003@extendedsubset.com> References: <4FA401F7.5060003@extendedsubset.com> From: Tom Ritter Date: Wed, 16 May 2012 08:49:31 -0400 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnxY3j2kODZFcU6Vnk3gLHc4as2lGOec15F5HQ9/zMikyqrez+gLGlllJvzb9+v/Api4Gdn Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 16 May 2012 12:49:53 -0000 This has quieted down a little bit after running around in different directions, but I wanted to bring back up the question of adopting it. By my informal count there were a few supports - I'd like to add to those and say I think this is worth adopting and developing. I think it's clear it'll require some careful accounting to track issues, but I'm willing to assist Marsh with that. -tom From marsh@extendedsubset.com Wed May 16 08:03:34 2012 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 579EC21F8528 for ; Wed, 16 May 2012 08:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 ESwx7qtLW2Hr for ; Wed, 16 May 2012 08:03:33 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id B4D2521F8546 for ; Wed, 16 May 2012 08:03:33 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SUfl9-000Nrl-Rz; Wed, 16 May 2012 15:03:27 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A32E561A9; Wed, 16 May 2012 15:03:26 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19Xg8xGaSBBAmV0ccefp2XBDDRnfiRU0tE= Message-ID: <4FB3C1BC.3030201@extendedsubset.com> Date: Wed, 16 May 2012 10:03:24 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Tom Ritter References: <4FA401F7.5060003@extendedsubset.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 16 May 2012 15:03:34 -0000 On 05/16/2012 07:49 AM, Tom Ritter wrote: > This has quieted down a little bit after running around in different > directions, but I wanted to bring back up the question of adopting it. > By my informal count there were a few supports - I'd like to add to > those and say I think this is worth adopting and developing. I think > it's clear it'll require some careful accounting to track issues, but > I'm willing to assist Marsh with that. Tom, thanks for your offer to coordinate that will be helpful. Update: I've been accumulating edits for a -01 that I expect will be out in a few days. If anyone else has things they'd like to see in the -01, this would be a good time to send them. Nikos has been helping develop the details on the various key exchange methods. Some of the non-RFC5246 key exchange methods look like they fit more elegantly than others. :-) A few points on which I'd love to take the temperature of the WG: 1. Having an unlimited variety of ways for the client to propose the (EC)DHE be conducted seems likely to unnecessarily increase the size of the Client Hello and make client fingerprinting easier. For classic DH, would it make sense to suggest using a more limited set of p and g parameters, like the standard groups used by IPsec and SSH? 2. This extension seems to be a natural fit for ECC in a few different ways. Would it make sense to standardize on ECC and/or a particular curve? 3. I have consistently resisted handshake changes that involve adding a second round of CCS absent renegotiation, mainly because it's unnecessary complexity in the primary use case of (EC)DHE. But some of the other key exchange methods can be done more efficiently than renegotiating if we allow another round of CCS in the usual place before the Finished messages of the first handshake. How much of a disruptive change is this really, or am I just feeling too conservative? Thanks, - Marsh From agl@google.com Wed May 16 08:35:54 2012 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 912E521F85FB for ; Wed, 16 May 2012 08:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.925 X-Spam-Level: X-Spam-Status: No, score=-102.925 tagged_above=-999 required=5 tests=[AWL=0.052, 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 kil9tNVxcqyp for ; Wed, 16 May 2012 08:35:54 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 08C6E21F85B9 for ; Wed, 16 May 2012 08:35:53 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so1450609obb.31 for ; Wed, 16 May 2012 08:35:53 -0700 (PDT) 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-system-of-record; bh=c0MS+E3FEIJIj1mCeGJKb8XGMM2crbeQrZlegyJc3uY=; b=SVax/jAfNw7u2vUbEZfeiOHPMlnA/QzxW7XPCif3Qe2NISq0PhRG2KJvClXsDWLbRW SuHG90ItQlPrh9+9araqZ4UeQHsRVWDOTIdsKz1URz4kyxFk605UyWigJ/rX6mWJFXOF gSCMe15nYvZEk7SWBoEI+FF5Poe27smFendyiCx4peZ/CL4ZnIRicN0U6FtQ2Pa5WwXS cOX6NkyqerUeYRCr4NSrCJLmVAjwOiav9XtFIYSXtpgQfSIQUTtBdfDFsfoRh473CW0R YCjIa/W3nVvN9bjxO7veIDgi/j+uAjCKRzOpTz70iioQKNtudb0npNnB+HlRLdRZJ9LE +SQg== 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-system-of-record :x-gm-message-state; bh=c0MS+E3FEIJIj1mCeGJKb8XGMM2crbeQrZlegyJc3uY=; b=OFK6TPablV4BHUWIba/H2bXrmIz+hRL8/JUeUTQZ2GsOOrLyrh9BXKzA4pdOR8APoG gUjmZRzBzlz9eTMj0I28wBiIbJodiCKTcltdbRs5vUVkofUZMb9a3BymL3NR1K4RN8kV 7skRwLdO+Ho3yjVcgfBU/l+LZ1nuUKCmY7uAHb1VYmCqb7lYDdbkwO7k+Nxck7sZjyLD MKS43sSiDpGdiXB8/n/jSfj6iBsdIi83+Y0eyYEGcHtiPX+PrmIQPd/PFzi5AEQTMg+Q bYgDkZYq+Yrv9WdZbuNcujlvPLoiKLYfKq5N8pifpkBLGHmqO0QPEgCF01kx3ztiAs0b +pcw== Received: by 10.182.197.69 with SMTP id is5mr3187294obc.32.1337182553560; Wed, 16 May 2012 08:35:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.197.69 with SMTP id is5mr3187284obc.32.1337182553404; Wed, 16 May 2012 08:35:53 -0700 (PDT) Received: by 10.182.220.102 with HTTP; Wed, 16 May 2012 08:35:52 -0700 (PDT) In-Reply-To: <4FB3C1BC.3030201@extendedsubset.com> References: <4FA401F7.5060003@extendedsubset.com> <4FB3C1BC.3030201@extendedsubset.com> Date: Wed, 16 May 2012 11:35:52 -0400 Message-ID: From: Adam Langley To: Marsh Ray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQkJI/87wFDlfkZtdxiPMZ5e27tu61s7JBzPxOx+ZQOBfR+bH60I0nVxzIssvu8Z2Yfpg1EXy4m2yaAMvM8dzWUxKrOYGy8GZiAKiOlS5cXF4950mj0M+pIhMoPeT9ScQBLUR037 Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 16 May 2012 15:35:54 -0000 On Wed, May 16, 2012 at 11:03 AM, Marsh Ray wrot= e: > 1. =C2=A0Having an unlimited variety of ways for the client to propose th= e > (EC)DHE be conducted seems likely to unnecessarily increase the size of t= he > Client Hello and make client fingerprinting easier. For classic DH, would= it > make sense to suggest using a more limited set of p and g parameters, lik= e > the standard groups used by IPsec and SSH? > > 2. This extension seems to be a natural fit for ECC in a few different wa= ys. > Would it make sense to standardize on ECC and/or a particular curve? I think having ids for some well known groups makes a lot of sense. Most TLS EDH in the world is done in a few, standard groups anyway. For ECC, I believe that P-256 is the best option. Because it's Suite B, it has wide implementation (as opposed to curves like P-224) and it's the fastest of the Suite B curves. I really don't like its prime structure as an implementer, but I believe it's other benefits outweigh that. > 3. I have consistently resisted handshake changes that involve adding a > second round of CCS absent renegotiation, mainly because it's unnecessary > complexity in the primary use case of (EC)DHE. But some of the other key > exchange methods can be done more efficiently than renegotiating if we al= low > another round of CCS in the usual place before the Finished messages of t= he > first handshake. How much of a disruptive change is this really, or am I > just feeling too conservative? I think that would be a fairly significant change. Which key exchanges benefit from more flows like that? Cheers AGL From paul.hoffman@vpnc.org Wed May 16 09:35:00 2012 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 AA3DC21F86AB for ; Wed, 16 May 2012 09:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, 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 epXXUfAs9EXN for ; Wed, 16 May 2012 09:35:00 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 041A321F8699 for ; Wed, 16 May 2012 09:34:59 -0700 (PDT) Received: from [10.20.30.102] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q4GGYuVc056523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 May 2012 09:34:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4FB3C1BC.3030201@extendedsubset.com> Date: Wed, 16 May 2012 09:34:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5D86282B-065E-4354-AA48-5E18C07F90CC@vpnc.org> References: <4FA401F7.5060003@extendedsubset.com> <4FB3C1BC.3030201@extendedsubset.com> To: Marsh Ray X-Mailer: Apple Mail (2.1278) Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 16 May 2012 16:35:00 -0000 On May 16, 2012, at 8:03 AM, Marsh Ray wrote: > 1. Having an unlimited variety of ways for the client to propose the = (EC)DHE be conducted seems likely to unnecessarily increase the size of = the Client Hello and make client fingerprinting easier. For classic DH, = would it make sense to suggest using a more limited set of p and g = parameters, like the standard groups used by IPsec and SSH? The Client Hello being a few bytes bigger is not worth considering. = Image the downside of having to create a new extension when a new ECDHE = is proposed, as it surely will be. As for client fingerprinting, a = client should probably only be offering one or two proposals. > 2. This extension seems to be a natural fit for ECC in a few different = ways. Would it make sense to standardize on ECC and/or a particular = curve? If you mean "should this spec have a mandatory to implement ECC = profile", that would be great. I agree with Adam: P256 seems like a = popular choice. > 3. I have consistently resisted handshake changes that involve adding = a second round of CCS absent renegotiation, mainly because it's = unnecessary complexity in the primary use case of (EC)DHE. But some of = the other key exchange methods can be done more efficiently than = renegotiating if we allow another round of CCS in the usual place before = the Finished messages of the first handshake. How much of a disruptive = change is this really, or am I just feeling too conservative? Other folks have pressed for this, so maybe have it in your next draft = with a bit of discussion about taking it out later when this is a WG = work item. --Paul Hoffman From n.mavrogiannopoulos@gmail.com Wed May 16 10:27:07 2012 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 26F5D21F870B for ; Wed, 16 May 2012 10:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 KhpYPS661C3K for ; Wed, 16 May 2012 10:27:06 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B23D21F8709 for ; Wed, 16 May 2012 10:27:05 -0700 (PDT) Received: by eaaq13 with SMTP id q13so311338eaa.31 for ; Wed, 16 May 2012 10:27:05 -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:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=UEIvlbpq8k8ty0/JRX3x8KePfHExciYbkpOMSfZ4QQM=; b=G3H5oGyCpkl6N0+T77c4vcbK4d9qFWd8pB79rC3BCjQbPWumesRUofrG3ghAoM9/qo WRv8nkI6LqS50jh6IK6nqVfgVIt6Bh/KZuT4djTZ9B8Oqpp4JdgM4MjyU7Ig40o6pbIn wfBBgEq004EhJ0TlM4sX+CQHCuvcD68vHRzcMHZZIIOalx6MRmqEnOBcu3f2RaNjORyV MyaPNynsYDCFNnP9KKOpGBGsvyozjCcmb0G66bczsRn3NKcuX3basX6I1nJOOGW5lpqf TNCFzalbnxJFqq2Jdf0ML6Hw0Gy9J2tdsVLvGB5eYwRIv9bI8w9oU0ksCT8mdUSVx3CM H6Og== Received: by 10.213.98.80 with SMTP id p16mr1685090ebn.2.1337189225232; Wed, 16 May 2012 10:27:05 -0700 (PDT) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id u7sm7721188eeb.7.2012.05.16.10.27.03 (version=SSLv3 cipher=OTHER); Wed, 16 May 2012 10:27:04 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4FB3E362.2030808@gnutls.org> Date: Wed, 16 May 2012 19:26:58 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: Adam Langley References: <4FA401F7.5060003@extendedsubset.com> <4FB3C1BC.3030201@extendedsubset.com> In-Reply-To: X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 16 May 2012 17:27:07 -0000 On 05/16/2012 05:35 PM, Adam Langley wrote: > On Wed, May 16, 2012 at 11:03 AM, Marsh Ray wrote: >> 1. Having an unlimited variety of ways for the client to propose the >> (EC)DHE be conducted seems likely to unnecessarily increase the size of the >> Client Hello and make client fingerprinting easier. For classic DH, would it >> make sense to suggest using a more limited set of p and g parameters, like >> the standard groups used by IPsec and SSH? >> 2. This extension seems to be a natural fit for ECC in a few different ways. >> Would it make sense to standardize on ECC and/or a particular curve? > I think having ids for some well known groups makes a lot of sense. > Most TLS EDH in the world is done in a few, standard groups anyway. Indeed. > For ECC, I believe that P-256 is the best option. Because it's Suite > B, it has wide implementation (as opposed to curves like P-224) and > it's the fastest of the Suite B curves. I really don't like its prime > structure as an implementer, but I believe it's other benefits > outweigh that. Having SECP-256 in a small list of curves is a good thing after the advantages you mention, but having it as a single curve would create a monoculture. That way in case of a catastrophic flaw, it would require a protocol change (as opposed to a configuration change) to avoid this curve. >> 3. I have consistently resisted handshake changes that involve adding a >> second round of CCS absent renegotiation, mainly because it's unnecessary >> complexity in the primary use case of (EC)DHE. But some of the other key >> exchange methods can be done more efficiently than renegotiating if we allow >> another round of CCS in the usual place before the Finished messages of the >> first handshake. How much of a disruptive change is this really, or am I >> just feeling too conservative? > I think that would be a fairly significant change. Which key exchanges > benefit from more flows like that? DHE-PSK and ECDHE-PSK. Unlike the "normal" DHE-RSA that sign the exchange parameters, those ciphersuites include the PSK into the negotiated premaster secret. That way the premaster secret needs to be updated after the PSK is known to both parties. (similary for SRP that performs a new key exchange after the initial DH) regards, Nikos From ekr@rtfm.com Wed May 16 10:55:33 2012 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 00C2721F8592 for ; Wed, 16 May 2012 10:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.889 X-Spam-Level: X-Spam-Status: No, score=-102.889 tagged_above=-999 required=5 tests=[AWL=0.088, 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 os2Dvarqhr9j for ; Wed, 16 May 2012 10:55:32 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DF08C21F854C for ; Wed, 16 May 2012 10:55:28 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1139937vbb.31 for ; Wed, 16 May 2012 10:55:28 -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=pEd75/3sSIjnW4kXxWc1tiMVizAoyOW0EyjimeLNXnU=; b=JlF+SCTnwbi0qJx2+xdW/H3F52pz+n637l/t3QatSkxFULmCPbuOfKca5j13YSO9uu 5BsOcKLXv4fd4CcLcPHVgOGaPChO66AeVHZpmmcuRqCu26KsTqWw3oIWgy6MBHQwcqyc NP4yZ7VQIDggGhcUMsfRZyoiNB2Hc+xvw8QcCGDK8S6H+LfleFC9DWn4DfQnT5U6zn8F uDvQKjxbBe7cM76H5T3wplaIHwYZ3uQlonUjmgqQTutPu+XLqJ7thEQoG8X7St2Uxucj VK1a69FUZ6XZ14crO4bocUR37kvD8pzFsN7tMtd4xDQsnaKuzYOzF3+Qe70C3xgTZ6Be f2Rw== Received: by 10.52.70.209 with SMTP id o17mr2556904vdu.11.1337190928375; Wed, 16 May 2012 10:55:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Wed, 16 May 2012 10:54:46 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <4FA401F7.5060003@extendedsubset.com> References: <4FA401F7.5060003@extendedsubset.com> From: Eric Rescorla Date: Wed, 16 May 2012 10:54:46 -0700 Message-ID: To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlS6JydJkTL68pxOh8R1SvWkGcqmwfl4Dec9nU9uIXGDXIjFQSD7RoswTnA8WrwAriBNSpq Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 16 May 2012 17:55:33 -0000 On Fri, May 4, 2012 at 9:21 AM, Marsh Ray wrote: > > I would appreciate it if the participants of the TLS WG will give this draft > a reading and serious consideration to taking it up as a work item: I have reviewed this document and I don't believe that the WG should adopt it. I understand the general desire to minimize the number of things exposed to a passive attacker but when one actually looks at the list of things that are disclosed, it's not particularly impressive. The draft says: The server's identity, session resumption data, and session ticket data are all sent in the clear. When client cert authentication is used, the client's identity and the server's list of trusted root CAs is also exposed. Typically the leaked information is sufficient to allow a passive observer to fingerprint the TLS client and server applications in use, and even to learn something about the connection history of the user. Unfortunately, much of this data is trivial to observe anyway. In particular: - The session ID and session ticket should both be random and/or encrypted, so what you really learn is that the client and server have communicated recently. But you can observe whether resumption is used merely from message order and size. - The server's trusted root list isn't any kind of secret and can be trivially elicited just by asking the server a single time. - You can fingerprint the server actively cheaply, so hiding that information from a passive attacker doesn't buy you much. - Fingerprinting the client is often possible if it does any HTTP at all (just based on the client's HTTP headers). Moreover, the cipher suite list is one of the most powerful fingerprinting tools and that lives in ClientHello, not ClientHello2. This leaves us with SNI and the client's certificate. SNI can often be inferred passively by examining message length and it's well-known that you can infer what sites people are visiting by traffic analysis [0], so the degree of protection that is provided here is distinctly limited. Finally, we have the client certificate. The idea of protecting the client certificate has been discussed many times over the years, most recently in Paris. However, given the extremely low use of client certificates, the rather significant level of changes to the protocol to protect it, and the fact that all the proposed changes are vulnerable to active attack, these proposals seem of limited value. In Paris, the WG was specifically asked the question of whether they wanted to protect client certificates from passive attack (but have them be vulnerable to active attack) and the answer was clear. (http://www.ietf.org/proceedings/83/minutes/minutes-83-tls.txt): Joe: 2 questions: do you think its important to protect client cert against passive attack (e.g. defeatable by active)? Or do you think it's not worth pursuing and we should move on? No one hums on first, lots of hums on 2nd. I don't see that this draft has a significantly different cost/benefit tradeoff. It's true that it protects more than the certificate, but (a) it still doesn't protect against active attack (b) most of the data it protects can be inferred by other means and (c) it does a lot more damage to the TLS state machine in the process. -Ekr [0] Chen, et al., "Side-Channel Leaks in Web Applications: a Realisty Today, a Challenge Tomorrow", Oakland 2007. Sen et al, "Statistical Identification of Encrypted Web Browsing Traffic", Oakland 2002. From n.mavrogiannopoulos@gmail.com Wed May 16 13:01:54 2012 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 767AA21F861C for ; Wed, 16 May 2012 13:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 bRW8vU1g4ujB for ; Wed, 16 May 2012 13:01:53 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 99BE821F85E6 for ; Wed, 16 May 2012 13:01:53 -0700 (PDT) Received: by eekd4 with SMTP id d4so359553eek.31 for ; Wed, 16 May 2012 13:01:52 -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=MwVNneylJ5RqJZUakxOl/uqZyimcqejRqDJh0lIHaFs=; b=nN5QxHb1qlI8AgMwlThyvubZLZAZ0EinmFpGfKr6SjIjvwh/bChqYVzZSVvRNeq8vC PNcxWbkzmCK5f1RZnTIOSzsk5skUZ6ND/UiG+QIcqvZmoic2wdG3LO+yJxw5VITbgZbT 1UEjddYcC4ITsIjQ9ubK6JnctWZBTlbpFOWTU4ioBPp/yftOTUil95sQ/WKqrSaSxvBO QW/e7YPE+Rz8NK7WGrV5J8cf+ahkXTIQ/Tfr0KJR/QYElidDWaJBChZLnZRvamr3Si8S jHu6UTDSXab3mALDjqeS0ww6Tk7LU7xPyu22NZKkEfup42RcyDAA7z49whaDE7EhUTKL Z4rA== Received: by 10.213.113.8 with SMTP id y8mr1751733ebp.101.1337198512811; Wed, 16 May 2012 13:01:52 -0700 (PDT) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id z5sm17400495eem.3.2012.05.16.13.01.51 (version=SSLv3 cipher=OTHER); Wed, 16 May 2012 13:01:52 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4FB407AA.7050400@gnutls.org> Date: Wed, 16 May 2012 22:01:46 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: tls@ietf.org References: <4FA401F7.5060003@extendedsubset.com> In-Reply-To: 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-ray-tls-encrypted-handshake-00.txt 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, 16 May 2012 20:01:54 -0000 On 05/16/2012 07:54 PM, Eric Rescorla wrote: > - You can fingerprint the server actively cheaply, so hiding that > information from a passive attacker doesn't buy you much. You cannot always fingerprint the server cheaply. What if the server presents different identities depending on where you connect from? In that case passive protection of the server credentials is an advantage. > - Fingerprinting the client is often possible if it does > any HTTP at all (just based on the client's HTTP headers). > Moreover, the cipher suite list is one of the most > powerful fingerprinting tools and that lives in > ClientHello, not ClientHello2. > This leaves us with SNI and the client's certificate. SNI can often be Also SRP and PSK usernames. > Finally, we have the client certificate. The idea of protecting the > client certificate has been discussed many times over the years, most > recently in Paris. However, given the extremely low use of client > certificates, the rather significant level of changes to the > protocol to protect it, and the fact that all the proposed changes > are vulnerable to active attack, these proposals seem of limited > value. Interestingly this proposal isn't vulnerable to active attacks. The client only sends its certificate, encrypted, after the server has presented a signed serverkeyexchange. If the client verifies that serverkeyexchange on reception he can be sure that the only the legitimate server knows the key to read it. In any case certificates, and usernames typically contain e-mails and that makes them a prime target for eavesdropping. Thus even protection against passive attacks is an interesting property for several use-cases. > I don't see that this draft has a significantly different cost/benefit > tradeoff. It's true that it protects more than the certificate, > but (a) it still doesn't protect against active attack (b) most > of the data it protects can be inferred by other means and (c) > it does a lot more damage to the TLS state machine in the process. I believe (a) isn't true. (c) is an unfortunate side-effect and by checking the EH protocol closely, several things could be simplified if TLS had privacy features designed in from the beginning. My opinion is that a redesign of TLS is needed to account for privacy as this draft does. I see this draft being as the first steps for TLS 1.3 which should include privacy protection by default. Dismissing it without suggesting an alternative plan seems like a step backwards for TLS and privacy. regards, Nikos From nico@cryptonector.com Wed May 16 13:30:48 2012 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 33A9D21F86FC for ; Wed, 16 May 2012 13:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 h1vIkBcMJ5DF for ; Wed, 16 May 2012 13:30:47 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id A4B0A21F86F3 for ; Wed, 16 May 2012 13:30:47 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 44E331F0086 for ; Wed, 16 May 2012 13:30:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=hYvkedylMOC7tK38nhrdy VIpQ8/4NS6n0qJcdOE6hFLfHgDD6JGdhpt2PIRWOOwkzwpu8YUkaEoiJP9Ym6/pX w8u9mY5zNaR6rKFRxfFMTidhhdKNlw8In7rXZyUi/L+TR72kEeSHP3rInzoQH3P9 Anc6JSYUpQ00GjUMyfbrCM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=09w/CB5JzzoX2lESq81e U/hQRqo=; b=GSuJpDUt80T6sf7PIRzYnBl0ItJKyaIkrcwJCYIgJSRACPdf9yQf BrccfG3/GmYqHPW42pf1TTBgf/Epq/DRtb0D1YSmq+Ht1uLgx/ow1aq1DfJi7f+v cPImhVrbdaEIlWECIVq1oHEa9+LYdz+npG7VGHK+IWF85FjPeWhS94A= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 169A21F007C for ; Wed, 16 May 2012 13:30:47 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so1620912pbc.31 for ; Wed, 16 May 2012 13:30:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.237.166 with SMTP id vd6mr19650328pbc.139.1337200246614; Wed, 16 May 2012 13:30:46 -0700 (PDT) Received: by 10.68.5.99 with HTTP; Wed, 16 May 2012 13:30:46 -0700 (PDT) In-Reply-To: References: <4FA401F7.5060003@extendedsubset.com> Date: Wed, 16 May 2012 15:30:46 -0500 Message-ID: From: Nico Williams To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 16 May 2012 20:30:48 -0000 Eric, In addition to Nikos' point I'd like to point out that it's not just the things this approach would protect today, but also the future extensions that it will also protect. More importantly, I think starting cryptographic protection as early as possible is a good design goal in general. It is worth asking whether these changes are worthwhile, of course. Even if desirable, if they were to be too difficult to implement and/or deploy then desirability might not be sufficient. But I think it's too soon to tell that this is too difficult to implement. I don't think Marsh's proposal does quite as much violence to implementations as you seem to think, and in any case, that's a one-time hit. The bigger concern for me is whether refactoring can be done so as to keep the complexity of implementation withing acceptable limits, but I think that must be possible anyways. Nico -- From ekr@rtfm.com Wed May 16 13:52:57 2012 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 0819421F85C0 for ; Wed, 16 May 2012 13:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.892 X-Spam-Level: X-Spam-Status: No, score=-102.892 tagged_above=-999 required=5 tests=[AWL=0.085, 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 9OVfworI-5nF for ; Wed, 16 May 2012 13:52:56 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A7AB221F85BE for ; Wed, 16 May 2012 13:52:52 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1331665vbb.31 for ; Wed, 16 May 2012 13:52:52 -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:content-transfer-encoding :x-gm-message-state; bh=PuiWEC6ZzllyMgDxmktsf0GDfdm+hJRYBuc1ArvWme0=; b=lIXm1ua/M8mXUWHkWx5W6/MZrAYwhBwxNu/Wn/YftzFLvrXGDYynwF4k3AO/9a7DKo V+GpOwx3ajXxRs7wGBkuOW0gYMh7t6AzAMtK5MLCth75MZaXweDYgHLfupMeXaRThJdo 6wYvAQDbFycL/4uIZ1UutmQIsFHkgjwKX52fKQWtEIKvlGnKHrF6FRYgWofjnzIcZZu+ Ll2SXq8TwglTuP1Ej47HINTAXPPL6WbnvGC0JicsmIDSISHeTw5TF/LdovVxsHPl5gD4 tXIfrECJhxY630ChXxvvseyfXYJwTbKMU6pzlLMQINsOOKsxF+Sg5QKEualPz31QKRh6 EsdQ== Received: by 10.220.141.79 with SMTP id l15mr3432231vcu.48.1337201572176; Wed, 16 May 2012 13:52:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Wed, 16 May 2012 13:52:12 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <4FB407AA.7050400@gnutls.org> References: <4FA401F7.5060003@extendedsubset.com> <4FB407AA.7050400@gnutls.org> From: Eric Rescorla Date: Wed, 16 May 2012 13:52:12 -0700 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkyLkvYyyX6v5n19eOrxgQjXbmJMx2AU0v+mm8lbdEhmuVdUBLBBsyxaWkF03d5oUu46iuL Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 16 May 2012 20:52:57 -0000 On Wed, May 16, 2012 at 1:01 PM, Nikos Mavrogiannopoulos wrote: > On 05/16/2012 07:54 PM, Eric Rescorla wrote: > > >> - You can fingerprint the server actively cheaply, so hiding that >> =A0 information from a passive attacker doesn't buy you much. > > > You cannot always fingerprint the server cheaply. What if the server > presents different identities depending on where you connect from? In > that case passive protection of the server credentials is an advantage. Why? If I'm on-path, I can just generate the same address as the client. >> - Fingerprinting the client is often possible if it does >> =A0 any HTTP at all (just based on the client's HTTP headers). >> =A0 Moreover, the cipher suite list is one of the most >> =A0 powerful fingerprinting tools and that lives in >> =A0 ClientHello, not ClientHello2. >> This leaves us with SNI and the client's certificate. SNI can often be > > > Also SRP and PSK usernames. Neither of these are in wide use, especially on the Web (more on this short= ly). Moreover, it's not clear that these can be bootstrapped into this framework= . For instance, SRP requires a salt that is stored with the username, so you must reveal the username to the server prior to doing the key exchange, which means you somehow need a preexisting DH exchange secured by the server. >> Finally, we have the client certificate. The idea of protecting the >> client certificate has been discussed many times over the years, most >> recently in Paris. However, given the extremely low use of client >> certificates, the rather significant level of changes to the >> protocol to protect it, and the fact that all the proposed changes >> are vulnerable to active attack, these proposals seem of limited >> value. > > > Interestingly this proposal isn't vulnerable to active attacks. The > client only sends its certificate, encrypted, after the server has > presented a signed serverkeyexchange. If the client verifies that > serverkeyexchange on reception he can be sure that the only the > legitimate server knows the key to read it. The attacker simulates being a server which doesn't support this extension, and unless clients hard fail (which is problematic), then the client will send the certificate in the clear. > (c) is an unfortunate side-effect and by > checking the EH protocol closely, several things could be simplified > if TLS had privacy features designed in from the beginning. > > My opinion is that a redesign of TLS is needed to account for privacy > as this draft does. I see this draft being as the first steps for TLS > 1.3 which should include privacy protection by default. Dismissing it > without suggesting an alternative plan seems like a step backwards for > TLS and privacy. We already have a perfectly good alternative plan: do simple TLS handshake to establish a secure channel and then renegotiate inside that channel with any fancy extensions you want. Note that this would have the advantage that it works with basically any TLS enhancement without any special per-enhancement engineering. The only real downsides of this are performance in the forms of latency and computational cost. As has been widely observed the computational cost of TLS relative to CPU power is shrinking fast, so this primarily leaves latency, which is principally an issue in the Web environment and even that for a relatively small number of servers. Since basically none of the features that you're claiming leak a lot of information (client certs, SRP, PSK) have significant deployment on the Web= , this seems like classic premature optimization. -Ekr From ekr@rtfm.com Wed May 16 13:54:25 2012 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 B98FC21F8682 for ; Wed, 16 May 2012 13:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.894 X-Spam-Level: X-Spam-Status: No, score=-102.894 tagged_above=-999 required=5 tests=[AWL=0.083, 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 FoKfPVTOWXs5 for ; Wed, 16 May 2012 13:54:25 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7C421F8659 for ; Wed, 16 May 2012 13:54:25 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1333249vbb.31 for ; Wed, 16 May 2012 13:54:24 -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:content-transfer-encoding :x-gm-message-state; bh=j79xsdket06IVG1nXIWleR3i8SWfcSwSr4efWu5CYNA=; b=gH84MECpUrdO5rHVRLI6mOdHz+IlezposBie09qNqt7lZHnL9s9sVrqKSrC2yR6x6N b6AEJBxjjNHsMc8oEwJcr7HJ45lTk6Gt5oPhGsub4v8Fnqb/vKDrzeOoGMVegEOinWZu j7Flh7KV3UEGcSwTWOj80HGBEgk0jHySnHkfhtVxuO3YUR28tDRkQGRCbnHzg/kkCScj FGhHKLsDOCfbi0C6tjUwaaWU4gW3qDOi4lYSUyHkZe+KUXFEGheCk9i+0Sfv6PTH+5+Y Rrt8M8+GFRKaMjyWJocwfTA2JwIYfi+C/lKOYQ73wRlOJF0MKBSsaZuq7b6wsonZYbK7 cklw== Received: by 10.220.150.12 with SMTP id w12mr3474226vcv.39.1337201664669; Wed, 16 May 2012 13:54:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Wed, 16 May 2012 13:53:44 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <4FA401F7.5060003@extendedsubset.com> From: Eric Rescorla Date: Wed, 16 May 2012 13:53:44 -0700 Message-ID: To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQncYiwxLeh7CVmWezLcyy+L+wsd2PddNhkjYRnWjbYzq+yCimLoSvRZS9hLlkJ9yap/A5lA Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 16 May 2012 20:54:25 -0000 On Wed, May 16, 2012 at 1:30 PM, Nico Williams wrot= e: > Eric, > > In addition to Nikos' point I'd like to point out that it's not just > the things this approach would protect today, but also the future > extensions that it will also protect. =A0More importantly, I think > starting cryptographic protection as early as possible is a good > design goal in general. > > It is worth asking whether these changes are worthwhile, of course. > Even if desirable, if they were to be too difficult to implement > and/or deploy then desirability might not be sufficient. =A0But I think > it's too soon to tell that this is too difficult to implement. =A0I > don't think Marsh's proposal does quite as much violence to > implementations as you seem to think, and in any case, that's a > one-time hit. =A0The bigger concern for me is whether refactoring can be > done so as to keep the complexity of implementation withing acceptable > limits, but I think that must be possible anyways. But as is already clear, this design doesn't actually give you protection for all additional features: rather it interacts badly with a number of existing features. There's no reason to think that other future features wouldn't have similar problems. -Ekr From marsh@extendedsubset.com Wed May 16 13:58:52 2012 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 136CC21F86A6 for ; Wed, 16 May 2012 13:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 RHsh3Y4egAu6 for ; Wed, 16 May 2012 13:58:51 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 89DC621F86A3 for ; Wed, 16 May 2012 13:58:51 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SUlJ5-000BGe-4C; Wed, 16 May 2012 20:58:51 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 8A1EF6067; Wed, 16 May 2012 20:58:49 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+K6YfVS1K5AhUkYXTFOPcZ7tW01gpifV0= Message-ID: <4FB41509.2040401@extendedsubset.com> Date: Wed, 16 May 2012 15:58:49 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Eric Rescorla References: <4FA401F7.5060003@extendedsubset.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 16 May 2012 20:58:52 -0000 On 05/16/2012 03:53 PM, Eric Rescorla wrote: > > But as is already clear, this design doesn't actually give you protection > for all additional features: rather it interacts badly with a number of > existing features. There's no reason to think that other future > features wouldn't have similar problems. Of course there is! Future features (e.g. NP(N), Websockets, SPDY) can not only be designed to work smoothly with Encrypted Handshake, but may even benefit from and require it. - Marsh From ekr@rtfm.com Wed May 16 14:03:56 2012 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 AE9F421F86DC for ; Wed, 16 May 2012 14:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.897 X-Spam-Level: X-Spam-Status: No, score=-102.897 tagged_above=-999 required=5 tests=[AWL=0.080, 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 2-BHQCJGxIMm for ; Wed, 16 May 2012 14:03:56 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2464F21F86BE for ; Wed, 16 May 2012 14:03:56 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1341499vbb.31 for ; Wed, 16 May 2012 14:03:55 -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:content-transfer-encoding :x-gm-message-state; bh=h4i+BWAOjbz3d0y8qd7WQeccnzK/vwkY0ZDBuejeEqU=; b=T4Ud15L92q2BszWFy21+vPHfGAbVQTgqDN6GpMczzGvOxRdYZCQvURaAkahPQQ8VVt uPxH8xxosWTyVLgTyUFNFGJ4JljfimjGK0hZHOI2rCSicjJh57Mc607SdDYVE0IY6iA7 m7jWlx6n3qn/nutWCawrOiHYMuC341m15we/wUquwU82wVkYp1CRHZQPdODVhJThNIKC ufG+EcAz3rATNUgGqqOPNsllWr+zowrnvq+K/tTXyy7PDYfqTGQGsWe0x3HWupqeUdBv 7l+8oVve0/oIdDuicPB5FBulSeVM0RQyV8aiOUCFbHGUlG7brk5PYExjmgZe/14BmpGO 6GBw== Received: by 10.52.74.69 with SMTP id r5mr2830516vdv.110.1337202235628; Wed, 16 May 2012 14:03:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Wed, 16 May 2012 14:03:15 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <4FB41509.2040401@extendedsubset.com> References: <4FA401F7.5060003@extendedsubset.com> <4FB41509.2040401@extendedsubset.com> From: Eric Rescorla Date: Wed, 16 May 2012 14:03:15 -0700 Message-ID: To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmCRjpAQLpASXqZUUR2m7zRDSTYfsafIt3zjwWhVfn21YeVl0BBmx0Xz1l++H1V14OALgoH Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 16 May 2012 21:03:56 -0000 On Wed, May 16, 2012 at 1:58 PM, Marsh Ray wrote= : > On 05/16/2012 03:53 PM, Eric Rescorla wrote: >> >> >> But as is already clear, this design doesn't actually give you protectio= n >> for all additional features: rather it interacts badly with a number of >> existing features. =A0There's no reason to think that other future >> features wouldn't have similar problems. > > > Of course there is! Future features (e.g. NP(N), Websockets, SPDY) can no= t > only be designed to work smoothly with Encrypted Handshake, but may even > benefit from and require it. I don't know why you raise Websockets here, since it's at an entirely different layer. More generally, yes, *some* features would obviously integrate smoothly, but it's really a stretch to talk about these as future features since they were designed prior to this proposal and indeed you list them as part of the design motivation in your original message. The test is how difficult it will be to make actual future features work. -Ekr From n.mavrogiannopoulos@gmail.com Wed May 16 14:13:40 2012 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 020EE21F864D for ; Wed, 16 May 2012 14:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 lc4hYE9-Jk32 for ; Wed, 16 May 2012 14:13:39 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E576821F85E6 for ; Wed, 16 May 2012 14:13:38 -0700 (PDT) Received: by eekd4 with SMTP id d4so373511eek.31 for ; Wed, 16 May 2012 14:13:33 -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:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=u/YLBGguuOnyh4u+kla6RlHNhMpnwp478zhh3mcnQ+s=; b=O7QSgDNHGwoD4veW+m9DWNzsQWJzzmcIA5Rmtt2HdYYoOWYEI/jcwb/vRwSc4NuQpH 3wYu46PIt0h4pxGIXcwt5GI0+DlsXJViJ4SzwNb05OdS+DYnoo+Gx0Z225/olwuGcO6p XekWvqOZdrLc2l88t7dZ58cQvRi/2kTfMI9ye4RqzvbRN4OHWKhA0BU30cKLUYwqfCs9 VMbE6xBV2+N/5C1Tc4CMX64d3TXvsMEqf04vs2+IgeFxA9mzjyjempT5Edqlvpesw+KD abR+aZFxqs7xqD3da45gaFzMJv53yFlvsTZCAKMPXpS5YOjy+gbvdjftbHrEkqXUZHue uNSg== Received: by 10.213.114.84 with SMTP id d20mr1835484ebq.15.1337202813797; Wed, 16 May 2012 14:13:33 -0700 (PDT) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id v46sm18111270eef.11.2012.05.16.14.13.32 (version=SSLv3 cipher=OTHER); Wed, 16 May 2012 14:13:32 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4FB4187C.9060305@gnutls.org> Date: Wed, 16 May 2012 23:13:32 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: Eric Rescorla References: <4FA401F7.5060003@extendedsubset.com> <4FB407AA.7050400@gnutls.org> In-Reply-To: X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 16 May 2012 21:13:40 -0000 On 05/16/2012 10:52 PM, Eric Rescorla wrote: >>> Finally, we have the client certificate. The idea of protecting the >>> client certificate has been discussed many times over the years, most >>> recently in Paris. However, given the extremely low use of client >>> certificates, the rather significant level of changes to the >>> protocol to protect it, and the fact that all the proposed changes >>> are vulnerable to active attack, these proposals seem of limited >>> value. >> Interestingly this proposal isn't vulnerable to active attacks. The >> client only sends its certificate, encrypted, after the server has >> presented a signed serverkeyexchange. If the client verifies that >> serverkeyexchange on reception he can be sure that the only the >> legitimate server knows the key to read it. > The attacker simulates being a server which doesn't support this > extension, and unless clients hard fail (which is problematic), > then the client will send the certificate in the clear. This is a denial of service attack that even TLS is vulnerable to. A client that doesn't want its identity to be expose it will disconnect. This is the same as saying the TLS is insecure because an attacker can say to the client please use SSL 2.0. It's up to the client to enforce the desired security level. > We already have a perfectly good alternative plan: do simple TLS handshake > to establish a secure channel and then renegotiate inside that channel > with any fancy extensions you want. It is not identical. This plan _is_ vulnerable to mitm attack. I can perfectly intercept an anonymous handshake and watch the certificate sent in the second handshake. In the EH protocol this isn't possible (unless of course you assume that the client will voluntarily transmit its identity in the clear). > Since basically none of the features that you're claiming leak a lot of > information (client certs, SRP, PSK) have significant deployment on the Web, > this seems like classic premature optimization. Note that this proposal started because a popular browser (chrome) did try to add that functionality restricted to the NPN extension. As far as I know major TLS libraries already implement that extension, so there is need for hiding parts of the handshake. regards, Nikos From ekr@rtfm.com Wed May 16 14:21:07 2012 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 0680C21F8716 for ; Wed, 16 May 2012 14:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.899 X-Spam-Level: X-Spam-Status: No, score=-102.899 tagged_above=-999 required=5 tests=[AWL=0.078, 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 KYCuqYcdRiog for ; Wed, 16 May 2012 14:21:06 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA4C21F85EA for ; Wed, 16 May 2012 14:21:06 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1356372vbb.31 for ; Wed, 16 May 2012 14:21:05 -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=KIgHXlzQ30VJ5N9nbs0iWb/hqeXgEXyTUe01MBHAJyQ=; b=RBzPzQ/7jwNkak10WELXObbgyfr3fAWE04S2X+uV1odmZWYhgO8sICjTwZW0xZVk8l xMeeIwO8SvQN9DlhbEO+Fi90QHadPvcv27k4vLFm1HApuwibHtqOHQRCjN72XI4CKvGk x6K3SOH8kz3lraftYXRMmPeegV6k9wx1DUiWw+xOgkRNf24APkmkKU1l6z2ximfIMBMk zcKwO46GoHdtYPQqOgPGRxbABfQNBU4WlItC47DZAQbqgnE1+PofqN8VgSfmpOLlT9iZ 5mjoEuHTTG22qngYOXIWJOTu0OAWGO8NxaqJrZsPnb3cPq/stFqvBcNxiVvAfPtMtTL3 8W5Q== Received: by 10.220.150.12 with SMTP id w12mr3523908vcv.39.1337203265702; Wed, 16 May 2012 14:21:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Wed, 16 May 2012 14:20:25 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <4FB4187C.9060305@gnutls.org> References: <4FA401F7.5060003@extendedsubset.com> <4FB407AA.7050400@gnutls.org> <4FB4187C.9060305@gnutls.org> From: Eric Rescorla Date: Wed, 16 May 2012 14:20:25 -0700 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmx1/FCcDgae3ROlqDiXiJT5FigNSV83XcPORRL11YWCfMnLiMMsTkhDn1Xjcr06dijMu7B Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 16 May 2012 21:21:07 -0000 On Wed, May 16, 2012 at 2:13 PM, Nikos Mavrogiannopoulos wrote: > On 05/16/2012 10:52 PM, Eric Rescorla wrote: > > >>>> Finally, we have the client certificate. The idea of protecting the >>>> client certificate has been discussed many times over the years, most >>>> recently in Paris. However, given the extremely low use of client >>>> certificates, the rather significant level of changes to the >>>> protocol to protect it, and the fact that all the proposed changes >>>> are vulnerable to active attack, these proposals seem of limited >>>> value. >>> Interestingly this proposal isn't vulnerable to active attacks. The >>> client only sends its certificate, encrypted, after the server has >>> presented a signed serverkeyexchange. If the client verifies that >>> serverkeyexchange on reception he can be sure that the only the >>> legitimate server knows the key to read it. >> The attacker simulates being a server which doesn't support this >> extension, and unless clients hard fail (which is problematic), >> then the client will send the certificate in the clear. > > > This is a denial of service attack that even TLS is vulnerable to. > A client that doesn't want its identity to be expose it will > disconnect. This is the same as saying the TLS is insecure because an > attacker can say to the client please use SSL 2.0. It's up to the > client to enforce the desired security level. That's not the security guarantee that TLS generally attempts to provide, namely the highest common parameters, not the weakest, which is why there is such extensive protection against downgrade attacks. Yes, I realize that it's difficult to provide that protection in this case, which is precisely why in Paris we decided that it wasn't worth moving forward with encrypted client certificate extensions. >> We already have a perfectly good alternative plan: do simple TLS handshake >> to establish a secure channel and then renegotiate inside that channel >> with any fancy extensions you want. > > > It is not identical. This plan _is_ vulnerable to mitm attack. I can > perfectly intercept an anonymous handshake and watch the certificate > sent in the second handshake. Not anonymous. Server authenticated. > In the EH protocol this isn't possible > (unless of course you assume that the client will voluntarily transmit > its identity in the clear). Which clients will of course do (or not, but in either case the security guarantees of renegotiation for the client cert are the same in this case). >> Since basically none of the features that you're claiming leak a lot of >> information (client certs, SRP, PSK) have significant deployment on the Web, >> this seems like classic premature optimization. > > > Note that this proposal started because a popular browser (chrome) did > try to add that functionality restricted to the NPN extension. As > far as I know major TLS libraries already implement that extension, > so there is need for hiding parts of the handshake. There has been extensive debate about whether NPN actually needs to be encrypted. Given that NPN currently more or less always means SPDY, I think the best thing you could say about that is that the jury is still out (and more likely that it's unnecessary). -Ekr From marsh@extendedsubset.com Wed May 16 15:08:46 2012 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 8416A9E8021 for ; Wed, 16 May 2012 15:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 njCAvRhfLXGq for ; Wed, 16 May 2012 15:08:45 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id AF5CE9E8020 for ; Wed, 16 May 2012 15:08:45 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SUmOj-00012d-9I; Wed, 16 May 2012 22:08:45 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id D042560A1; Wed, 16 May 2012 22:08:43 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18N475VRJdtI6VB0KuoQlMyqsrhpHfSdM4= Message-ID: <4FB42569.5020607@extendedsubset.com> Date: Wed, 16 May 2012 17:08:41 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Eric Rescorla References: <4FA401F7.5060003@extendedsubset.com> <4FB407AA.7050400@gnutls.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 16 May 2012 22:08:46 -0000 On 05/16/2012 03:52 PM, Eric Rescorla wrote: > On Wed, May 16, 2012 at 1:01 PM, Nikos Mavrogiannopoulos > wrote: >> >> You cannot always fingerprint the server cheaply. What if the server >> presents different identities depending on where you connect from? In >> that case passive protection of the server credentials is an advantage. > > Why? If I'm on-path, I can just generate the same address as the client. Yes, EH does not attempt to protect against active attacks. Up until recently I believed that unauthenticated encryption was bad because it was did not resist active attacks and could even lend a false sense of security. On any given network segment, an active attack is usually just as practical as a passive one. But then I considered the sheer volume of traffic flying around the net in aggregate. Some unknowable huge amount of it is subject to eavesdropping. But what we do know that only a very very small amount of it will be non-consentually MitM'd. So now I believe that converting a passive attack to a possibly-detectable active attack can be very valuable. >> Also SRP and PSK usernames. > > Neither of these are in wide use, especially on the Web (more on this shortly). Chicken, meet egg. Note: I am specifically not calling anyone a chicken. :-) > Moreover, it's not clear that these can be bootstrapped into this framework. > For instance, SRP requires a salt that is stored with the username, so > you must reveal the username to the server prior to doing the key > exchange, which means you somehow need a preexisting DH exchange > secured by the server. There are options for SRP, but I agree with Eric that SRP shouldn't be the defining use case for the evolution of TLS. >>> Finally, we have the client certificate. The idea of protecting the >>> client certificate has been discussed many times over the years, most >>> recently in Paris. Have these all been merely solutions chasing nonexistent problems? Or is there possibly some demand for something better? >>> However, given the extremely low use of client >>> certificates, Chicken-egg, to some degree. >>> the rather significant level of changes to the >>> protocol to protect it, and the fact that all the proposed changes >>> are vulnerable to active attack, these proposals seem of limited >>> value. Yes, EH involves some cost and it does not solve everything. >> Interestingly this proposal isn't vulnerable to active attacks. The >> client only sends its certificate, encrypted, after the server has >> presented a signed serverkeyexchange. If the client verifies that >> serverkeyexchange on reception he can be sure that the only the >> legitimate server knows the key to read it. > > The attacker simulates being a server which doesn't support this > extension, and unless clients hard fail (which is problematic), > then the client will send the certificate in the clear. I agree with Eric, an active attack will remain possible for all maximally interoperable TLS client applications. Again, EH does not attempt to protect against active attacks. > We already have a perfectly good alternative plan: do simple TLS handshake > to establish a secure channel and then renegotiate inside that channel > with any fancy extensions you want. Everyone knows how much I value secure renegotiation. But it seems that our users are speaking with their feet and saying that the status quo is not, in fact, perfectly good. > Note that this would have the advantage > that it works with basically any TLS enhancement without any special > per-enhancement engineering. The only real downsides of this > are performance in the forms of latency and computational cost. As > has been widely observed the computational cost of TLS relative > to CPU power is shrinking fast, so this primarily leaves latency, which is > principally an issue in the Web environment and even that for a relatively > small number of servers. I suppose web servers run by admins who value low latency are still a minority in absolute terms. But some of these sites are pretty darn successful (famously Amazon) and others of them are pushing TLS protocol innovations into half the world's web browsers (Google, Mozilla). > Since basically none of the features that you're claiming leak a lot of > information (client certs, SRP, PSK) have significant deployment on the Web, > this seems like classic premature optimization. I think you're slicing it too thin. The TLS handshake leaks a lot of metadata. So much so that people are reluctant to trust it for user credentials, standardize new upper-level features like NP(N), and even the talented developers behind Tor feel the need to migrate away due to TLS's susceptibility to selective DoS. Many of us have had the experience of looking at Wireshark and diagnosing connectivity issues. We shouldn't be able to do this! Useful as this may be, one of the properties of an ideal security protocol is that it will be annoyingly difficult to analyze passively. This means taking stuff that's now sent in the clear and moving it under encryption. EH is an attempt to achieve that goal with minimal disruption. - Marsh From nico@cryptonector.com Wed May 16 15:17:58 2012 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 133DB21F872E for ; Wed, 16 May 2012 15:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 C8J-HBGlZW+2 for ; Wed, 16 May 2012 15:17:57 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 58AAD21F86EE for ; Wed, 16 May 2012 15:17:57 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 22898508072 for ; Wed, 16 May 2012 15:17:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=eK5S+Lsa5mrzm7x4E2MtO cuUCR36EiveBgFvA0PMqyTMMrFUqQ6UKZcEKuccR+BBIufFT6E+4XHrgFovPCvHQ Rppil+GVxtsJfIycp/xyKVMv6qQLKSoGli+Rjg0kFBOcJ1eHgA5uTKNZ7N+1XsPe QZEb+3rdvTXEZJUsjNfGas= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=lHDSqrH4ysoVE24+3g2U 7jPrhns=; b=GwMTrrSumWjOHwSiFtCsYSv5EAHqGPNsTfXI/DNN0+0J7RzAK3Bn RPWO4+DOlSn3+OSCd2hpElQIMMWxSWcFEbzrZAq5At13BMCVjnsP2r5x3Tn1XLVe 0+oDD9GRE+U0a0mYhM70pxv4unT79vL4OPAPtMmHZ35e2DZbPT8QOvA= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 07AF5508069 for ; Wed, 16 May 2012 15:17:56 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so1719839pbc.31 for ; Wed, 16 May 2012 15:17:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.201 with SMTP id ow9mr20417849pbb.160.1337206676691; Wed, 16 May 2012 15:17:56 -0700 (PDT) Received: by 10.68.5.99 with HTTP; Wed, 16 May 2012 15:17:56 -0700 (PDT) In-Reply-To: References: <4FA401F7.5060003@extendedsubset.com> <4FB407AA.7050400@gnutls.org> Date: Wed, 16 May 2012 17:17:56 -0500 Message-ID: From: Nico Williams To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 16 May 2012 22:17:58 -0000 On Wed, May 16, 2012 at 3:52 PM, Eric Rescorla wrote: > We already have a perfectly good alternative plan: do simple TLS handshake > to establish a secure channel and then renegotiate inside that channel > with any fancy extensions you want. [...] The record type is visible to the attacker, so re-negotiation can be observed to be happening. I hear Tor used to use re-negotiation but had to stop because of this, it being trivial to observe re-negotiation happening, and re-negotiation being such a rare thing that blocking it is trivial. Nico -- From ekr@rtfm.com Wed May 16 15:41:45 2012 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 A511021F8622 for ; Wed, 16 May 2012 15:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.903 X-Spam-Level: X-Spam-Status: No, score=-102.903 tagged_above=-999 required=5 tests=[AWL=0.074, 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 JT03FwrM-sDV for ; Wed, 16 May 2012 15:41:45 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DBAE321F85FB for ; Wed, 16 May 2012 15:41:44 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1418785vbb.31 for ; Wed, 16 May 2012 15:41:44 -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=8+OwMU5kbalkY6LT0hVse00yP4t+5pCYD6UscE/U1sc=; b=LQC/I14ttF7MkwToNCuXHX/Ra92gJWMa12Mm2L0Z6Cx2eqOm6MVqwVSZ2yy04aokn0 Dx6CxMEIKgbkorx2pCMbjMk6DN6xwv3pMO2y6HDULXq0hYN2Sr2xRULqbRiVi5Y4K6bj FPI3+qhiXkYO2JTQOWFswwZCpvzEt6jCgc2ur/WtaXauASIjPdeTCRYS6M87UjrXnEX0 yhieRdV+wVdpeAS+oXu/yk1+eVoUhJVJ+Boweomq2yTUzN8klzy4aLm/izKRJMz75bQ+ HdtGz1dajgoVkgib0Lf8rDlGSuLxSb3yUUfOsAagzLS+yCYcq4ndiu1I8BeBPUxoD69R lkzQ== Received: by 10.52.67.11 with SMTP id j11mr2955180vdt.132.1337208104345; Wed, 16 May 2012 15:41:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Wed, 16 May 2012 15:41:03 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <4FA401F7.5060003@extendedsubset.com> From: Eric Rescorla Date: Wed, 16 May 2012 15:41:03 -0700 Message-ID: To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlCH8xbIvlvNP9eMEGgdgQjd4gELT5CVUzGagjASFp/CvMqqUtcU7SYvDipz7JbZ3UGcJcU Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 16 May 2012 22:41:45 -0000 On Wed, May 16, 2012 at 10:54 AM, Eric Rescorla wrote: > On Fri, May 4, 2012 at 9:21 AM, Marsh Ray wrote: >> >> I would appreciate it if the participants of the TLS WG will give this draft >> a reading and serious consideration to taking it up as a work item: > > I have reviewed this document and I don't believe that > the WG should adopt it. [...] Just in case it wasn't clear, this (and the other messages I have sent to this thread) are sent in my individual capacity. When I intend to be acting as chair, I clearly identify it in my messages. -Ekr From marsh@extendedsubset.com Wed May 16 16:57:43 2012 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 770A19E8024 for ; Wed, 16 May 2012 16:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 OdzaNsqD-bdM for ; Wed, 16 May 2012 16:57:42 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 616B59E8020 for ; Wed, 16 May 2012 16:57:42 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SUo69-0004S8-W0; Wed, 16 May 2012 23:57:42 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 2D56F6085; Wed, 16 May 2012 23:57:40 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/Xe4eDd6f8TCEvV+geVNH0hwmnMrwXBRw= Message-ID: <4FB43EF2.4020001@extendedsubset.com> Date: Wed, 16 May 2012 18:57:38 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Eric Rescorla References: <4FA401F7.5060003@extendedsubset.com> <4FB41509.2040401@extendedsubset.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 16 May 2012 23:57:43 -0000 On 05/16/2012 04:03 PM, Eric Rescorla wrote: > On Wed, May 16, 2012 at 1:58 PM, Marsh Ray > wrote: >> Of course there is! Future features (e.g. NP(N), Websockets, SPDY) >> can not only be designed to work smoothly with Encrypted Handshake, >> but may even benefit from and require it. > > More generally, yes, *some* features would obviously integrate > smoothly, but it's really a stretch to talk about these as future > features since they were designed prior to this proposal and indeed > you list them as part of the design motivation in your original > message. The test is how difficult it will be to make actual future > features work. Agree. > I don't know why you raise Websockets here, since it's at an > entirely different layer. Partly I just associate them because they seemed to be proposed sort of in the same batch as SPDY and NP(N). But here's another take, an example of *the general kind of thing* that we might be able to consider after EH as a first step. This is not a central point of EH or a rigorous proposal I'm making. Perhaps someone has thought of something similar before. If you fundamentally don't like the idea of extending TLS merely to accomodate app data protocols (there are certainly good reasons to feel that way), please stop reading now. :-) From Wikipedia https://en.wikipedia.org/wiki/WebSockets : > WebSocket is a web technology providing for bi-directional, > full-duplex communications channels... (OK we knew that already) > In addition, the communications are done over the regular TCP port > number 80, which is of benefit for those environments which block > non-standard Internet connections using a firewall. !!! This is an affront to data security everywhere! And we have no one to blame but [TLS] (and the careless vendors, server admins, and the clueless users, but blaming them is useless). It is absurd to recommend that anyone should use TCP port number 80 to avoid selective DoS when port 443 SHOULD provide a much better solution. A selective DoS is only possible when the confidentiality is ineffective. Of course anyone could run websockets on port 443, but common usage (as embodied in Wikipedia) recommends port 80 without a second thought. This is what Websockets looks like: > GET /mychat HTTP/1.1 > Host: server.example.com > Upgrade: websocket > Connection: Upgrade > Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== > Sec-WebSocket-Protocol: chat > Sec-WebSocket-Version: 13 > Origin: http://example.com > > HTTP/1.1 101 Switching Protocols > Upgrade: websocket > Connection: Upgrade > Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk= > Sec-WebSocket-Protocol: chat Almost none of that is useful at the HTTP layer, why would you even need to involve a web server? Passing the necessary info in a TLS extension could eliminate the server! Split off the websocket flow in the SSL offload device or other lightweight SSL stack. This could save a round trip or more of latency. But only *if* there were a way to pass the necessary information under encryption. We would also have to deal with the issue of active attacks, but still, we're talking about people happy with port 80 right now. Hmm, what would that look like.. > GET /mychat HTTP/1.1 Only '/mychat' conveys meaning. Send it later and drop the rest. > Host: server.example.com Already in SNI. > Upgrade: websocket >Sec-WebSocket-Protocol: chat >Sec-WebSocket-Version: 13 Sounds like a job for NP(N), already specified. > Connection: Upgrade It's now redundant. Drop it. > Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== Derive this and cryptographically bind it properly from your favorite flavor of strong mutual auth. E.g., SRP, PSK, existing TLS session support. > Origin: http://example.com Send in the extension. > HTTP/1.1 101 Switching Protocols > Upgrade: websocket > Connection: Upgrade > Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk= > Sec-WebSocket-Protocol: chat All this is now redundant. Drop it. So, we could combine EH, SNI, and NP(N) with a hypothetical Websocket TLS extension which might look something like: struct WebsocketClientToServerData { string url; string origin; }; struct WebsocketServerToClientData { // empty, just indicates acceptance }; effect: You no longer need a webserver to do websockets. * There is no longer an ad-hoc authenticated and unbound channel tunneled in HTTP, tunneled in TLS. * People happy with websockets on port 80 today could obtain the full security of TLS for their application data with only one additional round trip on the first connection and no additional round trips on subsequent (session resuming) connections. * Client apps in "environments which block non-standard Internet connections using a firewall" could restore connectivity using EH level two, unless their firewall is willing to break port 443 handshakes at random looking for a reason to DoS the client IP on future port 443 requests. - Marsh From marsh@extendedsubset.com Wed May 16 17:30:05 2012 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 7087021F8609 for ; Wed, 16 May 2012 17:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 jfQw7EuvMfFJ for ; Wed, 16 May 2012 17:30:05 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id E419221F85FB for ; Wed, 16 May 2012 17:30:04 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SUobU-000JiE-I2 for tls@ietf.org; Thu, 17 May 2012 00:30:04 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id B5EA360A1 for ; Thu, 17 May 2012 00:30:03 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18N+HVeYYHQiEP7BphdIwYlH+Y226vzSnE= Message-ID: <4FB44689.6030509@extendedsubset.com> Date: Wed, 16 May 2012 19:30:01 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: tls@ietf.org References: <4FA401F7.5060003@extendedsubset.com> <4FB407AA.7050400@gnutls.org> <4FB4187C.9060305@gnutls.org> In-Reply-To: <4FB4187C.9060305@gnutls.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 17 May 2012 00:30:05 -0000 On 05/16/2012 04:13 PM, Nikos Mavrogiannopoulos wrote: > > Note that this proposal started because a popular browser (chrome) did > try to add that functionality restricted to the NPN extension. For the record and before this meme gets out of hand, that was just one factor. I tried to list the motivating forces in that first email introducing the draft. At about the same time I saw several desired use cases running up against TLS limitations that seemed to have a common solution, or at least direction of improvement. I probably would not have gone to the trouble of writing a detailed I-D for any single one of them. :-) > As > far as I know major TLS libraries already implement that extension, > so there is need for hiding parts of the handshake. That, and I don't think the current incarnation of NP(N) is the best possible or even the best practical one. For example, NP(N) defines a new handshake message type (likely angering a few MitM in the process) but it doesn't seem to improve the handshake for anything except NP(N). The server-proposes-N/client-picks-1 negotiation is (IMHO) the right one for NP(N) and perhaps other extensions too, but it's not overly elegant with the current handshake. Of course the best NP(N) is the one that's properly RFC'd, by definition. Let's make it happen. - Marsh From n.mavrogiannopoulos@gmail.com Wed May 16 17:48:47 2012 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 A46CC21F86FD for ; Wed, 16 May 2012 17:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 nhn7Owl35x85 for ; Wed, 16 May 2012 17:48:47 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF0B021F86FA for ; Wed, 16 May 2012 17:48:46 -0700 (PDT) Received: by werf13 with SMTP id f13so1043778wer.31 for ; Wed, 16 May 2012 17:48:46 -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=5Oo1VFXmvduu7IzsHxg5+lUVmEXKNpl/6LTFp0AttQk=; b=xRLlEfJE6+6AoiXKxjQ6o6nqWKgfKK5495bUJ1alphCIJ6fT/gUJrbBWH4Ys/0LPwc 5j7kKvC1MmfwVvjUguPxQKXxvOOOhDpFKZMLm0PCztFgt605fkervGiJhgyYX7rTsMOS j0SACNiCZqLFg0zw9GZMeJXShHSyLGdLWv8RdNRcA7MykCnJ4rRBfF/duUz1vYa4qGJn iH5/4tboSOwChxup2+WFcNROR7V2jS14Grg7Q7U3jMow1gSDfBTHMM2bHQYf1MPbUmfK d4XlU6FNan/p8wTW1AkD8dm7rS5MMDbGpd/Mihp6xtXPaJ+Xpo7wing2QltJDv5p2Ij/ 7pew== MIME-Version: 1.0 Received: by 10.180.105.69 with SMTP id gk5mr47759582wib.3.1337215725983; Wed, 16 May 2012 17:48:45 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.180.103.228 with HTTP; Wed, 16 May 2012 17:48:45 -0700 (PDT) In-Reply-To: References: <4FA401F7.5060003@extendedsubset.com> <4FB407AA.7050400@gnutls.org> <4FB4187C.9060305@gnutls.org> Date: Thu, 17 May 2012 02:48:45 +0200 X-Google-Sender-Auth: YYIE-teDB_u5rCR04c0UdjKxtHI Message-ID: From: Nikos Mavrogiannopoulos To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 17 May 2012 00:48:47 -0000 On Wed, May 16, 2012 at 11:20 PM, Eric Rescorla wrote: >> This is a denial of service attack that even TLS is vulnerable to. >> A client that doesn't want its identity to be expose it will >> disconnect. This is the same as saying the TLS is insecure because an >> attacker can say to the client please use SSL 2.0. It's up to the >> client to enforce the desired security level. > That's not the security guarantee that TLS generally attempts to > provide, namely the highest common parameters, not the weakest, > which is why there is such extensive protection against > downgrade attacks. Although TLS attempts to negotiate the highest it explicitly mentions that it may not negotiate the strongest shared ciphersuite [0]. I think however that this disagreement is a matter of definition rather than actual disagreement. You assume a user (1) that would like to have his identity hidden, but doesn't really care. I assume a user (2) that doesn't want his identity to be revealed. Indeed this draft does not protect the former user, although it protects the latter under active attacks. In that sense I think it is similar to the TLS promise. It'll try for the best, but cannot guarantee it so one must be prepared to negotiate the weakest supported ciphersuite. [0] "Note that higher layers should not be overly reliant on TLS always negotiating the strongest possible connection between two peers..." > Not anonymous. Server authenticated. >> In the EH protocol this isn't possible >> (unless of course you assume that the client will voluntarily transmit >> its identity in the clear). > Which clients will of course do (or not, but in either case the security > guarantees of renegotiation for the client cert are the same in this > case). Indeed it is a practical solution, but at the cost of an extra handshake (2x round-trips + 2 times DH). > There has been extensive debate about whether NPN actually needs > to be encrypted. I also think that for current uses NPN should have been defined as a typical TLS extension, but there is not a definite answer for everyone. For some uses it may need to be encrypted, and the same is true for every other TLS extension. The reason I support this draft is that I see use-cases where encrypting parts of the handshake makes sense. What I am afraid is the complexity this currently requires due to the required protocol changes. For that I think it would be an advantage of having this work done within the WG rather than having to accept a de facto standard later. regards, Nikos From marsh@extendedsubset.com Wed May 16 21:37:06 2012 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 CB74E21F8644 for ; Wed, 16 May 2012 21:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 zQslJUOqCeRL for ; Wed, 16 May 2012 21:37:06 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id D805B21F8675 for ; Wed, 16 May 2012 21:37:00 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SUsSH-000C3R-IN; Thu, 17 May 2012 04:36:49 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id D175F693F; Thu, 17 May 2012 04:36:45 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18rsl3kMpLtN5RnBbsFWenMpMRuR9T64pU= Message-ID: <4FB48058.9060807@extendedsubset.com> Date: Wed, 16 May 2012 23:36:40 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Eric Rescorla References: <4FA401F7.5060003@extendedsubset.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt 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, 17 May 2012 04:37:07 -0000 On 05/16/2012 12:54 PM, Eric Rescorla wrote: > I understand the general desire to minimize the number > of things exposed to a passive attacker but when one > actually looks at the list of things that are disclosed, > it's not particularly impressive. I feel that way too. But how much of that is simply that we're just conditioned by long experience to accept it? > Unfortunately, much of this data is trivial to observe anyway. > In particular: > > - The session ID and session ticket should both be random and/or > encrypted, so what you really learn is that the client and > server have communicated recently. But you can observe > whether resumption is used merely from message order and size. Straight up: If I fixed all of that too in this or follow-on I-Ds, would you then support it? > - The server's trusted root list isn't any kind of secret But isn't this primarily an effect of current protocol limitations? It doesn't seem like a design principle we should seek to maintain. > and can be trivially elicited just by asking the server > a single time. Not if the server only requests a client under renegotiation triggered by a specific HTTP request unknown to the attacker. Such a server could even serve different lists according to the request. > - You can fingerprint the server actively cheaply, so hiding that > information from a passive attacker doesn't buy you much. Yes, but the active fingerprinting requires the eavesdropper to pay a certain price: He must divulge that he has in fact eavesdropped on some connection to that server and is now following-up with an active fingerprint. This could be very interesting information to the defender under the right circumstances. Sure, there is a background level of port 443 scans occurring over the entire IPv4 address space. But consider a TLS server on a nonstandard port, or in a sparse section of IPv6 address space. Active probing is not always so cheap to the attacker. > - Fingerprinting the client is often possible if it does > any HTTP at all (just based on the client's HTTP headers). Yes, if it does HTTP via a place that the eavesdropper can monitor and associate. For example, an eavesdropper near a server with HSTS is likely to see very little HTTP coming from the latest client apps. > Moreover, the cipher suite list is one of the most > powerful fingerprinting tools and that lives in > ClientHello, not ClientHello2. In practice, the more common sets are sent identically by millions of clients. > This leaves us with SNI and the client's certificate. SNI can often be > inferred passively by examining message length and it's well-known > that you can infer what sites people are visiting by traffic analysis > [0], so the degree of protection that is provided here is distinctly > limited. > [0] Chen, et al., "Side-Channel Leaks in Web Applications: a Realisty > Today, a Challenge Tomorrow", Oakland 2007. > Sen et al, "Statistical Identification of Encrypted Web Browsing Traffic", > Oakland 2002. Those are great papers. They prove that encryption alone does not solve everything. But the existence of even very effective traffic analysis does not seem a good argument for sending plaintext when it could be sent encrypted instead. - Marsh From marsh@extendedsubset.com Thu May 17 12:52:39 2012 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 ACFB821F86AB for ; Thu, 17 May 2012 12:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 F6U5ZnelM645 for ; Thu, 17 May 2012 12:52:38 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id CC69921F8686 for ; Thu, 17 May 2012 12:52:38 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SV6kY-0007Ls-6l; Thu, 17 May 2012 19:52:38 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 49C7D631F; Thu, 17 May 2012 19:52:37 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+YeSpA3+x08uZnI+/DDG8tkwUqcS/F9I0= Message-ID: <4FB55702.3090408@extendedsubset.com> Date: Thu, 17 May 2012 14:52:34 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Nikos Mavrogiannopoulos 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] Preventing cross-protocol attacks in TLS protocol 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, 17 May 2012 19:52:39 -0000 On 05/16/2012 06:56 AM, Nikos Mavrogiannopoulos wrote: > Hello, > I've submitted a proposal on how to prevent attacks similar in nature > with the Wagner and Schneier's one, at: > http://www.ietf.org/id/draft-mavrogiannopoulos-tls-server-key-exchage-00.txt > > Please consider adopting this or any other protection for the protocol. I think this is a good robustness improvement to the protocol and may bring other benefits. I actually considered including a very similar change in draft-ray-encrypted-handshake, but did not do so primarily due to scope. However, draft-mavrogiannopoulos-tls-server-key-exchage does not protect against the attack described. Thankfully, all evidence points to this attack being impractical with all current clients. But let us consider a hypothetical client and server which in combination are vulnerable to this SKE-switcheroo attack. The severity of the attack is such that the MitM is able to obtain the client-side premaster secret and is therefore able to impersonate the legitimate server. This must be the case or else the client would detect the change in the accepted cipher suite when the client validates the server's Finished message. But if the MitM can get away with convincing the client that the legitimate server selected a different cipher suite, he can just as easily convince the client that the server does not support draft-mavrogiannopoulos-tls-server-key-exchage. Client certs introduce a signature over the same handshake messages but don't mitigate the attack either. The attacker can simply not request one from the client or ignore the one that is sent. Opt-in schemes usually don't work very well for strengthening authentication. Nevertheless, if future extensions, key exchange methods, and/or TLS versions were to require this protocol change it could be quite useful. It could allow a client to authenticate the server at the point of the SKE message. This could enable him to transmit the client cert, NP(N), and other RFC 4680 messages under Encrypted Handshake secure even from active attacks. It could also enable the client to be secure in starting falsely the sending of an application data record. Again I think this SKE change is a useful improvement, but only in conjunction with some other extension that benefits from the client resisting active attacks before the server Finished. So I don't see much value in negotiating it independently with its own separate extension. Perhaps I am missing something. - Marsh P.S. While we're on the subject of this attack, we need to remember that server support for any new key exchange method could instantly make this attack practical. New key exchange methods MUST either require this improved SKE or they MUST have a ServerXParams format that is believed to be rejected by all current and future clients for all key exchange types. E.g., leading with a fixed number of 0x00 bytes might work. From nico@cryptonector.com Thu May 17 13:24:20 2012 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 2151021F87E6 for ; Thu, 17 May 2012 13:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 VIpemOMiENuN for ; Thu, 17 May 2012 13:24:19 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 8988C21F87E1 for ; Thu, 17 May 2012 13:24:19 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 6033F1005D for ; Thu, 17 May 2012 13:24:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=X3f7C6gg/SH1CwajpSo/u IbOBzMJfaUz+mh+c2b2SyFQGdH+fSoyWJb+pDftwqt+pkypw1av00y20bOx9FRG/ 8oa+JECn6KuKo+9Rk+KZJX/udLQN7rBrD7wy86iPWhU9xCuV659Dd8rM9ePwo+ek dU+GL0M32WJFgVh5S5fUfA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=OKnzkANp8RQK7z1l/Nus x4UZHQg=; b=herIdQnHuhi0duUU3pqCpkXM+1t80klEvJmHmwN4ru/7nTNIriQP iJLODiNZH2egtIpORzVN0qau6QelIm4w5AMcwiVvcI12bAsZ8tof2XbuiGNH1VMP XssaPYOFjJ5x16Zo/idxt9k3A+tYYqtUJkgSALsFX4Wqk07E5i+dnSg= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 4420810049 for ; Thu, 17 May 2012 13:24:19 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so3079479pbc.31 for ; Thu, 17 May 2012 13:24:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.204.2 with SMTP id ku2mr30938544pbc.55.1337286258952; Thu, 17 May 2012 13:24:18 -0700 (PDT) Received: by 10.68.5.99 with HTTP; Thu, 17 May 2012 13:24:18 -0700 (PDT) In-Reply-To: <4FB55702.3090408@extendedsubset.com> References: <4FB55702.3090408@extendedsubset.com> Date: Thu, 17 May 2012 15:24:18 -0500 Message-ID: From: Nico Williams To: Marsh Ray Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] Preventing cross-protocol attacks in TLS protocol 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, 17 May 2012 20:24:20 -0000 On Thu, May 17, 2012 at 2:52 PM, Marsh Ray wrote: > On 05/16/2012 06:56 AM, Nikos Mavrogiannopoulos wrote: > > [...] > > I think this is a good robustness improvement to the protocol and may bring > other benefits. I actually considered including a very similar change in > draft-ray-encrypted-handshake, but did not do so primarily due to scope. > > However, draft-mavrogiannopoulos-tls-server-key-exchage does not protect > against the attack described. > > [great explanation elided] To fix this in a way that resists downgrade attacks methinks you'll need a certificate extension by which to indicate that the server supports the new SKE. Then the client can send the TLS extension in its ClientHello, the server sends the new SKE, and if the MITM tries to play any funny games [*] the client will know it from the server's cert. [*] Stripping this extension, pasting an SKE intended for an old client, working out the downgraded key exchange's output, then making the Finished messages come out. Nico -- From n.mavrogiannopoulos@gmail.com Thu May 17 14:22:05 2012 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 8C7D621F873A for ; Thu, 17 May 2012 14:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 MXjT9IsRBpyl for ; Thu, 17 May 2012 14:22:04 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC92A21F870F for ; Thu, 17 May 2012 14:22:03 -0700 (PDT) Received: by eaaq13 with SMTP id q13so684534eaa.31 for ; Thu, 17 May 2012 14:22:02 -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:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=6jJLYt/+Xusj/8hbTvARF/Ba/ajzdw3OqkAKUqYNvdc=; b=LD6od6uknf6E6n8zQrobZGjX9Lchs19DkqptjNzfloLzJM8nf4kjAIgPBKcnAyC7Xp K+IXzzjoBSzlPy6MKPrsDdZTSlIRfbSGt1bmml6WRn43mMiRwGneP1pN8/4B9e4ixzsi OPKx2zkBwB2OpL4vGX/ru9PPxmqo4ePCILpJOobGF6CutNW4qObQ01mhyVv5Fh8WIJXR fJkY9/w9u6zHp/i1qlPQo5x5kTMgSNKjQnAopTu+dQD0NBU0OUIJoYL72CuqWHa7TFLF vm6KOz4STSTIu8skNRKWNsc2s2JAPqeLdyVE7+fRxlLcJUJCvhyEoE+0wHd+qh60yfOY wx7Q== Received: by 10.213.32.82 with SMTP id b18mr2520262ebd.83.1337289722778; Thu, 17 May 2012 14:22:02 -0700 (PDT) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id v7sm34749102eem.6.2012.05.17.14.22.01 (version=SSLv3 cipher=OTHER); Thu, 17 May 2012 14:22:02 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4FB56BF9.5060005@gnutls.org> Date: Thu, 17 May 2012 23:22:01 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: Marsh Ray References: <4FB55702.3090408@extendedsubset.com> In-Reply-To: <4FB55702.3090408@extendedsubset.com> X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Preventing cross-protocol attacks in TLS protocol 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, 17 May 2012 21:22:05 -0000 On 05/17/2012 09:52 PM, Marsh Ray wrote: > However, draft-mavrogiannopoulos-tls-server-key-exchage does not protect > against the attack described. > > Thankfully, all evidence points to this attack being impractical with > all current clients. But let us consider a hypothetical client and > server which in combination are vulnerable to this SKE-switcheroo attack. > > The severity of the attack is such that the MitM is able to obtain the > client-side premaster secret and is therefore able to impersonate the > legitimate server. This must be the case or else the client would detect > the change in the accepted cipher suite when the client validates the > server's Finished message. But if the MitM can get away with convincing > the client that the legitimate server selected a different cipher suite, > he can just as easily convince the client that the server does not > support draft-mavrogiannopoulos-tls-server-key-exchage. Hello, This is the same issue as in the TLS version and protocol negotiation. Even if both peers support TLS 1.2 but they are willing to accept SSL 3.0, then they may end up using it if it has a vulnerability. The same in this case. All TLS protocol versions are vulnerable unless this extension is sent. Thus a client has to require this extension to be present to prevent cross protocol attacks. regards, Nikos From geoffk@geoffk.org Thu May 17 14:34:28 2012 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 45B2F21F876F for ; Thu, 17 May 2012 14:34: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 MLf+A4GcnA19 for ; Thu, 17 May 2012 14:34:27 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id D729721F8783 for ; Thu, 17 May 2012 14:34:27 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 969D533D0A9; Thu, 17 May 2012 21:34:24 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Nikos Mavrogiannopoulos References: <4FB55702.3090408@extendedsubset.com> <4FB56BF9.5060005@gnutls.org> From: Geoffrey Keating Date: 17 May 2012 14:34:24 -0700 In-Reply-To: <4FB56BF9.5060005@gnutls.org> Message-ID: Lines: 33 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] Preventing cross-protocol attacks in TLS protocol 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, 17 May 2012 21:34:28 -0000 Nikos Mavrogiannopoulos writes: > On 05/17/2012 09:52 PM, Marsh Ray wrote: > > > However, draft-mavrogiannopoulos-tls-server-key-exchage does not protect > > against the attack described. > > > > Thankfully, all evidence points to this attack being impractical with > > all current clients. But let us consider a hypothetical client and > > server which in combination are vulnerable to this SKE-switcheroo attack. > > > > The severity of the attack is such that the MitM is able to obtain the > > client-side premaster secret and is therefore able to impersonate the > > legitimate server. This must be the case or else the client would detect > > the change in the accepted cipher suite when the client validates the > > server's Finished message. But if the MitM can get away with convincing > > the client that the legitimate server selected a different cipher suite, > > he can just as easily convince the client that the server does not > > support draft-mavrogiannopoulos-tls-server-key-exchage. > > > Hello, > This is the same issue as in the TLS version and protocol negotiation. > Even if both peers support TLS 1.2 but they are willing to accept SSL > 3.0, then they may end up using it if it has a vulnerability. The same > in this case. All TLS protocol versions are vulnerable unless this > extension is sent. Thus a client has to require this extension to be > present to prevent cross protocol attacks. Isn't that actually caused by this very attack? There is a version field in PreMasterSecret, sent in the non-DH cases when no ServerKeyExchange is needed, but there is no version field signed in ServerKeyExchange. From n.mavrogiannopoulos@gmail.com Fri May 18 00:25:47 2012 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 1E4CE21F863F for ; Fri, 18 May 2012 00:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 8gfKQYJCSn-q for ; Fri, 18 May 2012 00:25:44 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B7F5021F8505 for ; Fri, 18 May 2012 00:25:43 -0700 (PDT) Received: by eaaq13 with SMTP id q13so758257eaa.31 for ; Fri, 18 May 2012 00:25:43 -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:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=rKrxzGkZCfL3oKCKdgmSHxRvylyK5HjIErh70gcgl4E=; b=cfqwA8qmAloTALU1vitGo5PojG6N758TQHt8SjCBUby+tKGOmOvuJV/YXgP8zOy/J6 RNYt0F4hQxRA+AJpVKHb1QPliJ+9dC0XzrdQdkwp42Sem/Y7Og+VdCH4TN5B+3i46abK 7/KfoV2wR26R6RM7/BRDdX2XUT98fV4+ifAok5HRpDIggno0wcVFg67vGu7DA+/jwgI+ e8gP3cuUlGMj8oLXyanlx8CYst6rMuTURtk7moYmGsnQas7GuGuWp3+QbP8qF8lyFGvI i108Knak2JHwyVzHepFtMG0B6M1OoAaqjHOwNs5yrRXwXL/hyjvvKKsiz538xdYKP7Xl IEzA== Received: by 10.213.35.196 with SMTP id q4mr2778610ebd.25.1337325942876; Fri, 18 May 2012 00:25:42 -0700 (PDT) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id u7sm32957546eeb.7.2012.05.18.00.25.41 (version=SSLv3 cipher=OTHER); Fri, 18 May 2012 00:25:41 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4FB5F96F.4010000@gnutls.org> Date: Fri, 18 May 2012 09:25:35 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: Marsh Ray References: <4FB55702.3090408@extendedsubset.com> <4FB56BF9.5060005@gnutls.org> In-Reply-To: <4FB56BF9.5060005@gnutls.org> X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Preventing cross-protocol attacks in TLS protocol 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, 18 May 2012 07:25:47 -0000 On 05/17/2012 11:22 PM, Nikos Mavrogiannopoulos wrote: >> The severity of the attack is such that the MitM is able to obtain the >> client-side premaster secret and is therefore able to impersonate the >> legitimate server. This must be the case or else the client would detect >> the change in the accepted cipher suite when the client validates the >> server's Finished message. But if the MitM can get away with convincing >> the client that the legitimate server selected a different cipher suite, >> he can just as easily convince the client that the server does not >> support draft-mavrogiannopoulos-tls-server-key-exchage. > This is the same issue as in the TLS version and protocol negotiation. > Even if both peers support TLS 1.2 but they are willing to accept SSL > 3.0, then they may end up using it if it has a vulnerability. The same > in this case. All TLS protocol versions are vulnerable unless this > extension is sent. Thus a client has to require this extension to be > present to prevent cross protocol attacks. There is something (a hack) that can be done to ensure detection by the server of a conformant client, in the case of an active adversary. That is to add a magic number in the client nonce, or to replace the timestamp with a magic value. This would reduce the available entropy, but ensure that a conformant server will notice the support of the new format, even if the adversary removes the extension from the client hello. regards, Nikos From agl@google.com Mon May 21 14:36:11 2012 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 CE1B621F8554 for ; Mon, 21 May 2012 14:36:11 -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 iNDFpDPm2x-G for ; Mon, 21 May 2012 14:36:11 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4614721F8551 for ; Mon, 21 May 2012 14:36:11 -0700 (PDT) Received: by ggnc4 with SMTP id c4so5678519ggn.31 for ; Mon, 21 May 2012 14:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=sEOBqK+2bS5bltsOkoRmEZkufTp9gBP45dwIBERSO7U=; b=TqDAU+A+4EwDALE3JG6BQIWEsWNWpUlj0jzs1glqeX8wMq8DW2mQqloJ+lBYRBPECL L1VhjZOJZOqdEZOAOOX1zEMrPRlFfqk48D3YVRxrkPKqdwkBm6h+TX5muyZZtv0T1TrT FDblxRM7ouBhsPDRS7i7wDpeqm00aw+eUBKoxyh4NHv6jU2RSkfaAOFQko187GonjwET 6vwLRILw5NBrB0ZJV7ZqWCsMaW2OMKHQslFAufVu0sL+G/+no/z1X4QQTM/GOh1PSTd+ 3PjviSy0i3cUsiCzvnfXzkQ4h+JpLssdG+qyxta3MZ7cbRuKKot8OXCyUK5ndWMxn3YJ DuPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=sEOBqK+2bS5bltsOkoRmEZkufTp9gBP45dwIBERSO7U=; b=iCara2Ttxq/iH0pBOxkX058Itc1PJsvIKJhSVWG/rzGqcjNw8GHSZcttjaQXV3HJ8I 90ND3dDB1eY5XUT5TIY+CAZ0K1Skc+3piBfNv31uxLJpHASec5gUb8TiGVJ68qDEsen3 dpI3z6cf4k/1PWz6TFeY3fmI/5eyL3N7+hbfTFY9aEllYbRb/p0Vh6HQ11ozKSKb6gHy f0e8hs8v8NxBCrs6MhXRBUVfYBLBpUlF3sfB4ZKDZOOGVviWPzO1NZkL8ss12Ngp34QK QNv8v+Tzm20qaedITvAePhiqGW7eyL+k/OkmNT4Cyb1gx7sWKLEMPGWZ8oVF16qQzZF9 Sodg== Received: by 10.50.185.233 with SMTP id ff9mr7816991igc.57.1337636170433; Mon, 21 May 2012 14:36:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.185.233 with SMTP id ff9mr7816984igc.57.1337636170314; Mon, 21 May 2012 14:36:10 -0700 (PDT) Sender: agl@google.com Received: by 10.231.112.136 with HTTP; Mon, 21 May 2012 14:36:10 -0700 (PDT) In-Reply-To: References: <4F9981FC.4000205@extendedsubset.com> <201204261721.q3QHL0lA014062@fs4113.wdf.sap.corp> Date: Mon, 21 May 2012 17:36:10 -0400 X-Google-Sender-Auth: 1oejKhrPUtedy2jEhJ0ykZmKCiY Message-ID: From: Adam Langley To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmynzEt5mD7bGO9gZFFy8pmkhbwRSQ9CRAZkT7mNq2U0r1/EzBfy9bQuh/PjbZA9LHn276FK4zX0G143PR+ArC0B+I5HvpG3Om3hJprAk4BdfTG4rz0unaRNzyQX4l/kmUhDf5l Cc: tls@ietf.org Subject: Re: [TLS] Next Protocol Negotiation 03 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, 21 May 2012 21:36:11 -0000 On Thu, Apr 26, 2012 at 1:29 PM, Adam Langley wrote > So, in short, "still thinking". I've respun the draft in order to change the NextProtocol message into an EncryptedExtensions message which has the same format as the extension block in the hello messages. Everything else is the same. This allows the client's protocol selection to remain under encryption. The server's list of protocols is still in the clear, but that can be fixed via an orthogonal change like Marsh's encrypted handshake. https://tools.ietf.org/html/draft-agl-tls-nextprotoneg-04 Cheers AGL From marsh@extendedsubset.com Mon May 21 15:57:31 2012 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 A3CE621F85B9 for ; Mon, 21 May 2012 15:57:31 -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 05-EDGam7FkF for ; Mon, 21 May 2012 15:57:31 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB2121F858F for ; Mon, 21 May 2012 15:57:31 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SWbXe-0000PU-Oe; Mon, 21 May 2012 22:57:30 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 256506085; Mon, 21 May 2012 22:57:29 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+pMrkAbj0JDp4yfNPlJzUjYl0azQN4J+w= Message-ID: <4FBAC851.8090305@extendedsubset.com> Date: Mon, 21 May 2012 17:57:21 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Adam Langley References: <4F9981FC.4000205@extendedsubset.com> <201204261721.q3QHL0lA014062@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Next Protocol Negotiation 03 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, 21 May 2012 22:57:31 -0000 On 05/21/2012 04:36 PM, Adam Langley wrote: > On Thu, Apr 26, 2012 at 1:29 PM, Adam Langley wrote >> So, in short, "still thinking". > > I've respun the draft in order to change the NextProtocol message into > an EncryptedExtensions message which has the same format as the > extension block in the hello messages. Everything else is the same. > > This allows the client's protocol selection to remain under > encryption. The server's list of protocols is still in the clear, but > that can be fixed via an orthogonal change like Marsh's encrypted > handshake. > > https://tools.ietf.org/html/draft-agl-tls-nextprotoneg-04 That's seems like a cleaner version of the same approach. Now we can drop the parenthesis in "NP(N)"! If it's intended to be usable by more than just NPN, perhaps it should be described in a separate document? It does seem to raise the same discussion about resistance to active mischief that we've been going over for draft-ray-tls-encrypted-handshake and draft-mavrogiannopoulos-tls-server-key-exchage. It would be really nice to get these considerations addressed in one or some small set of docs. - Marsh From wtc@google.com Mon May 21 17:13:00 2012 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 3659621F854A for ; Mon, 21 May 2012 17:13:00 -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 lDDmNmCRduMR for ; Mon, 21 May 2012 17:12:59 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECA021F84FD for ; Mon, 21 May 2012 17:12:59 -0700 (PDT) Received: by ghbg16 with SMTP id g16so700144ghb.31 for ; Mon, 21 May 2012 17:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=sBDm37CtCj4xnyWimC+t1FPbYsgE2BHt3XQU03672Ic=; b=NneMBXn+nSI4vpKAXa3DXpdB7lITYsviigJAUpoHamfc9J9dz8X9iggMVse2puETcQ oNpqpSzawneV5hQbsSGFX5dUnWxoVQ/+Im2ZlkLKaWFmR8lxUAOXSL6ClVy6iHmn3KFe zCHsglMIRkYNEnnnfFjPNsPP8Pl5aeF8824EmSnWu480oSGOWizlgEcvbmc/1sLoo6pG 3jBVFxp5gPgYqx+W1i+8RuqVc5hLxyG7/5tMgnl6c2R8F+c/PMbf8/9hrpbA3qRuQAkh +UKkNAguAm1UT99VQSCtg1LNkwp3yIh91yuGkpp+mVb5beUadcQ2xk+qyF94Yu68kw66 QSqw== 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-system-of-record :x-gm-message-state; bh=sBDm37CtCj4xnyWimC+t1FPbYsgE2BHt3XQU03672Ic=; b=DPqxJUMtUVdr/lHCQ6OgrtPwfSZyd5OocPWe2BVhoX7HY5Eu/EcyEzEPaErL7gu5zQ E0TUfURNzzT1wn8qGQQ7LYdbObGQVvgco2KL2HMCJtngsRT+VXOZIOPYhr3kEbbsgfIN FbkWJ6WuNIsxGg8EoC4CPvS3s1ZmapR5gtCfDp3IAwpxEOM7r6hA3Hi1aKzqhd6KMVX5 Qo0wonSp5UYHeXxDScn+ZMYbi/13RADTNDPEY7E8RdWYylgPaZCunjSltgHQR1dGi7bL z0JFkkQq8cAWlkSfymQQ9kk2ke2a9Jm/Y4ziiJbs7IpHSMAfXnVPh4MEFNG5RDggzU9G IClQ== Received: by 10.50.94.133 with SMTP id dc5mr8165943igb.16.1337645578778; Mon, 21 May 2012 17:12:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.94.133 with SMTP id dc5mr8165934igb.16.1337645578630; Mon, 21 May 2012 17:12:58 -0700 (PDT) Received: by 10.231.122.204 with HTTP; Mon, 21 May 2012 17:12:58 -0700 (PDT) In-Reply-To: <4FBAC851.8090305@extendedsubset.com> References: <4F9981FC.4000205@extendedsubset.com> <201204261721.q3QHL0lA014062@fs4113.wdf.sap.corp> <4FBAC851.8090305@extendedsubset.com> Date: Mon, 21 May 2012 17:12:58 -0700 Message-ID: From: Wan-Teh Chang To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQmQjDOrjKPLMsEvn8MspLt7nzRhVlyYjdA6oboDKF1yWTdrEOjBD2N0WL4iFC53QbABhLxkVGm752kkMCmSMxWsZ19mbznF6cXd7WaP7Q/SQjItDZUqjnIgFMjoBR56hFD5NkQR Cc: Adam Langley , tls@ietf.org Subject: Re: [TLS] Next Protocol Negotiation 03 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, 22 May 2012 00:13:00 -0000 On Mon, May 21, 2012 at 3:57 PM, Marsh Ray wrote= : > On 05/21/2012 04:36 PM, Adam Langley wrote: >> >> On Thu, Apr 26, 2012 at 1:29 PM, Adam Langley =A0wrote >>> >>> So, in short, "still thinking". >> >> >> I've respun the draft in order to change the NextProtocol message into >> an EncryptedExtensions message which has the same format as the >> extension block in the hello messages. Everything else is the same. >> >> This allows the client's protocol selection to remain under >> encryption. The server's list of protocols is still in the clear, but >> that can be fixed via an orthogonal change like Marsh's encrypted >> handshake. >> >> https://tools.ietf.org/html/draft-agl-tls-nextprotoneg-04 > > That's seems like a cleaner version of the same approach. Yes. The EncryptedExtensions handshake message can also be used by other extensions that are negotiated in a three-step, half-encrypted manner. It avoids a proliferation of new handshake messages for these extensions and the need to specify an order between them. > Now we can drop the parenthesis in "NP(N)"! Could you explain the different between "NPN" and "NP(N)"? Thanks. > If it's intended to be usable by more than just NPN, perhaps it should be > described in a separate document? I agree. Wan-Teh From marsh@extendedsubset.com Mon May 21 18:31:25 2012 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 1A97921F8575 for ; Mon, 21 May 2012 18:31:25 -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 PeeCazJqMzYp for ; Mon, 21 May 2012 18:31:24 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4E621F8569 for ; Mon, 21 May 2012 18:31:24 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SWdwZ-000Avp-Hw; Tue, 22 May 2012 01:31:23 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 588A16085; Tue, 22 May 2012 01:31:22 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX195Y7KgnF6Tef5hcRZJlMi3J38zE/UHLb0= Message-ID: <4FBAEC63.9030808@extendedsubset.com> Date: Mon, 21 May 2012 20:31:15 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Wan-Teh Chang References: <4F9981FC.4000205@extendedsubset.com> <201204261721.q3QHL0lA014062@fs4113.wdf.sap.corp> <4FBAC851.8090305@extendedsubset.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Langley , tls@ietf.org Subject: Re: [TLS] Next Protocol Negotiation 03 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, 22 May 2012 01:31:25 -0000 On 05/21/2012 07:12 PM, Wan-Teh Chang wrote: > On Mon, May 21, 2012 at 3:57 PM, Marsh Ray wrote: > >> Now we can drop the parenthesis in "NP(N)"! > > Could you explain the different between "NPN" and "NP(N)"? Thanks. It's a trivial thing but the extension is Next Protocol Negotiation and the former handshake message was Next Protocol. The proposal had also switched between those names at one point. >> If it's intended to be usable by more than just NPN, perhaps it should be >> described in a separate document? > > I agree. It's a shame that RFC 4680 'TLS Handshake Message for Supplemental Data' couldn't be used for this, it even has a 2 byte 'type' enum which could perhaps map easily to extension types. But its RFC is quite specific about its position in the handshake. Perhaps something of it can be built upon. - Marsh From wtc@google.com Tue May 22 10:47:48 2012 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 3249F21F861B for ; Tue, 22 May 2012 10:47:48 -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 LEB13SjVSWTC for ; Tue, 22 May 2012 10:47:47 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2C27021F8606 for ; Tue, 22 May 2012 10:47:47 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1040976ghb.31 for ; Tue, 22 May 2012 10:47:46 -0700 (PDT) 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-system-of-record; bh=Ad/zQniACtpmWRTYtadmCpBYpvp5ehVVhXd2UM5Pvug=; b=IKT66gQ9qOoy+WrB2XNEjMTqcI40/OftMj3IBS427wrI/Wv2EwiBVyeUSfijCZFCLb T7uohDaxcZgLokSI46N2tnVU50y96u3k032Cut4C2LnkPND4cpB7QVH8pFxCUgTZWX06 i7YuKLpAZ18qDDI/R7hU/PcGVJ4z83gvVxyC19PFKJ8RjqGmWD5Y3hKXhSxfqIGMIJgJ teQcTpVjtZbLbGLjbxCZCA4eyT9MKDvUJHhyEfDMWfCwjiXKacFKylfVeW2Qa8S8/gP8 fXJHF8aesZv75WTP35wXn4kFaARWTVCNLzP9EDY+AfY5XW5X0cimGy/dmSxTA0kQ50p9 hXuQ== 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-system-of-record:x-gm-message-state; bh=Ad/zQniACtpmWRTYtadmCpBYpvp5ehVVhXd2UM5Pvug=; b=lX/Mi749HZK24gCtfy+L/BHoP/eCEJIYecc08pzKkrM86MNGNoTBENabAlUMX9w7F+ JeXjwuC/Mcjbuy4U4tBJxDySi45/hu7yqACRgt63SXhoumE/as6159/C+4ll3FcQMkvq +mMeKxJrcSNlS/FNKKBU4SMHP4oDQCGnCvSDVHQqRqn9hpSWcXF9O68ZazrlL4fiwboH Ng2dTmF396olAjwOaSFi2FbsQkBwtDVWFTSzx5YGmtX8Qpm8uwu5T0R2+u12pWRq5Gmg FgjyyCjqeezQTYHaisdOmz0HT31wHoK0YT2QBFbqL78pamDk+qpoPVZUULC/hCnouTBP IJWQ== Received: by 10.42.97.196 with SMTP id p4mr10826189icn.22.1337708866552; Tue, 22 May 2012 10:47:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.97.196 with SMTP id p4mr10826183icn.22.1337708866460; Tue, 22 May 2012 10:47:46 -0700 (PDT) Received: by 10.231.122.204 with HTTP; Tue, 22 May 2012 10:47:46 -0700 (PDT) In-Reply-To: <4FBAEC63.9030808@extendedsubset.com> References: <4F9981FC.4000205@extendedsubset.com> <201204261721.q3QHL0lA014062@fs4113.wdf.sap.corp> <4FBAC851.8090305@extendedsubset.com> <4FBAEC63.9030808@extendedsubset.com> Date: Tue, 22 May 2012 10:47:46 -0700 Message-ID: From: Wan-Teh Chang To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlyJRq7HbpWfa6L/RMcxaqSpBx5zEzkJ0vvPdk6i4k5pcbHhJYoBiCHBnOTH1V1S2qwxnELPBlfIi/6yIp1QNx4dpYra1oecVPpnY8fnfeQsjdy3BW612kMYuC7MFLHytNSr3ei Cc: Adam Langley , tls@ietf.org Subject: Re: [TLS] Next Protocol Negotiation 03 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, 22 May 2012 17:47:48 -0000 On Mon, May 21, 2012 at 6:31 PM, Marsh Ray wrote: > > It's a shame that RFC 4680 'TLS Handshake Message for Supplemental Data' > couldn't be used for this, it even has a 2 byte 'type' enum which could > perhaps map easily to extension types. But its RFC is quite specific about > its position in the handshake. Perhaps something of it can be built upon. I'm wondering why you're interested in using the SupplementalData handshake message. SupplementalData is sent immediately before the Certificate handshake message, so it is not encrypted in the initial handshake. It cannot replace the proposed EncryptedExtensions handshake message without amending RFC 4680. Wan-Teh From mrex@sap.com Tue May 22 10:57:25 2012 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 9D56D21F85EF for ; Tue, 22 May 2012 10:57:25 -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 xY-DL0zWDf-8 for ; Tue, 22 May 2012 10:57: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 CB06C21F85EA for ; Tue, 22 May 2012 10:57:24 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q4MHvJaD025064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 22 May 2012 19:57:19 +0200 (MEST) From: Martin Rex Message-Id: <201205221757.q4MHvIFO000482@fs4113.wdf.sap.corp> To: wtc@google.com (Wan-Teh Chang) Date: Tue, 22 May 2012 19:57:18 +0200 (MEST) In-Reply-To: from "Wan-Teh Chang" at May 22, 12 10:47:46 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: agl@chromium.org, tls@ietf.org Subject: Re: [TLS] Next Protocol Negotiation 03 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, 22 May 2012 17:57:25 -0000 Wan-Teh Chang wrote: > > On Mon, May 21, 2012 at 6:31 PM, Marsh Ray wrote: > > > > It's a shame that RFC 4680 'TLS Handshake Message for Supplemental Data' > > couldn't be used for this, it even has a 2 byte 'type' enum which could > > perhaps map easily to extension types. But its RFC is quite specific about > > its position in the handshake. Perhaps something of it can be built upon. > > I'm wondering why you're interested in using the SupplementalData > handshake message. SupplementalData is sent immediately before the > Certificate handshake message, so it is not encrypted in the initial > handshake. It cannot replace the proposed EncryptedExtensions > handshake message without amending RFC 4680. The logical extension of RFC 4680 would be to define another new pair of TLS handshake messages (EncryptedSupplementalData) with the same internal structure, that go between CCS and Finished. -Martin From marsh@extendedsubset.com Tue May 22 12:33:06 2012 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 7BF4E21F8577 for ; Tue, 22 May 2012 12:33:06 -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 vb4jRhvDE5xk for ; Tue, 22 May 2012 12:33:06 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 00E7C21F8570 for ; Tue, 22 May 2012 12:33:06 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SWupN-000D36-4W; Tue, 22 May 2012 19:33:05 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 067706081; Tue, 22 May 2012 19:33:04 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19aoDaXIB3nnXGsbO1gAUBsalQqBj9xqJ8= Message-ID: <4FBBE9E8.2050004@extendedsubset.com> Date: Tue, 22 May 2012 14:32:56 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Wan-Teh Chang References: <4F9981FC.4000205@extendedsubset.com> <201204261721.q3QHL0lA014062@fs4113.wdf.sap.corp> <4FBAC851.8090305@extendedsubset.com> <4FBAEC63.9030808@extendedsubset.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Langley , tls@ietf.org Subject: Re: [TLS] Next Protocol Negotiation 03 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, 22 May 2012 19:33:06 -0000 On 05/22/2012 12:47 PM, Wan-Teh Chang wrote: > > I'm wondering why you're interested in using the SupplementalData > handshake message. Simply because it's already mostly specified. > SupplementalData is sent immediately before the > Certificate handshake message, so it is not encrypted in the initial > handshake. It cannot replace the proposed EncryptedExtensions > handshake message without amending RFC 4680. Would it be better to amend an RFC in order to re-use an existing structure in a different place, or to define a new handshake message? If the structure were very complex, I think most of us would say the former. But this is a trivial wrapper structure so it probably doesn't make much difference. - Marsh From benl@google.com Wed May 23 04:02:43 2012 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 6EAA121F8577 for ; Wed, 23 May 2012 04:02:43 -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 sZ+wLli+26Ab for ; Wed, 23 May 2012 04:02:43 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDAD21F85C4 for ; Wed, 23 May 2012 04:02:42 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so5802271lbb.31 for ; Wed, 23 May 2012 04:02:41 -0700 (PDT) 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-system-of-record; bh=/jnVMhsJZILVJGTmlq9agZ5ijzwHyWLt27+d2ZNOeJU=; b=Gde5UYreBy82d+DuN9IhbiC5Hf2Z49JzbDu4cQbC3pImR4F3E340sOxa8NkwxjwrUE PM77mRRhzIEcNlLtWrZkA7zSHm3zB/qphWpq2s+b0HzlP358UgM1+n2OojcCr8eipC6u +bVxkN8/7zTPNNDQorz2Sg/KF/bW2q48EfEi0wqUOqUtzVIhrwxj0CLdjob4lmZ+W+of mvbfoIMOY/hQU8/5P7iVO30c5hgXLbrFN657/r1wAT5rT2jIcUUBMlWTU1tUSIcHcNSy YR6QLCKfoSF4uiOt8+00csJbOE2nwINnj5Z8WT3mjxU/2zTgeKNmqLoyo4TqTIdqifsg tGYg== 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-system-of-record:x-gm-message-state; bh=/jnVMhsJZILVJGTmlq9agZ5ijzwHyWLt27+d2ZNOeJU=; b=isglE0F7z3mbKjRP5hVTfJyUzQPWgnKZMmsgmJkV5LgzhECnxJoTdeHurCIBcdm6mR oqE8bdyFVGQF1VzQWvT+V3GLjIA+hKoNMgXKI0JKxO6A/9MAGAChwIKssdjgreIY7Kbj ixtHQSaGQ83u9vJcIVsoV6q2uhBnnk7uymJpFbaPRP9znS/x6YF2cb/3Pnfykz27TmWa ptMCC6Wtpi34j3y4YKSRL1uNlm5Vk6jKgsMJIrXFo0Qq8WjLSUyIL65HPADBLgxWAnWS 8iMs4sNcWGpPnUBLmtcNB8Y3WhQNDNi9JZ27B6dsXKHrglBB1ikApBTMtc/SIK8LuPu0 Ulhg== Received: by 10.152.108.178 with SMTP id hl18mr26604040lab.11.1337770961485; Wed, 23 May 2012 04:02:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.108.178 with SMTP id hl18mr26604027lab.11.1337770961326; Wed, 23 May 2012 04:02:41 -0700 (PDT) Received: by 10.112.66.136 with HTTP; Wed, 23 May 2012 04:02:41 -0700 (PDT) In-Reply-To: <4FBBE9E8.2050004@extendedsubset.com> References: <4F9981FC.4000205@extendedsubset.com> <201204261721.q3QHL0lA014062@fs4113.wdf.sap.corp> <4FBAC851.8090305@extendedsubset.com> <4FBAEC63.9030808@extendedsubset.com> <4FBBE9E8.2050004@extendedsubset.com> Date: Wed, 23 May 2012 12:02:41 +0100 Message-ID: From: Ben Laurie To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmi2melxECx3UASk4NFPHST6YT8bmYW/1c4QigSfqpuntudltcOyPXH8bTdoL00RogEazXz0CuMqx3CgmNSxUoEfs4xnL7JWNsRZ1dJckkx5rRbnw5SIC78oZDjpKbeR5j8NA/k Cc: Adam Langley , tls@ietf.org Subject: Re: [TLS] Next Protocol Negotiation 03 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, 23 May 2012 11:02:43 -0000 On 22 May 2012 20:32, Marsh Ray wrote: > On 05/22/2012 12:47 PM, Wan-Teh Chang wrote: >> >> >> I'm wondering why you're interested in using the SupplementalData >> handshake message. > > > Simply because it's already mostly specified. We're adding support to OpenSSL at the moment :-) We plan to use it for Certificate Transparency. From trevp@trevp.net Wed May 23 06:57:35 2012 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 7F18321F86C1 for ; Wed, 23 May 2012 06:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 CHJLZgyBCrRW for ; Wed, 23 May 2012 06:57:34 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 684D321F86C5 for ; Wed, 23 May 2012 06:57:34 -0700 (PDT) Received: by lagv3 with SMTP id v3so5935763lag.31 for ; Wed, 23 May 2012 06:57:29 -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:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=ZqtzLMyZ/neXMJhKeWuF4clT5RjEgIpJdQS8wMfKCFk=; b=nngd8kPvgU5ZTrTwVCy56qGR9AwS8cSbHugErbLWEoFXB0ve3Qg1XGpVAZzf6GJ8LK k2sYI9W8Fz+C2w8k+e5Wk/n9tW1AKb8uF4c7dRQobgjisolasTHe055Cy0HWg11YxTbV XwH1hkRRNwIhuAudmH2ErngyoLbfbC8XGRWYwye4aBSUANeuAeGDAkM1dRylHNlu6Wqs rljlRokozXbktxU9NkydttFAeOZnBejDvVU95BceVyV++mdRJ38gHsGM2gTRi/RTdtUY xEUTKa2HaT0TCQnd1pa0HRbOKl6WZVsZ+1UpbAColh+01kbjqLcBGJR2l95SnZ0LvLAu wzPw== MIME-Version: 1.0 Received: by 10.112.45.230 with SMTP id q6mr4719592lbm.94.1337781449382; Wed, 23 May 2012 06:57:29 -0700 (PDT) Received: by 10.112.98.170 with HTTP; Wed, 23 May 2012 06:57:29 -0700 (PDT) X-Originating-IP: [69.181.213.76] Date: Wed, 23 May 2012 06:57:29 -0700 Message-ID: From: Trevor Perrin To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnZEtf+XEsln5y0QrmTm81CqpptdGqxHKlv/JOkFoQ1XbB4Yci/HWxMc/7FlV7G+1mP2GOL Subject: [TLS] draft-perrin-tls-tack-00 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, 23 May 2012 13:57:36 -0000 Hi, I'm working with Moxie Marlinspike on "TACK", a TLS Extension we'd like to propose to help with pinning. Draft: https://datatracker.ietf.org/doc/draft-perrin-tls-tack/ Website: http://tack.io The main idea is to allow a site operator to sign their TLS public key with a separate "TACK" key which can be pinned. A pin based on a TACK key isn't tied to any CA or certificate chain, which has benefits in security and operational flexibility compared to pinning certificate chains more directly. There's also mechanisms for activating and de-activating pins, and handling compromises. Anyways, we'd greatly appreciate any feedback! At the website you can find some code (including a command-line tool and test server), and a dev mailing list. Thanks, Trevor From paul@nohats.ca Wed May 23 09:10:07 2012 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 94B6921F854D for ; Wed, 23 May 2012 09:10:07 -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 KGTdegKa4f6x for ; Wed, 23 May 2012 09:10:06 -0700 (PDT) Received: from letoams.cypherpunks.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id C7C9A21F8549 for ; Wed, 23 May 2012 09:10:06 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 2C4F4853FE; Wed, 23 May 2012 12:10:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 2082C803A3; Wed, 23 May 2012 12:10:04 -0400 (EDT) Date: Wed, 23 May 2012 12:10:04 -0400 (EDT) From: Paul Wouters To: Trevor Perrin In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: tls@ietf.org Subject: Re: [TLS] draft-perrin-tls-tack-00 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, 23 May 2012 16:10:07 -0000 On Wed, 23 May 2012, Trevor Perrin wrote: > I'm working with Moxie Marlinspike on "TACK", a TLS Extension we'd > like to propose to help with pinning. > > Draft: https://datatracker.ietf.org/doc/draft-perrin-tls-tack/ > Website: http://tack.io > > The main idea is to allow a site operator to sign their TLS public key > with a separate "TACK" key which can be pinned. A pin based on a TACK > key isn't tied to any CA or certificate chain, which has benefits in > security and operational flexibility compared to pinning certificate > chains more directly. > > There's also mechanisms for activating and de-activating pins, and > handling compromises. A first read seems to suggest you are embedding a self-signed CA into a new TLS extension without a trust model, requiring leaps of faith or an external undefind PKI model. It does not protect new sites you visit, unless you share TACK keys. Sharing tack keys means you just moved the problem without solving anything. How are you going to trust other people's TACK keys? You might as well share either the TLS cert pubkey directly, or the CA that signed it. It seems very hard to be an alternative to DANE/TLSA and PKIX/CAbforum without actually specifying an alternative trust model. But there has to be one. This isn't really different from CertPatrol without a central place to exchange certificate information. Which would require no protocol change. Why not add th TACK information into the X.509 certificate itself, so it would not require a new TLS extension? It only specified ECC, which is a problem for some people due to patents. It's lack of crypto agility is a generic problem. How will this work with CDNs and TLS load balancers using different certs and keys per location? If you want to notify the server owner of someone else faking them, you might want to consider adding something like this into the protocol: http://tools.ietf.org/html/draft-weimer-tls-previous-certificate-00 It seems plugins like CertPatrol already do exactly this, without requiring a TLS protocol change - and with the same problems of a lack of trusted repository to look up TLS server public keys. Paul From trevp@trevp.net Wed May 23 09:44:44 2012 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 8D39B21F8741 for ; Wed, 23 May 2012 09:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 JKniOAYBgfGI for ; Wed, 23 May 2012 09:44:43 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B57CE21F8739 for ; Wed, 23 May 2012 09:44:43 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5753589vbb.31 for ; Wed, 23 May 2012 09:44:43 -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:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=twoVCi2P6v6jb3c/Pxfq8dHdvtmICZCURCsrHu3MyLU=; b=jDlCED2BtLo16TspHsLLwEdmAibmeft265z2Wi48zUUkGAhR+6LxGsrNOo05Qw5Qrm NQtX3pMii4rW+ezBKOj1w0bYPyAqgb26bPxKOFp2BoL8zEcz3VE4d1iZnkNidyImTcIi xgZ+1noU2Q/jeEXhw4bEfepBXBGRHNvGQMoEXNI/TA2fn64NqKzGGTb3vhYXVJsjrVVe 4bfRROSG1YhhsDePKMTEF3NehXATT9rOwnWScpgXKO8+cA9HLAz+pVa+/e9G8VSC/3dv 2IYAr0dKYq+NKfGS+jQA+E4LVDZFox6YLjapcfJoleOkVVxd/aa0zjrC13jT2uzJJJP1 nkwQ== MIME-Version: 1.0 Received: by 10.221.0.197 with SMTP id nn5mr3371521vcb.0.1337791482942; Wed, 23 May 2012 09:44:42 -0700 (PDT) Received: by 10.52.26.199 with HTTP; Wed, 23 May 2012 09:44:42 -0700 (PDT) X-Originating-IP: [69.181.213.76] In-Reply-To: References: Date: Wed, 23 May 2012 09:44:42 -0700 Message-ID: From: Trevor Perrin To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmwLa6b/nB8sk/Scd7VBNNLwXMVjtSw5pQbcELFy2BlKSb1cjVKZNurpzu+FXeVKQoGPYjI Cc: tls@ietf.org Subject: Re: [TLS] draft-perrin-tls-tack-00 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, 23 May 2012 16:44:44 -0000 Hi Paul, Thanks for feedback, responses inline - On Wed, May 23, 2012 at 9:10 AM, Paul Wouters wrote: > A first read seems to suggest you are embedding a self-signed CA into a > new TLS extension without a trust model, requiring leaps of faith or > an external undefind PKI model. The "pin activation" algorithm is somewhat different from the typical "leap-of-faith" / "trust-on-first-use" model. Yes, pins could also be distributed from external sources, such as a browser preload list, etc. > It does not protect new sites you visit, unless you share TACK keys. > Sharing tack keys means you just moved the problem without solving > anything. How are you going to trust other people's TACK keys? You might > as well share either the TLS cert pubkey directly, or the CA that signed > it. Disagree with the "might as well" part. Sharing the cert pubkey or a CA key does not work as well, since sites can have mutliple of these things deployed simultaneously, and can change these things at any time. It is difficult to distinguish - without something like TACK - whether the presence of multiple such things, or such changes, are attacks or not. > protocol change. Why not add th TACK information into the X.509 > certificate itself, so it would not require a new TLS extension? We would not want to add it into a CA-signed certificate, since we would like a site to be able to deploy TACK without needing to rely on CAs. But, you're right that it may be reasonable, and a quicker route to deployment for some sites, to add a "superfluous" certificate to a TLS certificate chain, containing a TACK_Extension. In fact, we've implemented this as well, but figured that was somewhat an abuse of the TLS handshake, so we did not document it here. > It only specified ECC, which is a problem for some people due to patents. > It's > lack of crypto agility is a generic problem. ECDSA/P-256 is pretty widely used, and covered in RFC6090. See section 9.3 for agility: http://tack.io/draft.html#future > How will this work with CDNs and TLS load balancers using different > certs and keys per location? Hopefully well, since the TACK key can sign different TLS keys. > It seems plugins like CertPatrol already do exactly this Disagree per above - plugins like CertPatrol can't know whether the observation of a different cert from one seen previously is legitimate or an attack. A site rejected provided by a TACK pin provides a much stronger basis for rejecting the connection on security grounds. Trevor From moxie@thoughtcrime.org Wed May 23 10:31:45 2012 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 01E6721F853C for ; Wed, 23 May 2012 10:31:45 -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 SO0T2N8xEG0W for ; Wed, 23 May 2012 10:31:44 -0700 (PDT) Received: from mail.thoughtcrime.org (mail.thoughtcrime.org [97.107.130.249]) by ietfa.amsl.com (Postfix) with ESMTP id 1890B21F8507 for ; Wed, 23 May 2012 10:31:44 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by thoughtcrime.org (Postfix) with ESMTPSA id B18CF410F for ; Wed, 23 May 2012 17:31:42 +0000 (UTC) Message-ID: <4FBD1EFE.7040305@thoughtcrime.org> Date: Wed, 23 May 2012 10:31:42 -0700 From: Moxie Marlinspike User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] draft-perrin-tls-tack-00 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, 23 May 2012 17:31:45 -0000 On 05/23/2012 09:10 AM, Paul Wouters wrote: > It seems very hard to be an alternative to DANE/TLSA and PKIX/CAbforum > without actually specifying an alternative trust model. But there has to > be one. This isn't really different from CertPatrol without a central > place to exchange certificate information. Which would require no > protocol change. Why not add th TACK information into the X.509 > certificate itself, so it would not require a new TLS extension? To add a few comments to Trevor's, I don't think we see TACK (by itself) as a replacement for DANE or CAs. We hope that it's a smaller, simple to deploy solution that takes a bite out of the larger problem, and can work in conjunction with other trust systems. If we look at the history of CA compromises, the CA pins in Chrome are the only technology that I know of which has thus far been documented as effective in mitigating a real-time attack. They're the reason we even know about the DigiNotar compromise. The Chrome team has been very generous about allowing other sites to add their own CA pins to Chrome, but there are two limitations that I see: 1) Chrome pins CA SPKIs. Many sites have several certificates signed by multiple CAs, and don't know what root certificate their CAs will use to sign future renewals, so while the pins end up narrowing the risk, it still ends up being a pretty big list for major websites (look at Twitter's pins in Chrome, for instance). 2) Scalability. This requires actually embedding lists into the Chrome source, which is hard to imagine scaling extremely far. It adds friction for the site operator, because future CA changes or even certificate renewals with an existing CA might require Chrome to update its list. That means waiting for the change to get committed and distributed, then waiting another 10 weeks for the pinning window of users who might not have upgraded yet to phase out. And, of course, this is all limited to Chrome and doesn't extend to other browsers. If the DigiNotar attackers had been smart enough to fingerprint the browsers they were attacking, we might never have known about it. TACK is an attempt to extend this mechanism so that it's easy to deploy, pins site keys rather than CA keys, offers the agility site operators are used to, and can be easily supported in multiple browsers. While I see a project like Convergence as an attempt to provide increased 'trust agility,' I see TACK as an attempt to reduce the surface for which third party trust is even required. The two types of projects are not incompatible, and in fact the latter simply reduces the amount of work the former needs to do. > It seems plugins like CertPatrol already do exactly this, without > requiring a TLS protocol change - and with the same problems of a lack > of trusted repository to look up TLS server public keys. I think addons like CertPatrol are pretty nice, but there's a reason they have not been incorporated directly into browsers for the benefit of all users: TLS certificates change under completely normal circumstances. Browser vendors would have difficulty incorporating CertPatrol type logic into their browsers today, because it would probably either end up a) asking a lot of users or b) completely desensitizing them to whatever warnings they display. TACK provides a layer of indirection that allows a browser to distinguish between an attack and a normal certificate change. - moxie -- http://www.thoughtcrime.org From geoffk@geoffk.org Wed May 23 13:38:42 2012 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 A43FD11E80A5 for ; Wed, 23 May 2012 13:38:42 -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 4sxVx-WWKcrg for ; Wed, 23 May 2012 13:38:41 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id A67FD11E80A4 for ; Wed, 23 May 2012 13:38:41 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 1231D33D0AA; Wed, 23 May 2012 20:38:41 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Trevor Perrin References: From: Geoffrey Keating Date: 23 May 2012 13:38:40 -0700 In-Reply-To: Message-ID: Lines: 35 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] draft-perrin-tls-tack-00 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, 23 May 2012 20:38:42 -0000 Trevor Perrin writes: > Hi, > > I'm working with Moxie Marlinspike on "TACK", a TLS Extension we'd > like to propose to help with pinning. > > Draft: https://datatracker.ietf.org/doc/draft-perrin-tls-tack/ > Website: http://tack.io > > The main idea is to allow a site operator to sign their TLS public key > with a separate "TACK" key which can be pinned. A pin based on a TACK > key isn't tied to any CA or certificate chain, which has benefits in > security and operational flexibility compared to pinning certificate > chains more directly. > > There's also mechanisms for activating and de-activating pins, and > handling compromises. > > Anyways, we'd greatly appreciate any feedback! I like this part: When a client sees a new hostname and TACK key combination, an inactive pin is created. Every subsequent time the client sees the same pin, the pin is "activated" for a period equal to the timespan between the first time the pin was seen and the most recent time, up to a maximum period of 30 days. However, I would suggest 32 days not 30, so that a web site which is used at the same local time on the same day each month can always be pinned. Some months have 31 days, and you need a little more time to allow for DST or time zone changes which I rounded up to 1 extra day making 32. From yaronf.ietf@gmail.com Thu May 24 13:35:58 2012 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 CC47911E8112 for ; Thu, 24 May 2012 13:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.813 X-Spam-Level: X-Spam-Status: No, score=-102.813 tagged_above=-999 required=5 tests=[AWL=0.786, BAYES_00=-2.599, 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 D2q-I9XTVxvA for ; Thu, 24 May 2012 13:35:58 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0611011E8111 for ; Thu, 24 May 2012 13:35:52 -0700 (PDT) Received: by bkty8 with SMTP id y8so199893bkt.31 for ; Thu, 24 May 2012 13:35:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=1ygwe9f/jyiiVuZEy4bZBYXPel9cmHExC+DUTXyptOc=; b=eWNWd8dQ3DKE9ZGq+aUvb8ayTFzEdaXTDzpizIjVc12Q2kUaFIx2oq5NPyltNFASc7 mtkQdK3am+/yrlY0VF4EyMaEYe+wapaApSvmAz6qM+gHYiYkPgJhEz4569hx0//8gbsP TCfbRBAg6TEqkMlfMuHaMuL5u+FSKeFUERVAT7LqFxXLTSSDRnfv2VQXqUgC5y1zueLS l1zYZlJzWRkv7Hdp/VlDoRbB1icg4foG3mnAoD84/v2DGpgWs7nsuiHHfKVsJ1ro/6rN 3AJOKcB1xHZWbLkXNcSOArVLSVIP9AfeR/2rNAnIfWfwCtX27L0dhgmIRkj6ap8xbbJm HusA== Received: by 10.204.152.6 with SMTP id e6mr364712bkw.18.1337891752051; Thu, 24 May 2012 13:35:52 -0700 (PDT) Received: from [10.0.0.3] ([109.64.171.110]) by mx.google.com with ESMTPS id gm18sm4199957bkc.7.2012.05.24.13.35.50 (version=SSLv3 cipher=OTHER); Thu, 24 May 2012 13:35:50 -0700 (PDT) Message-ID: <4FBE9BA5.9090704@gmail.com> Date: Thu, 24 May 2012 23:35:49 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] draft-perrin-tls-tack-00 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, 24 May 2012 20:35:59 -0000 Hi, this draft looks too complex to be implementable in its current form, however I'd like to offer too early comments. First, pinning is a useful idea. To make it even more useful, we might want to extend TACK itself by pinning additional properties of the server, not just the server cert. For example, pinning the property "this server supports the Encrypted Handshake extension" would go a long way towards resolving the EH downgrade attack that EKR described. In addition, going through this exercise and then subjecting it to the user's "just press OK" mentality is kind of useless. So I would remove the following sentence: "An example policy would be to accept the connection only if it passes certificate verification and is not rejected by a pin, or if the user elects to "connect anyway" despite certificate and/or pin failures." Thanks, Yaron > > Trevor Perrin writes: > >> Hi, >> >> I'm working with Moxie Marlinspike on "TACK", a TLS Extension we'd >> like to propose to help with pinning. >> >> Draft: https://datatracker.ietf.org/doc/draft-perrin-tls-tack/ >> Website: http://tack.io >> >> The main idea is to allow a site operator to sign their TLS public key >> with a separate "TACK" key which can be pinned. A pin based on a TACK >> key isn't tied to any CA or certificate chain, which has benefits in >> security and operational flexibility compared to pinning certificate >> chains more directly. >> >> There's also mechanisms for activating and de-activating pins, and >> handling compromises. >> >> Anyways, we'd greatly appreciate any feedback! > > I like this part: > > When a > client sees a new hostname and TACK key combination, an inactive pin > is created. Every subsequent time the client sees the same pin, the > pin is "activated" for a period equal to the timespan between the > first time the pin was seen and the most recent time, up to a maximum > period of 30 days. > > However, I would suggest 32 days not 30, so that a web site which is > used at the same local time on the same day each month can always be > pinned. Some months have 31 days, and you need a little more time > to allow for DST or time zone changes which I rounded up to 1 extra > day making 32. > > > ------------------------------ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > End of TLS Digest, Vol 94, Issue 22 > *********************************** From trevp@trevp.net Thu May 24 15:17:03 2012 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 3606811E808A for ; Thu, 24 May 2012 15:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Vso9t6kKN0U1 for ; Thu, 24 May 2012 15:17:02 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C4B4311E8080 for ; Thu, 24 May 2012 15:17:01 -0700 (PDT) Received: by lagv3 with SMTP id v3so225364lag.31 for ; Thu, 24 May 2012 15:17:00 -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:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=9GlSVc++QA7HHzzKhzT/apwcBt+/jRuU+uba0xeqpb4=; b=Kay8InmCp4nlBcs3iDO6DCrgjtKcXx9ft4jxNOBpXa4eiv+ZlB9e6PxdcfWeShtIWD 1jkLHzQGyTti96M/2bTGvALYZ2CuqYKDNtGxunAmBv8ZHxmlTiNPov+wGYZ9xwsbBM5b 43xt/cZOhIhn4whbyVladJxucl5x+Rwovp3IyuWN7rl6/2f4d3WoDk+ZRW3CpYolpHgE 0GwBHwJvLSNNTxSZskTCaP7sqN9XfuESkQl5KrZx5GaTfa5s3+7lpoSzGwUfOVI6FoAP mmjYOxGflF5s6NMYLRcxa/mShkcZTTWicBUcmoXrSjCOhkiQJ/+9JSxYHkY5baNicn6S pTtQ== MIME-Version: 1.0 Received: by 10.112.51.228 with SMTP id n4mr495359lbo.35.1337897820744; Thu, 24 May 2012 15:17:00 -0700 (PDT) Received: by 10.112.98.170 with HTTP; Thu, 24 May 2012 15:17:00 -0700 (PDT) X-Originating-IP: [71.202.222.0] In-Reply-To: <4FBE9BA5.9090704@gmail.com> References: <4FBE9BA5.9090704@gmail.com> Date: Thu, 24 May 2012 15:17:00 -0700 Message-ID: From: Trevor Perrin To: Yaron Sheffer Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlNRSA0AljdC/nNHheCBK/MO44bMRkYVB5JezlrB17rD/GzPKE/BruWSKYAKeckFfNj3LQx Cc: tls@ietf.org Subject: Re: [TLS] draft-perrin-tls-tack-00 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, 24 May 2012 22:17:03 -0000 Hi Yaron, On Thu, May 24, 2012 at 1:35 PM, Yaron Sheffer wrote: > Hi, > > this draft looks too complex to be implementable in its current form, > however I'd like to offer too early comments. Which part? We've implemented much of it (admin tool, TLS support, OpenSSL/Apache patches): https://github.com/tack > First, pinning is a useful idea. To make it even more useful, we might want > to extend TACK itself by pinning additional properties of the server, not > just the server cert. For example, pinning the property "this server > supports the Encrypted Handshake extension" would go a long way towards > resolving the EH downgrade attack that EKR described. If you are thinking of pinning some other property to the domain name (besides a TACK key) then TACK may not be involved. However, you could consider re-using pin activation. If you are thinking of pinning some additional property to the TACK key, then check out section 6.2 on "Application-specific pinning", http://tack.io/draft.html#anchor17 A possible use-case for that is MTA-to-MTA SMTP, where instead of pinning the receiving MTA's domain name (to a TACK key), you'd like to pin the email recipient's domain name. > In addition, going through this exercise and then subjecting it to the > user's "just press OK" mentality is kind of useless. So I would remove the > following sentence: > > "An example policy would be to accept the connection only if it passes > certificate verification and is not rejected by a pin, or if the user elects > to "connect anyway" despite certificate and/or pin failures." We could maybe remove the "connect anyway" clause. Personally, I think it's reasonable to provide a user recourse in the case of security errors, as long as the user is suitably warned. Anyways, this sentence is just an example (non-normative), and client implementors are going to provide whatever UI makes sense for their app and user base, so I don't think what we say here is critical. Trevor From trevp@trevp.net Thu May 24 16:56:37 2012 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 3518A21F8503 for ; Thu, 24 May 2012 16:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 OX3mLyb65RWX for ; Thu, 24 May 2012 16:56:36 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 59C9F21F84E1 for ; Thu, 24 May 2012 16:56:36 -0700 (PDT) Received: by lagv3 with SMTP id v3so272338lag.31 for ; Thu, 24 May 2012 16:56:35 -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:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=4Vrdo27Sp2rpZ2Amv+K5lqIQ7KvOJsqJbRYPBSnWgGI=; b=EPn261YOXQxNvFNvRlY4tkjguH0jb1Z3tX2O7iDg7VIknXrSrwqt64jdzACaOfPd8J krsJamEDfetQ3b7LH0aK3wD9FspIqKPP4IJe7NElOM6c15IVgubwcl6WB91W7GCtFTSN ojHQjt2tPgnI0ywLVXZl1Wr3GfLmQK7rlT00WqRmJLE4KfOpbj2vCb4XeNYHEp2Pcr+M vhhriGUnj8iEk99odmLUavDdP5qvzGnwHz7iGs5CV9HawX/u0WhOKQKQQJuo1NB9octu /I46jAr0ig7g8db54GCle7lRbymmvjrS6lsgPXI/qsGZcW3rV8VDo1EjRCkzodcmsyUo UdSg== MIME-Version: 1.0 Received: by 10.112.103.194 with SMTP id fy2mr569736lbb.64.1337903795175; Thu, 24 May 2012 16:56:35 -0700 (PDT) Received: by 10.112.98.170 with HTTP; Thu, 24 May 2012 16:56:35 -0700 (PDT) X-Originating-IP: [71.202.222.0] In-Reply-To: References: Date: Thu, 24 May 2012 16:56:35 -0700 Message-ID: From: Trevor Perrin To: Geoffrey Keating Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmNgp8lzcapX96OQoHWGlIjNQSVVHmclKj9Ady2Bfn1fy4WDudm8FTl6RraP9vKpmJ7cZkm Cc: tls@ietf.org Subject: Re: [TLS] draft-perrin-tls-tack-00 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, 24 May 2012 23:56:37 -0000 On Wed, May 23, 2012 at 1:38 PM, Geoffrey Keating wrote= : > I like this part: > > =A0 When a > =A0 client sees a new hostname and TACK key combination, an inactive pin > =A0 is created. =A0Every subsequent time the client sees the same pin, th= e > =A0 pin is "activated" for a period equal to the timespan between the > =A0 first time the pin was seen and the most recent time, up to a maximum > =A0 period of 30 days. > > However, I would suggest 32 days not 30, so that a web site which is > used at the same local time on the same day each month can always be > pinned. =A0Some months have 31 days, and you need a little more time > to allow for DST or time zone changes which I rounded up to 1 extra > day making 32. Hmm, maybe... but 30 days has a nice ring to it, it's a sort of "standard" time interval that you encounter often. If we go with 32 we are going to have to explain your logic to people frequently. Leaning againt this, but noting it as an open issue. (We've received suggestions that the max period should be even longer. Moxie has a good post on the issues involved here:) https://lists.riseup.net/www/arc/tack/2012-05/msg00006.html Trevor From pritikin@cisco.com Thu May 24 22:19:15 2012 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 833D021F84B3 for ; Thu, 24 May 2012 22:19:15 -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 mf6zpTVWvatk for ; Thu, 24 May 2012 22:19:14 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id C845E21F84B2 for ; Thu, 24 May 2012 22:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=1569; q=dns/txt; s=iport; t=1337923154; x=1339132754; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=xlVqmmP6RxqjcV4IjX20lmxNkvCYJD9mep7XrYMEpo0=; b=foAj0N1PJZzPPRzZKWgSmPYJuUd21yBHB89G/jMyhMq8CeRRH2oN386/ DC8vuMDIzD6pAkl2fZFt65BxbweHiYSV4oF864uCod+ebeksMlLloeZaK wTcUHO7uE0PmOC1c9aHPyadia3+aTiG8j9YS+/06ju9dEcV9vUYJrhgqW Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmMFAIITv0+rRDoI/2dsb2JhbABEgx2xYoEHghUBAQEDAQEBAQ8BWwsFCwsOCi4nAS8GEyKHZgQMm1SfYgSKf4RmYAOIP4o0giWFT4g9gWSCfw X-IronPort-AV: E=Sophos;i="4.75,654,1330905600"; d="scan'208";a="43761339" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 25 May 2012 05:19:14 +0000 Received: from [10.21.0.115] ([10.21.0.115]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q4P5JDB5031239; Fri, 25 May 2012 05:19:14 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Max Pritikin In-Reply-To: Date: Thu, 24 May 2012 23:19:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Trevor Perrin X-Mailer: Apple Mail (2.1257) Cc: Geoffrey Keating , tls@ietf.org Subject: Re: [TLS] draft-perrin-tls-tack-00 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, 25 May 2012 05:19:15 -0000 I think 32 has a nice ring to it, its sort of a a "standard" number what = with it being 2^5th. :) On May 24, 2012, at 5:56 PM, Trevor Perrin wrote: > On Wed, May 23, 2012 at 1:38 PM, Geoffrey Keating = wrote: >> I like this part: >>=20 >> When a >> client sees a new hostname and TACK key combination, an inactive = pin >> is created. Every subsequent time the client sees the same pin, = the >> pin is "activated" for a period equal to the timespan between the >> first time the pin was seen and the most recent time, up to a = maximum >> period of 30 days. >>=20 >> However, I would suggest 32 days not 30, so that a web site which is >> used at the same local time on the same day each month can always be >> pinned. Some months have 31 days, and you need a little more time >> to allow for DST or time zone changes which I rounded up to 1 extra >> day making 32. >=20 >=20 > Hmm, maybe... but 30 days has a nice ring to it, it's a sort of > "standard" time interval that you encounter often. If we go with 32 > we are going to have to explain your logic to people frequently. >=20 > Leaning againt this, but noting it as an open issue. >=20 > (We've received suggestions that the max period should be even longer. > Moxie has a good post on the issues involved here:) >=20 > https://lists.riseup.net/www/arc/tack/2012-05/msg00006.html >=20 >=20 > Trevor > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From turners@ieca.com Sat May 26 13:08:08 2012 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 F173521F851E for ; Sat, 26 May 2012 13:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.765 X-Spam-Level: X-Spam-Status: No, score=-102.765 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 emLZxi0zWgRM for ; Sat, 26 May 2012 13:08:08 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.56.212.19]) by ietfa.amsl.com (Postfix) with ESMTP id 474BE21F851C for ; Sat, 26 May 2012 13:08:08 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id CB0C970B89113; Sat, 26 May 2012 15:08:07 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id C085770B890F3 for ; Sat, 26 May 2012 15:08:07 -0500 (CDT) Received: from [71.191.15.83] (port=45176 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SYNHT-00019q-5d for tls@ietf.org; Sat, 26 May 2012 15:08:07 -0500 Message-ID: <4FC13826.9010900@ieca.com> Date: Sat, 26 May 2012 16:08:06 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tls@ietf.org References: <20120509153513.11861.32080.idtracker@ietfa.amsl.com> In-Reply-To: <20120509153513.11861.32080.idtracker@ietfa.amsl.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) [71.191.15.83]:45176 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [TLS] I-D Action: draft-ietf-tls-multiple-cert-status-extension-00.txt 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: Sat, 26 May 2012 20:08:09 -0000 Yngve, Thanks for getting this posted so quickly. A lot of my comments are about supporting both OCSP and SCVP (OCSP being the MTI). I think it would be good to future proof this spec a bit, because I can see somebody coming down the trail later asking for it. 0) Move the requirements terminology to s1.1. The RFC editor will move it so you might as well do it now. 1) abstract: OLD: Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information not just about the server's own certificate, but also the status of intermediate certificates in the chain. NEW: Also defined is a new method based that servers can use to provide status information (i.e., Online Certificate Status Protocol and Server-Based Certificate Validation Protocol) not just about the server's own certificate, but also the status of intermediate certificates in the chain. 2) s1: r/such as CRLs,/such as Certificate Revocation Lists (CRLs), 3) s1: Introduce OCSP and SCVP OLD: Second, the current format of the extension and requirements in the TLS protocol prevents a client from offering the server multiple status methods. NEW: Second, the current format of the extension and requirements in the TLS protocol prevents a client from offering the server multiple status methods; there are two defined the Online Certificate Status Protocol (OCSP) [RFC2560] and the Server-Based Certificate Validation Protocol [RFC5055]. 4) s1: contains the following: Many Certification Authorities are now issuing intermediate CA certificates that not only specify a CRL Distribution Point [RFC5280], but also a URL for OCSP [RFC2560] Certificate Status requests. I think it makes sense to say where they're putting the OCSP URL: Many CAs issue intermediate CA certificates that not only specify the publication point for their CRLs in CRL Distribution Point [RFC5280], but also specify a URL for their OCSP server in Authority Information Access [RFC5280]. 5) s1: I'd tweak the following a bit: OLD: Given that client-cached CRLs are frequently out of date, using OCSP to access up-to-date status information about intermediate CA certificates will be of great benefit to clients. NEW: Given that client-cached CRLs are frequently out of date, clients would benefit from using OCSP to access up-to-date status information about intermediate CA certificates. 6) s1: Some more tweaking: OLD: For these reasons, it will be beneficial to use the TLS server to provide the certificate status information not just for the server certificate, but also for the intermediate CA certificates. This will ... NEW: Clients will benefit from the TLS server providing certificate status information regardless of type not just for the server certificate but also for the intermediate CA certificates. Combining the status checks in to one extension will ... 7) s1: Starting to like the idea of not using must if you don't have to: r/it must be possible for clients to/client need to 8) s1: r/TLS Protocol/TLS Protocol [RFC5246] r/PKIX infrastructure/PKIX infrastructure [RFC5280] r/by using/using 9) s1: (no action required) I think the introduction will be helpful during subsequent directorate/IESG reviews because it nicely explains why the WG thinks the extension is needed. 10) s2.2: I think we can drop the "like": r/certificate status protocol like OCSP/certificate status protocol (i.e., OCSP and SCVP) 11) s2.2: Add SCVP ... OLD: struct { CertificateStatusType status_type; uint16 request_length; /* Length of request field in bytes */ select (status_type) { case ocsp: OCSPStatusRequest; case ocsp_multi: OCSPStatusRequest; } request; } CertificateStatusRequestItem; NEW: struct { CertificateStatusType status_type; uint16 request_length; /* Length of request field in bytes */ select (status_type) { case ocsp: OCSPStatusRequest; case ocsp_multi: OCSPStatusRequest; case scvp: SCVPStatus Request; } request; } CertificateStatusRequestItem; SCVP will allow you to send multiple certs in one request so I don't think there's need for scvp_multi - unless we want to restrict scvp to just be one and have a scvp_multi for more than one. OLD: enum { ocsp(1), ocsp_multi(YY), (255) } CertificateStatusType; NEW: enum { ocsp(1), ocsp_multi(YY), scvp (AA), (255) } CertificateStatusType; struct { ResponderID responder_id_list<0..2^16-1>; Extensions request_extensions; } SCVPStatusRequest; Going with the though that we'd send the same type of information in, but this might be a bit simple minded. Obviously a bunch of text is needed for this too, but I figure I'd hold up here while we decide if this is the right approach. 12) s2.2/6: r/CCITT/ITU For these I guess maybe move the X.690 reference earlier to the first occurrence or just put it everywhere: s2.2: r/DER encoding/DER [ITU.X.690.2002] encoding s2.2: r/are DER-encoded ASN.1 types/ are DER-encoded [ITU.X.690.2002] ASN.1 types 13) s4.1: I'd add the following motherhood and apple pie: The security considerations of [RFC2560] to OCSP requests and responses. spt From n.mavrogiannopoulos@gmail.com Mon May 28 02:26:40 2012 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 E117C21F84A2 for ; Mon, 28 May 2012 02:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 XB6etvR32Tln for ; Mon, 28 May 2012 02:26:40 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDC321F84A0 for ; Mon, 28 May 2012 02:26:39 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1913184wgb.13 for ; Mon, 28 May 2012 02:26:39 -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=wK4eQVBaTw0NVJM5eXWmkNij/xsAUCbwOa8RfhflU4I=; b=o6x0vd1ZRaclywCh93Sl405pmAV5pBziX9r1BHX2BqPnkx9exHmLybq+XMdC9hNTeF ExtIurc5HB+l3nattwKRWcb5VJeSA7OZMRnwiEYSS03nxLxSu+XK9+p6wSkXvoH1Tq9Y UNpbT8ohuAjuT+xELf6ozDO/kD1BBUV4l6eGP/6x886QAjrpK7MmUPjv0pV+kd0H3+Tw Ci4Jq8+3OV8cOjb9CwKmVuDOzOL72mtEBlG80YSLSiu3LJLdODz8u2gkpxJkDCmaUB+o OGVP0l2KV/nskfW4jBytPFO5VOG7NlUMTXlVb9z1w8S9wxZVEKo1dKsx5WUenADuU2AL 4l5w== MIME-Version: 1.0 Received: by 10.216.212.217 with SMTP id y67mr4274782weo.173.1338197199163; Mon, 28 May 2012 02:26:39 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.180.103.228 with HTTP; Mon, 28 May 2012 02:26:38 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 May 2012 11:26:38 +0200 X-Google-Sender-Auth: mMYVM2eEj_AqkUoONiHREmp3VwQ Message-ID: From: Nikos Mavrogiannopoulos To: Trevor Perrin Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] draft-perrin-tls-tack-00 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, 28 May 2012 09:26:41 -0000 On Wed, May 23, 2012 at 3:57 PM, Trevor Perrin wrote: > Hi, > I'm working with Moxie Marlinspike on "TACK", a TLS Extension we'd > like to propose to help with pinning. > Draft: https://datatracker.ietf.org/doc/draft-perrin-tls-tack/ > Website: http://tack.io Hello, May I ask what are the advantages compared to: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-01 As I see it the key-pinning is simpler, does not require dependence on any signing algorithm (only hash). I can see that you try to have a discussion in the introduction, but it seems to be wrong: "Unfortunately, a number of problems arise when attempting to pin certificate chains: the TLS servers at a given hostname may have different certificate chains simultaneously deployed and may change their chains at any time, the "more constant" elements of a chain (the CAs) may not be trustworthy, and the client may be oblivious to key compromise events which render the pinned data untrustworthy." My understanding of the key-pinning draft is that pinning occurs on the hosts public key, so changing certificate chains does not have the effect you describe. regards, Nikos From turners@ieca.com Mon May 28 12:49:42 2012 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 973F621F869D for ; Mon, 28 May 2012 12:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.116 X-Spam-Level: X-Spam-Status: No, score=-102.116 tagged_above=-999 required=5 tests=[AWL=0.149, 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 Sksv2F9-wRUZ for ; Mon, 28 May 2012 12:49:42 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.225.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1913321F869A for ; Mon, 28 May 2012 12:49:42 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 778786F8118C5; Mon, 28 May 2012 14:49:41 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 695A06F81188C for ; Mon, 28 May 2012 14:49:41 -0500 (CDT) Received: from [71.191.15.83] (port=40789 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SZ5wi-0006UY-VQ; Mon, 28 May 2012 14:49:41 -0500 Message-ID: <4FC3D6D4.5050402@ieca.com> Date: Mon, 28 May 2012 15:49:40 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <4EF84292.50201@gmx.net> In-Reply-To: <4EF84292.50201@gmx.net> 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) [71.191.15.83]:40789 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: tls@ietf.org Subject: Re: [TLS] TLS Cached Information Extension - version 11 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, 28 May 2012 19:49:42 -0000 On 12/26/11 4:46 AM, Hannes Tschofenig wrote: > Hi all, > > Nikos provided review comments (see > http://www.ietf.org/mail-archive/web/tls/current/msg08338.html) and I > have incorporated them in version 11 of the draft: > http://www.ietf.org/internet-drafts/draft-ietf-tls-cached-info-11.txt > > As you can see, there are a number of smaller changes here and there. I > hope that readability has improved. > > There is an open issue: algorithm negotiation > > Currently, the draft defines a registry for hash algorithms that are > used to produce the hashes of cached information. The client can tell > the server that it has already cached, for example, the certificate > chain. The server then has to only send the fingerprint of it (rather > than the complete certificate chain). The other information (besides > certificate chains) that can be "fingerprinted" is the list of trusted > CAs. Does this cover all use cases? > > A few algorithms are defined, namely SHA-1, SHA-224, SHA-256, SHA-384, > SHA-512. Is this a good list to start with? Yes this looks like a good list. Nit: might change the reference from SHA to SHS. Also, to avoid the downref can we just use SHS for the SHA-224 reference? On the hash alg registry, why aren't we reusing the TLS HashAlgorithm Registry? If you're worried folks will be confused about if they can use it with SignatureAlgorithms can't we just add another column in the registry and indicate whether it's okay to use it for cached info/signaturealgorithms? > The draft does not define a way for the client to tell the server that > it only supports a certain hash algorithm. Should we allow the client to > indicate what algorithm it supports? And some more nits: s1: r/Transport Layer Security (TLS)/Transport Layer Security (TLS) [RFC5246] r/I-D.ietf-tls-rfc4366-bis/RFC6066 r/draft-ietf-tls-rfc4366-bis-12 (work in progress), September 2010/RFC 6066, January 2011 r/I-D.iab-smart-object-workshop/RFC 6574 r/draft-iab-smart-object-workshop-06 (work in progress), October 2011/RFC 6574, April 2012 r/wouters-tls-oob-pubkey/tls-oob-pubkey-03 r/draft-wouters-tls-oob-pubkey-02 (work in progress), November 2011/draft-ietf-tls-oob-pubkey-03 (work in progress), April 2012 spt From trevp@trevp.net Tue May 29 08:53:09 2012 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 3157221F86D8 for ; Tue, 29 May 2012 08:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 KpdsHxIzSg+I for ; Tue, 29 May 2012 08:53:08 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD6221F86D5 for ; Tue, 29 May 2012 08:53:08 -0700 (PDT) Received: by ggnc4 with SMTP id c4so3119473ggn.31 for ; Tue, 29 May 2012 08:53: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:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=r5J+7euBKEnt5plRPAUgZUWf4GyPVoVCw9rVf0gRPlc=; b=H3kwSrUChyFB1j5R/yZhbGnByqd9KZpAZ4n8YaVxTY4sUnqDiEMsBNKZvIJJ/eXOQY OIMkqV+tkrcS2Rn+qAsVYothaUwH5APzdl0tzfSBwVjGaL2HuV+AfjHkgWoRASRnMbWM Wd+Q68gaWH6m+UVDonsNE78uvPrkt06hIdme/2s2xmmknGJaC+lhKpucvUF6FP5keays h8FjSvPPqNZZOLhcP0nUde0NvNyYsizjvAYZsAFzF4wHkvfemgrs7wobjk/OEA8JYu1g 4vI+deST47LR6tKGvYVf1I81E/SGLZUza2BdU1CIO1gBHcWHIjpIPubhhM4SSEXzHuTc lZsA== MIME-Version: 1.0 Received: by 10.50.207.36 with SMTP id lt4mr8034376igc.5.1338306787268; Tue, 29 May 2012 08:53:07 -0700 (PDT) Received: by 10.64.163.70 with HTTP; Tue, 29 May 2012 08:53:07 -0700 (PDT) X-Originating-IP: [71.116.124.126] In-Reply-To: References: Date: Tue, 29 May 2012 08:53:07 -0700 Message-ID: From: Trevor Perrin To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnl3Yt5KZlH5X7ei+PebvveacY9poH8rCH91XPdTBC4+ioe/TZ2dzEm/3/5hMrf/hcsK+I/ Cc: tls@ietf.org Subject: Re: [TLS] draft-perrin-tls-tack-00 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, 29 May 2012 15:53:09 -0000 On Mon, May 28, 2012 at 2:26 AM, Nikos Mavrogiannopoulos wrote: > Hello, > =A0May I ask what are the advantages compared to: > http://tools.ietf.org/html/draft-ietf-websec-key-pinning-01 Hey Nikos, Good question. We think "PKP" is good work, but TACK has several advantage= s: (1) TACK works at the TLS layer, so it can be used by any application built on TLS. (2) TACK uses signing keys which are not CA keys. Thus, TACK allows for TLS key changes without needing trust in CAs. (3) TACK has additional safeguards to reduce the risk of bad pins affecting site availability. In particular, the "pin activation" algorithm places a limit on pin activation periods, and scales up slowly so that brief exposure to a bad pin cannot cause long-lived problems. (4) TACK's "break signatures" lets a server publish an emergency signal that a pin is compromised and should not be trusted. TACK's "min_generation" lets a server publish an emergency signal that a TLS key is compromised. These signals can be cryptographically verified using the pin, and could be gathered and distributed by 3rd-party trust infrastructure. (5) The TACK "expiration" field allows use of short-lived TACKs as an alternative way to mitigate the risk of TLS key compromise without relying on revocation messages. (6) TACK pins are small and contain embedded revocation info (min_generation), so they are a compact form for distributing trust information (e.g. via DNS, browser preload lists, Convergence, etc). (7) TACK supports 3rd-party-assisted pinning, where a 3rd-party (which could be a CA or any other entity) provides TACKs. > As I see it the key-pinning is simpler, TACK is a bit complicated to evaluate, but it's easier to implement, and even easier to deploy, since: (a) The deployer can ignore revocation features like break signatures and generations until they're needed. (b) The most complex part of TACK (pin activation) actually simplifies deployment, by automatically scaling up the activation period. To get a sense of the deployment process, see the tackpy README (or try the tool): https://raw.github.com/tack/tackpy/master/README https://github.com/tack/tackpy/downloads Trevor From paul@nohats.ca Tue May 29 09:41:30 2012 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 7D8FA21F8731 for ; Tue, 29 May 2012 09:41:30 -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, J_CHICKENPOX_42=0.6] 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 hZovRkiwoz2R for ; Tue, 29 May 2012 09:41:25 -0700 (PDT) Received: from letoams.cypherpunks.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAB521F8714 for ; Tue, 29 May 2012 09:41:22 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 3E837853FD; Tue, 29 May 2012 12:41:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 244C08244F; Tue, 29 May 2012 12:41:20 -0400 (EDT) Date: Tue, 29 May 2012 12:41:20 -0400 (EDT) From: Paul Wouters To: Trevor Perrin In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: tls@ietf.org Subject: Re: [TLS] draft-perrin-tls-tack-00 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, 29 May 2012 16:41:30 -0000 On Tue, 29 May 2012, Trevor Perrin wrote: > (2) TACK uses signing keys which are not CA keys. Thus, TACK allows > for TLS key changes without needing trust in CAs. Which is also the *problem* of TACK. Since the TACK pins are signed by entities for which no trust anchors are distributed, I do not see much value of TACK pins over the TLS public key. Both are obtained inside the TLS connection and come with no one backing them up to ensure you're not MITM'ed. You might think TACK keys can be handled better by larger SSL farms, but then you have to consider why those large SSL farms are not able to use the same SSL pubkeys everywhere either and why the same issue would not affect TACK keys. I'd say using a TLSA record, without any kind of trust anchor, would have benefits over TACK, as you can get DNS answers from unexpected sources that are not as easy to MITM. With DNS records, you already have a flexible caching system in place without the need for new code, or hardcoded timing values in an RFC. > (3) TACK has additional safeguards to reduce the risk of bad pins > affecting site availability. In particular, the "pin activation" > algorithm places a limit on pin activation periods, and scales up > slowly so that brief exposure to a bad pin cannot cause long-lived > problems. I'm not sure how that gains you anything compared to TLSA records with TTL values? How long any key has been used in the past is never any guarantee for its correctness of today's use. With TLSA records, you can only get exposed to a "bad pin" if the administrator makes a mistake, which is something that is still widely discussed on the dane list with respect to hard vs soft fail errors and how to actually convey "bad TLS" to the enduser. > (4) TACK's "break signatures" lets a server publish an emergency > signal that a pin is compromised and should not be trusted. TACK's > "min_generation" lets a server publish an emergency signal that a TLS > key is compromised. These signals can be cryptographically verified > using the pin, and could be gathered and distributed by 3rd-party > trust infrastructure. Then use rbl whitelists to store these pins in 3rd party DNS trees? > (5) The TACK "expiration" field allows use of short-lived TACKs as an > alternative way to mitigate the risk of TLS key compromise without > relying on revocation messages. Short TTLs on TLSA records? > (6) TACK pins are small and contain embedded revocation info > (min_generation), so they are a compact form for distributing trust > information (e.g. via DNS, browser preload lists, Convergence, etc). Ugh. so you figured out this DNS distribution method too. Then why do still think a TLS server/client modification is needed along with a new cryptographic identifier when we already have a way of storing TLS pubkeys in DNS (even if you ignore DNSSEC). How is storing a TACK pubkey any different? You could write the draft using TLSA records with the same initial timing constraints if you deem those better then trusting ICANN and Verisign without inventing any TLS extensions and without adding another level of trust indirection using a new keying scheme. > (7) TACK supports 3rd-party-assisted pinning, where a 3rd-party (which > could be a CA or any other entity) provides TACKs. Like DNSSEC? Or DLV? > (b) The most complex part of TACK (pin activation) actually > simplifies deployment, by automatically scaling up the activation > period. But DNSSEC allows the publisher of the TLS pubkey, the only entity which has absolute knowledge over their intentions with the key, to announce these intentions to everyone, without third party delays, agreements, redistribution, or "x out of y" trust requirements. Anyone else making assumptions about its key use runs the rsk of being wrong, and is delayed in making any such risky statements about the keys. It's a novell idea, but if you just want to avoid trusting ICANN or Verisign, you are better of setting up a third-party trust group that takes TLS pubkeys (or TLSA records) and verifies/distributes those, whether it is submitting to the EFF observatory, rbl lists, trust ambassadors or otherwise. But using TACK to pretend there is no need for the user to consult anyone else is pretty dangerous, especially with hardcoded algos and timings all over the place, and no trust model that scales, and corner cases with never before visited sites. Paul From turners@ieca.com Tue May 29 09:44:38 2012 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 1E63011E80B6 for ; Tue, 29 May 2012 09:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.131 X-Spam-Level: X-Spam-Status: No, score=-102.131 tagged_above=-999 required=5 tests=[AWL=0.134, 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 iQ53dnxnSzlC for ; Tue, 29 May 2012 09:44:37 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.56.159.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6555A11E80B5 for ; Tue, 29 May 2012 09:44:37 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 0B4E17456377B; Tue, 29 May 2012 11:44:37 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 000747456374A for ; Tue, 29 May 2012 11:44:36 -0500 (CDT) Received: from [71.191.15.83] (port=41551 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SZPXA-0004fT-Bx for tls@ietf.org; Tue, 29 May 2012 11:44:36 -0500 Message-ID: <4FC4FCF3.9010605@ieca.com> Date: Tue, 29 May 2012 12:44:35 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tls@ietf.org References: <20120509153513.11861.32080.idtracker@ietfa.amsl.com> <4FC13826.9010900@ieca.com> In-Reply-To: <4FC13826.9010900@ieca.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) [71.191.15.83]:41551 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [TLS] I-D Action: draft-ietf-tls-multiple-cert-status-extension-00.txt 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, 29 May 2012 16:44:38 -0000 After thinking about this some, I should have been clearer about the SCVP changes. They're suggestions not direction. That is, if the WG consensus is to not include SCVP then I'll live with being in the rough. spt On 5/26/12 4:08 PM, Sean Turner wrote: > Yngve, > > Thanks for getting this posted so quickly. > > A lot of my comments are about supporting both OCSP and SCVP (OCSP being > the MTI). I think it would be good to future proof this spec a bit, > because I can see somebody coming down the trail later asking for it. > > 0) Move the requirements terminology to s1.1. The RFC editor will move > it so you might as well do it now. > > 1) abstract: > > OLD: > > Also defined is a new method > based on the Online Certificate Status Protocol (OCSP) that servers > can use to provide status information not just about the server's own > certificate, but also the status of intermediate certificates in the > chain. > > NEW: > > Also defined is a new method based that servers > can use to provide status information (i.e., Online Certificate Status > Protocol and Server-Based Certificate Validation Protocol) not just > about the server's own certificate, but also the status of > intermediate certificates in the chain. > > 2) s1: r/such as CRLs,/such as Certificate Revocation Lists (CRLs), > > 3) s1: Introduce OCSP and SCVP > > OLD: > > Second, the current format of the extension and > requirements in the TLS protocol prevents a client from offering the > server multiple status methods. > > NEW: > > Second, the current format of the extension and > requirements in the TLS protocol prevents a client from > offering the server multiple status methods; there are two > defined the Online Certificate Status Protocol (OCSP) > [RFC2560] and the Server-Based Certificate Validation > Protocol [RFC5055]. > > 4) s1: contains the following: > > Many Certification Authorities are now issuing intermediate CA > certificates that not only specify a CRL Distribution Point > [RFC5280], but also a URL for OCSP [RFC2560] Certificate Status > requests. > > I think it makes sense to say where they're putting the OCSP URL: > > Many CAs issue intermediate CA certificates that not > only specify the publication point for their CRLs in CRL > Distribution Point [RFC5280], but also specify a URL for their > OCSP server in Authority Information Access [RFC5280]. > > 5) s1: I'd tweak the following a bit: > > OLD: > > Given that client-cached CRLs are frequently out of date, > using OCSP to access up-to-date status information about > intermediate CA certificates will be of great benefit to > clients. > > NEW: > > Given that client-cached CRLs are frequently out of date, > clients would benefit from using OCSP to access up-to-date > status information about intermediate CA certificates. > > 6) s1: Some more tweaking: > > OLD: > > For these reasons, it will be beneficial to use the TLS server to > provide the certificate status information not just for the server > certificate, but also for the intermediate CA certificates. This > will ... > > NEW: > > Clients will benefit from the TLS server providing certificate > status information regardless of type not just for the server > certificate but also for the intermediate CA certificates. Combining > the status checks in to one extension will ... > > 7) s1: Starting to like the idea of not using must if you don't have to: > > r/it must be possible for clients to/client need to > > 8) s1: r/TLS Protocol/TLS Protocol [RFC5246] > r/PKIX infrastructure/PKIX infrastructure [RFC5280] > r/by using/using > > 9) s1: (no action required) I think the introduction will be helpful > during subsequent directorate/IESG reviews because it nicely explains > why the WG thinks the extension is needed. > > 10) s2.2: I think we can drop the "like": > > r/certificate status protocol like OCSP/certificate status protocol > (i.e., OCSP and SCVP) > > 11) s2.2: Add SCVP ... > > OLD: > > struct { > CertificateStatusType status_type; > uint16 request_length; /* Length of request field in bytes */ > select (status_type) { > case ocsp: OCSPStatusRequest; > case ocsp_multi: OCSPStatusRequest; > } request; > } CertificateStatusRequestItem; > > NEW: > > struct { > CertificateStatusType status_type; > uint16 request_length; /* Length of request field in bytes */ > select (status_type) { > case ocsp: OCSPStatusRequest; > case ocsp_multi: OCSPStatusRequest; > case scvp: SCVPStatus Request; > } request; > } CertificateStatusRequestItem; > > SCVP will allow you to send multiple certs in one request so I don't > think there's need for scvp_multi - unless we want to restrict scvp to > just be one and have a scvp_multi for more than one. > > OLD: > > enum { ocsp(1), ocsp_multi(YY), (255) } CertificateStatusType; > > NEW: > > enum { ocsp(1), ocsp_multi(YY), scvp (AA), (255) > } CertificateStatusType; > > struct { > ResponderID responder_id_list<0..2^16-1>; > Extensions request_extensions; > } SCVPStatusRequest; > > Going with the though that we'd send the same type of information in, > but this might be a bit simple minded. > > Obviously a bunch of text is needed for this too, but I figure I'd hold > up here while we decide if this is the right approach. > > 12) s2.2/6: r/CCITT/ITU > For these I guess maybe move the X.690 reference earlier to the first > occurrence or just put it everywhere: > s2.2: r/DER encoding/DER [ITU.X.690.2002] encoding > s2.2: r/are DER-encoded ASN.1 types/ > are DER-encoded [ITU.X.690.2002] ASN.1 types > > 13) s4.1: I'd add the following motherhood and apple pie: > > The security considerations of [RFC2560] to OCSP requests > and responses. > > spt > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From marsh@extendedsubset.com Tue May 29 11:02:23 2012 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 5E25B11E8102 for ; Tue, 29 May 2012 11:02:23 -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, J_CHICKENPOX_42=0.6] 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 8df4DWXj+FLA for ; Tue, 29 May 2012 11:02:22 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id 592DC11E80F0 for ; Tue, 29 May 2012 11:02:22 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SZQkP-000Jhg-TD; Tue, 29 May 2012 18:02:21 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id E84FB60A2; Tue, 29 May 2012 18:02:20 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/d+NLNrFNxmXN9SjxCxnadD7JJ52lRM8s= Message-ID: <4FC50F1E.9040706@extendedsubset.com> Date: Tue, 29 May 2012 13:02:06 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Paul Wouters 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] draft-perrin-tls-tack-00 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, 29 May 2012 18:02:23 -0000 Disclaimer: I haven't had a chance to read TACK in detail yet, so this not so much a comment on TACK as a response to the response. On 05/29/2012 11:41 AM, Paul Wouters wrote: > On Tue, 29 May 2012, Trevor Perrin wrote: > >> (2) TACK uses signing keys which are not CA keys. Thus, TACK allows >> for TLS key changes without needing trust in CAs. > > Which is also the *problem* of TACK. Since the TACK pins are signed by > entities for which no trust anchors are distributed, I do not see > much value of TACK pins over the TLS public key. Both are obtained > inside the TLS connection and come with no one backing them up to > ensure you're not MITM'ed. You might think TACK keys can be handled > better by larger SSL farms, but then you have to consider why those > large SSL farms are not able to use the same SSL pubkeys everywhere > either and why the same issue would not affect TACK keys. > > I'd say using a TLSA record, without any kind of trust anchor, would > have benefits over TACK, as you can get DNS answers from unexpected > sources that are not as easy to MITM. I don't understand. It sounds to me like on one hand you're criticizing TACK because it involves asymmetric keys without the "security of a trusted CA" and on the other you're saying unauthenticated DNS replies are somehow more secure because they are harder to MITM? > With DNS records, you already > have a flexible caching system in place without the need for new code, > or hardcoded timing values in an RFC. > >> (3) TACK has additional safeguards to reduce the risk of bad pins >> affecting site availability. In particular, the "pin activation" >> algorithm places a limit on pin activation periods, and scales up >> slowly so that brief exposure to a bad pin cannot cause long-lived >> problems. > > I'm not sure how that gains you anything compared to TLSA records with > TTL values? How long any key has been used in the past is never any > guarantee for its correctness of today's use. I apologize for bringing up the cliche' "perfect is the enemy of the good enough". Personally I don't want "good enough" security, I want "best practical" security, which is a somewhat higher standard. But the saying still applies. What we've been learning in recent years is that such absolute guarantees (which look great on paper) are probably impossible in practice and we need to look at strategies that augment the status quo of PKI with a combination of less-than-airtight measures which make the attacker's job far more difficult. One of the only large scale real-world MitMs case studies comes to us from Iran and Diginotar. The attacker in this case was able to subvert PKI, subvert unauthenticated DNS, and could have easily blocked DNSSEC had there been any. However he was ultimately defeated by a (non-IETF) pinning technique. > With TLSA records, you can > only get exposed to a "bad pin" if the administrator makes a mistake, > which is something that is still widely discussed on the dane list with > respect to hard vs soft fail errors and how to actually convey "bad TLS" > to the enduser. There's no rule that says browsers, websites, and IETF can use only one new technique to secure the web. Therefore, an advantage of one proposal is not an argument against another. > Then why do > still think a TLS server/client modification is needed along with a new > cryptographic identifier when we already have a way of storing TLS pubkeys > in DNS (even if you ignore DNSSEC). How is storing a TACK pubkey any > different? You could write the draft using TLSA records with the same > initial timing constraints if you deem those better then trusting ICANN > and Verisign without inventing any TLS extensions and without adding > another level of trust indirection using a new keying scheme. It's unclear when, if ever, client browsers will begin to refuse to access sites for which DNSSEC records are unavailable but it's probably on the same timescale as websites going IPv6-only. Until that day, a malicious ISP is able to completely disable any protections provided by DNSSEC. In the meantime it appears that in practice TLS handshakes are far more difficult to MitM successfully, particularly if the attacker has only one chance to intercept the browser's first contact with a regularly visited website such as Gmail. > It's a novell idea, but if you just want to avoid trusting ICANN or > Verisign, you are better of setting up a third-party trust group that > takes TLS pubkeys (or TLSA records) and verifies/distributes those, > whether it is submitting to the EFF observatory, rbl lists, trust > ambassadors or otherwise. I suspect Moxie is familiar with these concepts as he is the guy who built Convergence. http://convergence.io/ > But using TACK to pretend there is no need > for the user to consult anyone else is pretty dangerous, Does TACK actually propose not consulting anyone else? I don't see it in the I-D. > especially with hardcoded algos and timings all over the place, This sounds like a valid criticism. > and no trust model that scales, I don't understand that. I see no scalability bottleneck here. > and corner cases with never before visited sites. Yes, it does not solve everything. But neither does anything else. - Marsh From trevp@trevp.net Wed May 30 09:00:43 2012 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 D524B11E80B8 for ; Wed, 30 May 2012 09:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=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 m+CXp2Jkg5Ig for ; Wed, 30 May 2012 09:00:43 -0700 (PDT) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by ietfa.amsl.com (Postfix) with ESMTP id C271B11E8083 for ; Wed, 30 May 2012 09:00:42 -0700 (PDT) Received: by ghbz22 with SMTP id z22so4527861ghb.27 for ; Wed, 30 May 2012 09:00:42 -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:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=suxRlKQTGrzN8eD8QslQWTP5R4XERCNKJOdXg5o2ZUc=; b=TVs8B2t0d4l/HEKp6zyvOFABrxODpWvJZD94bvXRcuVkiqJr9E9ziVFRGW0C3/BsLI RndiCYFuSqUFTSPR1JCQq5Cm+CiJfcelZmXolWqOo08aY1d64ekM491T+4xgUuxIMaP9 qWdgRqVVgsB9Xk+uHhm3Gn/2mXPS7ZfSpOCBziIbZGkF7dtqh9qml09BRKxzbPWW4lO3 0oXm+QPrH64PGDcN0hPSybnrGouaB1J1u+o007Y47vapzF1Z2C5giwyQKiniFzEEv47s UISK3VyRrsRjn96PneDBuzPoLIY1ygnVE0Q2uC/7Xth0MTQ6o4iTj7mqu2XhQn9B2gS0 +UwA== MIME-Version: 1.0 Received: by 10.50.207.36 with SMTP id lt4mr11403666igc.5.1338393641784; Wed, 30 May 2012 09:00:41 -0700 (PDT) Received: by 10.64.163.70 with HTTP; Wed, 30 May 2012 09:00:41 -0700 (PDT) X-Originating-IP: [66.127.230.131] In-Reply-To: References: Date: Wed, 30 May 2012 09:00:41 -0700 Message-ID: From: Trevor Perrin To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnLa9w6dOXhz1sLRwb9ushZ7INavKhNixQytFur/q1GEP8lNIozDtCgumLnoBVfFmlXXi/7 Cc: tls@ietf.org Subject: Re: [TLS] draft-perrin-tls-tack-00 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, 30 May 2012 16:00:44 -0000 Hi Paul, So, you're arguing that since TACKs are not signed by an authority, there is "no one backing them up", and we are "pretend[ing] there is no need for the user to consult anyone else". Not true! TACK pins can be encoded into small identifiers and distributed through 3rd-party trust infrastructures. This is a different, more flexible approach to 3rd-party trust than using signatures. - You're also arguing that instead of TACK pins, it would be better to distribute "DANE pins" (aka TLSA records) via DNS. If DNS was secure, we would be interested in distributing TACK pins through it. TACK pins have the advantage (compared to DANE pins) of allowing TLS key changes without needing CA trust or DNS updates. Unfortunately, DNS is not secure at present. So you're proposing that instead of key-continuity via a TACK TLS handshake, it would be better to do key-continuity via DANE pins retrieved over unsecure DNS. There are several problems with that: - DANE usages 2 and 3 can actually disable a client's default path validation, which would be a security hole in this case (and seems risky in general?). - If the pin is delivered outside the protection of the TLS handshake it is easier for an attacker to set a bad pin. - TLSA record retrieval could fail due to DNS middleboxes. - DANE pins do not have the same flexibility as TACK pins. So, we think that TACK is a better approach for supporting both key-continuity pinning as well as 3rd-party trust infrastructure. Trevor On Tue, May 29, 2012 at 9:41 AM, Paul Wouters wrote: > On Tue, 29 May 2012, Trevor Perrin wrote: > >> (2) TACK uses signing keys which are not CA keys. =A0Thus, TACK allows >> for TLS key changes without needing trust in CAs. > > > Which is also the *problem* of TACK. Since the TACK pins are signed by > entities for which no trust anchors are distributed, I do not see > much value of TACK pins over the TLS public key. Both are obtained > inside the TLS connection and come with no one backing them up to > ensure you're not MITM'ed. You might think TACK keys can be handled > better by larger SSL farms, but then you have to consider why those > large SSL farms are not able to use the same SSL pubkeys everywhere > either and why the same issue would not affect TACK keys. > > I'd say using a TLSA record, without any kind of trust anchor, would > have benefits over TACK, as you can get DNS answers from unexpected > sources that are not as easy to MITM. With DNS records, you already > have a flexible caching system in place without the need for new code, > or hardcoded timing values in an RFC. > > >> (3) TACK has additional safeguards to reduce the risk of bad pins >> affecting site availability. =A0In particular, the "pin activation" >> algorithm places a limit on pin activation periods, and scales up >> slowly so that brief exposure to a bad pin cannot cause long-lived >> problems. > > > I'm not sure how that gains you anything compared to TLSA records with > TTL values? How long any key has been used in the past is never any > guarantee for its correctness of today's use. With TLSA records, you can > only get exposed to a "bad pin" if the administrator makes a mistake, > which is something that is still widely discussed on the dane list with > respect to hard vs soft fail errors and how to actually convey "bad TLS" > to the enduser. > > >> (4) TACK's "break signatures" lets a server publish an emergency >> signal that a pin is compromised and should not be trusted. =A0TACK's >> "min_generation" lets a server publish an emergency signal that a TLS >> key is compromised. =A0These signals can be cryptographically verified >> using the pin, and could be gathered and distributed by 3rd-party >> trust infrastructure. > > > Then use rbl whitelists to store these pins in 3rd party DNS trees? > > >> (5) The TACK "expiration" field allows use of short-lived TACKs as an >> alternative way to mitigate the risk of TLS key compromise without >> relying on revocation messages. > > > Short TTLs on TLSA records? > > >> (6) TACK pins are small and contain embedded revocation info >> (min_generation), so they are a compact form for distributing trust >> information (e.g. via DNS, browser preload lists, Convergence, etc). > > > Ugh. so you figured out this DNS distribution method too. Then why do > still think a TLS server/client modification is needed along with a new > cryptographic identifier when we already have a way of storing TLS pubkey= s > in DNS (even if you ignore DNSSEC). How is storing a TACK pubkey any > different? You could write the draft using TLSA records with the same > initial timing constraints if you deem those better then trusting ICANN > and Verisign without inventing any TLS extensions and without adding > another level of trust indirection using a new keying scheme. > > >> (7) TACK supports 3rd-party-assisted pinning, where a 3rd-party (which >> could be a CA or any other entity) provides TACKs. > > > Like DNSSEC? Or DLV? > > >> (b) The most complex part of TACK (pin activation) actually >> simplifies deployment, by automatically scaling up the activation >> period. > > > But DNSSEC allows the publisher of the TLS pubkey, the only entity > which has absolute knowledge over their intentions with the key, to > announce these intentions to everyone, without third party delays, > agreements, redistribution, or "x out of y" trust requirements. Anyone > else making assumptions about its key use runs the rsk of being wrong, > and is delayed in making any such risky statements about the keys. > > It's a novell idea, but if you just want to avoid trusting ICANN or > Verisign, you are better of setting up a third-party trust group that > takes TLS pubkeys (or TLSA records) and verifies/distributes those, > whether it is submitting to the EFF observatory, rbl lists, trust > ambassadors or otherwise. But using TACK to pretend there is no need > for the user to consult anyone else is pretty dangerous, especially > with hardcoded algos and timings all over the place, and no trust > model that scales, and corner cases with never before visited sites. > > Paul From rob.stradling@comodo.com Thu May 31 04:13:16 2012 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 8FE6C21F8631 for ; Thu, 31 May 2012 04:13:16 -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 WxoVuw1fjSvI for ; Thu, 31 May 2012 04:13:15 -0700 (PDT) Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE4721F853E for ; Thu, 31 May 2012 04:13:15 -0700 (PDT) Received: (qmail 28572 invoked from network); 31 May 2012 11:13:14 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 31 May 2012 11:13:14 -0000 Received: (qmail 29173 invoked by uid 1000); 31 May 2012 11:13:13 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 31 May 2012 12:13:13 +0100 Message-ID: <4FC75249.3050805@comodo.com> Date: Thu, 31 May 2012 12:13:13 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: Yngve Nysaeter Pettersen References: <20120509153513.11861.32080.idtracker@ietfa.amsl.com> In-Reply-To: <20120509153513.11861.32080.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: [TLS] CRL Stapling? (was Re: I-D Action: draft-ietf-tls-multiple-cert-status-extension-00.txt) 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, 31 May 2012 11:13:16 -0000 Yngve, IIRC, when Opera does an online revocation check, it currently checks CRLs for intermediate CA certificates and OCSP for end-entity certificates. This makes sense because: - CRLs covering intermediate CA certificates tend to be roughly the same size (sometimes smaller!) as the equivalent OCSP Responses (since it's quite rare for intermediate CA certificates to be revoked). - Possessing a current CRL means you won't have to do an online revocation check if you encounter another certificate issued by the same issuer. How would you feel about updating the multi-stapling I-D so that it permits CRLs to be stapled (with a note to implementers that they should only staple CRLs that are deemed to be "small enough")? Simply adding something like "case crl_multi: CRLList;" to your definition of CertificateStatus.response would be problematic, because it would require the server to staple a (potentially huge!) CRL for the end-entity certificate too. So... How about changing the scope of the multi-stapling I-D so that it *only* covers the intermediate CA certificate(s) in the chain? With this approach, an end-entity OCSP Response could be stapled using the RFC6066 TLS extension, and the intermediate CRL(s) could be stapled using the new multi-stapling TLS extension. (End-entity certificate stapling is already defined in RFC6066 and this existing TLS extension is already supported by many clients and servers. So why not make the multi-stapling TLS extension complement it, rather than replace it?) On 09/05/12 16:35, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. > > Title : The TLS Multiple Certificate Status Request Extension > Author(s) : Yngve N. Pettersen > Filename : draft-ietf-tls-multiple-cert-status-extension-00.txt > Pages : 9 > Date : 2012-05-09 > > This document defines the Transport Layer Security (TLS) Certificate > Status Version 2 Extension to allow clients to specify and support > multiple certificate status methods. Also defined is a new method > based on the Online Certificate Status Protocol (OCSP) that servers > can use to provide status information not just about the server's own > certificate, but also the status of intermediate certificates in the > chain. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tls-multiple-cert-status-extension-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-multiple-cert-status-extension-00.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online