From nobody Fri Apr 1 00:54:59 2016 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 6625A12D175 for ; Fri, 1 Apr 2016 00:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJjACfMec3_i for ; Fri, 1 Apr 2016 00:54:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8E5C12D0E6 for ; Fri, 1 Apr 2016 00:54:55 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 99EC26317D; Fri, 1 Apr 2016 07:54:54 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.2.102]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u317sqn2008548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 Apr 2016 03:54:53 -0400 Message-ID: <1459497291.3034.20.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Peter Gutmann , "" Date: Fri, 01 Apr 2016 09:54:51 +0200 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 01 Apr 2016 07:54:54 +0000 (UTC) Archived-At: Subject: [TLS] TLS 1.2 Long-term Support Profile vs HTTP/2.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 07:54:57 -0000 On Wed, 2016-03-16 at 12:36 +0000, Peter Gutmann wrote: > After a number of, uh, gentle reminders from people who have been > waiting for > this, I've finally got around to posting the TLS-LTS draft I > mentioned a while > back.  It's now available as: > > > http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt I liked the idea of an LTS profile for TLS 1.2, however I just realized that RFC7540 [0] blacklists (with no rationale) 3 out of the 4 LTS ciphersuites and I'm wondering how practically useful will be that profile. regards, Nikos [0]. https://tools.ietf.org/html/rfc7540#appendix-A From nobody Fri Apr 1 05:19:40 2016 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 1DD0212D12B; Fri, 1 Apr 2016 05:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-1iQSncvpl0; Fri, 1 Apr 2016 05:19:35 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75F2912D129; Fri, 1 Apr 2016 05:19:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C49EFBE2D; Fri, 1 Apr 2016 13:19:33 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gC4iKTW9eOE; Fri, 1 Apr 2016 13:19:31 +0100 (IST) Received: from [10.87.49.100] (unknown [86.46.30.32]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EAB77BE29; Fri, 1 Apr 2016 13:19:30 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1459513171; bh=4NTyUJma0X81ea8A37uKofdBVgJRGiGwEgIqZsiXUkQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=WD/UOxa42Xb3o/bPLROxyycNJfnogxJBBF+8uELcqOzQ27H/QuSj3L0Xu10zgZyn7 VdPRLat4zPnBKRukg/nm//UYZLrRbF6X3HlpVj7H4AIbkSdeP8jKSUibm+MwWnyjZ/ QNYU5D78pVP85XMuOfFUZbqc93LvfnkqSVXozGMM= To: Sean Turner , "" References: <56F2B2E7.1060809@cs.tcd.ie> <56F3B9CC.8050305@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56FE6751.7040100@cs.tcd.ie> Date: Fri, 1 Apr 2016 13:19:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020109010206030208040207" Archived-At: Cc: draft-ietf-tls-falsestart@ietf.org Subject: Re: [TLS] AD review of draft-ietf-tls-falsestart-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 12:19:39 -0000 This is a cryptographically signed message in MIME format. --------------ms020109010206030208040207 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Sean, Thanks for moving this along, On 01/04/16 02:19, Sean Turner wrote: > On Mar 24, 2016, at 05:56, Stephen Farrell > wrote: >>=20 >>=20 >> Hiya, >>=20 >> Thanks for the speedy response... >>=20 >> Again #3 below is what I care about, the other stuff isn't a big >> deal. >>=20 >> On 24/03/16 00:38, Bodo Moeller wrote: >>> "Stephen Farrell" : >>>=20 >>>> (1) Why experimental? Wouldn't this be better as info and >>>> documented as "here's a spec for a thing that's widely >>>> deployed." I fear we may get questions like "what's the >>>> experiment?", "where's this going in future?" if this aims for >>>> experimental, and info may avoid that esp if we really want >>>> people to move to TLS1.3. I also didn't see list discussion >>>> about what kind of RFC to aim for, but maybe it was discussed >>>> at a meeting or interim? (Apologies if I missed that in my scan >>>> of the list.) >>>=20 >>> I'm myself torn between "Experimental" and "Informational" >>> (certainly not "Historic" because the spec has not been >>> superseded by a more recent one and is not obsolete for any other >>> reason [ https://tools.ietf.org/html/rfc2026#section-4.2.4], >>> unless we somehow manage to complete TLS 1.3 standardization >>> before this). Taking into account how False Start is actually >>> deployed (and taking into >>=20 >> Right. TLS1.3 will hopefully make this historic, so we could just=20 >> park this in the RFC editor queue and have both RFCs emerge on the=20 >> same day with this one as Historic. With did that with DKIM (4871)=20 >> and DomainKeys (4870, Historic) for example. Note that I'm not >> arguing for doing that, just raising the option if that's what the >> WG want and if the list hasn't discussed it. I assume though that >> the WG don't want to take this route so no need to discuss it more >> in that case. >>=20 >>> account that we expect it to eventually be replaced by a TLS 1.3 >>> mechanism) and how our I-D is cited in research papers on TLS, >>> "Experimental" sounds right to me: the spec really is part of a >>> research and development effort [=20 >>> https://tools.ietf.org/html/rfc2026#section-4.2.4]. >>> "Informational" wouldn't be wrong either. >>=20 >> I think the latter matches much better myself, as there really is=20 >> no experiment being done here and we're not gonna develop this any=20 >> more once TLS1.3 is done, but whatever - I'm ok with saying that=20 >> the WG just wanted experimental. But you'll likely get asked this=20 >> again and again. At least we can now point at this thread and say=20 >> that it was discussed on the list though. (Which was partly why I=20 >> asked:-) >>=20 >> It'd be no harm though if a couple of others chimed in on this just >> to there's recorded opinion from more than just the AD and an >> author. >>=20 >> We can change to informational at the end of LC if need be, i.e.,=20 >> there's no need to hold stuff up for that and such a change then=20 >> doesn't add any delay. >=20 >=20 > This draft started out as Informational and then we switched it > Experimental. The WG has not considered whether we should publish > this should go Historic now, be held and publish as Historic later, > etc. >=20 > How do folks feel about Historic vs Experimental vs Informational? >=20 > If we=E2=80=99re going to move it to Historic, then we=E2=80=99ve got a= couple of > options: >=20 > 0) As described above: Get it approved by the IESG, hold it in RFC > editor=E2=80=99s queue, and publish it as historic at the same time TLS= 1.3 > is published. >=20 > 1) Approve it, get it published, and then make it Historic with > another draft. >=20 > 2) Approve it, get it published, and then make it Historic with an > IESG initiated Protocol Action, which is a message that the IESG > initiates requesting the status be changed similar to an IETF but > requires no draft. >=20 > (there=E2=80=99s probably some other options like an adding an IESG not= e/new > section that says =E2=80=9Cthis goes to historic when TLS 1.3 is publis= hed, > but I think the above three options seem more realistic.) >=20 > Option 0 is probably the least amount of work. We just hold it, but > in some sense I kind of tend to think that we=E2=80=99re punishing the > authors. There=E2=80=99s nothing they=E2=80=99ve really got to do, but= it feels > somehow like we=E2=80=99re hitting them upside the head with the proces= s > two-by-four. >=20 > Option 1 would be a total PITA. People say that we can get a draft > published quickly if we (the royal we) really want to, but my > experience is otherwise. >=20 > Option 2 is something that I don't think we had in our toolkit when > DKIM was being worked on. The draft gets published the authors can > move on and we (the process moths) can make sure the draft gets moved > to Historic. >=20 > What do the WG members think about the options of moving to historic? > Personally, I=E2=80=99d advocate option 2 because it keeps the work loa= d on > the chairs/AD :) I'm fine with any of the above. >=20 > ~snipped 2~ >=20 >>>=20 >>>> (3) Why is there no description of the reasons for all the MUST >>>> only use whitelisted and for the choices that are >>>> whitelisted? Wouldn't omitting that tend to lead people to use >>>> this more badly? >>>=20 >>> Well, I tried to capture the general reasoning in the spec -- but >>> not the detailed reasons for the specific choices suggested, >>> because that again would just go stale quickly. >>=20 >> Where are those general reasons stated? I don't see =E2=80=98em. >=20 > The whitelisted options are described in the bullets in s4 and those > point to s5.* I'm still not seeing it. I do see things listed, but I don't see any reasons why the things are listed. The closest I see we get for now is: "The TLS protocol already relies on such a security property for authentication -- with False Start, the same is needed for encryption." But there's quite a gap between that statement and the set of rules given here. >=20 > It=E2=80=99s stuff like don=E2=80=99t use suspect symmetric ciphers. But surely that's tautological? When would we ever recommend using dodgy stuff? I think what's missing is a description of or reference to what is particularly going to go wrong if you use a ciphersuite with known attacks and do false-start. That'd give the reader a chance to do an informed evaluation for themselves as to whether or not some ciphersuite is or is not safe with false-start. (And that evaluation will be done at various points in future.) >=20 >>> In particular, I think this is an important observation in the >>> I-D: >>>=20 >>> "If heuristically a small list of cipher suites and a single >>> protocol version is found to be sufficient for the majority of >>> TLS handshakes in practice, it could make sense to forego False >>> Start for any handshake that does not match this expected >>> pattern, even if there is no concrete reason to assume a >>> cryptographic weakness." >>=20 >> That may be important but it doesn't address the issue about which=20 >> I'm asking. >>=20 >>>=20 >>> So the whitelists should have algorithms that are actually used >>> in practice and that don't have critical weaknesses, but why >>> exactly those particular algorithms happen to get used in >>> practice is mostly out of scope here. >>=20 >> Why is the logic behind such security relevant choices out of >> scope? That makes no sense to me. Let's imagine a new ciphersuite >> is invented and folks start to wonder whether or not it's ok to >> whitelist that for false-start - wouldn't they expect this document >> to explain (maybe mostly via references) why some ciphersuites are >> not good enough to whitelist? I would expect that to be clear. >>=20 >> And to be clear, I'm not asking for an essay, but more like some >> text in the intro saying "False start is not safe for a ciphersuite >> that has properties such as because of . >> See [refs] for full details." >>=20 >> For added clarity it'd also be good to have something like:=20 >> "Ciphersuites MUST have to be safe to=20 >> whitelist for false-start." >>=20 >> If figuring out text for the above is very hard, then I do think >> that would indicate a real issue with this spec. If figuring that >> out is just a minor bit of tedium, then I think it's worthwhile so >> that future readers of the RFC can understand what's going on here, >> which I don't think is the case from the current text. >=20 > I think this text is already present: >=20 > Clients MUST NOT use the False Start protocol modification in a=20 > handshake unless the cipher suite uses a symmetric cipher that is=20 > considered cryptographically strong. >=20 > In the key exchange algorithms and client certificate type security > considerations, there=E2=80=99s: >=20 > The recommended whitelists are such that if cryptographic algorithms=20 > suitable for forward secrecy would possibly be negotiated, no False=20 > Start will take place if the current handshake fails to provide=20 > forward secrecy. >=20 > .. and .. >=20 > Forward secrecy can be achieved using ephemeral Diffie-Hellman or > ephemeral Elliptic-Curve Diffie-Hellman ... >=20 > If we summarize these in the Introduction we=E2=80=99re good? No, I'm on about missing text not placement of text. Again if we added something like "False start is not safe for a ciphersuite that has properties such as because of . See [refs] for full details" then we'd be done because a reader could use that to analyse whether or not it is ok to use a future ciphersuite (or a current one, being re-evaluated in the future) with false-start. Cheers, S. PS: If I'm just not managing to explain myself well here, we can chat about it in B-A. >=20 > spt >=20 >> Cheers, S. >>=20 >>=20 >>>=20 >>> Bodo >>>=20 >>>> That could be done with some explanatory text and using some of >>>> the references below maybe. Or, if we don't really want new=20 >>>> folks to implement this (do we?) then just saying that might >>>> mean it's ok to not explain the "why." (And then you could also >>>> address #1 above then by issuing this as an historic RFC too if >>>> you wanted.) >>>=20 >>=20 >> _______________________________________________ TLS mailing list=20 >> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 >=20 --------------ms020109010206030208040207 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA0MDEx MjE5MjlaMC8GCSqGSIb3DQEJBDEiBCD85tif9uCKaOInQA03C8x4Gg6P2yBcenLmL0hkv5d8 CjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCL6jk+oKLoHsbe4zyxPamI5F/qYpZ+mhpj+tYnpjHpMHAfyObG7zqR jAWV5LHfUY/c/650yE0SpCyzcEVVm9XtVoHPAqpgL71xg6C+sRABVh5f8mTbzh/vFRFYmbXB iW/980F+KcZrUN50Ex96KoC+S0rmFctNY05L1/qTOfe3w+G/vwkrcXPY4sZhlaQPNBiKlyEV 0a8caTEi7rvcxWJUV3etfT6J8FtHfyKymbsookF8GRiq5frWxueRdBxwxHYPmxncsj4ucQlK Y9cAIWykP3OpV32F8bBRsgYg/Jg5zUeYR0lvZhD1nmrIIAflfS1aNeOIoxiZCDKn0x7LSEYw AAAAAAAA --------------ms020109010206030208040207-- From nobody Fri Apr 1 05:27:10 2016 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 CDCA812D115 for ; Fri, 1 Apr 2016 05:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaqSZvrXUxqw for ; Fri, 1 Apr 2016 05:27:07 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2167712D146 for ; Fri, 1 Apr 2016 05:27:07 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id s5so37153083qkd.0 for ; Fri, 01 Apr 2016 05:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t8/dzCgUDQ1hFrusb7WuQ7n1vY1bUYdBjOZZC7HNsbM=; b=FDdA2ZB2D45XOzZ+LBKoXmIe8BI87eCbtHNv4tN68Cck1eeZydRNxvX4rZ7ZQSIMwT XVBX6SUX8QVT4PmAfSJeqTiLCvjWVw4uXgXT+VFzQHQpXH/SfLYUu50nUq34DV4cgP3j ymQbL/ZE3+vaL86KQtiEmBH8bMsTXX6sYinE0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t8/dzCgUDQ1hFrusb7WuQ7n1vY1bUYdBjOZZC7HNsbM=; b=EhX3okKUbtjF9Pyl7E27L3m5Zkqi6EpYquNGiQpGwZaJ8w7LGbji9+2oEuQVUCE6gV 4maM/v7FxgiNPAmNKBIj3lew3wa5INpBiD5h+0b+kPSOFN4lHoUP4F6fQmetCS2MXbvd MjUGTyq35AvnMWw4KySW2dWE12cDKiBW+l5c1gaF12cUCG2Z58AKZqPzl3Wn8NpYCFmv GsadM0G03m+/J6uRXOxUMEVuj+eerxhMsa9Na7CzLoABk0iu816MgAOSXa/r3brgLSss E0h88ljslyfDXvn0mYF4ezBUSLf0W+5Q4UgVvGj6/R6/hRHhSHnN5uoRBoSykybT+Vxc 0CFw== X-Gm-Message-State: AD7BkJKIwqqeuRvyOQywzc5MSbZf0zWckJs2M462n/SJMy2YzZj9fLmggmwEnAlLi/Onxg== X-Received: by 10.55.75.212 with SMTP id y203mr18732027qka.3.1459513626152; Fri, 01 Apr 2016 05:27:06 -0700 (PDT) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id d187sm5948414qhc.38.2016.04.01.05.27.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2016 05:27:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <201604010107.51996.davemgarrett@gmail.com> Date: Fri, 1 Apr 2016 08:27:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <59521A44-DDF9-4038-AB48-37EE2C025EF8@sn3rd.com> References: <56F2B2E7.1060809@cs.tcd.ie> <56F3B9CC.8050305@cs.tcd.ie> <201604010107.51996.davemgarrett@gmail.com> To: Dave Garrett X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-tls-falsestart@ietf.org, "" Subject: Re: [TLS] AD review of draft-ietf-tls-falsestart-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 12:27:09 -0000 > On Apr 01, 2016, at 01:07, Dave Garrett = wrote: >=20 > handwaves an informational RFC to standards track (RFC5289: ECC AES = GCM) This bit we =E2=80=9Cfix=E2=80=9D by including what=E2=80=99s called a = =E2=80=9CDOWNREF" in the IETF LC, as per RFC 3967.=20 spt= From nobody Fri Apr 1 06:31:40 2016 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 9B15312D59C; Fri, 1 Apr 2016 06:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwvhFc86M28c; Fri, 1 Apr 2016 06:31:36 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6748112D590; Fri, 1 Apr 2016 06:31:36 -0700 (PDT) Received: by mail-pa0-x235.google.com with SMTP id fe3so90558497pab.1; Fri, 01 Apr 2016 06:31: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-transfer-encoding; bh=xandkmgnO/meeGspiVDwT4UZk/iC71o4H3Cw5hgCT9E=; b=r5dycSdhefvxA8rZJ0D7rRuQQTmWTJcmKYC2vt12L8UYfvtJaMn4InBXBLzqNTF16r FOPcR2kor8dJZhKRLgKr0eUd6Aw42WOBwP7UZwsIOIGtcfYr/dNX7ff5EW6nQCECRlUX qk3oCaYxk2ZoyCLL16Nb3N7VwlJjNHtXW8wJIc+EXQMKPwe36jMLn77c/LmdM+ewusAP FBOOt5CM6IOdhqH1culLBzX8sdfwgJMsWqwvS8hMzHGeXS/QoA1SK5mnzaskD3KqLdnI vsg2frtfbKxrBLJYUgJ+Xm4tJiOXQplhMJOmh8/t81de3VJudso621bk8gdRBTd3/jQ4 UuLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=xandkmgnO/meeGspiVDwT4UZk/iC71o4H3Cw5hgCT9E=; b=Astu1SSQ4+rLhCM3RqyAhsuh7nEjXn18BXUYtqcFBJyH4+cK8cRpiRXFgtinps9VkN x0/SKCImL4atbVHjyToObm6Kq9EQiOhAJKqz5FsWGADhXsE8StQCO0ucGvWAz5LBB8Ic +cWr3Hm4/XEFUjGvnG/hY+174XZjtWGMYckDhnxoQWk1IBxXxI+x3TBnmUs/1gPUn9t0 tMlaIM9wuk+nYUQxQ7Kq5RWGrieOBmmldJ45WsaRB1ThUVA+dwUz6i2op9wkQcZgBJ7C NorHXureawDicHqPDCqoTQXd8RgAR8pyxsNTLWTGedUoI4uJhwK58x1UtOxFdHdFknAs VYmw== X-Gm-Message-State: AD7BkJItqQpeywAHO5R5+dvgjXzHH5grnXXYs1J41prZsSjSAcpQfDx1YDz5G8OUA0/NfOUHhxl/N5vllf9ceQ== MIME-Version: 1.0 X-Received: by 10.66.176.139 with SMTP id ci11mr30724144pac.68.1459517495963; Fri, 01 Apr 2016 06:31:35 -0700 (PDT) Received: by 10.66.83.229 with HTTP; Fri, 1 Apr 2016 06:31:35 -0700 (PDT) In-Reply-To: References: <56F2B2E7.1060809@cs.tcd.ie> <56F3B9CC.8050305@cs.tcd.ie> Date: Fri, 1 Apr 2016 06:31:35 -0700 Message-ID: From: Peter Bowen To: Sean Turner Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-tls-falsestart@ietf.org, "" Subject: Re: [TLS] AD review of draft-ietf-tls-falsestart-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 13:31:38 -0000 On Thu, Mar 31, 2016 at 6:19 PM, Sean Turner wrote: > > 0) As described above: Get it approved by the IESG, hold it in RFC editor= =E2=80=99s queue, and publish it as historic at the same time TLS 1.3 is pu= blished. I'm not a fan of this option simply because draft-ietf-tls-negotiated-ff-dhe has been stuck is MISSREF state in the RFC editor queue for months waiting on this draft. I don't think there is any question the ffdhe draft is forward looking and I, for one, would like to see it published before TLS 1.3. Thanks, Peter From nobody Fri Apr 1 09:01:09 2016 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 9538512D709 for ; Fri, 1 Apr 2016 09:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nph4HPkThTnL for ; Fri, 1 Apr 2016 09:01:05 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD72C12D70D for ; Fri, 1 Apr 2016 09:00:54 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id d68so31892930ywe.1 for ; Fri, 01 Apr 2016 09:00:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=66WK1DjzygRU/fJ78lBEPijchEovcmxy73k4SJEJloU=; b=USsDpQUDRaF3P6HVBM6R1EuPSkrPZRwaIqlB6ggE/U6YW+8YWS1tiPGn6fyEhan7rP epVHBUhvqsWvfaxnyghXTuDTuMqtKiYqcathfDM0n0E8zUjI8BSI54DQtIwPYrRbNNB1 CxNPO+M+1B9d76j+4vP62tPqRaoQREPc8xbIM69jjjXIin2RAPbTJoSEdgfbSls2WznN rYLyX+bu+1OMmwUbatMCkJj07QQGTPuV7dRRVdjgPkd+Ruc3dvd/e5qfkC0n65BAtRxT UEI/KSGmh8SJQ8YH7ChEV5ox1bN3gBrMyJn6TueNAYEiY8QAWpanyazXux+dK4+dTSQz QkzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=66WK1DjzygRU/fJ78lBEPijchEovcmxy73k4SJEJloU=; b=e2XwwK9Hdc+bXccAA6flTDQeXbh7xOI+IOJLObndRr9w8VQmINODag6afE56+ZjG+D o8/cvaFVh1VwMReUdoAZ2VzXffSAslAiDC0ewvwpTooR2KBh2IuH230wRxdWyA1Omza/ 9RVJ2XF1Hupqwqxk3AqUeJ2wdlA5QAHOkXvFULKpXlN98Bd0sUl/IFvUe4bzknuoukdp /SUwzJZ43hFbq3FibmvxxQKOYNu67Sj2hy4xY8yGCSOlkU8yA2FUVMzBU9IhOork6OLl 7zwGzXPEDoAYebWTcOPYUOQD8RX/LRB+QWIC18Wf2IecThsGVmmK6tAtWDSbTuKRcSLa ZSkg== X-Gm-Message-State: AD7BkJJ1tEm9zGmGoU7OGoLQhj8ChP2L8DwX8A8dH3BEIqricqoWt+1Yer83d8BGH4WjqP5X0V1MgiiXowUpvA== X-Received: by 10.37.230.67 with SMTP id d64mr3701361ybh.159.1459526452840; Fri, 01 Apr 2016 09:00:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Fri, 1 Apr 2016 09:00:13 -0700 (PDT) In-Reply-To: <56FE6751.7040100@cs.tcd.ie> References: <56F2B2E7.1060809@cs.tcd.ie> <56F3B9CC.8050305@cs.tcd.ie> <56FE6751.7040100@cs.tcd.ie> From: Eric Rescorla Date: Fri, 1 Apr 2016 13:00:13 -0300 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=94eb2c0afa10c39ff4052f6e7bf4 Archived-At: Cc: draft-ietf-tls-falsestart@ietf.org, "" Subject: Re: [TLS] AD review of draft-ietf-tls-falsestart-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 16:01:08 -0000 --94eb2c0afa10c39ff4052f6e7bf4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 1, 2016 at 7:19 AM, Stephen Farrell wrote: > > > Forward secrecy can be achieved using ephemeral Diffie-Hellman or > > ephemeral Elliptic-Curve Diffie-Hellman ... > > > > If we summarize these in the Introduction we=E2=80=99re good? > > No, I'm on about missing text not placement of text. Again if > we added something like "False start is not safe for a ciphersuite > that has properties such as because of . > See [refs] for full details" then we'd be done because a reader > could use that to analyse whether or not it is ok to use a future > ciphersuite (or a current one, being re-evaluated in the future) with > false-start. > The issue isn't primarily the ciphers themselves, it's the security properties of False Start. Specifically, TLS is intended to allow a client and server to negotiate the most preferred joint cipher suite, even if they also support weaker cipher suites, even in the face of active attack [0]. In TLS 1.2, this guarantee is enforced by the Finished messages and therefore the client isn't able to verify it at the time it sends its second flight [1]. Thus, when you are doing False Start, the client has no guarantee that an attacker hasn't forced him into a much weaker cipher suite (potentially the weakest cipher suite that the client supports). Of course, the handshake won't complete, but the client will have already sent data under the weaker cipher suite. The restrictions here are targeted at minimizing the exposure due to potentially negotiating weaker ciphers with the general idea being that the weakest cipher acceptable for false start is not too far away from the best cipher. So, it's not really practical to pair it to specific cipher properties. -Ekr [0] Note, this protection starts to break down if the weakest joint cipher suite is really weak. [1] This is why TLS 1.3 signs the entire server's second flight and why False Start is redundant in TLS 1.3. > > Cheers, > S. > > PS: If I'm just not managing to explain myself well here, we can > chat about it in B-A. > > > > > spt > > > >> Cheers, S. > >> > >> > >>> > >>> Bodo > >>> > >>>> That could be done with some explanatory text and using some of > >>>> the references below maybe. Or, if we don't really want new > >>>> folks to implement this (do we?) then just saying that might > >>>> mean it's ok to not explain the "why." (And then you could also > >>>> address #1 above then by issuing this as an historic RFC too if > >>>> you wanted.) > >>> > >> > >> _______________________________________________ TLS mailing list > >> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c0afa10c39ff4052f6e7bf4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 1, 2016 at 7:19 AM, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:
> Forward secrecy can be achieved using ephemeral Diffie-Hellman or
> ephemeral Elliptic-Curve Diffie-Hellman ...
>
> If we summarize these in the Introduction we=E2=80=99re good?

No, I'm on about missing text not placement of text. Again = if
we added something like "False start is not safe for a ciphersuite
that has properties <A,B,C> such as <example> because of = <problem>.
See [refs] for full details" then we'd be done because a re= ader
could use that to analyse whether or not it is ok to use a future
ciphersuite (or a current one, being re-evaluated in the future) with
false-start.

The issue isn't primar= ily the ciphers themselves, it's the security properties of False Start= . Specifically, TLS =C2=A0is intended to allow a client and server to negot= iate the most preferred joint cipher suite, even if they also support weake= r cipher suites, even in the face of active attack [0]. In TLS 1.2, this gu= arantee is enforced by the Finished messages and therefore the client isn&#= 39;t able to verify it at the time it sends its second flight [1]. Thus, wh= en you are doing False Start, the client has no guarantee that an attacker = hasn't forced him into a much weaker cipher suite (potentially the weak= est cipher suite that the client supports). Of course, the handshake won= 9;t complete, but the client will have already sent data under the weaker c= ipher suite.

The restrictions here are targeted at= minimizing the exposure due to potentially negotiating weaker ciphers with= the general idea being that the weakest cipher acceptable for false start = is not too far away from the best cipher. So, it's not really practical= to pair it to specific cipher properties.

-Ekr

[0] Note, this protection starts to break down i= f the weakest joint cipher suite is really weak.
[1] This is why = TLS 1.3 signs the entire server's second flight and why False Start is = redundant in TLS 1.3.

Cheers,
S.

PS: If I'm just not managing to explain myself well here, we can
chat about it in B-A.

>
> spt
>
>> Cheers, S.
>>
>>
>>>
>>> Bodo
>>>
>>>> That could be done with some explanatory text and using so= me of
>>>> the references below maybe. Or, if we don't really wan= t new
>>>> folks to implement this (do we?) then just saying that mig= ht
>>>> mean it's ok to not explain the "why." (And = then you could also
>>>> address #1 above then by issuing this as an historic RFC t= oo if
>>>> you wanted.)
>>>
>>
>> _______________________________________________ TLS mailing list >> TLS@ietf.org= https://www.ietf.org/mailman/listinfo/tls
>
>


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


--94eb2c0afa10c39ff4052f6e7bf4-- From nobody Fri Apr 1 15:47:32 2016 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 E4F0112D5C8 for ; Fri, 1 Apr 2016 15:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkScQJ872QNj for ; Fri, 1 Apr 2016 15:47:28 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E37F212D5AB for ; Fri, 1 Apr 2016 15:47:27 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id p188so64418560lfd.0 for ; Fri, 01 Apr 2016 15:47:27 -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:from:date:message-id :subject:to:cc; bh=aintNYOtcjXMr2mFcXsT63vXO+hsU7hJsFCOLSw8Wts=; b=KFFDoSAfgBwHGomtUJKKpyQZKAH/4zDKIulgfytPkutS77gbceVCmj0g8QAL5NC9R8 MQ6WgBUwD2VHQ7OcN77Bo25PjbMtDtBIZijAI1MsyXApKw9dw268I7xckWGRYNZ5JI+1 RMa0Xrhnwxgf7M/u0tRjVpnX5NXwvCZQpB9sQ7/HuDEebmfLilK7PehYqjHBrql44wNQ CF5sZpPswJe3nUQNFSt4HR3TXrgrRQd1la5Ci8tu4YNptVTB4ADN+l9XZEVTCfnneqia sIw5406BeIg8gdlgqS34ASdE41mrDwsvuPgsk7JNutGRDnMiH36H/4eDjB0txZcwRxgS 3Tfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=aintNYOtcjXMr2mFcXsT63vXO+hsU7hJsFCOLSw8Wts=; b=LtGuoaeDJAsxwNGgmdQykFxCLe1tjFfnGqciH1hShRBhugdHGRQDNIGURjmMkScesp BP5xmGFZyMYbI69S8Jt8dvkFoI3RnJWh+RunRkoiU+a9swGzNiFShk5ZL8s3/tWLgb95 n11PVfLRJyrnBif/MAOJJEfedyhl/pCpSCsUBYNcaWa11nQN5EU03UVp8SPanTn3Z45d to5WvFc/2iimgh3pJN4ttlqi/qcCLHB7hgKz6+/W78I/jsAQftxDqFDCoOMDfU821fKb QkwhM66kBa6gG3K0i+SlA4jKT9kFPeLnk1c2sbZKnQrDTfEsn9CPGlYMy6T9cHAQP8yX 86+Q== X-Gm-Message-State: AD7BkJIxE9FLdkwSTNJpELtKZzIDirh9WhxqEptNpgMT1CkUbtTDwF2toZbhj40UnUJpQaibDFxUJ3oSF37rOA== X-Received: by 10.25.136.139 with SMTP id k133mr2836786lfd.157.1459550846083; Fri, 01 Apr 2016 15:47:26 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.31.6 with HTTP; Fri, 1 Apr 2016 15:46:56 -0700 (PDT) In-Reply-To: References: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> From: Hugo Krawczyk Date: Fri, 1 Apr 2016 18:46:56 -0400 X-Google-Sender-Auth: Vi_s0Yg_3mm9D7Nk4cqmWrVpzm4 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113f3894b66a88052f742958 Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing DHE-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 22:47:31 -0000 --001a113f3894b66a88052f742958 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 31, 2016 at 11:49 PM, Eric Rescorla wrote: > > > On Thu, Mar 31, 2016 at 8:39 PM, Hugo Krawczyk > wrote: > >> >> >> On Tue, Mar 29, 2016 at 9:11 AM, Sean Turner wrote: >> >>> All, >>> >>> To make sure we=E2=80=99ve got a clear way forward coming out of our BA >>> sessions, we need to make sure there=E2=80=99s consensus on a couple of= outstanding >>> issues. So... >>> >>> There also seems to be (rougher) consensus not to support 0-RTT via DHE >>> (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT = mode >>> as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT = are >>> almost identical, >> >> >> =E2=80=8BI am not offering an opinion about what the WG should decide re= garding >> keeping >> DHE-based 0-RTT in the base TLS 1.3 document, but just wanted to note >> that the >> above claim "The security properties of PSK-based 0-RTT and DHE-based >> 0-RTT are >> almost identical" is not quite right (nothing I say here is new, I just >> felt >> that I had to "object" to this statement as written). >> >> There are some significant differences - in some cases even "fundamental >> differences" - between keeping secret state (in the PSK case) and keepin= g >> non-secret state (in the DHE case) or even not keeping state at all (in >> the >> DHE case) and retrieving the server key g^s from some external source >> (with >> integrity but not secrecy). In addition, using DHE 0-RTT would require >> the >> client to send a key share g^x leading to a PFS 1-RTT exchange while wit= h >> PSK >> it may be "tempting" to omit PFS. >> > > The current plan of record is to allow the server to specify which cipher > suites it is > willing to accept, so it could refuse this > > =E2=80=8BI was just wondering if this is what will happen in practice. But I should have separated this consideration (and the next) from the more fundamental point of public vs secret state. > > > Moreover, if the server's configuration >> key g^s is refreshed often (say each 5 minutes) then the g^xs key used b= y >> the >> client to protect its 0-RTT data already has some good level of forward >> secrecy (the attacker has a 5 minute window to find s and after that >> forward >> security is guaranteed). The latter point touches on an important aspec= t >> which is the key management complexity of ticket encryption/decryption >> keys >> (as needed in the PSK case) vs managing secret DH key s (in the DHE >> case). >> I am not sure what would be done better (more secure) in practice. >> > > Can you expand on the difference here? Say that the server implements > tickets > by storing a DH private key and then encrypting the ticket under the > corresponding > public key. How does this provide different PFS properties? > =E2=80=8BIt doesn't. And you don't need a public key for this. If the serve= r rotates the ticket encrypting key =E2=80=8B =E2=80=8Boften (say each 5 minutes as in the example) then you get the same= effect. The point was about which case, g^s or symmetric ticket encryption key will be managed better in practice. I don't have an answer. Hugo > -Ekr > > >> But really it seems that the discussion boils down to identifying cases = of >> enough interest where avoiding the original 1-RTT trip for establishing = a >> session ticket is important. I am puzzled by the fact that the Google te= am >> seems ok with something that essentially voids the main feature and desi= gn >> basis of of QUIC. >> >> Hugo=E2=80=8B >> >> =E2=80=8B=E2=80=8B >> >>> but 0-RTT PSK has better performance properties and is simpler to >>> specify and implement. Note that this does not permanently preclude >>> supporting DHE-based 0-RTT in a future extension, but it would not be i= n >>> the initial TLS 1.3 RFC. >>> >>> If you think that we should keep DHE-based 0-RTT please indicate so now >>> and provide your rationale. >>> >>> J&S >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > --001a113f3894b66a88052f742958 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 31, 2016 at 11:49 PM, Eric Rescorla <ekr@rtfm.= com> wrote:


On Thu, Mar 31, 2016 at 8:39 PM, Hugo Krawczyk <= hugo@ee.technio= n.ac.il> wrote:


On Tue, Mar 29, 2016 at 9:11 AM, Sean Turner <sean@sn3= rd.com> wrote:
All,

To make sure we=E2=80=99ve got a clear way forward coming out of our BA ses= sions, we need to make sure there=E2=80=99s consensus on a couple of outsta= nding issues.=C2=A0 So...

There also seems to be (rougher) consensus not to support 0-RTT via DHE=C2= =A0 (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT = mode as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT= are almost identical,

=E2=80=8BI am not offer= ing an opinion about what the WG should decide regarding keeping
= DHE-based 0-RTT in the base TLS 1.3 docu= ment, but just wanted to note that the
above claim "The security properties of PSK-based 0-RT= T and DHE-based 0-RTT are
almost identical" is not quite right (nothing I say here is new, I = just felt
that I had to= "object" to this statement as written).

There are some significant differences - in some cases even "= ;fundamental
difference= s" - between keeping secret state (in the PSK case) and keeping=
non-secret state (in the DHE = case) or even not keeping state at all (in the
DHE case) and retrieving the server key g^s from s= ome external source (with
integrity but not secrecy).=C2=A0 In addition, using DHE 0-RTT would req= uire the
client to send= a key share g^x leading to a PFS 1-RTT exchange while with PSK
it may be "tempting" to = omit PFS.=C2=A0

<= /div>
The current plan of record is to allow the server to speci= fy which cipher suites it is
willing to accept, so it could refus= e this


=E2=80=8BI was just wo= ndering if this is what will happen in practice.
But I should have separated this consideration (and the nex= t) from the more fundamental point of public vs secret state.
=C2=A0


=
Moreover, =C2=A0if the server's configuration=
key g^s is refreshed o= ften (say each 5 minutes) then the g^xs key used by the
client to protect its 0-RTT data already h= as some good level of forward
secrecy (the attacker has a 5 minute window to find s and after that= forward
security is gu= aranteed).=C2=A0 The latter point touches on an important aspect
which is the key management compl= exity of ticket encryption/decryption keys
(as needed in the PSK case) vs managing secret DH key s= (in the DHE case).=C2=A0
I am not sure what would be done better (more secure) in practice. =C2= =A0

=
Can you expand on the difference here? Say that the server implements = tickets
by storing a DH private key and then encrypting the ticke= t under the corresponding
public key. How does this provide diffe= rent PFS properties?

=E2=80=8BIt doesn't. And you don't need= a public key for this. If the server rotates the ticket encrypting key =E2= =80=8B
=C2=A0
=E2=80=8Boften (say each 5 minu= tes as in the example) then you get the same effect. The point was about wh= ich case, g^s or symmetric ticket encryption key will be managed better in = practice. I don't have an answer.

Hugo

-Ekr


But really it seems that the discussion bo= ils down to identifying cases of
enough interest where avoiding the original 1-RTT trip for establ= ishing a
session ticket= is important. I am puzzled by the fact that the Google team
seems ok with something that essentia= lly voids the main feature and design
basis of of QUIC.
=

Hugo=E2=80=8B

=E2=80=8B=E2=80=8B
but 0-RTT PSK has better perfo= rmance properties and is simpler to specify and implement. Note that this d= oes not permanently preclude supporting DHE-based 0-RTT in a future extensi= on, but it would not be in the initial TLS 1.3 RFC.

If you think that we should keep DHE-based 0-RTT please indicate so now and= provide your rationale.

J&S

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


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



--001a113f3894b66a88052f742958-- From nobody Fri Apr 1 18:13:46 2016 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 3B1BF12D1DA for ; Fri, 1 Apr 2016 18:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8oGVnGO4MkF for ; Fri, 1 Apr 2016 18:13:43 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A45AE12D13C for ; Fri, 1 Apr 2016 18:13:43 -0700 (PDT) Received: by mail-ig0-x231.google.com with SMTP id cl4so7981094igb.0 for ; Fri, 01 Apr 2016 18:13:43 -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; bh=n+mNDxj4xclHYIV9jR/WSLxTQb2tRDJOu7dQeAWtz+Y=; b=lcTXYol6/xiFGo9sKIdut0ZXBz2SD3BFwQGap0kL1L0fhz+s3lBGQHeWIq+S3o/8on GGxBrKfrJ84gXFI4QKrpssEcKl81ImtKF423qsWa/yaY0YABw05zpluF5zrWPFI1Al4r Ufa1oOFfNbW+cZxne0kPLR11SPpie0D7BAblNA3FFJMrIKVJgpK79qNtogks8Er5UqYl 8JyTmvh1HpscyIifdxJZsu02C3RkVrysbz5peZcym/V65bh2JFdsvcdrUUZmF3szaBYj ZM5R3X+xGWBpKAxRq1Gr30HE0/RhxbYjKU+PMIEXHSQ5iG0L6FEH6lIOYY6lYhCDUkGf IrnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=n+mNDxj4xclHYIV9jR/WSLxTQb2tRDJOu7dQeAWtz+Y=; b=Oe1v1+Xsbk/fvZdQWkX+Sl866e+6A5yAFmZYaYiJKqOyBoqb0zgyNIWBkfoA3yFiC7 0dthjd+oXDXkNORAmEIPhbxfOrHRprXd38M6eZxZzJsoPZRGt+R6tIMqTcfdv3FAwCY3 WKPYQgh30Y7n5+6oKAia1hkkizmVQxmYXb7+1Nuo8hryceebWHoW2C643Lh2gTWxmeab eFajPPY2gh8oKrjpJQIts/evBghGmmrYjv1URzm76o77cjPWbzgo61+LTMUb+qh+MW1/ yWMQFv/4RcbGVs8F19VptyAoyohDMtuvY2cYIv+YC0/+Q+zyYcfBYJok6PmNTD7BdXXV y2/g== X-Gm-Message-State: AD7BkJKchF3P2XoRr9xK0ROv3X35aId4NP8Uyalqe+ijXWmeMHncMve3iDBBufJPXPX9/5PR4dDq85va98v5Cg== MIME-Version: 1.0 X-Received: by 10.107.34.139 with SMTP id i133mr10737585ioi.108.1459559622969; Fri, 01 Apr 2016 18:13:42 -0700 (PDT) Received: by 10.36.43.5 with HTTP; Fri, 1 Apr 2016 18:13:42 -0700 (PDT) In-Reply-To: <20160331164608.GA4279@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160331164608.GA4279@LK-Perkele-V2.elisa-laajakaista.fi> Date: Sat, 2 Apr 2016 12:13:42 +1100 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0RTT and HelloRetryRequest (Re: Narrowing the replay window) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2016 01:13:45 -0000 On 1 April 2016 at 03:46, Ilari Liusvaara wrote: > >> > I believe Option #2 is simplest. >> >> I didn't mention this because I was composing on a phone at the time, >> but we have to decide whether to allow a second attempt at 0-RTT. If >> we do, then the effect is a two round trip setback. I think that the >> odds of this happening are small, so I'm OK with it, but I wanted to >> highlight that. > > Not taking it could mix poorly with DTLS, as DTLS rejects need to be > stateless from server POV. I thought that we'd already established that this is entirely possible. From nobody Fri Apr 1 20:17:24 2016 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 62FBF12D510 for ; Fri, 1 Apr 2016 20:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qa8XOs0tfcgW for ; Fri, 1 Apr 2016 20:17:21 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637A412D506 for ; Fri, 1 Apr 2016 20:17:21 -0700 (PDT) Received: by mail-qg0-x234.google.com with SMTP id f52so15029856qga.3 for ; Fri, 01 Apr 2016 20:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=FiVYYUSeL0sUNqQILvrDDyUgU2YLYbd9j2Ir7oz61wk=; b=rjlp47DTbb5Krt4zC3nyyJV4pJg9QXo7TA9bVp4bktH2Iy7jXfuuUgcSfCMe3+PoNT lhtWYmm0zS/27H0ESL1dNpOhOvOVKKaZ/d7zy2nWMYXorQGNl3hgDPaF1hvgg6IRHeAW lIHIs+/alZa4ChEG6ZV4k0PIg9f4HYTRx0y66U2g7rB6srm/fdZLK5mZYWxVPtGxmC9C Jk3y4gJQneEcH/enr5sXI9A57t4Gk/vOKIKFiQZ5cdmrrToY9CBgY/QdJYOMPjsaVptk 1yOqWPYnCQZWUe6Sfu1kTa2NLtxsJ4iLNajNoa2xNi7SBSa/HrXxGBzLmmpY7mqnfy0T IsAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=FiVYYUSeL0sUNqQILvrDDyUgU2YLYbd9j2Ir7oz61wk=; b=X9gSbUATdGUFMmkbQaHcXBeBiC0QsBVCkG7l9GDMhgNBtogPMUNZBz6zb6YUe0yBok tj/+xipofM/LD1D5o7vdkuEIjJBMtUmYosq8B4RFC7R5uzObbycJtff3F6TW++Z4R6YW SzZCH2QoZ0JjE112KO0naNXEqPHVdQSX7v1Ojd1pcqSrW1BTDZ7w2h6i+svV76JpSUGu i0lD80SmZY54C0574R8fwS5BD5qVY/BpadHv6fa49q9bzpZzpFjcIbXsTXDXcu0xKz2W p4x3e3NCnD4Nb9VvZ2HSm3Ho1PYQYnWzFvDaKX2QFs2PGU/DKN+H94KEyNbw1zGcd1Y7 jPfA== X-Gm-Message-State: AD7BkJIhoLS/AZqGktm6N4FutFWW7SvIyOanRdjQU+mr6nIxjjaJ8UYl96IXgrc96eBRcw== X-Received: by 10.140.104.242 with SMTP id a105mr10668429qgf.1.1459567040536; Fri, 01 Apr 2016 20:17:20 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id o8sm7557775qko.24.2016.04.01.20.17.19 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 01 Apr 2016 20:17:19 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Fri, 1 Apr 2016 23:17:18 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <1459497291.3034.20.camel@redhat.com> In-Reply-To: <1459497291.3034.20.camel@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201604012317.18650.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] TLS 1.2 Long-term Support Profile vs HTTP/2.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2016 03:17:23 -0000 On Friday, April 01, 2016 03:54:51 am Nikos Mavrogiannopoulos wrote: > On Wed, 2016-03-16 at 12:36 +0000, Peter Gutmann wrote: > > After a number of, uh, gentle reminders from people who have been > > waiting for > > this, I've finally got around to posting the TLS-LTS draft I > > mentioned a while > > back. It's now available as: > > > > > http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt > > I liked the idea of an LTS profile for TLS 1.2, however I just realized > that RFC7540 [0] blacklists (with no rationale) 3 out of the 4 LTS > ciphersuites and I'm wondering how practically useful will be that > profile. > > regards, > Nikos > > [0]. https://tools.ietf.org/html/rfc7540#appendix-A As no such TLS 1.2 LTS existed at the time of publication (which multiple people, including myself, said would have been better), some kind of sane cipher restrictions were needed to avoid perpetual use of obsolete crypto. The consensus was requiring TLS 1.2+ with only PFS+AEAD cipher suites, however at the last minute implementors started complaining about the requirements and it was reduced to a blacklist of non-compliant cipher suites instead of requiring them to just update their APIs to handle things properly. Noted at the end of the section: https://tools.ietf.org/html/rfc7540#page-94 Dave From nobody Sat Apr 2 03:44:17 2016 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 C87B912D770 for ; Sat, 2 Apr 2016 03:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IydScZut9Doe for ; Sat, 2 Apr 2016 03:44:14 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B1912D76D for ; Sat, 2 Apr 2016 03:44:14 -0700 (PDT) Received: by mail-ig0-x22c.google.com with SMTP id cl4so16773362igb.0 for ; Sat, 02 Apr 2016 03:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=1BwobqSRO9OZxgEKiq5qO1T6snun/o3LYWQpQpU3BSo=; b=ezUNBxu4umskGpfP7Xp1Ko28GS2z0rY4kGjw+Xnb5YrpQmcb5jMLK/wHMs1OzDiHuc NosqBWsGd7QcRGFlF1NGEl5cYj9MKE4m2nOgbrqCPYTMQrGtsCxh5Wi0g3EiMkur5dos SWJ2cxknZYrX1Ggtavc1mo6d2Dmsyhm7gTxmmfjp7i2Kxo6YXC4Yu9t3ueoUuBIiCdrd 5hB8iDIDYv1UGGJZWnORW+933N3HC14V1W2wNmTZ6eToZfclii7DrIKflUOVoswrYVpR BhJemUltLlv/sqzX6H+HJH2AqJOgHsM2UNTugG7JNCZHDySDRw1P5AMn++u6PpXpOqDs sFKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=1BwobqSRO9OZxgEKiq5qO1T6snun/o3LYWQpQpU3BSo=; b=ED2If9xFfyueCHNXihphLm0TmLlDrnsq6SYtdwBdPI5B5TizZ27qNqHtApZBLGXcw1 gucW6IN+VZ7ilipzSu05arPo8CPn1kQ+zFX4jWxiVYE63+BurMyJ6sqchPFx7EFSLW8Q Mss07D4lbn61J3RY8BW9oycUAIeJm71BqS2g9dX/HPLVLFMoFlUV33qW4/ZTCUI+fAij 9FuC3enFvjNyo8fukbqpErb8vD6r2zLvglkof1/B14V87RbEnbB7QUdsKPIacnCepZJ+ yVou3BlDi/PCC2kXqJd7piR44xxmPgTLYVP6HZkkGam/UIm5pgkfW0Gb2WQ+IApOBSqU U0vw== X-Gm-Message-State: AD7BkJLVNslql+9nTIQVwkNxaZBoh7Gs7dlPKSm0cfCfORznlQ+/IsJGWShmaPGtMjEeClxDrrtvgYKIw+Q4Ow== MIME-Version: 1.0 X-Received: by 10.107.137.100 with SMTP id l97mr9247520iod.100.1459593853561; Sat, 02 Apr 2016 03:44:13 -0700 (PDT) Received: by 10.36.43.5 with HTTP; Sat, 2 Apr 2016 03:44:13 -0700 (PDT) In-Reply-To: References: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> Date: Sat, 2 Apr 2016 21:44:13 +1100 Message-ID: From: Martin Thomson To: Wan-Teh Chang Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing DHE-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2016 10:44:16 -0000 On 31 March 2016 at 15:52, Wan-Teh Chang wrote: > The info is these two tables is exactly the same for DHE-based 0-RTT > and PSK-based 0-RTT. You are right. I remain concerned about the other factors. From nobody Sat Apr 2 11:01:46 2016 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 8457412D579 for ; Sat, 2 Apr 2016 11:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H_EIuAW8fGc3 for ; Sat, 2 Apr 2016 11:01:43 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A8612D577 for ; Sat, 2 Apr 2016 10:53:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,432,1454972400"; d="scan'208";a="172223011" Received: from aclermont-ferrand-653-1-122-31.w86-207.abo.wanadoo.fr (HELO [192.168.1.40]) ([86.207.37.31]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Apr 2016 19:53:19 +0200 From: Karthik Bhargavan Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <4288B225-3CA9-426B-B352-FCC461E607B4@inria.fr> Date: Sat, 2 Apr 2016 19:53:16 +0200 To: tls@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] Avoiding Trial Decryption (for 0-RTT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2016 18:01:44 -0000 TLS 1.3 0-RTT introduces an =E2=80=9Coptimistic=E2=80=9D mode where the = client=20 encrypts data that the server can then accept or reject. In the case when the server rejects 0-RTT, the server is left in a = somewhat ugly state where it will receive, in sequence: (a) encrypted 0-RTT handshake data (that it needs to throw away) (b) encrypted 0-RTT application data (that it needs to throw away) (c) encrypted 1-RTT handshake data (that it needs to process) Since we have removed content types from the record headers of encrypted messages, these 3 flights of messages look the same. So, the current draft requires the server to =E2=80=9Ctrial decrypt=E2=80=9D= each message with the 1-RTT Handshake keys, in order to detect where (c) begins, and=20= to discard packets that do not decrypt correctly.=20 The situation can be even worse. Suppose the client sends a ClientHello and 0-RTT data, the server responds with a HelloRetryRequest, and now the client sends a new ClientHello and new 0-RTT data. In this case, we have (a), (b), (a), (b), (c); that is, the server needs to skip 4 flights of messages by trial decryption before getting to the = 1-RTT handshake data. This seems inefficient and inelegant, and it may open up a new attack vector where an attacker may sent many messages and get the=20 server to decrypt them under the same key (and same IV, etc).=20 In other modes of TLS, a single decryption failure would close the connection, so this mode of attack is new and we may need to take = care. Here is a proposal that would avoid trial decryption. When the client sends 0-RTT application data, it currently ends this flight of messages with an encrypted end_of_early data warning = alert. How about: if the server rejects trial decryption, the client must then send an *unencrypted* end_of_early_data warning alert before continuing with 1-RTT handshake data. The server could then easily discard all records until it sees this = warning alert. The main disadvantage of this approach seems to be that it reveals to = the adversary the point at which the 0-RTT application data ends (if this is sensitive = information.) However, note that if the length of 0-RTT data was sensitive, an = attacker could probably already obtain it by delaying the server flight. Does anyone see other practical or security disadvantages to using this = alert? Best regards, Karthik From nobody Sat Apr 2 13:05:18 2016 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 81C1312D593 for ; Sat, 2 Apr 2016 13:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21Rq4zM452mM for ; Sat, 2 Apr 2016 13:05:07 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D05012D592 for ; Sat, 2 Apr 2016 13:05:06 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id g184so42002785lfb.3 for ; Sat, 02 Apr 2016 13:05:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DK8vcy8WL4R6CmH04+Lr27Bs4ki4ciByV+4ZZpk5U4Q=; b=dc9klq3QXPpMbY0VeFJCokPrRRbKzPb5ll5kqJpEYdCK2mNM6kIdjVpS68wc7t3qSP UzkjjXJg73QF1UgMfJQPLkQI7u2KtHAkpz0fwBjmOj51L8vCB3e+rOoqIi17py9A/ZEG UyTO2ac0sbcjNQpqnqyIrVwxeerrLXcGfqZ545tT7UyVTRwdWPR/3GyAGm3gQvakkNMc ie2KIgbuE/lOc1EdxfrsCuFpJ06JH9Pz+MrbEE/jtGzn04QnoEiIJglwT08g66Tzk45L VbXb5Ba+1gA69/ctfRAuxxsXfEGIsbFI1kk6SXHVXOfGKxvBPDBVpUdQ6+d1wHbySBYU ZR2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DK8vcy8WL4R6CmH04+Lr27Bs4ki4ciByV+4ZZpk5U4Q=; b=jQ4y4qWVcxQYFOF6K8VzTqXNUoZwFRkVQroCrZT7nni2x/rTMO1OAoCRzRW452HyEK EAaHPrbFEvurjCMPdQEl6c85tk5XD4RY6x6lPiZ105SFpmaXKWwF8uBFFphssobzoHCf 5rlBlNJI57ruhuYVbO6M3RcEeZK5i/uLZo1YEN8DQXgaIQEHO4Wfj02K+oaa2KE7NRTG lZTY6EqlIalDZKBUgi+C2PAjvy7iC86MoepDhtWlO7wSvWD4fX+khF63EqVqQbrKZ8sc zyJBVUbCM342kbIACg54Zp+lIg29WolJr8s9I5yJSscFr1k3qY5utf+IbudCKQ6uPBRV yz2Q== X-Gm-Message-State: AD7BkJI2a2CCsK0wMYNaQpJpPT2qHK7UymFFQxCBxahAxQvxDPTez8i0aREIU3wL7Vh6nw== X-Received: by 10.194.191.199 with SMTP id ha7mr11142437wjc.128.1459627504591; Sat, 02 Apr 2016 13:05:04 -0700 (PDT) Received: from [192.168.1.40] (AClermont-Ferrand-653-1-122-31.w86-207.abo.wanadoo.fr. [86.207.37.31]) by smtp.gmail.com with ESMTPSA id d1sm4166688wmh.18.2016.04.02.13.05.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 02 Apr 2016 13:05:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Sat, 2 Apr 2016 22:05:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?utf-8?Q?Bj=C3=B6rn_Tackmann?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Key separation and privacy X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 02 Apr 2016 20:05:17 -0000 These are good questions. More generally, when do we care about distinguishing handshake data from = application data?=20 I just posted another email about using plaintext end_of_early_data = alerts to avoid trial decryption, and similar questions come into play = there. Best, Karthik > On 29 Mar 2016, at 22:50, Bj=C3=B6rn Tackmann = wrote: >=20 > Dear TLS Working Group, >=20 > this message relates mostly to (real-world) privacy, so I'd be = particularly grateful for comments from people concerned with that. >=20 > The TRON workshop [1] re-initiated a discussion about the handling of = keys among cryptography researchers involved with TLS. Although there is = no unanimous opinion on this matter, I think it is fair to say that the = majority of cryptographers support the principle of key separation, that = is, using each cryptographic key derived within the protocol (only) for = its specific purpose. (This simplifies the analysis significantly, but = it also helps to avoid unintended interactions between different = protocol parts and to keep things nice and modular.) We are particularly = concerned with the traffic keys used for handshake and for application = data. >=20 > The current TLS 1.3 draft is somewhat inconsistent here. While the = ordinary handshake messages are encrypted under a handshake traffic key = HTK, "late" handshake messages (NewSessionTicket and post-handshake = client authentication) are intermixed with application data messages and = encrypted under the application traffic key ATK. Encrypting late = handshake messages with HTK instead of ATK would cause the problem that = the receiver must know which key to use for decrypting a received = message; the somewhat most straightforward way would be to make the = messages clearly distinguishable, another way would be to do trial = decryption for each incoming message with ATK and, in case of failure, = decrypt with HTK. This key HTK could be the very same key as the one = used for encrypting the messages during the initial handshake. >=20 > The plain "record type" field has been retired when the new padding = mechanism was introduced, with the idea of better protecting privacy. So = the main question here is: how important is it to make handshake and = application data messages indistinguishable? And is it realistic? > - The late handshake messages are "new ticket," "late client auth," = and "key update." I guess the most sensitive of them is "late client = auth?" Is it important that this be hidden within application data? Are = "new ticket" and "key update" also considered privacy-sensitive? > - Beyond the plain record type, the message may also be identifiable = by other traffic characteristics such as length or timing. While the = length can be hidden using padding, this requires co-operation with the = application layer, because TLS can hardly know what the characteristic = traffic pattern of the particular application is. Is this, = realistically, ever going to happen in a way that will significantly = cover the characteristic pattern of the handshake messages? >=20 > In a nutshell, three possibilities for this are: > (a) Do not separate keys, i.e., set HTK =3D ATK. This makes = cryptographic analysis harder and renders the protocol less modular, but = it may have privacy advantages. > (b) Separate keys, set HTK !=3D ATK, and resurrect the =E2=80=9Crecord = type=E2=80=9D field to the extent that it allows to differentiate = HTK-encrypted packets from ATK-encrypted packets. This seems the = cryptographically cleanest way but may come with worse privacy = guarantees. > (c) Separate keys, set HTK !=3D ATK, leave =E2=80=9Crecord type=E2=80=9D= field disabled, and trial-decrypt. This is messier than both of the = above, but seems a possible compromise between modularity and privacy. >=20 > What do you think? >=20 > Thanks & best, > Bj=C3=B6rn >=20 >=20 > [1] = http://www.internetsociety.org/events/ndss-symposium-2016/tls-13-ready-or-= not-tron-workshop-programme >=20 > -- > Bj=C3=B6rn Tackmann > Postdoctoral Research Scholar > Computer Science & Engineering, UC San Diego >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From prvs=89482cc75=R.LIU@f5.com Sat Apr 2 21:59:04 2016 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 00E1F12D5C6 for ; Sat, 2 Apr 2016 21:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.031 X-Spam-Level: X-Spam-Status: No, score=-7.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=f5.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olXbULnfc0kN for ; Sat, 2 Apr 2016 21:59:00 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D68EB12D5C0 for ; Sat, 2 Apr 2016 21:59:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1459659541; x=1491195541; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=2l1AnmQOxKUJC6HfKBO03LdjuHX7CwyMqYRw33eshgI=; b=gHkHqiAprhFgJwpfwVKwQQd9jUI8U8lzjLk0HW+dTJQhJGRsJFFCx7At IGtb7kHmf8PC9MCXPUanwmOFDQKzonX8jM0qeyzNUPAliCup6x+BPYiFK GJecbHWJ2Tp/KXyNMb6avcaaGEIQNz9MSyx2syUdqgkzd6YRSAdohDzuR g=; X-IronPort-AV: E=Sophos;i="5.24,435,1454976000"; d="scan'208";a="211742222" Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 03 Apr 2016 04:59:00 +0000 Received: from SEAEXCHMBX03.olympus.F5Net.com (192.168.15.225) by seaexchmbx03.olympus.F5Net.com (192.168.15.225) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Sat, 2 Apr 2016 21:59:00 -0700 Received: from SEAEXCHMBX03.olympus.F5Net.com ([fe80::f95f:ea5d:773b:29b8]) by seaexchmbx03.olympus.F5Net.com ([fe80::f95f:ea5d:773b:29b8%13]) with mapi id 15.00.1156.000; Sat, 2 Apr 2016 21:59:00 -0700 From: Rik LIU To: "tls@ietf.org" Thread-Topic: question about the cipher_suite in server hello during a resume session Thread-Index: AQHRjWWIqzT3N/ewf0yvPauvZ7na0g== Date: Sun, 3 Apr 2016 04:58:59 +0000 Message-ID: <1459659538822.83443@f5.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [TLS] question about the cipher_suite in server hello during a resume session X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2016 05:03:19 -0000 Hello all,=0A= =0A= I have a confusion about this specification, and I did a search of the mail= archives, it seems not mentioned before :=0A= =0A= rfc5246=0A= 7.4.1.3. Server Hello=0A= cipher_suite=0A= For resumed sessions, this field is the value from the state of the session= being resumed.=0A= =0A= There is not a 'MUST' to strict the server that cannot pick up a different = cipher. Even we all know the resume must be failed.=0A= =0A= So it's a little tricky if a server implementation does wrong but not expli= citly against this RFC.=0A= =0A= And refering rfc 2119=0A= 6. Guidance in the use of these Imperatives=0A= In particular, they MUST only be used where it is actually required for int= eroperation or to limit behavior which has potential for causing harm (e.g.= , limiting retransmisssions)=0A= =0A= eg. If the server does pick up a different cipher in server hello, it indee= d cause a renegotiation instead of a successfuly resume.=0A= =0A= So is that possible to make this specification more strict with a 'MUST'?= =0A= =0A= "For resumed sessions, this field s/is/MUST/ the value from the state of th= e session being resumed."=0A= =0A= Thank you!=0A= BR=0A= Rik= From nobody Sun Apr 3 01:18:29 2016 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 61B3E12D1A4 for ; Sun, 3 Apr 2016 01:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaJ1ux6g-lUT for ; Sun, 3 Apr 2016 01:18:24 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE57412D1D7 for ; Sun, 3 Apr 2016 01:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1459671504; x=1491207504; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Gd/rTZ7WJ4QMslHazK6bFhKMICPL6YeRr8yNjfVRl/M=; b=IeglGtl7Fs+d53i9uqzcCIXBxEj8pFHtz22aPBwu9y+ghkdQNOd5wPjh N4EdVLHP0iSTO75WMJlygMIPeAZWBFs8fICpGQaNWx9421ZHorFTeVlZU e4k1U5KXLFwUXPcMuMB+pKgdG/26Wl8pFpoux/Svy/F7eD2ixY/bQQS1m ZiiiAWVzyz16yjtt+e9wO5uODwOA4EgijLhSWfLz70J/rDULqKMQUp+Sk cpgTaw7bfWqRPciWxKeXiQD5JGzRxwabpsDaDhvLP4rBiDjNdReoxiSvR 1+o6OkRIDZkxHLgXJttf8PTehFHftUGOfoMywuepkcKRfTtgstlhTL1SR g==; X-IronPort-AV: E=Sophos;i="5.24,435,1454929200"; d="scan'208";a="77816877" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 Apr 2016 20:18:22 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.241]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Sun, 3 Apr 2016 20:18:21 +1200 From: Peter Gutmann To: Nikos Mavrogiannopoulos , "" Thread-Topic: TLS 1.2 Long-term Support Profile vs HTTP/2.0 Thread-Index: AQHRi+vJnwT2ZsyWdkG5xgChHwbWmZ936rie Date: Sun, 3 Apr 2016 08:18:20 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C376E8@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz>, <1459497291.3034.20.camel@redhat.com> In-Reply-To: <1459497291.3034.20.camel@redhat.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] TLS 1.2 Long-term Support Profile vs HTTP/2.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2016 08:18:28 -0000 Nikos Mavrogiannopoulos writes:=0A= =0A= >I liked the idea of an LTS profile for TLS 1.2, however I just realized th= at=0A= >RFC7540 [0] blacklists (with no rationale) 3 out of the 4 LTS ciphersuites= =0A= >and I'm wondering how practically useful will be that profile.=0A= =0A= I chose the two sets of algorithms that were secure and had the most=0A= widespread acceptance/support/popularity/whatever, in other words the ones= =0A= where there was the biggest chance of developers being able to say "yeah, w= e=0A= do that already".=0A= =0A= >[0]. https://tools.ietf.org/html/rfc7540#appendix-A=0A= =0A= I think the reason why there's no rationale is because there's no rational= =0A= explanation for lumping TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 in with the lik= es=0A= of TLS_RSA_EXPORT_WITH_RC4_40_MD5.=0A= =0A= Peter.= From nobody Sun Apr 3 04:43:58 2016 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 BF2D812D5CA for ; Sun, 3 Apr 2016 04:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmpSW4CQ67-X for ; Sun, 3 Apr 2016 04:43:55 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2194F12D5DB for ; Sun, 3 Apr 2016 04:43:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id F36E84A76; Sun, 3 Apr 2016 14:43:52 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id uAIeb3qFV2p9; Sun, 3 Apr 2016 14:43:52 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 9B32021C; Sun, 3 Apr 2016 14:43:52 +0300 (EEST) Date: Sun, 3 Apr 2016 14:43:51 +0300 From: Ilari Liusvaara To: Karthik Bhargavan Message-ID: <20160403114351.GA10799@LK-Perkele-V2.elisa-laajakaista.fi> References: <4288B225-3CA9-426B-B352-FCC461E607B4@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4288B225-3CA9-426B-B352-FCC461E607B4@inria.fr> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Avoiding Trial Decryption (for 0-RTT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2016 11:43:58 -0000 On Sat, Apr 02, 2016 at 07:53:16PM +0200, Karthik Bhargavan wrote: > TLS 1.3 0-RTT introduces an “optimistic” mode where the client > encrypts data that the server can then accept or reject. > > In the case when the server rejects 0-RTT, the server is left in a somewhat > ugly state where it will receive, in sequence: > (a) encrypted 0-RTT handshake data (that it needs to throw away) > (b) encrypted 0-RTT application data (that it needs to throw away) > (c) encrypted 1-RTT handshake data (that it needs to process) > > Since we have removed content types from the record headers > of encrypted messages, these 3 flights of messages look the same. > So, the current draft requires the server to “trial decrypt” each message > with the 1-RTT Handshake keys, in order to detect where (c) begins, and > to discard packets that do not decrypt correctly. > > The situation can be even worse. Suppose the client sends a ClientHello > and 0-RTT data, the server responds with a HelloRetryRequest, and > now the client sends a new ClientHello and new 0-RTT data. > In this case, we have (a), (b), (a), (b), (c); that is, the server needs > to skip 4 flights of messages by trial decryption before getting to > the 1-RTT handshake data. And with DTLS, one can get even more wonderful cases from all sorts of datagram reordering. Including things like 1st round encrypted 0-RTT data being interpretted as 2nd round encrypted 0-RTT data (it won't decrypt). Oh, and also 0-RTT data being received after handshake has already finished. Well, in rejection case in (stream) TLS, you get ClientHello with its different content type in the middle. But that won't help with the last handshake. > Here is a proposal that would avoid trial decryption. > When the client sends 0-RTT application data, it currently > ends this flight of messages with an encrypted end_of_early data warning alert. > How about: if the server rejects trial decryption, the client > must then send an *unencrypted* end_of_early_data warning alert before > continuing with 1-RTT handshake data. > The server could then easily discard all records until it sees this warning alert. Only works on (stream) TLS, but in DTLS this can presumably be deduced from epoch numbers. > The main disadvantage of this approach seems to be that it reveals to the adversary > the point at which the 0-RTT application data ends (if this is sensitive information.) > However, note that if the length of 0-RTT data was sensitive, an attacker > could probably already obtain it by delaying the server flight. Also, the length could probably be obtained passively from message sizes, unless the implementation is very careful with padding (with high overhead). -Ilari From nobody Sun Apr 3 04:44:57 2016 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 2F87612D5DF for ; Sun, 3 Apr 2016 04:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bh_MjiLYKsvI for ; Sun, 3 Apr 2016 04:44:54 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0AF12D5DE for ; Sun, 3 Apr 2016 04:44:54 -0700 (PDT) Received: by mail-ig0-x230.google.com with SMTP id cl4so38467180igb.0 for ; Sun, 03 Apr 2016 04:44:54 -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; bh=rvZB1vyKFZWM4x/rnVKk+BOEvYXw54s6RVnNgvOfxK0=; b=bmcJVfUH6KN57CURyBKPGBtImMz5ndr9V7He7S1VHOpaUYUvFsyOI/kDNnQ832LeNv okvQRSYxB9+us0/WtNM+FMeTFXw9/DeQPgl8Ip5Tbroja6dNL9PrB0zLoUb7ERsS9j/l bdQC4dFHbvki0pPYW1Y03t/rGNDwz3yWlGbiUzsCUPfUap4tP9KtMahaXaIlDBZ65RCK KANqtfan5xmDNpUZf11umXWy4r0hhudpx3Pv1DQx46S7OJb/2dqHDj3XDaZ1YfOX4R0o oMlYVWo2JIuMBz5C8qus1Xi2p/vwCbIzofKkq7gqiOWizzEIVpp3Mu3A6ZDGyfgRcw4m 5L6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=rvZB1vyKFZWM4x/rnVKk+BOEvYXw54s6RVnNgvOfxK0=; b=a/eNC/Q5si/wOypmEJLuXeU1A2diwUyMyAe38Ire3mgnbgzx0zoPIGuLNYCT7up+N1 Sxh95JNCR1OZhLu5QTdBJGfY+aCmQq1ShmKvCUYrP+tuhl7fzJH5TsIHSdvkD4hlOfY7 zZ8BM6r0K+XhAvP173SJaZwbv4UUPre1+r8FLg2GICtkkdLZfHEyVfQOqwh8cL33Zs4f T5TDkDi+ywg3ddv12PN7uuCgQINw25sxkfugaRJZ3eKaCkXkf+lwqej8ceXg6tDm9yHL gm1sHux2HpE8sPIaEv+W7HC6GYlLz20yhPOAV3i0qiN0VW3alOnfT4KCw+MNO0Po+zXj Qmvw== X-Gm-Message-State: AD7BkJLd1oIBg76JxjUGo6jhPRwZsbsj9gfqIuB1UrO3s8aygnqQpIf6vLglV+tggV44VU0xSch9eAZaSl6T1g== MIME-Version: 1.0 X-Received: by 10.107.161.140 with SMTP id k134mr12539359ioe.190.1459683893779; Sun, 03 Apr 2016 04:44:53 -0700 (PDT) Received: by 10.36.43.5 with HTTP; Sun, 3 Apr 2016 04:44:53 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C376E8@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <1459497291.3034.20.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4C376E8@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Sun, 3 Apr 2016 21:44:53 +1000 Message-ID: From: Martin Thomson To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile vs HTTP/2.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2016 11:44:56 -0000 On 3 April 2016 at 18:18, Peter Gutmann wrote: > I think the reason why there's no rationale is because there's no rational > explanation for lumping TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 in with the likes > of TLS_RSA_EXPORT_WITH_RC4_40_MD5. You evidently believe that a decision to move to AEAD only is irrational. Others, myself included, do not. From nobody Sun Apr 3 06:28:10 2016 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 BB09412D10D for ; Sun, 3 Apr 2016 06:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtY2Dnjl30Y3 for ; Sun, 3 Apr 2016 06:28:07 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B331F12D199 for ; Sun, 3 Apr 2016 06:28:06 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id p188so106064167lfd.0 for ; Sun, 03 Apr 2016 06:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rGleXm3GBCKvQNDcucASGf/26+d1Ejwsy541eUcYe8A=; b=uBIIYA9M/C5DdTCW5XdlenELvx9TGgD3TL7xiByXeUl9f4pWATpN2JFVidzy/o/DLy DHP5g06leAaHkbESOZJoZ2DJfYc/i1YJ+FQMA2HU8LymAYHox91Kn9G8JswIpXOFqSAL nPle+dGex8x0EzUeUKvemxZgsCvZThftzw4Tzz0FcXM+CmnSpGAtSlVN+mRkQLQqsP1g i2Lox+G8aHXEdrdgzUEleejHhDaWfLvImc3ligRN1p52eXL6cj9hDFKThy7uolotLlcz Xjl6ovtXe14oBlJd54v0l2awO1DNsnRY9MiRe34xFfa1DKw0y9QDI9puR9ygqs4VK/gy yBpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rGleXm3GBCKvQNDcucASGf/26+d1Ejwsy541eUcYe8A=; b=Hp4tFoI9a57lGX5kvBXiWvRZ2hsK4BWa2oJ3L1ZWQ4wfMkoFA9KwscERDcTYo5LzfE 8Ei+e6CxmC8c697uuXnLkLaJGn2JqOTZKeamopL0moo+FlaByyEOX6C38wmIGRdB8wMv bR14B76J77fnJHwWD5i3lkRU2eUWuJa7jq3ZF6qqHbFsQfX7GH0WM8K/MsoYiJrCzQ5m rIGIjKMFo77G6+Ox6xUafHynFx2zUu0UnDI/nRpAMKHXiY0UZ6KQDL3KaHSbEvhoYux+ HHeiCux4LHiffcHHGhzUdLpgWK6FQ7slJNMP/uH44a8N91lXMkVO69Vh1naYA9dJ5cUq K8kg== X-Gm-Message-State: AD7BkJKj+DSobkunUx2yIpRtGOkPgW7xWAyl8eNHbMuIcLecfN5a9jabEmDZ6BXjGkO7cA== X-Received: by 10.194.202.162 with SMTP id kj2mr4431174wjc.121.1459690084931; Sun, 03 Apr 2016 06:28:04 -0700 (PDT) Received: from ?IPv6:2001:67c:370:160:edc2:3e9f:5b5d:546d? ([2001:67c:370:160:edc2:3e9f:5b5d:546d]) by smtp.gmail.com with ESMTPSA id yn10sm21809907wjc.45.2016.04.03.06.28.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 03 Apr 2016 06:28:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Sun, 3 Apr 2016 10:27:59 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <1459497291.3034.20.camel@redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4C376E8@uxcn10-tdc05.UoA.auckland.ac.nz> To: Martin Thomson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile vs HTTP/2.0 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 03 Apr 2016 13:28:09 -0000 > On 3 Apr 2016, at 8:44 AM, Martin Thomson = wrote: >=20 > On 3 April 2016 at 18:18, Peter Gutmann = wrote: >> I think the reason why there's no rationale is because there's no = rational >> explanation for lumping TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 in with = the likes >> of TLS_RSA_EXPORT_WITH_RC4_40_MD5. >=20 > You evidently believe that a decision to move to AEAD only is > irrational. Others, myself included, do not. >=20 Agree. TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 is fine if you also implement = the EtM extension that nobody did. OTOH everybody implemented AES-GCM, = so that=E2=80=99s better in the =E2=80=9Cyeah, we do that already=E2=80=9D= criterion. And as Dave McGrew=E2=80=99s draft showed us, you can fit = CBC + HMAC into an AEAD in case you really, really like CBC and HMAC. Yoav From nobody Sun Apr 3 17:43:52 2016 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 54E8512D58C for ; Sun, 3 Apr 2016 17:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLKtAxjoVwoj for ; Sun, 3 Apr 2016 17:43:49 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADD612D51F for ; Sun, 3 Apr 2016 17:43:49 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 4EDDA1022404C; Sun, 3 Apr 2016 17:43:48 -0700 (PDT) Received: from 31.133.138.227 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 3 Apr 2016 17:43:48 -0700 (PDT) Message-ID: <9d1de55db58e33f7e564a03bc140cb49.squirrel@www.trepanning.net> In-Reply-To: References: Date: Sun, 3 Apr 2016 17:43:48 -0700 (PDT) From: "Dan Harkins" To: "Sean Turner" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Call for consensus: Removing 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 00:43:50 -0000 Hi Sean & Joe, On Tue, March 29, 2016 5:59 am, Sean Turner wrote: > All, > > To make sure we’ve got a clear way forward coming out of our BA > sessions, we need to make sure there’s consensus on a couple of > outstanding issues. So... > > It seems that there is a clear consensus not to support 0-RTT client > authentication in TLS 1.3 at this time. If you think 0-RTT client > authentication needs to be supported please indicate so now and provide > your rationale. I don't think it needs to be supported and would be happy if it was removed. It's a dangerous and flawed feature. My concern is that if (which I fear is pronounced "when") an exploit is found it might be easy to remove in a browser update but there's gonna be some large TLS concentrator vendor that'll have a helluva time getting its deployed boxes patched and it'll be ugly. The rationale for this-- to get an ad to me just that much faster (an ad, I note, that I sure hope my ad blocking software will prevent me from seeing), and that the people who want to do this know what they're doing so it'll all be fine (which is not reassuring in the least)-- just does not justify the risk. regards, Dan. From nobody Sun Apr 3 18:24:08 2016 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 B33B212D18D for ; Sun, 3 Apr 2016 18:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WsZTUNNwK9Z for ; Sun, 3 Apr 2016 18:24:03 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAA412D11A for ; Sun, 3 Apr 2016 18:24:03 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6467D1022404C; Sun, 3 Apr 2016 18:24:02 -0700 (PDT) Received: from 31.133.138.227 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 3 Apr 2016 18:24:03 -0700 (PDT) Message-ID: <96b5aa358a8bcc0145dfcd935d20062b.squirrel@www.trepanning.net> In-Reply-To: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> Date: Sun, 3 Apr 2016 18:24:03 -0700 (PDT) From: "Dan Harkins" To: "Sean Turner" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 01:24:06 -0000 Hi Sean, In general I support this but.... A stable, publicly available document is basically an RFC. So when the TLS WG says no that means asking an AD to sponsor or putting it into the Independent Stream process. So what it looks like you're doing is punting this problem into the lap of whoever is gonna be the Independent Stream Editor for this stuff because he or she will start getting a steady stream of requests for publication of documents describing a fabulous new TLS ciphersuite after the ADs tell everyone to "pound sand". I wonder if you have thought this through or prepped the stuckee? regards, Dan. On Tue, March 29, 2016 6:53 pm, Sean Turner wrote: > Hi! > > In Yokohama, we discussed changing the IANA registry assignment rules for > cipher suites to allow anyone with a stable, publicly available, peer > reviewed reference document to request and get a code point and to add an > “IETF Recommended” column to the registry. This change is motivated > by the large # of requests received for code points [0], the need to alter > the incorrect perception that getting a code point somehow legitimizes the > suite/algorithm, and to help implementers out. We need to determine > whether we have consensus on this plan, which follows: > > 1. The IANA registry rules for the TLS cipher suite registry [1] will be > changed to specification required. > > 2. A new “IETF Recommended” column will be added with two values: > “Y” or “N”. Y and N have the following meaning: > > Cipher suites marked with a “Y” the IETF has consensus on > and are reasonably expected to be supported by widely > used implementations such as open-source libraries. The > IETF takes no position on the cipher suites marked with an > “N”. Not IETF recommended does not necessarily (but can) > mean that the ciphers are not cryptographically sound (i.e., > are bad). Cipher suites can be recategorized from N to Y > (e.g., Curve448) and vice versa. > > 3. We will add a “Note" to the IANA registry itself (i.e., on [0]) that > matches the above so that the same information is available to those who > don’t read the IANA considerations section of the RFC. > > Please indicate whether or not you could support this plan. > > Thanks, > > J&S > > [0] In the last year, the chairs have received requests for: > > PSK: https://datatracker.ietf.org/doc/draft-mattsson-tls-ecdhe-psk-aead/ > AES-OCB: https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt > Kcipher2: https://datatracker.ietf.org/doc/draft-kiyomoto-kcipher2-tls/ > dragonfly: https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/ > NTRU: http://www.ietf.org/id/draft-whyte-qsh-tls12-01.txt > JPAKE: not sure they got around to publishing a draft. > > [1] > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Sun Apr 3 19:24:19 2016 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 31EF712D0A7 for ; Sun, 3 Apr 2016 19:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o599oP-y1Rpm for ; Sun, 3 Apr 2016 19:24:16 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 59BB312D099 for ; Sun, 3 Apr 2016 19:24:16 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4A9CA3F4024; Mon, 4 Apr 2016 02:24:15 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 2C09B3F401D; Mon, 4 Apr 2016 02:24:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459736655; bh=48IC1YBJd9LbY7Pp46kq75W64msIlmSwO12I9yMPEr4=; l=90; h=From:To:CC:Date:References:In-Reply-To:From; b=pkgh3MA/zZsyurAQeko15rV6ufmD1NV2/EIYi2Cw+jXimG+4yH4YZzZRwSX+KoJx+ m1NnodwVN+r5jmh4q5w7A3lp05Jx5F/d+nQSQBL0xxYojdGGel103gvvajeVDi832V 8mYvYak5mD4oNEIVRCvF75tTCflNGUsn8r4SWfrw= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 18F5A1FC96; Mon, 4 Apr 2016 02:24:15 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Sun, 3 Apr 2016 22:24:14 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Sun, 3 Apr 2016 22:24:14 -0400 From: "Salz, Rich" To: Dan Harkins , Sean Turner Thread-Topic: [TLS] call for consensus: changes to IANA registry rules for cipher suites Thread-Index: AQHRjhCy0gnRfZuwC0CV5/8Pwv8R5p95FfiQ Date: Mon, 4 Apr 2016 02:24:14 +0000 Message-ID: <20d2ca68d90646688963ea2d5a686afc@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <96b5aa358a8bcc0145dfcd935d20062b.squirrel@www.trepanning.net> In-Reply-To: <96b5aa358a8bcc0145dfcd935d20062b.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.172] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 02:24:18 -0000 > A stable, publicly available document is basically an RFC. Not always; ISO et al. From nobody Mon Apr 4 05:51:57 2016 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 63E0B12D0E4 for ; Mon, 4 Apr 2016 05:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZLIGuzxQDi5 for ; Mon, 4 Apr 2016 05:51:54 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 03C4012D0C0 for ; Mon, 4 Apr 2016 05:51:54 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 49BF01022404C; Mon, 4 Apr 2016 05:51:53 -0700 (PDT) Received: from 31.133.138.227 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 4 Apr 2016 05:51:53 -0700 (PDT) Message-ID: In-Reply-To: <20d2ca68d90646688963ea2d5a686afc@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <96b5aa358a8bcc0145dfcd935d20062b.squirrel@www.trepanning.net> <20d2ca68d90646688963ea2d5a686afc@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Mon, 4 Apr 2016 05:51:53 -0700 (PDT) From: "Dan Harkins" To: "Salz, Rich" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 12:51:55 -0000 On Sun, April 3, 2016 7:24 pm, Salz, Rich wrote: > >> A stable, publicly available document is basically an RFC. > > Not always; ISO et al. That's why I said "basically"; it's a qualifier. But keep in mind what kind of stable, publicly available document needs to be published: a description not of the algorithm but of how that algorithm get crammed into the TLS exchange. (For example, not RFC 7539 which describes chacha20+poly1305 as a glot but draft-ietf-tls-chacha20-poly1305 which says how to cram that glot into TLS). So even if some one/company was able to get a National Body to push in in ISO I doubt ISO would entertain documents whose content was "cram alg described elsewhere into TLS like this" with changes to ServerKeyExchange etc. Dan. From nobody Mon Apr 4 07:05:38 2016 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 4657F12D6EA for ; Mon, 4 Apr 2016 07:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m37Xd0sOmIsI for ; Mon, 4 Apr 2016 07:05:36 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 0341012D1A3 for ; Mon, 4 Apr 2016 07:05:36 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 81EE01022404C; Mon, 4 Apr 2016 07:05:34 -0700 (PDT) Received: from 31.133.176.131 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 4 Apr 2016 07:05:35 -0700 (PDT) Message-ID: <1640361f86795f7c3117d9c25be91a72.squirrel@www.trepanning.net> In-Reply-To: <56FD63B0.2070205@cs.tcd.ie> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> <56FD5CFC.8090508@gmx.net> <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> <56FD610F.10301@gmx.net> <56FD63B0.2070205@cs.tcd.ie> Date: Mon, 4 Apr 2016 07:05:35 -0700 (PDT) From: "Dan Harkins" To: "Stephen Farrell" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:05:37 -0000 On Thu, March 31, 2016 10:51 am, Stephen Farrell wrote: > > If smaller devices don't use algorithms that can be used to talk to > random servers on the Internet, then they are choosing to not try to > get interop. That seems like a shame to me, unless there's a really > good reason and IMO, mostly there isn't, at the ciphersuite level. I > would hope we all won't make the GCM/CCM mistake again for example > (that "we" being roughly some combination of IETF/IEEE folks). That's because you incorrectly define "interop" as talking to random servers on the Internet. This browser-centric mode of thinking causes you to reject cipher suites that the browser/webserver community does not have any interest in. There are use cases where some app doesn't want to talk to random servers on the Internet. It wants to talk to a set of specific servers providing a specific stream of information unique to the app-- think of some network monitoring or RF-quality app that provides sensing data to servers and also sucks down neighbor air quality information as it roams around. There are IoT use cases where devices just want to talk to each other, not random servers on the Internet. The browser community wants 0-RTT; I don't give a damn about 0-RTT. I want a PAKE (specifically TLS-pwd); the browser community doesn't give a damn about PAKEs. We are both right. Because we have different requirements. > So I think the proposed change here, if it leads to fewer but more > ubiquitously deployed ciphersuites, will help smaller devices. And I > do think the IETF recommended column might lead us some way in that > direction. Fewer is better... for one set of requirements, there's no reason to have umpteen (> 2) ways of meeting the requirements. But to approach this issue as if there is only one set of requirements (being able to talk to random web servers on the Internet) is to cram a multiplicity of differently shaped pegs into the proverbial round hole. regards, Dan. From nobody Mon Apr 4 07:17:45 2016 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 351AA12D712 for ; Mon, 4 Apr 2016 07:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9Z0YE27GBJV for ; Mon, 4 Apr 2016 07:17:42 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADDBE12D6BC for ; Mon, 4 Apr 2016 07:17:38 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id e6so181326577vkh.2 for ; Mon, 04 Apr 2016 07:17:38 -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; bh=4opLyDn01ArDSY3D2Qn81AAaNySymyXbulitn1hGtKU=; b=INGtUpFZJTrRYloMoVux1s8xqlas1OTme8GwGIuog9ET6qAKtUcZZhDxbTONlbHCL8 2CY+SBUQwLJAqxg95jFX11JRB5cyQBKrcU9mdXbh9SgVXJilGaKo7wJMoLnoNIGwkS/D oWZB33OL93wQ4B9xGrgNZxSCvV30sYgCdes0/guwtUy944rluqhpMQ5dDGjkTO9QZpVm oH+geix7uZAmtol9VGO0yDmQFiGaoRaavybYOb1SVCXcHQWtuy3gouwN6BQKNBQ2vTUt 9B+MqDptI/kz6SXC+k4wAM5JM+/nUC2KC+iiWEmKEA5CvFNxsnnKjZQccME/mR+KEPnr 2fLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=4opLyDn01ArDSY3D2Qn81AAaNySymyXbulitn1hGtKU=; b=N5iVcVpI00sf/1D1IQYtQemQJ0q95Z+9Kh1hy0B7ULV3ijCEtIaOUKqfXUpHVzkZ+c JN/QTUJ56ML1ZCNkpikfoWytkMd38xOGIxUMHZfW6QZKj49OPqG1I2yYfTNHLgjLQwbB GNG1uS0Xt7znWKlkNWuUyQ+UUb3LE0d3UMR/B7010/oC95APiEiUOs45YhKxCK4nHEUX E2rprOT9PSHm2LBFXxRXolCoUtEVOc7Gh7033BvfliFWWSWJkNwS6upF0f+CM6uouwEU C7+nSCgAsE1f1SkCBgar3d1gouWt16MDxRo/wmLJi4KGpNRxlK3+DyigeTVgIQ3CSwX7 +e6w== X-Gm-Message-State: AD7BkJJ5FcM/i+3VVifnckfLTQqt1WvGDyaM5gO2GcYThnJQU1SzRC2fXz7V/waeBncXgxEIdKYfRahE7lK8yQ== MIME-Version: 1.0 X-Received: by 10.176.1.74 with SMTP id 68mr4357248uak.56.1459779457780; Mon, 04 Apr 2016 07:17:37 -0700 (PDT) Received: by 10.176.1.208 with HTTP; Mon, 4 Apr 2016 07:17:37 -0700 (PDT) In-Reply-To: <1640361f86795f7c3117d9c25be91a72.squirrel@www.trepanning.net> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> <56FD5CFC.8090508@gmx.net> <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> <56FD610F.10301@gmx.net> <56FD63B0.2070205@cs.tcd.ie> <1640361f86795f7c3117d9c25be91a72.squirrel@www.trepanning.net> Date: Mon, 4 Apr 2016 07:17:37 -0700 Message-ID: From: Watson Ladd To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:17:44 -0000 On Mon, Apr 4, 2016 at 7:05 AM, Dan Harkins wrote: > > > On Thu, March 31, 2016 10:51 am, Stephen Farrell wrote: >> >> If smaller devices don't use algorithms that can be used to talk to >> random servers on the Internet, then they are choosing to not try to >> get interop. That seems like a shame to me, unless there's a really >> good reason and IMO, mostly there isn't, at the ciphersuite level. I >> would hope we all won't make the GCM/CCM mistake again for example >> (that "we" being roughly some combination of IETF/IEEE folks). > > That's because you incorrectly define "interop" as talking to > random servers on the Internet. This browser-centric mode of thinking > causes you to reject cipher suites that the browser/webserver > community does not have any interest in. > > There are use cases where some app doesn't want to talk to random > servers on the Internet. It wants to talk to a set of specific servers > providing a specific stream of information unique to the app-- think > of some network monitoring or RF-quality app that provides sensing > data to servers and also sucks down neighbor air quality information > as it roams around. There are IoT use cases where devices just want > to talk to each other, not random servers on the Internet. > > The browser community wants 0-RTT; I don't give a damn about 0-RTT. > I want a PAKE (specifically TLS-pwd); the browser community doesn't > give a damn about PAKEs. We are both right. Because we have different > requirements. Why can't embedded devices use certificates? -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Mon Apr 4 07:30:58 2016 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 E868612D734 for ; Mon, 4 Apr 2016 07:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCIpPxhlK1Bf for ; Mon, 4 Apr 2016 07:30:49 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 8E34D12D724 for ; Mon, 4 Apr 2016 07:30:44 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BC7D2433448; Mon, 4 Apr 2016 14:30:43 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id A658C433443; Mon, 4 Apr 2016 14:30:43 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459780243; bh=LR+Y0TWepSk+Pj8eNs3uF8KG73NXlopdk80fos05R5o=; l=555; h=From:To:CC:Date:References:In-Reply-To:From; b=UecWjTtDUeLnXmBiBcSigeL3uoyycGd3V4U8mVsavV3WPyuM8NXgt/11ZoCJDKirz DKyjwV58bUtHJWifzCaOcvlU7h4jQ4DwyFtKVekrl6PTf8FN8eUI9O3l1ZfUyMAdH4 sm//5NFMo0lxB9dksNaU4p2hoyUzsTzBGrtiDTkA= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id A2C931FCAC; Mon, 4 Apr 2016 14:30:43 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 4 Apr 2016 10:30:42 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Mon, 4 Apr 2016 10:30:42 -0400 From: "Salz, Rich" To: Dan Harkins Thread-Topic: [TLS] call for consensus: changes to IANA registry rules for cipher suites Thread-Index: AQHRjnDFCjSOucd6Mk6c+fNeRoZL15950+8Q Date: Mon, 4 Apr 2016 14:30:42 +0000 Message-ID: <4f8be1d62df842df85786fa4ed4c85dd@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <96b5aa358a8bcc0145dfcd935d20062b.squirrel@www.trepanning.net> <20d2ca68d90646688963ea2d5a686afc@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.113.171] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:30:51 -0000 > > Not always; ISO et al. >=20 > That's why I said "basically"; it's a qualifier. I know; I was trying to emphasize, not correct :). =20 > But keep in mind what kind of stable, publicly available document needs= to > be published: a description not of the algorithm but of how that algorith= m > get crammed into the TLS exchange That is a good point. But most offerings we have seen so far are about na= tional bulk encryption ciphers and not, say, new key-exchange methods (GOST= the only one so far?). Of course that might change. From nobody Mon Apr 4 07:36:38 2016 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 A1EEE12D732 for ; Mon, 4 Apr 2016 07:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gelM5__4fVqG for ; Mon, 4 Apr 2016 07:36:35 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBFA12D730 for ; Mon, 4 Apr 2016 07:36:35 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id BF5711022404C; Mon, 4 Apr 2016 07:36:34 -0700 (PDT) Received: from 31.133.176.131 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 4 Apr 2016 07:36:35 -0700 (PDT) Message-ID: In-Reply-To: References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> <56FD5CFC.8090508@gmx.net> <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> <56FD610F.10301@gmx.net> <56FD63B0.2070205@cs.tcd.ie> <1640361f86795f7c3117d9c25be91a72.squirrel@www.trepanning.net> Date: Mon, 4 Apr 2016 07:36:35 -0700 (PDT) From: "Dan Harkins" To: "Watson Ladd" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:36:37 -0000 On Mon, April 4, 2016 7:17 am, Watson Ladd wrote: > On Mon, Apr 4, 2016 at 7:05 AM, Dan Harkins wrote: >> >> >> On Thu, March 31, 2016 10:51 am, Stephen Farrell wrote: >>> >>> If smaller devices don't use algorithms that can be used to talk to >>> random servers on the Internet, then they are choosing to not try to >>> get interop. That seems like a shame to me, unless there's a really >>> good reason and IMO, mostly there isn't, at the ciphersuite level. I >>> would hope we all won't make the GCM/CCM mistake again for example >>> (that "we" being roughly some combination of IETF/IEEE folks). >> >> That's because you incorrectly define "interop" as talking to >> random servers on the Internet. This browser-centric mode of thinking >> causes you to reject cipher suites that the browser/webserver >> community does not have any interest in. >> >> There are use cases where some app doesn't want to talk to random >> servers on the Internet. It wants to talk to a set of specific servers >> providing a specific stream of information unique to the app-- think >> of some network monitoring or RF-quality app that provides sensing >> data to servers and also sucks down neighbor air quality information >> as it roams around. There are IoT use cases where devices just want >> to talk to each other, not random servers on the Internet. >> >> The browser community wants 0-RTT; I don't give a damn about 0-RTT. >> I want a PAKE (specifically TLS-pwd); the browser community doesn't >> give a damn about PAKEs. We are both right. Because we have different >> requirements. > > Why can't embedded devices use certificates? Code bloat for a one-off enrollment protocol, no way to authenticate to obtain the certificate, and the continued lack of that Global PKI that was supposed to take care of everything and that is currently 20 years late in being delivered. Actually, that's not quite right. Some do use certificates...wrongly. Usually what happens is the server generates a self-signed certificate and the apps are given some "username" and "password" and the app ignores the unauthenticated nature of the TLS connection and sends the u/p credential on through. Dan. From nobody Mon Apr 4 07:40:22 2016 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 15F1912D74E for ; Mon, 4 Apr 2016 07:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4I7e0ZIB0hw for ; Mon, 4 Apr 2016 07:40:18 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 947F612D75F for ; Mon, 4 Apr 2016 07:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1459780790; x=1491316790; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TjHRxo+zt8ed4sby50xDy3VpSH13IOTEiu4l+LVCrl4=; b=th4GE+C7RfFrpMKt+U1mAEiTBeLDOxfNlRCFS3m5fcKCvBHUAU3y8ZS9 /NLmdjQqGALWR34YAPxbJC1VC/++CwrlgCourUo9M83hV6NjUxB7n4p5q +nZkS3fn3oln+ZAfqj4M730YD2slHJoRVeKg04S2ISC+7ErUbCmg7YH7y eR5dnsNRZufG/UVby0LMsLN3Z/62Yw4IQ/OypdqwmvHeLEAIRKNWR1ZbJ Gcpfh6AN1kWsTMT5qhyuuug4O/yQ818YB61yWLMPbGTKi2yYZ3D2T+hn/ X6jcyBztlA+aLYas1vOShniySvvBaHiI7cfcCC9kkPKzLbvPijmpLeGo3 A==; X-IronPort-AV: E=Sophos;i="5.24,440,1454929200"; d="scan'208";a="78065165" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 05 Apr 2016 02:39:48 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.241]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Tue, 5 Apr 2016 02:39:48 +1200 From: Peter Gutmann To: Watson Ladd , Dan Harkins Thread-Topic: [TLS] call for consensus: changes to IANA registry rules for cipher suites Thread-Index: AQHRi1OuU0aLD2CoU020MlW0nXLdGp9y3RMAgAAEsgCAAAkrgIAABHGAgAABqACAAADdAIAAAYAAgAAAugCAAAQigIAAAyIAgAYa54CAAANdgIAAzzMN Date: Mon, 4 Apr 2016 14:39:47 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C3852F@uxcn10-tdc05.UoA.auckland.ac.nz> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> <56FD5CFC.8090508@gmx.net> <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> <56FD610F.10301@gmx.net> <56FD63B0.2070205@cs.tcd.ie> <1640361f86795f7c3117d9c25be91a72.squirrel@www.trepanning.net>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:40:21 -0000 Watson Ladd writes:=0A= =0A= >Why can't embedded devices use certificates?=0A= =0A= Because they have neither a DNS name nor a fixed IP address. I ran into th= is=0A= just last week with a customer, they couldn't use certs for their embedded= =0A= devices and couldn't use PSK because the browser vendors have chosen not to= =0A= support it. As a result, they abandoned the use of TLS altogether and went= =0A= with SSH.=0A= =0A= Peter.= From nobody Mon Apr 4 07:44:54 2016 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 6881912D6F9 for ; Mon, 4 Apr 2016 07:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7O8i0pvg8TI for ; Mon, 4 Apr 2016 07:44:51 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id BB69812D55E for ; Mon, 4 Apr 2016 07:44:51 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0CC8016D13B; Mon, 4 Apr 2016 14:44:51 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id E0D2216CEB2; Mon, 4 Apr 2016 14:44:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459781090; bh=YvEfqxkqA65UG2SyBQt9h9iwFul1U63m0kmCrELgxZ8=; l=2870; h=From:To:Date:References:In-Reply-To:From; b=MkIP/tz1j8CHJvSCnIb1nRwovqm3W0vcEovDrkE5GQrghA43js2K4kOhEuXBOVzVi 7/UTSFJmShYCVVi0ofpkaa3ugZAqVlXP26G0E3CKY6m+t7IxioTQYBEOBlfSmOOjXD wFmpvA2yNfvb5fV6Z1AzG4d087tHAeeACV1Q0sqI= Received: from email.msg.corp.akamai.com (um-cas.msg.corp.akamai.com [172.27.25.33]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id DDC131E07C; Mon, 4 Apr 2016 14:44:50 +0000 (GMT) Received: from ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 4 Apr 2016 09:44:50 -0500 Received: from ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.27.107]) by ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.27.107]) with mapi id 15.00.1130.005; Mon, 4 Apr 2016 07:44:50 -0700 From: "Kaduk, Ben" To: Karthik Bhargavan , "tls@ietf.org" Thread-Topic: [TLS] Avoiding Trial Decryption (for 0-RTT) Thread-Index: AQHRjQm8JFlri5PmdkiUvkgiHg1xY596CIoA Date: Mon, 4 Apr 2016 14:44:50 +0000 Message-ID: References: <4288B225-3CA9-426B-B352-FCC461E607B4@inria.fr> In-Reply-To: <4288B225-3CA9-426B-B352-FCC461E607B4@inria.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.47.14] Content-Type: text/plain; charset="utf-8" Content-ID: <569F3FC98904DF468537D33696F2EBF0@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Avoiding Trial Decryption (for 0-RTT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:44:53 -0000 T24gNC8yLzE2LCAxNDo1MywgIkthcnRoaWsgQmhhcmdhdmFuIiA8a2FydGhpa2V5YW4uYmhhcmdh dmFuQGlucmlhLmZyPiB3cm90ZToNCg0KPg0KPkhlcmUgaXMgYSBwcm9wb3NhbCB0aGF0IHdvdWxk IGF2b2lkIHRyaWFsIGRlY3J5cHRpb24uDQo+V2hlbiB0aGUgY2xpZW50IHNlbmRzIDAtUlRUIGFw cGxpY2F0aW9uIGRhdGEsIGl0IGN1cnJlbnRseQ0KPmVuZHMgdGhpcyBmbGlnaHQgb2YgbWVzc2Fn ZXMgd2l0aCBhbiBlbmNyeXB0ZWQgZW5kX29mX2Vhcmx5IGRhdGEgd2FybmluZyBhbGVydC4NCj5I b3cgYWJvdXQ6IGlmIHRoZSBzZXJ2ZXIgcmVqZWN0cyB0cmlhbCBkZWNyeXB0aW9uLCB0aGUgY2xp ZW50DQo+bXVzdCB0aGVuIHNlbmQgYW4gKnVuZW5jcnlwdGVkKiBlbmRfb2ZfZWFybHlfZGF0YSB3 YXJuaW5nIGFsZXJ0IGJlZm9yZQ0KPmNvbnRpbnVpbmcgd2l0aCAxLVJUVCBoYW5kc2hha2UgZGF0 YS4NCj5UaGUgc2VydmVyIGNvdWxkIHRoZW4gZWFzaWx5IGRpc2NhcmQgYWxsIHJlY29yZHMgdW50 aWwgaXQgc2VlcyB0aGlzIHdhcm5pbmcgYWxlcnQuDQo+DQo+VGhlIG1haW4gZGlzYWR2YW50YWdl IG9mIHRoaXMgYXBwcm9hY2ggc2VlbXMgdG8gYmUgdGhhdCBpdCByZXZlYWxzIHRvIHRoZSBhZHZl cnNhcnkNCj50aGUgcG9pbnQgYXQgd2hpY2ggdGhlIDAtUlRUIGFwcGxpY2F0aW9uIGRhdGEgZW5k cyAoaWYgdGhpcyBpcyBzZW5zaXRpdmUgaW5mb3JtYXRpb24uKQ0KPkhvd2V2ZXIsIG5vdGUgdGhh dCBpZiB0aGUgbGVuZ3RoIG9mIDAtUlRUIGRhdGEgd2FzIHNlbnNpdGl2ZSwgYW4gYXR0YWNrZXIN Cj5jb3VsZCBwcm9iYWJseSBhbHJlYWR5IG9idGFpbiBpdCBieSBkZWxheWluZyB0aGUgc2VydmVy IGZsaWdodC4NCj4NCj5Eb2VzIGFueW9uZSBzZWUgb3RoZXIgcHJhY3RpY2FsIG9yIHNlY3VyaXR5 IGRpc2FkdmFudGFnZXMgdG8gdXNpbmcgdGhpcyBhbGVydD8NCg0KSSB0cmllZCB0byB0aGluayBv ZiB3YXlzIHRoYXQgYSBtaXNiZWhhdmluZyBjbGllbnQgKG9yIGF0dGFja2VyKSBjb3VsZCBjYXVz ZSBhIHNlcnZlciByZWx5aW5nIG9uIHRoZSB1bmVuY3J5cHRlZCBhbGVydCB0byBjb25zdW1lIHJl c291cmNlcyBhbmQgc2l0IGFyb3VuZCB3YWl0aW5nIGZvciBhIGxvbmcgdGltZSwgYnV0IGl0IHNl ZW1zIGxpa2UgdGhlIHVuZW5jcnlwdGVkIGFsZXJ0IGlzIHN0cmljdGx5IGJldHRlciB0aGFuIHRy aWFsIGRlY3J5cHRpb24gaW4gdGhhdCByZWdhcmQgKHNpbmNlIHRoZSBzZXJ2ZXIgZG9lc24ndCBo YXZlIHRvIGJ1cm4gQ1BVIG9uIGRlY3J5cHRpb24pLiAgU28sIGl0IHNlZW1zIHRoYXQgcmV2ZWFs aW5nIHRoZSBsZW5ndGggb2YgdGhlIDAtUlRUIGRhdGEgaXMgdGhlIG1haW4gZGlzYWR2YW50YWdl LCBidXQgYXMgSWxhcmkgbm90ZXMsIHRoZXJlIGFyZSBsaWtlbHkgdG8gYmUgb3RoZXIgY2hhbm5l bHMgdGhhdCB3b3VsZCBsZWFrIHRoYXQgYm91bmRhcnkgaW4gbWFueSBjYXNlcy4NCg0KVXNpbmcg dGhlIHVuZW5jcnlwdGVkIGFsZXJ0IGRvZXMgYWxzbyBwcm92aWRlIGEgY2xlYXIgaW5kaWNhdGlv biB0aGF0IHRoZSBjbGllbnQvc2VydmVyIGZhaWxlZCB0byBleGNoYW5nZSAwLVJUVCBkYXRhOyBm b3IgYSBQU0sgbW9kZSB3aXRoIGEgY2FjaGUgb2YgMC1SVFQgc2Vzc2lvbnMgdGhpcyBjb3VsZCBw cm92aWRlIGEgd2luZG93IGludG8gdGhlIHZhbGlkaXR5IHBlcmlvZHMgdXNlZCBieSB0aGUgdHdv IHBhcnRpZXMgb3IgYXMgYSBzaWduYWwgdGhhdCBhIGZpbml0ZS1zaXplZCBjYWNoZSBpcyBmdWxs IGFuZCBlamVjdGluZyBvbGQgZW50cmllcy4gIFBlcmhhcHMgYW4gYXR0YWNrZXIgY291bGQgdXNl IHRoYXQgc2lnbmFsIHRvIGRldGVybWluZSB0aGUgcmF0ZSBvZiBzb21lIG90aGVyIHNvcnQgb2Yg YXR0YWNrIHRoYXQgcmVxdWlyZXMgZ2V0dGluZyBhIHNlc3Npb24gZXZpY3RlZCBmcm9tIHRoZSBj YWNoZSwgYnV0IHRoZSBuZWVkIGZvciBzdWNoIGEgc2lnbmFsIHNlZW1zIHByZXR0eSBoeXBvdGhl dGljYWwsIGdpdmVuIHRoYXQgYW4gYXR0YWNrZXIgY2FuIGFscmVhZHkgY2xhaW0gdG8gYmUgYXMg bWFueSBkaWZmZXJlbnQgY2xpZW50cyBhcyBpdCB3YW50cy4NCg0KLUJlbg0K From nobody Mon Apr 4 08:24:47 2016 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 972B412D75D for ; Mon, 4 Apr 2016 08:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwPpQElDtgd4 for ; Mon, 4 Apr 2016 08:24:41 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1185512D730 for ; Mon, 4 Apr 2016 08:24:41 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id k1so184242947vkb.0 for ; Mon, 04 Apr 2016 08:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=JyeoqmZku8yLkW3YfJE+TqstmpQXc1OnujN9Pa/fwvU=; b=XL4Vq3AgVwHxYol+a6Rop5TKcq75p8LT41Ezq/OSroB0zMrIsLA1Z5FIeWgNM/nuHB LPMtlLjygG8l+2GaXWTHydiRiUSG+X3BQVG4nRsJBdaaCDLlbPj/A0QQtXMZ888EznHX zew4acx+3ZGrYGjubtlaIMxra693S4nUvFczT1zGHna7RfwlwDGULAq+yQkiYTvMeOUV e95mq367AGFBmg9IXHjQv20Lpe5bwwfznon/9xmyNSVdZBorcftySy4mYDJrGaMCv/cA yDtVscEWz0WM4Rop17RKyAdG2H8/+p6ZWhOG6vbgj1PpgPmpdvl5Ol/xI+49OWSKWLhj ujcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=JyeoqmZku8yLkW3YfJE+TqstmpQXc1OnujN9Pa/fwvU=; b=RkWdMYLLoxUEPOFdcH3SrLyUW1Z1aHVI7BrneWIv77sIWNKoFeaPjFDHLaEmaoEFci U9GX7plHsQk7NWsnzmkq2RxhpyTb5R5qQ5UtAP/ReZxwywryiUPCXKHc7ztHJ3H6OKxV AoApX6LWf3+H9WAt2sWhknMttrQz+5UyLvMpcSGEAd43clXWYd2v3zaIJiRn2ENUsL+h JicoWuk9gGQPg5HabkhZgIZRiLh35vXZp3cLt269vILCt2UuxQkhlJRLNkPF/a8873xN 5DNbXfoxTNh06RLw9aEUQLn+UeY43P7aHEHS0IhZlrByO72rurDIRd7Eew1twX3lBkSq Xq9A== X-Gm-Message-State: AD7BkJJvJpAdBbQ19q2QXEAi+6ktv2M+naAXOn29bSKZaQWwO0FOH2ZPR7FrcdnTVzbFpVwD2Jqvwn4bjUCuIg== MIME-Version: 1.0 X-Received: by 10.31.173.18 with SMTP id w18mr8692866vke.31.1459783480053; Mon, 04 Apr 2016 08:24:40 -0700 (PDT) Received: by 10.176.1.208 with HTTP; Mon, 4 Apr 2016 08:24:39 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C3852F@uxcn10-tdc05.UoA.auckland.ac.nz> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> <56FD5CFC.8090508@gmx.net> <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> <56FD610F.10301@gmx.net> <56FD63B0.2070205@cs.tcd.ie> <1640361f86795f7c3117d9c25be91a72.squirrel@www.trepanning.net> <9A043F3CF02CD34C8E74AC1594475C73F4C3852F@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Mon, 4 Apr 2016 08:24:39 -0700 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 15:24:44 -0000 On Mon, Apr 4, 2016 at 7:39 AM, Peter Gutmann wrote: > Watson Ladd writes: > >>Why can't embedded devices use certificates? > > Because they have neither a DNS name nor a fixed IP address. I ran into this > just last week with a customer, they couldn't use certs for their embedded > devices and couldn't use PSK because the browser vendors have chosen not to > support it. As a result, they abandoned the use of TLS altogether and went > with SSH. Actually, PKI certs are not required. There is an extension to support use of bare keys for authentication. And if you can provision with a shared secret, you can provision with a private key. > > Peter. -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Mon Apr 4 08:36:32 2016 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 8C21A12D734 for ; Mon, 4 Apr 2016 08:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yp5PDgl6XcPi for ; Mon, 4 Apr 2016 08:36:27 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B14312D720 for ; Mon, 4 Apr 2016 08:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1459784187; x=1491320187; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=atMN0IEGSDqlx3CjtvmpQ3Cp0jKze/8OhVehpE5gAjw=; b=4ujIb5loQ/ZdKDE5AebQe5z51fabL5/fcQkIainGGj+i5GEvqEGDfEMm HPFs1Agiyrfu0eAd2++xMMxA31ohTTuh0NjIQzUjTXSVdInmaY2w4yXUb F5REcYMPonyFnyDOA8Gus4rd6yHFodIexGU28+pyAfzeGlQM4Jnl1ftWw v/mmnFUnlcprC0GvKmbTs4oyChAulA7KlpJ+EjjTXP1X0zIL+UIj22yfI 98x5wxara4B6JrZBE7BMWd+DQ48yT/sTNva176ak+yjWgfb5XaenmRoNK IQXbNscgND/C9jxMiOLPI7vgojNRbBfeB/wy0EgGhkgTbyByoBYUCrI6z g==; X-IronPort-AV: E=Sophos;i="5.24,441,1454929200"; d="scan'208";a="78069794" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 05 Apr 2016 03:36:25 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.241]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Tue, 5 Apr 2016 03:36:25 +1200 From: Peter Gutmann To: Watson Ladd Thread-Topic: [TLS] call for consensus: changes to IANA registry rules for cipher suites Thread-Index: AQHRi1OuU0aLD2CoU020MlW0nXLdGp9y3RMAgAAEsgCAAAkrgIAABHGAgAABqACAAADdAIAAAYAAgAAAugCAAAQigIAAAyIAgAYa54CAAANdgIAAzzMN//9DiICAAMxfuQ== Date: Mon, 4 Apr 2016 15:36:25 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C385D9@uxcn10-tdc05.UoA.auckland.ac.nz> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> <56FD5CFC.8090508@gmx.net> <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> <56FD610F.10301@gmx.net> <56FD63B0.2070205@cs.tcd.ie> <1640361f86795f7c3117d9c25be91a72.squirrel@www.trepanning.net> <9A043F3CF02CD34C8E74AC1594475C73F4C3852F@uxcn10-tdc05.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 15:36:31 -0000 Watson Ladd writes:=0A= =0A= >Actually, PKI certs are not required. There is an extension to support use= of=0A= >bare keys for authentication. And if you can provision with a shared secre= t,=0A= >you can provision with a private key.=0A= =0A= And how many browsers support that?=0A= =0A= Peter.= From nobody Mon Apr 4 08:50:48 2016 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 96F1D12D591 for ; Mon, 4 Apr 2016 08:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dunlop-lello-uk.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMXPqt8tIg91 for ; Mon, 4 Apr 2016 08:50:43 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11E5612D5F5 for ; Mon, 4 Apr 2016 08:50:43 -0700 (PDT) Received: by mail-lb0-x233.google.com with SMTP id u8so167167437lbk.0 for ; Mon, 04 Apr 2016 08:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dunlop-lello-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=E2djDmv4CMXYzYpBWqf9guhWxM+vULzg6aZ/WvDadSA=; b=NPdDDVNrWn6s1dg5O3PQKsesyQihSaNPXvzXEN3C5b7yvTnhW9U9cUGUQ/suXDBcc0 z4OuReHZNjInf/rjeFK2LkFRDBeUXEULkALOzMSWfBZfhGn0UDNvRURt3pTGUqzz+jBj JV4Z4qfC8Fn7nXbErk1reEDqCzomqJbK9B7RhidJlpix6R9fyFu2sESwQHWwJlzDcqzu ctFx/UXkcLGlrWg4cnrQwXMc/VzvPlvk1hV+5PhnGHssrZVaHDHcIR1CM1v7BPsTPTI+ 3tgqgsaxLJMLUohzjVwkav5BoHBDiX3j39AHxrSppRS46lHWddypzP/IixVsEAyUZe+l D1qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=E2djDmv4CMXYzYpBWqf9guhWxM+vULzg6aZ/WvDadSA=; b=OS+FaLDnQp6tmXIwSRbVWZeimCkZSm+5aH3n9c+hXot/wGutgnLpsjAStj42CoPSO2 Ncc8prgx88Bi1aGdkgtJm3sSmaMrbrMU39al1ipP4UUzL4q1sFJCq+F4bxFRygFUao2Y 14suu/jl0tm5YQUVBjkvijwugfLG62f7bcDo/9osrIajneCLv1YfTB3SwnbHXOkPQfMF FWQCzUeKqGTlO6DadKWvZbmR6He1PQiUjTaeGsZ8vx+ekq8NKLNLUz4Jy2AqgBI/NKzu NFNuVNwYtBGh+JvHYWjvXdbRdSVAnf6TYpTWecC4/9/QwKKlCjOrUfbvY3CXm4Nku7E0 LnEA== X-Gm-Message-State: AD7BkJKBq41GCnQ6EL8qvmQEBOjdZbjMn5EXkELxt0YfujPFGvUjLtLlePKTe3EYNLnSuUcT43+a4s+2fkG+fGZN MIME-Version: 1.0 X-Received: by 10.112.235.71 with SMTP id uk7mr4025313lbc.39.1459785041255; Mon, 04 Apr 2016 08:50:41 -0700 (PDT) Received: by 10.25.40.85 with HTTP; Mon, 4 Apr 2016 08:50:40 -0700 (PDT) In-Reply-To: References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> <56FD5CFC.8090508@gmx.net> <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> <56FD610F.10301@gmx.net> <56FD63B0.2070205@cs.tcd.ie> <1640361f86795f7c3117d9c25be91a72.squirrel@www.trepanning.net> Date: Mon, 4 Apr 2016 16:50:40 +0100 Message-ID: From: Phil Lello To: Dan Harkins Content-Type: multipart/alternative; boundary=001a11c3c5c2d53ea4052faab04b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 15:50:46 -0000 --001a11c3c5c2d53ea4052faab04b Content-Type: text/plain; charset=UTF-8 On Mon, Apr 4, 2016 at 3:36 PM, Dan Harkins wrote: > > > On Mon, April 4, 2016 7:17 am, Watson Ladd wrote: > > Usually what happens is the server generates a self-signed certificate > and the apps are given some "username" and "password" and the app > ignores the unauthenticated nature of the TLS connection and sends > the u/p credential on through. Isn't this use case more of an argument for an updated auth-digest to use something better than MD5? I'm not convinced MITM is a real concern for a typical IoT environment (however that's defined - I'm assuming http in a domestic environment). Best wishes, Phil Lello --001a11c3c5c2d53ea4052faab04b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 4, 2016 at 3:36 PM, Dan Harkins <dharkins@lounge.org= > wrote:
=


On Mon, April 4, 2016 7:17 am, Watson Ladd wrote:

Usually what happens is the server generates a self-signed certificate
and the apps are given some "username" and "password" a= nd the app
ignores the unauthenticated nature of the TLS connection and sends
the u/p credential on through.

Isn't this use case mo= re of an argument for an updated auth-digest to use something better than M= D5? I'm not convinced MITM is a real concern for a typical IoT environm= ent (however that's defined - I'm assuming http in a domestic envir= onment).

Best wishes,

Phil Lello
--001a11c3c5c2d53ea4052faab04b-- From nobody Mon Apr 4 09:35:39 2016 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 DE09712D139 for ; Mon, 4 Apr 2016 09:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63HvfgrIcRNP for ; Mon, 4 Apr 2016 09:35:35 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id EA56312D11E for ; Mon, 4 Apr 2016 09:35:34 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3BA03433441; Mon, 4 Apr 2016 16:35:34 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 24E3B433404; Mon, 4 Apr 2016 16:35:34 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459787734; bh=xbWDOed5eDjaOqYpN5OpwTb7qEWrsk6vthEHq81ukfs=; l=592; h=From:To:CC:Date:References:In-Reply-To:From; b=tuPBbZ3Z+GI3llJz4MiBi4kE3uyqadnRqruqRf4vOxEBQvtGZtRK2fFovmyIe+j70 oY5cODzlsBBFWR/l7M5swBT2yc1HZJzBBYfk6jc4TRBiuCpdg+ici4rZheJv1ROIuJ mqELzBOr31pxzslkLCWwMITVXOwVVNnVm0Z43oZs= Received: from email.msg.corp.akamai.com (um-cas.msg.corp.akamai.com [172.27.25.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 0BAA71FC96; Mon, 4 Apr 2016 16:35:34 +0000 (GMT) Received: from ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 4 Apr 2016 11:35:33 -0500 Received: from ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.27.107]) by ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.27.107]) with mapi id 15.00.1130.005; Mon, 4 Apr 2016 09:35:33 -0700 From: "Kaduk, Ben" To: Phil Lello Thread-Topic: [TLS] call for consensus: changes to IANA registry rules for cipher suites Thread-Index: AQHRjnzIm6ry6psEtk+J3zO3TH6iyJ96VyWAgAAUswD//7i6AA== Date: Mon, 4 Apr 2016 16:35:33 +0000 Message-ID: <99655133-DA79-42EE-B718-41E598751645@akamai.com> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> <56FD5CFC.8090508@gmx.net> <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> <56FD610F.10301@gmx.net> <56FD63B0.2070205@cs.tcd.ie> <1640361f86795f7c3117d9c25be91a72.squirrel@www.trepanning.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.82] Content-Type: text/plain; charset="utf-8" Content-ID: <77E9080A23929846ADD0E41D337A315C@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 16:35:37 -0000 T24gNC80LzE2LCAxMjo1MCwgIlBoaWwgTGVsbG8iIDxwaGlsQGR1bmxvcC1sZWxsby51az4gd3Jv dGU6DQoNCj4NCj4NCj5PbiBNb24sIEFwciA0LCAyMDE2IGF0IDM6MzYgUE0sIERhbiBIYXJraW5z IA0KPjxkaGFya2luc0Bsb3VuZ2Uub3JnPiB3cm90ZToNCj4NCj4NCj4NCj4NCj5Jc24ndCB0aGlz IHVzZSBjYXNlIG1vcmUgb2YgYW4gYXJndW1lbnQgZm9yIGFuIHVwZGF0ZWQgYXV0aC1kaWdlc3Qg dG8gdXNlIHNvbWV0aGluZyBiZXR0ZXIgdGhhbiBNRDU/IEknbSBub3QgY29udmluY2VkIE1JVE0g aXMgYSByZWFsIGNvbmNlcm4gZm9yIGEgdHlwaWNhbCBJb1QgZW52aXJvbm1lbnQgKGhvd2V2ZXIg dGhhdCdzIGRlZmluZWQgLSBJJ20gYXNzdW1pbmcgaHR0cCBpbiBhIGRvbWVzdGljIGVudmlyb25t ZW50KS4NCg0KTGlrZSBSRkMgNzYxNj8NCg0KLUJlbg0K From nobody Mon Apr 4 10:03:33 2016 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 D5B6F12D600 for ; Mon, 4 Apr 2016 10:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2n8_e1knpLY3 for ; Mon, 4 Apr 2016 10:03:29 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54F9612D52F for ; Mon, 4 Apr 2016 10:03:29 -0700 (PDT) Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u34GURIt032141; Mon, 4 Apr 2016 09:37:00 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=facebook; bh=O1/Uu/Nr5U9yHuq0KySnEr0p9WVu2fc3/tFCPuP/Dd0=; b=V5CLuHqNMkY7991CBfSualF3xcJELJDF0z2R39GlP4i4hCdQQ3i0o4ZEqEKtGwq4Dg05 Kk8VMAuOHKIFpGxAluDeRrTnP8ZzX8IHyzbUc+y7dVO7DLq1L0l/XKFQTLlAlvuG/1I3 zmEjxLuehmOueSRP+nTs4rIO+StZ6iVs9+Q= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 223up186rh-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 04 Apr 2016 09:37:00 -0700 Received: from PRN-MBX01-4.TheFacebook.com ([169.254.3.151]) by PRN-CHUB16.TheFacebook.com ([fe80::7948:a494:45d7:3dd9%12]) with mapi id 14.03.0248.002; Mon, 4 Apr 2016 09:36:58 -0700 From: Subodh Iyengar To: Dan Harkins , Sean Turner Thread-Topic: [TLS] Call for consensus: Removing 0-RTT client auth Thread-Index: AQHRibrYKIycdbeyKkCF0K4tfALgkp95d/wAgACPC8k= Date: Mon, 4 Apr 2016 16:36:58 +0000 Message-ID: <974CF78E8475CD4CA398B1FCA21C8E995650125D@PRN-MBX01-4.TheFacebook.com> References: , <9d1de55db58e33f7e564a03bc140cb49.squirrel@www.trepanning.net> In-Reply-To: <9d1de55db58e33f7e564a03bc140cb49.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-04_07:, , signatures=0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Call for consensus: Removing 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 17:03:32 -0000 If DH 0-RTT client auth is removed, most apps will start using client auth = with PSK 0-RTT handshakes which is the current state in TLS 1.2 (with ticke= ts) as Bill previous mentioned. We've encountered implications of this when= using TLS1.2 for internal authentication. The tradeoff here is that a serv= er that shares a ticket key with another server can masquerade as any clien= t to the other server. This is a performance / security tradeoff here, and = we solve this using partitioning of ticket keys between untrustworthy serve= rs. There are several other implications of session tickets that we already= deal with for this security / performance tradeoff, and this is not the wo= rst one. =0A= =0A= I don't think having some form of 0-RTT client auth is a bad thing since th= ere are engineering implications of not providing client auth during 0-RTT.= =0A= A server app is using TLS for cert authentication and doing it's own author= ization, it might provide certain methods to be accessible without authoriz= ation, but others with authorization. In a lot of application protocols, th= e client would not know about this aproiri. Not having a form of client aut= h would obviate these from using 0-RTT completely which would be sad.=0A= =0A= Since 0-RTT DH is still under discussion, maybe we should revisit 0-RTT DH = client auth after that is decided?=0A= =0A= Subodh Iyengar=0A= ________________________________________=0A= From: TLS [tls-bounces@ietf.org] on behalf of Dan Harkins [dharkins@lounge.= org]=0A= Sent: Sunday, April 03, 2016 5:43 PM=0A= To: Sean Turner=0A= Cc: tls@ietf.org=0A= Subject: Re: [TLS] Call for consensus: Removing 0-RTT client auth=0A= =0A= Hi Sean & Joe,=0A= =0A= On Tue, March 29, 2016 5:59 am, Sean Turner wrote:=0A= > All,=0A= >=0A= > To make sure we=E2=80=99ve got a clear way forward coming out of our BA= =0A= > sessions, we need to make sure there=E2=80=99s consensus on a couple of= =0A= > outstanding issues. So...=0A= >=0A= > It seems that there is a clear consensus not to support 0-RTT client=0A= > authentication in TLS 1.3 at this time. If you think 0-RTT client=0A= > authentication needs to be supported please indicate so now and provide= =0A= > your rationale.=0A= =0A= I don't think it needs to be supported and would be happy if=0A= it was removed. It's a dangerous and flawed feature. My concern=0A= is that if (which I fear is pronounced "when") an exploit is found=0A= it might be easy to remove in a browser update but there's gonna=0A= be some large TLS concentrator vendor that'll have a helluva time=0A= getting its deployed boxes patched and it'll be ugly.=0A= =0A= The rationale for this-- to get an ad to me just that much faster=0A= (an ad, I note, that I sure hope my ad blocking software will prevent=0A= me from seeing), and that the people who want to do this know what=0A= they're doing so it'll all be fine (which is not reassuring in the=0A= least)-- just does not justify the risk.=0A= =0A= regards,=0A= =0A= Dan.=0A= =0A= =0A= _______________________________________________=0A= TLS mailing list=0A= TLS@ietf.org=0A= https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_tls&d=3DCwIFaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-wAyN= 7fQ&m=3D0Wl8UysaIyWxp0Iw_9TKo4jE9Iwn7DnABCdnYWj_2Kk&s=3D2SuDKxG_YMEaEm1zqgK= y4-aHt4NzUB9QVq8SzByaqp8&e=3D=0A= From nobody Mon Apr 4 10:25:07 2016 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 EFCB712D7E3 for ; Mon, 4 Apr 2016 10:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dunlop-lello-uk.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3G7dW7dvYwvQ for ; Mon, 4 Apr 2016 10:24:55 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD4CA12D7E2 for ; Mon, 4 Apr 2016 10:24:54 -0700 (PDT) Received: by mail-lb0-x235.google.com with SMTP id vo2so172104859lbb.1 for ; Mon, 04 Apr 2016 10:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dunlop-lello-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=RLwZISh1iKu4O/pd2RqS5b8sdOPvyPnkwJwZNsbKGyM=; b=1UB08PwRcZ+bSekrRX3LHY2ZtRVZoCOUqsx/8ONZm+EfVyApD07nmiXtneG6zwSYKb nJhI81U48bR6Hd4LTXUTfvKjJj7w2Obuw0B56oepoPCAERHcKjO4g9RWvOllJ9BofAMZ lC5esZakNlY03o30Sb4NpMc5kuCsuj3hz8Rhl8S9EQ/w9ihyZ7dq32R0oxCoWmQa+t9/ Rsb5qVDflGK9cvuxHXeyiXXwu5Hj8CZUkfgA80Xu884QQeRbkh7wqwQ+aCRyA3mexURW qYf74FZVeofI0vvR8FnS3XNIrUfTtJYBjqW4Ed1u0DBjJNCn6IZE1Zp+b+c7SJas9Uek dUqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=RLwZISh1iKu4O/pd2RqS5b8sdOPvyPnkwJwZNsbKGyM=; b=mfU5KL4plxKNXFG3ULlLFBK1E59tu3GQlKm+B/QCzCxIuRiELQZd94rugpBdjp5CXh EZCUyVxQWANUnss/tRg4U48wkgxtgdK50KIYtXE/1vj94uKGgxjV9+comuR7XU9+X4UL 7c28zHQyauIdGoc9/b6jki8J7DdozoIsbVRyVnNvPmQ23YYIxB+4YnYvEG/QaLz4+Hit +W66atjhSWnh/qqfzmNR9vylavl0tWTO5cYRhqlwhXFiljxBvBQRLIV85GjtQvm+Jumo DYLi3lYNcMOd77fbxyDJKUGTTL1HRchTOv9Nw/DjOa7Z58Ez/A1J7dof88dtmtic0WyD AWvA== X-Gm-Message-State: AD7BkJLX2ST+ryoiBDME4u0Tbcgmn6RGjWIkQB5smeh6C3TqHaQYo9dQhf2DyyWGcF7gVyQxDzeID5rnrXI6J8nY MIME-Version: 1.0 X-Received: by 10.112.181.38 with SMTP id dt6mr8882115lbc.114.1459790692892; Mon, 04 Apr 2016 10:24:52 -0700 (PDT) Received: by 10.25.40.85 with HTTP; Mon, 4 Apr 2016 10:24:52 -0700 (PDT) Date: Mon, 4 Apr 2016 18:24:52 +0100 Message-ID: From: Phil Lello To: tls Content-Type: multipart/alternative; boundary=001a11361298b255da052fac01d6 Archived-At: Subject: [TLS] Asymmetric TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 17:24:58 -0000 --001a11361298b255da052fac01d6 Content-Type: text/plain; charset=UTF-8 Hi, I have a use-case for allowing an MITM to monitor traffic, but not impersonate a server, and to allow MITM signing for replay of server-responses to support caching. As far as I'm aware, TLS currently only supports a shared-secret once session initialisation is complete, so I'd need to extend the protocol to support asymmetric encryption for the session. Would there be interest in extending TLS to: - allow monitoring-with-consent (based on asymmetric encryption)? - allow re-signing from an authorised MITM to support caching? Best wishes, Phil Lello --001a11361298b255da052fac01d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have a use-case for= allowing an MITM to monitor traffic, but not impersonate a server, and to = allow MITM signing for replay of server-responses to support caching.
As far as I'm aware, TLS currently only supports a shared-secret once= session initialisation is complete, so I'd need to extend the protocol= to support asymmetric encryption for the session.

Would there= be interest in extending TLS to:
=C2=A0 - allow monitoring-with-consent= (based on asymmetric encryption)?
=C2=A0 - allow re-signing = from an authorised MITM to support caching?

Best wishes,<= br>
Phil Lello

--001a11361298b255da052fac01d6-- From nobody Mon Apr 4 10:36:59 2016 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 F2B0212D115 for ; Mon, 4 Apr 2016 10:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BK9_eLaxuRi9 for ; Mon, 4 Apr 2016 10:36:46 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 989B512D12E for ; Mon, 4 Apr 2016 10:36:46 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3EAD31022404C; Mon, 4 Apr 2016 10:36:46 -0700 (PDT) Received: from 31.133.176.131 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 4 Apr 2016 10:36:46 -0700 (PDT) Message-ID: <1c1246d3be495728863f1633691e4a53.squirrel@www.trepanning.net> In-Reply-To: References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> <56FD5CFC.8090508@gmx.net> <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> <56FD610F.10301@gmx.net> <56FD63B0.2070205@cs.tcd.ie> <1640361f86795f7c3117d9c25be91a72.squirrel@www.trepanning.net> Date: Mon, 4 Apr 2016 10:36:46 -0700 (PDT) From: "Dan Harkins" To: "Phil Lello" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 17:36:48 -0000 On Mon, April 4, 2016 8:50 am, Phil Lello wrote: > On Mon, Apr 4, 2016 at 3:36 PM, Dan Harkins wrote: > >> >> Usually what happens is the server generates a self-signed certificate >> and the apps are given some "username" and "password" and the app >> ignores the unauthenticated nature of the TLS connection and sends >> the u/p credential on through. > > Isn't this use case more of an argument for an updated auth-digest to use > something better than MD5? I'm not convinced MITM is a real concern for a > typical IoT environment (however that's defined - I'm assuming http in a > domestic environment). First of all, what makes you think it's MD5 digest and not just plaintext? And updated by whom? These are ad hoc constructions done because the alternative is too onerous. As someone who has stolen wi-fi from the apt next door that was protected by a PSK I would say that doing a dictionary attack in a "domestic environment" is entirely plausible. If I have to do a soft AP advertising the neighbor's SSID in order to lure a set-top box or thermostat or whatever to connect to me then that's a very low bar. regard, Dan. From nobody Mon Apr 4 10:46:19 2016 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 01F2B12D178 for ; Mon, 4 Apr 2016 10:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dunlop-lello-uk.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n499ZMlnR8Yh for ; Mon, 4 Apr 2016 10:46:15 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1091112D128 for ; Mon, 4 Apr 2016 10:46:15 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id c62so182075292lfc.1 for ; Mon, 04 Apr 2016 10:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dunlop-lello-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=8Lt/MCFVfL6LqnTgortg/FfY/R1r03wKpJwHU2Jhwls=; b=Ovu+49/u9YvxPFwl5BOInRVUCCObP/dqTHt5+zzM82DvJIWKfoZaOWsWbTeUit35r2 axMvtJ3BHawOsWAY0VZVw6+WavQ2PWzT6dkhBOy/zmZ8spwXC56o3KTk4y21uYvXWOQ9 xdRE3C2nszR9z+VYKtOllUzYfF86eAZtmiVd18ihSZsHxLS7nVW/8P4CajdN6tpb/oDk tMFQPyWekmcvWpivfG5SoyDmw0szV2eH17H8nAkB2K1GVDPhw8J3rjnRVoK5hEg+aqdJ zjvwp8JY/7k+bm9tfLEhtbjDd2yy/2uVTXGDuGpIW0lDCi/wKOVVh2BpgVSVcBZ/6hdx a00Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=8Lt/MCFVfL6LqnTgortg/FfY/R1r03wKpJwHU2Jhwls=; b=eCN5ihL53U5pnkM+G1lBYk+m59aW0MVPxLJdMeH+3xg142g+EojYII9qhq0nJSn14O h7Gdt/m+eHU5kfzY9NTq2xHbwT4OX/l4kUv5bTcypq3GiPD+JUjM1oYp95aH62Qw7Ejm Xskbvw+JLxP48Hd/JAPh5bvGpcCniHxl5zg7FTZQyvatRcvCKPz9lYrMUQntYEc/8yOR uC8aKtWZE6eIe55JILxqGdzLpJukDKN2GwX9rNWWyGIPUdLAEhxDuNN4oZ7nWHmZpgli fr5ZD0wUNfQ5ULMRtDvH0WJ+FrxeI7/Ip/p892eFxZ/IPhjx+h6sLyf96FalMN92vWoj xdkg== X-Gm-Message-State: AD7BkJLim+nSaoFX3f4DgvSy5anRXjXzkD2ii4Ap7PGfvqzrV3wPdNcAW4ph/uIKVYIrtpwZujxf1k/nu4z15q4B MIME-Version: 1.0 X-Received: by 10.25.161.75 with SMTP id k72mr6428055lfe.86.1459791973117; Mon, 04 Apr 2016 10:46:13 -0700 (PDT) Received: by 10.25.40.85 with HTTP; Mon, 4 Apr 2016 10:46:12 -0700 (PDT) In-Reply-To: <1c1246d3be495728863f1633691e4a53.squirrel@www.trepanning.net> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> <56FD5CFC.8090508@gmx.net> <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> <56FD610F.10301@gmx.net> <56FD63B0.2070205@cs.tcd.ie> <1640361f86795f7c3117d9c25be91a72.squirrel@www.trepanning.net> <1c1246d3be495728863f1633691e4a53.squirrel@www.trepanning.net> Date: Mon, 4 Apr 2016 18:46:12 +0100 Message-ID: From: Phil Lello To: Dan Harkins Content-Type: multipart/alternative; boundary=001a114111bc01231d052fac4e3f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 17:46:18 -0000 --001a114111bc01231d052fac4e3f Content-Type: text/plain; charset=UTF-8 > > >> Usually what happens is the server generates a self-signed certificate > >> and the apps are given some "username" and "password" and the app > >> ignores the unauthenticated nature of the TLS connection and sends > >> the u/p credential on through. > > > > Isn't this use case more of an argument for an updated auth-digest to use > > something better than MD5? I'm not convinced MITM is a real concern for a > > typical IoT environment (however that's defined - I'm assuming http in a > > domestic environment). > > First of all, what makes you think it's MD5 digest and not just > plaintext? And updated by whom? These are ad hoc constructions done > because the alternative is too onerous. > I didn't say that. I was suggesting using a standard HTTP digest mechanism rather than sending a plaintext username/password. The IETF has already updated HTTP digest, so there's no work. > > As someone who has stolen wi-fi from the apt next door that was > protected by a PSK I would say that doing a dictionary attack in > a "domestic environment" is entirely plausible. If I have to do a > soft AP advertising the neighbor's SSID in order to lure a set-top > box or thermostat or whatever to connect to me then that's a very > low bar. > Whilst you have my sympathy, I don't see how that's relevant; a dictionary attack can be used just as easily against a TLS protected resource. Securing the WiFi configuration so that devices connect to the correct one is not a TLS issue. Best wishes, Phil Lello --001a114111bc01231d052fac4e3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= >> Usually what happens is the server generat= es a self-signed certificate
>> and the apps are given some "username" and "passwor= d" and the app
>> ignores the unauthenticated nature of the TLS connection and sends=
>> the u/p credential on through.
>
> Isn't this use case more of an argument for an updated auth-digest= to use
> something better than MD5? I'm not convinced MITM is a real concer= n for a
> typical IoT environment (however that's defined - I'm assuming= http in a
> domestic environment).

=C2=A0 First of all, what makes you think it's MD5 digest and no= t just
plaintext? And updated by whom? These are ad hoc constructions done
because the alternative is too onerous.

I didn't say that. I was suggesting using a standard HTTP digest mecha= nism rather than sending a plaintext username/password. The IETF has alread= y updated HTTP digest, so there's no work.

=C2=A0 As someone who has stolen wi-fi from the apt next door that was
protected by a PSK I would say that doing a dictionary attack in
a "domestic environment" is entirely plausible. If I have to do a=
soft AP advertising the neighbor's SSID in order to lure a set-top
box or thermostat or whatever to connect to me then that's a very
low bar.

Whilst you have my sympathy, I= don't see how that's relevant; a dictionary attack can be used jus= t as easily against a TLS protected resource. Securing the WiFi configurati= on so that devices connect to the correct one is not a TLS issue.

Best wishes,

Phil Lello
--001a114111bc01231d052fac4e3f-- From nobody Mon Apr 4 10:57:57 2016 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 9A88312D5BB for ; Mon, 4 Apr 2016 10:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SYIksKIHpC0 for ; Mon, 4 Apr 2016 10:57:52 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B211212D146 for ; Mon, 4 Apr 2016 10:57:52 -0700 (PDT) Received: by mail-ig0-x236.google.com with SMTP id g8so41482449igr.0 for ; Mon, 04 Apr 2016 10:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=KkkZLXOW3nhTpau+dL2cQ+JgRDUUgKgyw3Z8mxSxzvM=; b=o/QTyPZ1MrwuBHLV9tLWercCaRgzq/m5wR9n0Q8iWqD7ur6rBQA4Q5+qn7kdqX8OYj paNi5/B3hAIo/obBUsUUZ/QNxRfT56QJ7TvfpRcUkr6hu1g+jwFMPbr/aI3UMCXApTzx GL8s6Ef6xVeCjPMTpajhODo+PXGSHF16+ZyVBTXY3rD+rlAbwN9e3+O0whs1/0EVS594 3mwqIYGUwT/XF3FadJO0Dd0dTHJHRsYWYk1gFB7xNfbXgDnpuNi9+z1yBIlFeSgujI3q M5sB8uqOm5bXmEa6RMLua15zOJ9Ch60YTIfYU8xz+1P5pAUiPLwx3RR6vQCZ/EXRDn3r KCAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=KkkZLXOW3nhTpau+dL2cQ+JgRDUUgKgyw3Z8mxSxzvM=; b=fMsUuGh/neItVfX5//q6aK3/aR1Td80kfQSH81/f4kPg+dqYE9PK2J0iNMXUYvTCgk 7wsjE+SfDfOxVdr+kUyruUOlmWGyT/TNvAtGISG+ncc558LKojPCClcX9R8g99u+Zj5S 3BDOZJ7K4u9PGxjHOVHUPvz7+adtidNiHodvI2+d0puCO6jxT8AHN+/55suofRC9m6Vm TonWtv72PtbiF924rGHOX7sHFFJcavU9X/oaTBTJzuAnLEWIwgFv7g+wypbmfSuTcSiG zkMRBMbYJ6aHMv4EBB/UQplSufNlczYnN8ZfM7/zmSvirTG5PuEmToYA1JT8h8pMIQD0 seNA== X-Gm-Message-State: AD7BkJIqo5dmV15zfYrYLfbaY+TVs7n+DTSx+bXa8Z3iQyoKFakL5WqQ6safO2SK/QVUusZskWXbUicOtQnB8w== MIME-Version: 1.0 X-Received: by 10.107.166.72 with SMTP id p69mr7412006ioe.100.1459792672011; Mon, 04 Apr 2016 10:57:52 -0700 (PDT) Received: by 10.36.43.5 with HTTP; Mon, 4 Apr 2016 10:57:51 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 Apr 2016 14:57:51 -0300 Message-ID: From: Martin Thomson To: Phil Lello Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: tls Subject: Re: [TLS] Asymmetric TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 17:57:54 -0000 On 4 April 2016 at 14:24, Phil Lello wrote: > Would there be interest in extending TLS to: > - allow monitoring-with-consent (based on asymmetric encryption)? > - allow re-signing from an authorised MITM to support caching? no From nobody Mon Apr 4 11:01:22 2016 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 787C312D5E1 for ; Mon, 4 Apr 2016 11:01: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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3vgpX3JIgxY for ; Mon, 4 Apr 2016 11:01:19 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A328C12D1BA for ; Mon, 4 Apr 2016 11:01:19 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id g3so262886712ywa.3 for ; Mon, 04 Apr 2016 11:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jrVSumf6OxBtzPW+0gudiqcuzwseuQmd/alK8Tm8dC0=; b=2QDouUAJXtoZjLMDeK7mpqlQ86P0JiXMLVQ/W4Sqnl7Or7seuf3ofFvOerjFA7WVh7 O9x405Lc0HL8XVoLk3KA4merMzNDcJuH6XexoyoNWxC6/Syl6Em1dd43b4xkMQWTqSCD D1EOFkhJBn4bqEsPcdlr4XlR42vEUaF4Z7mzAdmhlRlLiypJYv/nYm/2b8tJnQfjnjjV KTM899P0+uuUl5TItkIwPxVQ5lUjHE/gtCYdtP7hm1mlUg0sT8k8nx2ljvSQh0hxmW3r +KcCCY0YRt8xHP6qyq7OyJ9goXj/SH9Q7pRqBwkctlpmtM/4Y37vbeRac+JmQBlj4Fjv yEHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jrVSumf6OxBtzPW+0gudiqcuzwseuQmd/alK8Tm8dC0=; b=UZi1pzxeVbnMnOJ/oxdCTx/pIuHpY+7RKHPN4ZtEI6m5eQkWYM0TjLiFau6zrM0t2J e6PMPVrus1lHrDlGjEAjeKicppuKHdvd5eFSxqMQyiIc+vfA7O1fph7OTOsczmFTifgc N+tD/8MIvQ8UZTgynYNnt9wickhh3J5tqsYWU85bLXGZvvHwia1Ae1di9tPDVUoVHf29 HdIVJU8Tb77d+7xF4KJEV6Igir0wqqaWwJfR6dl2n0Ug55FFH6birrC9kCJCMb1oq/in YQSJhcDI0EcTwANA8LEan75VO8e9V71LOmPBbt2wH2RaWIEghe95beI4AcgrZrIg8/cP 3vuQ== X-Gm-Message-State: AD7BkJIR53DjHbQpyYcBsFKxShYz7buR+VyW9A2fnqybXt746O2b9ADoea8aO/93gGAicQrT5iNRwQkS0/yz2Q== X-Received: by 10.37.230.135 with SMTP id d129mr12178627ybh.74.1459792878880; Mon, 04 Apr 2016 11:01:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Mon, 4 Apr 2016 11:00:39 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 4 Apr 2016 15:00:39 -0300 Message-ID: To: Phil Lello Content-Type: multipart/alternative; boundary=94eb2c0a911afe12b2052fac834e Archived-At: Cc: tls Subject: Re: [TLS] Asymmetric TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 18:01:21 -0000 --94eb2c0a911afe12b2052fac834e Content-Type: text/plain; charset=UTF-8 Let's not do this. See https://www.ietf.org/mail-archive/web/tls/current/msg19347.html for an alternative design for this that does not require weakening TLS. -Ekr On Mon, Apr 4, 2016 at 2:24 PM, Phil Lello wrote: > Hi, > > I have a use-case for allowing an MITM to monitor traffic, but not > impersonate a server, and to allow MITM signing for replay of > server-responses to support caching. > > As far as I'm aware, TLS currently only supports a shared-secret once > session initialisation is complete, so I'd need to extend the protocol to > support asymmetric encryption for the session. > > Would there be interest in extending TLS to: > - allow monitoring-with-consent (based on asymmetric encryption)? > - allow re-signing from an authorised MITM to support caching? > > Best wishes, > > Phil Lello > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c0a911afe12b2052fac834e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let's not do this.

See= =C2=A0https://www.ietf.org/mail-archive/web/tls/current/msg19347.html = for an alternative design for this that does not require weakening TLS.

-Ekr



On Mon, Apr 4, 2016 at 2:24 PM, Phil Lello <phil@dunlop-lello.uk= > wrote:
Hi,<= br>
I have a use-case for allowing an MITM to monitor traffic, but= not impersonate a server, and to allow MITM signing for replay of server-r= esponses to support caching.

As far as I'm aware, TLS currently = only supports a shared-secret once session initialisation is complete, so I= 'd need to extend the protocol to support asymmetric encryption for the= session.

Would there be interest in extending TLS to:
=C2= =A0 - allow monitoring-with-consent (based on asymmetric encryption)?
=C2=A0 - allow re-signing from an authorised MITM to support cachi= ng?

Best wishes,

Phil Lello

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


--94eb2c0a911afe12b2052fac834e-- From nobody Mon Apr 4 11:23:37 2016 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 996EC12D159 for ; Mon, 4 Apr 2016 11:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDuCviO_Zv_M for ; Mon, 4 Apr 2016 11:23:35 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 02FCC12D0B9 for ; Mon, 4 Apr 2016 11:23:35 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 91E081022404C; Mon, 4 Apr 2016 11:23:34 -0700 (PDT) Received: from 31.133.176.131 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 4 Apr 2016 11:23:34 -0700 (PDT) Message-ID: In-Reply-To: References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> <56FD5CFC.8090508@gmx.net> <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> <56FD610F.10301@gmx.net> <56FD63B0.2070205@cs.tcd.ie> <1640361f86795f7c3117d9c25be91a72.squirrel@www.trepanning.net> <1c1246d3be495728863f1633691e4a53.squirrel@www.trepanning.net> Date: Mon, 4 Apr 2016 11:23:34 -0700 (PDT) From: "Dan Harkins" To: "Phil Lello" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 18:23:36 -0000 On Mon, April 4, 2016 10:46 am, Phil Lello wrote: >> >> >> Usually what happens is the server generates a self-signed >> certificate >> >> and the apps are given some "username" and "password" and the app >> >> ignores the unauthenticated nature of the TLS connection and sends >> >> the u/p credential on through. >> > >> > Isn't this use case more of an argument for an updated auth-digest to >> use >> > something better than MD5? I'm not convinced MITM is a real concern >> for a >> > typical IoT environment (however that's defined - I'm assuming http in >> a >> > domestic environment). >> >> First of all, what makes you think it's MD5 digest and not just >> plaintext? And updated by whom? These are ad hoc constructions done >> because the alternative is too onerous. >> > > I didn't say that. I was suggesting using a standard HTTP digest mechanism > rather than sending a plaintext username/password. The IETF has already > updated HTTP digest, so there's no work. > >> >> As someone who has stolen wi-fi from the apt next door that was >> protected by a PSK I would say that doing a dictionary attack in >> a "domestic environment" is entirely plausible. If I have to do a >> soft AP advertising the neighbor's SSID in order to lure a set-top >> box or thermostat or whatever to connect to me then that's a very >> low bar. >> > > Whilst you have my sympathy, I don't see how that's relevant; a dictionary > attack can be used just as easily against a TLS protected resource. > Securing the WiFi configuration so that devices connect to the correct one > is not a TLS issue. I'm not asking for sympathy. I'm pointing out that your proposal does not work. Mentioning the ease at which one can launch a dictionary attack (regardless of the protocol) is relevant because you're proposing to use a technique that is susceptible to dictionary attack (presumably, but not necessarily, after misusing a certificate). As I mentioned, to support this kind of use case I favor using a TLS cipher suite that supports a PAKE (draft-ietf-tls-pwd-07, for example). Using such a cipher suite would mean that a dictionary attack cannot "be used just as easily against a TLS protected resource." regards, Dan. From nobody Mon Apr 4 21:10:10 2016 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 A8F4312D153 for ; Mon, 4 Apr 2016 21:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPnq_2y5tLZK for ; Mon, 4 Apr 2016 21:10:06 -0700 (PDT) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C0EC12D09F for ; Mon, 4 Apr 2016 21:10:05 -0700 (PDT) Received: by mail-io0-x241.google.com with SMTP id g185so586994ioa.0 for ; Mon, 04 Apr 2016 21:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=3JUEhzLwK4/jHOP//Twbi4/t2GCED1nCSQWC5Eb+lYk=; b=kQMxWcweRS7tZnWSTBvB4WZ/qpK9GQ5PFKKKKQI21PondMczGtnY/XRm8sxz/lKHxs oQOXvSoSnQ9zGAqzk3fLDDEkwtHIbBeu1Qn29KzCaSqRluRTCPeA9EGXpDpnVhHbFcsG v9xXLXQVyqiRD2LCMcQi1NQZBc65fciG8aeq5l+ZBAYXzI6k8K5RvkyUxdB4FFd+pzZb NwkSwTUfeeV4Pqc4QT6ls11HxrRhOtv+8TyqGQbZIKNBVYoCqqqezGHZnzAz3C+OKCHO edD+fTy4QzItRG7mJFlDwy2eGHh+Z5EW9XPboirVs+7dQDsHFXox6Fm1+NpmLe0nG1Jj bvsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=3JUEhzLwK4/jHOP//Twbi4/t2GCED1nCSQWC5Eb+lYk=; b=dYx7BhDFHsM8TrnBlb08+jKu1Vfvr7ili0jKXCcMYq6q+BCuXYqFMKXBt/4lTq1p3b SrsczVxcl8Scmjcp/Fg1r/ST7yZS34Hx0iLBzp2Gmf1RSVMq0H4y0fnYxYKvJzr5J+TY OHpT6+zk8GzMdjoV61jc08vHtDTPc8+KuzkOpWqrqoqyf28Sztjr+5HevlJ/S4toishS hSCQ72OZpJ8H97FvUagBO6RmIb0ijflhBOTdlgEE7ts1RoSXdI4xYxVCZcCO/y/p5B1X lNnCc+5VrGLW1QwPhwabBjZziKzRNRUUf5A/KC/m8sfBawsdGjf7L8Hzv7ERiWszpR3Z CSQg== X-Gm-Message-State: AD7BkJJZyQBHsEe46K5K2348xUuSazrXgJAzntz/GiHVNSxuLz6lq7fqnNyhDK7TIcaTEojL56mijcZ4Vy/p5Q== MIME-Version: 1.0 X-Received: by 10.107.150.208 with SMTP id y199mr6881736iod.23.1459829404924; Mon, 04 Apr 2016 21:10:04 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.79.117.207 with HTTP; Mon, 4 Apr 2016 21:10:04 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C3852F@uxcn10-tdc05.UoA.auckland.ac.nz> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> <56FD5CFC.8090508@gmx.net> <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> <56FD610F.10301@gmx.net> <56FD63B0.2070205@cs.tcd.ie> <1640361f86795f7c3117d9c25be91a72.squirrel@www.trepanning.net> <9A043F3CF02CD34C8E74AC1594475C73F4C3852F@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Tue, 5 Apr 2016 11:10:04 +0700 X-Google-Sender-Auth: TH0AP12mV2N-2lDUjhc6yIbUa1s Message-ID: From: Adam Langley To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 04:10:08 -0000 On Mon, Apr 4, 2016 at 9:39 PM, Peter Gutmann wrote: > Because they have neither a DNS name nor a fixed IP address. I ran into this > just last week with a customer, they couldn't use certs for their embedded > devices and couldn't use PSK because the browser vendors have chosen not to > support it. As a result, they abandoned the use of TLS altogether and went > with SSH. Ideas for supporting this case (i.e. the "I want to do HTTPS to my router" problem) in browsers have done the rounds a few times. The reason that nothing has happened is that it's a lot of work to do it right and it's unclear that we would be able to get a useful mass of devices supporting such a scheme. The mostly likely outcome seems to be that we would end up with a complex addition that's rarely used and thus doesn't justify the cost. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Tue Apr 5 02:55:46 2016 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 EA7D112D18A for ; Tue, 5 Apr 2016 02:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 192lf67kBjQd for ; Tue, 5 Apr 2016 02:55:41 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B516012D140 for ; Tue, 5 Apr 2016 02:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1459850140; x=1491386140; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hy44knR+s022ECpYvSfcuw+/i8a9di7Hg4xY4OFa54M=; b=HBj+QzbxgeRnw7dVzmNnPg8l/YxJ1cDFM/6nDzRDP7ffBM86qpS3jKT3 jJcdXU68dPxDqMp48pAOrCI4J2qjwH1dzZQDY24BjrMMgpc3MhxlYLx8j G5nits5TUuOmMqTxPTgR+BK9+Ah3thRRG3awgHqu2yI8O+anU5EKZ5YIK ljgASpRYIU3EYIopL+i2iamUv66oqZkj6pznQDSul9vCkLxt+SNOZimt7 0Frp9YzGaYYY6t/zLEslbzKpJ3eq+sfYen6FtzbSQMJbyWzLsFDyH/1Sh evE6CNWJ80EYvRNLCOKWAXfm4duwpgf3rEtAjgGdFVXoo/QXDm6v0HmJ6 A==; X-IronPort-AV: E=Sophos;i="5.24,443,1454929200"; d="scan'208";a="78302530" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 05 Apr 2016 21:55:08 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.241]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Tue, 5 Apr 2016 21:55:08 +1200 From: Peter Gutmann To: Adam Langley Thread-Topic: [TLS] call for consensus: changes to IANA registry rules for cipher suites Thread-Index: AQHRi1OuU0aLD2CoU020MlW0nXLdGp9y3RMAgAAEsgCAAAkrgIAABHGAgAABqACAAADdAIAAAYAAgAAAugCAAAQigIAAAyIAgAYa54CAAANdgIAAzzMNgAAZYgCAASl0yQ== Date: Tue, 5 Apr 2016 09:55:08 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C38F7B@uxcn10-tdc05.UoA.auckland.ac.nz> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> <56FD5CFC.8090508@gmx.net> <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> <56FD610F.10301@gmx.net> <56FD63B0.2070205@cs.tcd.ie> <1640361f86795f7c3117d9c25be91a72.squirrel@www.trepanning.net> <9A043F3CF02CD34C8E74AC1594475C73F4C3852F@uxcn10-tdc05.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 09:55:45 -0000 Adam Langley writes:=0A= =0A= >Ideas for supporting this case (i.e. the "I want to do HTTPS to my router"= =0A= >problem) in browsers have done the rounds a few times.=0A= =0A= This isn't for HTTPS to a router, it's to SCADA devices. The preferred=0A= interface to them is HTTPS, but since browsers have refused to implement=0A= anything other than cert-based TLS, there's nothing that can be done.=0A= =0A= >The reason that nothing has happened is that it's a lot of work to do it= =0A= >right=0A= =0A= How hard can it be to implement TLS-PSK? I did it in a few hours in my cry= pto=0A= library.=0A= =0A= Peter.= From nobody Tue Apr 5 07:42:33 2016 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 9CBB112D586 for ; Tue, 5 Apr 2016 07:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thabi2O80Dr4 for ; Tue, 5 Apr 2016 07:42:24 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6713D12D145 for ; Tue, 5 Apr 2016 07:42:22 -0700 (PDT) Received: by mail-ig0-x22b.google.com with SMTP id g8so15845163igr.0 for ; Tue, 05 Apr 2016 07:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=0JNw6iYc83o5ZlcPL9f3QH2D2LQ0t2q8jqnrVYtKYH8=; b=ZOxNPmbYPRdzxztAAXtwWjgxByx9veg3hfhikPS6pUPnSa2QcgOWhI6pXbfnXERjDV PTxNnJHOuCVV1P8vrMzWm5hTE+hLl90FPMlPwp+gbWMvI+QEZ5Gu2uqu6QF0RxSP+O2M FUSnCniHuaiufWo8PS26zZOfXOg+HmtkWpCR6HRZkIrPWTWALb4dYXQV7H6YGZ2uDvbe k4yJeCHjgmms5vVaj71g1rpYG9WYXzAbQiXgdmQ6kLXGjUSlxgBJBtM/ChJxcbA45+1r DETcQMAMOgEjFutkHe+FDMrgpLYGILVCDW2Yow7DKmuooTMkWdj1htTQ2s7uPP+/fC2L fjfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=0JNw6iYc83o5ZlcPL9f3QH2D2LQ0t2q8jqnrVYtKYH8=; b=jQNdugg2ipKHM2euXnQ4JzCIYdUTw5IOPK+gHXRQNFf3BbzrAJnwDbO1YdjDGk5/9q CPVLDTMSdgNKh0W8gEVKYkQ0QXqxTZxr4fI9W7/ETEkbuyoerGM1D97923Ze1Pyqou93 a2N5nkkWbizof3rCwwCe/4/pkTKlxoAk/ax6MQtmT6+j9Da894NUUZlLAZoM27RVH4Jy cAyklgxWnoqwNVJUmxqdDWG46J6/ek1PHmNHfZ7dyS8q/nQLG3ylPpjFbONFj+gf4MVZ RcF1WcGTk8lYDdn7iuMHMGmogl2/YBM/SzdrTWDRdFTQYycYjjBXOv/NYru/NX58ZJ5B k5qA== X-Gm-Message-State: AD7BkJLiz16d72BMJ2eKQ0yBkhNiUH0CwprTOZ64SZLIEB197KCqPXZ+yHxM8t218eiPIXvJSodX+y0VyRKViA== MIME-Version: 1.0 X-Received: by 10.50.129.103 with SMTP id nv7mr17446131igb.24.1459867341354; Tue, 05 Apr 2016 07:42:21 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.79.117.207 with HTTP; Tue, 5 Apr 2016 07:42:21 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C38F7B@uxcn10-tdc05.UoA.auckland.ac.nz> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> <56FD5CFC.8090508@gmx.net> <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> <56FD610F.10301@gmx.net> <56FD63B0.2070205@cs.tcd.ie> <1640361f86795f7c3117d9c25be91a72.squirrel@www.trepanning.net> <9A043F3CF02CD34C8E74AC1594475C73F4C3852F@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C38F7B@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Tue, 5 Apr 2016 21:42:21 +0700 X-Google-Sender-Auth: AxxGpIjRN30y28MX2q8FQ6gnaOA Message-ID: From: Adam Langley To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 14:42:26 -0000 On Tue, Apr 5, 2016 at 4:55 PM, Peter Gutmann wrote: > How hard can it be to implement TLS-PSK? I did it in a few hours in my crypto > library. This is getting off topic (which is my fault) but, for us, it wouldn't be "just" implementing PSK. We would need to evangelise it sufficiently with enough vendors to make sure that it would be used and that we were building the right thing. (The solution might well not be just using PSK). Then we need to implement it and get the UI right, try and get other browsers to implement it, write specs, write test suites, write sample code for all the vendors, deal with the resulting bugs in implementations and many smaller things besides. That's not to say that we wouldn't be willing to put the effort in, but the demand hasn't been evinced yet. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Tue Apr 5 08:47:41 2016 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 D7D5A12D615 for ; Tue, 5 Apr 2016 08:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enT_BaDI03tC for ; Tue, 5 Apr 2016 08:47:38 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id B322712D1A3 for ; Tue, 5 Apr 2016 08:47:37 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0461B43346B; Tue, 5 Apr 2016 15:47:37 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id E2A39433406; Tue, 5 Apr 2016 15:47:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459871256; bh=NQukbiJEmOW7R4k3wTGmkeIm8wRpDj9m62y9mVMqLwI=; l=276; h=From:To:CC:Date:References:In-Reply-To:From; b=ebe9vTtA5gLZ0SZsSsVmT0fupTKtgyWKZ0zihVXC1SleLuGXelT34Ac77ZX6Mjt82 w93Wf8+lPTFPNFU61uSZJYe1E/N9wbX/TR5Jk0c86nbhXtk3kalYylEc0ThHnFUyv5 ST011DiNAmnAh5+9jul9qkhSIiEPZS1Klwv1f57A= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id E01E01FC88; Tue, 5 Apr 2016 15:47:36 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 5 Apr 2016 11:47:36 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Tue, 5 Apr 2016 11:47:36 -0400 From: "Salz, Rich" To: Phil Lello Thread-Topic: [TLS] Asymmetric TLS Thread-Index: AQHRjpbxJW8qmc3hUkaSvB+nkOwY/p96XOKAgAEqjyA= Date: Tue, 5 Apr 2016 15:47:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.48.40] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: tls Subject: Re: [TLS] Asymmetric TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 15:47:41 -0000 On 4 April 2016 at 14:24, Phil Lello wrote: > Would there be interest in extending TLS to: > - allow monitoring-with-consent (based on asymmetric encryption)? > - allow re-signing from an authorised MITM to support caching? This is very bad; no. From nobody Tue Apr 5 09:36:09 2016 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 838B912D76A for ; Tue, 5 Apr 2016 09:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLRYsTZhfHka for ; Tue, 5 Apr 2016 09:36:05 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 079C712D762 for ; Tue, 5 Apr 2016 09:36:03 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 265C0A888014; Tue, 5 Apr 2016 09:36:02 -0700 (PDT) Received: from 31.133.176.131 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 5 Apr 2016 09:36:02 -0700 (PDT) Message-ID: <89f6e678df72e2aa000d71c8017782dc.squirrel@www.trepanning.net> In-Reply-To: References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> <56FD5CFC.8090508@gmx.net> <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> <56FD610F.10301@gmx.net> <56FD63B0.2070205@cs.tcd.ie> <1640361f86795f7c3117d9c25be91a72.squirrel@www.trepanning.net> <9A043F3CF02CD34C8E74AC1594475C73F4C3852F@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C38F7B@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Tue, 5 Apr 2016 09:36:02 -0700 (PDT) From: "Dan Harkins" To: "Adam Langley" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 16:36:07 -0000 On Tue, April 5, 2016 7:42 am, Adam Langley wrote: > On Tue, Apr 5, 2016 at 4:55 PM, Peter Gutmann > wrote: >> How hard can it be to implement TLS-PSK? I did it in a few hours in my >> crypto >> library. > > This is getting off topic (which is my fault) but, for us, it wouldn't > be "just" implementing PSK. > > We would need to evangelise it sufficiently with enough vendors to > make sure that it would be used and that we were building the right > thing. (The solution might well not be just using PSK). Then we need > to implement it and get the UI right, try and get other browsers to > implement it, write specs, write test suites, write sample code for > all the vendors, deal with the resulting bugs in implementations and > many smaller things besides. > > That's not to say that we wouldn't be willing to put the effort in, > but the demand hasn't been evinced yet. Don't bother. It's unlikely to be used in a browser. This just underscores the point I was making that people use TLS differently for different things and the requirements are not the same. Just as it doesn't make sense to force a browser to implement a PSK (or PAKE) cipher suite, it doesn't make sense to force some device with a limited UI that has no interest in accessing random web servers to use a public key. regards, Dan. From nobody Tue Apr 5 10:29:18 2016 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 1183B12D1D2 for ; Tue, 5 Apr 2016 10:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4GbfwhKbRwg for ; Tue, 5 Apr 2016 10:29:15 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C784412D58B for ; Tue, 5 Apr 2016 10:29:14 -0700 (PDT) Received: by mail-qg0-x230.google.com with SMTP id y89so15985602qge.2 for ; Tue, 05 Apr 2016 10:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZB67L/sVRKUYyTs92bVtHXtnghZjdbj5YgLvcK3/SSU=; b=DaKtXuFXO5k9RoCxh4T3wX6IOWgwtAdF45Rxsq5xY5yhh/VTjbTsOfDgVpEJtd/BoH hk78yh0ppDHMSxzJ3b/yqbrVeNoP9vMNEK4gGu5sZ8eUsdq4cUshWn21O4pXLvj1do51 V6NpjlTGahwjXhsoP0/8pNqq9Ckf5Lv2/gd68= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZB67L/sVRKUYyTs92bVtHXtnghZjdbj5YgLvcK3/SSU=; b=KKJ/E8IrJTEcl2jFXo+J5AUrZf3m+1vA/DKtiOKjNO9A3Z83WcOITaNMqkWV1lOjGg 0ARVpxXUTbj7LcK4qimkEzPh66eX8xEpN6sakIJszlE+86J7wEr95YlDfnj24xtSgxmQ aBD2HTeJWo6W+FfoWsOcZTWdT45nbH9FwK6QBgMp2fRpRuhLdRI2mCRmJsKM2uWsGbz9 tPEKjCPsLswwIDYu5JgtWzB1MNyk1sgn0W+B/TznZ0uSraxnhrhcVyTvmBVce4qTr5Cj mMNaR/HGOTociabMvKpwtQlaWOEZKfaudAHqGL2YKDTqKiHfjpL+2cRkSKitnZxQzw55 Ifwg== X-Gm-Message-State: AD7BkJLengq6A1GzlQg+H6rnLSxG6Xo/WKvFfkprFx0gnhaAoNGYlddyX9MX3tasB5XTPA== X-Received: by 10.140.32.116 with SMTP id g107mr30877345qgg.5.1459877353970; Tue, 05 Apr 2016 10:29:13 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:31e5:2b84:6e17:da4? ([2001:67c:370:176:31e5:2b84:6e17:da4]) by smtp.gmail.com with ESMTPSA id q10sm14816569qha.25.2016.04.05.10.29.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Apr 2016 10:29:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Tue, 5 Apr 2016 14:29:11 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Phil Lello X-Mailer: Apple Mail (2.3124) Archived-At: Cc: tls Subject: Re: [TLS] Asymmetric TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 17:29:17 -0000 With my chair hat on, I won=E2=80=99t comment one way or the other on = whether this should be done, but we have gone down this path before. As = I recall, the proposal was pretty resoundingly rejected. But, what I will say as chair is that this would most definitely require = a charter change for the WG. spt > On Apr 04, 2016, at 14:24, Phil Lello wrote: >=20 > Hi, >=20 > I have a use-case for allowing an MITM to monitor traffic, but not = impersonate a server, and to allow MITM signing for replay of = server-responses to support caching. >=20 > As far as I'm aware, TLS currently only supports a shared-secret once = session initialisation is complete, so I'd need to extend the protocol = to support asymmetric encryption for the session. >=20 > Would there be interest in extending TLS to: > - allow monitoring-with-consent (based on asymmetric encryption)? > - allow re-signing from an authorised MITM to support caching? >=20 > Best wishes, >=20 > Phil Lello >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Apr 5 14:20:30 2016 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 B57E612D7E7 for ; Tue, 5 Apr 2016 14:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FR3gLU-3giVw for ; Tue, 5 Apr 2016 14:20:26 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8498D12D742 for ; Tue, 5 Apr 2016 14:20:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id ABD97BE5C; Tue, 5 Apr 2016 22:20:24 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OniPKDDNAt-P; Tue, 5 Apr 2016 22:20:23 +0100 (IST) Received: from [31.133.178.21] (dhcp-b215.meeting.ietf.org [31.133.178.21]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 20C67BE55; Tue, 5 Apr 2016 22:20:21 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1459891223; bh=WKKogm023DGcdMP+hJ8KHI4pE8hnzPhJ7X0LNQpxFpA=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=vfDdwgwmzV8qK2FnFWrGlYlCCOEYhTY3hH89TJB8sZCORetVJiuOQhtBrv9SH+LZI 014YFbw7W5cCHu6sr01ZXB1tjoO21icVHZK8F7nC0+ynXpjaDBObA96aAVdNEcMVDT qxuQc4tJuqlsLn5K404D3tnU0Q0cg9t9JT7ZyrUs= To: Sean Turner , Phil Lello References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <57042C14.6000106@cs.tcd.ie> Date: Tue, 5 Apr 2016 22:20:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010802070209040808040603" Archived-At: Cc: tls Subject: Re: [TLS] Asymmetric TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 21:20:28 -0000 This is a cryptographically signed message in MIME format. --------------ms010802070209040808040603 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05/04/16 18:29, Sean Turner wrote: > But, what I will say as chair is that this would most definitely > require a charter change for the WG. FYI: you'd also have to climb over an AD-dead-body to get that. S. --------------ms010802070209040808040603 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA0MDUy MTIwMjBaMC8GCSqGSIb3DQEJBDEiBCAn8p4fqpWkZz56bBXYHx7F5tUZmpQywezVzI1EfVNP PzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQB8wQsHyJ8TQBIgyGwvZCviulBDv1sfIA6AN5nJpPzM8feG4t8NM4MK TImiJ0W+NreQD0ggfNxbHAGBFzXz3OiEfKgx25s1CU7qMYvDD08fI+qyprARJ4n2jAlv7m5Z CvLmP8mTHPJB3WrAara1zxIs5Au22EDcw878UVqO+Ya/Crnb8eT824ELNgH1nbvsw6ABiLCB LPEjsmEz5E5WW4NE4v+TEnCj2FjJnAwY1fyuwlHY0shlhEIypSUNHBKglilHFuKKpjhhkhs4 ZkOycFqqyHh6bMSlJJZd69k3hQe3ODHGbS+9fceN22O8cjxOHMnuLPnV2zZbg5TPxT1Y04Zj AAAAAAAA --------------ms010802070209040808040603-- From nobody Tue Apr 5 15:33:30 2016 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 21F3412D11E for ; Tue, 5 Apr 2016 15:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMQspHsEg3-r for ; Tue, 5 Apr 2016 15:33:27 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF3212D09D for ; Tue, 5 Apr 2016 15:33:27 -0700 (PDT) Received: from [173.75.83.83] (helo=Williams-MacBook-Pro.local) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1anZX5-0004qE-Dq; Tue, 05 Apr 2016 18:33:11 -0400 Date: Tue, 5 Apr 2016 15:33:06 -0700 From: Bill Frantz To: tls@ietf.org, Phil Lello X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec796e89b59512f59869ffd7121e63ead0fe350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.83 Archived-At: Subject: Re: [TLS] Asymmetric TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 22:33:29 -0000 To avoid a lot of "Over my dead body" comments, these=20 requirements should be met with a very visible man in the middle=20 and two (or more) TLS sessions. This architecture should provide=20 some security from unwanted men in the middle, as well as making=20 it obvious to the endpoints who that man in the middle is. Cheers - Bill On 4/5/16 at 10:29 AM, sean@sn3rd.com (Sean Turner) wrote: >With my chair hat on, I won=E2=80=99t comment one way or the other on=20 >whether this should be done, but we have gone down this path=20 >before. As I recall, the proposal was pretty resoundingly rejected. > >But, what I will say as chair is that this would most definitely require a= charter change for the WG. > >spt > >>On Apr 04, 2016, at 14:24, Phil Lello wrote: >> >>Hi, >> >>I have a use-case for allowing an MITM to monitor traffic, but not impers= onate a server, and to allow MITM signing for replay of >server-responses to support caching. >> >>As far as I'm aware, TLS currently only supports a shared-secret once ses= sion initialisation is complete, so I'd need to extend the >protocol to support asymmetric encryption for the session. >> >>Would there be interest in extending TLS to: >>- allow monitoring-with-consent (based on asymmetric encryption)? >>- allow re-signing from an authorised MITM to support caching? >> >>Best wishes, >> >>Phil Lello --------------------------------------------------------------------------- Bill Frantz |"Web security is like medicine - trying to=20 do good for 408-356-8506 |an evolved body of kludges" - Mark Miller www.pwpconsult.com | From nobody Tue Apr 5 21:49:44 2016 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 87FCF12D76F for ; Tue, 5 Apr 2016 21:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geph6jxU_e7V for ; Tue, 5 Apr 2016 21:49:40 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 6E26E12D541 for ; Tue, 5 Apr 2016 21:49:40 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9BB6020003B; Wed, 6 Apr 2016 04:49:39 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 85CB5200013; Wed, 6 Apr 2016 04:49:39 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459918179; bh=ybViZZej/Dq0lxV2m4qfCPvf5umDLpXQKPmhTezLwnU=; l=1136; h=From:To:CC:Date:References:In-Reply-To:From; b=nVp2woqY+BrWPO9WBz2A2ZZZtiUBE2ijTqjgHbH2iR9nhEbHH1CqGkmrwW7xzh8Ux 88Z9bgXJwWu7xxhIHOqB5eV7gnEkfCXUUoIQ+VU2mLEe7Joht3plDm/MIsPG0Rzoap GX2yCwEoUQTLREmw7MBcMDaDOVTVlXYZdmLwOIoY= Received: from email.msg.corp.akamai.com (um-cas.msg.corp.akamai.com [172.27.25.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 80A611E07C; Wed, 6 Apr 2016 04:49:39 +0000 (GMT) Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 5 Apr 2016 23:49:39 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1130.005; Tue, 5 Apr 2016 23:49:38 -0500 From: "Sniffen, Brian" To: Phil Lello Thread-Topic: [TLS] Asymmetric TLS Thread-Index: AQHRjpby7AMEJu3Lq0WyVYOAQ2PB/p98thYA Date: Wed, 6 Apr 2016 04:49:37 +0000 Message-ID: <4CFC4752-FCA5-4464-A8E8-AA423A69CE4E@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.142] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: tls Subject: Re: [TLS] Asymmetric TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 04:49:42 -0000 I suspect the right place to do this is not at the TLS layer. As Bill said= : do it with two TLS sessions, and then provide authenticated, cacheable ob= jects. The sub-resource-integrity system trie= d to achieve that, and seems to get pretty close. -Brian > On Apr 4, 2016, at 1:24 PM, Phil Lello wrote: >=20 > Hi, >=20 > I have a use-case for allowing an MITM to monitor traffic, but not impers= onate a server, and to allow MITM signing for replay of server-responses to= support caching. >=20 > As far as I'm aware, TLS currently only supports a shared-secret once ses= sion initialisation is complete, so I'd need to extend the protocol to supp= ort asymmetric encryption for the session. >=20 > Would there be interest in extending TLS to: > - allow monitoring-with-consent (based on asymmetric encryption)? > - allow re-signing from an authorised MITM to support caching? >=20 > Best wishes, >=20 > Phil Lello >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Apr 5 23:32:52 2016 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 3553D12D7FA for ; Tue, 5 Apr 2016 23:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0qejtEoYCCe for ; Tue, 5 Apr 2016 23:32:50 -0700 (PDT) Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037FA12D7BF for ; Tue, 5 Apr 2016 23:32:48 -0700 (PDT) Received: from airhead.fritz.box ([83.161.146.46]) by smtp-cloud3.xs4all.net with ESMTP id euYj1s01210HQrX01uYk1F; Wed, 06 Apr 2016 08:32:46 +0200 Message-ID: <5704AD8A.9070400@openfortress.nl> Date: Wed, 06 Apr 2016 08:32:42 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Phil Lello References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: tls Subject: Re: [TLS] Asymmetric TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 06:32:52 -0000 Hello Phil, > I have a use-case for allowing an MITM to monitor traffic, but not > impersonate a server, and to allow MITM signing for replay of > server-responses to support caching. > This sounds like attack monitoring (going beyond DoS for which SNI frequencies might already be helpful). This used to be possible by passing certificate private keys, until we all embraced (EC)DHE. This is still an option for you of course, since you're violating the idea of (EC)DHE anyway, at least between the monitor and its related TLS peer. > As far as I'm aware, TLS currently only supports a shared-secret once > session initialisation is complete, so I'd need to extend the protocol to > support asymmetric encryption for the session. > I wonder if you'd need to extend the *protocol* or rather its *implementation* to share private/secret key material. You could probably create a side-channel over which you communicate this efficienctly, based on the random pieces in Hello, for instance. Any such implementation would sound the alarm bells for this option (and probably not make it a default option) that the TLS protocol can't ring because it is just a protocol. My suggestion would be to let the monitor supply the private/secret key material its related TLS peer, so it has more control; also, for TLS implementations the import of key material is perhaps less scary than the export (or more possible, if PKCS #11 is used). Your monitor might decide to let go of monitoring traffic, to monitor other traffic and perhaps to share key material between certain sessions when under attack. Be careful with all of this though! > Would there be interest in extending TLS to: > - allow monitoring-with-consent (based on asymmetric encryption)? > - allow re-signing from an authorised MITM to support caching? > Clearly, the WG does not like this idea. Same with me. But if you tried something implementation-specific, or perhaps even standardise an explicit side-channel protocol, you may be more likely to get the work done because that would constitute an explicit and independent choice on the part of the administrators. TLS is so full of options that the eyes of admins already glaze over -- what you are proposing is explicit weakening of TLS, and it could slip into a configuration too easily as part of the confusion that the complexity of the protocol already causes. It could be interesting to let the WG know what your course of action will be, so we can positively reference any such requests in the future. Cheers, -Rick From nobody Wed Apr 6 03:46:30 2016 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 422B412D17F for ; Wed, 6 Apr 2016 03:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fSTGB5K5G58 for ; Wed, 6 Apr 2016 03:46:24 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A91F712D0B9 for ; Wed, 6 Apr 2016 03:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1459939584; x=1491475584; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=AJ7nypa7pa0QMxA88ASfqVgcI+0via49+E0/o6hR+g0=; b=QbgK9LHJP1RkLA30X3f5ybq9ZD9Uo0cd5VI1jQyQnt/hmHJwGogTic4L rcZMs0TK3lmDgIWRDW6kyv0MzPmShnAolrp/geSzgNWbz3Il9eNV8ZTHk fIttPUVaKYNQ0JG0Ylp3e+6o8gKCgVBNZJnBnN4kqOtyc2BoftYE+3ma9 46Yc6FDnlhAC44n+7qT6Ii9EADB3nfAR10iDoyvVg4Zf+nwpuhV9L5+Pb kYhgQpnfnBrYmu0g59FJZUcRleK7zvyNV1H3VcCxDgBoj8uvNw3ZFV9Fi g/n286ASN5sUCtDltz7aTkZlaK0m3TylmtSqZoElEqZ/LrDqwqAaNt+W8 w==; X-IronPort-AV: E=Sophos;i="5.24,447,1454929200"; d="scan'208";a="78582121" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 06 Apr 2016 22:46:22 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.241]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Wed, 6 Apr 2016 22:46:22 +1200 From: Peter Gutmann To: "" Thread-Topic: New Version Notification for draft-gutmann-tls-lts-03.txt Thread-Index: AQHRj/EsMv3c8ZVhPkm9seXwLvFv9p98wwdS Date: Wed, 6 Apr 2016 10:46:21 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C3A635@uxcn10-tdc05.UoA.auckland.ac.nz> References: <20160406104334.24895.88709.idtracker@ietfa.amsl.com> In-Reply-To: <20160406104334.24895.88709.idtracker@ietfa.amsl.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [TLS] FW: New Version Notification for draft-gutmann-tls-lts-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 10:46:29 -0000 A new version of I-D, draft-gutmann-tls-lts-03.txt=0A= has been successfully submitted by Peter Gutmann and posted to the=0A= IETF repository.=0A= =0A= Name: draft-gutmann-tls-lts=0A= Revision: 03=0A= Title: TLS 1.2 Long-term Support Profile=0A= Document date: 2016-04-06=0A= Group: Individual Submission=0A= Pages: 12=0A= URL: https://www.ietf.org/internet-drafts/draft-gutmann-tls-lts-= 03.txt=0A= Status: https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/=0A= Htmlized: https://tools.ietf.org/html/draft-gutmann-tls-lts-03=0A= Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-gutmann-tls-lts-0= 3=0A= =0A= Abstract:=0A= This document specifies a profile of TLS 1.2 for long-term support,=0A= one that incoporates as far as possible what's already deployed for=0A= TLS 1.2 but with the security holes and bugs fixed. This represents=0A= a stable, known-good profile that can be deployed to systems that=0A= can't roll out a new set of patches every month or two when the next=0A= attack on TLS is published.=0A= =0A= Please note that it may take a couple of minutes from the time of submissio= n=0A= until the htmlized version and diff are available at tools.ietf.org.=0A= =0A= The IETF Secretariat= From nobody Wed Apr 6 07:47:02 2016 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 6B3D212D16D for ; Wed, 6 Apr 2016 07:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iI38jyBArtXQ for ; Wed, 6 Apr 2016 07:46:59 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F1912D0E4 for ; Wed, 6 Apr 2016 07:46:58 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id v188so25773833wme.1 for ; Wed, 06 Apr 2016 07:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=from:subject:date:references:to:message-id:mime-version; bh=wY9K/Ptsmh5GDsOzv6igfHUyjeZdajaozXn63C0kXgk=; b=PX2ottowykV0EMYdrdsmW+qbyGZCFSMxysDTgbtZJvo9fViHOatL4Yc4h1vJbP/28/ bKRp554H2lZkcHzgQ1bDPH5/mn+/oWiaRQHEvBxybSssgd/nOgBPYfblV+1tnzM4Oesa 3PC04/lII/V2Sv5roWIL9Qw6navmsvoI/UQ1c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:references:to:message-id :mime-version; bh=wY9K/Ptsmh5GDsOzv6igfHUyjeZdajaozXn63C0kXgk=; b=FA8D+ZkdcD0mMPeFWjSDcd2HzRdnx05/Dd+J+UIhbrF5/5A467YCwXER4nOJTNNaRG bk6HUVuXUygF8zW1XIGXIUFQJCNWQlHrTotp1uTBS3WLPK2HxL2gdTb80BCdSYCiw8QY +nTCO0yo/4+IbRCmAbiftx0+cRDwxoth39UWP28kfYqE2TtADTFFy1BaOyqL4rxjPV+l i6AsSLW6uGZxhlnD/6mb/yki4zK3y4KddZjdrNqpGNvFwPJkhwf79yG+PIFcYRowT9dg iBE97HWYVa5pPE4uHkzcwsAXX9yhPAA7Y+SNfOqZmAYxAjaSokL4XrtDDw6Vnm6SqIQS Jk5w== X-Gm-Message-State: AD7BkJKtuvDK0ilWeEFR8tYkfx3NdB6q88lkGNk68S6F6LbO1c41kzcXrJ6oMmgRIM1pUA== X-Received: by 10.28.173.71 with SMTP id w68mr24979175wme.88.1459954017407; Wed, 06 Apr 2016 07:46:57 -0700 (PDT) Received: from [192.168.23.127] (chello212017113090.11.11.vie.surfer.at. [212.17.113.90]) by smtp.gmail.com with ESMTPSA id 192sm4131812wmw.0.2016.04.06.07.46.55 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Apr 2016 07:46:55 -0700 (PDT) From: Aaron Zauner X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_749E95AC-7DCA-4FD9-A6AB-F69611AE2A05"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 6 Apr 2016 16:47:20 +0200 References: <20160404164526.15645.26001.idtracker@ietfa.amsl.com> To: tls@ietf.org Message-Id: <5194DF8B-DFF1-4E41-A93C-6A80D063E7B5@azet.org> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [TLS] Fwd: New Version Notification for draft-zauner-tls-aes-ocb-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 14:47:01 -0000 --Apple-Mail=_749E95AC-7DCA-4FD9-A6AB-F69611AE2A05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I've uploaded a new version of the OCB draft a few days ago. Major = changes: - the nonce construction is now identical to the one from the = chacha/poly draft to reduce risk of nonce misuse/reuse - added a security considerations section on data limit under a single = key (identical to GCM) - IPR claims for TLS are now fully resolved as far as I can tell - the = draft contains updated information on the issue I'm happy to receive any feedback/critique on the draft if anyone is = interested in reviewing. BTW: Andy Polyakov has added AESNI optimized assembly for OCB to OpenSSL = (https://github.com/openssl/openssl/commit/bd30091c9725bdad1c82bce10839f33= ceaa5623b). C/B numbers are quite impressive, IMO. Thanks for your consideration, Aaron > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-zauner-tls-aes-ocb-04.txt > Date: 4 April 2016 at 18:45:26 GMT+2 > To: "Aaron Zauner" > Message-Id: <20160404164526.15645.26001.idtracker@ietfa.amsl.com> >=20 >=20 > A new version of I-D, draft-zauner-tls-aes-ocb-04.txt > has been successfully submitted by Aaron Zauner and posted to the > IETF repository. >=20 > Name: draft-zauner-tls-aes-ocb > Revision: 04 > Title: AES-OCB (Offset Codebook Mode) Ciphersuites for = Transport Layer Security (TLS) > Document date: 2016-04-04 > Group: Individual Submission > Pages: 8 > URL: = https://www.ietf.org/internet-drafts/draft-zauner-tls-aes-ocb-04.txt > Status: = https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/ > Htmlized: = https://tools.ietf.org/html/draft-zauner-tls-aes-ocb-04 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-zauner-tls-aes-ocb-04 >=20 > Abstract: > This memo describes the use of the Advanced Encryption Standard = (AES) > in the Offset Codebook Mode (OCB) of operation within Transport = Layer > Security (TLS) and Datagram TLS (DTLS) to provide confidentiality = and > data origin authentication. The AES-OCB algorithm is highly > parallelizable, provable secure and can be efficiently implemented = in > software and hardware providing high performance. Furthermore, use > of AES-OCB in TLS is exempt from former IPR claims by various > parties. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_749E95AC-7DCA-4FD9-A6AB-F69611AE2A05 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXBSF5AAoJEOTbZJL9ubXVnZkP/jqjP79W21gipBQI5Cj//Ms3 38mWzHsbJo5k2uHQ9EOZgFt8HdgMkmKAHYBnpf7lqYSOLq660CeDVEKVfGc6HL9i 2fl21KdV4EPVt3thcb9Wv0SjSFfyLreKsvje/1vXEjiZOxYQdviF4LDjOkvTHn0y eA/JTAieWYF1jKufDvlPZ1tenkgBTwQEk2UUNZ7pHbelwj8cONzIfq2tsn617hWi pvfLOarJLt/4x4DOpV+UkoTEjuJ5Rs+dQK8YpxKN2AQZJd8Fow58954+4IytTF14 ikg6dFZ4gA5kDZPI+ciUsybmK9+bQynsNsndop8EJ7pyT63Ij+PamUcTrem1XWFT r1VZE2sd6QVygk9JYdQhX6dyufipJXkTIpIMJtgj9sA7K4EL94W7euIXHQ9qQOO+ duR97SZwBIlj8ejkWbPZrmuslBl85Rl6j2B86KI5TtnQLQv7+kEdRxXLcB7rCM22 X2IqS0oSW6cHAf7l/+VPi56qYp4HHWPUFlxuzuHM5k9ht37DEzCjdz6V7KyZnE5S YVR+j0QKffAT4cRNd1uR77BNTfrA8/V3y2Svw3x/pENTLnytO2h73kJemvy6apMu K5eUBRHBP1ubKWgY0QfosGGoOArPVNSOnLlQIrMxmtNJ7hOeX4XrB45TVfqC03aL P6cC3MYNBL7pe5JAbFT/ =YonH -----END PGP SIGNATURE----- --Apple-Mail=_749E95AC-7DCA-4FD9-A6AB-F69611AE2A05-- From nobody Wed Apr 6 08:24:19 2016 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 3CFA712D660 for ; Wed, 6 Apr 2016 08:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JtoXmm6N-fs for ; Wed, 6 Apr 2016 08:24:16 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 688DB12D781 for ; Wed, 6 Apr 2016 08:21:07 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id n3so68073613wmn.0 for ; Wed, 06 Apr 2016 08:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=P1ip9ayDHN8ok9O3asjw8yUS6rU4g8niUIOOGmW1qy8=; b=g5R3RQRcjW+jaabAd3bD5DVkyPsh26Iz0qS8OI0xqbwv38J+Db5q94SKieHQfFTL/Y eyjBbvVqPZ7fRCTqbqwBqhYMvlgN/RqSL08Z4mRgiyuNe+Phwv8oPZXy2jfy743NqSWk D9W7daAror0PZHzaH3O5jLSIlxcpiS3dyl5ME= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=P1ip9ayDHN8ok9O3asjw8yUS6rU4g8niUIOOGmW1qy8=; b=cmRYyOBO/nEbBFwqtBp1Upg3/YCRZ7zfo6QTk3OmC5Iks6PLYYAimWMv9gO7lupJou YAmWExm6qLtojur7JfcEqevBOSgOhTUoWxB+aYDSsqFrhkrrd/09dGy/9lO46t2wdWNp IlMscy1UbYQdgv1CwtW0au0kr9DaH9SB4rv8l2BimsxrVz2PJXmUmT3dhgOusDtubcKm fHBWotUazjbJi1OSfcyNo1YNwS4nz4U6vVzbXK24H6872cXpMY8CO4BYWI5RJ3j0nixk stxzFFqSmPp4gZdhKFiCIc8VzYmSa8x2bRWYnw14MNI0ebDvMHsUWIK3oZ+i6Ls9VWi4 PPeA== X-Gm-Message-State: AD7BkJKuFQfwmEX0x3f5mPpw7YFg4N1TWm1xT9WHnN8rvawkK4NGaS5E91eNMexvenHUew== X-Received: by 10.28.218.145 with SMTP id r139mr25618302wmg.52.1459956065996; Wed, 06 Apr 2016 08:21:05 -0700 (PDT) Received: from [192.168.23.127] (chello212017113090.11.11.vie.surfer.at. [212.17.113.90]) by smtp.gmail.com with ESMTPSA id a184sm1835031wma.3.2016.04.06.08.21.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Apr 2016 08:21:03 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FD0CF216-BAFA-47EE-ABD1-2F2C72714806"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Aaron Zauner In-Reply-To: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> Date: Wed, 6 Apr 2016 17:21:29 +0200 Message-Id: References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 15:24:18 -0000 --Apple-Mail=_FD0CF216-BAFA-47EE-ABD1-2F2C72714806 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On 30 Mar 2016, at 03:53, Sean Turner wrote: >=20 > Hi! >=20 > In Yokohama, we discussed changing the IANA registry assignment rules = for cipher suites to allow anyone with a stable, publicly available, = peer reviewed reference document to request and get a code point and to = add an =E2=80=9CIETF Recommended=E2=80=9D column to the registry. This = change is motivated by the large # of requests received for code points = [0], the need to alter the incorrect perception that getting a code = point somehow legitimizes the suite/algorithm, and to help implementers = out. We need to determine whether we have consensus on this plan, which = follows: >=20 > 1. The IANA registry rules for the TLS cipher suite registry [1] will = be changed to specification required. >=20 > 2. A new =E2=80=9CIETF Recommended=E2=80=9D column will be added with = two values: =E2=80=9CY=E2=80=9D or =E2=80=9CN=E2=80=9D. Y and N have = the following meaning: >=20 > Cipher suites marked with a =E2=80=9CY=E2=80=9D the IETF has consensus = on > and are reasonably expected to be supported by widely > used implementations such as open-source libraries. The > IETF takes no position on the cipher suites marked with an > =E2=80=9CN=E2=80=9D. Not IETF recommended does not necessarily (but = can) > mean that the ciphers are not cryptographically sound (i.e., > are bad). Cipher suites can be recategorized from N to Y > (e.g., Curve448) and vice versa. >=20 > 3. We will add a =E2=80=9CNote" to the IANA registry itself (i.e., on = [0]) that matches the above so that the same information is available to = those who don=E2=80=99t read the IANA considerations section of the RFC. >=20 > Please indicate whether or not you could support this plan. I maintain the OCB draft and I do support this idea. Sorry for joining = this thread late. I did however vote on it during the meeting on monday. What's still unclear to me from the discussion is what suites would get = a Y or N and which suites won't. Are we just talking about WG consensus = or does implementation-availability weigh in here? It's not perfectly = clear to me how this would be decided; just because the IANA registry = flags a certain suite as preferred doesn't mean it actually will be = implemented, and vice-versa. Library authors sometimes implement = algorithms out of pure interest and love for coding. I, too, think going = beyond a simple Y/N would just further complicate things for = implementers and people trying to understand the IANA registry. Aaron --Apple-Mail=_FD0CF216-BAFA-47EE-ABD1-2F2C72714806 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXBSl6AAoJEOTbZJL9ubXV4VQP/iSWhKx1y3MFXrMjdqHz6mMM +vpDgb9ek4+4C35orbPZMTnh9mn9BAIFgE8w3ZPIiOyfge/alwfqk6+nJTyTKQ7b viEuUf/NUDNb7TeTX2ICZyRk1lkR8swo4l8Z5bhYg/IUoO6MxC8kt9tj1Cq9jDdw H+Y1+j9H+GFXltuM13VxFTDJgRG3hM2DlwvcyQWIgD5d9HSVDajW5Wgu7qRHO831 zG1y0iJxd+jf1+tVUBJA2RZs4r9hBkiqLP7RidQTQ6Q1Y+6F8+VpIi35czC6UAw/ 4Nk/vj6zlnURPJgoRuvn28fOvylI7b0UPPlRY57uIvyFjYJzu507zGHvZzKpLHez 8YQUXmFEmFZEeUU5Er4CNbpYdRaGdXiMi9DPm/3nelPz1mJhaP0/WkA9WDkVrue4 gBg5kpljdM/OIY5nb1ulPCIxlxIgbEfka7qYKq048/uehwkx2gKltraHVJZKcfbf hupD8bRYvL+0iS91+gStJje1/7YsWbGT2B2CpNNztuOP6JahyWnn/5y8dUy48kId Oo5yszcbcBUS2ECRtQAhOBV3ONRQJGCyQqbVq+Wd1IpgBLA/Cmfe09IFNy9888Pm srjwoowHKveh8/1jS7cVwYs2IkOwQD29ca8e3D+k74CtxGaVXjUwXZFLQfMPqYZH WTkn4hRy8dMvXcudzkhF =h9/2 -----END PGP SIGNATURE----- --Apple-Mail=_FD0CF216-BAFA-47EE-ABD1-2F2C72714806-- From nobody Wed Apr 6 09:10:43 2016 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 408D612D15E for ; Wed, 6 Apr 2016 09:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cixTQxRObeRa for ; Wed, 6 Apr 2016 09:10:39 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ACBF12D10C for ; Wed, 6 Apr 2016 09:10:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B2EBBBE2F for ; Wed, 6 Apr 2016 17:02:36 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07haYxdmAOLS for ; Wed, 6 Apr 2016 17:02:29 +0100 (IST) Received: from [31.133.178.21] (dhcp-b215.meeting.ietf.org [31.133.178.21]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C66D4BE33 for ; Wed, 6 Apr 2016 17:01:55 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1459958516; bh=mPTUXLKRKLZ+wtv4eRX6Xf7bexyWs1bOQ+jRIRa5hOs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=X0ZEKlyZ+otw5Y06QHl5GNiwCIDLPVUEPO9lZrRXKSXOY3T3mizxn3v3xnKK7GAx5 jIukinDBOeJYHAhKyVLGC79oEz4TxyUUD3HJ29QkScQO/Ibr+jqj28Nz7fI72joawq VUY4HLKpVzIkArb1rBbTNd0WuFRGuxk5VF+hmiW0= To: "tls@ietf.org" References: <56F2B2E7.1060809@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <570532F1.9090802@cs.tcd.ie> Date: Wed, 6 Apr 2016 17:01:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F2B2E7.1060809@cs.tcd.ie> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010702080701050206010107" Archived-At: Subject: Re: [TLS] AD review of draft-ietf-tls-falsestart-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 16:10:41 -0000 This is a cryptographically signed message in MIME format. --------------ms010702080701050206010107 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, ekr, Sean and Joe convinced me #2 below wasn't really needed. And I don't much care what the WG conclude wrt #1 (and we can fix later if needed), so I've requested IETF LC to start for this. Thanks, S. On 23/03/16 15:14, Stephen Farrell wrote: >=20 > Hiya, >=20 > I've done my AD review of this and have three questions > I'd like to ask before starting IETF last call. I mostly > care about the answer to #3. #1 is just a suggestion that > might avoid some process-crap and #2 is just me being > curious (unless #2 turns out to be a part of #3). >=20 > (1) Why experimental? Wouldn't this be better as info > and documented as "here's a spec for a thing that's > widely deployed." I fear we may get questions like > "what's the experiment?", "where's this going in > future?" if this aims for experimental, and info may > avoid that esp if we really want people to move to > TLS1.3. I also didn't see list discussion about what > kind of RFC to aim for, but maybe it was discussed at > a meeting or interim? (Apologies if I missed that in > my scan of the list.) >=20 > (2) The write up and some mail list traffic and AGL's > bloggy thing all refer to NPN, but there's no mention of > NPN or ALPN in the draft. What's up with that? (Not > saying that needs to be explained, but I wondered.) >=20 > (3) Why is there no description of the reasons for all > the MUST only use whitelisted and for the choices > that are whitelisted? Wouldn't omitting that tend to > lead people to use this more badly? That could be done > with some explanatory text and using some of the > references below maybe. Or, if we don't really want new > folks to implement this (do we?) then just saying that > might mean it's ok to not explain the "why." (And then > you could also address #1 above then by issuing this > as an historic RFC too if you wanted.) >=20 > Cheers, > S. >=20 > Possible refs: > - http://www.ieee-security.org/TC/SP2015/papers-archived/6949a535.pdf > (esp Section V-C) > - http://homes.esat.kuleuven.be/~fvercaut/papers/ACM2012.pdf > - https://hal.inria.fr/hal-01184171/document > - https://arxiv.org/pdf/1602.02396.pdf > - https://eprint.iacr.org/2016/072.pdf >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --------------ms010702080701050206010107 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA0MDYx NjAxNTNaMC8GCSqGSIb3DQEJBDEiBCCJGNU553wPH7GNOCv+C7dKrjCz6pBpnuD015eM3c7v TDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAKTBI7G70e+OWoGUxx4jPz/+4wE3/bEbR8B6g7bUeIOLP81WTyzIeQ kS5kqOXrxiS5W8yeSHnY5YpBwbLPvBC6hHDdNk/GEQSodaKBRQXQyZcBsPcRoVem12wO00eg xN4kB8s2GJyXqHuz3VLLop9ZpDucGXOXBqgSM3m+XsGyEoMY2kuL9Xf+8j611icntgMHzukL lbNgnJXf5UgDhMo7cf9jjNDvKlt83SvBStXuw28rkWe0auF0HnZz5roJjKw5nrMWsEZHYA20 Fkz9LdCOwxBxwK0BhZ8zWKGp9DaGilNoGsl/pShhWQPTOTBAF/FrvAVS5eQ+BQHQbLGK91nU AAAAAAAA --------------ms010702080701050206010107-- From nobody Wed Apr 6 10:16:22 2016 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 1AD0812D623 for ; Wed, 6 Apr 2016 10:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIYsh26cNpRt for ; Wed, 6 Apr 2016 10:16:19 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5DCB12D5F0 for ; Wed, 6 Apr 2016 10:16:18 -0700 (PDT) Received: by mail-qg0-x232.google.com with SMTP id c6so41521690qga.1 for ; Wed, 06 Apr 2016 10:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FN2xscADRsW/NwJQuomRIUbodXPmRmBYSH4bQRzYW3M=; b=kPS3vmdq1Zyb+HRQtpONnZChvZ9w9eGxawomZNWRjfN4wnSQptT7MYTw5zkBf2D2x2 KtiWqJT2cjwNCl8INqfSix/Hsi6wBLOPOxO8Ll5Rp3x4IxzVmrBD7OjrHnyNuRtYudZI rgTPRqtMpsYen5D52VP0eCtH/DkXQV5cI8URc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FN2xscADRsW/NwJQuomRIUbodXPmRmBYSH4bQRzYW3M=; b=ekCFuThi1TkvoKobRlhBD79qXpwwRJvFCtr7Eo8GpWPj9AJFMqCGvkgU9MTl0n7dyR oKwZA1mmdBvr4g1HqN+0jvIzti32Jm7beUMNR23NBgtfnMHmsx7sffh8p/cWPfN68xVs 2W/et2rlENy6BdRXessk1Mar96UysYjlQG3HO8Q9KUiU6cIL8EXPZMU4O3em5VZN7YfW z6tNDnG++I11UB5WCNPYnwibqIw3POmenjV5nvInpjvFwkhpeuKLqHiJ4tJ2ILuFViUz mKY7X2CTdfNjyaPEF+RR/RibZnWcSRFe1rmUCJKc7fQXNYUnpAHYNkyIKMvHCQ0eZuqz YCNg== X-Gm-Message-State: AD7BkJLVD6+Ox4sn9nWLUGvxGl1F+Hq1S7iW1ME/55wCOeVEGbHJ6A5F64CCatnFwzNClA== X-Received: by 10.140.153.135 with SMTP id 129mr39544999qhz.38.1459962977827; Wed, 06 Apr 2016 10:16:17 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:fca1:5cc3:4f89:2dc6? ([2001:67c:370:176:fca1:5cc3:4f89:2dc6]) by smtp.gmail.com with ESMTPSA id c90sm1649566qkj.47.2016.04.06.10.16.15 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Apr 2016 10:16:16 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Wed, 6 Apr 2016 14:16:13 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> To: Aaron Zauner X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:16:21 -0000 On Apr 06, 2016, at 12:21, Aaron Zauner wrote: >=20 > Hi, >=20 >> On 30 Mar 2016, at 03:53, Sean Turner wrote: >>=20 >> Hi! >>=20 >> In Yokohama, we discussed changing the IANA registry assignment rules = for cipher suites to allow anyone with a stable, publicly available, = peer reviewed reference document to request and get a code point and to = add an =E2=80=9CIETF Recommended=E2=80=9D column to the registry. This = change is motivated by the large # of requests received for code points = [0], the need to alter the incorrect perception that getting a code = point somehow legitimizes the suite/algorithm, and to help implementers = out. We need to determine whether we have consensus on this plan, which = follows: >>=20 >> 1. The IANA registry rules for the TLS cipher suite registry [1] will = be changed to specification required. >>=20 >> 2. A new =E2=80=9CIETF Recommended=E2=80=9D column will be added with = two values: =E2=80=9CY=E2=80=9D or =E2=80=9CN=E2=80=9D. Y and N have = the following meaning: >>=20 >> Cipher suites marked with a =E2=80=9CY=E2=80=9D the IETF has = consensus on >> and are reasonably expected to be supported by widely >> used implementations such as open-source libraries. The >> IETF takes no position on the cipher suites marked with an >> =E2=80=9CN=E2=80=9D. Not IETF recommended does not necessarily (but = can) >> mean that the ciphers are not cryptographically sound (i.e., >> are bad). Cipher suites can be recategorized from N to Y >> (e.g., Curve448) and vice versa. >>=20 >> 3. We will add a =E2=80=9CNote" to the IANA registry itself (i.e., on = [0]) that matches the above so that the same information is available to = those who don=E2=80=99t read the IANA considerations section of the RFC. >>=20 >> Please indicate whether or not you could support this plan. >=20 > I maintain the OCB draft and I do support this idea. Sorry for joining = this thread late. I did however vote on it during the meeting on monday. >=20 > What's still unclear to me from the discussion is what suites would = get a Y or N and which suites won't. Are we just talking about WG = consensus or does implementation-availability weigh in here? It's not = perfectly clear to me how this would be decided; just because the IANA = registry flags a certain suite as preferred doesn't mean it actually = will be implemented, and vice-versa. Library authors sometimes implement = algorithms out of pure interest and love for coding. I, too, think going = beyond a simple Y/N would just further complicate things for = implementers and people trying to understand the IANA registry. >=20 > Aaron What we=E2=80=99re talking about is IETF consensus (i.e., it=E2=80=99s = got to get through an IETF LC which is slightly higher than just a = WGLC), but we=E2=80=99d do a one sentence tweak to the TLS WG charter to = make the TLS WG be the entity that determine whether there=E2=80=99s a Y = or N. A =E2=80=9CY=E2=80=9D does not guarantee that it will be implemented and = that=E2=80=99s why we put "and are reasonably expected to be supported = by widely used implementations such as open-source libraries.=E2=80=9D = Those are pretty good weasel words, but since there=E2=80=99s no = protocol police we can=E2=80=99t really say they will be implemented. = On the other hand, open source implementations also have their own = pressures they have to deal with that I=E2=80=99m not sure should = automatically impact the list. I also am worried about just adding = algorithms that are in an open source implementation because I believe = just about everybody that=E2=80=99s requested a code point starts the = conversation out with =E2=80=9CI=E2=80=99ve got this OpenSSL patch =E2=80=A6= . " spt From nobody Wed Apr 6 10:33:07 2016 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 D1F0312D6F5 for ; Wed, 6 Apr 2016 10:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5C7w4A9kbMei for ; Wed, 6 Apr 2016 10:33:01 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0116.outbound.protection.outlook.com [23.103.200.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C441A12D6D9 for ; Wed, 6 Apr 2016 10:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2um14h3x8w79IovS4pjkT++F6eBRfys9Wm9VsxD+/Qg=; b=oasAe/8h/GyuFSAyIlVvxcx8/LVZa4scSXCRB1R+f4YmtTE0whDU3qYlfAY+G2Q89VyYL3uJCrH1JlStVPy2xJ7D7FqYQNUJ92yU2B78umuqmKZwBs7HCFCMc2M2EXUl7wGWjhTQZQ/bBdfKQhx3YGScGVAnr2S35UD9wB//fBI= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB121.namprd09.prod.outlook.com (10.255.200.145) with Microsoft SMTP Server (TLS) id 15.1.447.15; Wed, 6 Apr 2016 17:32:59 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0447.028; Wed, 6 Apr 2016 17:32:59 +0000 From: "Dang, Quynh (Fed)" To: Hannes Tschofenig , Sean Turner , "" Thread-Topic: [TLS] call for consensus: changes to IANA registry rules for cipher suites Thread-Index: AQHRi1Owi0D04/+DE0+p53p0UyUeQJ99PGoW Date: Wed, 6 Apr 2016 17:32:58 +0000 Message-ID: References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com>, <56FD2A0A.1050607@gmx.net> In-Reply-To: <56FD2A0A.1050607@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=nist.gov; x-originating-ip: [2001:67c:370:160:c9ba:e21e:246:a4f2] x-ms-office365-filtering-correlation-id: 6048529b-112c-4258-8ff4-08d35e417f49 x-microsoft-exchange-diagnostics: 1; BN1PR09MB121; 5:l7YTr2iBtHdvIYOOV0RdILXBB1iO3NyT6A2aqkHGmBVM4v7Lr19kC0fpu39hpK2/IjZG64nB4ixwYITcg2nocuLZ5Fl8UctF3EiBoTKkzrdaV0hHzmZL1zbCHJx2rav6uOIjoibTNkbu91P+c7uthQ==; 24:nz/Cwq0u5Secnp5dEPuY34W3wSVCVswIqGJC0o6+nQlfOpHgXdPkcMYb2wJp3fF103L7gIQ2gfC0dFHI4CCzqlQ4Jab6N11kY02Rwgs7auc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB121; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BN1PR09MB121; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB121; x-forefront-prvs: 0904004ECB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(1220700001)(87936001)(76176999)(1096002)(54356999)(2950100001)(10400500002)(5008740100001)(102836003)(2900100001)(586003)(189998001)(74316001)(107886002)(5001770100001)(5002640100001)(5004730100002)(50986999)(6116002)(15975445007)(5003600100002)(33656002)(106116001)(122556002)(77096005)(86362001)(99286002)(76576001)(81166005)(11100500001)(92566002)(3660700001)(164054004)(2906002)(19580405001)(3280700002)(19580395003)(3900700001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB121; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2016 17:32:58.6253 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB121 Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:33:06 -0000 Hi Sean, I would like to express my opinion again. I think the first requirement is great and sufficient.=20 I have great support, appreciation and respect for the open source communit= ies. However, the second requirement means that an IETF consensus can have = no values in theory and that sounds not right to me. Regards, Quynh.=20 ________________________________________ From: TLS on behalf of Hannes Tschofenig Sent: Thursday, March 31, 2016 9:45 AM To: Sean Turner; Subject: Re: [TLS] call for consensus: changes to IANA registry rules for c= ipher suites Hi Sean, What is the requirement for adding a spec to the list with the value IETF Recommended =3D "Y" (or to change an entry from "Y" to "N")? You mention two conditions: * IETF has consensus * Are reasonably expected to be supported by widely used implementations such as open-source libraries Of course, with all our work we expect them to be supported by widely used implementations. The future is unpredicable and therefore not a good item for making a judgement. I realy find document authors who have less interest to get their stuff deployed. Getting IETF consensus on specifications has turned to be easier than most people expect and the IETF published RFCs that have not received a lot of review. Large amount of review is not a pre-condition for consensus. While your idea sounds good it suffers from practical issues. I am worried that the process will not be too fair and may favor a certain type of community. Ciao Hannes On 03/30/2016 03:53 AM, Sean Turner wrote: > Hi! > > In Yokohama, we discussed changing the IANA registry assignment rules for= cipher suites to allow anyone with a stable, publicly available, peer revi= ewed reference document to request and get a code point and to add an =93IE= TF Recommended=94 column to the registry. This change is motivated by the = large # of requests received for code points [0], the need to alter the inc= orrect perception that getting a code point somehow legitimizes the suite/a= lgorithm, and to help implementers out. We need to determine whether we ha= ve consensus on this plan, which follows: > > 1. The IANA registry rules for the TLS cipher suite registry [1] will be = changed to specification required. > > 2. A new =93IETF Recommended=94 column will be added with two values: =93= Y=94 or =93N=94. Y and N have the following meaning: > > Cipher suites marked with a =93Y=94 the IETF has consensus on > and are reasonably expected to be supported by widely > used implementations such as open-source libraries. The > IETF takes no position on the cipher suites marked with an > =93N=94. Not IETF recommended does not necessarily (but can) > mean that the ciphers are not cryptographically sound (i.e., > are bad). Cipher suites can be recategorized from N to Y > (e.g., Curve448) and vice versa. > > 3. We will add a =93Note" to the IANA registry itself (i.e., on [0]) that= matches the above so that the same information is available to those who d= on=92t read the IANA considerations section of the RFC. > > Please indicate whether or not you could support this plan. > > Thanks, > > J&S > > [0] In the last year, the chairs have received requests for: > > PSK: https://datatracker.ietf.org/doc/draft-mattsson-tls-ecdhe-psk-aead/ > AES-OCB: https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt > Kcipher2: https://datatracker.ietf.org/doc/draft-kiyomoto-kcipher2-tls/ > dragonfly: https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/ > NTRU: http://www.ietf.org/id/draft-whyte-qsh-tls12-01.txt > JPAKE: not sure they got around to publishing a draft. > > [1] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#= tls-parameters-4 > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Apr 6 10:39:19 2016 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 ACE5D12D6E4 for ; Wed, 6 Apr 2016 10:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deKOCyRAHqw2 for ; Wed, 6 Apr 2016 10:39:15 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1547412D0F3 for ; Wed, 6 Apr 2016 10:39:15 -0700 (PDT) Received: by mail-qg0-x229.google.com with SMTP id j35so42135935qge.0 for ; Wed, 06 Apr 2016 10:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=59nPJfZ23UbZ6EaBkzNAbvSeLcHYfeWhJBklUzAFnFc=; b=CWIfrDufIRHqnlJQJI+AyPpLmnQ3KkjcHsJDtTkBRctl0UJ6bTknI3U40eChuYQl9v jkhoi14t3B1Eab/HnNrcwicXEarzIYO8wTghgEps/lgAylBDZ5TpcT+9SVVE8bARn/1r oRk/4cxBLWFEBbdO7Qg1qHyS6XvWtmjY+DDtk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=59nPJfZ23UbZ6EaBkzNAbvSeLcHYfeWhJBklUzAFnFc=; b=W+ZuYY2vtovcul/CoAH+w7E5Y1yDsnsri7jMTbhIpWk7aQndyLOUBeV1rmih6aCpqZ 4N+GqL/JACXHnSgc6ApnESl/3a+IDQ+yGzERpEpVqn1KS7mfskjwOzSx+1d5KciYA09c go/kYxbQl5uFn9tc449EqcYk+X2YH86jCHyhpcvq2hyJ1aW7gd5H8nAVXOY9ypUZcZXv se5/o0mYUJOR/XKgd/+rShowqMI0E7CXPQlZobuLt1HHb+W1f/iCRZVjCE8VjCMJ2CmU 4gBR8RcfWOL9MSMVF/+X1FkVI8EK4bTgCkwgmulpNZTdK3XeopMmP+340xwOFNQWudge Eahg== X-Gm-Message-State: AD7BkJJZObMJ+Bf4YoprdBYuLdSblmhmD6WTt1nvzMUvBFhqutX414rj+W1KBilgg8XggA== X-Received: by 10.140.86.101 with SMTP id o92mr25943709qgd.49.1459964354186; Wed, 06 Apr 2016 10:39:14 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:fca1:5cc3:4f89:2dc6? ([2001:67c:370:176:fca1:5cc3:4f89:2dc6]) by smtp.gmail.com with ESMTPSA id a11sm1691133qge.43.2016.04.06.10.39.12 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Apr 2016 10:39:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner X-Priority: 3 (Normal) In-Reply-To: <96b5aa358a8bcc0145dfcd935d20062b.squirrel@www.trepanning.net> Date: Wed, 6 Apr 2016 14:39:10 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0A40070B-4BA8-446A-8723-09CF60A7A546@sn3rd.com> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <96b5aa358a8bcc0145dfcd935d20062b.squirrel@www.trepanning.net> To: tls X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 17:39:17 -0000 On Apr 03, 2016, at 22:24, Dan Harkins wrote: >=20 > I wonder if you have thought this through or prepped the > stuckee? During Wed=E2=80=99s session the chairs took the action to prep the = =E2=80=9Cstuckee(s)=E2=80=9D. Those other stuckee(s) include: - Our AD (Stephen for the next year): is following along. - The Independent Stream Editor (ISE): I talked to Nevil Brownlee (often = can be found during the IETF week by the RFC editor=E2=80=99s table) = about the uptick in drafts coming his way. The current backlog of ~5 = didn=E2=80=99t seem to phase him. He reminded me (as I mention at the = TLS session) that there is also an ISE review that falls back on the = community. This review process can be greatly aided by noting the last = bullet in the submission instructions found at [0]; tl;dr propose a = competent reviewer to the ISE. - The IANA protocol parameter folks: I also talked to Michelle and = Amanda. They are also comfortable with the change and adding the note = in the registry. spt [0] https://www.rfc-editor.org/about/independent/= From nobody Wed Apr 6 11:37:40 2016 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 6E7B812D774 for ; Wed, 6 Apr 2016 11:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKXoGq_CaFyZ for ; Wed, 6 Apr 2016 11:37:37 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 57B6412D729 for ; Wed, 6 Apr 2016 11:37:37 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u36IaDHI043013; Wed, 6 Apr 2016 14:36:20 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Aaron Zauner , "tls@ietf.org" Thread-Topic: [TLS] Fwd: New Version Notification for draft-zauner-tls-aes-ocb-04.txt Thread-Index: AQHRkDGPBzRCbC0njEqL+dur4SQUXw== Date: Wed, 6 Apr 2016 18:24:29 +0000 Message-ID: References: <20160404164526.15645.26001.idtracker@ietfa.amsl.com> <5194DF8B-DFF1-4E41-A93C-6A80D063E7B5@azet.org> In-Reply-To: <5194DF8B-DFF1-4E41-A93C-6A80D063E7B5@azet.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [172.25.177.51] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha384; boundary="B_3542797463_41697750" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-06_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1604060270 Archived-At: Cc: "ted@krovetz.net" Subject: Re: [TLS] Fwd: New Version Notification for draft-zauner-tls-aes-ocb-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:37:39 -0000 --B_3542797463_41697750 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit I seem to recall that Ted Krovetz some time ago submitted a draft (to CFRG?) defining OCB: https://tools.ietf.org/html/draft-krovetz-ocb-04 . Perhaps these two should be brought to sync, since the nonce construction changes? -- Regards, Uri Blumenthal On 4/6/16, 10:47 , "TLS on behalf of Aaron Zauner" wrote: >Hi, > >I've uploaded a new version of the OCB draft a few days ago. Major >changes: > >- the nonce construction is now identical to the one from the chacha/poly >draft to reduce risk of nonce misuse/reuse >- added a security considerations section on data limit under a single >key (identical to GCM) >- IPR claims for TLS are now fully resolved as far as I can tell - the >draft contains updated information on the issue > >I'm happy to receive any feedback/critique on the draft if anyone is >interested in reviewing. > >BTW: Andy Polyakov has added AESNI optimized assembly for OCB to OpenSSL >(https://github.com/openssl/openssl/commit/bd30091c9725bdad1c82bce10839f33 >ceaa5623b). C/B numbers are quite impressive, IMO. > >Thanks for your consideration, >Aaron > >> Begin forwarded message: >> >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-zauner-tls-aes-ocb-04.txt >> Date: 4 April 2016 at 18:45:26 GMT+2 >> To: "Aaron Zauner" >> Message-Id: <20160404164526.15645.26001.idtracker@ietfa.amsl.com> >> >> >> A new version of I-D, draft-zauner-tls-aes-ocb-04.txt >> has been successfully submitted by Aaron Zauner and posted to the >> IETF repository. >> >> Name: draft-zauner-tls-aes-ocb >> Revision: 04 >> Title: AES-OCB (Offset Codebook Mode) Ciphersuites for Transport Layer >>Security (TLS) >> Document date: 2016-04-04 >> Group: Individual Submission >> Pages: 8 >> URL: >>https://www.ietf.org/internet-drafts/draft-zauner-tls-aes-ocb-04.txt >> Status: >>https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/ >> Htmlized: https://tools.ietf.org/html/draft-zauner-tls-aes-ocb-04 >> Diff: >>https://www.ietf.org/rfcdiff?url2=draft-zauner-tls-aes-ocb-04 >> >> Abstract: >> This memo describes the use of the Advanced Encryption Standard (AES) >> in the Offset Codebook Mode (OCB) of operation within Transport Layer >> Security (TLS) and Datagram TLS (DTLS) to provide confidentiality and >> data origin authentication. The AES-OCB algorithm is highly >> parallelizable, provable secure and can be efficiently implemented in >> software and hardware providing high performance. Furthermore, use >> of AES-OCB in TLS is exempt from former IPR claims by various >> parties. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >>submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > --B_3542797463_41697750 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ4AYJKoZIhvcNAQcCoIIQ0TCCEM0CAQExDzANBglghkgBZQMEAgIFADALBgkqhkiG9w0B BwGggg6fMIIE6jCCA9KgAwIBAgIKMztKZQAAAABumTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzMzN1oXDTE5MDExMzE3MzMzN1ow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDqifs8K0OoodbmOo5G/j2+p2ibbOsEoJ9GJjK8K1Iw 6iig59a3EuNB6NR4tAR3INwjjUwMCa4o8ysnk1hN32B3HPrK5Z8++Y/xcX5iP1L6fc51YQ5C /EGvrSbjuPLvt19SNfVdwcuoc842Sgk9N/HemdwmvcqJkwzWDsuxKikI2clT1N5LTAaPMkhr HVuYOHBE0mCXjHjFnYuHsEXyVvUZLxziDgduV9WKbC90Z1NZMXB6ZeQTACUWgMfpFrE12LKb fvOmxepCBfCPbGB3ZyG+FaUdtQoCEAbGTnY7nCedQFn7pV1hppCt4jjLVlOpgYc3dPmyiXsL nhDQZ5ptmks/AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUiXqPublGfd0sWKNk/BObT6Oorzgw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAK7HM6o1IolvkCJrlsjj N1+0Z2JG8anwkHkVKAg/K9qUD0LE9zbnK3kZRGZsljJUDG+hMWmTWCkx0TTzbg/BeVrypVPD 7rn1Tagi9QBV2eJhdBZRHWOcsteRldUukKbMw74hkNGH9o/p/FFZYMA0kHnA7XfECilF9Yl6 uKDv1lbjuWdgcKD1FdEj7rL/IdX0wKJVUKjwLG1RQZel1nuwyRjVtXWz8IUMJXRsYHf6uSzy YoNBeZuWyMx/J5c0ACKXXs1O721GPJ5U5gcEaQ/b8lwQGcOgPk28RPwgiBF3f5TgrTa7QxGf ozmNsTj1OV1vU0vjqKrg7USi9q0xTdGUIyowggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIE7TCCA9WgAwIBAgIKMziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJV UzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYD VQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBl b3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4cot eDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4 u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n 2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh 6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQV ubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEE WjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYI KwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAu BiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUE HjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV 2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwX ENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2Pz BkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvv k0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa 1Vshx7ElBIk0cXhep6mLMLqGNX3azAkxggIFMIICAQIBATBfMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTMCCjM7SmUAAAAAbpkwDQYJYIZIAWUDBAICBQCgeTA/BgkqhkiG9w0BCQQx MgQw0mmlJqTURtkIqReAVvB6Rcjt53JzPDChnM6WSpB6PLjvHDAyFQrkmV93fFRRpHnRMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDQwNjE4MjQyM1ow DQYJKoZIhvcNAQEBBQAEggEAjwDvAcDzu96pvGpzTI9iarertfWXrH3ODE6KnSWxh7z8fK6b OW2Dqq6AwRaFt3TDoouJzjJrVop6Zvp7+ihUvsUp6B6gXIm72ZYU4gVfGmr1Mxwkx5Y76IDT YtZn7AjJ9MAkLGpYHW/Z5X/Iyjw4zNs2wNKuANdU3v312yZ54GyCYQ56ia1tFjVM8wIjrF7x HX7PiQldv32c8Z3rxSai8Ou5VWCstjC8kwJ7o/m+HcXzBk3mLUdcV7utTTkofllpniRDRSdt b5bqPzMOT9No2QegzSH1DwUQD2meJese0TParuIxPu+N/BPGAzhC+Ikvnc6jLIVd6nNub4GT OCS7kg== --B_3542797463_41697750-- From nobody Wed Apr 6 11:38:33 2016 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 084E212D653; Wed, 6 Apr 2016 11:38:32 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160406183831.24899.59187.idtracker@ietfa.amsl.com> Date: Wed, 06 Apr 2016 11:38:31 -0700 Archived-At: Cc: tls-chairs@ietf.org, draft-ietf-tls-falsestart@ietf.org, tls@ietf.org Subject: [TLS] Last Call: (Transport Layer Security (TLS) False Start) to Experimental RFC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:38:32 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Transport Layer Security (TLS) False Start' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-04-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies an optional behavior of TLS client implementations, dubbed False Start. It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally. A TLS False Start reduces handshake latency to one round trip. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/ballot/ No IPR declarations have been submitted directly on this I-D. The reference to RFC2616 should probably be updated to 7230. From nobody Wed Apr 6 11:54:38 2016 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 25A0312D52F for ; Wed, 6 Apr 2016 11:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=krovetz-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzyUZLxYRxVb for ; Wed, 6 Apr 2016 11:54:35 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9143D12D18B for ; Wed, 6 Apr 2016 11:54:32 -0700 (PDT) Received: by mail-pa0-x233.google.com with SMTP id td3so38370219pab.2 for ; Wed, 06 Apr 2016 11:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krovetz-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rx54Z9mApUKXzZOWk2fB6dIX7wp99SoJfRR/5uZilgI=; b=sOwh8D8Sy0ZUmAXwSsxR8bbxCfKPAGzhZXLnpM+cLHNmSCcITNpELA2eM4ueiuhH94 aJ8nDJZlLo/PoevXLzNtmJynNkrecKt+bm6Ftyy5Cfa57iePFdxxg1mudv83njYcGKO5 GWqOWB+WmA00vSmutECX73Q1M1auQwDj3+/9QqIVOUrNAolWRKbI/Rx5gj0vyyFNAgjF yZNm8eh2p6b2e6h0vzFko/C/XucAdJOlzBwKWpkc97bCAH4Ry+QCx7vps/WnbxP2JfkM 2WN1hatl6n7f0yDAV0/aP+etMLsLGrrXr9CgpJEvRT7wAuf+0dmhwWMGoWa1N2zWgqEK fwNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rx54Z9mApUKXzZOWk2fB6dIX7wp99SoJfRR/5uZilgI=; b=cr07uXCbZstNlAFrQEeZZctyOxV3menuCNJUCU3Nqg87uvxvZHYugvFo9QgzJdDSoi aCJPmFAoEhWI5pbZ8Sa1BtiuEixjrewNkukx9wfl+2KAD6SmaLKdXeRjIHffhgQYpLO0 0OT/l5a0BRJpUYI1I1gASvk7qeczxul7A6UQl50mELw8DdnyPVKh+Ov5MPeZ7O6LkRG9 w/gOYUpSptYVlxxYzDKrywTC4ZAmDJd3CoFU6iJK2OReawth2V6m06I2Lkqtgtq9V4/8 mkvnW9XD5G0AuBOfd79V/7eFyUVby1dBQiBYlI7XC38mzOpOtiw/6bIx3qSh1hnzka74 zKLw== X-Gm-Message-State: AD7BkJIen908Mx7/1HnVRhbc9j4HvcM0Rh7J1k/7AdCGMXAriyvs/Slcc01RKly38hNXEg== X-Received: by 10.66.90.163 with SMTP id bx3mr73318839pab.59.1459968872201; Wed, 06 Apr 2016 11:54:32 -0700 (PDT) Received: from isis.ecs.csus.edu ([130.86.68.216]) by smtp.gmail.com with ESMTPSA id r65sm6649787pfa.27.2016.04.06.11.54.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Apr 2016 11:54:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ted Krovetz In-Reply-To: Date: Wed, 6 Apr 2016 11:54:28 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <20160404164526.15645.26001.idtracker@ietfa.amsl.com> <5194DF8B-DFF1-4E41-A93C-6A80D063E7B5@azet.org> To: "Blumenthal, Uri - 0553 - MITLL" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: New Version Notification for draft-zauner-tls-aes-ocb-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:54:37 -0000 An RFC for OCB was approved in 2014. https://tools.ietf.org/html/rfc7253 From nobody Wed Apr 6 12:03:13 2016 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 699DB12D796 for ; Wed, 6 Apr 2016 12:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbNYRc-6CSIO for ; Wed, 6 Apr 2016 12:03:08 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B2F12D7A4 for ; Wed, 6 Apr 2016 12:02:39 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id n3so75752674wmn.0 for ; Wed, 06 Apr 2016 12:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=XNp+0ZcvbYA/FB9Zb50M2IWBfBdpqBAEt8zxkQAHWRA=; b=cmK3/td4Lrhgl/SxynJbtRXccQcw9E6myE8iiMYEHhRhi3M577lVl5AQ7ilL5WAOCv olfU4K1HY9K2BezDamE34AGppYyhgtuJQi7JasIX89cs42qhNIE8+W/ztwk69+zb9p6N BoZxTEHAY+uMW8dfn3OIHgmz+ARkV8ZAmeazU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=XNp+0ZcvbYA/FB9Zb50M2IWBfBdpqBAEt8zxkQAHWRA=; b=m5otdpTySU7baK6xKnG9tinPaGFy6g3rp1Jg9Z5olca4ZBmBlelh1pHQ04+kbN2I1w SluC2qLQnHAQHVuVBPP1SnMrU4GKWRXA2YzuyeuZUsD4dGHUbHwymqV2GmbF7ljFZGnR /k+ywmGMRO4UR/OuRbg8n0qnYa+aq4dqIyzzzev9kHQNAoNuJSTfdv4LiH4u+fHG6qF/ k47juYtJ7vQB5soBWhoVQ9aC1VZvrg5RHQSiy+5NImx28nlHp08hn+ejs7dhAXyE+FB+ L5zJEMrAQWj+1R+202WO0xSkqQc2/FAocCmpBN0JljnWh/VjCNOsy7hDdFOCU0LAOo8r EFGg== X-Gm-Message-State: AD7BkJIHsZkEZmUqf2IW5hAJHANGg9vScqbvwpKYU6r/pWskzPbTwzq/au124WIFOVbc4g== X-Received: by 10.194.246.137 with SMTP id xw9mr1276454wjc.172.1459969358229; Wed, 06 Apr 2016 12:02:38 -0700 (PDT) Received: from typhoon.azet.org (chello080108049181.14.11.vie.surfer.at. [80.108.49.181]) by smtp.gmail.com with ESMTPSA id e80sm26698468wma.1.2016.04.06.12.02.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Apr 2016 12:02:35 -0700 (PDT) Date: Wed, 6 Apr 2016 21:02:33 +0200 From: Aaron Zauner To: "Blumenthal, Uri - 0553 - MITLL" Message-ID: <20160406205517.c893a669a3@9d91a553349d5c3> References: <20160404164526.15645.26001.idtracker@ietfa.amsl.com> <5194DF8B-DFF1-4E41-A93C-6A80D063E7B5@azet.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "ted@krovetz.net" , "tls@ietf.org" Subject: Re: [TLS] Fwd: New Version Notification for draft-zauner-tls-aes-ocb-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 19:03:10 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hi Uri, * Blumenthal, Uri - 0553 - MITLL [06/04/2016 20:37:35] wrote: > I seem to recall that Ted Krovetz some time ago submitted a draft (to > CFRG?) defining OCB: https://tools.ietf.org/html/draft-krovetz-ocb-04 . > Perhaps these two should be brought to sync, since the nonce construction > changes? I'm not sure this is necessary as my draft is specific to the TLS nonce construction and there's no need to update the primitive itself. As far as I can tell this nonce construction doesn't conflict with the RFC defining the primitive. I've switched to this new nonce construction since it effectively prevents implementers from re-using the same nonce as it would make implementations non-interoperable, which I feel is a good thing. It's also similar to how TLS 1.3 will form a nonce. HTH, Aaron --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXBV1HAAoJEOTbZJL9ubXV9m0QAKzkjPxWNTUjvuSxgET4XJIb 7KbYzkNosVRLjZT8x5tOXlBDgr10C/0jvE4xm1DqAIhH17THOOYcqqvb0VV9C0w8 c3WK03USDCke8mJbtIEj1erpy54u8EJrXqpqvq+0YiBV85nmpeKS3loPIRKmiPlE 6hyMg+1hYgBhNreGlQNmULkfDaRIo+ENhQx+QPg5Tut0eWn+jwjEAStpvudhom2+ W+fgOt+jDZNOu49xpUyvIGYeGqrRBYKQKreslqaagTFnmrO0t9zjlnT3L7TaQIVq z+mm+ZsCV30rik7RZEi1DRwassLcqI0T8KdxaYw7CK1tQQ23xOKdpjPq69I/uxJ4 ev/imLsrluFZYr2HjVi3oTUsxUGzhV6q7svhhaGUGfPLs9326GoOEgIoohxPpbt7 KBayv89jmmMfwQ7yi63PN8yUdtsGWOduUP5yb2SbFfyZkXy9fUIbD3KpbJOuVEzU vi1ZlKtELLwCEGzacJnP7McK9MtSPqS88UMAdVzG5OwsZFv4AFBI473CCrV23ERS 09Y6pdXhFMJbS47jb9hmyK3Y+w3oJaoohKEIgpfSCfuOgkM4Cc/fC2upJHn+4xVz nIRJkSqVgPYUZFcwEEVrY6DS6cea+uiwJ+EyTNUylhlD8uVqoijXwoN9RBH2fckH oSmMzH5gPyXMm5Zxibir =m10b -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- From nobody Wed Apr 6 12:11:13 2016 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 E80D312D13D for ; Wed, 6 Apr 2016 12:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLKXvipvwi-8 for ; Wed, 6 Apr 2016 12:11:05 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2CA12D52F for ; Wed, 6 Apr 2016 12:11:00 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u36J9PIa020724; Wed, 6 Apr 2016 15:09:42 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Ted Krovetz , Aaron Zauner Thread-Topic: [TLS] Fwd: New Version Notification for draft-zauner-tls-aes-ocb-04.txt Thread-Index: AQHRkDGPBzRCbC0njEqL+dur4SQUX599jigA///BVwA= Date: Wed, 6 Apr 2016 19:10:22 +0000 Message-ID: References: <20160404164526.15645.26001.idtracker@ietfa.amsl.com> <5194DF8B-DFF1-4E41-A93C-6A80D063E7B5@azet.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [172.25.177.51] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha384; boundary="B_3542800212_41856493" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-06_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1604060276 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: New Version Notification for draft-zauner-tls-aes-ocb-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 19:11:11 -0000 --B_3542800212_41856493 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 4/6/16, 14:54 , "Ted Krovetz" wrote: >An RFC for OCB was approved in 2014. https://tools.ietf.org/html/rfc7253 Excellent! I=E2=80=99m happy to hear that. ;) The question remains: should these two definitions be brought to sync? I seem to recall that we=E2=80=99ve had quite a bit of discussion about the nonce for OCB=E2=80=A6 Perhaps you want to take it with Aaron offline?=20 --B_3542800212_41856493 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ4AYJKoZIhvcNAQcCoIIQ0TCCEM0CAQExDzANBglghkgBZQMEAgIFADALBgkqhkiG9w0B BwGggg6fMIIE6jCCA9KgAwIBAgIKMztKZQAAAABumTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzMzN1oXDTE5MDExMzE3MzMzN1ow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDqifs8K0OoodbmOo5G/j2+p2ibbOsEoJ9GJjK8K1Iw 6iig59a3EuNB6NR4tAR3INwjjUwMCa4o8ysnk1hN32B3HPrK5Z8++Y/xcX5iP1L6fc51YQ5C /EGvrSbjuPLvt19SNfVdwcuoc842Sgk9N/HemdwmvcqJkwzWDsuxKikI2clT1N5LTAaPMkhr HVuYOHBE0mCXjHjFnYuHsEXyVvUZLxziDgduV9WKbC90Z1NZMXB6ZeQTACUWgMfpFrE12LKb fvOmxepCBfCPbGB3ZyG+FaUdtQoCEAbGTnY7nCedQFn7pV1hppCt4jjLVlOpgYc3dPmyiXsL nhDQZ5ptmks/AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUiXqPublGfd0sWKNk/BObT6Oorzgw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAK7HM6o1IolvkCJrlsjj N1+0Z2JG8anwkHkVKAg/K9qUD0LE9zbnK3kZRGZsljJUDG+hMWmTWCkx0TTzbg/BeVrypVPD 7rn1Tagi9QBV2eJhdBZRHWOcsteRldUukKbMw74hkNGH9o/p/FFZYMA0kHnA7XfECilF9Yl6 uKDv1lbjuWdgcKD1FdEj7rL/IdX0wKJVUKjwLG1RQZel1nuwyRjVtXWz8IUMJXRsYHf6uSzy YoNBeZuWyMx/J5c0ACKXXs1O721GPJ5U5gcEaQ/b8lwQGcOgPk28RPwgiBF3f5TgrTa7QxGf ozmNsTj1OV1vU0vjqKrg7USi9q0xTdGUIyowggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIE7TCCA9WgAwIBAgIKMziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJV UzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYD VQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBl b3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4cot eDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4 u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n 2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh 6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQV ubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEE WjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYI KwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAu BiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUE HjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV 2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwX ENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2Pz BkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvv k0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa 1Vshx7ElBIk0cXhep6mLMLqGNX3azAkxggIFMIICAQIBATBfMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTMCCjM7SmUAAAAAbpkwDQYJYIZIAWUDBAICBQCgeTA/BgkqhkiG9w0BCQQx MgQweQF/XT4E/krWTYs0kO7bwepNoJbxChxHskg3CA45e0VQyEvTwCG9mwEVWRsfvXysMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDQwNjE5MTAxMlow DQYJKoZIhvcNAQEBBQAEggEAkA4FECFB7dFvz3XXanmfengbcnAi0Ee0P9FwnC39w/w14WHE yysCtAYUtFq0Z57yeUIh5HQy4StDGj+OIvCqm7v/Z4U2f3QUJLsHDYWNUWHC+S9Sx+mgGV/7 QoI8tXVonfxbgEjUoW9hlCVQ3N1oUTj/qhuZHR9lzm8gulFXVj4qlCzGaRk8RmqrNjRkjoVm xss/7r7rxSX2B54B4seCloMettNw1G4IrczhafJYTughQKWlVkU5VX0tVabMUBpd00ShC2x5 WNzjsmp0zDWRfYMyIdX5UMWe0wo4kVdQUrBVNemYYrgU6BygG3iTwRvr//HtyAHqaoEVH5i5 62hQdA== --B_3542800212_41856493-- From nobody Thu Apr 7 06:13:58 2016 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 545B412D95A for ; Thu, 7 Apr 2016 06:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9vnZSKCM61L for ; Thu, 7 Apr 2016 06:13:54 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E27812D95B for ; Thu, 7 Apr 2016 06:13:53 -0700 (PDT) X-AuditID: c1b4fb2d-f79c06d000005960-43-57065d0fdaee Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 59.90.22880.F0D56075; Thu, 7 Apr 2016 15:13:52 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.106]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Thu, 7 Apr 2016 15:13:51 +0200 From: John Mattsson To: "TLS@ietf.org" Thread-Topic: New Version Notification for draft-mattsson-tls-ecdhe-psk-aead-04.txt Thread-Index: AQHRkMn7ULREmfDr5UOR6SFM4CecTJ9+KUMA Date: Thu, 7 Apr 2016 13:13:50 +0000 Message-ID: References: <20160407123533.19788.89216.idtracker@ietfa.amsl.com> In-Reply-To: <20160407123533.19788.89216.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: <600C37D3A9ADD045A8BDCA6FD7A69B75@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2J7lK5ALFu4wcnlrBafzncxOjB6LFny kymAMYrLJiU1J7MstUjfLoEro33dGuaCAyIVJ+59Y25g/CPcxcjJISFgIrHk9ms2CFtM4sK9 9UA2F4eQwBFGiaf/G1ghnMWMEi+7tjOCVLEJGEjM3dMAVMXBISKgKPHpczZIWFggRGLG9gcs ILaIQKjE56N9jBAlRhLP38iChFkEVCQ6f50DK+EVMJeYNe0/M4gtJOAo8WzGXLAbOAWcJC4e 2QW2iRHonu+n1jCB2MwC4hK3nsxngrhTQGLJnvPMELaoxMvH/1hBbFEBPYnbHWvZIeJKEiu2 XwI7gVlAU2L9Ln2IMdYS697dZYOwFSWmdD9khzhHUOLkzCcsExjFZyHZNguhexaS7llIumch 6V7AyLqKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzCqDm75rbuDcfVrx0OMAhyMSjy8CvtZ w4VYE8uKK3MPMUpwMCuJ8B4OZwsX4k1JrKxKLcqPLyrNSS0+xCjNwaIkzpsT+S9MSCA9sSQ1 OzW1ILUIJsvEwSnVwJgz8xjDiY2/plzuYmXmsW45doo3zKjJsDxllUF45uwDV2Q/3D/89Vl+ kI0MX/+KAql/j4ojbTYfy7q7R7vztUB3hJuOT+IFn33HJ1QYlt9zDhRZX7oyQ+4Qu9cVp5j2 DYpr9qqs90pMPxqyzejvap4QhsVBxvuSBdi0u1K8RBWCf++exz53gxJLcUaioRZzUXEiAEFv 18imAgAA Archived-At: Subject: [TLS] FW: New Version Notification for draft-mattsson-tls-ecdhe-psk-aead-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 13:13:56 -0000 SGksDQoNCkEgbWlub3IgdXBkYXRlLiBkcmFmdC1tYXR0c3Nvbi10bHMtZWNkaGUtcHNrLWFlYWQg aXMgYSBub3JtYXRpdmUgcmVmZXJlbmNlDQppbiBkcmFmdC1pZXRmLXRscy10bHMxMy0xMi4gVGhl IG5ldyB2ZXJzaW9uIC0wNCBpcyB1cGRhdGVkIHdpdGggdGhlIGNvZGUNCnBvaW50cyBmcm9tIGRy YWZ0LWlldGYtdGxzLXRsczEzLTEyLiBkcmFmdC1tYXR0c3Nvbi10bHMtZWNkaGUtcHNrLWFlYWQN CmRlZmluZXMgZWNkaGUtcHNrIGNpcGVoZXJzdWl0ZXMgZm9yIGJvdGggVExTIDEuMiBhbmQgVExT IDEuMy4NCg0KQ2hlZXJzLA0KSm9obg0KDQoNCk9uIDA3LzA0LzE2IDA5OjM1LCAiaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0Kd3JvdGU6DQoNCj4N Cj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWF0dHNzb24tdGxzLWVjZGhlLXBzay1hZWFk LTA0LnR4dA0KPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSm9obiBNYXR0c3Nv biBhbmQgcG9zdGVkIHRvIHRoZQ0KPklFVEYgcmVwb3NpdG9yeS4NCj4NCj5OYW1lOgkJZHJhZnQt bWF0dHNzb24tdGxzLWVjZGhlLXBzay1hZWFkDQo+UmV2aXNpb246CTA0DQo+VGl0bGU6CQlFQ0RI RV9QU0sgd2l0aCBBRVMtR0NNIGFuZCBBRVMtQ0NNIENpcGhlciBTdWl0ZXMgZm9yIFRyYW5zcG9y dA0KPkxheWVyIFNlY3VyaXR5IChUTFMpDQo+RG9jdW1lbnQgZGF0ZToJMjAxNi0wNC0wNw0KPkdy b3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+UGFnZXM6CQk2DQo+VVJMOiAgICAgICAgICAg IA0KPmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tYXR0c3Nvbi10 bHMtZWNkaGUtcHNrLWFlYWQtMDQuDQo+dHh0DQo+U3RhdHVzOiAgICAgICAgIA0KPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1hdHRzc29uLXRscy1lY2RoZS1wc2stYWVh ZC8NCj5IdG1saXplZDogICAgICAgDQo+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LW1hdHRzc29uLXRscy1lY2RoZS1wc2stYWVhZC0wNA0KPkRpZmY6ICAgICAgICAgICANCj5odHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbWF0dHNzb24tdGxzLWVjZGhlLXBz ay1hZWFkLTA0DQo+DQo+QWJzdHJhY3Q6DQo+ICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHNldmVy YWwgbmV3IGNpcGhlciBzdWl0ZXMgZm9yIHRoZSBUcmFuc3BvcnQNCj4gICBMYXllciBTZWN1cml0 eSAoVExTKSBwcm90b2NvbC4gIFRoZSBjaXBoZXIgc3VpdGVzIGFyZSBhbGwgYmFzZWQgb24NCj4g ICB0aGUgRXBoZW1lcmFsIEVsbGlwdGljIEN1cnZlIERpZmZpZS1IZWxsbWFuIHdpdGggUHJlLVNo YXJlZCBLZXkNCj4gICAoRUNESEVfUFNLKSBrZXkgZXhjaGFuZ2UgdG9nZXRoZXIgd2l0aCB0aGUg QXV0aGVudGljYXRlZCBFbmNyeXB0aW9uDQo+ICAgd2l0aCBBc3NvY2lhdGVkIERhdGEgKEFFQUQp IGFsZ29yaXRobXMgQUVTLUdDTSBhbmQgQUVTLUNDTS4gIFBTSw0KPiAgIHByb3ZpZGVzIGxpZ2h0 IGFuZCBlZmZpY2llbnQgYXV0aGVudGljYXRpb24sIEVDREhFIHByb3ZpZGVzIHBlcmZlY3QNCj4g ICBmb3J3YXJkIHNlY3JlY3ksIGFuZCBBRVMtR0NNIGFuZCBBRVMtQ0NNIHByb3ZpZGVzIGVuY3J5 cHRpb24gYW5kDQo+ICAgaW50ZWdyaXR5IHByb3RlY3Rpb24uDQo+DQo+ICAgICAgICAgICAgICAg ICAgDQo+ICAgICAgICANCj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPnN1Ym1pc3Npb24NCj51bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn Lg0KPg0KPlRoZSBJRVRGIFNlY3JldGFyaWF0DQo+DQoNCg== From nobody Thu Apr 7 06:19:20 2016 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 40C0512D113 for ; Thu, 7 Apr 2016 06:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCM-96QC8OvV for ; Thu, 7 Apr 2016 06:19:17 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6783F12D6B6 for ; Thu, 7 Apr 2016 06:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1460035159; x=1491571159; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Nxxgqia3F0kUY6r4a01XrIfqa0SKpdFTHyABgZngf5k=; b=o6+ibL318yVzJcB6rW/ASHprRFV2U6mS/0uTmGsD6oxdwAOZRFy/RBqo XgxOBpwIp1jISQ/Lz5lWzNQSCGAcI2Xz6Ufu3QrdpzqUBUpBtubUnUT5f XX9rZa9Yh0qvrgm4YFdMP8ne5bPZsJH1PVAAiD+xW6tXXmXMs4DWIOQCq Q9MR3eYH/nTaW/vtDfvf8h5fcLAbi28dlW5MWNhBY47GpOsTyuVCVNEpS CIRB9RIdfgzpYMpBba+WSNOyEY/st4iSdF/Q33C3rk7m2VznspYsZmSFv X/fR+tLMdPwK8V7ttP3unNq+BLqe9a46PdGCrb7ySYwKOCAfSQgssDO9N A==; X-IronPort-AV: E=Sophos;i="5.24,449,1454929200"; d="scan'208";a="78833897" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Apr 2016 01:19:17 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Fri, 8 Apr 2016 01:19:15 +1200 From: Peter Gutmann To: John Mattsson , "TLS@ietf.org" Thread-Topic: New Version Notification for draft-mattsson-tls-ecdhe-psk-aead-04.txt Thread-Index: AQHRkMn7ULREmfDr5UOR6SFM4CecTJ9+KUMAgABU5Wk= Date: Thu, 7 Apr 2016 13:19:14 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C44057@uxcn10-5.UoA.auckland.ac.nz> References: <20160407123533.19788.89216.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] New Version Notification for draft-mattsson-tls-ecdhe-psk-aead-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 13:19:19 -0000 John Mattsson writes:=0A= =0A= >A minor update. draft-mattsson-tls-ecdhe-psk-aead is a normative reference= =0A= >in draft-ietf-tls-tls13-12. =0A= =0A= And it'll be a reference for TLS-LTS, since it fills the gap for the missin= g=0A= TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256.=0A= =0A= Peter.= From nobody Thu Apr 7 07:37:21 2016 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 F0E0B12D96D for ; Thu, 7 Apr 2016 07:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vFgxmhQmZ8z for ; Thu, 7 Apr 2016 07:37:19 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 272D412D96C for ; Thu, 7 Apr 2016 07:22:02 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 93132F2403D; Thu, 7 Apr 2016 10:22:01 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id mtA5dX5LvWg5; Thu, 7 Apr 2016 10:07:24 -0400 (EDT) Received: from dhcp-b4d9.meeting.ietf.org (dhcp-b4d9.meeting.ietf.org [31.133.180.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 6C76BF24036; Thu, 7 Apr 2016 10:22:00 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Thu, 7 Apr 2016 10:21:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Maarten Bodewes X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF TLS Subject: Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 14:37:21 -0000 I would prefer to always use the full, known-length byte string for Z. = In my experience, it is better to know the lengths of byte strings = instead of stripping leading zeroes. The difference in the speed of the = HKDF computation by omitting the leading zeros is not significant. = Alignment with NIST SP 800-56A is nice, but it is not the reason for my = preference. Russ On Mar 28, 2016, at 11:56 AM, Maarten Bodewes = wrote: > Hi all, >=20 > I see that the leading zero is stripped off of the value of Z (the = shared secret) before it is used as input to HKDF. This seems to be = compatible with TLS 1.2. Then again, it is not compatible with e.g. = NISP800-56A which uses the value of Z with the same size of the prime in = octets. Furthermore, it is also different with regards to handling the = coordinate X as used in ECDH. >=20 > Was this a conscious decision to keep compatibility with TLS? Has the = use of the value of Z including zero octets been considered? >=20 > Regards, > Maarten From nobody Thu Apr 7 08:35:30 2016 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 A21FC12D4FD for ; Thu, 7 Apr 2016 08:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lTRtCwm1OHZ for ; Thu, 7 Apr 2016 08:35:27 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D4C12D119 for ; Thu, 7 Apr 2016 08:32:46 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id t129so17526727vkg.2 for ; Thu, 07 Apr 2016 08:32: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; bh=XLxG/hhea9j9ZgI2DbEUU7JoKR3VDLmS8GT2JBnjZCU=; b=cxU8Lqembm0rgN/CkdfwVAcerptK0koXVLw8/Yvo1wnEHOpq2TkJp//O+2jVLWl63U BU9LlmpWkqE/DkKFkqXojS1OZ9IUYFenXXISUcD1DPT3zZL8tuN8er30fUBpe+0p8JQV Xks6MOR8wNyrxMmZnpxWsbbAP/4ckwXYTNNGjslwrJWdNvrFuYlEubL88DBQ6E5WAuKF ULk8qBDASYCwke29KsSx9EvdoBSfsUzu8wmK3FqcA+1ce40bQU4gUo9W2EPDXAmjcIpl XQe9A7cnRYwNAp8m3FEf4nJqWB98gbvQXnFKY+bIIJQ6qI6qxqRnwIeTwxGcx3EAlLHP pyhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=XLxG/hhea9j9ZgI2DbEUU7JoKR3VDLmS8GT2JBnjZCU=; b=k6gnU6oFunAZ84eFdN/1Bd4dRcI5Rza17RMl1F9G9c6VuhZb21aMytOJb4BKpvCyfR XspBuofCOtVMaSv0y559C/VEKSdvGfyiPx0tlMwo9nk7w9FodTmlkVCKWhyHduW/M8gV 7tR4N/RYsSdNcOW0oXl4z1UzC0jGvJO4AlcTYEtU3MvboIjwnn27BdJWn3ihpymDte7N JMUaXXGCYqvcJy4uBua+XosQ4F55iOtAG9xDGGNxT0mQrjL4sun1Z63vN303eq0kMrFq agfwyWJzWpHrsB5DpHRQWjJQSqzUfWMlXvmtEZslgEawObveljhbklSj5XYCoBdwEdOu FMIQ== X-Gm-Message-State: AD7BkJKsItf7dobvLdJlwRIe8vFBsp3J6Wc+flaXx0JEpesVmiQ/CuaI7Yso+5TMYBxqVBWlL6jxq/oM6GxwCP/Q MIME-Version: 1.0 X-Received: by 10.159.38.15 with SMTP id 15mr1740559uag.34.1460043165296; Thu, 07 Apr 2016 08:32:45 -0700 (PDT) Received: by 10.31.179.1 with HTTP; Thu, 7 Apr 2016 08:32:45 -0700 (PDT) In-Reply-To: <974CF78E8475CD4CA398B1FCA21C8E995650125D@PRN-MBX01-4.TheFacebook.com> References: <9d1de55db58e33f7e564a03bc140cb49.squirrel@www.trepanning.net> <974CF78E8475CD4CA398B1FCA21C8E995650125D@PRN-MBX01-4.TheFacebook.com> Date: Thu, 7 Apr 2016 08:32:45 -0700 Message-ID: From: Bill Cox To: Subodh Iyengar Content-Type: multipart/alternative; boundary=001a113e334e39c7fa052fe6ca79 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Call for consensus: Removing 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 15:35:29 -0000 --001a113e334e39c7fa052fe6ca79 Content-Type: text/plain; charset=UTF-8 I've been reviewing this issue because I want to help figure out how to do token binding over TLS 1.3 PKS 0-RTT. When the server emulates a session cache, then the RMS is unique on every PSK 0-RTT resumption. That means the client handshake hash is also unique, and it therefore becomes an attractive value for the purpose of signing. If we allow client auth in this mode, we gain some security. In particular, without access to the client cert private key, an attacker cannot resume a session, even if they have the RMS. Give this possible mode of operation, we may want to consider keeping client auth as an option in 0-RTT PSK resumption. Bill --001a113e334e39c7fa052fe6ca79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've been reviewing this issue because I want to help = figure out how to do token binding over TLS 1.3 PKS 0-RTT.=C2=A0 When the s= erver emulates a session cache, then the RMS is unique on every PSK 0-RTT r= esumption.=C2=A0 That means the client handshake hash is also unique, and i= t therefore becomes an attractive value for the purpose of signing.=C2=A0 I= f we allow client auth in this mode, we gain some security.=C2=A0 In partic= ular, without access to the client cert private key, an attacker cannot res= ume a session, even if they have the RMS.

Give this poss= ible mode of operation, we may want to consider keeping client auth as an o= ption in 0-RTT PSK resumption.

Bill
--001a113e334e39c7fa052fe6ca79-- From nobody Thu Apr 7 08:52:15 2016 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 402C212D0E9 for ; Thu, 7 Apr 2016 08:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FK54vSwdPkZD for ; Thu, 7 Apr 2016 08:52:12 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9002412D0C6 for ; Thu, 7 Apr 2016 08:52:12 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id e185so104549117vkb.1 for ; Thu, 07 Apr 2016 08:52:12 -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; bh=/cQsHdLBaCBvIEsCakWKTcol3WJlAux8DQ8NhdxnzwQ=; b=BIdoTBwzV4wC2BT9LP3LimG9jPPxeCGTujmkbJNzn3RtP001Z7QM+n6KqTnU+EPtqP /CvAHZ+ndzD8JJ+wdsqldEHrYdkHCKSaUGF6GovJO4G8Zc/2KAM6aeZPGRaRFCI8rLee 1m8p3Ps87hGTfWJskkTQo3PfzBUXIE78oXfGlM6X3O2l3x7PjUrWMNstoMuxOEbncwbA ISOd8010ZhkggIAulhgQc7pSNOR/3liuz/gkG0TyXrkIh1AzX4fPyBqzs5p/EvsedSZr wJFmnQo5qe6aLUWkWDFvh1fOLSDPYxo2wjnaa8IfWwVGOQaRFOeOP0maNKb9VSoOIpkq xtNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/cQsHdLBaCBvIEsCakWKTcol3WJlAux8DQ8NhdxnzwQ=; b=U+sGG8ql/yR0TFM7m0gN6GHzswYcrYo7uVhjYdMxy4Yp33MhUyN+cf4t2rdX3rjVXx WGAG1Zh3GxURk2gmMsmKCVrqDsZZ4GG82jSmFLs8oVyAqYfb/iH/RYhGSBm4xan7gPc4 UpQlqQHerjyzeH8fTA32Ad5A3eXpg7pzVS9lbKxb4Tpa3G3Hduy4c78h6qhWmrYLAmiV sBOeBIbRVvP0Ud3CM5D43QA7h4nz8ndQijCly0idokfBHDi6CMdqh5uoc1/tGqLGyp0c VVQhG5wvjIonbjyaVh9s2PRcUmzSvCSaVlBMCdCU+yMDxdaqD+H3Mpq1lmAXfXa19UET zvcA== X-Gm-Message-State: AD7BkJLuHWGLAJUe271CCN2kwDLNM0JfNStJwdcWaAOCc0T+kJRRPJduAyYMsEg2LFKSaCSchgiIFVlYL+CwVosF MIME-Version: 1.0 X-Received: by 10.31.180.213 with SMTP id d204mr1502991vkf.80.1460044331569; Thu, 07 Apr 2016 08:52:11 -0700 (PDT) Received: by 10.31.179.1 with HTTP; Thu, 7 Apr 2016 08:52:11 -0700 (PDT) In-Reply-To: References: <9d1de55db58e33f7e564a03bc140cb49.squirrel@www.trepanning.net> <974CF78E8475CD4CA398B1FCA21C8E995650125D@PRN-MBX01-4.TheFacebook.com> Date: Thu, 7 Apr 2016 08:52:11 -0700 Message-ID: From: Bill Cox To: Subodh Iyengar Content-Type: multipart/alternative; boundary=001a1144030ebda41c052fe70f89 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Call for consensus: Removing 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 15:52:14 -0000 --001a1144030ebda41c052fe70f89 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 7, 2016 at 8:32 AM, Bill Cox wrote: > I've been reviewing this issue because I want to help figure out how to do > token binding over TLS 1.3 PKS 0-RTT. When the server emulates a session > cache, then the RMS is unique on every PSK 0-RTT resumption. That means > the client handshake hash is also unique, and it therefore becomes an > attractive value for the purpose of signing. If we allow client auth in > this mode, we gain some security. In particular, without access to the > client cert private key, an attacker cannot resume a session, even if they > have the RMS. > > Give this possible mode of operation, we may want to consider keeping > client auth as an option in 0-RTT PSK resumption. > This brings up another issue: the client does not currently know if the server is running stateless or if it has some form of replay protection. It was proposed on another thread to add this information to the new ticket with a 1-byte type. I think this is a good idea. With replay protection, allowing client auth makes some sense. The server loses freshness, but not uniqueness of the signature, and uniqueness is the more important of the two properties IMO. Without replay protection, only the initial 1-RTT signature actually proves possession of the private key, so we should probably not allow client auth on PSK 0-RTT in that case and instead advise the client to secure the RMS well, since it can be used to resume authenticated sessions without the client private key. Without extending the ticket format to provide this information to the client, it will not be possible to make this differentiation, and either we will have to disallow all 0-RTT client auth for replay-resistant servers, or we will have to require all servers supporting 0-RTT to provide a client signature, even when running stateless. Given that stateless 0-RTT client auth does not prove possession of the private key, I would prefer not to allow it in that mode. Bill --001a1144030ebda41c052fe70f89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 7, 2016 at 8:32 AM, Bill Cox <waywardgeek@google.com><= /span> wrote:
I've b= een reviewing this issue because I want to help figure out how to do token = binding over TLS 1.3 PKS 0-RTT.=C2=A0 When the server emulates a session ca= che, then the RMS is unique on every PSK 0-RTT resumption.=C2=A0 That means= the client handshake hash is also unique, and it therefore becomes an attr= active value for the purpose of signing.=C2=A0 If we allow client auth in t= his mode, we gain some security.=C2=A0 In particular, without access to the= client cert private key, an attacker cannot resume a session, even if they= have the RMS.

Give this possible mode of operation, we = may want to consider keeping client auth as an option in 0-RTT PSK resumpti= on.

This brings up another issu= e: the client does not currently know if the server is running stateless or= if it has some form of replay protection.=C2=A0 It was proposed on another= thread to add this information to the new ticket with a 1-byte type.=C2=A0= I think this is a good idea.

With replay protecti= on, allowing client auth makes some sense.=C2=A0 The server loses freshness= , but not uniqueness of the signature, and uniqueness is the more important= of the two properties IMO.=C2=A0 Without replay protection, only the initi= al 1-RTT signature actually proves possession of the private key, so we sho= uld probably not allow client auth on PSK 0-RTT in that case and instead ad= vise the client to secure the RMS well, since it can be used to resume auth= enticated sessions without the client private key.=C2=A0 Without extending = the ticket format to provide this information to the client, it will not be= possible to make this differentiation, and either we will have to disallow= all 0-RTT client auth for replay-resistant servers, or we will have to req= uire all servers supporting 0-RTT to provide a client signature, even when = running stateless.=C2=A0 Given that stateless 0-RTT client auth does not pr= ove possession of the private key, I would prefer not to allow it in that m= ode.

Bill
--001a1144030ebda41c052fe70f89-- From nobody Fri Apr 8 13:50:43 2016 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 7DA3E12D62A for ; Fri, 8 Apr 2016 13:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8u66-KO2B79F for ; Fri, 8 Apr 2016 13:50:35 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222EE12D609 for ; Fri, 8 Apr 2016 13:50:35 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id c20so82339706pfc.1 for ; Fri, 08 Apr 2016 13:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to; bh=Nk96sPG9yqX+SWnebBjvi+4FLHA/ToXfqtus1VTlgnY=; b=Gxeu0FDMax14iNQtyR3ERlfoWOWMeRCEaigDshudLieWRTRw/PZbvraR+MBCAHNAPO 4rH0+qKYwyk0DwbL08drlSbA1LClHm45izAgPf3xOvoRbO+HU4SGXmQ0mQeRMeTvPcMV ZU0/QcKvCaHaP9Me+WK31HsItTWNKa3M9rg9qFqax7rYLP+ILRGf7zK8ZBiGBQ9xd72S 2LSgE+sAKFf+Ub69PLhQtZAwSW6+QV6jH7Y1Wxwi+BJmq3pc+T1k3RXkt+2ccRbO9Kn/ Radf8IlrIRmr3epui0ryqPSyhQaOeZJwpqqzJmQg67broLPnVH4S3cI9drVGSAlrhZ9u wsFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to; bh=Nk96sPG9yqX+SWnebBjvi+4FLHA/ToXfqtus1VTlgnY=; b=kSCTsV0eMrpJ+pPoVSKhPy6XnoZnodg46/bffAhN3xioDpzPTr9xVJmjIGBOaMOLAt 9pzJTQravkJT0PjITtUhrBrdU45CawHglZwfyRqqCvmeEACw4LjwODlp3zBjm8L3KH1K i5VnPiCCMPj6JOubO8HK9S03VP7+idF130tClQAKjuOJOp+98G/t7H0NCvrl67RItz2G nlFF16yIXXSVsxlj7+3jBLfy5DiyqHRMCPFPhB0fNazRGwCRKCy3/jUEcpJKfYQAke3B xcQffmK4ifkPDM6oM2wIIdQNcfwAOcGiU9CAwh6APQ+xSBD7lnRte4KP+d1/QbuZH8/N lcmg== X-Gm-Message-State: AD7BkJIEu2BwUpq1vhVX0z6iIsANqqwO3OhPi6zt7NauDJqd2jrALqTU4yjOhiW3e4PIGGl5DRdhs55RFtkUGg== MIME-Version: 1.0 X-Received: by 10.98.42.211 with SMTP id q202mr15201442pfq.13.1460148634577; Fri, 08 Apr 2016 13:50:34 -0700 (PDT) Sender: jim.roskind@gmail.com Received: by 10.66.13.98 with HTTP; Fri, 8 Apr 2016 13:50:34 -0700 (PDT) Date: Fri, 8 Apr 2016 13:50:34 -0700 X-Google-Sender-Auth: uxEGAL3kuR93o7O5Vnw_Jl_CIJ4 Message-ID: From: Jim Roskind To: IETF TLS Working Group Content-Type: multipart/alternative; boundary=001a1144d1beaef07a052fff58d2 Archived-At: Subject: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 20:50:40 -0000 --001a1144d1beaef07a052fff58d2 Content-Type: text/plain; charset=UTF-8 The combination of DHE and TLS 1.3 session resumption via session tickets, can destroy the forward secrecy property that DHE was intended to provide. With the proposed removal of DHE-based 0-RTT from TLS 1.3, session resumption is the mechanism by which 0-RTT connections are established. When adopted into QUIC, this will then be a reduction in security as compared with the current QUIC Crypto protocol, which rapidly steps all connections up to having forward secrecy immediately after a 0-RTT connection. The 0-RTT connection is extremely desirable for use in QUIC, because of the impact on connection latency, a known critical issues in all HTTP(S) content acquisition. Currently, at least 75% of all QUIC connections use 0-RTT, and then enjoy forward secrecy for the bulk of their communications. I would like TLS 1.3 to provide similar forward-secrecy guarantees after a 0-RTT connection. If a symmetric-session-ticket-decryption-key was compromised by a server, as a result of a break-in, or a subpoena, then all traffic that depended on the session resumption tickets would be at risk. Moreover, a third party attacker that possessed such a key, or planned to acquire a copy, could "encourage" traffic to use session resumption by disrupting any connection. A common use case involves having a large number of servers that must all be equally able to resume a connection. As a result, encrypted session tickets, protected by a server's symmetric secret key, are generally the preferred mechanism for resumption. Thanks for you consideration, Jim Roskind --001a1144d1beaef07a052fff58d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The combination of DHE and TLS 1.3 session res= umption via session tickets, can destroy the forward secrecy property that = DHE was intended to provide.=C2=A0 With the proposed removal of DHE-based 0= -RTT from TLS 1.3, session resumption is the mechanism by which 0-RTT conne= ctions are established. When adopted into QUIC, this will then be a reducti= on in security as compared with the current QUIC Crypto protocol, which rap= idly steps all connections up to having forward secrecy immediately after a= 0-RTT connection.

The= 0-RTT connection is extremely desirable for use in QUIC, because of the im= pact on connection latency, a known critical issues in all HTTP(S) content = acquisition.=C2=A0 Currently, at least 75% of all QUIC connections use 0-RT= T, and then enjoy forward secrecy for the bulk of their communications. I w= ould like TLS 1.3 to provide similar forward-secrecy guarantees after a 0-R= TT connection.

If a sy= mmetric-session-ticket-decryption-key was compromised by a server, as a res= ult of a break-in, or a subpoena, then all traffic that depended on the ses= sion resumption tickets would be at risk.=C2=A0 Moreover, a third party att= acker that possessed such a key, or planned to acquire a copy, could "= encourage" traffic to use session resumption by disrupting any connect= ion.=C2=A0

A common us= e case involves having a large number of servers that must all be equally a= ble to resume a connection. As a result, encrypted session tickets, protect= ed by a server's symmetric secret key, are generally the preferred mech= anism for resumption.

Thanks for you consideration,

Jim Roskind
--001a1144d1beaef07a052fff58d2-- From nobody Fri Apr 8 14:13:53 2016 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 6920C12D0F5 for ; Fri, 8 Apr 2016 14:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKB96UMxdcyS for ; Fri, 8 Apr 2016 14:13:49 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AF9912D0CD for ; Fri, 8 Apr 2016 14:13:49 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id e185so152853528vkb.1 for ; Fri, 08 Apr 2016 14:13:49 -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; bh=LL39BgPcTu4zV5aA4nf6DgG3iD3bg0IDxvAVFHvSN/Y=; b=Wz02GMET8nx1u3zW8KWXMyrFDfrUzXkVaB7Z6JkVFjOAi3bn9nU6gTelepazEjJqij HVYZpXmTFNX/un8GOfYB8QH/Krqe/yQMdN4XM9JWC2rLDrSSLHPq2zH+WlaGZPfOsuJf TnLR42EbM15V5CcaafSVAKmnlZn/EZmgEXCK1UJyjCCNTB0KCtwuBMcVKTEbfCbxaO7T mLFqUd4yg0zABcMgNuQiegIXvkyUjeCNt9McAl3CJttCFMcet5qkz/jIiI8FKxuA3ydJ 15b1gY9rnFfNnCLfx5yqfA//tnSUwa+vldFq2fEShsk2B3mtnG0H2w6RBEkafAN093Ic yeDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=LL39BgPcTu4zV5aA4nf6DgG3iD3bg0IDxvAVFHvSN/Y=; b=EWB8FnKhx+w8QV50ejJKDpAUQSdWNsG7u8Va2cQG++ZRTXaykrDqrjIj3INb7h7fN2 xz+b2rNai9R+7xvy2tYmeECIWmdgIXaPf7xwWGJuVfRIu47PYPV3ZVaWuU3/jKIOgM4X nmEtzqvbs93H9bFQkYgVPm9DoHg3yXEjBVVFg7LzXiS/L5atxas8ZW/fuPvBPVKv0bz5 nf7/lAM0D5HzcR+18H4XBoYq0FriukBZSVQNvxqKGTEm46p/MRYUWJmpJsBEnGh/T+lb IwrDz+YcICTTAyvZfKgTMG52O+XorASz3pVqAVBZ7sc/N6+1L/QH8uNF3XWDhmmujOIO T77w== X-Gm-Message-State: AD7BkJJiuyl8t0SQP6on6mNO/8dQHzEzKTFIKYkAfGSuIlE6aCtSBqGY4mOqAlkBEUYILvtubUl/rXeeZS9KzIYU MIME-Version: 1.0 X-Received: by 10.159.37.104 with SMTP id 95mr5216123uaz.85.1460150027939; Fri, 08 Apr 2016 14:13:47 -0700 (PDT) Received: by 10.31.179.1 with HTTP; Fri, 8 Apr 2016 14:13:47 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Apr 2016 14:13:47 -0700 Message-ID: From: Bill Cox To: Jim Roskind Content-Type: multipart/alternative; boundary=94eb2c123022bc4a41052fffabbe Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 21:13:51 -0000 --94eb2c123022bc4a41052fffabbe Content-Type: text/plain; charset=UTF-8 On Fri, Apr 8, 2016 at 1:50 PM, Jim Roskind wrote: > The combination of DHE and TLS 1.3 session resumption via session tickets, > can destroy the forward secrecy property that DHE was intended to provide. > With the proposed removal of DHE-based 0-RTT from TLS 1.3, session > resumption is the mechanism by which 0-RTT connections are established. > When adopted into QUIC, this will then be a reduction in security as > compared with the current QUIC Crypto protocol, which rapidly steps all > connections up to having forward secrecy immediately after a 0-RTT > connection. > I think I can accurately answer this: just use ephemeral keys during your resumption handshake. Then only the first flight 0-RTT packets lack PFS, just like with DHE 0-RTT. > The 0-RTT connection is extremely desirable for use in QUIC, because of > the impact on connection latency, a known critical issues in all HTTP(S) > content acquisition. Currently, at least 75% of all QUIC connections use > 0-RTT, and then enjoy forward secrecy for the bulk of their communications. > I would like TLS 1.3 to provide similar forward-secrecy guarantees after a > 0-RTT connection. > If you are only getting 75%, there is room for improvement :) I also would like as much PFS as we can afford. Running the server with a session cache enables PSK 0-RTT to have true PFS for all application data, even first flight 0-RTT data, but of course the session cache is expensive in several ways. Doing an ephemeral key exchange might be preferable in many cases, even with the loss of first-flight PFS. Just reiterating a point I think is important: the client needs to know whether the server has replay protection in this case. It may decide to use 1-RTT to have full PFS for all application data and real proofs of possession for client certs, or it might decide to send 0-RTT data in any case. However, we should advise clients not to send client certs and POST requests over PSK 0-RTT resumes during the first flight, IMO. I'd like to see tickets enhanced to enable the server to tell the client whether replay protection is in place on the server. Bill --94eb2c123022bc4a41052fffabbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 8, 2016 at 1:50 PM, Jim Roskind <JimRoskind@gmail.com> wrote:
The combination of DHE and TLS 1.3 session resumption via session tickets= , can destroy the forward secrecy property that DHE was intended to provide= .=C2=A0 With the proposed removal of DHE-based 0-RTT from TLS 1.3, session = resumption is the mechanism by which 0-RTT connections are established. Whe= n adopted into QUIC, this will then be a reduction in security as compared = with the current QUIC Crypto protocol, which rapidly steps all connections = up to having forward secrecy immediately after a 0-RTT connection.

I think I can accurately answer = this: just use ephemeral keys during your resumption handshake.=C2=A0 Then = only the first flight 0-RTT packets lack PFS, just like with DHE 0-RTT.
=C2=A0
The 0-RTT connection is extremely desirable for use in QUIC, because of= the impact on connection latency, a known critical issues in all HTTP(S) c= ontent acquisition.=C2=A0 Currently, at least 75% of all QUIC connections u= se 0-RTT, and then enjoy forward secrecy for the bulk of their communicatio= ns. I would like TLS 1.3 to provide similar forward-secrecy guarantees afte= r a 0-RTT connection.

If= you are only getting 75%, there is room for improvement :) =C2=A0I also wo= uld like as much PFS as we can afford.=C2=A0 Running the server with a sess= ion cache enables PSK 0-RTT to have true PFS for all application data, even= first flight 0-RTT data, but of course the session cache is expensive in s= everal ways.=C2=A0 Doing an ephemeral key exchange might be preferable in m= any cases, even with the loss of first-flight PFS.

Just reiterating a point I think is important: the client needs to know wh= ether the server has replay protection in this case.=C2=A0 It may decide to= use 1-RTT to have full PFS for all application data and real proofs of pos= session for client certs, or it might decide to send 0-RTT data in any case= .=C2=A0 However, we should advise clients not to send client certs and POST= requests over PSK 0-RTT resumes during the first flight, IMO.=C2=A0 I'= d like to see tickets enhanced to enable the server to tell the client whet= her replay protection is in place on the server.

B= ill
--94eb2c123022bc4a41052fffabbe-- From nobody Fri Apr 8 14:17:29 2016 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 3724712D599 for ; Fri, 8 Apr 2016 14:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2Y-WeSJAN2b for ; Fri, 8 Apr 2016 14:17:26 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 876A812D1CA for ; Fri, 8 Apr 2016 14:17:26 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id c4so152929381vkb.3 for ; Fri, 08 Apr 2016 14:17:26 -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; bh=h8bcJ3ZGAOHgvNrFM+7wZkNpj6CAeUyQ69EYBu3ECWg=; b=Pi7WKVJG0HQ12CYSkb/f5uHkL97EJEAmSk8n2eqHih4RHiKTqfB1fnLsbxeBddtN/A aNbTS8ShW3Kjr5Q4V8WKdIUT3Sy/Z/cZkTOO7go5/nxmt98Yxn94IEVJrthnwnxWRPN0 CvdpTH77DPCJJkc3k3pM9Lco2pvDf2RvG6r4xNfKlw0k0JbhOaBBlwSAUU30bXH3afQm 8vWtjqXXSFZsmhPw4WxFsoKpp0zEPAlbxT1E2xhvf5wj9weVK+6G5jui1JvbRVd1GeX/ UELHsuV6dxt0bE6YnsoQLVsfWY0QFgbq18s2+AlMZ6CDdKwLa86yjfyjFY770B/xv18Q GsQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=h8bcJ3ZGAOHgvNrFM+7wZkNpj6CAeUyQ69EYBu3ECWg=; b=Bk+EnGc6I6JSEgm+0yfzCZEcPvVwbnswelkNqCjT9NKwGkfbkSk1h77BRhhdnVEa1f diLLiT50L9xCKFxvhV6X8IPgcfKaWG+8C+9jTdTIBHu0c7RRr5/4FDAMmhOBDuOR+o29 ObVBoJHb8fI4VcC5xKFUV6astoBZMDiab01D6+BhUKVI074vHgD1FihKdS10t1ltvflb vj5y+3y1NFUARYsrYg+B4qAh1/4wUubYEpSJ0WZYeVE69Nl9k9c0C13E2KKIslBWbBRU rrin2KKmUAOBktjBnfJFWLhI88VEv39nolAxNaV6ti3gk7KVfKaevimeYD1kc9yZ5l77 HCVA== X-Gm-Message-State: AD7BkJKqsstDgU1o/1+iQGwU0YE8ifa3CFGbmRBYuzNrpCKW6ElIA13GU2HXIMLHTXfXTTkINOPBaA9WblI5/Kv0 MIME-Version: 1.0 X-Received: by 10.159.38.15 with SMTP id 15mr5291990uag.34.1460150245618; Fri, 08 Apr 2016 14:17:25 -0700 (PDT) Received: by 10.31.179.1 with HTTP; Fri, 8 Apr 2016 14:17:25 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Apr 2016 14:17:25 -0700 Message-ID: From: Bill Cox To: Jim Roskind Content-Type: multipart/alternative; boundary=001a113e334eb5c463052fffb885 Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 21:17:28 -0000 --001a113e334eb5c463052fffb885 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 8, 2016 at 2:13 PM, Bill Cox wrote: > However, we should advise clients not to send client certs and POST > requests over PSK 0-RTT resumes during the first flight, IMO. I'd like to > see tickets enhanced to enable the server to tell the client whether replay > protection is in place on the server. > Just clarifying: I meant client certs should not be sent over PSK 0-RTT resumption when the server has no replay protection. With replay protection, I'd probably recommend it. As the spec stands today, there is not quite enough information in the 1-RTT initial server reply for the client to figure out how to behave. Bill --001a113e334eb5c463052fffb885 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 8, 2016 at 2:13 PM, Bill Cox <waywardgeek@google.com><= /span> wrote:
However, we should advise = clients not to send client certs and POST requests over PSK 0-RTT resumes d= uring the first flight, IMO.=C2=A0 I'd like to see tickets enhanced to = enable the server to tell the client whether replay protection is in place = on the server.

Just= clarifying: I meant client certs should not be sent over PSK 0-RTT resumpt= ion when the server has no replay protection.=C2=A0 With replay protection,= I'd probably recommend it.=C2=A0 As the spec stands today, there is no= t quite enough information in the 1-RTT initial server reply for the client= to figure out how to behave.

Bill=C2=A0
--001a113e334eb5c463052fffb885-- From nobody Fri Apr 8 14:32:47 2016 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 CDC9712D6D5 for ; Fri, 8 Apr 2016 14:32: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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYMHkVzLH_sY for ; Fri, 8 Apr 2016 14:32:37 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1E612D1CA for ; Fri, 8 Apr 2016 14:32:36 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id d68so149650663ywe.1 for ; Fri, 08 Apr 2016 14:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kV9N6MsoILY3rOOayxLhhHzIIDyH5MNt1QCcqj28zAo=; b=NFAkgzuh+GrpU8BfpUBLlorxXduOTNvOHwExnefn1ta3xvNx7wcMxVhVZisjQShFjk 0nY0JyOPyVzUl1m+bOiv3OfWWV0PcNomiEFFfVfSBi9+/DFUecewfGC5dpN03JqWPYmd aXWEIVehrD4X463oJ5goNNawfHyTw9Ad+GgyXwB0PTGeR+Zf0gN2loh5yiTgqnxfMPw4 ujs/5zL2BQvlzM3/zuoDbA0EBxaTetmoab81YoE3KFyCm/zEzbEIRG+SR+eT+fhjzZtk s37SzI/JoQWUvAXzqxkdPnJviFslmgktYvN4GJPe/sV45zgsoVqkFRgR3i+o8EpOQNAL qksA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kV9N6MsoILY3rOOayxLhhHzIIDyH5MNt1QCcqj28zAo=; b=Jaa3a2gP/6LtSpxZ5zCMxxIeWM6iXwVPGvOifZ+IeSCJh6o3nenvUDZy/0macEBwEy 5SI9R/nBqRyG+/d/usjhx7oFKhompezSc/4Vrdn0IuaqAZws4iFPpPhWUd1S20tce32K ARRSgpMFZz+APaGCjp+jT6hBw0XgYYg9VWJ2vumG7mG0eCTQnNOXHhu2N++mYiMCuGxI 6C82QU7jqh0CI/UuDLaVxgkfkm5OfIs4s1rStBexOAhs2t0r7kmlqK/VvXasdBTflmRY GIrnOkCigBrAhoErfHKIajML4mT9/eoUt4qFaot5wjwZTVyFmqUozR7HsOLMJLZkPhhZ U0LQ== X-Gm-Message-State: AD7BkJLPaPsi08JXjinmjvrcsnd+0/TYiqsv4Ure31yFOOMgfgVuIJTOrn0uIhCstcty6PYVhn6Vlw26u8yCgA== X-Received: by 10.37.230.135 with SMTP id d129mr5965485ybh.74.1460151156056; Fri, 08 Apr 2016 14:32:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Fri, 8 Apr 2016 14:31:56 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 8 Apr 2016 18:31:56 -0300 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=94eb2c0a911af9d94f052fffee07 Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 21:32:46 -0000 --94eb2c0a911af9d94f052fffee07 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 8, 2016 at 6:13 PM, Bill Cox wrote: > On Fri, Apr 8, 2016 at 1:50 PM, Jim Roskind wrote: > >> The combination of DHE and TLS 1.3 session resumption via session >> tickets, can destroy the forward secrecy property that DHE was intended to >> provide. With the proposed removal of DHE-based 0-RTT from TLS 1.3, >> session resumption is the mechanism by which 0-RTT connections are >> established. When adopted into QUIC, this will then be a reduction in >> security as compared with the current QUIC Crypto protocol, which rapidly >> steps all connections up to having forward secrecy immediately after a >> 0-RTT connection. >> > > I think I can accurately answer this: just use ephemeral keys during your > resumption handshake. Then only the first flight 0-RTT packets lack PFS, > just like with DHE 0-RTT. > Quite so. TLS 1.3 supports two PSK-resumption modes: 1. Pure PSK, which has somewhat better security properties than in TLS 1.2 2. PSK-ECDHE, which has similar security properties to those of QUIC, i.e., no-PFS for the first flight and PFS for subsequent flights I think it would be good to encourage people to use mode #2, but there are obvious reasons why performance-sensitive implementations might opt for mode #1. -Ekr > Just reiterating a point I think is important: the client needs to know > whether the server has replay protection in this case. It may decide to > use 1-RTT to have full PFS for all application data and real proofs of > possession for client certs, or it might decide to send 0-RTT data in any > case. However, we should advise clients not to send client certs and POST > requests over PSK 0-RTT resumes during the first flight, IMO. I'd like to > see tickets enhanced to enable the server to tell the client whether replay > protection is in place on the server. > > Bill > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c0a911af9d94f052fffee07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 8, 2016 at 6:13 PM, Bill Cox <waywardgeek@google.com= > wrote:
<= div class=3D"gmail_extra">
On Fr= i, Apr 8, 2016 at 1:50 PM, Jim Roskind <JimRoskind@gmail.com> wrote:
The combination of DHE and TLS 1.3 session resumption via session tickets= , can destroy the forward secrecy property that DHE was intended to provide= .=C2=A0 With the proposed removal of DHE-based 0-RTT from TLS 1.3, session = resumption is the mechanism by which 0-RTT connections are established. Whe= n adopted into QUIC, this will then be a reduction in security as compared = with the current QUIC Crypto protocol, which rapidly steps all connections = up to having forward secrecy immediately after a 0-RTT connection.

I think I can accurately = answer this: just use ephemeral keys during your resumption handshake.=C2= =A0 Then only the first flight 0-RTT packets lack PFS, just like with DHE 0= -RTT.

Quite so. TLS= 1.3 supports two PSK-resumption modes:

1. Pure PS= K, which has somewhat better security properties than in TLS 1.2
= 2. PSK-ECDHE, which has similar security properties to those of QUIC, i.e.,=
no-PFS for the first flight and PFS for subsequent flights
=

I think it would be good to encourage people to use mod= e #2, but there are obvious
reasons why performance-sensitive imp= lementations might opt for mode #1.

-Ekr


Just reiterating = a point I think is important: the client needs to know whether the server h= as replay protection in this case.=C2=A0 It may decide to use 1-RTT to have= full PFS for all application data and real proofs of possession for client= certs, or it might decide to send 0-RTT data in any case.=C2=A0 However, w= e should advise clients not to send client certs and POST requests over PSK= 0-RTT resumes during the first flight, IMO.=C2=A0 I'd like to see tick= ets enhanced to enable the server to tell the client whether replay protect= ion is in place on the server.

Bill

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


--94eb2c0a911af9d94f052fffee07-- From nobody Fri Apr 8 14:38:43 2016 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 617B512D71E for ; Fri, 8 Apr 2016 14: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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEo3qsvZFREg for ; Fri, 8 Apr 2016 14:38:40 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 873A312D6DF for ; Fri, 8 Apr 2016 14:38:40 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id d68so149794405ywe.1 for ; Fri, 08 Apr 2016 14:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=TovJYj0TQ+8mYPPkYeFNhOMUO8k6ZbCzScVdP4t/j5k=; b=C7ESxlsNVElcE69kQ3tTLkyFt+5PkldxUF22H5hN5NNVQyHET2jWFaoCKdllCcZdEN tR8qpYd0CXDGJCS5g30VLm98/+EqYAPieidUAzhAmPymxoycXXi0Wbg4ELjIMc7GFhyl L3UtEEU32jkiA1INtkmciu9g/yCDud793QNPzcFa/EDtFadbpglF7wXzG0JFhHDtCOkv sFO7lamWtX2SnZy3M/naSS101Nn+9bD5XOQhfITXO3NrozRR0BL0znzDZ1OepdFPuKY8 YQ7ML43Nc/G3CDF1pgIu/RY08rqjCyogGuSXTJ4jiJbsZtMvKPrgwTc1o5bmvZAdOI8R O06A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=TovJYj0TQ+8mYPPkYeFNhOMUO8k6ZbCzScVdP4t/j5k=; b=g1KCT7IEbSLH3niS9Ni3WJm9yxRv33/jR81m/XsvbRQCKQAW5Cr0lWquDqtG1eH3Kn ui8yisLpMwvsQLN0idZ7VrLIUA+AZFVbd0/UR04qKzRM+gloq4W/PX3auxL39kIzs7wE 7eJ2Jn42CtzAhUNO81hmQcp0bGH8sHv/NPJsqHI1H1OhBBtL1Fbstl8n8A0uJelB6EW8 QjIL2v4L5gTj1lFLFONagPrPev/jO2Pv9CWZk7EyiYpHKYfMKjN00xILjd5GpvqNrUA3 M+PEYYbyJIjPfcT1uZEreTwwe5k05v3lcyV7SovYfjQLIBuSZL1NLSEDokSgU0R/jopg nDCg== X-Gm-Message-State: AD7BkJIYTvRtmnobMQgTge90UjFpKU68Xg+1s2mE3KZH47W3vy7+doymr4TJaRiElxaPZ4nCidNXi3+OSrJsRQ== MIME-Version: 1.0 X-Received: by 10.13.252.197 with SMTP id m188mr6067137ywf.281.1460151519755; Fri, 08 Apr 2016 14:38:39 -0700 (PDT) Received: by 10.129.88.86 with HTTP; Fri, 8 Apr 2016 14:38:39 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Apr 2016 14:38:39 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Jim Roskind Content-Type: multipart/alternative; boundary=94eb2c06c240a777d905300004b5 Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 21:38:42 -0000 --94eb2c06c240a777d905300004b5 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 8, 2016 at 1:50 PM, Jim Roskind wrote: > If a symmetric-session-ticket-decryption-key was compromised by a server, > as a result of a break-in, or a subpoena, then all traffic that depended on > the session resumption tickets would be at risk. Moreover, a third party > attacker that possessed such a key, or planned to acquire a copy, could > "encourage" traffic to use session resumption by disrupting any connection. > Why isn't your concern just as valid for the 0RTT itself though? If it's a URL it's entirely possible for it to be privacy sensitive, or to have some kind of bearer token in it. Or the 0RTT might have POST-like data, like maybe your credit card number. -- Colm --94eb2c06c240a777d905300004b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --94eb2c06c240a777d905300004b5-- From nobody Fri Apr 8 14:42:43 2016 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 A510612D628 for ; Fri, 8 Apr 2016 14:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMHekeleVY4N for ; Fri, 8 Apr 2016 14:42:41 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34D1F12D71F for ; Fri, 8 Apr 2016 14:42:41 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id i84so143782698ywc.2 for ; Fri, 08 Apr 2016 14:42: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; bh=YvC6NXFyu/Q45HgKdbsXoBX9ObWYktYAwZXi991X49E=; b=WiQ4guXajn64UUarb+xGu1BrEWqorR1a5LzaLO16qRL5IGs1vhn5vCplVycQXpOsqb J2EU4UQVAOwkybL0Yov/NQi9mzKehU16h48E2KTTyDz73z9YyNZrVqfIya0h+z6MTmen BVPSKHCUS4LkEsunnlX0MV/izK+0GPZ0xtZHr9E2NZ8i7SAx1VW2kqLOSKU2RlPtTLlN vdE8Qh9X7nRLdkCkq2gVGhXMY8GEUV3dPUjbEWCNWgNrP8M0sIkR/edGOG0+HBvsf372 gNfyknmGqn7mb452S1DbbgXoDJgvPPuMxzd/NiEiT/Tkv9EmXg8BOszp6gNpP03zgFKs EmRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=YvC6NXFyu/Q45HgKdbsXoBX9ObWYktYAwZXi991X49E=; b=UxcWXHELMQ4uadMLrdxMxtnlc0o3wFcN5uDUlliksDzt14i2mzvD9Vnb4sHSfdOEYL PXca5Z4wTqWKC6+UG2jcqiCQuNe/93GCyRcMdL9amEn9kKQA4sDkca1SnWNXSgJ83JQR E85CWVn3UwOxKoFjcP0dOY7OOyHxrAzJtJCAK41c6RAvERha+RH8+UszundPGlLU7lx0 xpOkMZzBrtUG97csWhxUG7JDp0aKBP9+75B7NaFB1Cg6MNJdiZFXWslfz1kDt0IRAcWa CzW6h/VzMGwnxSx3ZFpRP+hYMvfOYH/CwpuSZug8lz8xzjVeF5xQKvpVQlOg0lrBGk2P kOxw== X-Gm-Message-State: AD7BkJIgkxj0rqNcyZqH+ALYXJ7QmzKItNoqo+1YDvDR0u7uJ8aons2/l+JBo/RQnOvYHSsjjIKleVtzA5ZqpvRs MIME-Version: 1.0 X-Received: by 10.129.147.5 with SMTP id k5mr5585562ywg.206.1460151760367; Fri, 08 Apr 2016 14:42:40 -0700 (PDT) Received: by 10.37.113.67 with HTTP; Fri, 8 Apr 2016 14:42:40 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Apr 2016 14:42:40 -0700 Message-ID: From: Wan-Teh Chang To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 21:42:42 -0000 On Fri, Apr 8, 2016 at 2:31 PM, Eric Rescorla wrote: > > ... TLS 1.3 supports two PSK-resumption modes: > > 1. Pure PSK, which has somewhat better security properties than in TLS 1.2 > 2. PSK-ECDHE, which has similar security properties to those of QUIC, i.e., > no-PFS for the first flight and PFS for subsequent flights > > I think it would be good to encourage people to use mode #2, but there are > obvious > reasons why performance-sensitive implementations might opt for mode #1. I don't know why one wants to choose PSK-ECDHE resumption over ECDHE full handshake. Does PSK-ECDHE resumption have any advantage over ECDHE full handshake? Wan-Teh Chang From nobody Fri Apr 8 14:54:15 2016 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 87B3012D628 for ; Fri, 8 Apr 2016 14:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgxUMsrxds9q for ; Fri, 8 Apr 2016 14:54:12 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 080DB12D51C for ; Fri, 8 Apr 2016 14:54:12 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id o66so58951466ywc.3 for ; Fri, 08 Apr 2016 14:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C0L7Mto14UH+cBSrIBxv/DMqY+nufDrZaB3YOCRfSLs=; b=lMHwuBgg7XZTnQBkFLCyJMhxhBC/LPQTLOyfCnTtPhUZd5UxphScYcW0tpXOU3E6Jn oTtZN0NQTC3MV0uw4f4jVvNFrF1Fi0sllspIxp4xWLPDwr4DOv/+llVfqGUMSlv3GSPH HvXhxKAz5XYTg7Pw2ffOmggwTHQY40mNe7WKKUTqqox7q8vXxqJoCpHpLq19JvKYQRso +Lb0K94e+nGIwHCf6h6Hz42b8VLkdX4rzf8TkY5YYBYWHWgMh7wwLvLinJpvMxAthxQL Rw2bTUaMEcK4ynilewCDDv2/1rBd5fa8ThawfNsJaBdu9k+Sh3nbSaIWOC6B4XvuVUlI rAQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C0L7Mto14UH+cBSrIBxv/DMqY+nufDrZaB3YOCRfSLs=; b=gu06h5L19NhUQSn4nLcJBq8qSe9xi9UcyTU+kZ7Q9q2beNO3LdtX3ewtXnqf1+jf6r Y93WnEBd0+0mEnw4e2QHZ82u4JoOQD/gd/r5gAPm8FuMyBZyCpV5ObF2693YCOntoLMi P6hHZCdp3HH5b1rFqx5Rm9ESjwFWZfHLsah4JWQ0f/WVKjqVlTr64V31A6cGU5rWANDb 66QdQrQ8v8ijMzChPBnQF1/OCt5G4fA+bbAncry8JE9GlnLkq0iba/KjBgB7tSNi1OfI /EctyihWxuVY6650EZMeUZ22zJ0AMYzcj1k89eZHFg6heztWcZBb2iU89oxJp5KLS2GL sHLQ== X-Gm-Message-State: AOPr4FWZhQ6F5elqvuNalajezrqAa4vW7zMOMPb2EXs2Qy0j0z6CV6qW9XW3d7b67Daj3b8AV56AK+KAwqLP+w== X-Received: by 10.13.204.144 with SMTP id o138mr2325995ywd.192.1460152451265; Fri, 08 Apr 2016 14:54:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Fri, 8 Apr 2016 14:53:31 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 8 Apr 2016 18:53:31 -0300 Message-ID: To: Wan-Teh Chang Content-Type: multipart/alternative; boundary=001a114edcc82d4d4d0530003c81 Archived-At: Cc: IETF TLS Working Group Subject: Re: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 21:54:14 -0000 --001a114edcc82d4d4d0530003c81 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 8, 2016 at 6:42 PM, Wan-Teh Chang wrote: > On Fri, Apr 8, 2016 at 2:31 PM, Eric Rescorla wrote: > > > > ... TLS 1.3 supports two PSK-resumption modes: > > > > 1. Pure PSK, which has somewhat better security properties than in TLS > 1.2 > > 2. PSK-ECDHE, which has similar security properties to those of QUIC, > i.e., > > no-PFS for the first flight and PFS for subsequent flights > > > > I think it would be good to encourage people to use mode #2, but there > are > > obvious > > reasons why performance-sensitive implementations might opt for mode #1. > > I don't know why one wants to choose PSK-ECDHE resumption over ECDHE > full handshake. Does PSK-ECDHE resumption have any advantage over > ECDHE full handshake? Yes [0] 1. It has a significantly lower performance cost (especially if you have an RSA cert) 2. If you have done client authentication, then you can carry the state over between handshakes. 3. As it seems likely we are going to remove the (EC)DHE 0-RTT mode, this is how you do 0-RTT. -Ekr [0] For the sake of this discussion, I'm talking about resumption PSK when the server is authenticating with a cert. Obviously if you are using PSK-based authentication there are reasons why you would want to do this. --001a114edcc82d4d4d0530003c81 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 8, 2016 at 6:42 PM, Wan-Teh Chang <wtc@google.com> wrote:
On Fri, Apr 8, 2016 at 2:31 PM= , Eric Rescorla <ekr@rtfm.com> wr= ote:
>
> ... TLS 1.3 supports two PSK-resumption modes:
>
> 1. Pure PSK, which has somewhat better security properties than in TLS= 1.2
> 2. PSK-ECDHE, which has similar security properties to those of QUIC, = i.e.,
> no-PFS for the first flight and PFS for subsequent flights
>
> I think it would be good to encourage people to use mode #2, but there= are
> obvious
> reasons why performance-sensitive implementations might opt for mode #= 1.

I don't know why one wants to choose PSK-ECDHE resumption over E= CDHE
full handshake. Does PSK-ECDHE resumption have any advantage over
ECDHE full handshake?

Yes [0]
1. It has a significantly lower performance cost (especially if= you have an RSA cert)
2. If you have done client authentication,= then you can carry the state over between
handshakes.
= 3. As it seems likely we are going to remove the (EC)DHE 0-RTT mode, this i= s how you
do 0-RTT.

-Ekr

<= /div>


[0] For the sake of this discussion= , I'm talking about resumption PSK when the server
is authent= icating with a cert. Obviously if you are using PSK-based authentication th= ere
are reasons why you would want to do this.
<= /div> --001a114edcc82d4d4d0530003c81-- From nobody Fri Apr 8 18:26:21 2016 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 3656012D625 for ; Fri, 8 Apr 2016 18:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7P9YOsbY5ToD for ; Fri, 8 Apr 2016 18:26:17 -0700 (PDT) Received: from calvin.win.tue.nl (calvin.win.tue.nl [131.155.70.11]) by ietfa.amsl.com (Postfix) with SMTP id 627EA12D617 for ; Fri, 8 Apr 2016 18:26:17 -0700 (PDT) Received: (qmail 28516 invoked from network); 9 Apr 2016 01:26:39 -0000 Received: from ein.win.tue.nl (HELO hyperelliptic.org) (131.155.70.18) by calvin.win.tue.nl with SMTP; 9 Apr 2016 01:26:39 -0000 Received: (qmail 31508 invoked by uid 1004); 9 Apr 2016 01:26:38 -0000 Date: Sat, 9 Apr 2016 03:26:38 +0200 From: Tanja Lange To: tls@ietf.org Message-ID: <20160409012638.GT2556@ein.win.tue.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [TLS] [solworth@rites.uic.edu: TLS weakness in Forward Secrecy compared to QUIC Crypto] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 01:26:20 -0000 Looks like this didn't make it out to the list. Forwarding from my email address a message by Jon Solworth. ----- Forwarded message from "Jon A. Solworth" ----- Date: Fri, 8 Apr 2016 17:33:57 -0500 From: "Jon A. Solworth" To: tls@ietf.org, Tanja Lange , "D. J. Bernstein" , "W. Michael Petullo" Subject: TLS weakness in Forward Secrecy compared to QUIC Crypto It is not necessary to choose between either forward secrecy or low latency. It is possible to achieve both (and many other properties) as does MinimaLT. In MinimaLT, the current ephemeral key for the server is added to the DNS record fetched during the DNS lookup. These entries expire fairly quickly, ensuring that old keys are never used. The DNS lookup is necessary for other reasons, so there is no additional latency. This design avoids weak mechanisms and added complexity, two issues that cause enormous problems in security software. Jon Solworth ----- End forwarded message ----- From nobody Fri Apr 8 19:20:09 2016 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 EC41C12D527 for ; Fri, 8 Apr 2016 19:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5j_hu0gqOczf for ; Fri, 8 Apr 2016 19:20:02 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C3BC12D0EE for ; Fri, 8 Apr 2016 19:20:02 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id o66so63488239ywc.3 for ; Fri, 08 Apr 2016 19:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=inmLeLp2Xe1Z5pDxzQgxVPU4OguYX+GsAVL50yWFi7g=; b=mQQ9PnEqmCeX4XU7s9I69AEm0gqMPI7Wa0QvtRqaFzGvtmGTPB5I+GFxboZjmSXLnT cr1xI+sT7KlbhPRTfcVsYhGUd0qIUG36+q926iNGGHsxaqt12e/HtnUrSio/RKslyQRK OkfiFfHC3TJ6tAI4XUyPEE5QHRi8huSjRYe06kPLpWNfjxgU7bdhvlHedW2g/PnHMBvO jhIOr63V3qNyOm5JAiBa5/Q8YUC99G1b3Fh21GnP2UmSZG5rgrb9d0Cj+f79IUqL0iX3 gNd+MvfP4wvz24Imnf1+jkN64N75hw5fa0R0CfibqP1sBRZH1s/Vb8QU7aHwwqB1qGwL mdVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=inmLeLp2Xe1Z5pDxzQgxVPU4OguYX+GsAVL50yWFi7g=; b=Vmj/kAz7gaZ31sF5/eGQ6UfATRsAXXdeISrtNfU09rfd44ZCQBGMRBbbfFkFQu/b+A GFUaRrsBVkqvhJlsEjUNY7M5yodz6e88QN6yRqxAR/2uY1nHaFKXfFRq9iS13Pn13pMA jaPyn+KPyddEVqIemsCVPGodggaj4PL4dqjzRq6Vx2Coj4rGBZOq4mCbL9Ebkz/8qMpa uT9nnHd0o0RnFb3Uam0CCFTDU8g9fsGLqstURPAKhMOI/0pr/RjBT7/60pGCuakSxl4V NtQy1qrMVBikQMQoAugYx6wARzBP71mtm+aaBdFVTOdkU8sT925yRSiJPQe0QZpW7ux8 aHsw== X-Gm-Message-State: AD7BkJLMs+gM6hpxAfAFh701LvuQ18yfXaeXKY95+sHwxJeyQAw5M3qXwZafncqEH1+M0zHjREuuE0IO1bLYiw== X-Received: by 10.13.218.198 with SMTP id c189mr6618681ywe.165.1460168401576; Fri, 08 Apr 2016 19:20:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Fri, 8 Apr 2016 19:19:22 -0700 (PDT) In-Reply-To: <20160409012638.GT2556@ein.win.tue.nl> References: <20160409012638.GT2556@ein.win.tue.nl> From: Eric Rescorla Date: Fri, 8 Apr 2016 23:19:22 -0300 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c08192ae39488053003f2f1 Archived-At: Subject: Re: [TLS] [solworth@rites.uic.edu: TLS weakness in Forward Secrecy compared to QUIC Crypto] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 02:20:06 -0000 --94eb2c08192ae39488053003f2f1 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 8, 2016 at 10:26 PM, Tanja Lange wrote: > Looks like this didn't make it out to the list. Forwarding > from my email address a message by Jon Solworth. > > ----- Forwarded message from "Jon A. Solworth" > ----- > > Date: Fri, 8 Apr 2016 17:33:57 -0500 > From: "Jon A. Solworth" > To: tls@ietf.org, Tanja Lange , "D. J. Bernstein" > , "W. Michael Petullo" > Subject: TLS weakness in Forward Secrecy compared to QUIC Crypto > > It is not necessary to choose between either forward secrecy > or low latency. It is possible to achieve both (and many other > properties) as does MinimaLT. > > In MinimaLT, the current ephemeral key for the server > is added to the DNS record fetched during the DNS lookup. These entries > expire fairly quickly, ensuring that old keys are never > used. > > The DNS lookup is necessary for other reasons, so there > is no additional latency. > DNS-based priming is a seemingly attractive concept but unfortunately isn't really workable here, for several reasons: 1. It requires DNS security, which has relatively minimal deployment. We want 0-RTT to be available in TLS 1.3 even in environments without DNS security. 2. Measurements indicate that penetration rates for DNS records other than the basic ones that are necessary for nearly all operation (A, CNAME, etc.) are fairly poor, so this adds a number of operational problems. If you want to use short-lived ephemerals that are frequently refreshed in the DNS, thus providing forward secrecy you have the additional problem that most Web servers are not well integrated into the DNS server (one reason why Let's Encrypt initially launched with HTTP-based validation). With that said, if the deployment situation changes, it wouldn't be that hard to add a feature like this to TLS 1.3 in the future. Best, -Ekr > This design avoids weak mechanisms and added complexity, > two issues that cause enormous problems in security software. > > Jon Solworth > > ----- End forwarded message ----- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c08192ae39488053003f2f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


<= br>
On Fri, Apr 8, 2016 at 10:26 PM, Tanja Lange = <tanja@hyperelliptic.org> wrote:
Looks like this didn't make it out to the list. Forwardin= g
from my email address a message by Jon Solworth.

----- Forwarded message from "Jon A. Solworth" <solworth@rites.uic.edu> -----

Date: Fri, 8 Apr 2016 17:33:57 -0500
From: "Jon A. Solworth" <solworth@rites.uic.edu>
To: tls@ietf.org, Tanja Lange <tanja@hyperelliptic.org>, &quo= t;D. J. Bernstein"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <djb@cr.yp.t= o>, "W. Michael Petullo" <mike@flyn.org>
Subject: TLS weakness in Forward Secrecy compared to QUIC Crypto

=C2=A0 =C2=A0 =C2=A0 =C2=A0 It is not necessary to choose between either fo= rward secrecy
or low latency.=C2=A0 It is possible to achieve both (and many other
properties) as does MinimaLT.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 In MinimaLT, the current ephemeral key for the = server
is added to the DNS record fetched during the DNS lookup.=C2=A0 These entri= es
expire fairly quickly, ensuring that old keys are never
used.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The DNS lookup is necessary for other reasons, = so there
is no additional latency.

DNS-based pri= ming is a seemingly attractive concept but unfortunately isn't
really workable here, for several reasons:

1. It= requires DNS security, which has relatively minimal deployment. We want
0-RTT to be available in TLS 1.3 even in environments without DNS s= ecurity.

2. Measurements indicate that penetration= rates for DNS records other than the
basic ones that are necessa= ry for nearly all operation (A, CNAME, etc.) are
fairly poor, so = this adds a number of operational problems.


If you want to use short-lived ephemerals that are frequently refr= eshed in the
DNS, thus providing forward secrecy you have the= additional problem that
most Web servers are not well integrated= into the DNS server (one reason why
Let's Encrypt initially = launched with HTTP-based validation).

With that sa= id, if the deployment situation changes, it wouldn't be
that = hard to add a feature like this to TLS 1.3 in the future.

Best,
-Ekr






=C2=A0 =C2=A0 =C2=A0 =C2=A0 This design avoids weak mechanisms and added co= mplexity,
two issues that cause enormous problems in security software.

Jon Solworth

----- End forwarded message -----

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

--94eb2c08192ae39488053003f2f1-- From nobody Sun Apr 10 05:45:10 2016 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 386EF12D540 for ; Fri, 8 Apr 2016 15:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0S_c9iYFWfAx for ; Fri, 8 Apr 2016 15:34:03 -0700 (PDT) Received: from mail-5.cc.uic.edu (mail-5.cc.uic.edu [128.248.156.155]) by ietfa.amsl.com (Postfix) with ESMTP id 847F212D14D for ; Fri, 8 Apr 2016 15:34:03 -0700 (PDT) Received: from [10.137.2.7] (131-193-157-54.east.wireless.uic.edu [131.193.157.54]) (authenticated bits=0) by mail-5.cc.uic.edu (8.14.4/8.14.4) with ESMTP id u38MXwi5026042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 8 Apr 2016 17:33:58 -0500 To: tls@ietf.org, Tanja Lange , "D. J. Bernstein" , "W. Michael Petullo" From: "Jon A. Solworth" X-Enigmail-Draft-Status: N1110 Message-ID: <570831D5.2050300@rites.uic.edu> Date: Fri, 8 Apr 2016 17:33:57 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sun, 10 Apr 2016 05:45:08 -0700 Subject: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 22:34:05 -0000 It is not necessary to choose between either forward secrecy or low latency. It is possible to achieve both (and many other properties) as does MinimaLT. In MinimaLT, the current ephemeral key for the server is added to the DNS record fetched during the DNS lookup. These entries expire fairly quickly, ensuring that old keys are never used. The DNS lookup is necessary for other reasons, so there is no additional latency. This design avoids weak mechanisms and added complexity, two issues that cause enormous problems in security software. Jon Solworth From nobody Mon Apr 11 05:29:03 2016 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 38D4212ED9B for ; Mon, 11 Apr 2016 05:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.717 X-Spam-Level: X-Spam-Status: No, score=-3.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pklI0jd9lN6d for ; Mon, 11 Apr 2016 05:29:00 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id D5C2E12ED9A for ; Mon, 11 Apr 2016 05:29:00 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 30AF42000AE; Mon, 11 Apr 2016 12:29:00 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 18928200041; Mon, 11 Apr 2016 12:29:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1460377740; bh=QCzf0Bg0XJsCQcSKbOD1sYbtaJwlC+LIp8VriNY44IM=; l=497; h=From:To:Date:References:In-Reply-To:From; b=DKPPKHMkOy5DjjR0T4YZUdWxAcxOzxI77KgpIX/eNdtGjLmv2btvEyqVVWqwZpAuS wALusBs4OQldmqWNpwNK7zMQWwlbEVUukq4US0fqbuMkmZwd4kBYVg5BHzy0YkkhIt alT9pZAYA+mbzmC5/tRzkl5TPwqkaMwVBh3AINtc= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id EC9701E07C; Mon, 11 Apr 2016 12:28:59 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 11 Apr 2016 08:28:59 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Mon, 11 Apr 2016 08:28:59 -0400 From: "Salz, Rich" To: "Jon A. Solworth" , "tls@ietf.org" , Tanja Lange , "D. J. Bernstein" , "W. Michael Petullo" Thread-Topic: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto Thread-Index: AQHRkybTb63kxmht1UuE/DQSa8EA/J+EtHAg Date: Mon, 11 Apr 2016 12:28:58 +0000 Message-ID: References: <570831D5.2050300@rites.uic.edu> In-Reply-To: <570831D5.2050300@rites.uic.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.46.153] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 12:29:02 -0000 > In MinimaLT, the current ephemeral key for the server is added to > the DNS record fetched during the DNS lookup. These entries expire fairl= y > quickly, ensuring that old keys are never used. Can you compare the TTL of the ephemeral key record with the A/AAAA record = TTL? Are they related? If someone can get phony records into DNS, can the= y then become the real MLT server? For how long? -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz From nobody Mon Apr 11 06:05:15 2016 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 4CFC512D515 for ; Mon, 11 Apr 2016 06:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7u81hKVy-Sna for ; Mon, 11 Apr 2016 06:05:12 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7901D12D145 for ; Mon, 11 Apr 2016 06:05:12 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 771E444414; Mon, 11 Apr 2016 15:05:10 +0200 (CEST) X-purgate-ID: 152705::1460379910-000073AB-CE874B6F/0/0 X-purgate-size: 982 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 4B3C640C35; Mon, 11 Apr 2016 15:05:09 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 294B21A48A; Mon, 11 Apr 2016 15:05:09 +0200 (CEST) In-Reply-To: To: "Salz, Rich" Date: Mon, 11 Apr 2016 15:05:09 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20160411130509.294B21A48A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "W. Michael Petullo" , "Jon A. Solworth" , "tls@ietf.org" , "D. J. Bernstein" Subject: Re: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 13:05:14 -0000 Salz, Rich wrote: >> In MinimaLT, the current ephemeral key for the server is added to >> the DNS record fetched during the DNS lookup. These entries expire fairly >> quickly, ensuring that old keys are never used. > > Can you compare the TTL of the ephemeral key record with the > A/AAAA record TTL? Are they related? If someone can get phony > records into DNS, can they then become the real MLT server? For how long? Admittedly I don't know anything about MLT, but your question indicates what might be a serious misunderstanding about DNSSEC. The TTL of a DNS record is *NOT* protected by DNSSEC, and can be regenerated at will by an attacker, will be regenerated by intermediate DNS server and its purpose is purely cache-management, *NOT* security. Only the "Signature Expiration" information in the RRSIG is protected by DNSSEC, and only that ensures expiry of information from DNS. https://tools.ietf.org/html/rfc4034#section-3.1 -Martin From nobody Mon Apr 11 07:52:34 2016 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 9377912DB89 for ; Mon, 11 Apr 2016 07:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.717 X-Spam-Level: X-Spam-Status: No, score=-3.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNCxeOCaXfYZ for ; Mon, 11 Apr 2016 07:52:28 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 864F912DD7B for ; Mon, 11 Apr 2016 07:52:27 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id EE1A92000B4; Mon, 11 Apr 2016 14:52:26 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id D799D2000B0; Mon, 11 Apr 2016 14:52:26 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1460386346; bh=7ijGwkTR/RvVgat6OPFhR3EhJMDw/ZJOU6QJlrTi5+4=; l=488; h=From:To:CC:Date:References:In-Reply-To:From; b=Au/+2+9FqHMb6Jq9NC+g/HD5G2NIYpzTfjlDn5HyQtRs3tugVm6QJHdXxGKUne6Yr AQQG5990JY0nP+VQgoJOpna1/GzSDb7daWk9RkoorB8IBjZyZZlyPLxjFY6gPDQSB7 F/QwUlF4Ilfds19CO5Z2E9pFpgkYzVckRqtkcpAA= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id BBDED1E07C; Mon, 11 Apr 2016 14:52:26 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 11 Apr 2016 10:52:26 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Mon, 11 Apr 2016 10:52:26 -0400 From: "Salz, Rich" To: "mrex@sap.com" Thread-Topic: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto Thread-Index: AQHRkybTb63kxmht1UuE/DQSa8EA/J+EtHAggABN3YD//73dwA== Date: Mon, 11 Apr 2016 14:52:26 +0000 Message-ID: References: <20160411130509.294B21A48A@ld9781.wdf.sap.corp> In-Reply-To: <20160411130509.294B21A48A@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.46.153] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "W. Michael Petullo" , "Jon A. Solworth" , "tls@ietf.org" , "D. J. Bernstein" Subject: Re: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 14:52:30 -0000 > > Can you compare the TTL of the ephemeral key record with the A/AAAA > > record TTL? Are they related? If someone can get phony records into > > DNS, can they then become the real MLT server? For how long? >=20 >=20 > Admittedly I don't know anything about MLT, but your question indicates > what might be a serious misunderstanding about DNSSEC. No, thanks, I understand that. I am asking only about the TTL's of the epehemeral key and what the risks/e= xposures are. From nobody Mon Apr 11 08:54:25 2016 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 0D51C12EFFD for ; Mon, 11 Apr 2016 08:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5Qxf2-a9WiN for ; Mon, 11 Apr 2016 08:54:22 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E72B12ED43 for ; Mon, 11 Apr 2016 08:54:22 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id EFF6D284D97 for ; Mon, 11 Apr 2016 15:54:20 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: <20160411130509.294B21A48A@ld9781.wdf.sap.corp> Date: Mon, 11 Apr 2016 11:54:19 -0400 Content-Transfer-Encoding: 7bit Message-Id: <4E3EEC39-6917-4B3D-973C-1DE3897E2009@dukhovni.org> References: <20160411130509.294B21A48A@ld9781.wdf.sap.corp> To: "tls@ietf.org" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] TLS weakness in Forward Secrecy compared to QUIC Crypto X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "tls@ietf.org" List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 15:54:24 -0000 > On Apr 11, 2016, at 9:05 AM, Martin Rex wrote: > > The TTL of a DNS record is *NOT* protected by DNSSEC, and can be > regenerated at will by an attacker, will be regenerated by intermediate > DNS server and its purpose is purely cache-management, *NOT* security. > > Only the "Signature Expiration" information in the RRSIG > is protected by DNSSEC, and only that ensures expiry of information > from DNS. This is largely wrong, RRSIG RRs carry an "original TTL" field and: https://tools.ietf.org/html/rfc4035#section-5.3.3 If the resolver accepts the RRset as authentic, the validator MUST set the TTL of the RRSIG RR and each RR in the authenticated RRset to a value no greater than the minimum of: o the RRset's TTL as received in the response; o the RRSIG RR's TTL as received in the response; o the value in the RRSIG RR's Original TTL field; and o the difference of the RRSIG RR's Signature Expiration time and the current time. So attackers cannot generate TTL values "at will", the TTL is bounded by the signed "original TTL". Of course if the attacker remains on path indefinitely, then he can replay a stale signed RRset until the RRSIG expires. -- Viktor. From nobody Mon Apr 11 09:46:28 2016 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 0837A12F164 for ; Mon, 11 Apr 2016 09:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFn75P-8frJN for ; Mon, 11 Apr 2016 09:36:45 -0700 (PDT) Received: from calvin.win.tue.nl (calvin.win.tue.nl [131.155.70.11]) by ietfa.amsl.com (Postfix) with SMTP id AB85E12F165 for ; Mon, 11 Apr 2016 09:36:39 -0700 (PDT) Received: (qmail 12333 invoked by uid 1017); 11 Apr 2016 16:37:03 -0000 Received: from unknown (unknown) by unknown with QMTP; 11 Apr 2016 16:37:03 -0000 Received: (qmail 22353 invoked by uid 1000); 11 Apr 2016 16:36:28 -0000 Date: 11 Apr 2016 16:36:28 -0000 Message-ID: <20160411163628.22351.qmail@cr.yp.to> From: "D. J. Bernstein" To: tls@ietf.org Mail-Followup-To: tls@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Mon, 11 Apr 2016 09:46:27 -0700 Subject: Re: [TLS] [solworth@rites.uic.edu: TLS weakness in Forward Secrecy compared to QUIC Crypto] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 16:36:47 -0000 Eric Rescorla writes: > DNS-based priming is a seemingly attractive concept but unfortunately isn't > really workable here, for several reasons: > 1. It requires DNS security No, it doesn't. MinimaLT sticks to the existing X.509 PKI for easy deployability. The same server key that you're using for HTTPS, the key where you've obtained a certificate from (say) Let's Encrypt, is also signing your MinimaLT ephemeral keys. (Improvements in DNS security can give _additional_ protection to MinimaLT beyond the X.509 PKI, whereas TLS doesn't have this feature, but this is not the main point.) You _do_ need to be able to automatically sign new ephemeral keys and drop the signed data into your DNS database. If you're not used to this level of automation---for example, if you've outsourced your DNS data to a company that provides only manual web-based DNS editing---then you might see this as a showstopper. But there are many other sites where this is a trivial level of scripting. The resulting latency improvement is huge---_always_ getting what 0RTT _sometimes_ gets. > 2. Measurements indicate that penetration rates for DNS records other > than the basic ones that are necessary for nearly all operation (A, > CNAME, etc.) are fairly poor, so this adds a number of operational > problems. I agree that the original goal of extensible "query types" in DNS (see RFC 1034, third paragraph) was ruined by poor implementation work (which was in turn encouraged by other aspects of the DNS protocol design, but let me not get sidetracked here), so trying to deploy new DNS "query types" creates operational problems. This does _not_ mean, however, that putting new applications into DNS creates operational problems. It simply means that one has to avoid the trap of thinking that new applications should encode their data as new DNS "query types". Sticking to the limited set of well-supported DNS "query types" is reasonably straightforward and eliminates all of the operational problems. Of course, the difference in encodings between DNS and TLS can produce differences in the number of packets used to send a long chain of large certificates. But it's an easy exercise to have DNS cache pretty much everything for long periods. The only thing that changes frequently is a new signature on a new ephemeral key. ---Dan From nobody Mon Apr 11 10:08:46 2016 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 931D512F12A for ; Mon, 11 Apr 2016 10:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ir3ScVGMCOtR for ; Mon, 11 Apr 2016 10:08:41 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D95412F110 for ; Mon, 11 Apr 2016 10:08:41 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id E4A5F284D97 for ; Mon, 11 Apr 2016 17:08:39 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: <20160411163628.22351.qmail@cr.yp.to> Date: Mon, 11 Apr 2016 13:08:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9DE2C398-4101-482A-A372-AF3B96FF65DB@dukhovni.org> References: <20160411163628.22351.qmail@cr.yp.to> To: tls@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] [solworth@rites.uic.edu: TLS weakness in Forward Secrecy compared to QUIC Crypto] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 17:08:44 -0000 > On Apr 11, 2016, at 12:36 PM, D. J. Bernstein wrote: >=20 > I agree that the original goal of extensible "query types" in DNS (see > RFC 1034, third paragraph) was ruined by poor implementation work = (which > was in turn encouraged by other aspects of the DNS protocol design, = but > let me not get sidetracked here), so trying to deploy new DNS "query > types" creates operational problems. I've been monitoring DANE TLSA adoption in SMTP for some time now, = including monitoring of domains where requests for the novel TLSA records = encountered misconfigured middle-boxes that drop the query. Initially (2 years ago), problems were widespread. Now problems are = rather rare and getting more so. Out of ~130,000 DNSSEC domains in my corpus, = only ~40 drop requests for TLSA records. Two years ago there were many = thousands out of a much smaller corpus. If TLSA is a canary for generic "exotic" RRtypes, we're increasingly in = good shape, at least for domains whose zones are signed. When one reports demonstrated problems caused by firewalls that are too = eager to "protect" DNS servers from "non-standard" DNS queries the issue is = generally dealt with. So the main obstacle to lack of support of new RRtypes is lack of use. = Make it compelling for DNS operators to support these (e.g. continue to receive = email, ...) and they will update their configurations accordingly. --=20 Viktor. From nobody Mon Apr 11 10:11:38 2016 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 309C812E1C2 for ; Mon, 11 Apr 2016 10:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaoP351B9tsw for ; Mon, 11 Apr 2016 10:11:35 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E8F212D0F6 for ; Mon, 11 Apr 2016 10:11:34 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id t10so217871311ywa.0 for ; Mon, 11 Apr 2016 10:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=bP/6p1+66Kjz+39rPRSMvcSdy7ZMbxVplIDluUaQ2H0=; b=mj33W/IG8KX7xKgd/ebjfzU15QxiX8lksXLB7Q6D3FLFzGE9UehRlFRLzj7uPCoUpA w9omntgbxI4QkJU9thBsk+ArV2+mLjPdfrkJxKqxnqtg6DJCimzoMGvtsHYg/Pw3WIHx RCdZzgeCpHC2lNHHzsCYahAgfjVy+3rndKvkII4dPsOrZK2YOIc9eKDi+wni9TUJmqKY yFkdujDfUbeut+etlbkcoaeM2gcd3Z8atPlZr1NhxhMuvQVBeNpEIQV+jKmisD51nVnq lLtg9Qe0vHhUNkSiMG1yQ1MAQ7y3OmMsVVCCM1GnaN5KF25jb6SZzRS+PPLwj8YVuj8j FChA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=bP/6p1+66Kjz+39rPRSMvcSdy7ZMbxVplIDluUaQ2H0=; b=Fiq7S8AR7dPs2HD7tcJrHrCb5MfY+bcjX78/eC5wjN9fc+VG0aRYl3guanmLq5rHvT FyM+X63gAU1pK613ddGmyhQrZ6Lg9XDEgjfgEDyrLjjD6HNFuUKAaDj+hJEMVb3WdNus rmFmJK22xfCYzTtFuAhACoE9AcepX0L7eKvuH+EKCM0HLSndAnl/F/4YebpLgM3pmZYR uWL0TpuRK8+mc5NbEH5wvCNjN2om9MaeYfKD5J8+qaHAQlYR4LmCgKe+g7CGJdSciAxI X5C4PfO3Jhqy36X1Nby4M/zO2iMFcNd5sgPtFog4rO29a8vl7Xs0vJWF1SSjfvWvTMvm mZPw== X-Gm-Message-State: AD7BkJK8PUaM4h+mjoGccwUrgX98jLUFKEafVPvEw0tMHnafMe2KdkBxXT33zz9b+kI9WVzU60/eddnHs0Dw6Q== X-Received: by 10.13.229.132 with SMTP id o126mr11217517ywe.254.1460394693749; Mon, 11 Apr 2016 10:11:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Mon, 11 Apr 2016 10:10:54 -0700 (PDT) In-Reply-To: <20160411163628.22351.qmail@cr.yp.to> References: <20160411163628.22351.qmail@cr.yp.to> From: Eric Rescorla Date: Mon, 11 Apr 2016 10:10:54 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c07f9f0f4221a053038a2df Archived-At: Subject: Re: [TLS] [solworth@rites.uic.edu: TLS weakness in Forward Secrecy compared to QUIC Crypto] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 17:11:37 -0000 --94eb2c07f9f0f4221a053038a2df Content-Type: text/plain; charset=UTF-8 On Mon, Apr 11, 2016 at 9:36 AM, D. J. Bernstein wrote: > Eric Rescorla writes: > > DNS-based priming is a seemingly attractive concept but unfortunately > isn't > > really workable here, for several reasons: > > 1. It requires DNS security > > No, it doesn't. MinimaLT sticks to the existing X.509 PKI for easy > deployability. The same server key that you're using for HTTPS, the key > where you've obtained a certificate from (say) Let's Encrypt, is also > signing your MinimaLT ephemeral keys. (Improvements in DNS security can > give _additional_ protection to MinimaLT beyond the X.509 PKI, whereas > TLS doesn't have this feature, but this is not the main point.) > Yes, this is a fair point. You _do_ need to be able to automatically sign new ephemeral keys and > drop the signed data into your DNS database. If you're not used to this > level of automation---for example, if you've outsourced your DNS data to > a company that provides only manual web-based DNS editing---then you > might see this as a showstopper. But there are many other sites where > this is a trivial level of scripting. The resulting latency improvement > is huge---_always_ getting what 0RTT _sometimes_ gets. Perhaps: Google's measurements indicate a very high rate of 0-RTT with QUIC (75%) without DNS-based priming. > > 2. Measurements indicate that penetration rates for DNS records other > > than the basic ones that are necessary for nearly all operation (A, > > CNAME, etc.) are fairly poor, so this adds a number of operational > > problems. > > I agree that the original goal of extensible "query types" in DNS (see > RFC 1034, third paragraph) was ruined by poor implementation work (which > was in turn encouraged by other aspects of the DNS protocol design, but > let me not get sidetracked here), so trying to deploy new DNS "query > types" creates operational problems. > > This does _not_ mean, however, that putting new applications into DNS > creates operational problems. It simply means that one has to avoid the > trap of thinking that new applications should encode their data as new > DNS "query types". Sticking to the limited set of well-supported DNS > "query types" is reasonably straightforward and eliminates all of the > operational problems. I'm not sure which query type you're assuming: the measurements I am referring to were taken with TXT records. To be clear: I wish this weren't true. Expecting to have some kind of out-out-band priming was one of the main reasons for having a DH-based 0-RTT mode in draft-12, but increasingly it just started to look like that wasn't viable. -Ekr --94eb2c07f9f0f4221a053038a2df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 11, 2016 at 9:36 AM, D. J. Bernstein <= djb@cr.yp.to> wrote:
Eric Rescorla writes:
> DNS-based priming is a seemingly attractive concept but unfortunately = isn't
> really workable here, for several reasons:
> 1. It requires DNS security

No, it doesn't. MinimaLT sticks to the existing X.509 PKI for ea= sy
deployability. The same server key that you're using for HTTPS, the key=
where you've obtained a certificate from (say) Let's Encrypt, is al= so
signing your MinimaLT ephemeral keys. (Improvements in DNS security can
give _additional_ protection to MinimaLT beyond the X.509 PKI, whereas
TLS doesn't have this feature, but this is not the main point.)

Yes, this is a fair point.


You _do_ need to be able to automatically sign new ephemeral keys and
drop the signed data into your DNS database. If you're not used to this=
level of automation---for example, if you've outsourced your DNS data t= o
a company that provides only manual web-based DNS editing---then you
might see this as a showstopper. But there are many other sites where
this is a trivial level of scripting. The resulting latency improvement
is huge---_always_ getting what 0RTT _sometimes_ gets.
Perhaps: Google's measurements indicate a very high rate of= 0-RTT with
QUIC (75%) without DNS-based priming.

<= /div>
=C2=A0
> 2. Measurements indicate that penetration rates for DNS records other<= br> > than the basic ones that are necessary for nearly all operation (A, > CNAME, etc.) are fairly poor, so this adds a number of operational
> problems.

I agree that the original goal of extensible "query types"= in DNS (see
RFC 1034, third paragraph) was ruined by poor implementation work (which was in turn encouraged by other aspects of the DNS protocol design, but
let me not get sidetracked here), so trying to deploy new DNS "query types" creates operational problems.

This does _not_ mean, however, that putting new applications into DNS
creates operational problems. It simply means that one has to avoid the
trap of thinking that new applications should encode their data as new
DNS "query types". Sticking to the limited set of well-supported = DNS
"query types" is reasonably straightforward and eliminates all of= the
operational problems.

I'm not sure whic= h query type you're assuming: the measurements I am
referring= to were taken with TXT records.

To be clear: I wi= sh this weren't true. Expecting to have some kind of out-out-band
=
priming was one of the main reasons for having a DH-based 0-RTT mode i= n
draft-12, but increasingly it just started to look like that wa= sn't viable.

-Ekr
--94eb2c07f9f0f4221a053038a2df-- From nobody Mon Apr 11 10:16:09 2016 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 ECD9B12F1CB for ; Mon, 11 Apr 2016 10:16: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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rr2HPb-jiA-f for ; Mon, 11 Apr 2016 10:16:06 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2710C12DAF5 for ; Mon, 11 Apr 2016 10:16:06 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id d68so217883398ywe.1 for ; Mon, 11 Apr 2016 10:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ERInFeBmLoHMjnLfh9Kq+mY1RNp5fHKh2K1UN4MsgSY=; b=pw/EfIXTP0I05egjW9EmuP0WtlCljTE1BUqDr6Ha2SgRU/t34Nn1cUbXg/JyCIEgXp RBbgJ8hyp0MnZSxqYbhgwx7XEgFqa3oP1F9z5/JmrekNlnRjIJWjwhdf8YiIRgDpOYha KaT9wIKIaSKkqq9PbTz19Ev6V+pIdJVmjW+KGhSCCLT+KRF3pDngewN9U7PZ+HVQRi6e 5DBULlvm8olN4DGQ5KqY9AIjo8E7frCVuxoyDAz8VNL1zhPyRaJXvVwDEuKgDX78mAkl T/L6nn/t68nvZnIjWX1iIYfhl/HblqU0J3F1uiD3b/6bMQzPS8oGljv/NdOIzM9YmFZO YJNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ERInFeBmLoHMjnLfh9Kq+mY1RNp5fHKh2K1UN4MsgSY=; b=gVDLZqlCFBPNSxQptYO1MImg/47cGMeGdDEpx0o2qsKy2WIERjQ9zYrtKiM3XpI0wW igNDYaNRQ/EZfehmDTBwD8NOW9iUKXQsfr7bueNfiVqp9T1B1CKX4MvpEjEGWM4HryZn hZxXUCaxpotd9oGVlYBL0ke//D033/ixKikOSDf9Hj/E/AjDhDkfxAQVcuRSO3rJGZ1P jLpcDnaFfrPDxA69WLQ2Nrd5ZaUJM97QYkFLtH7SZSpyFIKuvMdRy047/0uJGJpN7mxu LOAaJzuB5k10TwIxPeBXo6rQxMH62WuUsWDzQ1eYtbkAndK8EWOdhlKEBrGeCCozzwJw i94g== X-Gm-Message-State: AD7BkJJLweBPqHK9KSEYHAjjIklSEireRocVdvfnXRx/zOuFOZu/dodTtrP1fj5q0UWp0CKqJoFTnuNGOVBZYA== X-Received: by 10.37.231.85 with SMTP id e82mr12057466ybh.130.1460394965319; Mon, 11 Apr 2016 10:16:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Mon, 11 Apr 2016 10:15:25 -0700 (PDT) In-Reply-To: References: <20160411163628.22351.qmail@cr.yp.to> From: Eric Rescorla Date: Mon, 11 Apr 2016 10:15:25 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0b1c5023fd54053038b3d3 Archived-At: Subject: Re: [TLS] [solworth@rites.uic.edu: TLS weakness in Forward Secrecy compared to QUIC Crypto] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 17:16:08 -0000 --94eb2c0b1c5023fd54053038b3d3 Content-Type: text/plain; charset=UTF-8 To add one more point here: the WG was very uncomfortable with having any kind of long-term delegation mechanism, which a static signature of this type would be (though perhaps it would be a weaker form of attack if you required an online signature as part of the handshake, as draft-12 does, in which case the attack would be limited to the 0-RTT data). -Ekr On Mon, Apr 11, 2016 at 10:10 AM, Eric Rescorla wrote: > > > On Mon, Apr 11, 2016 at 9:36 AM, D. J. Bernstein wrote: > >> Eric Rescorla writes: >> > DNS-based priming is a seemingly attractive concept but unfortunately >> isn't >> > really workable here, for several reasons: >> > 1. It requires DNS security >> >> No, it doesn't. MinimaLT sticks to the existing X.509 PKI for easy >> deployability. The same server key that you're using for HTTPS, the key >> where you've obtained a certificate from (say) Let's Encrypt, is also >> signing your MinimaLT ephemeral keys. (Improvements in DNS security can >> give _additional_ protection to MinimaLT beyond the X.509 PKI, whereas >> TLS doesn't have this feature, but this is not the main point.) >> > > Yes, this is a fair point. > > > You _do_ need to be able to automatically sign new ephemeral keys and >> drop the signed data into your DNS database. If you're not used to this >> level of automation---for example, if you've outsourced your DNS data to >> a company that provides only manual web-based DNS editing---then you >> might see this as a showstopper. But there are many other sites where >> this is a trivial level of scripting. The resulting latency improvement >> is huge---_always_ getting what 0RTT _sometimes_ gets. > > > Perhaps: Google's measurements indicate a very high rate of 0-RTT with > QUIC (75%) without DNS-based priming. > > > >> > 2. Measurements indicate that penetration rates for DNS records other >> > than the basic ones that are necessary for nearly all operation (A, >> > CNAME, etc.) are fairly poor, so this adds a number of operational >> > problems. >> >> I agree that the original goal of extensible "query types" in DNS (see >> RFC 1034, third paragraph) was ruined by poor implementation work (which >> was in turn encouraged by other aspects of the DNS protocol design, but >> let me not get sidetracked here), so trying to deploy new DNS "query >> types" creates operational problems. >> >> This does _not_ mean, however, that putting new applications into DNS >> creates operational problems. It simply means that one has to avoid the >> trap of thinking that new applications should encode their data as new >> DNS "query types". Sticking to the limited set of well-supported DNS >> "query types" is reasonably straightforward and eliminates all of the >> operational problems. > > > I'm not sure which query type you're assuming: the measurements I am > referring to were taken with TXT records. > > To be clear: I wish this weren't true. Expecting to have some kind of > out-out-band > priming was one of the main reasons for having a DH-based 0-RTT mode in > draft-12, but increasingly it just started to look like that wasn't viable. > > -Ekr > --94eb2c0b1c5023fd54053038b3d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To add one more point here: the WG was very uncomfortable = with having any
kind of long-term delegation mechanism, which a static = signature of this type
would be (though perhaps it would be a wea= ker form of attack if you required
an online signature as part of= the handshake, as draft-12 does, in which case
the attack would = be limited to the 0-RTT data).

-Ekr

=

On Mo= n, Apr 11, 2016 at 10:10 AM, Eric Rescorla <ekr@rtfm.com> wrote:<= br>


On Mon, Apr 11, 2016= at 9:36 AM, D. J. Bernstein <djb@cr.yp.to> wrote:
Eric Rescorla writes:
> DNS-based priming is a seemingly attractive concept but unfortunately = isn't
> really workable here, for several reasons:
> 1. It requires DNS security

No, it doesn't. MinimaLT sticks to the existing X.509 PKI for ea= sy
deployability. The same server key that you're using for HTTPS, the key=
where you've obtained a certificate from (say) Let's Encrypt, is al= so
signing your MinimaLT ephemeral keys. (Improvements in DNS security can
give _additional_ protection to MinimaLT beyond the X.509 PKI, whereas
TLS doesn't have this feature, but this is not the main point.)

Yes, this is a fair point.


You _do_ need to be able to automatically sign new ephemeral keys and
drop the signed data into your DNS database. If you're not used to this=
level of automation---for example, if you've outsourced your DNS data t= o
a company that provides only manual web-based DNS editing---then you
might see this as a showstopper. But there are many other sites where
this is a trivial level of scripting. The resulting latency improvement
is huge---_always_ getting what 0RTT _sometimes_ gets.
Perhaps: Google's measurements indicate a very high = rate of 0-RTT with
QUIC (75%) without DNS-based priming.

=C2=A0
> 2. Measurements indicate that penetration rates for DNS records other<= br> > than the basic ones that are necessary for nearly all operation (A, > CNAME, etc.) are fairly poor, so this adds a number of operational
> problems.

I agree that the original goal of extensible "query types"= in DNS (see
RFC 1034, third paragraph) was ruined by poor implementation work (which was in turn encouraged by other aspects of the DNS protocol design, but
let me not get sidetracked here), so trying to deploy new DNS "query types" creates operational problems.

This does _not_ mean, however, that putting new applications into DNS
creates operational problems. It simply means that one has to avoid the
trap of thinking that new applications should encode their data as new
DNS "query types". Sticking to the limited set of well-supported = DNS
"query types" is reasonably straightforward and eliminates all of= the
operational problems.

I'm not su= re which query type you're assuming: the measurements I am
re= ferring to were taken with TXT records.

To be clea= r: I wish this weren't true. Expecting to have some kind of out-out-ban= d
priming was one of the main reasons for having a DH-based 0-RTT= mode in
draft-12, but increasingly it just started to look like = that wasn't viable.

-Ekr

--94eb2c0b1c5023fd54053038b3d3-- From nobody Mon Apr 11 14:48:45 2016 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 A2C4C12E2DA for ; Mon, 11 Apr 2016 14:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPuF4eqTr5RE for ; Mon, 11 Apr 2016 14:48:42 -0700 (PDT) Received: from excelsior.roeckx.be (excelsior.roeckx.be [IPv6:2a01:70:ffff:1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39AFF12F4A9 for ; Mon, 11 Apr 2016 14:48:42 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id CE83DA8A0268 for ; Mon, 11 Apr 2016 21:48:39 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id A2FBE1FE0218; Mon, 11 Apr 2016 23:48:39 +0200 (CEST) Date: Mon, 11 Apr 2016 23:48:39 +0200 From: Kurt Roeckx To: tls@ietf.org Message-ID: <20160411214839.GA16614@roeckx.be> References: <20160411163628.22351.qmail@cr.yp.to> <9DE2C398-4101-482A-A372-AF3B96FF65DB@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9DE2C398-4101-482A-A372-AF3B96FF65DB@dukhovni.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] [solworth@rites.uic.edu: TLS weakness in Forward Secrecy compared to QUIC Crypto] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 21:48:44 -0000 On Mon, Apr 11, 2016 at 01:08:39PM -0400, Viktor Dukhovni wrote: > > > On Apr 11, 2016, at 12:36 PM, D. J. Bernstein wrote: > > > > I agree that the original goal of extensible "query types" in DNS (see > > RFC 1034, third paragraph) was ruined by poor implementation work (which > > was in turn encouraged by other aspects of the DNS protocol design, but > > let me not get sidetracked here), so trying to deploy new DNS "query > > types" creates operational problems. > > I've been monitoring DANE TLSA adoption in SMTP for some time now, including > monitoring of domains where requests for the novel TLSA records encountered > misconfigured middle-boxes that drop the query. > > Initially (2 years ago), problems were widespread. Now problems are rather > rare and getting more so. Out of ~130,000 DNSSEC domains in my corpus, only > ~40 drop requests for TLSA records. Two years ago there were many thousands > out of a much smaller corpus. Don't you have to look at it the other way? From a client that's behind some broken box that tries to look up TLSA records? I would really hope that if someone deploys DNSSEC that their nameservers would actually support DNSSEC. But that doesn't mean that a client trying to look up the DNSSEC related records is able to. Kurt From nobody Tue Apr 12 20:07:26 2016 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 50CC112DBEC for ; Tue, 12 Apr 2016 20:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4wwV41iJB5A for ; Tue, 12 Apr 2016 20:07:23 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6A2512DBD7 for ; Tue, 12 Apr 2016 20:07:23 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AB994284DCA; Wed, 13 Apr 2016 03:07:22 +0000 (UTC) Date: Wed, 13 Apr 2016 03:07:22 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20160413030722.GD26423@mournblade.imrryr.org> References: <20160411163628.22351.qmail@cr.yp.to> <9DE2C398-4101-482A-A372-AF3B96FF65DB@dukhovni.org> <20160411214839.GA16614@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160411214839.GA16614@roeckx.be> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] [solworth@rites.uic.edu: TLS weakness in Forward Secrecy compared to QUIC Crypto] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 03:07:25 -0000 On Mon, Apr 11, 2016 at 11:48:39PM +0200, Kurt Roeckx wrote: > > Initially (2 years ago), problems were widespread. Now problems are rather > > rare and getting more so. Out of ~130,000 DNSSEC domains in my corpus, only > > ~40 drop requests for TLSA records. Two years ago there were many thousands > > out of a much smaller corpus. > > Don't you have to look at it the other way? From a client that's > behind some broken box that tries to look up TLSA records? Yes, that's a separate issue. I've been monitoring domains served by nameservers that support DNSSEC, but refuse TLSA RR queries. (which are DANE, not DNSSEC). > I would really hope that if someone deploys DNSSEC that their > nameservers would actually support DNSSEC. Some had significant issues with authenticated denial of existence, which was a DNSSEC implementation problem, the vast majority of these are now resolved. Others, were dropping TLSA RRs, which is not a DNSSEC issue, but breaks RFC 7672 opportunistic DANE TLS. That too is mostly addressed. > But that doesn't mean > that a client trying to look up the DNSSEC related records is able > to. What's under discussion here is not so much DNSSEC, but some hypothetical new RRtype to support 0-RTT data. It is true that I've not been monitoring client-side issues (home cable boxes, hotel networks, and the like), a lot more cats to herd on the client side, and not really relevant to MTA-to-MTA transport security. -- Viktor. From nobody Wed Apr 13 15:57:57 2016 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 275F712E344 for ; Wed, 13 Apr 2016 15:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oh6bs5j2q54Z for ; Wed, 13 Apr 2016 15:57:53 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53F9D12E2F8 for ; Wed, 13 Apr 2016 15:57:52 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id n3so101355941wmn.0 for ; Wed, 13 Apr 2016 15:57:52 -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; bh=w7jystQMqLBwYO4Vpoa/bEL41WbxK8sDW4baxqJJGmo=; b=NN/zRF5j+WfcV/CC+lBpSoy2pddgq3uEuYC4zaMgzIt04qTJi0BfjSbt6FmW7YgGYh p406KMKxAZTdyubs191voRqwFde8GNgt2MRSNYM6WAFHED38Rq9TSSUu9706J4byCoSD bFlHh+GA0HuYFwfN70nnAx7YQngJb9dly2AUyTAKwuqU9+ZLU4OIoYU1BXGILXV6aDQE S1JRQ4c7EWCieZo7IOA369yUtMUlh2ZOGyH1a7L0bCRvCZJYEXwiU4Cg3AAUoBzjnm6a O0ru+s5uybqRgLfLU2SLJuNd4MKnDQdqyruWMncBDNxLPXx+WajmR067sCmGNFM0lm4K W0yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=w7jystQMqLBwYO4Vpoa/bEL41WbxK8sDW4baxqJJGmo=; b=MQJqZCbRnKbQ8/2/4W4RIYeTG7jwyRThjcv5rNFCyggto10WxgEzY473gQ5LPZ1z4L fqybBZ7Bs6wV8edxkylzxHqZfJEJONAnQzG3FtNhFFGPMUDnj8lEO8BLTGH/OoMMIFNr jFSRYHe+JL6JR2654x0dbctXG/aAakvVSqo7neEyavJl8BfN/o8AyVnjvtAdcsck7WcT KyHHOca3awKNb/Y2TwJw2BdeWdsf5n0ixi0ZCr/l1+ls6hTuoBTwGIHE3Y7RkCB8EJni rOPZL3/21VFIpVNVVXsxsws39UNSU/fwYGPgM63tQPSOHA+Gjm1aVwFcZVbLRgjxgpeE WTxw== X-Gm-Message-State: AOPr4FWpnt12Kl0rumGyqn7vIxb/B3GFvW4+Ry1j+4+lGgIAN8T6JjeRB2VjZDKKAkb+n7+w9PFjxvbQ2lKvFJSo MIME-Version: 1.0 X-Received: by 10.194.178.233 with SMTP id db9mr12367377wjc.11.1460588270657; Wed, 13 Apr 2016 15:57:50 -0700 (PDT) Received: by 10.28.31.201 with HTTP; Wed, 13 Apr 2016 15:57:50 -0700 (PDT) In-Reply-To: References: <7B4301E9-0282-47A3-8824-5ACC2C61910F@gmail.com> <535576C4-F808-4937-946C-B53661F0645D@gmail.com> Date: Wed, 13 Apr 2016 15:57:50 -0700 Message-ID: From: Ryan Hamilton To: Tony Arcieri Content-Type: multipart/alternative; boundary=089e013d1a08096a5e053065b5cd Archived-At: Cc: "karthik@messengeruser.com" , "tls@ietf.org" Subject: Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 22:57:55 -0000 --089e013d1a08096a5e053065b5cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 29, 2016 at 10:18 PM, Tony Arcieri wrote: > On Mon, Mar 28, 2016 at 3:49 PM, Ryan Hamilton wrote: > >> =E2=80=8BWe (Chrome) definitely want this (sending cookies in 0-RTT requ= ests), >> and are doing this today with QUIC (which we can't wait to TLS 1.3-ify).= =E2=80=8B >> > > I went to RealWorldCrypto 2016 and saw the TLS track and all of the > analysis TLS 1.3 has received, and while it wasn't TRON, I can sympathize > with why you might want TLS 1.3, namely the extensive analysis it is > receiving as an up and coming cryptographic standard which is a clear > choice for academic researchers to focus on. > > That said, I really don't understand Google's excitement to switch from > QUIC's crypto to TLS 1.3. QUIC crypto seems like a much simpler and clean= er > protocol which fulfills many of the same goals as TLS, and while it hasn'= t > received as much scrutiny as TLS 1.3, it seems like it doesn't need as mu= ch > by design due to its relative simplicity. > > I also understand Facebook is adding QUIC-crypto-over-TCP support to > proxygen (there was also a talk at RWC2016) for use in their mobile apps = as > a stopgap for doing 0-RTT until such a time as 0-RTT ships in TLS 1.3. > > Can you speak to specific reasons why the Chrome team "can't wait to TLS > 1.3-ify" over QUIC, specifically reasons different from the ones I have > already highlighted above? > =E2=80=8BQUIC Crypto was created by Adam Langley at the start of the projec= t. I believe he has said that if TLS could have provided the functionality we needed (wanted) at the time, he would have used it. Maintaining two different crypto handshake paths is undesirable. There are a number of features in TLS that we don't have in QUIC crypto (client certificates, for example). We don't need them for the experiments/deployments we've run so far, but we'll need them if we want QUIC to ubiquitous. If we can get all of this "for free" from TLS, that sounds awesome.=E2=80=8B There is no way = Chrome is ever going to ship without TLS, so the choice we have is between TLS + QUIC Crypto, or just TLS. Just TLS sounds pretty good to me. I hope that helps. --089e013d1a08096a5e053065b5cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 2= 9, 2016 at 10:18 PM, Tony Arcieri <bascule@gmail.com> wrote:
On= Mon, Mar 28, 2016 at 3:49 PM, Ryan Hamilton <rch@google.co= m> wrote:
=E2=80=8BWe (Chrome) definitely want t= his (sending cookies in 0-RTT requests), and are doing this today with QUIC= (which we can't wait to TLS 1.3-ify). =E2=80=8B

I went to RealWorldCrypto 2016 and saw t= he TLS track and all of the analysis TLS 1.3 has received, and while it was= n't TRON, I can sympathize with why you might want TLS 1.3, namely the = extensive analysis it is receiving as an up and coming cryptographic standa= rd which is a clear choice for academic researchers to focus on.
=
That said, I really don't understand Google's excite= ment to switch from QUIC's crypto to TLS 1.3. QUIC crypto seems like a = much simpler and cleaner protocol which fulfills many of the same goals as = TLS, and while it hasn't received as much scrutiny as TLS 1.3, it seems= like it doesn't need as much by design due to its relative simplicity.=

I also understand Facebook is adding QUIC-crypto-= over-TCP support to proxygen (there was also a talk at RWC2016) for use in = their mobile apps as a stopgap for doing 0-RTT until such a time as 0-RTT s= hips in TLS 1.3.

Can you speak to specific reasons= why the Chrome team "can't wait to TLS 1.3-ify" over QUIC, s= pecifically reasons different from the ones I have already highlighted abov= e?

=E2=80= =8BQUIC Crypto was created by Adam Langley at the start of the project. I b= elieve he has said that if TLS could have provided the functionality we nee= ded (wanted) at the time, he would have used it. Maintaining two different = crypto handshake paths is undesirable. There are a number of features in TL= S that we don't have in QUIC crypto (client certificates, for example).= We don't need them for the experiments/deployments we've run so fa= r, but we'll need them if we want QUIC to ubiquitous. If we can get all= of this "for free" from TLS, that sounds awesome.=E2=80=8B There= is no way Chrome is ever going to ship without TLS, so the choice we have = is between TLS + QUIC Crypto, or just TLS. Just TLS sounds pretty good to m= e.

I hope that helps.

--089e013d1a08096a5e053065b5cd-- From nobody Wed Apr 20 23:07:35 2016 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 6535F12E06C for ; Wed, 20 Apr 2016 23:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rb0LKDH-CbMS for ; Wed, 20 Apr 2016 23:07:32 -0700 (PDT) Received: from tauceti.org.au (mail.tauceti.org.au [203.32.61.25]) by ietfa.amsl.com (Postfix) with ESMTP id 92F8412E034 for ; Wed, 20 Apr 2016 23:07:31 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=ppp-223-24-93-187.revip6.asianet.co.th; To: tls@ietf.org References: <20160404164526.15645.26001.idtracker@ietfa.amsl.com> <5194DF8B-DFF1-4E41-A93C-6A80D063E7B5@azet.org> From: Peter Dettman Message-ID: <57186E18.10207@bouncycastle.org> Date: Thu, 21 Apr 2016 13:07:20 +0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5194DF8B-DFF1-4E41-A93C-6A80D063E7B5@azet.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Authenticated-User: peter.dettman@bouncycastle.org Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-zauner-tls-aes-ocb-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2016 06:07:34 -0000 draft-zauner-tls-aes-ocb-04 is now implemented in BouncyCastle TLS, and I am looking for other implementations for interop testing. Regards, Pete Dettman On 6/04/2016 9:47 PM, Aaron Zauner wrote: > Hi, > > I've uploaded a new version of the OCB draft a few days ago. Major changes: > > - the nonce construction is now identical to the one from the chacha/poly draft to reduce risk of nonce misuse/reuse > - added a security considerations section on data limit under a single key (identical to GCM) > - IPR claims for TLS are now fully resolved as far as I can tell - the draft contains updated information on the issue > > I'm happy to receive any feedback/critique on the draft if anyone is interested in reviewing. > > BTW: Andy Polyakov has added AESNI optimized assembly for OCB to OpenSSL (https://github.com/openssl/openssl/commit/bd30091c9725bdad1c82bce10839f33ceaa5623b). C/B numbers are quite impressive, IMO. > > Thanks for your consideration, > Aaron From nobody Thu Apr 21 05:26:26 2016 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 93BED12EBC9 for ; Thu, 21 Apr 2016 05:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 228kgOQ1tO0I for ; Thu, 21 Apr 2016 05:26:23 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0C5C12EBB7 for ; Thu, 21 Apr 2016 05:26:22 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id n62so95892594vkb.0 for ; Thu, 21 Apr 2016 05:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=GlL6qWNDXVoiyWL5RZKXFwbjFh0yWbrIDqchXf2BqNk=; b=bC6y4fhfXzHre4s6Km/lBxaMBtAeBjguH+GoXkvH8z3YADDcQIOTkiMCnjGnual0CC uwJ76Mc5trVFXIDu9XOL08GbbUzrx2BEZ3u25m1aRc6P62HKYF6J7qImoq5r26lRb34L AV0rVdaqHPmejIsy0Iape63sQ+swhrCPMAZe4mJL4ORVk+VbSoAj1SaKNdI+fwTMc2Eb rN9uDZZSzc1IvN5WljsZYW1TsZgGMSB7burgDpEfgIlYgRI2W6y6NWIeM6a02S6QgYHV PC/KX32a2FU7OzFzpNPNAIcQBpz3a2JOy636KhxeJpVNyXZTByuXKNj6wTVXwJ2gA2Jo lYpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=GlL6qWNDXVoiyWL5RZKXFwbjFh0yWbrIDqchXf2BqNk=; b=bE/wEwMWB45CPG4P3gI8y/GVAbVo0LowRSOl6al3KOU7W09DY5Q+LXvI3Hbc/ZZz5d h9aaPp6+iNxY57Jc1IPcE2VZYz/o2eXAcdTOTNVo8dG+vt3FN4RtlWKXoIHeqQylBvF1 QMSC6x5NfFzEGpI4IZ6+Bg0xYC9ubCUUxex3zYlnNV66pwccpx0F+MD6AzIavX3Ue2Rb HvmB+BqWQ575HVC6DhqxP7JZ042PfDep+tuFPBlrO7R0OBQjazoqw13DyoqYtIAsSftn emMrdZ/22N/Y9vJYtcoGFZ/k6+QVuaNDmjdU0KzEE6/Wc02C2+1/GbHgr79eAlX9gH6u iL2w== X-Gm-Message-State: AOPr4FXSAAzlD2lgcHbKUUgDTreYSgccpUJKpWCjc2O97KN2bWxrME1CpziNhkSFOyUh1S/jy1dOFHjIQvrFeWxr MIME-Version: 1.0 X-Received: by 10.31.180.213 with SMTP id d204mr7063337vkf.80.1461241581791; Thu, 21 Apr 2016 05:26:21 -0700 (PDT) Received: by 10.31.209.196 with HTTP; Thu, 21 Apr 2016 05:26:21 -0700 (PDT) Date: Thu, 21 Apr 2016 05:26:21 -0700 Message-ID: From: Bill Cox To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1144030e6a3e9e0530fdd10f Archived-At: Subject: [TLS] Can we require extensions to be sorted? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2016 12:26:24 -0000 --001a1144030e6a3e9e0530fdd10f Content-Type: text/plain; charset=UTF-8 We did this in QUIC, and it is a major simplification. This is one feature I will be sad to loose when we switch to TLS 1.3 for the crypto in QUIC. I've worked on 3 extensions so far: EMS, channel ID, and token binding. We are not allowed to negotiate channel ID or token binding unless we also have negotiated EMS. If channel ID and token binding are both offered by the client, the best behavior is for servers supporting both is to pick token binding. Since token binding can be implemented as a custom extension, in current implementations it is negotiated after builtin extensions, but I cannot count on that when using the custom extension API. The logic required to deal with inter-extension dependencies is now so complex that TLS implementations are forced to pre-parse extensions, adding even more complexity and latency. Even so, that only lets extensions know that the others exist when processed (such as EMS when processing token binding), but it does not ensure that one extension has successfully been negotiated before processing another. This is a mess. Is it too late to modify the TLS 1.3 spec to require extensions to be sent in order of their tags? If we were to do so, I would recommend that we use a bit-reversal pattern for numbering official extensions when the order makes no difference, and when they do, put them in the middle between existing extensions. Some extensions, like token binding, are intended to be lightweight extensions that can be supported through a custom extension API. Such extensions should always come after the more complex builtin extensions, because built-in extensions are often processed in switch statements, while custom extensions have to be handled separately. It is most natural for these extensions to be parsed after builtin extensions, so maybe they should start with a 1, and builtin extensions should start with a 0. For example, if we had EXT1, EXT2, and EXT3 as official extensions with no specific ordering needs, and EXT1-2 that needs to come after EXT1, but was defined after EXT3, and TESTEXT2-1 that is still unofficial, but must come after EXT2, and CUSTEXT1 and CUSTEXT2, the tags might look like (in order of when they were defined): EXT1: 0 EXT2: 0x4000 EXT3: 0x2000 EXT1-2: 0x1000 TESTEXT2-1: 0x60a5 CUSTEXT1: 0x8000 CUSTEXT2: 0xc000 The 0x608a5 starts with 0x60 for ordering half way between 0x4000 and 0x8000, and has a random odd lower byte, 0xa5, to reduce accidental collisions between TLS implementations that happen to be experimenting with test extensions. The custom extensions follow a bit-reversal pattern in the range where the MSB is set. I'm not confident that we need to differentiate custom extensions here. QUIC does not. If we do, to help clarify the custom extension concept, these are extensions that: 1) can be processed with two callbacks: one for adding, one for parsing (which are different on client vs server) 2) do not keep any state between resumes, and are renegotiated 3) can be processed after builtin extensions The issue of extensions requiring state between resumes confuses me, so I'll send a separate email for help understanding it. Bill --001a1144030e6a3e9e0530fdd10f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We did this in QUIC, and it is a major simplification.=C2= =A0 This is one feature I will be sad to loose when we switch to TLS 1.3 fo= r the crypto in QUIC.

I've worked on 3 extensions so= far: EMS, channel ID, and token binding.=C2=A0 We are not allowed to negot= iate channel ID or token binding unless we also have negotiated EMS.=C2=A0 = If channel ID and token binding are both offered by the client, the best be= havior is for servers supporting both is to pick token binding.=C2=A0 Since= token binding can be implemented as a custom extension, in current impleme= ntations it is negotiated after builtin extensions, but I cannot count on t= hat when using the custom extension API.

The logic= required to deal with inter-extension dependencies is now so complex that = TLS implementations are forced to pre-parse extensions, adding even more co= mplexity and latency.=C2=A0 Even so, that only lets extensions know that th= e others exist when processed (such as EMS when processing token binding), = but it does not ensure that one extension has successfully been negotiated = before processing another.

This is a mess.=C2=A0 I= s it too late to modify the TLS 1.3 spec to require extensions to be sent i= n order of their tags?

If we were to do so, I woul= d recommend that we use a bit-reversal pattern for numbering official exten= sions when the order makes no difference, and when they do, put them in the= middle between existing extensions.=C2=A0 Some extensions, like token bind= ing, are intended to be lightweight extensions that can be supported throug= h a custom extension API.=C2=A0 Such extensions should always come after th= e more complex builtin extensions, because built-in extensions are often pr= ocessed in switch statements, while custom extensions have to be handled se= parately.=C2=A0 It is most natural for these extensions to be parsed after = builtin extensions, so maybe they should start with a 1, and builtin extens= ions should start with a 0.

For example, if we had= EXT1, EXT2, and EXT3 as official extensions with no specific ordering need= s, and EXT1-2 that needs to come after EXT1, but was defined after EXT3, an= d TESTEXT2-1 that is still unofficial, but must come after EXT2, and CUSTEX= T1 and CUSTEXT2, the tags might look like (in order of when they were defin= ed):

EXT1: 0
EXT2: 0x4000
EXT3= : 0x2000
EXT1-2: 0x1000
TESTEXT2-1: 0x60a5
CUSTEXT1: 0x8000
CUSTEXT2: 0xc000

= The 0x608a5 starts with 0x60 for ordering half way between 0x4000 and 0x800= 0, and has a random odd lower byte, 0xa5, to reduce accidental collisions b= etween TLS implementations that happen to be experimenting with test extens= ions.=C2=A0 The custom extensions follow a bit-reversal pattern in the rang= e where the MSB is set.

I'm not confident that= we need to differentiate custom extensions here.=C2=A0 QUIC does not.=C2= =A0 If we do, to help clarify the custom extension concept, these are exten= sions that:

1) can be processed with two callbacks= : one for adding, one for parsing (which are different on client vs server)=
2) do not keep any state between resumes, and are renegotiated
3) can be processed after builtin extensions

<= div>The issue of extensions requiring state between resumes confuses me, so= I'll send a separate email for help understanding it.

Bill
--001a1144030e6a3e9e0530fdd10f-- From nobody Thu Apr 21 06:12:44 2016 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 0607512DD08 for ; Thu, 21 Apr 2016 06:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bRM7pzyIg7e for ; Thu, 21 Apr 2016 06:12:42 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E17DA12D515 for ; Thu, 21 Apr 2016 06:12:41 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id n67so85061711vkf.3 for ; Thu, 21 Apr 2016 06:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=V+aZmC+JVuKNz0szAAdljLsELoDlAMt0EyMqYSMtEPk=; b=Tz72MQlNidwOFYZI6KZb3d1NPre1SmkQaVsmDK4YOGUqvUFHJhOI3S+gBrNhq/B8F3 WEohsascmKzPn4DxpXXc/gHoZMYobQs4V6nHXe8XPBucqlbBaPihJj2STfaQqIu4MmYP GsPOu0g8lsuokdupZxHDEZPD9nswpxYDPIo196KlqGCL9jARGNeRxSjMG87r5x4ldUAL 86Oc9CXxHSFpmXrxl2PsbwRzBD9S5IYeFj4+JxAUdYAf/9wfcQeKNiQzNBNP+5mrm6Ro 0gVzaewrcAe/l5c41VzUxhAcMLWY4hpVqRWTDOkBQ+WoVTfj61k0y2zaZFGN84qgv+eI 3FTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=V+aZmC+JVuKNz0szAAdljLsELoDlAMt0EyMqYSMtEPk=; b=gRSgsm+YvpKFUciEyasgE4ATLlCasNQXFXPFLJcVkerwhrFUXCZWgw+dDBy3fB489g us3WEsWcVOST5t/vEQmJhFhkDNLpT+ScyV+uvmoDuefPWdt66ww6iA8UhtC2JFs7RzcO HyIK0MwCmGFmW5V7shf47lhtQzD8ezOiPijE3p0xWJBgmM0uLMMCE4s2brrprSLwn+Px FvLtFoj2/wc+Alohj3goM8PJtX52PGPlrN4mBPiWcn09wWQ3IoPnwuKqAlM0c1/3dkuU 8BMQDvc9leBqrYuVexZsKrIDo/V+5nJEgFMHxKmwoGzTupp1fHg0SV/sF2KDO3nPFUY9 zkkw== X-Gm-Message-State: AOPr4FXfV6NUeNGyncgLDnmE/3m3juFIe7KO+CfVE3MsUXR3IY+gI3GwpdjysxR6PNkI7JWLHNw6V4/su9pKr01c MIME-Version: 1.0 X-Received: by 10.31.134.71 with SMTP id i68mr7713794vkd.46.1461244360830; Thu, 21 Apr 2016 06:12:40 -0700 (PDT) Received: by 10.31.209.196 with HTTP; Thu, 21 Apr 2016 06:12:40 -0700 (PDT) Date: Thu, 21 Apr 2016 06:12:40 -0700 Message-ID: From: Bill Cox To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11458eb40f0f190530fe7782 Archived-At: Subject: [TLS] Extensions and state during a resume X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2016 13:12:43 -0000 --001a11458eb40f0f190530fe7782 Content-Type: text/plain; charset=UTF-8 In TLS 1.3, do we renegotiate all extensions on a PSK resumption, or do we assume the full state of the prior connection is remembered (either in the ticket, or in session caches)? Alternatively, do we let some extensions require remembered state while other extensions require renegotiation? This was a bit of a mess in TLS 1.2, IMO. In TLS 1.3 we have the concept of the resume master secret (RMS). Ideally, this is all that would be needed, in addition to the new ticket, to resume. This would add some security in that the full session state would not need to be remembered, and some simplification in that the client and server may not require a full session cache. This would make it simpler and safer to write the RMS and ticket to disk, considerably improving resumption rates. The RMS is also a candidate for storing more securely than a full session state. OTOH, the spec appears to assume the security parameters from the initial connection are inherited on resumed connections, and this requires potentially a lot of state from multiple negotiated extensions to be remembered. This means the client would have to write the entire session cache to disk to achieve high resumption rates, which is less safe and more complex. Thanks, Bill --001a11458eb40f0f190530fe7782 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In TLS 1.3, do we renegotiate all extensions on a PSK resu= mption, or do we assume the full state of the prior connection is remembere= d (either in the ticket, or in session caches)?=C2=A0 Alternatively, do we = let some extensions require remembered state while other extensions require= renegotiation?=C2=A0 This was a bit of a mess in TLS 1.2, IMO.

In TLS 1.3 we have the concept of the resume master secret (RMS).= =C2=A0 Ideally, this is all that would be needed, in addition to the new ti= cket, to resume.=C2=A0 This would add some security in that the full sessio= n state would not need to be remembered, and some simplification in that th= e client and server may not require a full session cache.=C2=A0 This would = make it simpler and safer to write the RMS and ticket to disk, considerably= improving resumption rates.=C2=A0 The RMS is also a candidate for storing = more securely than a full session state.

OTOH, the= spec appears to assume the security parameters from the initial connection= are inherited on resumed connections, and this requires potentially a lot = of state from multiple negotiated extensions to be remembered.=C2=A0 This m= eans the client would have to write the entire session cache to disk to ach= ieve high resumption rates, which is less safe and more complex.
=
Thanks,
Bill
--001a11458eb40f0f190530fe7782-- From nobody Thu Apr 21 07:40:26 2016 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 07A5B12DB3F for ; Thu, 21 Apr 2016 07:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEf1uTvKAFCh for ; Thu, 21 Apr 2016 07:40:21 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79C1512DA64 for ; Thu, 21 Apr 2016 07:40:21 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id g133so80339815ywb.2 for ; Thu, 21 Apr 2016 07:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Uq1/1cufA5Hwobip2F+yNsNMqH2UOi2fLGk9UVhziWM=; b=d1xqwlFxyLUyBTfKT5qi+PfMzbtLhDt7N0/+HrIK9/Z3B2uZjYZY41sFEIWdV3do21 nk+Dkx8XQCGCb7nmU6ekTCON7aOYi5GcpXRRaj6NFXywZavxjLkufK7SJTtePNpP7Dvn XNZOqF+h5kl8LdXmo1xr7o3qgKyVI2PAcAEBc4WO3JeNcBeisdfROSXfsWZp9wfp6++7 839w+iEhSkbW4rqWABbGN7jJw1O5Yc2pEMaH+nge6Jku3Y9CRUqCTG5eHGlZdbwT0QaC VULpFg4Sj3xjxu2mWnzR1v7wRHnNHOL4ek1dNFcEf5WT1rtQ1sOAjvzmP2lTa5uidvBY V2yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Uq1/1cufA5Hwobip2F+yNsNMqH2UOi2fLGk9UVhziWM=; b=dDNPA/JjkcVNBlFVjYD2Kfwx4SBMIMnFVNyy+fJzK7WpMTYYNvGsT0ysW4X1LduuXq u8VXL8+vEQSZii30baB7FHE4qvNJl4kSHjxXmxDNu85P4mB6gtq5PLcZQB3U8pBSm1W0 DvIGniq/Y7aMD+zl5inmw0IXgibo7TV46t/+6IhI2YnGT53aMvQcxVIYs5VlwE1zLkBx ePmz3lyNnU0l9LQ3WhDzkeXnVc9y6K4KTYCOIF6O9ZfygaMHjHc9/4qdzXBqLphWfJy9 gLydJQ9lrqDI4VywxrlZjIvtEJGrMUBHQ1LOrzoRv5IWA5NlVooxJVnTB2JitQcj9SpQ wTFQ== X-Gm-Message-State: AOPr4FU5tp6QbV5/Y4qoZaUUgJdWQ+flP23UM2LcBAw1C0bm2yKQBRpZ3r6cgD3tmV35wjzfKqvY/ujVSUssqw== X-Received: by 10.13.237.1 with SMTP id w1mr9285766ywe.62.1461249620764; Thu, 21 Apr 2016 07:40:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Thu, 21 Apr 2016 07:39:41 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 21 Apr 2016 16:39:41 +0200 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=94eb2c0864a8931a020530ffb0a0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Can we require extensions to be sorted? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2016 14:40:24 -0000 --94eb2c0864a8931a020530ffb0a0 Content-Type: text/plain; charset=UTF-8 I wouldn't object in general to requiring sorting, but... 1. I wouldn't want to renumber existing extensions. 2. Servers badly handle some extension orderings (e.g., an empty extension at the end) So we would need to stay withing these guiderails. -Ekr On Thu, Apr 21, 2016 at 2:26 PM, Bill Cox wrote: > We did this in QUIC, and it is a major simplification. This is one > feature I will be sad to loose when we switch to TLS 1.3 for the crypto in > QUIC. > > I've worked on 3 extensions so far: EMS, channel ID, and token binding. > We are not allowed to negotiate channel ID or token binding unless we also > have negotiated EMS. If channel ID and token binding are both offered by > the client, the best behavior is for servers supporting both is to pick > token binding. Since token binding can be implemented as a custom > extension, in current implementations it is negotiated after builtin > extensions, but I cannot count on that when using the custom extension API. > > The logic required to deal with inter-extension dependencies is now so > complex that TLS implementations are forced to pre-parse extensions, adding > even more complexity and latency. Even so, that only lets extensions know > that the others exist when processed (such as EMS when processing token > binding), but it does not ensure that one extension has successfully been > negotiated before processing another. > > This is a mess. Is it too late to modify the TLS 1.3 spec to require > extensions to be sent in order of their tags? > > If we were to do so, I would recommend that we use a bit-reversal pattern > for numbering official extensions when the order makes no difference, and > when they do, put them in the middle between existing extensions. Some > extensions, like token binding, are intended to be lightweight extensions > that can be supported through a custom extension API. Such extensions > should always come after the more complex builtin extensions, because > built-in extensions are often processed in switch statements, while custom > extensions have to be handled separately. It is most natural for these > extensions to be parsed after builtin extensions, so maybe they should > start with a 1, and builtin extensions should start with a 0. > > For example, if we had EXT1, EXT2, and EXT3 as official extensions with no > specific ordering needs, and EXT1-2 that needs to come after EXT1, but was > defined after EXT3, and TESTEXT2-1 that is still unofficial, but must come > after EXT2, and CUSTEXT1 and CUSTEXT2, the tags might look like (in order > of when they were defined): > > EXT1: 0 > EXT2: 0x4000 > EXT3: 0x2000 > EXT1-2: 0x1000 > TESTEXT2-1: 0x60a5 > CUSTEXT1: 0x8000 > CUSTEXT2: 0xc000 > > The 0x608a5 starts with 0x60 for ordering half way between 0x4000 and > 0x8000, and has a random odd lower byte, 0xa5, to reduce accidental > collisions between TLS implementations that happen to be experimenting with > test extensions. The custom extensions follow a bit-reversal pattern in > the range where the MSB is set. > > I'm not confident that we need to differentiate custom extensions here. > QUIC does not. If we do, to help clarify the custom extension concept, > these are extensions that: > > 1) can be processed with two callbacks: one for adding, one for parsing > (which are different on client vs server) > 2) do not keep any state between resumes, and are renegotiated > 3) can be processed after builtin extensions > > The issue of extensions requiring state between resumes confuses me, so > I'll send a separate email for help understanding it. > > Bill > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c0864a8931a020530ffb0a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I wouldn't object in general to requiring sorting= , but...

1. I wouldn't want to renumber existi= ng extensions.
2. Servers badly handle some extension orderings (= e.g., an empty extension at the end)

So we would n= eed to stay withing these guiderails.

-Ekr


On Thu, Ap= r 21, 2016 at 2:26 PM, Bill Cox <waywardgeek@google.com> wrote:
We did this in = QUIC, and it is a major simplification.=C2=A0 This is one feature I will be= sad to loose when we switch to TLS 1.3 for the crypto in QUIC.

I've worked on 3 extensions so far: EMS, channel ID, and token = binding.=C2=A0 We are not allowed to negotiate channel ID or token binding = unless we also have negotiated EMS.=C2=A0 If channel ID and token binding a= re both offered by the client, the best behavior is for servers supporting = both is to pick token binding.=C2=A0 Since token binding can be implemented= as a custom extension, in current implementations it is negotiated after b= uiltin extensions, but I cannot count on that when using the custom extensi= on API.

The logic required to deal with inter-exte= nsion dependencies is now so complex that TLS implementations are forced to= pre-parse extensions, adding even more complexity and latency.=C2=A0 Even = so, that only lets extensions know that the others exist when processed (su= ch as EMS when processing token binding), but it does not ensure that one e= xtension has successfully been negotiated before processing another.
<= div>
This is a mess.=C2=A0 Is it too late to modify the TLS 1= .3 spec to require extensions to be sent in order of their tags?
=
If we were to do so, I would recommend that we use a bit-rev= ersal pattern for numbering official extensions when the order makes no dif= ference, and when they do, put them in the middle between existing extensio= ns.=C2=A0 Some extensions, like token binding, are intended to be lightweig= ht extensions that can be supported through a custom extension API.=C2=A0 S= uch extensions should always come after the more complex builtin extensions= , because built-in extensions are often processed in switch statements, whi= le custom extensions have to be handled separately.=C2=A0 It is most natura= l for these extensions to be parsed after builtin extensions, so maybe they= should start with a 1, and builtin extensions should start with a 0.
=

For example, if we had EXT1, EXT2, and EXT3 as official= extensions with no specific ordering needs, and EXT1-2 that needs to come = after EXT1, but was defined after EXT3, and TESTEXT2-1 that is still unoffi= cial, but must come after EXT2, and CUSTEXT1 and CUSTEXT2, the tags might l= ook like (in order of when they were defined):

EXT= 1: 0
EXT2: 0x4000
EXT3: 0x2000
EXT1-2: 0x= 1000
TESTEXT2-1: 0x60a5
CUSTEXT1: 0x8000
= CUSTEXT2: 0xc000

The 0x608a5 starts with 0x60 for = ordering half way between 0x4000 and 0x8000, and has a random odd lower byt= e, 0xa5, to reduce accidental collisions between TLS implementations that h= appen to be experimenting with test extensions.=C2=A0 The custom extensions= follow a bit-reversal pattern in the range where the MSB is set.

I'm not confident that we need to differentiate custom = extensions here.=C2=A0 QUIC does not.=C2=A0 If we do, to help clarify the c= ustom extension concept, these are extensions that:

1) can be processed with two callbacks: one for adding, one for parsing (= which are different on client vs server)
2) do not keep any state= between resumes, and are renegotiated
3) can be processed after = builtin extensions

The issue of extensions requiri= ng state between resumes confuses me, so I'll send a separate email for= help understanding it.

Bill

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


--94eb2c0864a8931a020530ffb0a0-- From nobody Thu Apr 21 07:41:01 2016 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 898E112D5CC for ; Thu, 21 Apr 2016 07:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVMlid6WQ-mv for ; Thu, 21 Apr 2016 07:40:53 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6E512DE91 for ; Thu, 21 Apr 2016 07:40:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 02D5327AD; Thu, 21 Apr 2016 17:40:52 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id j5DUJcORfYa5; Thu, 21 Apr 2016 17:40:51 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id CEAE721C; Thu, 21 Apr 2016 17:40:51 +0300 (EEST) Date: Thu, 21 Apr 2016 17:40:49 +0300 From: Ilari Liusvaara To: Bill Cox Message-ID: <20160421144049.GB24969@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions and state during a resume X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2016 14:40:59 -0000 On Thu, Apr 21, 2016 at 06:12:40AM -0700, Bill Cox wrote: > In TLS 1.3, do we renegotiate all extensions on a PSK resumption, or do we > assume the full state of the prior connection is remembered (either in the > ticket, or in session caches)? Alternatively, do we let some extensions > require remembered state while other extensions require renegotiation? > This was a bit of a mess in TLS 1.2, IMO. My understanding is that TLS 1.3 replaces the entiere resumption with what is essentially dynamic PSK provosioning. So state to be remembered is to be kept at minimum. Certainly remembering extensions from past handshake would be quite nasty to implement (especially correctly). -Ilari From nobody Thu Apr 21 08:05:58 2016 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 9FA3512DF38 for ; Thu, 21 Apr 2016 08:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IEO1bf3wqid for ; Thu, 21 Apr 2016 08:05:55 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D60D912DE54 for ; Thu, 21 Apr 2016 08:05:54 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id e185so101494250vkb.1 for ; Thu, 21 Apr 2016 08:05:54 -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; bh=BrqumOIAgyViXjzB44adNq6YvXuik9hvwoB7v22vFWA=; b=kL358gAQlFMfLf1R+jcBxDkAdketuO34pMnTlg+ZiX4zvCORweq/v4St5iYm8QqmIF RUR6cbenj7WH4Qinkq2IhYPq8FT+d6yGMHymla0dioaKCfVXXO8vjUGZdfUAn6/SUHPk ysJmFyonFtQbkr/6XZfjfzGH2IvShhO+NtfbwyZgDk9XPh01scNVmPt6smBDixL3Z75e FZIYrcLeuqQW1iMraIhFUbfceghmfmwCThz27wh2huopT4OzJfmYFUG7Z+sFFLDmpmIw qz2M/hT86uG9rjgI/zRVG0TnjbeGHxTzBcyUpTfT5TID2eRsH4gwCWHDDziSXjbGxtnM uwSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=BrqumOIAgyViXjzB44adNq6YvXuik9hvwoB7v22vFWA=; b=eH6UcmolN4KbvcY6/eL2XAKobNsMaZaeORo2/hYu6vsJM2kY3N4Zn6aygHIsGtzdbM 91y8nL/9AZeby9xqk8jgz4mh5QfzHJr7DXY+1fRs+nH2D3JOt+yluuLttSiOKqm9pkKe cEkBAvLzWPp0/xVw3Rakii7qGWQoWziohOltZYt4GERp1ES3vtwB0wfV8YUV8eUX8nhE WJMS8IwToAufwvz9WFvasq+TVZKZvGlYRgRq67jdOzPFpfvTqryYKjtSpPFLZmbfvdfk H3W/xfrtj79UbS8HobYPD6u0gIuXFI6obzYMm8B7mMigYquRb4NNjdWJMd77xTpL5EGI tEmA== X-Gm-Message-State: AOPr4FXNHR95d07GnfVDtRPv4k0v1AiOgDk1p5EJOahZOrqxPOEyh+BqclYk46x/TeNiKnsrj+1LCQ+daadijG+O MIME-Version: 1.0 X-Received: by 10.31.8.205 with SMTP id 196mr8235177vki.144.1461251153732; Thu, 21 Apr 2016 08:05:53 -0700 (PDT) Received: by 10.31.209.196 with HTTP; Thu, 21 Apr 2016 08:05:53 -0700 (PDT) In-Reply-To: <20160421144049.GB24969@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160421144049.GB24969@LK-Perkele-V2.elisa-laajakaista.fi> Date: Thu, 21 Apr 2016 08:05:53 -0700 Message-ID: From: Bill Cox To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a1144f912f297520531000b0e Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions and state during a resume X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2016 15:05:56 -0000 --001a1144f912f297520531000b0e Content-Type: text/plain; charset=UTF-8 On Thu, Apr 21, 2016 at 7:40 AM, Ilari Liusvaara wrote: > My understanding is that TLS 1.3 replaces the entiere resumption with > what is essentially dynamic PSK provosioning. So state to be remembered > is to be kept at minimum. > > Certainly remembering extensions from past handshake would be quite > nasty to implement (especially correctly). > > > -Ilari > That sounds reasonable, except for PSK 0-RTT resumption. In that case, the first flight of data is protected with whatever extensions the client decides to use on its own. I think it should be all the extensions negotiated on the original handshake in this case, which requires a client-side cache. In this case, I think the client should replace the secrets in the serialized session state with the RMS, to protect the prior connection data. I also think the client should write this session state to disk, preferably encrypted, since this results in a huge reduction in 1-RTT handshakes. If we accept the need for a client-side cache, then it seems reasonable to expect that either the server session state is in the ticket for stateless servers, or in a server-side cache for servers with replay protection. If all this is basically acceptable, then should we simply mandate that all extension data must be remembered, and that extensions are not sent on resumes unless they specifically are needed to change the state on the new connection? This has implications on custom extension APIs. There seem to be very few uses of it today in OpenSSL, and I think one reason is that extensions generally need to have remembered state, such as whether or not it was negotiated. I think we may want to look into enhancing the API to allow custom extensions to serialize custom state to the session state. Bill --001a1144f912f297520531000b0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 21, 2016 at 7:40 AM, Ilari Liusvaara <ilariliusvaara@welho= .com> wrote:
My understandi= ng is that TLS 1.3 replaces the entiere resumption with
what is essentially dynamic PSK provosioning. So state to be remembered
is to be kept at minimum.

Certainly remembering extensions from past handshake would be quite
nasty to implement (especially correctly).


-Ilari

That = sounds reasonable, except for PSK 0-RTT resumption.=C2=A0 In that case, the= first flight of data is protected with whatever extensions the client deci= des to use on its own.=C2=A0 I think it should be all the extensions negoti= ated on the original handshake in this case, which requires a client-side c= ache.

= In this case, I think the client should replace the secrets in the serializ= ed session state with the RMS, to protect the prior connection data.=C2=A0 = I also think the client should write this session state to disk, preferably= encrypted, since this results in a huge reduction in 1-RTT handshakes.

If we acc= ept the need for a client-side cache, then it seems reasonable to expect th= at either the server session state is in the ticket for stateless servers, = or in a server-side cache for servers with replay protection.

If all this is basi= cally acceptable, then should we simply mandate that all extension data mus= t be remembered, and that extensions are not sent on resumes unless they sp= ecifically are needed to change the state on the new connection?

This has implica= tions on custom extension APIs.=C2=A0 There seem to be very few uses of it = today in OpenSSL, and I think one reason is that extensions generally need = to have remembered state, such as whether or not it was negotiated.=C2=A0 I= think we may want to look into enhancing the API to allow custom extension= s to serialize custom state to the session state.

Bill
--001a1144f912f297520531000b0e-- From nobody Thu Apr 21 08:24:44 2016 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 19CF112DB04 for ; Thu, 21 Apr 2016 08:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.918 X-Spam-Level: X-Spam-Status: No, score=-7.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKWziDrTKu7I for ; Thu, 21 Apr 2016 08:24:38 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FD7212D66B for ; Thu, 21 Apr 2016 08:24:37 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 32D147F36F; Thu, 21 Apr 2016 15:24:37 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-113.brq.redhat.com [10.34.0.113]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3LFOZXm026388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Apr 2016 11:24:36 -0400 From: Hubert Kario To: tls@ietf.org Date: Thu, 21 Apr 2016 17:24:30 +0200 Message-ID: <2583177.ZKtSIvTJKQ@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.6-201.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart40596353.A4GGOzDHGR"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Can we require extensions to be sorted? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2016 15:24:44 -0000 --nextPart40596353.A4GGOzDHGR Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thursday 21 April 2016 05:26:21 Bill Cox wrote: > We did this in QUIC, and it is a major simplification. This is one > feature I will be sad to loose when we switch to TLS 1.3 for the > crypto in QUIC. >=20 > I've worked on 3 extensions so far: EMS, channel ID, and token > binding. We are not allowed to negotiate channel ID or token binding= > unless we also have negotiated EMS. If channel ID and token binding > are both offered by the client, the best behavior is for servers > supporting both is to pick token binding. Since token binding can be= > implemented as a custom extension, in current implementations it is > negotiated after builtin extensions, but I cannot count on that when > using the custom extension API. >=20 > The logic required to deal with inter-extension dependencies is now s= o > complex that TLS implementations are forced to pre-parse extensions, > adding even more complexity and latency. Even so, that only lets > extensions know that the others exist when processed (such as EMS > when processing token binding), but it does not ensure that one > extension has successfully been negotiated before processing another.= I don't follow. If you understand given extension, you must reject Client Hello if that= =20 extension is malformed. If one extension depends on other extension, you just need to check if=20= it is present. =20 I don't see how single array lookup is overly complex, to the point tha= t=20 we need to assign new IDs to existing extensions. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c --nextPart40596353.A4GGOzDHGR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJXGPCuAAoJEJKo0bgB0vX1tjYQAKBozabEjxIkweCpdYdgY6iV A2LPlWP0p8wjjfYBNFDUWxFGJ5ngCLi3LN61W9wg0WKl4Pa62gySuU+RF1QzRAuv pqVlbP95VIoMKp6Uhi7hDgCsB3QTMccaicdat2sz9sFRVLE20Q7DJDfd9nOdXxhc GIIuejXSfIVRpsl+0Wb5BIAbPZS7hFlfV6Zyt9KPvU39sQDGUltMAi2c8datLWBc 0zS1r8EaAf8FAfZtcNwjqMB+qLFMjBNW5RqLpg58LwdEOdYIe3hdHxQ+bX4lqvKz Q9dW1vWKOLRVRmFb38aP+GjXEvMCtVImTudWC5A8h5QSIoyVziF3zvs4OoJzE73G rztXvS8DeZ4a4/SkvNmJ9GbTT1Zrzponp/X5kyrD8hRhcGjfD3tAOHmiGTPdvkod si5al93Xmxz9EgjjGctJcob2vVRTIwyFQ8TCcVplPjRO7gjonnX8Pz4j3wUu+Xse GRBigmIGgsub9h4V3CLS9fJHXDwpGu0zSXehsyDzv63D+THtWWEiiz1OcvcgXzPd +/y7s0EZFWDyQRRFyL1vd6cYUwa3u3maFHOV2EviFSNvcbAuvw0sIeWIqSUSJJCY 3dgkpwXxnh60Kg+g0bKV7H27WYGKFdUVIy3EPYIKwApdYNRJd6/0rHgGNx6MV8gA 2JvqiYM205HDdlzl44Pq =+Mu4 -----END PGP SIGNATURE----- --nextPart40596353.A4GGOzDHGR-- From nobody Thu Apr 21 08:28:59 2016 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 DD8F012EBE8 for ; Thu, 21 Apr 2016 08:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KommleBtQrBi for ; Thu, 21 Apr 2016 08:28:56 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id CD17612DF07 for ; Thu, 21 Apr 2016 08:28:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 2747830E2; Thu, 21 Apr 2016 18:28:49 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id hFxa_5wkoYvZ; Thu, 21 Apr 2016 18:28:48 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id C1AB4C4; Thu, 21 Apr 2016 18:28:48 +0300 (EEST) Date: Thu, 21 Apr 2016 18:28:45 +0300 From: Ilari Liusvaara To: Bill Cox Message-ID: <20160421152845.GA25769@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160421144049.GB24969@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions and state during a resume X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2016 15:28:58 -0000 On Thu, Apr 21, 2016 at 08:05:53AM -0700, Bill Cox wrote: > On Thu, Apr 21, 2016 at 7:40 AM, Ilari Liusvaara > wrote: > > > My understanding is that TLS 1.3 replaces the entiere resumption with > > what is essentially dynamic PSK provosioning. So state to be remembered > > is to be kept at minimum. > > > > Certainly remembering extensions from past handshake would be quite > > nasty to implement (especially correctly). > > > > > > -Ilari > > > > That sounds reasonable, except for PSK 0-RTT resumption. In that case, the > first flight of data is protected with whatever extensions the client > decides to use on its own. I think it should be all the extensions > negotiated on the original handshake in this case, which requires a > client-side cache. IMO, there is no "PSK 0-RTT resumption", it is just PSK 0-RTT with dynamically provisioned PSK. > In this case, I think the client should replace the secrets in the > serialized session state with the RMS, to protect the prior connection > data. I also think the client should write this session state to disk, > preferably encrypted, since this results in a huge reduction in 1-RTT > handshakes. Obviously, the client shouldn't save any secrets from connection except for RMS, and no extension should require it to do so. > If we accept the need for a client-side cache, then it seems reasonable to > expect that either the server session state is in the ticket for stateless > servers, or in a server-side cache for servers with replay protection. The session state is source of subtle bugs. > If all this is basically acceptable, then should we simply mandate that all > extension data must be remembered, and that extensions are not sent on > resumes unless they specifically are needed to change the state on the new > connection? The extension data can not be guaranted to be preserved. The client has to send extensions it wants anyway. > This has implications on custom extension APIs. There seem to be very few > uses of it today in OpenSSL, and I think one reason is that extensions > generally need to have remembered state, such as whether or not it was > negotiated. I think we may want to look into enhancing the API to allow > custom extensions to serialize custom state to the session state. Ever seen what kind of mess the interaction between extensions and re- sumption is? E.g. the interaction between ALPN and resumption is not what one could quickly think based of general type of ALPN extension... -Ilari From nobody Thu Apr 21 09:02:22 2016 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 2E57B12EC57 for ; Thu, 21 Apr 2016 09:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0L2griQTXB7 for ; Thu, 21 Apr 2016 09:02:19 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DFCB12EA84 for ; Thu, 21 Apr 2016 09:02:19 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id n67so90652701vkf.3 for ; Thu, 21 Apr 2016 09:02:19 -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; bh=Dgf50FyDrcLiuv93U1vtA7/+xujD0qhaJu+mdLviC4Q=; b=Pe0AZuz/RRGbG6xMlQhWKoGw4Zc1yYeyKJEFScJDRFWY0q1xA4qVM4sS5n434l69Aw Kh5eI23zY3e+QgYppGV972mLsCZwei8emIsu7mmwbRWphZDa5jPGb7uDWujn6B/DYPLQ 8aVajFAaNhILh/v1SVyoSyB6YnoFLJDSDy2henAbxZNewnvqg8ho7BPNEyo1rKGwaPpk xnpwIb9mwg+CMUFB9iP9qk4if4OwkmwqA9y79usbgFkHFQUbC3B6QxuZStPq6n/NdEfR azsKkuTpj/1uWtNfz7/6wNQAYcFCvzuWNRbyA8fqFGUgmi325y0cSbyU2YfhsI1fDWVG sdzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Dgf50FyDrcLiuv93U1vtA7/+xujD0qhaJu+mdLviC4Q=; b=Qvn8fHgX35vTSjo2BzBXSTK2g3A1GEFjgS7oAWeshltBhsAXBpewezayOOdNn4Ddzj YvslwIXUnm09BSVRKxH788kls1Qz/HwL6LBi3VSs2yAJIwQOt14UoVR+aO2eDanNsR2+ ifLZFD17EkYvDQgyRXtSh0UE+psdwB8PXhOx+C5FvQy+SfwWPbJB0ClNbKgBsEYmHJIH 3YNfHGPpG2LhjnidvDhr7Cbvi9ZUdoR/IaveTXwP+6/abmiPvdqz4MVmyyuZcY5/Hi3+ mzpATGA8B1lnmyxySRQP0ddjTCHlRA8UYdR9OEiK+PUcdlgdA9C/pSHwxx7TRfPR9Ddn ZzvA== X-Gm-Message-State: AOPr4FXBrvxSbbO6FCk/Da1JQcQSzcyeLvYeXRUZhbJQXCTyd4SXTNgH1Y4vmR70vFbxty2HVkLVi2dpC/O3NDgo MIME-Version: 1.0 X-Received: by 10.159.35.226 with SMTP id 89mr8503842uao.27.1461254537902; Thu, 21 Apr 2016 09:02:17 -0700 (PDT) Received: by 10.31.209.196 with HTTP; Thu, 21 Apr 2016 09:02:17 -0700 (PDT) In-Reply-To: <20160421152845.GA25769@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160421144049.GB24969@LK-Perkele-V2.elisa-laajakaista.fi> <20160421152845.GA25769@LK-Perkele-V2.elisa-laajakaista.fi> Date: Thu, 21 Apr 2016 09:02:17 -0700 Message-ID: From: Bill Cox To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c03da36a8d55a053100d534 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions and state during a resume X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2016 16:02:21 -0000 --94eb2c03da36a8d55a053100d534 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 21, 2016 at 8:28 AM, Ilari Liusvaara wrote: > IMO, there is no "PSK 0-RTT resumption", it is just PSK 0-RTT with > dynamically provisioned PSK. This sounds good, but there are exceptions. Any extension that needs to be negotiated that impacts security needs to be remembered for a PSK 0-RTT resume. > > If we accept the need for a client-side cache, then it seems reasonable > to > > expect that either the server session state is in the ticket for > stateless > > servers, or in a server-side cache for servers with replay protection. > > The session state is source of subtle bugs. Agreed. I'm no TLS expert, but I've already experienced significant pain resulting from these bugs. > > If all this is basically acceptable, then should we simply mandate that > all > > extension data must be remembered, and that extensions are not sent on > > resumes unless they specifically are needed to change the state on the > new > > connection? > > The extension data can not be guaranted to be preserved. The client has to > send extensions it wants anyway. Good point. The client has to send extensions in the handshake anyway, in case we fall back to 1-RTT. > This has implications on custom extension APIs. There seem to be very few > > uses of it today in OpenSSL, and I think one reason is that extensions > > generally need to have remembered state, such as whether or not it was > > negotiated. I think we may want to look into enhancing the API to allow > > custom extensions to serialize custom state to the session state. > > Ever seen what kind of mess the interaction between extensions and re- > sumption is? E.g. the interaction between ALPN and resumption is not what > one could quickly think based of general type of ALPN extension... > Yes, I've worked with EMS and session resumption. This is very messy stuff which makes me long for the relative simplicity of QUIC crypto. Without remembering the APLN negotiation results from the 1-RTT handshake, should the client send first flight application data over HTTP/1 or HTTP/2? What if we merged the server-config feature from the ECDH 0-RTT mode into the PSK mode? Most of the data that needs to be remembered from the 1-RTT handshake is semi-static, and suitable for a server-config. In particular, I would like to know about the server: - Does it support replay protection? This impacts whether or not I would use client certs, for example. - Does it support HTTP/2? I want to encode my first flight data in HTTP/2 if possible. What do you think? Bill --94eb2c03da36a8d55a053100d534 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 21, 2016 at 8:28 AM, Ilari Liusvaara <ilariliusvaara@welho= .com> wrote:
IMO, there is = no "PSK 0-RTT resumption", it is just PSK 0-RTT with
dynamically provisioned PSK.

This sounds go= od, but there are exceptions.=C2=A0 Any extension that needs to be negotiat= ed that impacts security needs to be remembered for a PSK 0-RTT resume.
=C2=A0
> If we accept the need for a client-side cache, then it seems reasonabl= e to
> expect that either the server session state is in the ticket for state= less
> servers, or in a server-side cache for servers with replay protection.=

The session state is source of subtle bugs.

Agreed.=C2=A0 I'm no TLS expert, but I've already experienc= ed significant pain resulting from these bugs.
=C2=A0
> If all this is basically acceptable, then should we simply mandate tha= t all
> extension data must be remembered, and that extensions are not sent on=
> resumes unless they specifically are needed to change the state on the= new
> connection?

The extension data can not be guaranted to be preserved. The client = has to
send extensions it wants anyway.

Good point= .=C2=A0 The client has to send extensions in the handshake anyway, in case = we fall back to 1-RTT.

<= span class=3D"">> This has implications on custom extension APIs.=C2=A0 = There seem to be very few
> uses of it today in OpenSSL, and I think one reason is that extensions=
> generally need to have remembered state, such as whether or not it was=
> negotiated.=C2=A0 I think we may want to look into enhancing the API t= o allow
> custom extensions to serialize custom state to the session state.

Ever seen what kind of mess the interaction between extensions and r= e-
sumption is? E.g. the interaction between ALPN and resumption is not what one could quickly think based of general type of ALPN extension...

Yes, I've worked with EMS and session resum= ption.=C2=A0 This is very messy stuff which makes me long for the relative = simplicity of QUIC crypto.=C2=A0 Without remembering the APLN negotiation r= esults from the 1-RTT handshake, should the client send first flight applic= ation data over HTTP/1 or HTTP/2?

What if we merge= d the server-config feature from the ECDH 0-RTT mode into the PSK mode?=C2= =A0 Most of the data that needs to be remembered from the 1-RTT handshake i= s semi-static, and suitable for a server-config.=C2=A0 In particular, I wou= ld like to know about the server:

- Does it suppor= t replay protection?=C2=A0 This impacts whether or not I would use client c= erts, for example.
- Does it support HTTP/2?=C2=A0 I want to enco= de my first flight data in HTTP/2 if possible.

Wha= t do you think?

Bill
--94eb2c03da36a8d55a053100d534-- From nobody Thu Apr 21 09:32:34 2016 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 9E59C12DF23 for ; Thu, 21 Apr 2016 09:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVnejUrDD2qV for ; Thu, 21 Apr 2016 09:32:32 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B692412DF0E for ; Thu, 21 Apr 2016 09:32:31 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id n67so91613999vkf.3 for ; Thu, 21 Apr 2016 09:32:31 -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; bh=PsjiVhDFVeshYFp28OszO8+D1mp0tRkogrjFtsGwAUU=; b=I3xTnAlaTjfzGFXDVqpfaSFQyD42PkjCV2v5sip/ziO3m1H8+TVGhUDckaRJDG6/nc jUi+AyAxSmvcEQRQlj2Vg+RBJXj6zlE/7L6/HQhRJ8rOCvoMAdepafGf4Of11pwPaxrj nmegV3fKNR2F/Sp5uNBzBqRKhOY++gD9kV+3FFWz4bYHvdMX9WvNOIcYAr5bFpQ/IPk+ DsHFvCLNVwQItHwaJZN1BP0geVJmsViFyX1aIgU9ND0cmltABR+sIig23OFbHW11qomm enS8rWgTmsTNb5x0u0N9PNN1I1kTuWIVxh9aYxoUrEmrht2LEzEADYPpd5UmUqURKmMO aMzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=PsjiVhDFVeshYFp28OszO8+D1mp0tRkogrjFtsGwAUU=; b=aP+AZgn6ae2ow5eg1D6P/llTJrXaNX65LmT8UHT1f8gFeuuK83P5AbT6EIAoRKFp48 DpgDXBu92jZK3Xqev9WAI+mpL1PZ6sMY3qKk/92fKi7yVAJ2w8QqCCgMxYvsJzIs/CvF ntKcFtYAXxRU/EO+RazjlJ25awSh2ULNhnUW5O13JW0Kuw+besLQf1ATgrFbSKcjqdL1 a6DXZxK6rbyYnJqur9xgBhqwQXpt2lCxX/hQ54r9iJTn4FbRqO8Idts2rmAH4vicdtha YB79jJbiJHw6QctlD2nQhlwZfWTWp06ZgRGIx6Z2fzUTnan/9nmkzlKPV5SKsidrGIvI EO1A== X-Gm-Message-State: AOPr4FWQ2cgLdsg4SbsdRhHhYgoL4rX6FBZu/PmZ456bGJpOiJtmfVeC8wlPx0iQ7V9j22vZSgjWG7kHtK1QjcXa MIME-Version: 1.0 X-Received: by 10.176.0.106 with SMTP id 97mr8334128uai.113.1461256350462; Thu, 21 Apr 2016 09:32:30 -0700 (PDT) Received: by 10.31.209.196 with HTTP; Thu, 21 Apr 2016 09:32:30 -0700 (PDT) In-Reply-To: References: <20160421144049.GB24969@LK-Perkele-V2.elisa-laajakaista.fi> <20160421152845.GA25769@LK-Perkele-V2.elisa-laajakaista.fi> Date: Thu, 21 Apr 2016 09:32:30 -0700 Message-ID: From: Bill Cox To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a113e4d9cb23fc005310141ce Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions and state during a resume X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2016 16:32:33 -0000 --001a113e4d9cb23fc005310141ce Content-Type: text/plain; charset=UTF-8 I'm just going through an example which is related to what I work on, which currently is token binding. Client certs are very similar. If client certs (or token binding) were supported by the server, as well as replay protection, then I would prefer to send the ClientVerify message in a PSK 0-RTT resume. Without replay protection, I would prefer to avoid client certs and token binding. Basically, I think we have two choices for remembering server feature support, which is required when doing PSK 0-RTT: 1) negotiate all supported features in the 1-RTT handshake and use session caches to remember the results 2) use server configs instead Given all the bugs resulting from 1), I think I prefer 2). Bill --001a113e4d9cb23fc005310141ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I= 9;m just going through an example which is related to what I work on, which= currently is token binding.=C2=A0 Client certs are very similar.

If client certs= (or token binding) were supported by the server, as well as replay protect= ion, then I would prefer to send the ClientVerify message in a PSK 0-RTT re= sume.=C2=A0 Without replay protection, I would prefer to avoid client certs= and token binding.

Basically, I think we have two choices for remembering server= feature support, which is required when doing PSK 0-RTT:

1) negotiate all supp= orted features in the 1-RTT handshake and use session caches to remember th= e results
2) use server configs instead

Given all= the bugs resulting from 1), I think I prefer 2).

Bill
--001a113e4d9cb23fc005310141ce-- From nobody Thu Apr 21 10:51:02 2016 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 B69F812E97B for ; Thu, 21 Apr 2016 10:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdKN8fXHAPLx for ; Thu, 21 Apr 2016 10:50:57 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0797.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:797]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2610212E863 for ; Thu, 21 Apr 2016 10:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=esdjLYLAnmQM3S1BHi/jMHjWzHbLUCUiXwwJwbbH2Ho=; b=kWapl7dAiFOhkcr3aCtFbjxPbF2RCGGy3h8KDAoccG2s9WtopkkZOlwL6PH9Eea8Q4lrueKTm8Paw4WQcS3GLHW/gSRcU3tfX3Gpvl6qRHkbpEhZfaKTfwdaT46Xa6vJJb/CAKWUn0RBrQNQ9atmxMKruX7LVjQO9kZwanxXtcg= Received: from BN3PR03MB1445.namprd03.prod.outlook.com (10.163.34.28) by BN3PR03MB1447.namprd03.prod.outlook.com (10.163.34.30) with Microsoft SMTP Server (TLS) id 15.1.466.19; Thu, 21 Apr 2016 17:50:40 +0000 Received: from BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) by BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) with mapi id 15.01.0466.023; Thu, 21 Apr 2016 17:50:40 +0000 From: Andrei Popov To: Bill Cox , "tls@ietf.org" Thread-Topic: [TLS] Can we require extensions to be sorted? Thread-Index: AQHRm8kL3FzqwswyPE2wSwLpX+9POZ+Urv5w Date: Thu, 21 Apr 2016 17:50:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:7::1d2] x-ms-office365-filtering-correlation-id: 22becd17-dc61-4d52-bb9c-08d36a0d745f x-microsoft-exchange-diagnostics: 1; BN3PR03MB1447; 5:WWTEqllIk/ckUlHGoq6h9wFInPCPowCOt9I5GPdpOKp81GkinM1XJXBPt9GrIvAn3f4LvwCe/S4LsCgc5GBeqT9ZLZYCqj01upa47Dem2RgWtIISaMcjCo3eDDRkGdazSA6wUFMFxsA+xP8whyEEXYsyjQqz2gG+72NQOVAjf8uoae5MWLoouXYgM+PVxqNS; 24:+bSwZv5H7rIdll/h6ftHSSzBwEgU1BMKRO6s2FGPtYJ4RMK/PA2a3MmRY5BjumiMRa/WBseWJHO4wb5jNYCUVZNxjIYkpy9h3eAWUZyW8LY=; 7:b/3PekgVYJAMZjyBklDFo7rV9QraW2Roz0wHWBixpMZx9itROlpazO/dmKBYzaxKXDKQEpl4czYuUWmeQnp2Zmf54nfTVUAeG8Vr7ISTD+wpRr9jj+vgUeCJMLKCYO7gfdP7XM+hsNljFjXgK0gBSzWzbalqyCEmv3tcgNHUkg8t69vmwbsjAFF3g0TbGygwUllyn9RhiEeGptqd1YHdELJ4jsSM7Q3oN1qTWOYbiPZvibR3pJ5ul0L9V4vzRmeZ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1447; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN3PR03MB1447; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1447; x-forefront-prvs: 091949432C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(189998001)(76576001)(54356999)(16236675004)(107886002)(99286002)(5003600100002)(87936001)(5008740100001)(586003)(3660700001)(50986999)(2950100001)(2501003)(790700001)(2900100001)(6116002)(102836003)(77096005)(76176999)(3280700002)(86362001)(92566002)(19300405004)(74316001)(86612001)(2906002)(9686002)(1096002)(19580395003)(15975445007)(8990500004)(5002640100001)(5005710100001)(10400500002)(106116001)(19625215002)(11100500001)(122556002)(5001770100001)(10090500001)(81166005)(33656002)(1220700001)(19580405001)(10290500002)(5004730100002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB1447; H:BN3PR03MB1445.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB1445925980B3FFCA941D665B8C6E0BN3PR03MB1445namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2016 17:50:40.7203 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1447 Archived-At: Subject: Re: [TLS] Can we require extensions to be sorted? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2016 17:50:59 -0000 --_000_BN3PR03MB1445925980B3FFCA941D665B8C6E0BN3PR03MB1445namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIFRoZSBsb2dpYyByZXF1aXJlZCB0byBkZWFsIHdpdGggaW50ZXItZXh0ZW5zaW9uIGRlcGVu ZGVuY2llcyBpcyBub3cgc28gY29tcGxleCB0aGF0IFRMUyBpbXBsZW1lbnRhdGlvbnMgYXJlIGZv cmNlZCB0byBwcmUtcGFyc2UgZXh0ZW5zaW9ucywgYWRkaW5nIGV2ZW4gbW9yZSBjb21wbGV4aXR5 IGFuZCBsYXRlbmN5Lg0KSSBhZ3JlZSBhYm91dCB0aGUgY29tcGxleGl0eS4gVExTIGV4dGVuc2lv bnMgYXJlIGVzc2VudGlhbGx5IHN1Yi1wcm90b2NvbHMgdGhhdCBkZWZpbmUgdGhlaXIgb3duIG1l c3NhZ2VzLCBhbmQgdGhleSBjYW4gYmUgaW50ZXItZGVwZW5kZW50LiBJ4oCZdmUgYWxzbyBzZWVu IHBlb3BsZSBjb25mdXNlZCBieSB0aGUgZmFjdCB0aGF0IGNlcnRhaW4g4oCcZXh0ZW5zaW9uc+KA nSBhcmUgYWN0dWFsbHkgbmVjZXNzYXJ5IHRvIGltcGxlbWVudC4NCg0KDQrDmCAgSXMgaXQgdG9v IGxhdGUgdG8gbW9kaWZ5IHRoZSBUTFMgMS4zIHNwZWMgdG8gcmVxdWlyZSBleHRlbnNpb25zIHRv IGJlIHNlbnQgaW4gb3JkZXIgb2YgdGhlaXIgdGFncz8NCknigJltIG5vdCBzdXJlIHRoaXMgd291 bGQgaGVscC4gU29tZSBleHRlbnNpb25zIGhhdmUgdGhlIGNsaWVudCBhZHZlcnRpc2luZyBvcHRp b25zIGFuZCB0aGUgc2VydmVyIHBpY2tpbmcgdGhlbTsgb3RoZXJzIGRvIHRoZSByZXZlcnNlLiBU aGUgbW9tZW50IGluIHRoZSBoYW5kc2hha2Ugd2hlcmUgdGhlIGV4dGVuc2lvbiBjYW4gYmUgY29u c2lkZXJlZCDigJxuZWdvdGlhdGVk4oCdIGRpZmZlcnMgcGVyIGV4dGVuc2lvbi4NCg0KSW4gb3Ro ZXIgd29yZHMsIHRoZSBvcmRlciBpbiB3aGljaCBleHRlbnNpb25zIGFyZSBwcmVzZW50ZWQgaW4g dGhlIENsaWVudEhlbGxvXFNlcnZlckhlbGxvIHNvIGZhciBoYXMgYmVlbiB0aGUgbGVhc3Qgb2Yg bXkgcHJvYmxlbXMuIEZpZ3VyaW5nIG91dCB3aGljaCBleHRlbnNpb25zIHRvIHNlbmQgYW5kIHJl c3BvbmQgdG8sIG1heGltaXppbmcgdGhlIGNoYW5jZSBvZiBzdWNjZXNzZnVsIGhhbmRzaGFrZSwg Y2FuIGJlIHRyaWNreS4gQW5kIHRoZW4gdGhlcmUgYXJlIGludGVyb3AtZHJpdmVuIHJ1bGVzLCBl LmcuIOKAnG5ldmVyIHNlbmQgZW1wdHkgZXh0ZW5zaW9ucyBhdCB0aGUgZW5k4oCd4pi6Lg0KDQpD aGVlcnMsDQoNCkFuZHJlaQ0KDQpGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEJpbGwgQ294DQpTZW50OiBUaHVyc2RheSwgQXByaWwgMjEsIDIwMTYg NToyNiBBTQ0KVG86IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogW1RMU10gQ2FuIHdlIHJlcXVpcmUg ZXh0ZW5zaW9ucyB0byBiZSBzb3J0ZWQ/DQoNCldlIGRpZCB0aGlzIGluIFFVSUMsIGFuZCBpdCBp cyBhIG1ham9yIHNpbXBsaWZpY2F0aW9uLiAgVGhpcyBpcyBvbmUgZmVhdHVyZSBJIHdpbGwgYmUg c2FkIHRvIGxvb3NlIHdoZW4gd2Ugc3dpdGNoIHRvIFRMUyAxLjMgZm9yIHRoZSBjcnlwdG8gaW4g UVVJQy4NCg0KSSd2ZSB3b3JrZWQgb24gMyBleHRlbnNpb25zIHNvIGZhcjogRU1TLCBjaGFubmVs IElELCBhbmQgdG9rZW4gYmluZGluZy4gIFdlIGFyZSBub3QgYWxsb3dlZCB0byBuZWdvdGlhdGUg Y2hhbm5lbCBJRCBvciB0b2tlbiBiaW5kaW5nIHVubGVzcyB3ZSBhbHNvIGhhdmUgbmVnb3RpYXRl ZCBFTVMuICBJZiBjaGFubmVsIElEIGFuZCB0b2tlbiBiaW5kaW5nIGFyZSBib3RoIG9mZmVyZWQg YnkgdGhlIGNsaWVudCwgdGhlIGJlc3QgYmVoYXZpb3IgaXMgZm9yIHNlcnZlcnMgc3VwcG9ydGlu ZyBib3RoIGlzIHRvIHBpY2sgdG9rZW4gYmluZGluZy4gIFNpbmNlIHRva2VuIGJpbmRpbmcgY2Fu IGJlIGltcGxlbWVudGVkIGFzIGEgY3VzdG9tIGV4dGVuc2lvbiwgaW4gY3VycmVudCBpbXBsZW1l bnRhdGlvbnMgaXQgaXMgbmVnb3RpYXRlZCBhZnRlciBidWlsdGluIGV4dGVuc2lvbnMsIGJ1dCBJ IGNhbm5vdCBjb3VudCBvbiB0aGF0IHdoZW4gdXNpbmcgdGhlIGN1c3RvbSBleHRlbnNpb24gQVBJ Lg0KDQpUaGUgbG9naWMgcmVxdWlyZWQgdG8gZGVhbCB3aXRoIGludGVyLWV4dGVuc2lvbiBkZXBl bmRlbmNpZXMgaXMgbm93IHNvIGNvbXBsZXggdGhhdCBUTFMgaW1wbGVtZW50YXRpb25zIGFyZSBm b3JjZWQgdG8gcHJlLXBhcnNlIGV4dGVuc2lvbnMsIGFkZGluZyBldmVuIG1vcmUgY29tcGxleGl0 eSBhbmQgbGF0ZW5jeS4gIEV2ZW4gc28sIHRoYXQgb25seSBsZXRzIGV4dGVuc2lvbnMga25vdyB0 aGF0IHRoZSBvdGhlcnMgZXhpc3Qgd2hlbiBwcm9jZXNzZWQgKHN1Y2ggYXMgRU1TIHdoZW4gcHJv Y2Vzc2luZyB0b2tlbiBiaW5kaW5nKSwgYnV0IGl0IGRvZXMgbm90IGVuc3VyZSB0aGF0IG9uZSBl eHRlbnNpb24gaGFzIHN1Y2Nlc3NmdWxseSBiZWVuIG5lZ290aWF0ZWQgYmVmb3JlIHByb2Nlc3Np bmcgYW5vdGhlci4NCg0KVGhpcyBpcyBhIG1lc3MuICBJcyBpdCB0b28gbGF0ZSB0byBtb2RpZnkg dGhlIFRMUyAxLjMgc3BlYyB0byByZXF1aXJlIGV4dGVuc2lvbnMgdG8gYmUgc2VudCBpbiBvcmRl ciBvZiB0aGVpciB0YWdzPw0KDQpJZiB3ZSB3ZXJlIHRvIGRvIHNvLCBJIHdvdWxkIHJlY29tbWVu ZCB0aGF0IHdlIHVzZSBhIGJpdC1yZXZlcnNhbCBwYXR0ZXJuIGZvciBudW1iZXJpbmcgb2ZmaWNp YWwgZXh0ZW5zaW9ucyB3aGVuIHRoZSBvcmRlciBtYWtlcyBubyBkaWZmZXJlbmNlLCBhbmQgd2hl biB0aGV5IGRvLCBwdXQgdGhlbSBpbiB0aGUgbWlkZGxlIGJldHdlZW4gZXhpc3RpbmcgZXh0ZW5z aW9ucy4gIFNvbWUgZXh0ZW5zaW9ucywgbGlrZSB0b2tlbiBiaW5kaW5nLCBhcmUgaW50ZW5kZWQg dG8gYmUgbGlnaHR3ZWlnaHQgZXh0ZW5zaW9ucyB0aGF0IGNhbiBiZSBzdXBwb3J0ZWQgdGhyb3Vn aCBhIGN1c3RvbSBleHRlbnNpb24gQVBJLiAgU3VjaCBleHRlbnNpb25zIHNob3VsZCBhbHdheXMg Y29tZSBhZnRlciB0aGUgbW9yZSBjb21wbGV4IGJ1aWx0aW4gZXh0ZW5zaW9ucywgYmVjYXVzZSBi dWlsdC1pbiBleHRlbnNpb25zIGFyZSBvZnRlbiBwcm9jZXNzZWQgaW4gc3dpdGNoIHN0YXRlbWVu dHMsIHdoaWxlIGN1c3RvbSBleHRlbnNpb25zIGhhdmUgdG8gYmUgaGFuZGxlZCBzZXBhcmF0ZWx5 LiAgSXQgaXMgbW9zdCBuYXR1cmFsIGZvciB0aGVzZSBleHRlbnNpb25zIHRvIGJlIHBhcnNlZCBh ZnRlciBidWlsdGluIGV4dGVuc2lvbnMsIHNvIG1heWJlIHRoZXkgc2hvdWxkIHN0YXJ0IHdpdGgg YSAxLCBhbmQgYnVpbHRpbiBleHRlbnNpb25zIHNob3VsZCBzdGFydCB3aXRoIGEgMC4NCg0KRm9y IGV4YW1wbGUsIGlmIHdlIGhhZCBFWFQxLCBFWFQyLCBhbmQgRVhUMyBhcyBvZmZpY2lhbCBleHRl bnNpb25zIHdpdGggbm8gc3BlY2lmaWMgb3JkZXJpbmcgbmVlZHMsIGFuZCBFWFQxLTIgdGhhdCBu ZWVkcyB0byBjb21lIGFmdGVyIEVYVDEsIGJ1dCB3YXMgZGVmaW5lZCBhZnRlciBFWFQzLCBhbmQg VEVTVEVYVDItMSB0aGF0IGlzIHN0aWxsIHVub2ZmaWNpYWwsIGJ1dCBtdXN0IGNvbWUgYWZ0ZXIg RVhUMiwgYW5kIENVU1RFWFQxIGFuZCBDVVNURVhUMiwgdGhlIHRhZ3MgbWlnaHQgbG9vayBsaWtl IChpbiBvcmRlciBvZiB3aGVuIHRoZXkgd2VyZSBkZWZpbmVkKToNCg0KRVhUMTogMA0KRVhUMjog MHg0MDAwDQpFWFQzOiAweDIwMDANCkVYVDEtMjogMHgxMDAwDQpURVNURVhUMi0xOiAweDYwYTUN CkNVU1RFWFQxOiAweDgwMDANCkNVU1RFWFQyOiAweGMwMDANCg0KVGhlIDB4NjA4YTUgc3RhcnRz IHdpdGggMHg2MCBmb3Igb3JkZXJpbmcgaGFsZiB3YXkgYmV0d2VlbiAweDQwMDAgYW5kIDB4ODAw MCwgYW5kIGhhcyBhIHJhbmRvbSBvZGQgbG93ZXIgYnl0ZSwgMHhhNSwgdG8gcmVkdWNlIGFjY2lk ZW50YWwgY29sbGlzaW9ucyBiZXR3ZWVuIFRMUyBpbXBsZW1lbnRhdGlvbnMgdGhhdCBoYXBwZW4g dG8gYmUgZXhwZXJpbWVudGluZyB3aXRoIHRlc3QgZXh0ZW5zaW9ucy4gIFRoZSBjdXN0b20gZXh0 ZW5zaW9ucyBmb2xsb3cgYSBiaXQtcmV2ZXJzYWwgcGF0dGVybiBpbiB0aGUgcmFuZ2Ugd2hlcmUg dGhlIE1TQiBpcyBzZXQuDQoNCkknbSBub3QgY29uZmlkZW50IHRoYXQgd2UgbmVlZCB0byBkaWZm ZXJlbnRpYXRlIGN1c3RvbSBleHRlbnNpb25zIGhlcmUuICBRVUlDIGRvZXMgbm90LiAgSWYgd2Ug ZG8sIHRvIGhlbHAgY2xhcmlmeSB0aGUgY3VzdG9tIGV4dGVuc2lvbiBjb25jZXB0LCB0aGVzZSBh cmUgZXh0ZW5zaW9ucyB0aGF0Og0KDQoxKSBjYW4gYmUgcHJvY2Vzc2VkIHdpdGggdHdvIGNhbGxi YWNrczogb25lIGZvciBhZGRpbmcsIG9uZSBmb3IgcGFyc2luZyAod2hpY2ggYXJlIGRpZmZlcmVu dCBvbiBjbGllbnQgdnMgc2VydmVyKQ0KMikgZG8gbm90IGtlZXAgYW55IHN0YXRlIGJldHdlZW4g cmVzdW1lcywgYW5kIGFyZSByZW5lZ290aWF0ZWQNCjMpIGNhbiBiZSBwcm9jZXNzZWQgYWZ0ZXIg YnVpbHRpbiBleHRlbnNpb25zDQoNClRoZSBpc3N1ZSBvZiBleHRlbnNpb25zIHJlcXVpcmluZyBz dGF0ZSBiZXR3ZWVuIHJlc3VtZXMgY29uZnVzZXMgbWUsIHNvIEknbGwgc2VuZCBhIHNlcGFyYXRl IGVtYWlsIGZvciBoZWxwIHVuZGVyc3RhbmRpbmcgaXQuDQoNCkJpbGwNCg== --_000_BN3PR03MB1445925980B3FFCA941D665B8C6E0BN3PR03MB1445namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdy YXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0 IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxOTk3NDE1NTA4Ow0KCW1z by1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczozMTQ4NjMwMzIgLTk5 NDU0NjUzMiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5 ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZh bWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N CkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWlu ZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xv cjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+VGhlIGxvZ2ljIHJlcXVpcmVkIHRvIGRlYWwgd2l0aCBpbnRl ci1leHRlbnNpb24gZGVwZW5kZW5jaWVzIGlzIG5vdyBzbyBjb21wbGV4IHRoYXQgVExTIGltcGxl bWVudGF0aW9ucyBhcmUgZm9yY2VkIHRvIHByZS1wYXJzZSBleHRlbnNpb25zLCBhZGRpbmcgZXZl biBtb3JlIGNvbXBsZXhpdHkgYW5kIGxhdGVuY3kuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFncmVlIGFib3V0IHRoZSBjb21wbGV4aXR5LiBUTFMg ZXh0ZW5zaW9ucyBhcmUgZXNzZW50aWFsbHkgc3ViLXByb3RvY29scyB0aGF0IGRlZmluZSB0aGVp ciBvd24gbWVzc2FnZXMsIGFuZCB0aGV5IGNhbiBiZSBpbnRlci1kZXBlbmRlbnQuIEnigJl2ZSBh bHNvIHNlZW4gcGVvcGxlDQogY29uZnVzZWQgYnkgdGhlIGZhY3QgdGhhdCBjZXJ0YWluIOKAnGV4 dGVuc2lvbnPigJ0gYXJlIGFjdHVhbGx5IG5lY2Vzc2FyeSB0byBpbXBsZW1lbnQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPklzIGl0IHRvbyBs YXRlIHRvIG1vZGlmeSB0aGUgVExTIDEuMyBzcGVjIHRvIHJlcXVpcmUgZXh0ZW5zaW9ucyB0byBi ZSBzZW50IGluIG9yZGVyIG9mIHRoZWlyIHRhZ3M/PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5J4oCZbSBub3Qgc3VyZSB0aGlzIHdvdWxkIGhlbHAuIFNv bWUgZXh0ZW5zaW9ucyBoYXZlIHRoZSBjbGllbnQgYWR2ZXJ0aXNpbmcgb3B0aW9ucyBhbmQgdGhl IHNlcnZlciBwaWNraW5nIHRoZW07IG90aGVycyBkbyB0aGUgcmV2ZXJzZS4gVGhlIG1vbWVudCBp biB0aGUgaGFuZHNoYWtlDQogd2hlcmUgdGhlIGV4dGVuc2lvbiBjYW4gYmUgY29uc2lkZXJlZCDi gJxuZWdvdGlhdGVk4oCdIGRpZmZlcnMgcGVyIGV4dGVuc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkluIG90aGVyIHdvcmRzLCB0aGUgb3JkZXIgaW4gd2hp Y2ggZXh0ZW5zaW9ucyBhcmUgcHJlc2VudGVkIGluIHRoZSBDbGllbnRIZWxsb1xTZXJ2ZXJIZWxs byBzbyBmYXIgaGFzIGJlZW4gdGhlIGxlYXN0IG9mIG15IHByb2JsZW1zLiBGaWd1cmluZyBvdXQg d2hpY2ggZXh0ZW5zaW9ucw0KIHRvIHNlbmQgYW5kIHJlc3BvbmQgdG8sIG1heGltaXppbmcgdGhl IGNoYW5jZSBvZiBzdWNjZXNzZnVsIGhhbmRzaGFrZSwgY2FuIGJlIHRyaWNreS4gQW5kIHRoZW4g dGhlcmUgYXJlIGludGVyb3AtZHJpdmVuIHJ1bGVzLCBlLmcuIOKAnG5ldmVyIHNlbmQgZW1wdHkg ZXh0ZW5zaW9ucyBhdCB0aGUgZW5k4oCdPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj5KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5BbmRyZWk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPkJpbGwgQ294PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBB cHJpbCAyMSwgMjAxNiA1OjI2IEFNPGJyPg0KPGI+VG86PC9iPiB0bHNAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gW1RMU10gQ2FuIHdlIHJlcXVpcmUgZXh0ZW5zaW9ucyB0byBiZSBzb3J0 ZWQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgZGlkIHRoaXMgaW4g UVVJQywgYW5kIGl0IGlzIGEgbWFqb3Igc2ltcGxpZmljYXRpb24uJm5ic3A7IFRoaXMgaXMgb25l IGZlYXR1cmUgSSB3aWxsIGJlIHNhZCB0byBsb29zZSB3aGVuIHdlIHN3aXRjaCB0byBUTFMgMS4z IGZvciB0aGUgY3J5cHRvIGluIFFVSUMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JJ3ZlIHdvcmtlZCBvbiAzIGV4dGVuc2lvbnMgc28gZmFyOiBFTVMsIGNo YW5uZWwgSUQsIGFuZCB0b2tlbiBiaW5kaW5nLiZuYnNwOyBXZSBhcmUgbm90IGFsbG93ZWQgdG8g bmVnb3RpYXRlIGNoYW5uZWwgSUQgb3IgdG9rZW4gYmluZGluZyB1bmxlc3Mgd2UgYWxzbyBoYXZl IG5lZ290aWF0ZWQgRU1TLiZuYnNwOyBJZiBjaGFubmVsIElEIGFuZCB0b2tlbiBiaW5kaW5nIGFy ZSBib3RoIG9mZmVyZWQgYnkgdGhlIGNsaWVudCwgdGhlDQogYmVzdCBiZWhhdmlvciBpcyBmb3Ig c2VydmVycyBzdXBwb3J0aW5nIGJvdGggaXMgdG8gcGljayB0b2tlbiBiaW5kaW5nLiZuYnNwOyBT aW5jZSB0b2tlbiBiaW5kaW5nIGNhbiBiZSBpbXBsZW1lbnRlZCBhcyBhIGN1c3RvbSBleHRlbnNp b24sIGluIGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIGl0IGlzIG5lZ290aWF0ZWQgYWZ0ZXIgYnVp bHRpbiBleHRlbnNpb25zLCBidXQgSSBjYW5ub3QgY291bnQgb24gdGhhdCB3aGVuIHVzaW5nIHRo ZSBjdXN0b20gZXh0ZW5zaW9uDQogQVBJLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgbG9naWMgcmVxdWlyZWQgdG8gZGVhbCB3aXRoIGlu dGVyLWV4dGVuc2lvbiBkZXBlbmRlbmNpZXMgaXMgbm93IHNvIGNvbXBsZXggdGhhdCBUTFMgaW1w bGVtZW50YXRpb25zIGFyZSBmb3JjZWQgdG8gcHJlLXBhcnNlIGV4dGVuc2lvbnMsIGFkZGluZyBl dmVuIG1vcmUgY29tcGxleGl0eSBhbmQgbGF0ZW5jeS4mbmJzcDsgRXZlbiBzbywgdGhhdCBvbmx5 IGxldHMgZXh0ZW5zaW9ucyBrbm93IHRoYXQgdGhlIG90aGVycw0KIGV4aXN0IHdoZW4gcHJvY2Vz c2VkIChzdWNoIGFzIEVNUyB3aGVuIHByb2Nlc3NpbmcgdG9rZW4gYmluZGluZyksIGJ1dCBpdCBk b2VzIG5vdCBlbnN1cmUgdGhhdCBvbmUgZXh0ZW5zaW9uIGhhcyBzdWNjZXNzZnVsbHkgYmVlbiBu ZWdvdGlhdGVkIGJlZm9yZSBwcm9jZXNzaW5nIGFub3RoZXIuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgYSBtZXNzLiZuYnNwOyBJ cyBpdCB0b28gbGF0ZSB0byBtb2RpZnkgdGhlIFRMUyAxLjMgc3BlYyB0byByZXF1aXJlIGV4dGVu c2lvbnMgdG8gYmUgc2VudCBpbiBvcmRlciBvZiB0aGVpciB0YWdzPzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB3ZSB3ZXJlIHRvIGRvIHNv LCBJIHdvdWxkIHJlY29tbWVuZCB0aGF0IHdlIHVzZSBhIGJpdC1yZXZlcnNhbCBwYXR0ZXJuIGZv ciBudW1iZXJpbmcgb2ZmaWNpYWwgZXh0ZW5zaW9ucyB3aGVuIHRoZSBvcmRlciBtYWtlcyBubyBk aWZmZXJlbmNlLCBhbmQgd2hlbiB0aGV5IGRvLCBwdXQgdGhlbSBpbiB0aGUgbWlkZGxlIGJldHdl ZW4gZXhpc3RpbmcgZXh0ZW5zaW9ucy4mbmJzcDsgU29tZSBleHRlbnNpb25zLCBsaWtlDQogdG9r ZW4gYmluZGluZywgYXJlIGludGVuZGVkIHRvIGJlIGxpZ2h0d2VpZ2h0IGV4dGVuc2lvbnMgdGhh dCBjYW4gYmUgc3VwcG9ydGVkIHRocm91Z2ggYSBjdXN0b20gZXh0ZW5zaW9uIEFQSS4mbmJzcDsg U3VjaCBleHRlbnNpb25zIHNob3VsZCBhbHdheXMgY29tZSBhZnRlciB0aGUgbW9yZSBjb21wbGV4 IGJ1aWx0aW4gZXh0ZW5zaW9ucywgYmVjYXVzZSBidWlsdC1pbiBleHRlbnNpb25zIGFyZSBvZnRl biBwcm9jZXNzZWQgaW4gc3dpdGNoIHN0YXRlbWVudHMsDQogd2hpbGUgY3VzdG9tIGV4dGVuc2lv bnMgaGF2ZSB0byBiZSBoYW5kbGVkIHNlcGFyYXRlbHkuJm5ic3A7IEl0IGlzIG1vc3QgbmF0dXJh bCBmb3IgdGhlc2UgZXh0ZW5zaW9ucyB0byBiZSBwYXJzZWQgYWZ0ZXIgYnVpbHRpbiBleHRlbnNp b25zLCBzbyBtYXliZSB0aGV5IHNob3VsZCBzdGFydCB3aXRoIGEgMSwgYW5kIGJ1aWx0aW4gZXh0 ZW5zaW9ucyBzaG91bGQgc3RhcnQgd2l0aCBhIDAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBleGFtcGxlLCBpZiB3ZSBoYWQgRVhUMSwg RVhUMiwgYW5kIEVYVDMgYXMgb2ZmaWNpYWwgZXh0ZW5zaW9ucyB3aXRoIG5vIHNwZWNpZmljIG9y ZGVyaW5nIG5lZWRzLCBhbmQgRVhUMS0yIHRoYXQgbmVlZHMgdG8gY29tZSBhZnRlciBFWFQxLCBi dXQgd2FzIGRlZmluZWQgYWZ0ZXIgRVhUMywgYW5kIFRFU1RFWFQyLTEgdGhhdCBpcyBzdGlsbCB1 bm9mZmljaWFsLCBidXQgbXVzdCBjb21lIGFmdGVyIEVYVDIsDQogYW5kIENVU1RFWFQxIGFuZCBD VVNURVhUMiwgdGhlIHRhZ3MgbWlnaHQgbG9vayBsaWtlIChpbiBvcmRlciBvZiB3aGVuIHRoZXkg d2VyZSBkZWZpbmVkKTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RVhUMTogMDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+RVhUMjogMHg0MDAwPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FWFQzOiAweDIwMDA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVYVDEtMjogMHgxMDAwPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5URVNURVhUMi0xOiAweDYw YTU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNV U1RFWFQxOiAweDgwMDA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkNVU1RFWFQyOiAweGMwMDA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIDB4NjA4YTUgc3RhcnRzIHdpdGggMHg2MCBmb3Ig b3JkZXJpbmcgaGFsZiB3YXkgYmV0d2VlbiAweDQwMDAgYW5kIDB4ODAwMCwgYW5kIGhhcyBhIHJh bmRvbSBvZGQgbG93ZXIgYnl0ZSwgMHhhNSwgdG8gcmVkdWNlIGFjY2lkZW50YWwgY29sbGlzaW9u cyBiZXR3ZWVuIFRMUyBpbXBsZW1lbnRhdGlvbnMgdGhhdCBoYXBwZW4gdG8gYmUgZXhwZXJpbWVu dGluZyB3aXRoIHRlc3QgZXh0ZW5zaW9ucy4mbmJzcDsgVGhlDQogY3VzdG9tIGV4dGVuc2lvbnMg Zm9sbG93IGEgYml0LXJldmVyc2FsIHBhdHRlcm4gaW4gdGhlIHJhbmdlIHdoZXJlIHRoZSBNU0Ig aXMgc2V0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JJ20gbm90IGNvbmZpZGVudCB0aGF0IHdlIG5lZWQgdG8gZGlmZmVyZW50aWF0ZSBjdXN0 b20gZXh0ZW5zaW9ucyBoZXJlLiZuYnNwOyBRVUlDIGRvZXMgbm90LiZuYnNwOyBJZiB3ZSBkbywg dG8gaGVscCBjbGFyaWZ5IHRoZSBjdXN0b20gZXh0ZW5zaW9uIGNvbmNlcHQsIHRoZXNlIGFyZSBl eHRlbnNpb25zIHRoYXQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjEpIGNhbiBiZSBwcm9jZXNzZWQgd2l0aCB0d28gY2FsbGJhY2tzOiBvbmUg Zm9yIGFkZGluZywgb25lIGZvciBwYXJzaW5nICh3aGljaCBhcmUgZGlmZmVyZW50IG9uIGNsaWVu dCB2cyBzZXJ2ZXIpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4yKSBkbyBub3Qga2VlcCBhbnkgc3RhdGUgYmV0d2VlbiByZXN1bWVzLCBhbmQgYXJl IHJlbmVnb3RpYXRlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+MykgY2FuIGJlIHByb2Nlc3NlZCBhZnRlciBidWlsdGluIGV4dGVuc2lvbnM8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGlz c3VlIG9mIGV4dGVuc2lvbnMgcmVxdWlyaW5nIHN0YXRlIGJldHdlZW4gcmVzdW1lcyBjb25mdXNl cyBtZSwgc28gSSdsbCBzZW5kIGEgc2VwYXJhdGUgZW1haWwgZm9yIGhlbHAgdW5kZXJzdGFuZGlu ZyBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QmlsbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_BN3PR03MB1445925980B3FFCA941D665B8C6E0BN3PR03MB1445namp_-- From nobody Thu Apr 21 10:53:09 2016 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 8B62E12E9DC for ; Thu, 21 Apr 2016 10:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgqdNvU8cytl for ; Thu, 21 Apr 2016 10:53:06 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 832CF12E49A for ; Thu, 21 Apr 2016 10:53:06 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id n67so93967274vkf.3 for ; Thu, 21 Apr 2016 10:53:06 -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; bh=xJoJKzyNpF5dTkOdpCvaLLrxACsFBxY82LKguJesMTQ=; b=tD0bqpPkBQzAxJNPvJftN47/FJLPL1ZK6XCA1saB1LNiSJKrvQkav3+filg/69vSrd 30bhCM1+LaTH7+nrgKuXmhojKwGtJaa/GIjDZNVy3U80vhR0VtWBeKH+ws6ANTCi8jbq bGZkKyMP5I5iZ7LzeJxvuqunkEpEtUWnU+lRIEFKvf0yqH9XFdU+UL0+4YuBHq9kWeQV fyVcmhMO0P9hsE9K3pa3GYUTM6iGup6TocNfKIh3H2MH43IV3HymIToHAIN9HT9kzyQi xoaSuTwY5KcWqPAZMnJS5S+tPVkAYe6S5I0cgs0I8aaCN+GIYOhMxLR0E7Lx/twtl004 6K7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=xJoJKzyNpF5dTkOdpCvaLLrxACsFBxY82LKguJesMTQ=; b=gGPbUNt+Pp+vldw6DGwZXHu7pKuv0pOUnW7efSm7QhQ+y8RO1hPx5svZBGpB0qmY7G c/bCBbuf/Uka4eh5a+F20xktPkjEH7Ml33YpgiDuwB4TdGjSepyjNwg89Timdnv8LPSz mVoaOYraHkxDAJHUAeW7UFl96bH6EGqinhG2IDqsOUiiCqKGNuwk0cwW7jje5YGAl6au fXlu631m6X9RuOG7dh7ViSeBOFHSodpotNZrgTOyo/hi1QFN3bfNBcEXmdGHF2XGByyp TAQIkOBni8xsia0q3pjMUFvhzsRdDmIuaOypKVnRukXOL1JvHh8yYohPtiCYspQB2+PO xUlw== X-Gm-Message-State: AOPr4FUcGIxnnnwkG0mgAMpiPptb9Dlq4fLRWddELXzzm96y8Ek43UpwpY2aaGgtmsJl81nXQJmew0zN6ruDTQ== MIME-Version: 1.0 X-Received: by 10.31.58.83 with SMTP id h80mr8652003vka.149.1461261185176; Thu, 21 Apr 2016 10:53:05 -0700 (PDT) Received: by 10.176.64.68 with HTTP; Thu, 21 Apr 2016 10:53:04 -0700 (PDT) Received: by 10.176.64.68 with HTTP; Thu, 21 Apr 2016 10:53:04 -0700 (PDT) In-Reply-To: References: <2583177.ZKtSIvTJKQ@pintsize.usersys.redhat.com> Date: Thu, 21 Apr 2016 10:53:04 -0700 Message-ID: From: Watson Ladd To: Hubert Kario Content-Type: multipart/alternative; boundary=001a114389d4dddd9a05310261ec Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Can we require extensions to be sorted? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2016 17:53:08 -0000 --001a114389d4dddd9a05310261ec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 21, 2016 at 8:24 AM, Hubert Kario wrote: > On Thursday 21 April 2016 05:26:21 Bill Cox wrote: >> We did this in QUIC, and it is a major simplification. This is one >> feature I will be sad to loose when we switch to TLS 1.3 for the >> crypto in QUIC. >> >> I've worked on 3 extensions so far: EMS, channel ID, and token >> binding. We are not allowed to negotiate channel ID or token binding >> unless we also have negotiated EMS. If channel ID and token binding >> are both offered by the client, the best behavior is for servers >> supporting both is to pick token binding. Since token binding can be >> implemented as a custom extension, in current implementations it is >> negotiated after builtin extensions, but I cannot count on that when >> using the custom extension API. >> >> The logic required to deal with inter-extension dependencies is now so >> complex that TLS implementations are forced to pre-parse extensions, >> adding even more complexity and latency. Even so, that only lets >> extensions know that the others exist when processed (such as EMS >> when processing token binding), but it does not ensure that one >> extension has successfully been negotiated before processing another. Oh nyo! Shotgun parsing doesn't work: I might actually have to write a real parser like Sergey Bratus is always on about. Maybe I'll even ensure that the input is well-formed, so I don't blindly go ahead and copy more to the output then was actually there. If only there was a 50 year old book to tell me how to write parsers. > > I don't follow. > > If you understand given extension, you must reject Client Hello if that > extension is malformed. > > If one extension depends on other extension, you just need to check if > it is present. > > I don't see how single array lookup is overly complex, to the point that > we need to assign new IDs to existing extensions. If we really want a simpler TLS, let's switch to QUIC. > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. --001a114389d4dddd9a05310261ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Apr 21, 2016 at 8:24 AM, Hubert Kario <hkario@redhat.com> wrote:
> On Thursday 21 April 2016 05:26:21 Bill Cox wrote:
>> We did this in QUIC, and it is a major simplification. This is one=
>> feature I will be sad to loose when we switch to TLS 1.3 for the >> crypto in QUIC.
>>
>> I've worked on 3 extensions so far: EMS, channel ID, and token=
>> binding. We are not allowed to negotiate channel ID or token bindi= ng
>> unless we also have negotiated EMS. If channel ID and token bindin= g
>> are both offered by the client, the best behavior is for servers >> supporting both is to pick token binding. Since token binding can = be
>> implemented as a custom extension, in current implementations it i= s
>> negotiated after builtin extensions, but I cannot count on that wh= en
>> using the custom extension API.
>>
>> The logic required to deal with inter-extension dependencies is no= w so
>> complex that TLS implementations are forced to pre-parse extension= s,
>> adding even more complexity and latency. Even so, that only lets >> extensions know that the others exist when processed (such as EMS<= br> >> when processing token binding), but it does not ensure that one >> extension has successfully been negotiated before processing anoth= er.

Oh nyo! Shotgun parsing doesn't work: I might actually h= ave to write a real parser like Sergey Bratus is always on about. Maybe I&#= 39;ll even ensure that the input is well-formed, so I don't blindly go = ahead and copy more to the output then was actually there. If only there wa= s a 50 year old book to tell me how to write parsers.

>
> I don't follow.
>
> If you understand given extension, you must reject Client Hello if tha= t
> extension is malformed.
>
> If one extension depends on other extension, you just need to check if=
> it is present.
>
> I don't see how single array lookup is overly complex, to the poin= t that
> we need to assign new IDs to existing extensions.

If we really want a simpler TLS, let's switch to QUIC. > --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republ= ic
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls
>

--
"Man is born free, but everywhere he is in chains".
--Rousseau.

--001a114389d4dddd9a05310261ec-- From nobody Thu Apr 21 10:54:41 2016 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 AC36812DC1E for ; Thu, 21 Apr 2016 10:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gKF2t4q2EsI for ; Thu, 21 Apr 2016 10:54:34 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 84AD212DB31 for ; Thu, 21 Apr 2016 10:54:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id CEA432BDD; Thu, 21 Apr 2016 20:54:33 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 7r3_27ITibhQ; Thu, 21 Apr 2016 20:54:33 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 931AD286; Thu, 21 Apr 2016 20:54:33 +0300 (EEST) Date: Thu, 21 Apr 2016 20:54:31 +0300 From: Ilari Liusvaara To: Bill Cox Message-ID: <20160421175430.GA26016@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160421144049.GB24969@LK-Perkele-V2.elisa-laajakaista.fi> <20160421152845.GA25769@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions and state during a resume X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2016 17:54:37 -0000 On Thu, Apr 21, 2016 at 09:32:30AM -0700, Bill Cox wrote: > I'm just going through an example which is related to what I work on, which > currently is token binding. Client certs are very similar. > > If client certs (or token binding) were supported by the server, as well as > replay protection, then I would prefer to send the ClientVerify message in > a PSK 0-RTT resume. Without replay protection, I would prefer to avoid > client certs and token binding. 0-RTT client certificate auth is very annoying to implement properly. In fact, any handshake messages in 0-RTT causes the 0-RTT to couple into the main handshake state machine. This causes all sorts of less than fun problems with implementing it properly. Also, 1-RTT client certs with GDHE-PSK are much less annoying, but wonder how many will get that right, given that TLS 1.2 doesn't support that, only client certs for GDHE-CERT... > Basically, I think we have two choices for remembering server feature > support, which is required when doing PSK 0-RTT: > > 1) negotiate all supported features in the 1-RTT handshake and use session > caches to remember the results > 2) use server configs instead > > Given all the bugs resulting from 1), I think I prefer 2). 3) Eliminate any coupling between connections to the extent possible. -Ilari From nobody Thu Apr 21 11:47:11 2016 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 599C512E97F for ; Thu, 21 Apr 2016 11:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtRk8XSeKh3p for ; Thu, 21 Apr 2016 11:47:07 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0133.outbound.protection.outlook.com [207.46.100.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12C2012DED4 for ; Thu, 21 Apr 2016 11:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=k9xc/csfIvneDQv5hS8qK0+dWpmHjvD7miu10irIFYI=; b=H1mQISzkccSJ01jMXa3977XdG45iQo0a2ReWVJfDxSXEzPrpJgX8TAMnV8UpEmcM+IlFcsdf9bZCTLto0TUP16coNyBSweE41b+iK5HdaumMVHWOfxWbYgkktnqh5jQ5irhFEh/KHZOSajqIaNMcGl0/VATmeBlud5OXWKHK4eg= Received: from BN3PR03MB1445.namprd03.prod.outlook.com (10.163.34.28) by BN3PR03MB1448.namprd03.prod.outlook.com (10.163.35.11) with Microsoft SMTP Server (TLS) id 15.1.466.19; Thu, 21 Apr 2016 18:47:03 +0000 Received: from BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) by BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) with mapi id 15.01.0466.023; Thu, 21 Apr 2016 18:47:03 +0000 From: Andrei Popov To: Ilari Liusvaara , Bill Cox Thread-Topic: [TLS] Extensions and state during a resume Thread-Index: AQHRm8+E6DErGREsb0qdZ2i+yfrUi5+Uf/iAgAAHAYCAAAZkgIAACV6AgAAIcQCAABbrgIAACmKQ Date: Thu, 21 Apr 2016 18:47:02 +0000 Message-ID: References: <20160421144049.GB24969@LK-Perkele-V2.elisa-laajakaista.fi> <20160421152845.GA25769@LK-Perkele-V2.elisa-laajakaista.fi> <20160421175430.GA26016@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160421175430.GA26016@LK-Perkele-V2.elisa-laajakaista.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: welho.com; dkim=none (message not signed) header.d=none;welho.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:7::1d2] x-ms-office365-filtering-correlation-id: 7d1cb54a-fe59-40f6-ae4c-08d36a155447 x-microsoft-exchange-diagnostics: 1; BN3PR03MB1448; 5:Gt8odimhjhKLo6lUOGBn/N+/NMchSmRvGfIVEl4VhBzW6U7XPc5qJa807qrHDchUV7XzYXAHxoUTpeMAkxJGOcCJy1wqPnLAES8LtzDPi4cffVjBTB7dVKpUy2DSasi+7D3zJxJli4DScuxSbyfMtSUpRQIoph3hdQnPa/RZYrrZJlGzxL6UMw3euul6aFt7; 24:oozftiRHYD6lMvXDB0AASJm3hxuLfdoIzRF2pNQw2WoMm/vNYVamD/8X95HxA6echEbQZGftlwMHY3HXtO+mPgyVYjRtPGBamHu9VnK9kgQ=; 7:Gwg9I6NHWsTz2PwJO6PprbTY/YrYQAK5+GMBaN3vqtE/n+QCpn2BeswMOjvrLANsO6ZEWJIiXQ/l+x+f31VRWbipHvB3AsuVN3VANyIe/YpvZQUu+aku1ccOsp4SZwiVXCgGh3YnAkO4YaOSqd+1L5hkWFRGtNAmePjf4D8xCRY01kX7XrFlOpDAYuYKi2svP/BSULQ7TsdSqtDfNR8Li4pZOEV3JGu2/RWWV67FY75ol687Qrehpp+dgLq3TrFF x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1448; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN3PR03MB1448; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1448; x-forefront-prvs: 091949432C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(13464003)(5002640100001)(2900100001)(1096002)(102836003)(4326007)(6116002)(19580405001)(19580395003)(8990500004)(10090500001)(86612001)(122556002)(86362001)(1220700001)(5003600100002)(586003)(15975445007)(93886004)(77096005)(2950100001)(99286002)(106116001)(81166005)(74316001)(5004730100002)(54356999)(50986999)(5001770100001)(5005710100001)(10400500002)(10290500002)(3660700001)(92566002)(3280700002)(9686002)(76576001)(76176999)(33656002)(5008740100001)(189998001)(2906002)(87936001)(11100500001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB1448; H:BN3PR03MB1445.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2016 18:47:02.9275 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1448 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions and state during a resume X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2016 18:47:09 -0000 > In TLS 1.3 we have the concept of the resume master secret (RMS). Ideall= y, this is all that would be needed, in addition to the new ticket, to resu= me. Even without any extensions, the client needs to remember certain things ab= out the TLS session, e.g. negotiated protocol version, cipher suite, curve,= server cert, session lifetime info... Some of this could be stored per ser= ver, rather than per session, but that's implementation-specific details. I= agree that we should minimize protocol features (including extensions) tha= t increase the size of the session state, esp. on the server side. > This would make it simpler and safer to write the RMS and ticket to disk,= considerably improving resumption rates. The RMS is also a candidate for = storing more securely than a full session state. MS TLS stack does not currently store session cache items or resumptions se= crets on disk, so I'm curious: why is it easier to store and protect RMS al= one, rather than storing a session cache item that contains RMS? Isn't it j= ust a BLOB in either case, from the perspective of protected storage? Thanks, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ilari Liusvaara Sent: Thursday, April 21, 2016 10:55 AM To: Bill Cox Cc: tls@ietf.org Subject: Re: [TLS] Extensions and state during a resume On Thu, Apr 21, 2016 at 09:32:30AM -0700, Bill Cox wrote: > I'm just going through an example which is related to what I work on, whi= ch > currently is token binding. Client certs are very similar. >=20 > If client certs (or token binding) were supported by the server, as well = as > replay protection, then I would prefer to send the ClientVerify message i= n > a PSK 0-RTT resume. Without replay protection, I would prefer to avoid > client certs and token binding. 0-RTT client certificate auth is very annoying to implement properly. In fact, any handshake messages in 0-RTT causes the 0-RTT to couple into the main handshake state machine. This causes all sorts of less than fun problems with implementing it properly. Also, 1-RTT client certs with GDHE-PSK are much less annoying, but wonder how many will get that right, given that TLS 1.2 doesn't support that, only client certs for GDHE-CERT... > Basically, I think we have two choices for remembering server feature > support, which is required when doing PSK 0-RTT: >=20 > 1) negotiate all supported features in the 1-RTT handshake and use sessio= n > caches to remember the results > 2) use server configs instead >=20 > Given all the bugs resulting from 1), I think I prefer 2). 3) Eliminate any coupling between connections to the extent possible. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Thu Apr 21 11:55:12 2016 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 5C40F12D585 for ; Thu, 21 Apr 2016 11:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJlWPhEWI7dH for ; Thu, 21 Apr 2016 11:55:08 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BE3D12D1C8 for ; Thu, 21 Apr 2016 11:55:08 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id e185so109300412vkb.1 for ; Thu, 21 Apr 2016 11:55:08 -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; bh=Sl/KmaunuUZrx3NvH5GY3KtJ3zvuRxONoPK+84BgrnQ=; b=QYSNlXMClaS+su0I1DnAUJ4QUbLczFgUz2+JKmsw0cyxYeNLVoXwbjieBEC3zRLtlt 9oPL0lR3IikJY4HIqfolbn4DltMWj//vBs6356VXtu58JRXYyjKTKRPgKXqug3Wuz6Ns pDE9SOy1TMllp5QIBfoPMoQ8NQRRq1Z+xcLzyUKNhGW4TJ5cnVKpFUCS46PLKgcgiew/ s6xbbkpHRx18/Z8cYjrXc5rTREOQMZbq8PLmnmKMXYhgOf2QzDkkZzIKkk0rXL+//JYN yGXm7kkedYtQi6lCOgfOuroYuW02eXahq+xmaEVXb2j/D7WSXkc7Z6P3GbfqdrTE0k5z HWCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Sl/KmaunuUZrx3NvH5GY3KtJ3zvuRxONoPK+84BgrnQ=; b=KBUvRaQOkrXrfcHBttXP8wuPe68vsF+uWfX4GcKLfWzamajoW5NXDIhS5MPiya5hcQ mWp+aDsUvZ60GV2XByV0lpITDalpCD20dooqlEt3s7hOJbQaQGdFyHg+vZDXXlzYYqpM togpHbsb5w8wU0iUG40EcNlxrMGnmCNNs2sqeeff7JtkXosxHj5atvaVo+fqkHRkvyqb PNk78lTvMafVl0xUwpK9feJcUIMn9J2buEMLdCHB4gE9bMtySvk4XvdpKpGDYtVtEOiV o6MZ5O4YaklmkjUh5wy1EKK0/vLVeYw62IrQrBJH33w8NE2r62glKUcHPXZamNK9DdwJ LMzQ== X-Gm-Message-State: AOPr4FXty8mjrj/wNBcDceFrBwX9jPfZHHfI+qu5tIKzTY5lXLYkczojUap1piCstM4y01mVx4xVPjej14wFWr2F MIME-Version: 1.0 X-Received: by 10.176.0.106 with SMTP id 97mr8674411uai.113.1461264907430; Thu, 21 Apr 2016 11:55:07 -0700 (PDT) Received: by 10.31.209.196 with HTTP; Thu, 21 Apr 2016 11:55:07 -0700 (PDT) In-Reply-To: <20160421175430.GA26016@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160421144049.GB24969@LK-Perkele-V2.elisa-laajakaista.fi> <20160421152845.GA25769@LK-Perkele-V2.elisa-laajakaista.fi> <20160421175430.GA26016@LK-Perkele-V2.elisa-laajakaista.fi> Date: Thu, 21 Apr 2016 11:55:07 -0700 Message-ID: From: Bill Cox To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a113e4d9cbb3ffe0531033fb6 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions and state during a resume X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2016 18:55:10 -0000 --001a113e4d9cbb3ffe0531033fb6 Content-Type: text/plain; charset=UTF-8 I was able to chat a bit with someone who had been to the recent IETF meeting and has more insight into the current state of things. The most important insight is that it seems that TLS 1.3 will be going with a TLS 1.2 style serialized session state. Server-configs mean the server offers security parameters and the client chooses, which is backwards from TLS 1.2. That would be too hard to merge into the existing TLS code base. On Thu, Apr 21, 2016 at 10:54 AM, Ilari Liusvaara wrote: > 0-RTT client certificate auth is very annoying to implement properly. In > fact, any handshake messages in 0-RTT causes the 0-RTT to couple into > the main handshake state machine. This causes all sorts of less than fun > problems with implementing it properly. > Yep. Unfortunately it looks like this particular form of TLS complexity is going to be inherited in TLS 1.3. Channel ID is also a very complex addition, which is one motivation for moving to token binding, to get that complexity out of the TLS state machine. > > Basically, I think we have two choices for remembering server feature > > support, which is required when doing PSK 0-RTT: > > > > 1) negotiate all supported features in the 1-RTT handshake and use > session > > caches to remember the results > > 2) use server configs instead > > > > Given all the bugs resulting from 1), I think I prefer 2). > > 3) Eliminate any coupling between connections to the extent possible. > Looks like we're going with 1). It's ugly, but I think I understand the motivation now. Maybe we can finally dump the coupling between connections in TLS 2.0 :) I am very concerned that the default mode of operation for popular web server software might be stateless PSK 0-RTT. My main concern is that most web sites out there have too little testing for resistance to infinite replay of 0-RTT requests. My preference would be for the default mode to be 1-RTT only, and if admins enable 0-RTT, replay protection would be enabled by default. Turning on 0-RTT and turning off replay protection should be a conscious and well-informed choice, IMO. It also sounds like the proposal to inform the client in the new ticket whether or not the server supports replay is not popular, but that the client will most likely be informed of whether the server supports PSK 0-RTT resumption. I think servers supporting replay protection should be allowed (but not required) to let authenticated clients connect with 0-RTT resumption, and servers without replay protection should only offer authenticated clients 1-RTT resumption, or drop client authentication. Bill --001a113e4d9cbb3ffe0531033fb6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was able to chat a bit with someone who had been to the = recent IETF meeting and has more insight into the current state of things.= =C2=A0 The most important insight is that it seems that TLS 1.3 will be goi= ng with a TLS 1.2 style serialized session state.=C2=A0 Server-configs mean= the server offers security parameters and the client chooses, which is bac= kwards from TLS 1.2.=C2=A0 That would be too hard to merge into the existin= g TLS code base.

On Thu, Apr 21, 2016 at 10:54 AM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
0-RTT c= lient certificate auth is very annoying to implement properly. In
fact, any handshake messages in 0-RTT causes the 0-RTT to couple into
the main handshake state machine. This causes all sorts of less than fun problems with implementing it properly.

Yep.=C2=A0 Unfortunately it looks like this particular form of TLS complex= ity is going to be inherited in TLS 1.3.=C2=A0 Channel ID is also a very co= mplex addition, which is one motivation for moving to token binding, to get= that complexity out of the TLS state machine.


> Basically, I think we have two choices for remembering server feature<= br> > support, which is required when doing PSK 0-RTT:
>
> 1) negotiate all supported features in the 1-RTT handshake and use ses= sion
> caches to remember the results
> 2) use server configs instead
>
> Given all the bugs resulting from 1), I think I prefer 2).

3) Eliminate any coupling between connections to the extent possible= .

Looks like we're going with 1).= =C2=A0 It's ugly, but I think I understand the motivation now.=C2=A0 Ma= ybe we can finally dump the coupling between connections in TLS 2.0 :)

I am very concerned that the default mode of operation= for popular web server software might be stateless PSK 0-RTT.=C2=A0 My mai= n concern is that most web sites out there have too little testing for resi= stance to infinite replay of 0-RTT requests.=C2=A0 My preference would be f= or the default mode to be 1-RTT only, and if admins enable 0-RTT, replay pr= otection would be enabled by default.=C2=A0 Turning on 0-RTT and turning of= f replay protection should be a conscious and well-informed choice, IMO.

It also sounds like the proposal to inform the clien= t in the new ticket whether or not the server supports replay is not popula= r, but that the client will most likely be informed of whether the server s= upports PSK 0-RTT resumption.=C2=A0 I think servers supporting replay prote= ction should be allowed (but not required) to let authenticated clients con= nect with 0-RTT resumption, and servers without replay protection should on= ly offer authenticated clients 1-RTT resumption, or drop client authenticat= ion.

Bill
--001a113e4d9cbb3ffe0531033fb6-- From nobody Thu Apr 21 12:03:17 2016 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 C9D9512DBFD for ; Thu, 21 Apr 2016 12:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVGmn0lwe5JS for ; Thu, 21 Apr 2016 12:03:14 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 3F65012DA1A for ; Thu, 21 Apr 2016 12:03:14 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 870B020009E for ; Thu, 21 Apr 2016 19:03:13 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 6801220009A for ; Thu, 21 Apr 2016 19:03:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1461265393; bh=XM7F8V6vkDXT4wueBwuC2Ao6FNbmqZG8JHQC3huR5jY=; l=2932; h=From:To:Date:From; b=Xpnzj3j7HZg2cvXy/obugazaen9mw95p5t7HP7n+MvWBgh0O/f/dVshZ4gkN5fmKm jrJoS3yOzg+ukyqzmCiHSR3fzHY9+i3UtKL+DLluoCCrtCLSctj+1tXQwGSQGY6Avu 0a7BYlFxVs3jS1/RXsQqGGDgIFssZ6YQnHTtK3Mw= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 4F6F598082 for ; Thu, 21 Apr 2016 19:03:13 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 21 Apr 2016 15:03:12 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Thu, 21 Apr 2016 15:03:12 -0400 From: "Salz, Rich" To: "tls@ietf.org" Thread-Topic: TLS testing kit Thread-Index: AdGcAGuhO8Uy0EWeQ9KcSe0TLoHX+Q== Date: Thu, 21 Apr 2016 19:03:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.6] Content-Type: multipart/alternative; boundary="_000_fd7cfb4ca71d4ddca552ef784d8bd02eusma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: [TLS] TLS testing kit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2016 19:03:16 -0000 --_000_fd7cfb4ca71d4ddca552ef784d8bd02eusma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable https://github.com/rub-nds/tls-attacker Very impressive. Had some good impacts on OpenSSL :) -- Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz --_000_fd7cfb4ca71d4ddca552ef784d8bd02eusma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= https://github.com/rub-nds/tls-attacker

 

Very impressive.  Had some good impacts on Open= SSL J

 

-- 

Senior Architect, Akamai Technologies

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

--_000_fd7cfb4ca71d4ddca552ef784d8bd02eusma1exdag1mb1msgcorpak_-- From nobody Thu Apr 21 15:01:19 2016 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 3640212E5A8 for ; Thu, 21 Apr 2016 15:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDTbxjJVErdl for ; Thu, 21 Apr 2016 15:01:12 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2363712E19A for ; Thu, 21 Apr 2016 15:01:12 -0700 (PDT) Received: by mail-ig0-x22d.google.com with SMTP id f1so170110604igr.1 for ; Thu, 21 Apr 2016 15:01:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=262dr6GcqFCxFjFKsnrz8vLnF81eZCxBfgAm7VQEZEk=; b=FuF6ShUXOgahvT7XQFbRXavteceCyNRierLmoasUbsY+0DrUaEeSueJntXSfXkG7JV rPFb5BxGBg0qfEeSskByvX7GYC7ZL5e2tc3EdzyubzeTTJuEBB5QJzOt0B+jEpCKUA1l gGimnhYq6p2n4ZlObJc0LNCkswMy+h9/L9eA10gTO1N7hR1i6qPodkgmMQsXP9wj/lIY uPyBldaUgJWztP6nTkP0oSoKh/+7CO2Dw1h4TZoiAllbIRjGtp1lFEEqtPdIxp2zNRvt FgIzYWgGkTY81QoESBzc98YHVHd2mpjVVO4jqRskJo9tV5BKkmFaEHK8JRmOcYGEdaI6 2G9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=262dr6GcqFCxFjFKsnrz8vLnF81eZCxBfgAm7VQEZEk=; b=mvwVaUHO+N/EO7gKnpbhCth6ck3MoQpvVUumQUbGD1XyvNsxtZptdFazKLdzr0izpi Vwjz0bKsRqCWSV8EGwuVi0es3vHGoW5iVK8004xC8WVifYO/qEXq0h5gE1w2+OWO+BTN vu5kfEb9+T/d6ZEmFBiGH8Du70kLfRwjK+pGxwixRWxvqXco5zEmJYd7onOtys6OcFKM V46f4mm8P5q5vvzTTGCbOZkmpBZwFpMUtUoDHEmqgqCc7r0jZckYbuROc1QmyVeBxDnA WXyYHdz+XLAK9nAlzc8/u7BUL3RXmj1E0T9EhRWeZzir8kKLIrLdOwMJjN50rVxSwWV6 6FUA== X-Gm-Message-State: AOPr4FUhK1nOlcvXOK3kqAA4qtWaKw4JtK3PzlhHkqxEQm/mb0ryA+2X+v01P3rjlg+cLQSLl+KzQG6iNF19bQ== MIME-Version: 1.0 X-Received: by 10.50.30.73 with SMTP id q9mr315276igh.77.1461276071291; Thu, 21 Apr 2016 15:01:11 -0700 (PDT) Received: by 10.36.43.82 with HTTP; Thu, 21 Apr 2016 15:01:11 -0700 (PDT) In-Reply-To: <20160421144049.GB24969@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160421144049.GB24969@LK-Perkele-V2.elisa-laajakaista.fi> Date: Fri, 22 Apr 2016 08:01:11 +1000 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions and state during a resume X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Apr 2016 22:01:18 -0000 On 22 April 2016 at 00:40, Ilari Liusvaara wrote: > > My understanding is that TLS 1.3 replaces the entiere resumption with > what is essentially dynamic PSK provosioning. So state to be remembered > is to be kept at minimum. This is a point that is not clear, but here's my view on it: Unlike pure PSK, using PSK for resumption needs to always come with enough information to fall back to a full handshake. This means signaling a non-PSK cipher suite and all the extensions that you would normally include in a ClientHello. Thus, anything that depends on the state of those extensions is covered. (For the most part, those extensions only apply to subsequent connections.) As for what you need to remember for the 0-RTT data. Well, by default that's everything, unless you know that you can forget it. We agreed at the meeting that 0-RTT data would not explicitly signal parameters, so peers would have to remember things from the previous session. That means that you will need to bind everything you need into the stored state. That includes any extensions that aren't already bound to the keys or are only relevant to the 1-RTT. You don't have to remember the old key_share extension, and certificate_status[_v2]. Client authentication is one thing that you can remember. Of course, if you know you don't need it, don't save it. If you don't want it, don't save it. From nobody Fri Apr 22 05:19:28 2016 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 13A1B12D55F for ; Fri, 22 Apr 2016 05:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myyHh95C5uG4 for ; Fri, 22 Apr 2016 05:19:25 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 38B6612D5F0 for ; Fri, 22 Apr 2016 05:19:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 3B35D4B89 for ; Fri, 22 Apr 2016 15:19:24 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 92XFuxfnCmf1 for ; Fri, 22 Apr 2016 15:19:24 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id EEF872315 for ; Fri, 22 Apr 2016 15:19:23 +0300 (EEST) Date: Fri, 22 Apr 2016 15:19:21 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160422121920.GA28353@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160421144049.GB24969@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Extensions and state during a resume X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 12:19:27 -0000 On Fri, Apr 22, 2016 at 08:01:11AM +1000, Martin Thomson wrote: > > We agreed at the meeting that 0-RTT data would not explicitly signal > parameters, so peers would have to remember things from the previous > session. That means that you will need to bind everything you need > into the stored state. That includes any extensions that aren't > already bound to the keys or are only relevant to the 1-RTT. You > don't have to remember the old key_share extension, and > certificate_status[_v2]. What exactly needs to be remembered in dynamically created state (for baseline TLS 1.3 and all extensions currently defined allowed therein)? Looking at the extension list, I only see the following at coupling level for PSK 0-RTT data: - RMS (which acts as PSK key). - Ciphersuites allowed. - ALPN (ALPN needs to redefined for this!) (And a few more at non-coupled level, like identities of both peers). Also, what should happen if you try to do PSK 0-RTT with static PSK? In practicular, with what application protocol the data is interpretted as? And for subsequent handshake and operation, I consider any implicit extensions at TLS level to be nasty source of bugs (possibly even breaking protocol-level security).. -Ilari From nobody Fri Apr 22 06:13:33 2016 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 563D212D6F1 for ; Fri, 22 Apr 2016 06:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omtWOaZZIKVD for ; Fri, 22 Apr 2016 06:13:27 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6CA612ECA8 for ; Fri, 22 Apr 2016 06:13:26 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id t129so135304922vkg.2 for ; Fri, 22 Apr 2016 06:13:26 -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; bh=BQZngLYpzcZBHX4JFVAaZSEu1vo9c2/ojbzMjhoH0wA=; b=LRSsTHHbd6LBHg09FEIlZ5iLYyYwMOFiUm/jSeWmVEEGm/I39FjX0UGYHtKe3z5ABQ zeGoX+/DUvbeDkyTUVzTntTCzq+TBOMJfzt5hsnoDTMQNjMRnDWHWbzC8nQJXKXTBaF4 Oci2Edp+qDwsNQtxXwx0FH8E7UjDoTT8TS8hP334AF2f6SoCj9eazGP/CVPPzHUEcyLL TtUWFEWrlemVFKyQKu7P7Z647jf5IGIFfx0KaXe5ATHCxL9oqKoq6exLux7miJjWNt1c 57NhJy7y47nJOILM6nV7gaYDeu31xqBJw+OJgdZslq4htRGE4xtZX1XynqSKBr5909G5 PQsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=BQZngLYpzcZBHX4JFVAaZSEu1vo9c2/ojbzMjhoH0wA=; b=Z/6mtVa222Ti78MsEpXkMKk0KN3PNpQCMgVYrn/7w/C8Yng0LFxdXMysmmWHRq/cYg bq3CAn972lq+tx4T9muteM3L/9mfrK9sImykOUPDbwiOjNesGZJT3H4t0aW+EUMKEDEN GDNKe22do18d4fvG4Tk8k/bvJQrXzFeS3AANdfNU281m6XgAHEsg5hBtdmIRh1khn3Rj zGmp7BFouXJw7+1SAeLM4V1gIbmYq/a3nFYjGouBlaWvY0+wDtg3rkQIkzgR6eHp/kfl nuK0XpJgSe15QOUAXej7Xyvh9afLqG5dVdhts0zhj4qcebatw3Mqc4NgrY4JN7ttDuOU A2ZQ== X-Gm-Message-State: AOPr4FVifEGupbS3QM5fP5Up4LBiEKvtGsc9UcpMa/wBFq9/iho/AaxJsB5c/NW8br7vkEp0xiktrpd3RMrHSFni MIME-Version: 1.0 X-Received: by 10.159.37.100 with SMTP id 91mr9254020uaz.79.1461330805768; Fri, 22 Apr 2016 06:13:25 -0700 (PDT) Received: by 10.31.209.196 with HTTP; Fri, 22 Apr 2016 06:13:25 -0700 (PDT) In-Reply-To: <20160422121920.GA28353@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160421144049.GB24969@LK-Perkele-V2.elisa-laajakaista.fi> <20160422121920.GA28353@LK-Perkele-V2.elisa-laajakaista.fi> Date: Fri, 22 Apr 2016 06:13:25 -0700 Message-ID: From: Bill Cox To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c122da4942e1e0531129794 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions and state during a resume X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 13:13:32 -0000 --94eb2c122da4942e1e0531129794 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 22, 2016 at 5:19 AM, Ilari Liusvaara wrote: > Looking at the extension list, I only see the following at coupling > level for PSK 0-RTT data: > > - RMS (which acts as PSK key). > - Ciphersuites allowed. > - ALPN (ALPN needs to redefined for this!) > There is more state that must be remembered: - client authentication status (if client certs are used) - most likely the EKM seed from the 1-RTT connection - whether 0-RTT is supported The list will likely grow over time much like it has in the past. My guess is that most clients will simply reuse the existing session cache from TLS 1.2. All state will be remembered. Bill --94eb2c122da4942e1e0531129794 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 22, 2016 at 5:19 AM, Ilari Liusvaara <ilariliusvaara@welho= .com> wrote:
Looking at the= extension list, I only see the following at coupling
level for PSK 0-RTT data:

- RMS (which acts as PSK key).
- Ciphersuites allowed.
- ALPN (ALPN needs to redefined for this!)

<= div>There is more state that must be remembered:

-= client authentication status (if client certs are used)
- most l= ikely the EKM seed from the 1-RTT connection
- whether 0-RTT is s= upported

The list will likely grow over time much = like it has in the past.=C2=A0 My guess is that most clients will simply re= use the existing session cache from TLS 1.2.=C2=A0 All state will be rememb= ered.

Bill
--94eb2c122da4942e1e0531129794-- From nobody Fri Apr 22 06:49:38 2016 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 B721D12DEF7 for ; Fri, 22 Apr 2016 06:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrKrxfI6W_i3 for ; Fri, 22 Apr 2016 06:49:35 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2AF12DDE2 for ; Fri, 22 Apr 2016 06:49:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 86A8F2F5C for ; Fri, 22 Apr 2016 16:49:33 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id ONdhXOsUEv0M for ; Fri, 22 Apr 2016 16:49:33 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 501E421C for ; Fri, 22 Apr 2016 16:49:33 +0300 (EEST) Date: Fri, 22 Apr 2016 16:49:30 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160422134930.GB28353@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160421144049.GB24969@LK-Perkele-V2.elisa-laajakaista.fi> <20160422121920.GA28353@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Extensions and state during a resume X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 13:49:36 -0000 On Fri, Apr 22, 2016 at 06:13:25AM -0700, Bill Cox wrote: > On Fri, Apr 22, 2016 at 5:19 AM, Ilari Liusvaara > wrote: > > > Looking at the extension list, I only see the following at coupling > > level for PSK 0-RTT data: > > > > - RMS (which acts as PSK key). > > - Ciphersuites allowed. > > - ALPN (ALPN needs to redefined for this!) > > > > There is more state that must be remembered: > > - client authentication status (if client certs are used) Included in "identities of peers". > - most likely the EKM seed from the 1-RTT connection Looks dangerous to me. There is at least one standards track protocol that would interact badly with (destroy forward security). > - whether 0-RTT is supported Oh yeah... > The list will likely grow over time much like it has in the past. My guess > is that most clients will simply reuse the existing session cache from TLS > 1.2. All state will be remembered. If I was to implement this, I would implement it as dynamic provisioning of PSKs (because that it is) with fixed-schema database table (not SQL tho) for PSK data. And then never resume sessions but treat every connection as in- depedently as possible (PSK priorized over GDHE-CERT). That is, anything remembered should only be used for 0-RTT interpretation anything else looks to be a nasty trap (at least don't assume it will be implemented correctly!).. Also thanks for flashbacks from realizing that TLS 1.2 session resumption is much nastier than what I thought, and I already considered it nasty enough to put choice DJB quote about TLS as code comment... -Ilari From nobody Fri Apr 22 07:29:38 2016 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 2E08212D131 for ; Fri, 22 Apr 2016 07:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOTgENnMnwwI for ; Fri, 22 Apr 2016 07:29:33 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A960012D0C0 for ; Fri, 22 Apr 2016 07:29:33 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id n62so138239169vkb.0 for ; Fri, 22 Apr 2016 07:29:33 -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; bh=fsOjKMemAMlP9wE4MsPiVfYbb7oaHHACXh9mgBcCRNA=; b=AT1bJ+QSiTs5D68KZsBWxuMQPe13ba1GICxcpRevxEFIrX2t9OO2/nlfj6BargVmiv uNquDP033UT26XtbnKipM6M1Pe7SVUrzR0j/eNYQYrOK7jMF/EB4heuGn7kM/pDBEYAU 0DiOX8UI4vtUDPZMyDhMTqW1haO6EgdWH7h08QgKGxoci27WlKt0DTZKeWWOmmsukoNp yowYPoWdeSxQnSvvCdYauU75QWbYOnljVNIxqSEImtZqHi78/SuVOHtDoX/L48Pw6TqL PzxZA+kL80HK3flpKq8/Mmpj1m36G/kOkupxq1rK1Vowb356oFDiZo4s+T6QbWpBZrCD 5hfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=fsOjKMemAMlP9wE4MsPiVfYbb7oaHHACXh9mgBcCRNA=; b=IY3GOI30nukw8rzAtkDnUlfoQNsPWb5XLJwQycRWet1oGum4C/FpcjRdGfn4uR+zwH S5YjQBtXb3KBex3/PNVQFwEy7p72s1hkNFQ5IXXqmAaQkGtFyNLPBeg3yAXfaRqLbUdq XrWWgCqAvV2P0Bwn6fbof39y8g+o+eEgyj6O5o5RejD4noWawBQy7lMERW6Az1jcUO7y jyIr6580YrxzxDq4w56rteHnniZUTt4lZqrq+LcPuQ3XrmHs69HSaqDqPKHYtl0OSH7u u+gARhXtkKIQe+3P0YtxMz4MqAT+7gQ4eQmDHyuOQEKilM6m9osIUeLB6B47hWi16blh SKSQ== X-Gm-Message-State: AOPr4FW/Ck12KTGzVv7oxm4rVP61/Ig3FE9rPTAx9HsYf2Q/QKR0Pp3vqciI5zAxz4AeXZ2pzMFu+Pl1QVQjQgz2 MIME-Version: 1.0 X-Received: by 10.176.69.136 with SMTP id u8mr10798951uau.155.1461335372528; Fri, 22 Apr 2016 07:29:32 -0700 (PDT) Received: by 10.31.209.196 with HTTP; Fri, 22 Apr 2016 07:29:32 -0700 (PDT) In-Reply-To: <20160422134930.GB28353@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160421144049.GB24969@LK-Perkele-V2.elisa-laajakaista.fi> <20160422121920.GA28353@LK-Perkele-V2.elisa-laajakaista.fi> <20160422134930.GB28353@LK-Perkele-V2.elisa-laajakaista.fi> Date: Fri, 22 Apr 2016 07:29:32 -0700 Message-ID: From: Bill Cox To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c11be54c74941053113a70e Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Extensions and state during a resume X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 14:29:35 -0000 --94eb2c11be54c74941053113a70e Content-Type: text/plain; charset=UTF-8 On Fri, Apr 22, 2016 at 6:49 AM, Ilari Liusvaara wrote: > > The list will likely grow over time much like it has in the past. My > guess > > is that most clients will simply reuse the existing session cache from > TLS > > 1.2. All state will be remembered. > > If I was to implement this, I would implement it as dynamic provisioning of > PSKs (because that it is) with fixed-schema database table (not SQL tho) > for > PSK data. And then never resume sessions but treat every connection as in- > depedently as possible (PSK priorized over GDHE-CERT). > > That is, anything remembered should only be used for 0-RTT interpretation > anything else looks to be a nasty trap (at least don't assume it will be > implemented correctly!).. > > Also thanks for flashbacks from realizing that TLS 1.2 session resumption > is > much nastier than what I thought, and I already considered it nasty enough > to > put choice DJB quote about TLS as code comment... I think we're in agreement now. Imagine all that code dedicated to session state interaction with extensions, and now instead of a clean slate TLS 2.0, do a TLS 1.3 that is as different as possible from TLS 1.2 without actually requiring rewriting the code... It will be awesome to have the speed of 0-RTT in TLS 1.3, but I look forward to the TLS 2.0 effort. Bill --94eb2c11be54c74941053113a70e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 22, 2016 at 6:49 AM, Ilari Liusvaara <ilariliusvaara@welho= .com> wrote:
> The list will likely grow over time much like it has in the past.= =C2=A0 My guess
> is that most clients will simply reuse the existing session cache from= TLS
> 1.2.=C2=A0 All state will be remembered.

If I was to implement this, I would implement it as dynamic provisio= ning of
PSKs (because that it is) with fixed-schema database table (not SQL tho) fo= r
PSK data. And then never resume sessions but treat every connection as in-<= br> depedently as possible (PSK priorized over GDHE-CERT).

That is, anything remembered should only be used for 0-RTT interpretation anything else looks to be a nasty trap (at least don't assume it will b= e
implemented correctly!)..

Also thanks for flashbacks from realizing that TLS 1.2 session resumption i= s
much nastier than what I thought, and I already considered it nasty enough = to
put choice DJB quote about TLS as code comment...

I think we're in agreement now.=C2=A0 Imagine all that code dedi= cated to session state interaction with extensions, and now instead of a cl= ean slate TLS 2.0, do a TLS 1.3 that is as different as possible from TLS 1= .2 without actually requiring rewriting the code...=C2=A0 It will be awesom= e to have the speed of 0-RTT in TLS 1.3, but I look forward to the TLS 2.0 = effort.

Bill=C2=A0
--94eb2c11be54c74941053113a70e-- From abhishek.tiwari@aurea.com Sat Apr 23 12:00:39 2016 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 1CE5D12D556 for ; Sat, 23 Apr 2016 12:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aurea-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oR-fJ-5xvhc for ; Sat, 23 Apr 2016 12:00:38 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB6CE12D60E for ; Sat, 23 Apr 2016 12:00:34 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id u206so70814434wme.1 for ; Sat, 23 Apr 2016 12:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aurea-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=I14AYNsKqbSCXuSgcX7XW1CBkjIhZobZdX7mBTfKmpc=; b=wXQtuBE7Ax+JRo1dQRcmz+WQSR4nLpvIVoJu2IBxdp0xB9ZWEA08MJyJBodB2bIP8y Mcc5DcFbnOzC3FO0zAttI+rhvjmjZlWk/UBRZyxXtMYNSeVNIqcWjHbWlnI6TJ6ohid0 8u2tzVbTg7BQcNnhCNG+YVCVBdSAnKNUWYkmap/Dx8QFMm5CEqwSwWy2wL2xoEy6PE3Z iZeC9aiCnLakaOFp+FDlP7ckjGvpF2mZD5fP6gRX3/yZXr9ygZV1EjdeiUgDTrq1gQKD WhQURIXv+srUobP2AD6dKlVKcpuM+slQsMTDPJd9bVoYLSvPD4i9Xui8H5n2E9cOoB0h 4G1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=I14AYNsKqbSCXuSgcX7XW1CBkjIhZobZdX7mBTfKmpc=; b=PZXsRXaXTYIK9r+aX10L6iMnt7kgi71pjlBmIUQdzrgPHLyZhC/iO9MryZ4OAdGxLH Q2/NxZ8fllRAsXPPFDy0vRVkUumBZ607lw4hM/VE2oGbsVU+muDH0OMDuxbCVbihtkuX f06ml7ySNjRoATbWWTHb/YfNEFuqzXjhSVNHiUqYaMN5dwwuATfZrxJVTJ+UL1yYlyzw uTyBc9Cdq9OYT+dFUCj7kUKOnoWoYiD+mcCMiPSnjwyK4f2cH8asKvD1HLvURnpkApxh tlXNVioCOQ7L/XQbNfgonnWKqwzcx8GgcXYLcB3OgcQWhkkHi+aql8ye8d7g8uxVBCrG zFHw== X-Gm-Message-State: AOPr4FVPUhgSa1vTA4yCzFWxPenbhrvkiUyMdjJEIYQZEiPqGsO+Nf/r9eqaLEGT/12bQukbmIBb5eNCGlMGt6ea MIME-Version: 1.0 X-Received: by 10.28.174.70 with SMTP id x67mr3565160wme.43.1461438033273; Sat, 23 Apr 2016 12:00:33 -0700 (PDT) Received: by 10.28.171.86 with HTTP; Sat, 23 Apr 2016 12:00:33 -0700 (PDT) Date: Sun, 24 Apr 2016 00:30:33 +0530 Message-ID: From: Abhishek Tiwari To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a1144283ed5c5fb05312b8e0b Archived-At: Subject: [TLS] performance issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2016 19:02:20 -0000 --001a1144283ed5c5fb05312b8e0b Content-Type: text/plain; charset=UTF-8 Hello, Our application uses TLS and we upgraded tls 1.6 -> 1.6.4 Due to this , Issues like high CPU usage, application not responsive(for client connections) started coming Reverting back to 1.6 solved issue for couple of customers Upgrading to 1.6.7 solved issue for most of customers(windows+linux) Now one particular customer has reported such issue with 1.6.7 as well. This customer is on Windows. The reason for the problem arised with upgrade : tls 1.6 -> 1.6.4, was described by the peer developer was : ----------------------------- The cause of the issue is in the lmtcl/tls(TLS protocol implementation for Tcl) which was updated from 1.6 to 1.6.4 The bug was in static int TlsNotifyProc(instanceData, mask) function which is defined in tlsIO.c file. Infinite loop in this function is executed in separate "notifier" thread and in tls1.6.4 it applies I/O load to the main application thread, so it consumes 100% CPU. -------------------------------- Please let me how relevant is this Regards Abhishek --001a1144283ed5c5fb05312b8e0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,=C2=A0

Our application uses TLS =C2=A0and we up= graded tls 1.6 -> 1.6.4
Due to this , Issues like high CPU usa= ge, application not responsive(for client connections) started coming
=

Reverting back to =C2=A01.6 solved issue for couple of = customers
Upgrading to =C2=A01.6.7 solved issue for most of custo= mers(windows+linux)

Now one particular custome= r has reported such issue with 1.6.7 as well.
This customer is on= =C2=A0Windows.

The reason for the problem arised = with upgrade : =C2=A0tls 1.6 -> 1.6.4, was described by the peer develop= er was :
-----------------------------
The cau= se of the issue is in the lmtcl/tls(TLS protocol implementation for Tcl) wh= ich was updated from 1.6 to 1.6.4=C2=A0
The bug was in static int= TlsNotifyProc(instanceData, mask) function which is defined in tlsIO.c fil= e. Infinite loop in this function is executed in separate=C2=A0
<= br>
"notifier" thread and in tls1.6.4 it applies I/O lo= ad to the main application thread, so it consumes 100% CPU.
-----= ---------------------------
Please let me how relevant is this

Regards
Abhishek
--001a1144283ed5c5fb05312b8e0b-- From nobody Sat Apr 23 15:59:01 2016 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 8782812D186 for ; Sat, 23 Apr 2016 15:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kls5uYa6a4XE for ; Sat, 23 Apr 2016 15:58:57 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 75FF812D17F for ; Sat, 23 Apr 2016 15:58:57 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8D06343347B; Sat, 23 Apr 2016 22:58:56 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 74E50433478; Sat, 23 Apr 2016 22:58:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1461452336; bh=V7zOiaZhxLhBjVH/29ZVQybbM780nStBtdhC/e1ej9g=; l=4610; h=From:To:Date:References:In-Reply-To:From; b=axDwtPkmXRLXDkHOSBY0Ra/zMJhyxUpUKNXM1mWw+Pnjha/2gr4tLiEFQwaZVeNZU 34n442reVmgwN60WpVs6t9jyDLWV4GVTkIkiO+gDZ0E3m2xiiXKETCqcom1xaS72// u3yMeZ1SuKWX/bPP0UEMyYXd6JCrjZnG04UeoweU= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 6FD9B1FC93; Sat, 23 Apr 2016 22:58:56 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Sat, 23 Apr 2016 18:58:55 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Sat, 23 Apr 2016 18:58:55 -0400 From: "Salz, Rich" To: Abhishek Tiwari , "tls@ietf.org" Thread-Topic: [TLS] performance issue Thread-Index: AQHRnZKrGg2auXujgku0L+THCYFxwJ+YK/tQ Date: Sat, 23 Apr 2016 22:58:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.84] Content-Type: multipart/alternative; boundary="_000_b755b961b4b945c4a1db2756e0d145f2usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] performance issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Apr 2016 22:58:59 -0000 --_000_b755b961b4b945c4a1db2756e0d145f2usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBzb3VuZHMgbGlrZSBpbXBsZW1lbnRhdGlvbiBwcm9ibGVtczsgbm90IHN1cmUgd2hhdCBw YWNrYWdlIOKAnHRscyAxLjYuN+KAnSBpcywgYnV0IGNvbnRhY3QgeW91ciB2ZW5kb3IuDQoNClRo aXMgbWFpbGluZyBsaXN0IGlzIGZvciBkaXNjdXNzaW9uIGFuZCBldm9sdXRpb24gb2YgdGhlIFRM UyAqcHJvdG9jb2wqDQoNCi0tDQpTZW5pb3IgQXJjaGl0ZWN0LCBBa2FtYWkgVGVjaG5vbG9naWVz DQpJTTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6IFJpY2hTYWx6DQo= --_000_b755b961b4b945c4a1db2756e0d145f2usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBzb3VuZHMgbGlrZSBpbXBsZW1lbnRh dGlvbiBwcm9ibGVtczsgbm90IHN1cmUgd2hhdCBwYWNrYWdlIOKAnHRscyAxLjYuN+KAnSBpcywg YnV0IGNvbnRhY3QgeW91ciB2ZW5kb3IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIG1haWxpbmcgbGlzdCBpcyBm b3IgZGlzY3Vzc2lvbiBhbmQgZXZvbHV0aW9uIG9mIHRoZSBUTFMgKjxiPnByb3RvY29sPC9iPio8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPi0tJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2VuaW9y IEFyY2hpdGVjdCwgQWthbWFpIFRlY2hub2xvZ2llczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JTTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6IFJpY2hTYWx6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_b755b961b4b945c4a1db2756e0d145f2usma1exdag1mb1msgcorpak_-- From nobody Sun Apr 24 09:23:33 2016 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D9912D141; Sun, 24 Apr 2016 09:23:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160424162332.6957.99300.idtracker@ietfa.amsl.com> Date: Sun, 24 Apr 2016 09:23:32 -0700 Archived-At: Cc: draft-ietf-tls-chacha20-poly1305@ietf.org, tls-chairs@ietf.org, tls@ietf.org Subject: [TLS] Alexey Melnikov's Yes on draft-ietf-tls-chacha20-poly1305-04: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the mailing list 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, 24 Apr 2016 16:23:32 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-tls-chacha20-poly1305-04: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-poly1305/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Nit: SHA-256 probably needs a normative reference. From nobody Mon Apr 25 08:12:20 2016 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 D8B2E12D526 for ; Mon, 25 Apr 2016 08:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuAc3Yvs9VSR for ; Mon, 25 Apr 2016 08:12:16 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DB8D12D156 for ; Mon, 25 Apr 2016 08:12:16 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id 206so18567657pfu.0 for ; Mon, 25 Apr 2016 08:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=tmB+c6w4ffrka4CQnFX1r/4WjfWqmhaoNFN2SlXzriY=; b=KSSuVS+aXYcQwQ1tRSWtBuLvQjY65GHal4sbLFPkcIve6a+RR2nl4d6tTGvWm3ximc QRON/DbPr8/xo4cKHjP+rJGqrpaYCS1HNk1rn6kqqiEss1qizp+fJJ9Ta03TJlfehr9y Xs0WC6H+ovgLMteHi8T68ylKAwyiNmfNI22uY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=tmB+c6w4ffrka4CQnFX1r/4WjfWqmhaoNFN2SlXzriY=; b=GTTAK4j/6saifcMQiIvc0YEW4IYx9PcDu4n1flIhd5wurUFF3fPeWsKo2P72Yzwpvm a4+w35oz54zNF7RyzuCLSjmTrzImmvlqUYJbi78eV+Vm+T8aVJttJ2WI01SsoMb+Ai9b C6wgJBzWWy9SlMlHIr406hnX0krcaSnAqBDFrbNuNat89dofMt9fyN2hpmaU0LXHb07y 9KLFSMe0Ot7QOjLI+VoN3PjAWh3gtp7yqpluge1jdD4AswgzmKPBUGAb4PdrXKyzVeGd gfXIfc63ZyOR9WgMM9paptkCEURGlWr3i973GG+QnxyKDJvR/AcnF6hhgg1t3gYvHsLb iOPg== X-Gm-Message-State: AOPr4FUlHTn5lsrVBJmjTsKCJP4i6POHOLyLPH1zLQaiMajQszSomi/Q+Qi7ZmK2kdLYqA== X-Received: by 10.98.92.135 with SMTP id q129mr48699395pfb.71.1461597135576; Mon, 25 Apr 2016 08:12:15 -0700 (PDT) Received: from [172.20.10.4] ([166.177.250.132]) by smtp.gmail.com with ESMTPSA id m186sm29582097pfm.29.2016.04.25.08.12.14 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Apr 2016 08:12:14 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 25 Apr 2016 08:12:17 -0700 To: tls Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] Call for WG adoption of draft-shore-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2016 15:12:19 -0000 All, draft-shore-tls-dnssec-chain-extension was originally discussed at IETF = 93 [0], and the authors have been biding their time while the WG = thrashed out TLS1.3s' issues. At IETF 95, they presented again [1], but = this time the chairs took a sense of the room about whether the WG was = in favor of adopting the draft. According to the minutes, there were = =E2=80=9Ccrickets=E2=80=9D against and =E2=80=9Clots of noise=E2=80=9D = for adoption. But, we need to take it to the list so please indicate = whether you: - Support adoption and are willing to review/comment on the draft by = 201600429. Note that the extensions is pretty straight forward, but the = chairs still need people to comment on the draft as we=E2=80=99re = processing it down the path. - Object to the adoption of this draft as a WG item, please respond to = the list indicating why by 201600510. Cheers, J&S [0] https://www.ietf.org/proceedings/93/slides/slides-93-tls-1.pdf [1] https://www.ietf.org/proceedings/95/slides/slides-95-tls-3.pdf= From nobody Mon Apr 25 08:17:45 2016 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 DA76612D526 for ; Mon, 25 Apr 2016 08:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V87IiQWjTfel for ; Mon, 25 Apr 2016 08:17:43 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B034612D1B0 for ; Mon, 25 Apr 2016 08:17:43 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id y69so47991342pfb.1 for ; Mon, 25 Apr 2016 08:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=C3yLasv+qzhwYT6JhrKVDG0QW0SCYFXeqf4yH69ugNg=; b=GSRtZ/ZpftDueWwSnCv3XFn56+UgsTPxdnUXj0vB/Y3AhJvjcx37saSDFMc9j5B7e0 i3VYUEXyZ87WSv20Pq2F/Mxy+ZYbUWzitEvBtbJ79IFyASHf8tilr1tw3luFdHWlLHNU XlkWIdhT4uppoJQHou6aCXsQQ/NJLH72TMuAY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=C3yLasv+qzhwYT6JhrKVDG0QW0SCYFXeqf4yH69ugNg=; b=gksaB+GeKff4Y6VQWV2/BbpN+eoKnwkixVd10R/j0iqMMeJ2NsNydzBEYvfZiL4YzI 6mIxHS9PUZb+S7rziPSmh4Tb1EkdOkKqYctGl7xUeiQVa1q22xjpggRCgVdongj5OXNw l1nkgKaD7LvutDJg5yz/mPbpq/hmv7cjFCAQDSZOXVoUszgBaCLhCjUAwNDoRafQu5oF Pc2zmRmsptoq/Ig7bqab1UqEgC8ArbI7hBd/MFtv73fS3FVv+apXT/GUGd/ckS2AAf1p iocYeyuLyegK1fMwYEdD0rK+Lz7xSjO7OZbHkf6rV+oJ1gBahseMMPkID2PsbE4VdUpH vKbw== X-Gm-Message-State: AOPr4FXiXNDvx2JFpi0imfW/AlEv+q6Pu7vUdvAJVYZZlOT0H42mp6PzY4UthBfnAj8+FA== X-Received: by 10.98.69.75 with SMTP id s72mr49658373pfa.66.1461597463333; Mon, 25 Apr 2016 08:17:43 -0700 (PDT) Received: from [172.20.10.4] ([166.177.250.132]) by smtp.gmail.com with ESMTPSA id 28sm25409774pfs.1.2016.04.25.08.17.42 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Apr 2016 08:17:42 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 25 Apr 2016 08:17:45 -0700 To: tls Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2016 15:17:45 -0000 All, draft-mattsson-tls-ecdhe-psk-aead includes some cipher suites that are = needed for TLS1.3. We need to get these officially registered so the = chairs would like to hear whether there is WG support for adopting = draft-mattsson-tls-ecdhe-psk-aead. Please let us know whether you: - Support adoption and are willing to review/comment on the draft by = 201600429; the chairs still need people to review the draft to show = there=E2=80=99s support for it as we process it down the path. - Object to the adoption of this draft as a WG item, please respond to = the list indicating why by 201600429. Note 1: This draft will get published using the new rules we=E2=80=99ve = been concocting on the list so the IANA considerations section will get = tweaked as we settle on what words need to be included. Note 2: The other option is to put the registrations in the TLS1.3 spec, = but that would add four pages that I=E2=80=99m pretty sure no = implementer is going to read so there seems to be little point in = included the registrations in the TLS1.3 spec. And, these cipher suites = do apply to TLS1.2. Cheers, J&S= From nobody Mon Apr 25 08:19:21 2016 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 96F2212B03B for ; Mon, 25 Apr 2016 08:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKa-UzJ5KEYm for ; Mon, 25 Apr 2016 08:19:18 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 676F112B017 for ; Mon, 25 Apr 2016 08:19:18 -0700 (PDT) Received: by mail-pa0-x232.google.com with SMTP id r5so59657999pag.1 for ; Mon, 25 Apr 2016 08:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=SQn4XcO/KPQXvFe2Q48QgD/6HAiJWZ/3NLDKWHmAVUA=; b=SAKtJ3tu97S0dbdyRZyQPyzAAtS+TQK8oVNpocTciUaOftDjb04MZz/6E/8lk26EMR 0r0Lwgfs55/AA0Evb9K7Jufe04AYLRjNJGzKXXhyiLGnXgJhQDZS9T5VqetuXwuy8Apb UTLADIRY+se1XR+S8/Z4h+xTp8z71vIgjUD+Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=SQn4XcO/KPQXvFe2Q48QgD/6HAiJWZ/3NLDKWHmAVUA=; b=nFCRi5NHeNJqDyBnB6LQtUdMr6in0IXOKbd9s8Z545Kj8623seLksiePiDFUf4ADnD R+/H11W7uvmTE9qZT9tgzurUIpmbdHoCjZIRET1g34gHkDXUxeWCTuaKyRpxqA9h9VDH 6X3/wpfgGemgaoilL/OHxPBq5DNyuv03FypVNKCVNNlXlBV1/HuX/UN++VUXXTtsmqaX 8CIwdgIsKFY0tasdEYXbvSMypBdzSY4zZ1K2IRWJv8Q4CSsX7VfPQUIGtWkpP0JpkO1z pTlCuROmdk9rjtBtDyN6p5Vi6Rr7eYXrHtz7cIL13O/h+W/1Kou9b2X04fpeqJtRJyf0 4QFg== X-Gm-Message-State: AOPr4FVszQ4trnYy5f2d8x1KIX+s+McCf4QPWwTAJ+VoXvn2MtZteOM31dR1yTd+tsDKlQ== X-Received: by 10.66.156.232 with SMTP id wh8mr49559982pab.153.1461597558022; Mon, 25 Apr 2016 08:19:18 -0700 (PDT) Received: from [172.20.10.4] ([166.177.250.132]) by smtp.gmail.com with ESMTPSA id 80sm29588950pfx.68.2016.04.25.08.19.17 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Apr 2016 08:19:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Mon, 25 Apr 2016 08:19:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: tls X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] Call for WG adoption of draft-shore-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2016 15:19:19 -0000 I got the dates wrong. They should both have been 20160510. spt > On Apr 25, 2016, at 08:12, Sean Turner wrote: >=20 > All, >=20 > draft-shore-tls-dnssec-chain-extension was originally discussed at = IETF 93 [0], and the authors have been biding their time while the WG = thrashed out TLS1.3s' issues. At IETF 95, they presented again [1], but = this time the chairs took a sense of the room about whether the WG was = in favor of adopting the draft. According to the minutes, there were = =E2=80=9Ccrickets=E2=80=9D against and =E2=80=9Clots of noise=E2=80=9D = for adoption. But, we need to take it to the list so please indicate = whether you: >=20 > - Support adoption and are willing to review/comment on the draft by = 201600429. Note that the extensions is pretty straight forward, but the = chairs still need people to comment on the draft as we=E2=80=99re = processing it down the path. >=20 > - Object to the adoption of this draft as a WG item, please respond to = the list indicating why by 201600510. >=20 > Cheers, >=20 > J&S >=20 > [0] https://www.ietf.org/proceedings/93/slides/slides-93-tls-1.pdf > [1] https://www.ietf.org/proceedings/95/slides/slides-95-tls-3.pdf From nobody Mon Apr 25 08:19:53 2016 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 044DB12D102 for ; Mon, 25 Apr 2016 08:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.996] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wL7klaQN_d9I for ; Mon, 25 Apr 2016 08:19:50 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBD0712B05A for ; Mon, 25 Apr 2016 08:19:49 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qtqdv6pbdz2Cg; Mon, 25 Apr 2016 17:19:47 +0200 (CEST) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id qFY8gYt9SPIL; Mon, 25 Apr 2016 17:19:47 +0200 (CEST) Received: from ns0.nohats.ca (ns0.nohats.ca [IPv6:2a03:6000:1004:1::102]) by mx.nohats.ca (Postfix) with ESMTP; Mon, 25 Apr 2016 17:19:47 +0200 (CEST) Received: by ns0.nohats.ca (Postfix, from userid 500) id 17C0540AEA; Mon, 25 Apr 2016 11:19:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ns0.nohats.ca (Postfix) with ESMTP id 14B2940206; Mon, 25 Apr 2016 11:19:47 -0400 (EDT) Date: Mon, 25 Apr 2016 11:19:46 -0400 (EDT) From: Paul Wouters To: Sean Turner In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: tls Subject: Re: [TLS] Call for WG adoption of draft-shore-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2016 15:19:52 -0000 On Mon, 25 Apr 2016, Sean Turner wrote: > draft-shore-tls-dnssec-chain-extension was originally discussed at IETF 93 [0], and the authors have been biding their time while the WG thrashed out TLS1.3s' issues. At IETF 95, they presented again [1], but this time the chairs took a sense of the room about whether the WG was in favor of adopting the draft. According to the minutes, there were “crickets” against and “lots of noise” for adoption. But, we need to take it to the list so please indicate whether you: > > - Support adoption and are willing to review/comment on the draft by 201600429. Note that the extensions is pretty straight forward, but the chairs still need people to comment on the draft as we’re processing it down the path. I support and will review the document. I think it is a great idea that will help deploying DNSSEC and TLSA for browsers. Paul From nobody Mon Apr 25 08:21:35 2016 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 4CD6912D543 for ; Mon, 25 Apr 2016 08:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmBgxMk3ql_N for ; Mon, 25 Apr 2016 08:21:32 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDE1012B05A for ; Mon, 25 Apr 2016 08:21:32 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id n1so69656758pfn.2 for ; Mon, 25 Apr 2016 08:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=MHlbhp3aMfLRQBQyTW/vGiFtff0s4vzLeoXf1JS71/c=; b=AFiBRalrFbDEhRKXZRnvatxgU/5V9wzNGaHgL16kRc6/ziFkyGMj2j8J/F1TP8yXL/ F9pd+Ks944OQ7LbNBifALAW9R6UY2y56jtizwvVMnCmK1pDpWO5I+NDEnNT1w8o9Tkdn qBqXZAg9+vB4arDbp4aIH0pe0UX2tcVb3ux18= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=MHlbhp3aMfLRQBQyTW/vGiFtff0s4vzLeoXf1JS71/c=; b=KjxZLgxXUQCYeFFaJ8iPa9SZ10JgqkqyHsOT0qTpqRV8Q/9sgOQ1jf7qmVHWDRMIhP w2alQCgSyqAdFeyTqqhg5E2u5s2tUwTanVXT5B5CcXX24cluLXmk9p3Nn2v+kU5z+xUE D9/eTOsERhMjcOtMQMCjcULmYx7hU6BMbr4wkwwHMkQ5NBfZjviPAnJuw8rhWEoOvfne uofI1lTr8oa7gEvNnz+jiP7/uH+74P/u0lVhUK/LPOVMuaVzyKjqFuLbelBW+eSRQ6VR QiHifIlzOrH+RHz45L2JsoqTxAOrR1woNB3vcVOmhObQdH4y/J8w00+46vv4B6wUCVBz 8zbA== X-Gm-Message-State: AOPr4FUitbZAHHu7jO2cjgzBNSA/uJmSeemgfxEhpGTas5Wt3ehc5Z69r1vXy1JMDcFFSg== X-Received: by 10.98.18.80 with SMTP id a77mr11896309pfj.27.1461597692381; Mon, 25 Apr 2016 08:21:32 -0700 (PDT) Received: from [172.20.10.4] ([166.177.250.132]) by smtp.gmail.com with ESMTPSA id uw2sm30861722pac.10.2016.04.25.08.21.31 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Apr 2016 08:21:31 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Mon, 25 Apr 2016 08:21:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: tls X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2016 15:21:34 -0000 sigh and here as well - they should have been 20160510. spt > On Apr 25, 2016, at 08:17, Sean Turner wrote: >=20 > All, >=20 > draft-mattsson-tls-ecdhe-psk-aead includes some cipher suites that are = needed for TLS1.3. We need to get these officially registered so the = chairs would like to hear whether there is WG support for adopting = draft-mattsson-tls-ecdhe-psk-aead. Please let us know whether you: >=20 > - Support adoption and are willing to review/comment on the draft by = 201600429; the chairs still need people to review the draft to show = there=E2=80=99s support for it as we process it down the path. >=20 > - Object to the adoption of this draft as a WG item, please respond to = the list indicating why by 201600429. >=20 > Note 1: This draft will get published using the new rules we=E2=80=99ve = been concocting on the list so the IANA considerations section will get = tweaked as we settle on what words need to be included. >=20 > Note 2: The other option is to put the registrations in the TLS1.3 = spec, but that would add four pages that I=E2=80=99m pretty sure no = implementer is going to read so there seems to be little point in = included the registrations in the TLS1.3 spec. And, these cipher suites = do apply to TLS1.2. >=20 > Cheers, >=20 > J&S From nobody Mon Apr 25 08:27:55 2016 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 1EB8D12D1AB for ; Mon, 25 Apr 2016 08:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1rzrZLNXAuZ for ; Mon, 25 Apr 2016 08:27:45 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8768612D1B9 for ; Mon, 25 Apr 2016 08:27:45 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 52DFBF2402E for ; Mon, 25 Apr 2016 11:27:45 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id wmM4Z-hdjvAq for ; Mon, 25 Apr 2016 11:11:58 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id EE550F2401F for ; Mon, 25 Apr 2016 11:27:44 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Mon, 25 Apr 2016 11:27:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <01290CDD-4DCB-4215-861F-B1CCCA79787C@vigilsec.com> References: To: IETF TLS X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [TLS] Call for WG adoption of draft-shore-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2016 15:27:49 -0000 On Apr 25, 2016, at 11:19 AM, Paul Wouters wrote: > On Mon, 25 Apr 2016, Sean Turner wrote: >=20 >> draft-shore-tls-dnssec-chain-extension was originally discussed at = IETF 93 [0], and the authors have been biding their time while the WG = thrashed out TLS1.3s' issues. At IETF 95, they presented again [1], but = this time the chairs took a sense of the room about whether the WG was = in favor of adopting the draft. According to the minutes, there were = =93crickets=94 against and =93lots of noise=94 for adoption. But, we = need to take it to the list so please indicate whether you: >>=20 >> - Support adoption and are willing to review/comment on the draft by = 201600429. Note that the extensions is pretty straight forward, but the = chairs still need people to comment on the draft as we=92re processing = it down the path. >=20 > I support and will review the document. I think it is a great idea = that > will help deploying DNSSEC and TLSA for browsers. +1 From nobody Mon Apr 25 09:13:31 2016 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 020C712D52D for ; Mon, 25 Apr 2016 09:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JD88fwMpH_IE for ; Mon, 25 Apr 2016 09:13:27 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFEAF12B05C for ; Mon, 25 Apr 2016 09:13:26 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id j11so120135659lfb.1 for ; Mon, 25 Apr 2016 09:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=31A7a/HALNtLS1AMs734zfKMsBYBImc8xlROMImmK7A=; b=bPhhPBtSRUvGCv4ltnAA4ra2pkErzunsjuISA3ef351UJFqHiVJkd6M+HJ/omZ4Cmq or/o+OWNBt+WjXrpVy4STRfp01zvYT6ZWsJIpxS2sOnCavqSNFa0DK+UTA9iGPWz5uRw Q/7DJXW8tG9BK4cv9n30+90DkmdPd6Mi1fxrgjRVxNAh/tI16hw7lMF4lGIq9vLQHgYR wAoTBFxHBFIUCAuSkMmormv0k3EhUG6PSTLpExSAiV6njL0aF5yz5BrsQkUMlTK1/5ni V2Y4oTrJ9QYaqXYHpNp1KaybgBgx9tUM3VsBJws4VLL5qjP5mOZFgUKOjTLISz4SKMiX B4ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=31A7a/HALNtLS1AMs734zfKMsBYBImc8xlROMImmK7A=; b=M0nTcbNmZ/OR7BRuIlTnoWSxxtp3qa3QS8Szag+/0FtYx0of6dzHDh8vEokEjXoFoa AO1HuiKX4TNE2JeUGZ6KIUnLc/7mlRNjHTuez3s5Fo/kJX0Fa1PiblS2m3OgccLw3oeQ f/7VV5TNYPJO+vlV6Gc6Ku7AkH9ysSbN1Jp+MyqSOdSh6/CiseJZ5GpKnX8jb59W9hG4 +jiz3zzQPPH1xY1zm82pT/jzhLGjtG49QBi5M0pAHcLkOsxckFzbQAlpnVOl2qqHwfZP y5JSA+mRuPELxBRRkvXDB13jj7+8Eup6ffu1y+65Ky2fkXvxLterko6/J+Ynv17TA/rB tCEg== X-Gm-Message-State: AOPr4FUUnffHrSsk9gyFf6FFpKDCq/+ryf9O+jHwL1To+E05HQV52qtgNf3dFvdWwKtnRt4nOJUW6DRAbtuTXA== X-Received: by 10.25.42.13 with SMTP id q13mr14286385lfq.2.1461600805036; Mon, 25 Apr 2016 09:13:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.189.74 with HTTP; Mon, 25 Apr 2016 09:13:05 -0700 (PDT) From: Joseph Salowey Date: Mon, 25 Apr 2016 09:13:05 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11410bc2c9d26d0531517454 Archived-At: Subject: [TLS] Actions and issues from the IETF 95 TLS meeting X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2016 16:13:29 -0000 --001a11410bc2c9d26d0531517454 Content-Type: text/plain; charset=UTF-8 Below are some of the more significant issues discussed at the meeting in Buenos Aires: 1. Adopt David Benjamin's signature and hash algorithm negotiation structure that ties both together. New code points to define signature algorithm, curve and hash as a unit. - PR incorporated into draft - https://github.com/tlswg/tls13-spec/pull/404 2. Adopt Anti-Downgrade mechanism proposed by Green/Bhargavan. - PR incorporated into draft - https://github.com/tlswg/tls13-spec/pull/284 3. Adopt a simplified NewSessionTicket Format. The ticket format should indicate if the server would accept ECDHE-PSK or PSK and indicate if early data is allowed or not. The use of a bit mask was discussed in the meeting. - PR to be discussed on the list when available. 4. Adopt proposal to add back encrypted extensions for early data. Encrypted extensions provide application identification (ALPN) and elapsed timestamp. - PR to be discussed on the list when available. 5. Adopt simplified more linear key separation derivation. - PR to be discussed on the list when available. 6. Adopt proposal for demuxing handshake message from data messages. New handshake key is derived to encrypt post initial handshake messages. Proposed solution is to wrap encrypted handshake message in encrypted data message. This is pending cryptographic evaluation. - PR to be discussed on the list when available. 7. Adopt proposal to include OCSP stapling as part of certificate messages. - PR to be discussed on the list when available. 8. Adopt proposal to allow server to send known groups (Issue 415). - PR to be discussed on the list when available. 9. Park proposal to add receive generation field in the key update so client knows it is safe to release keys (PR 426) - We do not have consensus to move forward with this PR --001a11410bc2c9d26d0531517454 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Below are some of the mor= e=C2=A0significant=C2=A0issues discussed at the meeting in Buenos Aires:

1. Adopt David Benjamin's signature = and hash algorithm negotiation structure that ties both together. =C2=A0 Ne= w code points to define signature algorithm, curve and hash as a unit. =C2= =A0=C2=A0

- PR incorporated into draft -=C2=A0https://github.com/tlswg/tls13-spec/pull/404

2. Adopt Anti-Downgr= ade mechanism proposed by Green/Bhargavan.=C2=A0

- PR incorporated into draft -=C2=A0https://github.com/tlswg/tls13-spec/pull/284

3. Adopt a = simplified NewSessionTicket Format.=C2=A0 The ticket format should indicate= if the server would accept ECDHE-PSK or PSK =C2=A0and indicate if early da= ta is allowed or not.=C2=A0 The use of a bit mask was discussed in the meet= ing.=C2=A0

- PR to be discussed on the list when available.=C2=A0
=

4= .=C2=A0 Adopt proposal to add back encrypted extensions for early data.=C2= =A0 Encrypted extensions provide application identification (ALPN) and elap= sed timestamp. =C2=A0=C2=A0

=
- PR to be discussed on the list when avail= able.=C2=A0

5.=C2=A0 Adopt simplified more linear key separation deriva= tion.=C2=A0

- PR to be discussed on the list when available.=C2=A0

= 6.=C2=A0 Adopt proposal for demuxing handshake message from data messages.= =C2=A0 New handshake key is derived to encrypt post initial handshake messa= ges.=C2=A0 Proposed solution is to wrap encrypted handshake message in encr= ypted data message.=C2=A0 This is pending cryptographic evaluation.=C2=A0= =C2=A0

- PR to be discussed on the list when available.=C2=A0

7.=C2= =A0 Adopt proposal to include OCSP stapling as part of certificate messages= . =C2=A0

- PR to be discussed on the l= ist when available.=C2=A0=C2=A0

8.=C2=A0 Adopt proposal to allow= server to send known groups (Issue 415).=C2=A0=C2=A0

- PR to be discus= sed on the list when available.=C2=A0

9.=C2=A0 Park proposal to add receive generation field in the key upd= ate so client knows it is safe to release keys =C2=A0(PR 426)=C2=A0<= /div>

- We do not have consensus to move forward with this PR
--001a11410bc2c9d26d0531517454-- From nobody Mon Apr 25 10:37:36 2016 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 5BE5812B05F for ; Mon, 25 Apr 2016 10:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BOWx4ANu4DP for ; Mon, 25 Apr 2016 10:37:34 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 450A412B023 for ; Mon, 25 Apr 2016 10:37:34 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BFC96284B6F; Mon, 25 Apr 2016 17:37:32 +0000 (UTC) Date: Mon, 25 Apr 2016 17:37:32 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20160425173732.GB26423@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Call for WG adoption of draft-shore-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 17:37:35 -0000 On Mon, Apr 25, 2016 at 08:12:17AM -0700, Sean Turner wrote: > - Support adoption and are willing to review/comment on the draft I support the adoption of this draft. -- Viktor. From nobody Mon Apr 25 10:51:03 2016 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 7EEFD12B068 for ; Mon, 25 Apr 2016 10:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7P9sm5X44gOE for ; Mon, 25 Apr 2016 10:51:01 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD1512B041 for ; Mon, 25 Apr 2016 10:51:01 -0700 (PDT) Received: by mail-pa0-x231.google.com with SMTP id r5so61161413pag.1 for ; Mon, 25 Apr 2016 10:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=tGZNpqfYVyOV4Um58P5F1Y3U/E1nC8PJsLmn9E1vGw4=; b=IR7Xfm33p7DJGHbiRvW29zbv77WUcTHjCugxwLJTg+lWKE7MdPR4izpxVr04WgpsHM uJbhUz/SOTO8EIOZvfg9KXZbd65VlHhQlvUbhIbITQiyURM3VaZqzqfDhlebRfAO1klH Y2CbtOOtfLsxwAvKlrmlC/jX3bLuur3nRg+oU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=tGZNpqfYVyOV4Um58P5F1Y3U/E1nC8PJsLmn9E1vGw4=; b=YYIW7EO+D5HUEQZc2yf1lDFZISGS/83GMEn5jdTYF0jStFxaZSqvwSGUkpZgb5OzDf KO0/bRMCJaTFQow4rFWnd4tFnlyPYGld4ep2v/FZdFzLvJB6U0HxZcWsOnwLGdClwpL4 hejopv3BfQFkDu/8WoubBDc+UXNcne8DEFp5yT15tPVMRxFKiGBox2u8wnTWVdSxLIsz zJcJM+KR8kbK+TKCt3iQQZw41VKE02+XbTxSVKsTdyyKfZxCatCedcMtvChq6ax/X5ny DwhMbHdcB7LQEFXWlXJWAiZg9WJCRFwB3E943lJdbSTBlpDAa8txCjQE026OFhxyqC5X vyRg== X-Gm-Message-State: AOPr4FWN8i1HzFBen2w9mw2/FPZxEgDwwsL2E4cZXpu9Vlbj1f1ObO1cGvdVPz6HxYVgxQ== X-Received: by 10.66.225.235 with SMTP id rn11mr50237380pac.138.1461606660766; Mon, 25 Apr 2016 10:51:00 -0700 (PDT) Received: from [192.168.1.234] (ppp-49-237-233-227.revip6.asianet.co.th. [49.237.233.227]) by smtp.gmail.com with ESMTPSA id zn12sm13390393pab.14.2016.04.25.10.50.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Apr 2016 10:51:00 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_108BFF6E-07E5-4D46-A4D5-109E31F33EFC"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Aaron Zauner In-Reply-To: Date: Tue, 26 Apr 2016 00:50:56 +0700 Message-Id: <366DFBD9-9B3B-40C3-B361-8CE28AA4A6FA@azet.org> References: To: Sean Turner X-Mailer: Apple Mail (2.3112) Archived-At: Cc: tls Subject: Re: [TLS] Call for WG adoption of draft-shore-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2016 17:51:02 -0000 --Apple-Mail=_108BFF6E-07E5-4D46-A4D5-109E31F33EFC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 25 Apr 2016, at 22:12, Sean Turner wrote: > - Support adoption and are willing to review/comment on the draft by = 201600429. Note that the extensions is pretty straight forward, but the = chairs still need people to comment on the draft as we=E2=80=99re = processing it down the path. ... >=20 > [0] https://www.ietf.org/proceedings/93/slides/slides-93-tls-1.pdf > [1] https://www.ietf.org/proceedings/95/slides/slides-95-tls-3.pdf This seems like a good idea. I support adoption of this draft. Aaron --Apple-Mail=_108BFF6E-07E5-4D46-A4D5-109E31F33EFC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXHlkAAAoJEOTbZJL9ubXVWKgP/0o8DsMolTkCQrdSayCh0vE2 S/2Ge56+p9yEGh4sd2eNzRkM53s1u3tUsLpqEklpeiECYgG3/pmEoTagWv1pdqpp eZ6ojjlVgVitFTYuPEhomK314zrs8HlrZQ6FhO0zd3DH1eGPXEIBLYNtU623VylX 3xCxgfWXHx2NWrEocFW8JhNLUsVnU8V/t9PsN5Fn0nMyJ5pl6m2NrYQwXi8QGTOD /8Dps6NEiIGdLmT7PxU7gp3KwAmhqTruIWswZ6rABPzkkrAJi2iUkW/JAJAVTOnP TTCmHQgcj0PkpoStnhBT/R5cQMv7gqAHaibZGQdbuEKT+jYkK8hvUbf5YeDPI9It qRogyuNKIm4rlt7LojUtV3e6WR5auXyf9u07/B0a8oQpg4GpQXeTc3ESr3u98VLa 8Lo0VcvsEbi7S/guHJF0TrjlpddbOWkAMW/8OTQhVwcOzvmMYe9rsoEclIs9Y0Dv ZDBpBV2vDmE6q3BZlIUQv5hdx61yZCzNoyOW6ergv37BDxBZe2n8bBbmdsPpW1zI rH/Hj9uMo8BVDfxC39IfPM/H4wGnof3tg8PZDpMUdsI1UxWEdgOEvrIkWw6qbbma yQ22xdek7wV5z15XRDh15X/Bduu+ABscRCIR1yd67PZTpOKixEuYm2m3I4sKunU6 00n9vedi80TZ9j1wz2eX =IA54 -----END PGP SIGNATURE----- --Apple-Mail=_108BFF6E-07E5-4D46-A4D5-109E31F33EFC-- From nobody Mon Apr 25 10:53:11 2016 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 5E70E12B041 for ; Mon, 25 Apr 2016 10:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.697 X-Spam-Level: X-Spam-Status: No, score=-3.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wI4B6_-Bfrl5 for ; Mon, 25 Apr 2016 10:53:08 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9E70E12D0A0 for ; Mon, 25 Apr 2016 10:53:08 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9B9FE433447; Mon, 25 Apr 2016 17:53:02 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 5B77343340A; Mon, 25 Apr 2016 17:53:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1461606782; bh=1g1lDUxy0ol5jY+EthfMRyEoEn627B+f7scJyr0KLrU=; l=156; h=From:To:CC:Date:References:In-Reply-To:From; b=dWygOWXIgxMZuFiWaJF/eUdGJXk2jaOj9YyfIbrPMpiootHl88RtHP4GKz/+Ga0gw q56bCNspljBdRAJLIjK2JbMmgrMsVQ1bqB9wbqrgf/4hC3uI6FvrNkzxiJtwr3C3V6 oU33UsTX/v8HEBVfE+EOTMpRbsE74kP6g4SnfOLw= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 515D91FC8B; Mon, 25 Apr 2016 17:53:02 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 25 Apr 2016 13:53:01 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Mon, 25 Apr 2016 13:53:01 -0400 From: "Salz, Rich" To: Sean Turner Thread-Topic: [TLS] Call for WG adoption of draft-shore-tls-dnssec-chain-extension Thread-Index: AQHRnwTeAxr7OylqbE2J1G/V4r52mp+bOw0A//+9d+A= Date: Mon, 25 Apr 2016 17:53:01 +0000 Message-ID: References: <366DFBD9-9B3B-40C3-B361-8CE28AA4A6FA@azet.org> In-Reply-To: <366DFBD9-9B3B-40C3-B361-8CE28AA4A6FA@azet.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: tls Subject: Re: [TLS] Call for WG adoption of draft-shore-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2016 17:53:10 -0000 SSBzdXBwb3J0IGFkb3B0aW9uLg0KDQotLSAgDQpTZW5pb3IgQXJjaGl0ZWN0LCBBa2FtYWkgVGVj aG5vbG9naWVzDQpJTTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6IFJpY2hTYWx6DQoNCg0K From nobody Mon Apr 25 11:07:16 2016 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 C0B6812D530 for ; Mon, 25 Apr 2016 11:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPgwrenpdyXD for ; Mon, 25 Apr 2016 11:07:12 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1C7D12D0EF for ; Mon, 25 Apr 2016 11:07:12 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 6433838EA2 for ; Mon, 25 Apr 2016 11:07:12 -0700 (PDT) From: "Jim Schaad" To: Date: Mon, 25 Apr 2016 11:07:12 -0700 Message-ID: <048101d19f1d$4b0c99c0$e125cd40$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdGfHNNpCJwY1RmmS8CND4nuwBjZuw== Content-Language: en-us Archived-At: Subject: [TLS] NewSessionTicketFormat - for PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2016 18:07:14 -0000 I was looking at how TLS 1.3 was going to fit into an upgrade from the existing 1.2 version that is used for RADIUS and having vague memories of what was going on during the F2F meeting and I ended up with the following question. We are planning to indicate in the NewSessionTicket items such as if early data is going to be allowed. Do we need to make some statements someplace about if early data is going to be accepted for a pure PSK (or PSK-ECDH) configuration either as an marker that it needs to be configured into the client or as a indication sent back from the server to the client that it will or will not accept early data when connecting? Does this apply to some of the other fields that were being discussed as being encoded into the ticket as well? Jim From nobody Mon Apr 25 11:10:34 2016 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 50AE812D10A for ; Mon, 25 Apr 2016 11:10: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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ua6Ivxa5hv1T for ; Mon, 25 Apr 2016 11:10:32 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA46612B041 for ; Mon, 25 Apr 2016 11:10:31 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id t10so229309248ywa.0 for ; Mon, 25 Apr 2016 11:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u7mjF+FnoJSkmje3FAoXUHtGOHhUG9ZRHgVOZxyRaOw=; b=EvttiCr5mxNU0pOxo+sqF9i4fMCV+CDHVD++QKyx+l4xAfxJLCFv5P0LKR5jxV3tyQ JQgVs8MQcUszeNEjtd3U1dHIQvr1r64WERlsu5w3c0xyDQ2wMed3m9aalAvyqqjthGYB TpcDDoovPTzz5SsWDkdnF+dyrk6aHVg8nJcVWmMqmpFh7YnaYN5R1w70hJc83xLsaFsX za2KoCjjWtEXJ12q0yZkMLYQ8NBOu7ACR9/tcCRY0IWWEH5mHVI1n5QJJClL55DPkX+V dUyfvccinyppb/Qrmc5FS7FeomjX8bhvgninKxgaxU1+XNBqIuJggFIhOs+ESv5ZHPxY DOJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u7mjF+FnoJSkmje3FAoXUHtGOHhUG9ZRHgVOZxyRaOw=; b=L1mtXVZVzQhdMEVlCz9E27GwejVvTpUK/oYkyFoj6/AOzQlfSovMTZku60NoMewBQG sa52crE2e3vvit2BqapsKz8kua3ne/UBYaYc40sxhlgOFWTnjBP25la/+KsDLBC4kScf 1sreAc3H9TTA2+jlFarJWuyK32qmiVy2e1l8l3jajJysRI+sfFPZ1r2pLYbFqRPzUHYK Ml+epRkhX6721OZwrCK26WbKQO7r9yuHJv0WvauzGGndv7KOpCPSveUgyauqqOTWQpOY TX5NZvw5WRvl+fIYx3JB914kyR+UYrBV5kdBRkxOQB9bZtmStKCAePKSl9colHvN+iPn SP/A== X-Gm-Message-State: AOPr4FW38lCmY8T2QodbWNg21TiiCEbXohmlNKm8/3VXAF/MMZRGFWcJkS6jeDfQQfOWiGFVU5fSx7KOMSWesg== X-Received: by 10.37.80.199 with SMTP id e190mr20145364ybb.162.1461607831042; Mon, 25 Apr 2016 11:10:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Mon, 25 Apr 2016 11:09:51 -0700 (PDT) In-Reply-To: <048101d19f1d$4b0c99c0$e125cd40$@augustcellars.com> References: <048101d19f1d$4b0c99c0$e125cd40$@augustcellars.com> From: Eric Rescorla Date: Mon, 25 Apr 2016 11:09:51 -0700 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=001a113e9b769229a30531531776 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] NewSessionTicketFormat - for PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2016 18:10:33 -0000 --001a113e9b769229a30531531776 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 25, 2016 at 11:07 AM, Jim Schaad wrote: > I was looking at how TLS 1.3 was going to fit into an upgrade from the > existing 1.2 version that is used for RADIUS and having vague memories of > what was going on during the F2F meeting and I ended up with the following > question. > > We are planning to indicate in the NewSessionTicket items such as if early > data is going to be allowed. Do we need to make some statements someplace > about if early data is going to be accepted for a pure PSK (or PSK-ECDH) > configuration either as an marker that it needs to be configured into the > client or as a indication sent back from the server to the client that it > will or will not accept early data when connecting? There is no way to do do early data with PSK-ECDH because the data is encrypted under the PSK only. -Ekr Does this apply to > some of the other fields that were being discussed as being encoded into > the > ticket as well? > > Jim > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113e9b769229a30531531776 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 25, 2016 at 11:07 AM, Jim Schaad <ietf@augustcellars.= com> wrote:
I was looking a= t how TLS 1.3 was going to fit into an upgrade from the
existing 1.2 version that is used for RADIUS and having vague memories of what was going on during the F2F meeting and I ended up with the following<= br> question.

We are planning to indicate in the NewSessionTicket items such as if early<= br> data is going to be allowed.=C2=A0 Do we need to make some statements somep= lace
about if early data is going to be accepted for a pure PSK (or PSK-ECDH) configuration either as an marker that it needs to be configured into the client or as a indication sent back from the server to the client that it will or will not accept early data when connecting?=C2=A0

There is no way to do do early data with PSK-ECDH because t= he data is
encrypted under the PSK only.

-Ekr


=C2= =A0Does this apply to
some of the other fields that were being discussed as being encoded into th= e
ticket as well?

Jim


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

--001a113e9b769229a30531531776-- From nobody Mon Apr 25 12:13:14 2016 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 CBE2812D67A for ; Mon, 25 Apr 2016 12:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0N-7X5pNYV0T for ; Mon, 25 Apr 2016 12:13:12 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36FB712D670 for ; Mon, 25 Apr 2016 12:13:12 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id CE0252C9C5; Mon, 25 Apr 2016 12:13:11 -0700 (PDT) From: "Jim Schaad" To: "'Eric Rescorla'" References: <048101d19f1d$4b0c99c0$e125cd40$@augustcellars.com> In-Reply-To: Date: Mon, 25 Apr 2016 12:13:11 -0700 Message-ID: <049301d19f26$82bd9050$8838b0f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0494_01D19EEB.D65F7BA0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKX0AD9UJ6hI1np2smKXp7XZ6fJlAG9c6XmngDBCZA= Content-Language: en-us Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] NewSessionTicketFormat - for PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2016 19:13:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0494_01D19EEB.D65F7BA0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: Monday, April 25, 2016 11:10 AM To: Jim Schaad Cc: tls@ietf.org Subject: Re: [TLS] NewSessionTicketFormat - for PSK =20 =20 =20 On Mon, Apr 25, 2016 at 11:07 AM, Jim Schaad > wrote: I was looking at how TLS 1.3 was going to fit into an upgrade from the existing 1.2 version that is used for RADIUS and having vague memories = of what was going on during the F2F meeting and I ended up with the = following question. We are planning to indicate in the NewSessionTicket items such as if = early data is going to be allowed. Do we need to make some statements = someplace about if early data is going to be accepted for a pure PSK (or PSK-ECDH) configuration either as an marker that it needs to be configured into = the client or as a indication sent back from the server to the client that = it will or will not accept early data when connecting? =20 =20 There is no way to do do early data with PSK-ECDH because the data is encrypted under the PSK only. =20 -Ekr =20 What about the case of just pure PSK? =20 =20 I also assume that there is nothing to stop from getting a ticket if I = connect using PSK to begin with. =20 Jim =20 =20 =20 Does this apply to some of the other fields that were being discussed as being encoded into = the ticket as well? Jim _______________________________________________ TLS mailing list TLS@ietf.org =20 https://www.ietf.org/mailman/listinfo/tls =20 ------=_NextPart_000_0494_01D19EEB.D65F7BA0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From:<= /b> = TLS [mailto:tls-bounces@ietf.org] On Behalf Of Eric = Rescorla
Sent: Monday, April 25, 2016 11:10 AM
To: = Jim Schaad <ietf@augustcellars.com>
Cc: = tls@ietf.org
Subject: Re: [TLS] NewSessionTicketFormat - for = PSK

 

 

 

On Mon, Apr 25, 2016 at = 11:07 AM, Jim Schaad <ietf@augustcellars.com> = wrote:

I was looking at how TLS 1.3 was going to fit = into an upgrade from the
existing 1.2 version that is used for RADIUS = and having vague memories of
what was going on during the F2F meeting = and I ended up with the following
question.

We are planning to = indicate in the NewSessionTicket items such as if early
data is going = to be allowed.  Do we need to make some statements = someplace
about if early data is going to be accepted for a pure PSK = (or PSK-ECDH)
configuration either as an marker that it needs to be = configured into the
client or as a indication sent back from the = server to the client that it
will or will not accept early data when = connecting? 

 

There is no way to do do = early data with PSK-ECDH because the data is

encrypted under the PSK = only.

 

-Ekr

 

What about = the case of just pure PSK?=C2=A0

 

I also = assume that there is nothing to stop from getting a ticket if I connect = using PSK to begin with.

 

Jim

 

 

 

 Does this apply to
some of the other = fields that were being discussed as being encoded into the
ticket as = well?

Jim


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

 

= ------=_NextPart_000_0494_01D19EEB.D65F7BA0-- From nobody Mon Apr 25 12:30:24 2016 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 C0E1212D0B4 for ; Mon, 25 Apr 2016 12:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y79mLv8eFrEJ for ; Mon, 25 Apr 2016 12:30:21 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4E9C12D537 for ; Mon, 25 Apr 2016 12:30:20 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id r12so24404235wme.0 for ; Mon, 25 Apr 2016 12:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=dDRZirvEOzT0rHZ7/6jYWuFDnpp0cxNr3+2dsXE4dHo=; b=Y642W+gUjRd/Fd+T3X+/076R324UgZree808DBwH67Tmohkq9mbYYDHqSlCvNcBy0W ALPZSSbyq35YRaZF6ly2avLqPxSsKUAiEcAkackuhfbTs0fAnt9cT8IZ1Fdv9DCF6u4T ghATjwnE/HVc6HQ8Cox9NQTHbDzO4F5HDN2BbxVWhVh+QBbpdsvU+gcMhnIP//wDuah6 /tC5h0J7DwtVmQool6hnEG3T6fw7wNVx7irfd2cNN0P7upNU0D8MyjNP6/5tmZbX0itO JA+Eikon0PaCVYeMBTj2q74JlKfY1NSaEpLcBRMs90BtRRY9v3ML5touv4tSEKwEjyg+ Vaeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=dDRZirvEOzT0rHZ7/6jYWuFDnpp0cxNr3+2dsXE4dHo=; b=g2e1ZqaaH3vhRnftYOjXobk0HMZ/Q3ZbFdOPoMABonaJ5vvKm4+pO2mZBY4CBD7bD9 WmigIRK9YYr23zTlDgzPdaByU8EOfM/uVe6dOmvD9B7wUGC3DLnAgMzw0Ey5oQ1pvrOl k/26BiC45Tx3RHjiMJqGULYI6GEalV87wNV/s4qc5bLOQSsPTgtOUwOTdVLnuN1YDlZd uKoLEBsneTQv4sC0JHuyops6kaMeFQBKXgqsJ4tYo89plk1iWMhg+7wi2ILF5HmG7lPd t18m25v1P+OYFG8BjIj4oBIK1qtLSErWwk8cb9WXWPGogpSS5zJx2GwSJ3Eh/j97MdUD +YVA== X-Gm-Message-State: AOPr4FUgoZaTzMhMuHkRo/yiPjKXdXE7KUSEmvtCqXP9+GTCNCnv7IXjVeeZgry0205hNPnvfpBiKVuXnk8XsQ== MIME-Version: 1.0 X-Received: by 10.195.6.65 with SMTP id cs1mr28881863wjd.8.1461612619453; Mon, 25 Apr 2016 12:30:19 -0700 (PDT) Sender: mglt.ietf@gmail.com Received: by 10.194.78.163 with HTTP; Mon, 25 Apr 2016 12:30:19 -0700 (PDT) In-Reply-To: References: <366DFBD9-9B3B-40C3-B361-8CE28AA4A6FA@azet.org> Date: Mon, 25 Apr 2016 15:30:19 -0400 X-Google-Sender-Auth: xT9LPRSTN_4n9KBUvkyQ-tPNRWk Message-ID: From: Daniel Migault To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a11c296aefb613d05315434c9 Archived-At: Cc: tls Subject: Re: [TLS] Call for WG adoption of draft-shore-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2016 19:30:23 -0000 --001a11c296aefb613d05315434c9 Content-Type: text/plain; charset=UTF-8 I support the adoption of the draft. On Mon, Apr 25, 2016 at 1:53 PM, Salz, Rich wrote: > I support adoption. > > -- > Senior Architect, Akamai Technologies > IM: richsalz@jabber.at Twitter: RichSalz > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c296aefb613d05315434c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support the adoption of the draft.

On Mon, Apr 25, 2016 at 1:5= 3 PM, Salz, Rich <rsalz@akamai.com> wrote:
I support adoption.

--
Senior Architect, Akamai Technologies
IM: richsalz@jabber.at Twitter: R= ichSalz


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

--001a11c296aefb613d05315434c9-- From nobody Mon Apr 25 12:31:42 2016 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 05DE512D6B8 for ; Mon, 25 Apr 2016 12:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCpg1QOqv8fh for ; Mon, 25 Apr 2016 12:31:40 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0762.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:762]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C74E412D0B4 for ; Mon, 25 Apr 2016 12:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UxH9pNJd9zGNvqwn6TM0oLyL02m7IW3AoUuIxsbVpcI=; b=SJbm9DdyQHse0paxr5xAG83GZAebOhVOS7AZadKRsF5Qb3o+Mm0IiBUezDuX6Dzxy4lqyoUGSS4dfJjzvKZiKz8cKPCZNIg/IFcbMiMQ3ARKZETkqz5/RzT7bJIMjP5byygsPGDB5x5mH6k4m4vJm0kViF6wf/1U6CN1DuTQrBo= Received: from BN3PR03MB1445.namprd03.prod.outlook.com (10.163.34.28) by BN3PR03MB1447.namprd03.prod.outlook.com (10.163.34.30) with Microsoft SMTP Server (TLS) id 15.1.477.8; Mon, 25 Apr 2016 19:31:18 +0000 Received: from BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) by BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) with mapi id 15.01.0477.012; Mon, 25 Apr 2016 19:31:18 +0000 From: Andrei Popov To: Sean Turner , tls Thread-Topic: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead Thread-Index: AQHRnwWl2EYt8+fXEE6a8m2b3XjO25+azkOAgABDrWA= Date: Mon, 25 Apr 2016 19:31:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sn3rd.com; dkim=none (message not signed) header.d=none;sn3rd.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:e::1d2] x-ms-office365-filtering-correlation-id: 2a1241eb-588c-4a49-f19d-08d36d402cca x-microsoft-exchange-diagnostics: 1; BN3PR03MB1447; 5:mZSQW9JXWL0TxJNhm/f/fFGeY4Izuc4fcb6pqS0Ch4eC09BI4nQ3d26StFgtk5gf7QDm4pIfRaHLvWz7i+g9E9Gs//Wg0y7yItqneThLXGt2Ut2pRNv1CoNFL33DznxuVTyz8ifXb8Ymw+eX2uyoiA==; 24:KbeaWmoMIRRFGPhiaLvux+0whP6gr9YSoDw7d4u69A050fKsAwpH9HyXrhnkUL9o1FYI3Ev5H1ESmwh1BybDy2U9g7fk8wsQSys2JNJMXDY=; 7:UVUqRbn5z3Ybmh4jvH6yEMjYW9D13duDvaB7XCUettD4+APY40HJ2YvhmV7YV6QJm+SAZHGrbM5JyEE9MF6LODnNMrM7ZJWGgcOLBmWs9zphs/iubjMKIb6OhnRy+lzCMPJQZ+hLCKBOP6lwoHkNJi7O98ftrqI7V95vF2YWxaRuksbiDQGij+JZDr8bRhGv7vwdH4d4M/ggHnx5mBBuKQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1447; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521072)(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN3PR03MB1447; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1447; x-forefront-prvs: 0923977CCA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(13464003)(76576001)(106116001)(86362001)(99286002)(9686002)(76176999)(586003)(15975445007)(2906002)(102836003)(54356999)(6116002)(5002640100001)(74316001)(50986999)(3660700001)(92566002)(19580405001)(19580395003)(189998001)(5001770100001)(10090500001)(11100500001)(1220700001)(1096002)(107886002)(81166005)(2900100001)(3280700002)(2950100001)(5003600100002)(5004730100002)(5008740100001)(10400500002)(10290500002)(87936001)(77096005)(230783001)(5005710100001)(86612001)(122556002)(33656002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB1447; H:BN3PR03MB1445.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2016 19:31:18.4172 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1447 Archived-At: Subject: Re: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2016 19:31:42 -0000 SSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQuIE5vIHJlYXNvbiB0byBsaW1pdCBFQ0RI RV9QU0sgdG8gQ0JDLg0KDQpDaGVlcnMsDQoNCkFuZHJlaSANCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgU2VhbiBUdXJuZXINClNlbnQ6IE1vbmRheSwgQXByaWwgMjUsIDIwMTYgODoyMiBBTQ0K VG86IHRscyA8dGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUTFNdIENhbGwgZm9yIFdHIGFk b3B0aW9uIG9mIGRyYWZ0LW1hdHRzc29uLXRscy1lY2RoZS1wc2stYWVhZA0KDQpzaWdoIGFuZCBo ZXJlIGFzIHdlbGwgLSB0aGV5IHNob3VsZCBoYXZlIGJlZW4gMjAxNjA1MTAuDQoNCnNwdA0KDQo+ IE9uIEFwciAyNSwgMjAxNiwgYXQgMDg6MTcsIFNlYW4gVHVybmVyIDxzZWFuQHNuM3JkLmNvbT4g d3JvdGU6DQo+IA0KPiBBbGwsDQo+IA0KPiBkcmFmdC1tYXR0c3Nvbi10bHMtZWNkaGUtcHNrLWFl YWQgaW5jbHVkZXMgc29tZSBjaXBoZXIgc3VpdGVzIHRoYXQgYXJlIG5lZWRlZCBmb3IgVExTMS4z LiAgV2UgbmVlZCB0byBnZXQgdGhlc2Ugb2ZmaWNpYWxseSByZWdpc3RlcmVkIHNvIHRoZSBjaGFp cnMgd291bGQgbGlrZSB0byBoZWFyIHdoZXRoZXIgdGhlcmUgaXMgV0cgc3VwcG9ydCBmb3IgYWRv cHRpbmcgZHJhZnQtbWF0dHNzb24tdGxzLWVjZGhlLXBzay1hZWFkLiBQbGVhc2UgbGV0IHVzIGtu b3cgd2hldGhlciB5b3U6DQo+IA0KPiAtIFN1cHBvcnQgYWRvcHRpb24gYW5kIGFyZSB3aWxsaW5n IHRvIHJldmlldy9jb21tZW50IG9uIHRoZSBkcmFmdCBieSAyMDE2MDA0Mjk7IHRoZSBjaGFpcnMg c3RpbGwgbmVlZCBwZW9wbGUgdG8gcmV2aWV3IHRoZSBkcmFmdCB0byBzaG93IHRoZXJl4oCZcyBz dXBwb3J0IGZvciBpdCBhcyB3ZSBwcm9jZXNzIGl0IGRvd24gdGhlIHBhdGguDQo+IA0KPiAtIE9i amVjdCB0byB0aGUgYWRvcHRpb24gb2YgdGhpcyBkcmFmdCBhcyBhIFdHIGl0ZW0sIHBsZWFzZSBy ZXNwb25kIHRvIHRoZSBsaXN0IGluZGljYXRpbmcgd2h5IGJ5IDIwMTYwMDQyOS4NCj4gDQo+IE5v dGUgMTogVGhpcyBkcmFmdCB3aWxsIGdldCBwdWJsaXNoZWQgdXNpbmcgdGhlIG5ldyBydWxlcyB3 ZeKAmXZlIGJlZW4gY29uY29jdGluZyBvbiB0aGUgbGlzdCBzbyB0aGUgSUFOQSBjb25zaWRlcmF0 aW9ucyBzZWN0aW9uIHdpbGwgZ2V0IHR3ZWFrZWQgYXMgd2Ugc2V0dGxlIG9uIHdoYXQgd29yZHMg bmVlZCB0byBiZSBpbmNsdWRlZC4NCj4gDQo+IE5vdGUgMjogVGhlIG90aGVyIG9wdGlvbiBpcyB0 byBwdXQgdGhlIHJlZ2lzdHJhdGlvbnMgaW4gdGhlIFRMUzEuMyBzcGVjLCBidXQgdGhhdCB3b3Vs ZCBhZGQgZm91ciBwYWdlcyB0aGF0IEnigJltIHByZXR0eSBzdXJlIG5vIGltcGxlbWVudGVyIGlz IGdvaW5nIHRvIHJlYWQgc28gdGhlcmUgc2VlbXMgdG8gYmUgbGl0dGxlIHBvaW50IGluIGluY2x1 ZGVkIHRoZSByZWdpc3RyYXRpb25zIGluIHRoZSBUTFMxLjMgc3BlYy4gIEFuZCwgdGhlc2UgY2lw aGVyIHN1aXRlcyBkbyBhcHBseSB0byBUTFMxLjIuDQo+IA0KPiBDaGVlcnMsDQo+IA0KPiBKJlMN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBt YWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90bHMNCg== From nobody Mon Apr 25 13:07:39 2016 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 7681112B060 for ; Mon, 25 Apr 2016 13:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i58QEcL939JT for ; Mon, 25 Apr 2016 13:07:37 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFA1C12B01E for ; Mon, 25 Apr 2016 13:07:36 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id r78so188838619oie.0 for ; Mon, 25 Apr 2016 13:07:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tT0EtTI7kE5NxobW5W8CdD9M8GWOGyiQoQAbGi1d0R8=; b=j1Cs7r8BqOKcod5MyU0CJWXpnLjA3Q9AqO3TcHgkTTlvJjxHAgEo/yIN+ek42bkLjS QLTdLzW3m3OaKI9HgAf+geUNrg8VwxBrsc1JvcP3mYhLEyubJ76dsK+ErZXdK0/QleNd Ch1gOGTddqSvN+JPLplzFDvqlJ1aNCI6PjKhg2WL+RiAh7Jm51WD1xE2LJu4NqD1F1c0 JW4zyg0Xyfz0OdH2f8qdmNw8RhYzVwJ07FrEP9uAQyOdk+1wsF6qnSSu/GFCSE/J0JbY +VeXDPcRu2KZD0dmz77wT747GJekmzXGWucZ7AuECm01Yog+8ieKFPO7dxbZa6LBjv1C bmsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tT0EtTI7kE5NxobW5W8CdD9M8GWOGyiQoQAbGi1d0R8=; b=NVPf6P0txWd3H3RU6+TwYt4N9XfNltLj5G1nga6PwCc3Zkp1mlZbknRjvxSlumPmd4 AS8KKQFd+tkfxdhSayxImhqAMxa+VXsEmF81A1MqtJPCj5bosu75anLNgkjVfZbSkQwN Ox2y0Ngb7d/BDMaoY8AIb6dz0RrvbmchOSr03yZU6DiLarh8aQ1safEPv+wWqO/kop2P hvzWBMhXia70x2pmgMQk3DgIqWvImxVwr9dSIu0NNOIVpEBYuRG7Eop2mDNCrfMfpShX oRxBJ3a+JUeGW0xvL6ea5kbuauDcHb17gjwKbQTS92caN9qDDeU9L4lJ/H/jGsfYr10H UuvA== X-Gm-Message-State: AOPr4FX3LetcyfaLfgWGXjpfIgYXaMAlzsXsjIIH9DiSvlpYjTSE7m0Mg7qr1iWSco0mTKuei7VrGWxtXDtC+g== X-Received: by 10.157.14.166 with SMTP id 35mr12614644otj.158.1461614856210; Mon, 25 Apr 2016 13:07:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Mon, 25 Apr 2016 13:06:54 -0700 (PDT) In-Reply-To: <049301d19f26$82bd9050$8838b0f0$@augustcellars.com> References: <048101d19f1d$4b0c99c0$e125cd40$@augustcellars.com> <049301d19f26$82bd9050$8838b0f0$@augustcellars.com> From: Eric Rescorla Date: Mon, 25 Apr 2016 13:06:54 -0700 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=001a113cf9464da367053154baaf Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] NewSessionTicketFormat - for PSK X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Apr 2016 20:07:38 -0000 --001a113cf9464da367053154baaf Content-Type: text/plain; charset=UTF-8 On Mon, Apr 25, 2016 at 12:13 PM, Jim Schaad wrote: > > > > > *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* Monday, April 25, 2016 11:10 AM > *To:* Jim Schaad > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] NewSessionTicketFormat - for PSK > > > > > > > > On Mon, Apr 25, 2016 at 11:07 AM, Jim Schaad > wrote: > > I was looking at how TLS 1.3 was going to fit into an upgrade from the > existing 1.2 version that is used for RADIUS and having vague memories of > what was going on during the F2F meeting and I ended up with the following > question. > > We are planning to indicate in the NewSessionTicket items such as if early > data is going to be allowed. Do we need to make some statements someplace > about if early data is going to be accepted for a pure PSK (or PSK-ECDH) > configuration either as an marker that it needs to be configured into the > client or as a indication sent back from the server to the client that it > will or will not accept early data when connecting? > > > > There is no way to do do early data with PSK-ECDH because the data is > > encrypted under the PSK only. > > > > -Ekr > > > > What about the case of just pure PSK? > > > > I also assume that there is nothing to stop from getting a ticket if I > connect using PSK to begin with. > Yes... Maybe I'm missing your point -Ekr > > Jim > > > > > > > > Does this apply to > some of the other fields that were being discussed as being encoded into > the > ticket as well? > > Jim > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > --001a113cf9464da367053154baaf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 25, 2016 at 12:13 PM, Jim Schaad <ietf@augustcellars.= com> wrote:

=C2= =A0

=C2=A0

From: TL= S [mailto:tls-bou= nces@ietf.org] On Behalf Of Eric Rescorla
Sent: Monday= , April 25, 2016 11:10 AM
To: Jim Schaad <ietf@augustcellars.com>
<= b>Cc: tls@ietf.org
Subject: Re: [TLS] NewSessionTicketFormat - for PSK

=C2= =A0

=C2=A0

=C2=A0

On Mon, Apr 25, 2016 at 11:07 AM, Jim Schaad <ietf@augustcellars.com= > wrote:

I was looking a= t how TLS 1.3 was going to fit into an upgrade from the
existing 1.2 ver= sion that is used for RADIUS and having vague memories of
what was going= on during the F2F meeting and I ended up with the following
question.
We are planning to indicate in the NewSessionTicket items such as if = early
data is going to be allowed.=C2=A0 Do we need to make some stateme= nts someplace
about if early data is going to be accepted for a pure PSK= (or PSK-ECDH)
configuration either as an marker that it needs to be con= figured into the
client or as a indication sent back from the server to = the client that it
will or will not accept early data when connecting?= =C2=A0

=C2=A0

There is no way to do do early data with PSK-EC= DH because the data is

encrypted under the PSK only.

=C2=A0=

-Ekr

=C2=A0<= /p>

What about the case of just pure PSK?=C2=A0 <= /u>

=C2=A0

I also assume that there is nothing to stop from g= etting a ticket if I connect using PSK to begin with.


Yes... Maybe I= 9;m missing your point

-Ekr

=C2=A0<= u>

Jim

=C2=A0

= =C2=A0

=C2=A0

=C2=A0Does this= apply to
some of the other fields that were being discussed as being en= coded into the
ticket as well?

Jim


___________________= ____________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/li= stinfo/tls

=C2=A0

=

--001a113cf9464da367053154baaf-- From nobody Tue Apr 26 02:22:12 2016 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 9A35212B069 for ; Tue, 26 Apr 2016 02:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LrCw6TE3kWE for ; Tue, 26 Apr 2016 02:22:09 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C09812B01F for ; Tue, 26 Apr 2016 02:22:08 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id x7so3028439qkd.3 for ; Tue, 26 Apr 2016 02:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=SWUaooSwsPJiN3thJbyoOblQVcN7OG7JtHZG31atoUE=; b=J9p9S1cA9LGBBR4UxJzyifr/V/XjLWu8k+sOas2Rt/AY/upgUmqnHqOSnSSNdDbzxi SxTZ7KRkli3DGa9owzX6tKSD8fF1QEZpdEq0ShFtEDFwhSRVYGbA29QeFWzwzP65yRbh 9tTF9S5+n6qplNSP9JQCMX4yc8RMoFt4wWjJGFSRpsYCkmuEX5F3HVs4I1//I3xOuhz+ fQJuTMGlVJrHtkPLbxjaZyz1oAF537VQVlMYiLyEB22b/X8/rOJ7i+XTvZfgwopjLpKB AoaObPOHnaDnexNmmlqjxjJvzqQLj8WZ+6M4xICm6vAfLhr/bQ/FXuQAL37g/qAd6x6t KPTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=SWUaooSwsPJiN3thJbyoOblQVcN7OG7JtHZG31atoUE=; b=PRxezRaxWeqxcCBSAaEDgSgBmgqr8lvwzBkiKwUzF/BYtEWcqu0lGnZP7Ckj1tyzjx 6bFbb62uyot/1QOvdsavXX9JRZng4PlmVpTS2qIOmqcOVMp2FWiqn3RMGKw+fsHRDU2/ FW+SEfIw4wED/AVtSlb9yajzeJHhbJX4hLEt6sk6x/2tOkmDxXpWA5sOQadHKgpouaSS GYTapIrVD8a/TXz9HW6UVYCn1E/pwC5CP1ZTjCTjf5aZkkC2HOu8/5OQDe31dfcDsY7A nqtzkwbe/DalU7LMG4V3t3CrraRrh9tRJ+NmvAZ3KqxTKyqPvtNMt17LDfI9HMNNIvdC yyBg== X-Gm-Message-State: AOPr4FV+gvvCIycE/BJ+FQBo0hdEojt032w04FSOyu7FuJhVzy3fZCiHXG+6Z/AdpxSQyQ== X-Received: by 10.55.79.5 with SMTP id d5mr1184067qkb.30.1461662528104; Tue, 26 Apr 2016 02:22:08 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-36-244.phlapa.fios.verizon.net. [72.94.36.244]) by smtp.gmail.com with ESMTPSA id r18sm8524286qhb.35.2016.04.26.02.22.07 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 26 Apr 2016 02:22:07 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Tue, 26 Apr 2016 05:22:05 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201604260522.05723.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 09:22:11 -0000 Just to make note on-list, I support adoption of the draft. I've already ci= ted it in the current TLS 1.3 draft as a normative reference, and thus cons= ider it required for completion of the new version. One objection to part of the current draft, though, which I think needs cha= nging. It currently states that implementations have a MUST-level requireme= nt to use no less than 255-bit curves with AES-128 and 384-bit curves with = AES-256. Due to discussion on here a bit back, my current opinion is that t= he floor should be set to 255-bit for both. Yes, ideally you'd prefer compa= rable security levels, but AES-256 gives some PQ resistance and bigger ECC = is just as dead there as with a smaller curve. Transitioning to stronger sy= mmetric, over the long term, need not be held back by performance worries i= f some were required to use slower ECDHE, especially with some devices that= may be using PSK for performance reasons. Also, I'd much prefer this be adopted as a separate draft and not merged fu= lly into the TLS 1.3 draft. Dave On Monday, April 25, 2016 11:17:45 am Sean Turner wrote: > draft-mattsson-tls-ecdhe-psk-aead includes some cipher suites that are ne= eded for TLS1.3. We need to get these officially registered so the chairs = would like to hear whether there is WG support for adopting draft-mattsson-= tls-ecdhe-psk-aead. Please let us know whether you: >=20 > - Support adoption and are willing to review/comment on the draft by 2016= 00429; the chairs still need people to review the draft to show there=E2=80= =99s support for it as we process it down the path. >=20 > - Object to the adoption of this draft as a WG item, please respond to th= e list indicating why by 201600429. >=20 > Note 1: This draft will get published using the new rules we=E2=80=99ve b= een concocting on the list so the IANA considerations section will get twea= ked as we settle on what words need to be included. >=20 > Note 2: The other option is to put the registrations in the TLS1.3 spec, = but that would add four pages that I=E2=80=99m pretty sure no implementer i= s going to read so there seems to be little point in included the registrat= ions in the TLS1.3 spec. And, these cipher suites do apply to TLS1.2. From nobody Tue Apr 26 04:22:54 2016 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 1623E12D098 for ; Tue, 26 Apr 2016 04:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IT1Sj_t_hiyH for ; Tue, 26 Apr 2016 04:22:51 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51AFE12B036 for ; Tue, 26 Apr 2016 04:22:51 -0700 (PDT) Received: by mail-ig0-x236.google.com with SMTP id bi2so93447887igb.0 for ; Tue, 26 Apr 2016 04:22:51 -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-transfer-encoding; bh=AMRYmVI7e8s2loT/zvwo8DKZkcisBMeM7jZfUfxIgGc=; b=uz4/YtIUqIR4hVjqQcYM2RROxCWfAVRZBoCK1FoZ5lF/K70qwQ8ngujwlSso/LAq0E 4xV00M7tZyuRwHyMHxEQGJQ5DRTklszNCcYqTbtWwr68kjWWup6r1k4b9TAk0iq+SLQp 92C0HHbqoDpmLtQh4XinM7Z5aL0Tkb43vh/f72mv9Ws58UHFXXFh0fWDhqJaPhqaOXcs VLhDTcc9bh1n2+Z9r7Nf1LrSuAtyNeWoy+h1PrzfiHcnUHSwvE4GG6NuNXRjxNLx7V3Z wA+ZfOX4p6gaJf4fQrrZutZwSDkvZ8WtHAVEpmg4JUUvCnYZTc/R5Cm8HfBkdLuJQtn4 J+Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=AMRYmVI7e8s2loT/zvwo8DKZkcisBMeM7jZfUfxIgGc=; b=P4rDTnodxZx6tj1Jt0ZVxa+r/ch2Jvo7qNAjC9ON85wd7WEoND/0nnlLxEZZbBhcbO z0LwtJ/4uB7v3sYD9cu5YCrYOFS1C0L2nIKWIa3mbebxPVdOYIvlt/ZPm5WZ7lqDkFIE VwyZBXcVioyPv31WLIeuaVzOMMTKB5ioBSd7wRaLQPtlHvVQ14RqD8pkpGZ6ekDskwQX 6epowvxmoHr1Km1Or8RS6g/e+sInzbZ9vCbWiLoSRhCbR3WWlWP9El2yoSk1cAWvi5WY Pv8OfeBgeEDzx75Pqwrqlh+t1hXODtsd+reFY+5v+L4WtI3WoafH2L+cuWhuaoDwPBcl SuCA== X-Gm-Message-State: AOPr4FUCfXsJfDThgQ6LxlEB/6Nf34JNwFczId10y34S+SVT/myxIxqrh4f9GyKAWmEv0yPTZJkn9en+QGX15Q== MIME-Version: 1.0 X-Received: by 10.50.221.67 with SMTP id qc3mr2989434igc.77.1461669770736; Tue, 26 Apr 2016 04:22:50 -0700 (PDT) Received: by 10.36.43.82 with HTTP; Tue, 26 Apr 2016 04:22:50 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Apr 2016 21:22:50 +1000 Message-ID: From: Martin Thomson To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tls Subject: Re: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 11:22:53 -0000 Yes, adopt. We need something approximately like this and I think that it can proceed well ahead of TLS 1.3. (Dave's nit seems reasonable, but adoption lets us fix that in the working group.) On 26 April 2016 at 05:31, Andrei Popov wrote: > I support adoption of this draft. No reason to limit ECDHE_PSK to CBC. > > Cheers, > > Andrei > > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Sean Turner > Sent: Monday, April 25, 2016 8:22 AM > To: tls > Subject: Re: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-a= ead > > sigh and here as well - they should have been 20160510. > > spt > >> On Apr 25, 2016, at 08:17, Sean Turner wrote: >> >> All, >> >> draft-mattsson-tls-ecdhe-psk-aead includes some cipher suites that are n= eeded for TLS1.3. We need to get these officially registered so the chairs= would like to hear whether there is WG support for adopting draft-mattsson= -tls-ecdhe-psk-aead. Please let us know whether you: >> >> - Support adoption and are willing to review/comment on the draft by 201= 600429; the chairs still need people to review the draft to show there=E2= =80=99s support for it as we process it down the path. >> >> - Object to the adoption of this draft as a WG item, please respond to t= he list indicating why by 201600429. >> >> Note 1: This draft will get published using the new rules we=E2=80=99ve = been concocting on the list so the IANA considerations section will get twe= aked as we settle on what words need to be included. >> >> Note 2: The other option is to put the registrations in the TLS1.3 spec,= but that would add four pages that I=E2=80=99m pretty sure no implementer = is going to read so there seems to be little point in included the registra= tions in the TLS1.3 spec. And, these cipher suites do apply to TLS1.2. >> >> Cheers, >> >> J&S > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Apr 26 07:05:58 2016 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 50AB612D1D4 for ; Tue, 26 Apr 2016 07:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.918 X-Spam-Level: X-Spam-Status: No, score=-7.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsH-U_f8xhub for ; Tue, 26 Apr 2016 07:05:50 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1644A12D1B2 for ; Tue, 26 Apr 2016 07:05:50 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C05C846291; Tue, 26 Apr 2016 14:05:49 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.2.205]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3QE5l2t023776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Apr 2016 10:05:49 -0400 Message-ID: <1461679547.15804.53.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Sean Turner , tls Date: Tue, 26 Apr 2016 16:05:47 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Subject: Re: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 14:05:56 -0000 On Mon, 2016-04-25 at 08:17 -0700, Sean Turner wrote: > All, > > draft-mattsson-tls-ecdhe-psk-aead includes some cipher suites that > are needed for TLS1.3.  We need to get these officially registered so > the chairs would like to hear whether there is WG support for > adopting draft-mattsson-tls-ecdhe-psk-aead. Please let us know > whether you: I support this draft. However see comment below. The text: "For the AES-128 cipher suites, the TLS Pseudorandom Function (PRF) with SHA-256 as the hash function SHALL be used and Clients and Servers MUST NOT negotiate curves of less than 255 bits." is very tricky. Implementations do not restrict ciphersuites based on curves (there is no such notion in TLS, nor mentioned in rfc4492), and I cannot even think how a TLS handshake implementation would look like if each different ciphersuite has specific curve requirements. Note that this requirement is unlike the suiteB RFC (rfc6460) that also restricts the curves. SuiteB specifies a profile/set of parameters which include ciphersuites, while this draft only defines ciphersuite code points. If a side goal of this draft is to deprecate the <255 bit elliptic curves from TLS 1.2, or to unify security levels across ciphersuites then I'd recommend to do that with a separate RFC rather than bundling it into a code-point assignment RFC. regards, Nikos From nobody Tue Apr 26 08:20:43 2016 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 B3B2512D1E9 for ; Tue, 26 Apr 2016 08:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ojg-af3j3M0f for ; Tue, 26 Apr 2016 08:20:36 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC3E12D0AD for ; Tue, 26 Apr 2016 08:20:34 -0700 (PDT) Received: from [192.168.10.140] ([80.92.119.69]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M7ojs-1bhQFD09i4-00vPVl; Tue, 26 Apr 2016 17:20:31 +0200 To: Sean Turner , tls References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <571F8748.1000202@gmx.net> Date: Tue, 26 Apr 2016 17:20:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fUShOL5dBfwsIvj68DGi8aq7joVi8xSBf" X-Provags-ID: V03:K0:AquvX82ZiIg3F8RD1L5HOdGRD6WdPb9uqHQTjceyFRyKn2iKTBr GlexrVMHNju9uG2EMZP7OuJ0y9pGtMvGwMThVp3t/NiauIBltQFthTp9kzLkaYrNYnypQUh tKpLR4SRvv9L32Zy3vO8znjvW1PbUUg/wuar/kMHKqbkX2RYBLcrMTasnQ00Tmm6HsXoVAr hu6KwDuCk/sNmJ86rOBDA== X-UI-Out-Filterresults: notjunk:1;V01:K0:J6aV2mG1IPo=:6Uezt9ewfiJ9t6PHqn+Nzs 5HWE2d1K91hCUELZ92OyLpHxykGgvU3WH2kBlb76RX37NF/8sAnFiR9J+BBk+D4h1chkWZ8q3 n3bJX/x8wtVXfe3dSmS6DxkEX2EqlqkrpflxhfaEj138ceFNq4nCkF+kPWU4EDK2JKww2JEwQ 6Kv2uLMzXL9bIqNMEd94WwOk94VPihzA2bvtq/muIwjD0T9aUamtaYt2JP/DyqFjrR3eqg8Bx Jg0Bx6CqOQNlJzuFigzUNamwFexylgfmd0IB7iWNiAYunDK48bn+74avJ7LpCYo1+RpOyiDqJ /WAt0DtPYYtXarsqouL01sYC1XZG0fFdyrPVCSage5+KElpxLfrSEHImInq+7dlRKfPcm8uzT 9+muXMOFvG44CVGyzhHtnfEnSTwZZwW6ZWryQz8w+EbYt0ke46s1g+wG+Q3GHxhbzRtukjO9S GFad064nDw0I6XMHShC10YYdoWVwMGiNoXOnxoZ0h/quulEJpfHLcRLLapVtHil6nmYPrN6W2 QYMPKx3sgmtMYCfGPnWWX3+wDm6gEAIQowQukKDj0I7D0VmD8ETaWbM7nF1jBYl75ileUIz7D Jm/XBYcInISGsHNK2tOo7hITVWyjIZ0rfS8iZgciSZbcWGAQd/cizldF2QLVDct56CpDGU+Da yZvaNoan2VUy5d7oF9foMT1a7nX9VFYvPKre9wVLtXopiDD4zmiTM5IJaa4atZm/hZXJ/mHN/ C9LyexKjQdtq/uf++pnpDRDZke/8+MlSF87duws8kJktmeGiCKtmueYa1E8= Archived-At: Subject: Re: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 15:20:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fUShOL5dBfwsIvj68DGi8aq7joVi8xSBf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable My 5 cents. For the IoT environment this ciphersuite is not very useful. If you want the best possible performance, lowest RAM utilization and use as little flash as possible then you go for a plain PSK ciphersuite (without DH/ECDHE). If you are already paying the price of the asymmetric crypto (in terms of flash usage/CPU speed/RAM utilization then just switch to a raw public key or a certificate based ciphersuite (since there is very little additional overhead). I suspect the usage is more for the we or so? Ciao Hannes On 04/25/2016 05:17 PM, Sean Turner wrote: > All, >=20 > draft-mattsson-tls-ecdhe-psk-aead includes some cipher suites that are = needed for TLS1.3. We need to get these officially registered so the cha= irs would like to hear whether there is WG support for adopting draft-mat= tsson-tls-ecdhe-psk-aead. Please let us know whether you: >=20 > - Support adoption and are willing to review/comment on the draft by 20= 1600429; the chairs still need people to review the draft to show there=E2= =80=99s support for it as we process it down the path. >=20 > - Object to the adoption of this draft as a WG item, please respond to = the list indicating why by 201600429. >=20 > Note 1: This draft will get published using the new rules we=E2=80=99ve= been concocting on the list so the IANA considerations section will get = tweaked as we settle on what words need to be included. >=20 > Note 2: The other option is to put the registrations in the TLS1.3 spec= , but that would add four pages that I=E2=80=99m pretty sure no implement= er is going to read so there seems to be little point in included the reg= istrations in the TLS1.3 spec. And, these cipher suites do apply to TLS1= =2E2. >=20 > Cheers, >=20 > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --fUShOL5dBfwsIvj68DGi8aq7joVi8xSBf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXH4dIAAoJEGhJURNOOiAt30QIAJKUfSbMhUi9y+JV+v9PgIYD oazVmFpzmJbTCAyOy8Prs9IHNQ9Mvg0faXIBEdQrk/TMz2oTrcOgj3LFbvsTBnyx v8zjQucHCTM+tOkC1XLYOVywn2ERHUnMfzwEcNu66Wy6HLOUFnt20Emo6v7AW6BK 1pnv2P9oigzVL6N6r9lpmP8301GrMbHkSd8wqOl0ZmUu8SDWlKVlNzq+7cAIgGM9 Z9pNfXuPLMQH/fIlhrMQm261DJ7/Aw59/2T+JS9XroXYaWyupd8D81NlZwiT5U/7 AKZ5R1H2LZP3Gw0RM9s1v5uth9Aesrvsm4/AmugxyV1n+chBegVDGKFsvbTVbXc= =Nf9c -----END PGP SIGNATURE----- --fUShOL5dBfwsIvj68DGi8aq7joVi8xSBf-- From nobody Tue Apr 26 10:46:35 2016 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 D382812D534 for ; Tue, 26 Apr 2016 10:46: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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETeQLvaWEYrV for ; Tue, 26 Apr 2016 10:46:29 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AFB612D552 for ; Tue, 26 Apr 2016 10:46:29 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id t10so26387313ywa.0 for ; Tue, 26 Apr 2016 10:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=JGn3jPWAhvtp1uoQspB0gEKVYen7aHSm7UPfW5usVC4=; b=Jrx6pQ+R6aTRzZcikBIVBHNtA4JqqyVKxZEfWa/+mupzvzsAl/CH7zZN2/sdi+rmPd jOiB84IDLD1BEePFp6h0O49IRcTnoZc22VA6bSfKGWDKTl+c+2bq67gQbKumTdbghNld IRrVYP9MXPfsy38I6RcMdtRMqcTCiMAV605Q1aCUviTiNG3ErSi5Arm9BAkXjqSTNig7 KO8yKxku1nyMgSBOkBq67wYm9cOoxZ5Z8E63bUWv1IguMTWDAGLLjigJd2nWEEDUAQpL DuRn1lB1+j5JsBSRufJjv01ylyhbk9fk1Vwtumurwjr0nZf1hrMJeCdHZEX3CR5GABI0 inmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JGn3jPWAhvtp1uoQspB0gEKVYen7aHSm7UPfW5usVC4=; b=Fxv/IA1wMaY7zuJcLxXLzl4U8SXXE894QnCq0IeOmINheMokuGHt8Hgp9FFM0vMK9a RL/uz/xO4Ypjbkawve+EYgBhIpKQv/1DvlshPogizID3E6uC9KS3NxDTK9kb+2vgoKJU a8WKGFrFuXEDVaDFnaXZAOuSCWqy+EeU8QxV+1KYjxKXdvB4jzJDi9N1TrxsVq8n/1H8 74AAo9HchuTAmo3dAUBz4eapBbeQy7z9XqlT1DJoV6XstJD8cLGuH+JSgNLq42jCVjmD 2X2W2zI0DBn4UCO4EMhgXbTRk0asWslnS6xich9957Q8uEG/qUmw7hb8ZHhOCGIqSjzq YcdQ== X-Gm-Message-State: AOPr4FVJomAl1H2Ztoi7JEid07UfSzNOV2hvdiZLqKDg6Q67VFWTubEHOquWLeMLQnTFDPYZt82UBfwJ8PViVw== X-Received: by 10.37.198.2 with SMTP id k2mr2132645ybf.82.1461692788371; Tue, 26 Apr 2016 10:46:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Tue, 26 Apr 2016 10:45:49 -0700 (PDT) From: Eric Rescorla Date: Tue, 26 Apr 2016 10:45:49 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c08c9506c28d6053166df2e Archived-At: Subject: [TLS] Review of draft-guballa-tls-terminology-03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 17:46:34 -0000 --94eb2c08c9506c28d6053166df2e Content-Type: text/plain; charset=UTF-8 I recently reviewed draft-guballa-tls-terminology-03. Comments below. OVERALL I'm sympathetic to concerns that TLS terminology may not be as precise as one would like, but IMO this document doesn't make things significantly clearer and in some cases makes it worse. Specifically: - (D)TLS is intentionally defined without any tight binding to the underlying transport. However, this document tries to tie it to IP semantics, which is not helpful and doesn't match existing practice. - This document introduces a number of terms that don't exist in the (D)TLS documents (e.g., "Transient (D)TLS session"). This is just going to cause confusion. In general, I don't think that having a second document that acts as a glossary for (D)TLS but isn't part of the main documents is going to help much. If the authors feel like the terminology in TLS is imprecise, it would be more helpful to suggest changes to TLS 1.3 (e.g., via PRs). DETAILED COMENTS S 3.1.1. There's no restriction on TLS that a given endpoint is attached to one IP address, and in fact, it's common to run DTLS in multihomed configs (e.g., DTLS over ICE). S 3.2.1. Again, (D)TLS isn't bound to the port or IP. S 3.2.2. This whole notion of semi-permanent versus transient isn't helpful, especially in the face of tickets. S 3.2.2. This is just a new invented term. Please don't S 3.3.1. Destruction point doesn't seem useful since in many cases it's "unknown" since it's in the future S 3.3.4. In DTLS you can respond to a ClientHello with a HelloVerifyRequest as well. S 3.4.4. "message sequence" seems invented. S 3.4.7. I don't think it's helpful to import ITU notions of connection state here, especially in the face of stuff like false start. S 3.4.12. Copying the session state here doesn't seem that useful, especially splitting it into two states. --94eb2c08c9506c28d6053166df2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I recently reviewed draft-guballa-tls-terminology-03.= Comments below.

OVERALL
I'm sympath= etic to concerns that TLS terminology may not be as precise
as on= e would like, but IMO this document doesn't make things significantly
clearer and in some cases makes it worse. Specifically:
=
- (D)TLS is intentionally defined without any tight binding = to the underlying
=C2=A0 transport. However, this document tries = to tie it to IP semantics, which
=C2=A0 is not helpful and doesn&= #39;t match existing practice.

- This document int= roduces a number of terms that don't exist in the (D)TLS
=C2= =A0 documents (e.g., "Transient (D)TLS session"). This is just go= ing to cause
=C2=A0 confusion.

In genera= l, I don't think that having a second document that acts as
a= glossary for (D)TLS but isn't part of the main documents is going to h= elp
much. If the authors feel like the terminology in TLS is impr= ecise, it
would be more helpful to suggest changes to TLS 1.3 (e.= g., via PRs).


DETAILED COMENTS
S 3.1.1.
There's no restriction on TLS that a given end= point is attached
to one IP address, and in fact, it's common= to run DTLS in
multihomed configs (e.g., DTLS over ICE).

S 3.2.1.
Again, (D)TLS isn't bound to the p= ort or IP.

S 3.2.2.
This whole notion of= semi-permanent versus transient isn't helpful,
especially in= the face of tickets.

S 3.2.2.
This is j= ust a new invented term. Please don't

S 3.3.1.=
Destruction point doesn't seem useful since in many cases it= 's "unknown"
since it's in the future

S 3.3.4.
In DTLS you can respond to a ClientHello= with a HelloVerifyRequest as
well.

S 3.= 4.4.
"message sequence" seems invented.

<= /div>
S 3.4.7.
I don't think it's helpful to import I= TU notions of connection state here,
especially in the face of st= uff like false start.

S 3.4.12.
Copying = the session state here doesn't seem that useful, especially splitting
it into two states.





=C2=A0=C2=A0

--94eb2c08c9506c28d6053166df2e-- From nobody Tue Apr 26 12:13:05 2016 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 7EC0012D56C for ; Tue, 26 Apr 2016 12:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27lGW4faBBUs for ; Tue, 26 Apr 2016 12:13:03 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4427712D1D1 for ; Tue, 26 Apr 2016 12:13:03 -0700 (PDT) Received: by mail-qg0-x233.google.com with SMTP id c6so10017466qga.1 for ; Tue, 26 Apr 2016 12:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=2viXXHbd8JBA1aI8PD7lZYsn4tT/rJfhwAiDtHdsk6U=; b=gQFYUQlOdBDvwOpVn/x0o30LHWob5zR+sznBZz8fN6rRqkzMyEt29F6c4CBUADMdB8 y8v/0ZFY7tLR95Wl0J9Is3HvB6yC8XQn5BAltRlX5IntzhcYYdUnOIYukbjOS28C6ZHX YwNm2E1z/MH9b+ilm0p+VF1cZbJ6KD7R40k39kRyy2ax45i7Sqxb6M8mnkVvvbxY0mhZ xOmRgAPfTND9ij5U27hZfTrfQM//ltxI35RWX1rZFVi19Ozsui6Gbt2RO8A6mFw/lcAs 1CsSqyO9UKuwTxj9NZZS0lbMC/suS0Z0auMiAtbCPUE/MN/d9/lEZi/M+hgjDo+JWncs A9IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=2viXXHbd8JBA1aI8PD7lZYsn4tT/rJfhwAiDtHdsk6U=; b=X7JVv2Me/dAgeK6JC6qiXNOk1xvYauDAlNU7/+sKmd/Ya5+6G83j8O7bQsveghCQRI zn1PCIi4KcEddR8QoOh0Q7yr4ulHlv7rIkVr7WmuEwuX3tSOcJmEDEWpFYlHLnPThXtj yuGZL7NaAfqoSjMWtZzFGLc379nz5ELk5iKJp1rZGHZ0X8K5V9g4jGbUcV6YUPCpSEpq NuxKY158sQMWuz+VnR2MFqhHU2OMjoy8AHxrKrJMyoF38ztyYofdSIK59wJC/057uLvX B10UvZluxkusXhEiKdgblnGVKR/AT6QCwHlfw3OsmYLsWyawyg6LQ55JJ4xXtoCM+thb tXtA== X-Gm-Message-State: AOPr4FWsScMJIcg2JxL3TPuqlDekdcL4R95tXfrldRcU9CE+n+M2Qf3UVLm6hNcxTvsjfg== X-Received: by 10.140.82.69 with SMTP id g63mr4016851qgd.106.1461697982213; Tue, 26 Apr 2016 12:13:02 -0700 (PDT) Received: from dave-laptop.localnet (pool-72-94-36-244.phlapa.fios.verizon.net. [72.94.36.244]) by smtp.gmail.com with ESMTPSA id y200sm9250962qka.48.2016.04.26.12.13.01 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 26 Apr 2016 12:13:01 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Tue, 26 Apr 2016 15:13:00 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <571F8748.1000202@gmx.net> In-Reply-To: <571F8748.1000202@gmx.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201604261513.00630.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Call for WG adoption of draft-mattsson-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 19:13:04 -0000 On Tuesday, April 26, 2016 11:20:40 am Hannes Tschofenig wrote: > If you are already paying the price of the asymmetric crypto (in terms > of flash usage/CPU speed/RAM utilization then just switch to a raw > public key or a certificate based ciphersuite (since there is very > little additional overhead). > > I suspect the usage is more for the we or so? (assuming that was supposed to be "web") With resumption now done through PSK in TLS 1.3, these suites will be desired for that in addition to systems that will be using PSK as their primary suite. Without them, the only FS AEAD PSK AES suites are DHE, and we'd much prefer ECDHE be available. Dave From nobody Tue Apr 26 17:41:55 2016 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 D135512D590 for ; Tue, 26 Apr 2016 17:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sl1UWKJdnCSO for ; Tue, 26 Apr 2016 17:41:53 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id 9E0D312B016 for ; Tue, 26 Apr 2016 17:41:53 -0700 (PDT) Received: (qmail 17200 invoked by uid 0); 27 Apr 2016 00:41:52 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy1.mail.unifiedlayer.com with SMTP; 27 Apr 2016 00:41:52 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id nChn1s00m2UhLwi01ChqG8; Tue, 26 Apr 2016 18:41:50 -0600 X-Authority-Analysis: v=2.1 cv=Nal1iQz4 c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=kziv93cY1bsA:10 a=tGX7uwomAAAA:8 a=icCb6OXmypcf6Lz6QzYA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:To:From:Subject:Date:Message-ID; bh=YmrsIC9lyycpzQljGwd6YggLqfrdIZ2Yzf5kyNCeIGA=; b=EcAe0wcQ6wNXIpst16GRRx/rAG eKKrI7jLoHIRth4pu9fPMukZ+NjSNSST4cwm+KCkBKZiFd6zbioKc3m3ksiHOddWF6WNS4ONrGJ3m SXWvylrlLB986sLc6BfKjKCby; Received: from [127.0.0.1] (port=51938 helo=box514.bluehost.com) by box514.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1avDY5-0001u1-MZ for tls@ietf.org; Tue, 26 Apr 2016 18:41:49 -0600 Received: from 73.202.80.238 ([73.202.80.238]) (SquirrelMail authenticated user jeff.hodges@kingsmountain.com) by box514.bluehost.com with HTTP; Tue, 26 Apr 2016 18:41:49 -0600 Message-ID: <7b8a3feb9790cd255e1106f2ea749f58.squirrel@box514.bluehost.com> Date: Tue, 26 Apr 2016 18:41:49 -0600 From: jeff.hodges@kingsmountain.com To: tls@ietf.org User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Identified-User: {:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:program running on server} Archived-At: Subject: Re: [TLS] Call for WG adoption of draft-shore-tls-dnssec-chain-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 00:41:55 -0000 On 4/25/16, 8:27 AM, "Russ Housley" wrote: > >On Apr 25, 2016, at 11:19 AM, Paul Wouters wrote: > >> On Mon, 25 Apr 2016, Sean Turner wrote: >> >>> draft-shore-tls-dnssec-chain-extension was originally discussed at >>>IETF 93 [0], and the authors have been biding their time while the WG >>>thrashed out TLS1.3s' issues. At IETF 95, they presented again [1], >>>but this time the chairs took a sense of the room about whether the WG >>>was in favor of adopting the draft. According to the minutes, there >>>were ³crickets² against and ³lots of noise² for adoption. But, we need >>>to take it to the list so please indicate whether you: >>> >>> - Support adoption and are willing to review/comment on the draft by >>>201600429. Note that the extensions is pretty straight forward, but >>>the chairs still need people to comment on the draft as we¹re >>>processing it down the path. >> >> I support and will review the document. I think it is a great idea that >> will help deploying DNSSEC and TLSA for browsers. > >+1 +1 =JeffH From nobody Wed Apr 27 08:48:34 2016 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 85A9E12D0AE for ; Wed, 27 Apr 2016 08:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceD6J_OMJ3-A for ; Wed, 27 Apr 2016 08:48:31 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 857CA12B047 for ; Wed, 27 Apr 2016 08:48:31 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 8D561EC385F54; Wed, 27 Apr 2016 15:48:26 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u3RFmSrk026326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Apr 2016 15:48:28 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u3RFmSpK017944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Apr 2016 17:48:28 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.187]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 27 Apr 2016 17:48:27 +0200 From: "Schwarz, Albrecht (Nokia - DE)" To: EXT Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] Review of draft-guballa-tls-terminology-03 Thread-Index: AQHRn+OaVk0dK2ZXAE+4bi4kHxNxuJ+dsk9w Date: Wed, 27 Apr 2016 15:48:27 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1ACE1A46C9C@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Review of draft-guballa-tls-terminology-03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 15:48:33 -0000 SGVsbG8gRXJpYywNCg0KdGhhbmtzIGZvciBzdGFydGluZyB0aGUgZGlzY3Vzc2lvbiBpbiBnZXR0 aW5nIHRoZSBUTFMgYW5kIERUTFMgdGVybXMgY2xhcmlmaWVkIGFuZCBmaXhlZCENCkp1c3QgYSBx dWljayByZXBseSB0b2RheSBvbiB0aGUgb3ZlcmFsbCBhcHByb2FjaCBiZWZvcmUgY29tbWVudGlu ZyAob3IgbXkgY29sbGVhZ3Vlcykgb24gdGhlIGluZGl2aWR1YWwgdGVybXMuDQoNCjFzdCBUaGVy ZSBhcmUgdHdvIGdyb3VwcyB3b3JraW5nIG9uIChEKVRMUyBzcGVjaWZpY2F0aW9uczogdGhlIGlu bmVyIGNpcmNsZSBvZiBUTFMgZXhwZXJ0cyB3aGljaCBtaWdodCBzaGFyZSBhIGNvbW1vbiB1bmRl cnN0YW5kaW5nIGFib3V0IHRoZSBwcm90b2NvbCBzZW1hbnRpY3MgYmVoaW5kIGEgdGVybSAodGhp cyBncm91cCBtaWdodCBiZSBXRyBUTFMgYW5kIHBlcmhhcHMgYWxzbyBVVEEpOyAtIGFuZCB0aGVy ZSBpcyBvdXRlciBjaXJjbGUgcmVmZXJpbmcgdG8gKEQpVExTIGluIHNpZ25hbGxpbmcgcGxhbmUs IG1hbmFnZW1lbnQgcGxhbmUsIGNvbnRyb2wgcGxhbmUsIGFwcGxpY2F0aW9uIGFuZCBzZXJ2aWNl IHNwZWNpZmljYXRpb25zIGV0YyAoc3VjaCBhcyBXR3MgTU1VU0lDLCBSVENXRUIsIFBFUkMsIGV0 YyBldGMgYW5kIFNET3MgbGlrZSBJVFUtVCwgM0dQUCwgT01BLCBldGMgZXRjKS4NCkknbSBiZWxv bmdpbmcgdG8gdGhlIHNlY29uZCBncm91cCwgbGFja2luZyB0aGF0IGluc2lkZXIga25vd2xlZGdl IHRvIHRoZSBUTFMgZXhwZXJ0cyBjb21tdW5pdHkuDQoNCjJuZCBEZWZpbml0aW9uIEEgdnMgQiBm b3IgVGVybSBYDQpXaGVuIHVzaW5nIHN0YXRlbWVudHMgIm1ha2UgdGhpbmdzIGNsZWFyZXIgLyB3 b3JzZXIgdGhhbiAuLi4iIHRoZW4gd2UgbmVlZCB0byBsb29rIGF0IHRoZSBjb21wYXJpc29uIG9m IEEgYW5kIEIuDQpOb3csICJBIiBpcyAob2Z0ZW4pIG5vdCBhdmFpbGFibGUgKG9yIHNvbWVob3cg aGlkZGVuIGluIHRoZSBleGlzdGluZyAoRClUTFMgUkZDcywgb3Igb25seSBkZXNjcmliZWQgYXQg aGlnaCBsZXZlbCkgd2hlbiAiQiIgcmVsYXRlcyB0byB0aGUgdGVybWlub2xvZ3kgZHJhZnQuDQoN CkZ1cnRoZXJtb3JlLCByZWxhdGVkIHRoZSBjb25zaWRlcmVkIHNldCBvZiB0ZXJtczoNCldlIG5l ZWQgZmlyc3RseSBmaXhlIHRoZSB0ZXJtcyBmb3IgdGhlIFRMUyBhbmQgRFRMUyAiYmFzaWMgcHJv dG9jb2wgc2V0IiAoc2VlIHRoZSBsaXN0IG9mIHJlZmVycmVuY2VkIFJGQ3MgaW4gdGhlIGRyYWZ0 KS4gVGhlIHVzYWdlIG9mIHRoZW0gaW4gY29udGV4dCBvZiBJQ0UgKGFuZCB0aGUgaW50ZXJlc3N0 aW5nIHF1ZXN0aW9uIG9mIElDRSByZXN0YXJ0cyksIFdlYlJUQywgdHVubmVsIHRlY2huaXF1ZXMs IGV0YyBzaG91bGQgYmUgY29uc2lkZXJlZCBpbiBhIHN1YnNlcXVlbnQgc3RlcC4gRWl0aGVyIGFu IG9yaWdpbmFsIHRlcm0gcmVtYWlucyB1bmNoYW5nZWQgb3Igd291bGQgbmVlZCB0byBiZSBmdXJ0 aGVyIHF1YWxpZmllZC4NCkJ1dCBhIGNvbnNpZGVyYXRpb24gb2YgIm9wZW4sIGZvcndhcmQgY29t cGF0aWJsaXR5IiB0ZXJtIHNlbWFudGljcyB3aWxsIGxlYWQgaW4gdGhlIGVuZCB0byBhIHZlcnkg dmFndWUgZGVmaW5pdGlvbiBpbiBteSB1bmRlcnN0YW5kaW5nLg0KQW5kIGl0IHNob3VsZCBiZSBm ZWFzaWJsZSB0byBmaXggdGhlc2UgdGVybXMgYmVjYXVzZSB3ZSBnb3QgY29uY3JldGUgaW5mb3Jt YXRpb24gYW5kIGRhdGEgbW9kZWxzIGJlaGluZCB0aGUgKEQpVExTIHByb3RvY29sIGVudGl0aWVz LiBJdCdzIG1lcmVseSBhIHF1ZXN0aW9uIGFib3V0IHRoZSBjb25jcmV0ZSBzZXQgb2YgaW5mb3Jt YXRpb24gYmVoaW5kIGEgcGFydGljdWxhciB0ZXJtLg0KDQpXaXRoIHJlZ2FyZHMgdG8gaGllcmFy Y2h5Og0KVGhlIGNvbmNlcHQgb2YgKEQpVExTIGluIHNlcGFyYXRpbmcgInNlc3Npb24iIGFuZCAi Y29ubmVjdGlvbnxhc3NvY2lhdGlvbiIgbGV2ZWwsIGFzIHdlbGwgYXMgcHJvdG9jb2wgcHJvY2Vk dXJlcyBhdCB0aGUgdmVyeSBiZWdpbm5pbmcgYW5kIGR1cmluZyB0aGUgY29tbXVuaWNhdGlvbiBw aGFzZSByZXByZXNlbnQgYWN0dWFsbHkgYW4gaGllcmFyY2hpY2FsIG1vZGVsIGluc2lkZSB0aGUg cHJvdG9jb2wuDQpUaHVzLCB0aGUgdGVybWlub2xvZ3kgZHJhZnQgZm9sbG93cyB0aGF0IGhpZXJh cmNoaWNhbCBhcHByb2FjaCAod2hpY2ggYWdhaW4gc2hvdWxkIGxlYWRzIHRvIGNvbmNpc2UgaW5k aXZpZHVhbCB0ZXJtIGRlZmluaXRpb25zKS4NCg0KUmVnYXJkcywgQWxicmVjaHQNCg0KDQoNCkZy b206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRVhUIEVy aWMgUmVzY29ybGENClNlbnQ6IERpZW5zdGFnLCAyNi4gQXByaWwgMjAxNiAxOTo0Ng0KVG86IHRs c0BpZXRmLm9yZw0KU3ViamVjdDogW1RMU10gUmV2aWV3IG9mIGRyYWZ0LWd1YmFsbGEtdGxzLXRl cm1pbm9sb2d5LTAzDQoNCkkgcmVjZW50bHkgcmV2aWV3ZWQgZHJhZnQtZ3ViYWxsYS10bHMtdGVy bWlub2xvZ3ktMDMuIENvbW1lbnRzIGJlbG93Lg0KDQpPVkVSQUxMDQpJJ20gc3ltcGF0aGV0aWMg dG8gY29uY2VybnMgdGhhdCBUTFMgdGVybWlub2xvZ3kgbWF5IG5vdCBiZSBhcyBwcmVjaXNlDQph cyBvbmUgd291bGQgbGlrZSwgYnV0IElNTyB0aGlzIGRvY3VtZW50IGRvZXNuJ3QgbWFrZSB0aGlu Z3Mgc2lnbmlmaWNhbnRseQ0KY2xlYXJlciBhbmQgaW4gc29tZSBjYXNlcyBtYWtlcyBpdCB3b3Jz ZS4gU3BlY2lmaWNhbGx5Og0KDQotIChEKVRMUyBpcyBpbnRlbnRpb25hbGx5IGRlZmluZWQgd2l0 aG91dCBhbnkgdGlnaHQgYmluZGluZyB0byB0aGUgdW5kZXJseWluZw0KwqAgdHJhbnNwb3J0LiBI b3dldmVyLCB0aGlzIGRvY3VtZW50IHRyaWVzIHRvIHRpZSBpdCB0byBJUCBzZW1hbnRpY3MsIHdo aWNoDQrCoCBpcyBub3QgaGVscGZ1bCBhbmQgZG9lc24ndCBtYXRjaCBleGlzdGluZyBwcmFjdGlj ZS4NCg0KLSBUaGlzIGRvY3VtZW50IGludHJvZHVjZXMgYSBudW1iZXIgb2YgdGVybXMgdGhhdCBk b24ndCBleGlzdCBpbiB0aGUgKEQpVExTDQrCoCBkb2N1bWVudHMgKGUuZy4sICJUcmFuc2llbnQg KEQpVExTIHNlc3Npb24iKS4gVGhpcyBpcyBqdXN0IGdvaW5nIHRvIGNhdXNlDQrCoCBjb25mdXNp b24uDQoNCkluIGdlbmVyYWwsIEkgZG9uJ3QgdGhpbmsgdGhhdCBoYXZpbmcgYSBzZWNvbmQgZG9j dW1lbnQgdGhhdCBhY3RzIGFzDQphIGdsb3NzYXJ5IGZvciAoRClUTFMgYnV0IGlzbid0IHBhcnQg b2YgdGhlIG1haW4gZG9jdW1lbnRzIGlzIGdvaW5nIHRvIGhlbHANCm11Y2guIElmIHRoZSBhdXRo b3JzIGZlZWwgbGlrZSB0aGUgdGVybWlub2xvZ3kgaW4gVExTIGlzIGltcHJlY2lzZSwgaXQNCndv dWxkIGJlIG1vcmUgaGVscGZ1bCB0byBzdWdnZXN0IGNoYW5nZXMgdG8gVExTIDEuMyAoZS5nLiwg dmlhIFBScykuDQoNCg0KREVUQUlMRUQgQ09NRU5UUw0KUyAzLjEuMS4NClRoZXJlJ3Mgbm8gcmVz dHJpY3Rpb24gb24gVExTIHRoYXQgYSBnaXZlbiBlbmRwb2ludCBpcyBhdHRhY2hlZA0KdG8gb25l IElQIGFkZHJlc3MsIGFuZCBpbiBmYWN0LCBpdCdzIGNvbW1vbiB0byBydW4gRFRMUyBpbg0KbXVs dGlob21lZCBjb25maWdzIChlLmcuLCBEVExTIG92ZXIgSUNFKS4NCg0KUyAzLjIuMS4NCkFnYWlu LCAoRClUTFMgaXNuJ3QgYm91bmQgdG8gdGhlIHBvcnQgb3IgSVAuDQoNClMgMy4yLjIuDQpUaGlz IHdob2xlIG5vdGlvbiBvZiBzZW1pLXBlcm1hbmVudCB2ZXJzdXMgdHJhbnNpZW50IGlzbid0IGhl bHBmdWwsDQplc3BlY2lhbGx5IGluIHRoZSBmYWNlIG9mIHRpY2tldHMuDQoNClMgMy4yLjIuDQpU aGlzIGlzIGp1c3QgYSBuZXcgaW52ZW50ZWQgdGVybS4gUGxlYXNlIGRvbid0DQoNClMgMy4zLjEu DQpEZXN0cnVjdGlvbiBwb2ludCBkb2Vzbid0IHNlZW0gdXNlZnVsIHNpbmNlIGluIG1hbnkgY2Fz ZXMgaXQncyAidW5rbm93biINCnNpbmNlIGl0J3MgaW4gdGhlIGZ1dHVyZQ0KDQpTIDMuMy40Lg0K SW4gRFRMUyB5b3UgY2FuIHJlc3BvbmQgdG8gYSBDbGllbnRIZWxsbyB3aXRoIGEgSGVsbG9WZXJp ZnlSZXF1ZXN0IGFzDQp3ZWxsLg0KDQpTIDMuNC40Lg0KIm1lc3NhZ2Ugc2VxdWVuY2UiIHNlZW1z IGludmVudGVkLg0KDQpTIDMuNC43Lg0KSSBkb24ndCB0aGluayBpdCdzIGhlbHBmdWwgdG8gaW1w b3J0IElUVSBub3Rpb25zIG9mIGNvbm5lY3Rpb24gc3RhdGUgaGVyZSwNCmVzcGVjaWFsbHkgaW4g dGhlIGZhY2Ugb2Ygc3R1ZmYgbGlrZSBmYWxzZSBzdGFydC4NCg0KUyAzLjQuMTIuDQpDb3B5aW5n IHRoZSBzZXNzaW9uIHN0YXRlIGhlcmUgZG9lc24ndCBzZWVtIHRoYXQgdXNlZnVsLCBlc3BlY2lh bGx5IHNwbGl0dGluZw0KaXQgaW50byB0d28gc3RhdGVzLg0KDQoNCg0KDQoNCsKgwqANCg0K From nobody Wed Apr 27 08:51:09 2016 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 E140112D89B for ; Wed, 27 Apr 2016 08:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.697 X-Spam-Level: X-Spam-Status: No, score=-3.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09rf4wKq0yMz for ; Wed, 27 Apr 2016 08:51:08 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 1C47212D505 for ; Wed, 27 Apr 2016 08:51:08 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8E948496C19; Wed, 27 Apr 2016 15:51:07 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 7864D16C50E; Wed, 27 Apr 2016 15:51:07 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1461772267; bh=BeKlklGd1uI38KjF/MSW19ZSrA3BGu5nqqnrE5RrIJg=; l=162; h=From:To:Date:References:In-Reply-To:From; b=zOdOGoeZXV+rsckVOm44N2eDIjeqEr8tf0hd9fq3r17zN9ar1UbG9gDXbXH9xh/Lb sMiYmaAOJ/qh3w0cRXv6LLsQNHhwAFzuvyLyzXHMWD+AP17RMxe+lJ99c/dzLTlxrh RIcYEgS7fy1xKQ3HlSCpCq9YSbrYQw+OyZbc9o50= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 5E8971E07C; Wed, 27 Apr 2016 15:51:07 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 27 Apr 2016 11:51:06 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Wed, 27 Apr 2016 11:51:06 -0400 From: "Salz, Rich" To: "Schwarz, Albrecht (Nokia - DE)" , "EXT Eric Rescorla" , "tls@ietf.org" Thread-Topic: [TLS] Review of draft-guballa-tls-terminology-03 Thread-Index: AQHRn+OUm0ARF34CDkaHuYz5QQEKep+eO8GA//+9exA= Date: Wed, 27 Apr 2016 15:51:05 +0000 Message-ID: References: <786615F3A85DF44AA2A76164A71FE1ACE1A46C9C@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1ACE1A46C9C@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.89] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Review of draft-guballa-tls-terminology-03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 15:51:09 -0000 SSBzaGFyZSBla3IncyBjb25jZXJuIGFib3V0IGEgc2VwYXJhdGUgZG9jdW1lbnQgZGVmaW5pbmcg dGVybXMgdGhhdCBhcmUgbmVlZGVkIHRvIHVuZGVyc3RhbmQgdGhlIG9mZmljaWFsIHNwZWMuDQoN Cg== From nobody Wed Apr 27 11:09:26 2016 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 DCA8712DB8A for ; Wed, 27 Apr 2016 11:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zpxj11GF-fVs for ; Wed, 27 Apr 2016 11:09:17 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6BA12DB4A for ; Wed, 27 Apr 2016 11:09:17 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id u64so59000960lff.3 for ; Wed, 27 Apr 2016 11:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=BT9kucZhsv6kTdL/6rgwmu81uCm8Ra3QV18Fc+txPdQ=; b=LoqmKbRIpzrFI+a5BOVQNGSPv8fVQneUB3n7jdymdAUkBjPSqCF+vquZVHkQnavnod YHVgu4HariGjFYxhBfZ18HkvRVxaWWCQnWcNz0rAEkGU6CWgrrdqVfLRHXdtiQpw9qjU AgoIFHoj/rn9PrEcJk2OEj8QrzTwb1IEC9HgK7mGtH49ATBUO1bcD4VLs0WJuqvhFMeq /2cYiDUOO0N73qOtNBGx73vPePbpsJanc5gyEc7Ol36tgPiRlkekYs6buYjS7JfyNaqB g2Sx04G4Ldk+CUmHQO8EJmswbBp3yneJOiylPA2hwGFfInMyoBzueClXgTdjAJzU/unP g5KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=BT9kucZhsv6kTdL/6rgwmu81uCm8Ra3QV18Fc+txPdQ=; b=aNxGa2mqnTe/vy6D2XaBXr0gC7Vlq3JhnHo9N2LFzmucKn1o5wMe2nx9bYJzdDya/Q Li5ET2e4USgwv2lwwBocUJQ0K+rujUt+O+nY7DPINvoEKI91k/9h1hRkdm0M2DbqjzBv sxIDoBcpu2ygNW92sg28JqmjWYp0V+rDxGsloZjoMsWF7e9H5kj89orXDSUNWgx6RPkJ vdbqZ0UhixX3jeXqyLj4MHOizBDKj9J/8wYMSDGZKGoHIc/GYKvF/LVle5TgQyC7lnOe c6ru8YwwPmDtEP5PPqkobMuaTUbMm+uNKd3whyK23CNX4WjCSu9bvc6x6Hiz9PDLLP6e ETEw== X-Gm-Message-State: AOPr4FXF21Toas5mHSZtDToQ7bu1Df4UVUa3TI47wUvf2dZjqmHy0NLamaVu7UgcfNNBVoE6arXwpBECSffUIQ== X-Received: by 10.112.132.104 with SMTP id ot8mr4177606lbb.34.1461780555586; Wed, 27 Apr 2016 11:09:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.189.74 with HTTP; Wed, 27 Apr 2016 11:08:56 -0700 (PDT) From: Joseph Salowey Date: Wed, 27 Apr 2016 11:08:56 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7b3a7ffec17ea905317b4ecb Archived-At: Subject: [TLS] Draft minutes from IETF 95 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 18:09:22 -0000 --047d7b3a7ffec17ea905317b4ecb Content-Type: text/plain; charset=UTF-8 Thanks to Jim Schaad for taking minutes during our two sessions. A draft is available on the IETF website at: https://www.ietf.org/proceedings/95/minutes/minutes-95-tls Corrections welcome. Thanks, Joe --047d7b3a7ffec17ea905317b4ecb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks to Jim Schaad for taking minutes during our two ses= sions.=C2=A0 A draft is available on the IETF website at:

ht= tps://www.ietf.org/proceedings/95/minutes/minutes-95-tls
=
Corrections welcome. =C2=A0

Thanks,=

Joe


--047d7b3a7ffec17ea905317b4ecb-- From nobody Wed Apr 27 11:13:34 2016 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 082D612D55E for ; Wed, 27 Apr 2016 11:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DS7p-_1A7sb9 for ; Wed, 27 Apr 2016 11:13:31 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E14612DB70 for ; Wed, 27 Apr 2016 11:13:31 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id n1so25785888pfn.2 for ; Wed, 27 Apr 2016 11:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=qepOQCdLEiXsU3CrNitSGtrrD7g0FvBw82f8ALzR+Ug=; b=KMTumX4Vsbs0oJG5OItbkoiEVG3KIf67ZjGS6mwOwlHz3f5usYb0bHka7v+4LK6XNK DcFV6PNXzOttRaFSATXI+CXKyX/yJ66Tajtubf/SRYzxID0Q+F14frk9r2qLPnerInKe YLqYFpqZ+PIEqm4Ax2jl07QW3RU1wgeFjxHlxw6wdcoz6WzI6T9kaoef4XFUjN77cTK5 H1MSr9RpHS8BqdL8My9+KzKoQfXS4fdMR/g5sNAKLMCvOwwGw1Gf0jMS8MEVOJMMCVbJ kdhm1OYa6niaK7GmB8FIIrnEM2gLtP/5FuCcqzLs0CEeoh7EL1OZH+MEf++G2UfuicxS Mmlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=qepOQCdLEiXsU3CrNitSGtrrD7g0FvBw82f8ALzR+Ug=; b=QtPMHH49+LkTPAJlxGOBGVAFAeIBotaDlo4F9Xx1xAZ54rVrsxvyKhRHsfqFGvCzoV LrloJ8pi0x97ejcYCVoY6WSITg/b1w0xufImB3HgySXdw/dQ8TblalXhRHJgPXY6dhuU 8/22SyLRJ64ATSq5hAa9riGiJYSwhy8VkFOg/05gTx4r9EWS2pCjogPWUBRx5trC+s/N LTqRpoSPL3MV9loCeQ613dmNknOAdOTMXYx6dr9TmZKr9d9b7ywA0m8QC5hPE4JSb7PF bDqMaX6KPeDd2Yfbae1rJhjb0E3jR31zgxaGprYqPonC+LAPsz+G9VgFpkdS1L54E8WU GcJw== X-Gm-Message-State: AOPr4FWqAj+ITpa7h7LOX+Fayo9/L6gL2Q0la28WNkaP1/tNWX3Ej0BbHyiV3YBclnq9QA== X-Received: by 10.98.42.207 with SMTP id q198mr14118779pfq.103.1461780811153; Wed, 27 Apr 2016 11:13:31 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (216-67-4-29-radius.dynamic.acsalaska.net. [216.67.4.29]) by smtp.gmail.com with ESMTPSA id w125sm8290891pfb.16.2016.04.27.11.13.30 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2016 11:13:30 -0700 (PDT) To: tls@ietf.org References: <786615F3A85DF44AA2A76164A71FE1ACE1A46C9C@FR711WXCHMBA03.zeu.alcatel-lucent.com> From: Melinda Shore Message-ID: <5721015C.1060602@nomountain.net> Date: Wed, 27 Apr 2016 10:13:48 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <786615F3A85DF44AA2A76164A71FE1ACE1A46C9C@FR711WXCHMBA03.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Review of draft-guballa-tls-terminology-03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 18:13:34 -0000 I share the more broadly-stated concern that this draft introduces terminology and architectural framings that don't match how things work either in practice or in existing documents. I understand that the authors are looking for a tool to get a better handle on the protocol, but if there's a need for a clearer terminology section in a core specification it might best be written by someone who does have "insider"-level knowledge of the protocol and how it's implemented, etc. (I don't think that need exists, for the little that's worth). Melinda From nobody Thu Apr 28 12:12:03 2016 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 2F88812D8B3 for ; Thu, 28 Apr 2016 12:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKsOsRFdY7Zl for ; Thu, 28 Apr 2016 12:11:59 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4313412D883 for ; Thu, 28 Apr 2016 12:11:59 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id g133so122132548ywb.2 for ; Thu, 28 Apr 2016 12:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=856V1sK74UaHe78Y8MBdthW4PULCw6cFZmRCAKJDFXo=; b=Ruq/dkBfKqFIHXII4cjbYeiV2gxB4UHhc7UkKt/uoyREcuY6wMn7REMwFadv0W9Zra HVRAPe9QcH4+lM/k6ZYsMW/Vr1DPyhxTBwL+pq98ww5wtOsjp6EV+TqvdurGA9zYdGGY xBOMOTmNftkiNjXZ6hUFsTfOQbFQRcAJeGfZCuvybhx7f6gX2NrRAUA3BgWf/V6go8Qj +Yp2TxDj185NHFm6EjH774WsrACqf1pqPUkqNgZXiWlW5qqKz+kvWrjtYLQB6CYgoTJW pHQylGM3EuNTmav4KkNPPjEmNStA7FYeP1zAWHLfMrQeEMeVFQmVzKeTLfdreb2YmZa3 ngYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=856V1sK74UaHe78Y8MBdthW4PULCw6cFZmRCAKJDFXo=; b=c2WgP5bt70US44WsfxC/YFV0+u/H1v+c7UJcXclnjm+f34j4tKjDZAjxR7PSijIxRl mHYV2C6M9aFwlLi/MXiihmp3IOzeFBuEwMXHopTFHSgWQGVb7yWocvAxinykkT/r4jit FADUpfwzWErBzUtPNQKPmaBIp+beoj67wTo4z8ToMvYQA7F/8FIwguMMA4M1NOZ7bwVk m0xZ0b2jighq826L20vCCgSekzAO4WsIIgFlQojJw0UKR07+Lo1YZ3tOy1N8RKKXiPwK F5iRhJScO3eTTK+kyIYxOvnpfXGJHPCLXVjsYz7S/q82McAnAAJOnhFaCD/jKGF9du0R 2T1w== X-Gm-Message-State: AOPr4FW3K2JYCKMYarObaScm90go/EJvl9JICeQD7yioma2xtQgfJfyuCGpZIvupNUhF/MuQA1FU5pxcIcxdqA== X-Received: by 10.129.163.146 with SMTP id a140mr2232771ywh.254.1461870718429; Thu, 28 Apr 2016 12:11:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Thu, 28 Apr 2016 12:11:19 -0700 (PDT) From: Eric Rescorla Date: Thu, 28 Apr 2016 12:11:19 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1287eee162450531904ccf Archived-At: Subject: [TLS] PR #446: Allow server to send SupportedGroups X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2016 19:12:02 -0000 --94eb2c1287eee162450531904ccf Content-Type: text/plain; charset=UTF-8 https://github.com/tlswg/tls13-spec/pull/446 Per discussion in Buenos Aires, this PR allows the server to send SupportedGroups. Target merge date: Monday 5/2. --94eb2c1287eee162450531904ccf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
h= ttps://github.com/tlswg/tls13-spec/pull/446

Per disc= ussion in Buenos Aires, this PR allows the server to send SupportedGroups.<= /div>

Target merge date: Monday 5/2.

--94eb2c1287eee162450531904ccf-- From nobody Thu Apr 28 12:33:01 2016 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 4736412D8F7 for ; Thu, 28 Apr 2016 12:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6p5IIVIbucB for ; Thu, 28 Apr 2016 12:32:58 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id D995712B004 for ; Thu, 28 Apr 2016 12:32:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 94B5A482A for ; Thu, 28 Apr 2016 22:32:56 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 8IEV_WdHbAIG for ; Thu, 28 Apr 2016 22:32:56 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 4A6712310 for ; Thu, 28 Apr 2016 22:32:56 +0300 (EEST) Date: Thu, 28 Apr 2016 22:32:52 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20160428193252.GA16096@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Subject: [TLS] #445: Enhanced New Session Ticket X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2016 19:33:00 -0000 Some comments: - I presume 0-RTT used in retried ClientHello uses (and for the verify mechanism to work, that needs to be allowed!) uses ClientHello1... ClientHello2 as its base hash? - Is that 0-RTT Finished message needed? It is the only 0-RTT handshake message... - Server can send CertificateRequest in GDHE-PSK or PSK mode??? - What are 'etc' for parameters for 0-RTT data? Use the present extension list here and have any future extensions that matter here explicitly define their interaction. - The requirement for server to validate its extensions... Hopefully there is no security reason for that... I really don't see it being implemented correctly (and the description looks completely screwy[1]). - 1 RTT server context presumably ends in CertificateRequest, not CertificateVerify (the Certificate and CertificateVerify are impiled). - You might want flag for if server promises replay protection or not in NST. - You might want to specify that allow_dhe_resumption doesn't change key exchange, only authentication (so DHE_CERT becomes DHE_PSK and ECDHE_CERT becomes ECDHE_PSK). [1] There are many extensions that are not relevant because those control server authentication (e.g. status_request, status_request_v2, signed_certificate_timestamp, server_certificate_type). And some that are low-level connection control (e.g. max_fragment_length). ALPN is special here tho: It needs to match the impiled 0-RTT ALPN (does one want that extension in 0-RTT case anyway?). -Ilari From nobody Thu Apr 28 13:44:28 2016 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 2286212B04A for ; Thu, 28 Apr 2016 13:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEnSYBLsaLT1 for ; Thu, 28 Apr 2016 13:44:24 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECFC812D65C for ; Thu, 28 Apr 2016 13:44:21 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id g133so127119336ywb.2 for ; Thu, 28 Apr 2016 13:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RDhpLWrGu+qHT1NGG2fIXXAl+h5gf0RKvB7e6HzDhdA=; b=RinFObf3afuB+mowKuuNnia8nPmMReZs+KwEHQzetsfO8dCsXO58TqzW0TQR11+tN0 O7vRwd9hCFdEHsA8JuwbOCJWF6BlNlmrEBTURA+zwmehrFBbt90n0qFFdRQZNPYFJLnT FLqIlhzoWLxR7A90kxPPLI+KO2OttKJuU5nlvXAy1FBQcnphpB305vzRrwdLNh8BxhzO wDe3Rt+smFOItnw2CF7QLxBGsB0MAFapHRQ5mqQBXrzM7XJbhOzzWSw+Jcy4FCAWr3Gw WLCDTX6QELs4Zd27KCr7NtxGEzTKjgSA0NsqqAPKDhdbKykAHF+Mo9UNn298nhPdSzIf W7TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RDhpLWrGu+qHT1NGG2fIXXAl+h5gf0RKvB7e6HzDhdA=; b=k3ihrdQefpTQnVi1MabZ2K0usjMYkEUEXJQRsdw9wWrz31p+TpiBbXMUBSN4ESgHSB +EJSfKZk1xBwDtmJQBM4whwIsAgG85HlMGwAQjv32rHDs8J9Dm1J0EJmBxZ0P5e0jjUD EhpOShDp9nHZi8Frckj/QEBvHV54v6+OONG+reQ4L5chvRHHwzxRmqDyMqPfHgsWsqqa W4i7kS+e23fbWmEVNXyUkVUnaXFzBLbVeM33mfAxH32RmdxgLmEydIb+PVRZVlkzQP4y 2S0HnKPYyZux9/Utasr/keMaGrmExnjZPfCOB+kqhJEbBMFEIDznTKSQAdnshKnIEfhK I+eQ== X-Gm-Message-State: AOPr4FUdc6jOVjM5YoRYnMQmhe7y4ZMTaDMUf94BZGIVg9IY/ROWH1R6B5sAGors7Hg4V2fot6+znc/ucVEFFg== X-Received: by 10.13.237.1 with SMTP id w1mr9160523ywe.62.1461876261208; Thu, 28 Apr 2016 13:44:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Thu, 28 Apr 2016 13:43:41 -0700 (PDT) In-Reply-To: <20160428193252.GA16096@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160428193252.GA16096@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Thu, 28 Apr 2016 13:43:41 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c0864a84174c8053191978e Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] #445: Enhanced New Session Ticket X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2016 20:44:27 -0000 --94eb2c0864a84174c8053191978e Content-Type: text/plain; charset=UTF-8 On Thu, Apr 28, 2016 at 12:32 PM, Ilari Liusvaara wrote: > Some comments: > Please note: this PR is still a WIP. I'll be updating it in a bit... > - I presume 0-RTT used in retried ClientHello uses (and for the verify > mechanism to work, that needs to be allowed!) uses ClientHello1... > ClientHello2 as its base hash? > I don't think I understand what you are asking. Can you rephrase. > - Is that 0-RTT Finished message needed? It is the only 0-RTT handshake > message... > I think so it's a proof that the client knows the key. Also, per the discussion in Buenos-Aires we expect to be adding > - Server can send CertificateRequest in GDHE-PSK or PSK mode??? > Is there a reason that's undesirable? Note that it can always do post-handshake authentication, so we need to ensure that this is secure. My understanding is that because it covers the server's Finished, it therefore builds in the PSK value (per the analyis from Scott et al.). Do you have a concern with this. - What are 'etc' for parameters for 0-RTT data? Use the present > extension list here and have any future extensions that matter here > explicitly define their interaction. > The list is an example. The operative word is "all". - The requirement for server to validate its extensions... Hopefully > there is no security reason for that... I really don't see it being > implemented correctly (and the description looks completely screwy[1]). > This is an important requirement. For instance, you need the same ALPN value. > - 1 RTT server context presumably ends in CertificateRequest, not > CertificateVerify (the Certificate and CertificateVerify are > impiled). > I'm not sure which section of the draft you're referring too here. - You might want flag for if server promises replay protection or > not in NST. > We discussed this in BE and the consensus was that it was not clear how the server implemented this and so it was unwise to promise it. > - You might want to specify that allow_dhe_resumption doesn't > change key exchange, only authentication (so DHE_CERT becomes > DHE_PSK and ECDHE_CERT becomes ECDHE_PSK). I'm not sure I follow. It changes key exchange. If we want to have a resumption mode that has the server sign, we'll need a different indicator here. [1] There are many extensions that are not relevant because those > control server authentication (e.g. status_request, status_request_v2, > signed_certificate_timestamp, server_certificate_type). And some that > are low-level connection control (e.g. max_fragment_length) Yes, I am being conservative here because false positives don't seem like they will happen a lot. ALPN is special here tho: It needs to match the impiled 0-RTT ALPN > (does one want that extension in 0-RTT case anyway?). > Yes, you absolutely need ALPN for early data. -Ekr > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0864a84174c8053191978e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 28, 2016 at 12:32 PM, Ilari Liusvaara <ilariliusvaara@welho= .com> wrote:
Some comments:=

Please note: this PR is still a WIP. I= 'll be updating it in a bit...

=C2=A0
- I presume 0-RTT used in retried ClientHello uses (and for the verify
=C2=A0 mechanism to work, that needs to be allowed!) uses ClientHello1... =C2=A0 ClientHello2 as its base hash?

I= don't think I understand what you are asking. Can you rephrase.
<= div>=C2=A0
=C2=A0
- Is that 0-RTT Finished message needed? It is the only 0-RTT handshake
=C2=A0 message...

I think so it's a= proof that the client knows the key. Also, per the discussion in
Buenos-Aires we expect to be adding=C2=A0

=C2=A0<= br>
- Server can send CertificateRequest in GDHE-PSK or PSK mode???

Is there a reason that's undesirable? Note tha= t it can always do post-handshake
authentication, so we need to e= nsure that this is secure. My understanding is
that because it co= vers the server's Finished, it therefore builds in the PSK
va= lue (per the analyis from Scott et al.). Do you have a concern with this.


- What are 'etc' for parameters for 0-RTT data? Use the present
=C2=A0 extension list here and have any future extensions that matter here<= br> =C2=A0 explicitly define their interaction.

=
The list is an example. The operative word is "all".

- The requirement for server to validate its extensions... Hopefully
=C2=A0 there is no security reason for that... I really don't see it be= ing
=C2=A0 implemented correctly (and the description looks completely screwy[1= ]).

This is an important requirement. F= or instance, you need the same ALPN value.

=C2=A0<= /div>
- 1 RTT server context presumably ends in CertificateRequest, not
=C2=A0 CertificateVerify (the Certificate and CertificateVerify are
=C2=A0 impiled).

I'm not sure which= section of the draft you're referring too here.


- You might want flag for if server promises replay protection or
=C2=A0 not in NST.

We discussed this in= BE and the consensus was that it was not clear how
the server im= plemented this and so it was unwise to promise it.

=C2=A0
- You might want to specify that allow_dhe_resumption doesn't
=C2=A0 change key exchange, only authentication (so DHE_CERT becomes
=C2=A0 DHE_PSK and ECDHE_CERT becomes ECDHE_PSK).

I'm not sure I follow. It changes key exchange. If we want to ha= ve
a resumption mode that has the server sign, we'll need a d= ifferent
indicator here.


[1] There are many extensions that are not relevant because those
control server authentication (e.g. status_request, status_request_v2,
signed_certificate_timestamp, server_certificate_type). And some that
are low-level connection control (e.g. max_fragment_length)
Yes, I am being conservative here because false positives = don't seem like
they will happen a lot.

<= div>
ALPN is special here tho: It needs to match the impiled 0-RTT ALPN
(does one want that extension in 0-RTT case anyway?).
=
Yes, you absolutely need ALPN for early data.

=
-Ekr



-Ilari

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

--94eb2c0864a84174c8053191978e-- From nobody Thu Apr 28 14:04:03 2016 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 C18C712D1BE for ; Thu, 28 Apr 2016 14:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcwvW3TAFQ2o for ; Thu, 28 Apr 2016 14:04:00 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B46F12B00F for ; Thu, 28 Apr 2016 14:04:00 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id f89so89633090ioi.0 for ; Thu, 28 Apr 2016 14:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=vmhQ6dsDBBWl6U8rcMGHwn8dsCag/pvrH8s1iBIG0Ew=; b=cy0Fxb7AcUQX73OvA32495AujrJS7FbIFFV+d7REltCpCr+baEFDnffZuroodi2X9h U6GZCiejLuDeBx7CIezmtZYN1wF0uUkQTCO8plm6mF75f2BYF50mZJHPJCMQt5iAJ+MM gcpRAwFgQc+q9ZXGcXoXG2ww/CcO+19rOoNgvDXzHgX/FOWjT/WlGRVs5THIWfo0eLun LDWimxQ6PA4GFtX1v9DA6kAwfT7Hw6RnYU81NKE679YKHgB7gWSRXGYOkKWqdOBrA4Hn 3JyvVKPmN7IVjcmKvnUkk4X0I5+uJz0U5UhAQAZOEBtUZFhO9BgUQy9x0XJN3oMYitnh DxNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=vmhQ6dsDBBWl6U8rcMGHwn8dsCag/pvrH8s1iBIG0Ew=; b=hKl544RoBJVqRzLP9X/0ypq/zshTaGjqzBf48fISTOB8UJstuxD98wAm1VCL2gMmwK OzRVavOQwQjJ2dnOJGAYmnpEsx7b3BmEteKatgmppnzKa9kKlb7T+gmpJWuoqTS/3urs kALZP/Oa1Gx4BM1eupsotecbnuwUD24XaaotEvkKGs0odt+Z+5/hhQnyGFazb3lyZbTK KWZGE5q+An4Jduu7C8IRXQSQsBaf1TDc/1bikqIT1EvzL9iaFLGPfwSzBzfliOur3nTS OiBt15A9CBMCBvmjkDbZvejS0UEyBHabuyNnhrPavyAJFZuW5xN5tF1cYevjmxUBo0zx HmlA== X-Gm-Message-State: AOPr4FVTFx71ZInjhICNV9X1X3GszLAq/u9fnUXdNDtTH4HmCPDIND/OI3KkKXc00WcL1iK6fcGHwa3IySEQCg== MIME-Version: 1.0 X-Received: by 10.107.59.85 with SMTP id i82mr18634516ioa.108.1461877439551; Thu, 28 Apr 2016 14:03:59 -0700 (PDT) Received: by 10.36.43.82 with HTTP; Thu, 28 Apr 2016 14:03:59 -0700 (PDT) In-Reply-To: References: <20160428193252.GA16096@LK-Perkele-V2.elisa-laajakaista.fi> Date: Fri, 29 Apr 2016 07:03:59 +1000 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] #445: Enhanced New Session Ticket X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2016 21:04:01 -0000 On 29 April 2016 at 06:43, Eric Rescorla wrote: >> - You might want to specify that allow_dhe_resumption doesn't >> change key exchange, only authentication (so DHE_CERT becomes >> DHE_PSK and ECDHE_CERT becomes ECDHE_PSK). > > > I'm not sure I follow. It changes key exchange. If we want to have > a resumption mode that has the server sign, we'll need a different > indicator here. There is a separate issue that would have the client able to request that the server provide a certificate/certificateverify in resumption handshakes. For that, we might add a allow_cert_resumption flag. But we would do that separately. (Regarding that, if we use cached-info on that resumption, which is probably a good idea overall, then that extension will differ between handshakes.) From nobody Thu Apr 28 14:21:57 2016 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 08A8C12D9F4 for ; Thu, 28 Apr 2016 14:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kroMSTYNvl8w for ; Thu, 28 Apr 2016 14:21:52 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C414A12D9F1 for ; Thu, 28 Apr 2016 14:21:51 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id g133so128986553ywb.2 for ; Thu, 28 Apr 2016 14:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QL59JnFpPiwV7jTW2Z7c101W8vn8Z6lrlMFD7yrWG2o=; b=A5TdIeO81MN4/gS8KcVkWDFwDXu901/FFUphi2LTojrFkUs+JLHCstDBTe/N6swzbf 6QWRdeAX9BV64C2D5SiL/OhSQ4vVrwRN9VY4IsMqiFb+XEkFDSaIOvqg13RV6XbfVPiY jeQSEF1JMLU1uiY4rq8SjbeTasxvsacHWlLPuzO4Q1vazGSsFh+6z7SAjCbV0pndirjF zF5x1/RipuX5xGNkF8m0AoF8Vi+GlTS5M3O+QNiuJjh0SQ7hq1hiuO0RPezhLm+W66H6 ocxkqNgV/aqhW8XnRp7LntMrKAzCnOSzJzEpr+1FT8qWY28WZ+jRH4XoHcnsZViU7Ggv IfvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QL59JnFpPiwV7jTW2Z7c101W8vn8Z6lrlMFD7yrWG2o=; b=AAJ86CewQ6UCHHV0OTnnzBN1zboI3h9BqOxSGo+R8w1PJoceLiT6bFqv/jPerxhlgG Y/MDb/MKycNHs4xEP7Srp2x0REIqm3Fhoj6dusu9YRIVKaV3tbvzQ+CEfc7ns3qgyln1 rL1mR+rGx6qyWuRFuKSKQL5BXYeffrXnoTMkax+UEU2hHWcnQSTh9GzxL+TZF3AJV/nQ uXFpkABCTR1iUVINOa3m44rm0wYSPrh83NsxDZfIsdug32pfu1Vd2Cv23+gQ6Fg8C5Yp F+PZaOF5a4qAcZDwWtMHdzZEu26CqjsArT7Ny8/iEcldjFmyZ4fP4RnzJLNPQi4fJu9z TGqw== X-Gm-Message-State: AOPr4FXDC4mpx2ZI+kr+mME1db1ddgJJWj81s158IDYetCGSX5KA7maPjO+I3GXUoi70rpSXRQOr58Kqfs6cnQ== X-Received: by 10.37.80.146 with SMTP id e140mr4748524ybb.162.1461878511090; Thu, 28 Apr 2016 14:21:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Thu, 28 Apr 2016 14:21:11 -0700 (PDT) In-Reply-To: References: <20160428193252.GA16096@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Thu, 28 Apr 2016 14:21:11 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a113ea0605bf2130531921dcf Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] #445: Enhanced New Session Ticket X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2016 21:21:54 -0000 --001a113ea0605bf2130531921dcf Content-Type: text/plain; charset=UTF-8 On Thu, Apr 28, 2016 at 1:43 PM, Eric Rescorla wrote: > On Thu, Apr 28, 2016 at 12:32 PM, Ilari Liusvaara < > ilariliusvaara@welho.com> wrote: > >> Some comments: >> > > Please note: this PR is still a WIP. I'll be updating it in a bit... > > > >> - I presume 0-RTT used in retried ClientHello uses (and for the verify >> mechanism to work, that needs to be allowed!) uses ClientHello1... >> ClientHello2 as its base hash? >> > > I don't think I understand what you are asking. Can you rephrase. > > > >> - Is that 0-RTT Finished message needed? It is the only 0-RTT handshake >> message... >> > > I think so it's a proof that the client knows the key. Also, per the > discussion in > Buenos-Aires we expect to be adding > > > >> - Server can send CertificateRequest in GDHE-PSK or PSK mode??? >> > > Is there a reason that's undesirable? Note that it can always do > post-handshake > authentication, so we need to ensure that this is secure. My understanding > is > that because it covers the server's Finished, it therefore builds in the > PSK > value (per the analyis from Scott et al.). Do you have a concern with this. > > > - What are 'etc' for parameters for 0-RTT data? Use the present >> extension list here and have any future extensions that matter here >> explicitly define their interaction. >> > > The list is an example. The operative word is "all". > > - The requirement for server to validate its extensions... Hopefully >> there is no security reason for that... I really don't see it being >> implemented correctly (and the description looks completely screwy[1]). >> > > This is an important requirement. For instance, you need the same ALPN > value. > > > >> - 1 RTT server context presumably ends in CertificateRequest, not >> CertificateVerify (the Certificate and CertificateVerify are >> impiled). >> > > I'm not sure which section of the draft you're referring too here. > Ah, right, I got confused about sections. Thanks. > > > - You might want flag for if server promises replay protection or >> not in NST. >> > > We discussed this in BE and the consensus was that it was not clear how > the server implemented this and so it was unwise to promise it. > > > >> - You might want to specify that allow_dhe_resumption doesn't >> change key exchange, only authentication (so DHE_CERT becomes >> DHE_PSK and ECDHE_CERT becomes ECDHE_PSK). > > > I'm not sure I follow. It changes key exchange. If we want to have > a resumption mode that has the server sign, we'll need a different > indicator here. > > > [1] There are many extensions that are not relevant because those >> control server authentication (e.g. status_request, status_request_v2, >> signed_certificate_timestamp, server_certificate_type). And some that >> are low-level connection control (e.g. max_fragment_length) > > > Yes, I am being conservative here because false positives don't seem like > they will happen a lot. > > > ALPN is special here tho: It needs to match the impiled 0-RTT ALPN >> (does one want that extension in 0-RTT case anyway?). >> > > Yes, you absolutely need ALPN for early data. > > -Ekr > > >> >> -Ilari >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > --001a113ea0605bf2130531921dcf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 28, 2016 at 1:43 PM, Eric Rescorla <ekr@rtfm.com>= wrote:
On Thu, Apr 28, 2016 at 12:32 PM, Ila= ri Liusvaara <ilariliusvaara@welho.com> wrote:
Some comments:

<= div>Please note: this PR is still a WIP. I'll be updating it in a bit..= .

=C2=A0
- I presume 0-RTT used in retried ClientHello uses (and for the verify
=C2=A0 mechanism to work, that needs to be allowed!) uses ClientHello1... =C2=A0 ClientHello2 as its base hash?

I don't think I understand what you are asking. Can you rephrase.=
=C2=A0
=C2=A0
- Is that 0-RTT Finished message needed? It is the only 0-RTT handshake
=C2=A0 message...

I think so it&= #39;s a proof that the client knows the key. Also, per the discussion in
Buenos-Aires we expect to be adding=C2=A0

=C2=A0
- Server can send CertificateRequest in GDHE-PSK or PSK mode???

Is there a reason that's undesirable? N= ote that it can always do post-handshake
authentication, so we ne= ed to ensure that this is secure. My understanding is
that becaus= e it covers the server's Finished, it therefore builds in the PSK
=
value (per the analyis from Scott et al.). Do you have a concern with = this.


- What are 'etc' for parameters for 0-RTT data? Use the present
=C2=A0 extension list here and have any future extensions that matter here<= br> =C2=A0 explicitly define their interaction.

=
The list is an example. The operative word is "all".<= /div>

- The requirement for server to validate its extensions... Hopefully
=C2=A0 there is no security reason for that... I really don't see it be= ing
=C2=A0 implemented correctly (and the description looks completely screwy[1= ]).

This is an important require= ment. For instance, you need the same ALPN value.

=C2=A0
- 1 RTT server context presumably ends in CertificateRequest, not
=C2=A0 CertificateVerify (the Certificate and CertificateVerify are
=C2=A0 impiled).

I'm not sur= e which section of the draft you're referring too here.

Ah, right, I got confused about se= ctions. Thanks.
=C2=A0


- You might want flag for if server promises replay protection or
=C2=A0 not in NST.

We discussed = this in BE and the consensus was that it was not clear how
the se= rver implemented this and so it was unwise to promise it.

=C2=A0
- You might want to specify that allow_dhe_resumption doesn't
=C2=A0 change key exchange, only authentication (so DHE_CERT becomes
=C2=A0 DHE_PSK and ECDHE_CERT becomes ECDHE_PSK).

I'm not sure I follow. It changes key exchange. If we wan= t to have
a resumption mode that has the server sign, we'll n= eed a different
indicator here.


[1] There are many extensions that are not relevant because those
control server authentication (e.g. status_request, status_request_v2,
signed_certificate_timestamp, server_certificate_type). And some that
are low-level connection control (e.g. max_fragment_length)

Yes, I am being conservative here because false pos= itives don't seem like
they will happen a lot.


ALPN is special here tho: It needs to match the impiled 0-RTT ALPN
(does one want that extension in 0-RTT case anyway?).
=
Yes, you absolutely need ALPN for early data.

-Ekr



-Ilari

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


--001a113ea0605bf2130531921dcf-- From nobody Thu Apr 28 14:40:54 2016 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 0AA1C12D522 for ; Thu, 28 Apr 2016 14:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fY3TkerXqb4J for ; Thu, 28 Apr 2016 14:40:51 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 51D2512D19F for ; Thu, 28 Apr 2016 14:40:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id D45E76B91; Fri, 29 Apr 2016 00:40:49 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id Xw4LSsl0lGeX; Fri, 29 Apr 2016 00:40:49 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 690D327F; Fri, 29 Apr 2016 00:40:49 +0300 (EEST) Date: Fri, 29 Apr 2016 00:40:46 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160428214046.GB16096@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160428193252.GA16096@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] #445: Enhanced New Session Ticket X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2016 21:40:54 -0000 On Thu, Apr 28, 2016 at 01:43:41PM -0700, Eric Rescorla wrote: > On Thu, Apr 28, 2016 at 12:32 PM, Ilari Liusvaara > wrote: > > > > - I presume 0-RTT used in retried ClientHello uses (and for the verify > > mechanism to work, that needs to be allowed!) uses ClientHello1... > > ClientHello2 as its base hash? > > > > I don't think I understand what you are asking. Can you rephrase. Client sends ClientHello with 0RTT data, gets HelloRetryRequest back and resends ClientHello. For hash continuation to work, the new ClientHello needs to contain the EarlyData extension, which would imply there is 0RTT data following that too. > > - Server can send CertificateRequest in GDHE-PSK or PSK mode??? > > > > Is there a reason that's undesirable? Note that it can always do > post-handshake > authentication, so we need to ensure that this is secure. My understanding > is > that because it covers the server's Finished, it therefore builds in the PSK > value (per the analyis from Scott et al.). Do you have a concern with this. Note that carelessly doing post-handshake auth can lead to nasty issues (fortunately it is not allowed for HTTP/2!). And wonder what it would do to the handshake state machine to have the possibility of the CertificateRequest message (you need state machine to avoid all sorts of attacks). > - What are 'etc' for parameters for 0-RTT data? Use the present > > extension list here and have any future extensions that matter here > > explicitly define their interaction. > > > > The list is an example. The operative word is "all". And what is "all" with current extensions (defined as whatever is in registry currently + whatever TLS 1.3 base defines)? I think ciphersuite (apporiately transformed) and ALPN. Are there others? I'm ignoring future extensions, as those can define whatever is needed. > - The requirement for server to validate its extensions... Hopefully > > there is no security reason for that... I really don't see it being > > implemented correctly (and the description looks completely screwy[1]). > > > > This is an important requirement. For instance, you need the same ALPN > value. ALPN yes. However, with all the extensions the chances this requirement is implemented correctly are slim. Which means that relying upon it for safety is a Bad Idea. I think one should explicitly call out extensions that need special handling here (which I think is presently only ALPN). > > - 1 RTT server context presumably ends in CertificateRequest, not > > CertificateVerify (the Certificate and CertificateVerify are > > impiled). > > > > I'm not sure which section of the draft you're referring too here. The table of authentication block (Certificate+CertificateVerify+Finished sequences) base keys and hashes (section 6.3.4 in current Editor's Copy). > - You might want flag for if server promises replay protection or > > not in NST. > > > > We discussed this in BE and the consensus was that it was not clear how > the server implemented this and so it was unwise to promise it. You can replay-cache on ClientHello hash. > > - You might want to specify that allow_dhe_resumption doesn't > > change key exchange, only authentication (so DHE_CERT becomes > > DHE_PSK and ECDHE_CERT becomes ECDHE_PSK). > > I'm not sure I follow. It changes key exchange. If we want to have > a resumption mode that has the server sign, we'll need a different > indicator here. Can ciphersuite C02B (ECDHE_ECDSA/...) become 00AA (DHE_PSK/...) upon use of the created PSK? > [1] There are many extensions that are not relevant because those > > control server authentication (e.g. status_request, status_request_v2, > > signed_certificate_timestamp, server_certificate_type). And some that > > are low-level connection control (e.g. max_fragment_length) > > Yes, I am being conservative here because false positives don't seem like > they will happen a lot. False positives? Try implementation errors. > ALPN is special here tho: It needs to match the impiled 0-RTT ALPN > > (does one want that extension in 0-RTT case anyway?). > > > > Yes, you absolutely need ALPN for early data. I mean do you need explicit indication, as opposed to taking the protocol the accepted 0-RTT data was for and not signaling it. Otherwise you need MUST abort requirement for the client. -Ilari From nobody Thu Apr 28 15:12:33 2016 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 AEB2F12B018 for ; Thu, 28 Apr 2016 15:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqbqdPh8EPpq for ; Thu, 28 Apr 2016 15:12:30 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51EDF12D88C for ; Thu, 28 Apr 2016 15:12:30 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id g133so131249058ywb.2 for ; Thu, 28 Apr 2016 15:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nwFBtRmup654XTP8F7gJa2s3WxnX0oB1mTBYgq4KFUw=; b=jekimdiZwjucCRfDUYXmjUGR31SkOXDPItwvzKlNxJ9ydahDQs9rKxYYW0jKz5l6o+ A75Y5auVLgDpaLvL2MIkXac4enCimNGYSuxpvwRwMWLNIoVWR2I0WUKl2aAGC/VlOSey 7lSC2B+0vP6enOE3tf3fCh7gAfzRWIjmuOCzaNPtAJ+Atl+wwwcsqAHJLoEMm66ZG6wO QeJu0xXkvwfgBpAnSNTChIkhGvmkcerkG2F0sjJ8kwKsTIlwrn++pUff8CYCk8BiZQ8J y7xfz1i5ZIxI3ZJ7y8K9jrD/25sRHoLxznFawihHrgI6uni8OQQRYoiMWp2n4YdrgP8s 88WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nwFBtRmup654XTP8F7gJa2s3WxnX0oB1mTBYgq4KFUw=; b=X5HF60qyB7uaPaKVnTV3Evx8ydShsTVDUGTpDqJr3S7sZYUgbejc5B2wwhzTb+xuOG yOqAN2MD1Mar7LkssUGy3MlGBClvN5+BYKPei/+ePSbKkTn1hJ0xkO0Kf9SlfNeUOE+r vvm4mEL9GbyGKhKi3O9lwlSLGOeUFAx1yzXsbp6FAEvk1pPDYSEJR1Smsg+KzxDkPnsj jZCAOzdB5TgsyiU1jB+oDsvnCfe4as7SitDkNidKwgv0Ssq5Zp9xn9I83S5NmIlMTBdb BvVYGywqW5b2DmoeVnO0gVP11IyB+Ozoli/8hrFRFkUTceMzSl9BUH+ewI8MOkfomf2K EmGQ== X-Gm-Message-State: AOPr4FUCpTvAe7cmPVBKsTyNwcNnrg0Ye7mfmYzmoj2aW1yKxl2zmSjwPkqWmjbZVKOrtLTgPUwuxqhBh5wo2A== X-Received: by 10.13.222.1 with SMTP id h1mr10984401ywe.171.1461881549572; Thu, 28 Apr 2016 15:12:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Thu, 28 Apr 2016 15:11:50 -0700 (PDT) In-Reply-To: <20160428214046.GB16096@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160428193252.GA16096@LK-Perkele-V2.elisa-laajakaista.fi> <20160428214046.GB16096@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Thu, 28 Apr 2016 15:11:50 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c07c412777cb5053192d2e8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] #445: Enhanced New Session Ticket X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 28 Apr 2016 22:12:32 -0000 --94eb2c07c412777cb5053192d2e8 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 28, 2016 at 2:40 PM, Ilari Liusvaara wrote: > On Thu, Apr 28, 2016 at 01:43:41PM -0700, Eric Rescorla wrote: > > On Thu, Apr 28, 2016 at 12:32 PM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > > > > - I presume 0-RTT used in retried ClientHello uses (and for the verify > > > mechanism to work, that needs to be allowed!) uses ClientHello1... > > > ClientHello2 as its base hash? > > > > > > > I don't think I understand what you are asking. Can you rephrase. > > Client sends ClientHello with 0RTT data, gets HelloRetryRequest back and > resends ClientHello. For hash continuation to work, the new ClientHello > needs to contain the EarlyData extension, which would imply there is > 0RTT data following that too. > No, I don't think you need to have the extension. Either the server is keeping state and there's no problem or the server is offloading state in a cookie (mechanism TBD) and in either case it just needs the state as of the beginning of the new ClientHello. > > - Server can send CertificateRequest in GDHE-PSK or PSK mode??? > > > > > > > Is there a reason that's undesirable? Note that it can always do > > post-handshake > > authentication, so we need to ensure that this is secure. My > understanding > > is > > that because it covers the server's Finished, it therefore builds in the > PSK > > value (per the analyis from Scott et al.). Do you have a concern with > this. > > Note that carelessly doing post-handshake auth can lead to nasty issues > (fortunately it is not allowed for HTTP/2!). > I expect that post-handshake client auth will be allowed for HTTP/2. Can you elaborate on your concern. And wonder what it would do to the handshake state machine to have the > possibility of the CertificateRequest message (you need state machine to > avoid all sorts of attacks). Well note that the EncryptedExtensions. > > - What are 'etc' for parameters for 0-RTT data? Use the present > > > extension list here and have any future extensions that matter here > > > explicitly define their interaction. > > > > > > > The list is an example. The operative word is "all". > > And what is "all" with current extensions (defined as whatever is in > registry currently + whatever TLS 1.3 base defines)? I think ciphersuite > (apporiately transformed) and ALPN. Are there others? > Yes, that's what I meant. > > > - 1 RTT server context presumably ends in CertificateRequest, not > > > CertificateVerify (the Certificate and CertificateVerify are > > > impiled). > > > > > > > I'm not sure which section of the draft you're referring too here. > > The table of authentication block (Certificate+CertificateVerify+Finished > sequences) base keys and hashes (section 6.3.4 in current Editor's Copy). > Thanks, I've fixed this > - You might want flag for if server promises replay protection or > > > not in NST. > > > > > > > We discussed this in BE and the consensus was that it was not clear how > > the server implemented this and so it was unwise to promise it. > > You can replay-cache on ClientHello hash. > Unfortunately this does not work perfectly in distributed systems, which is the original source of the concern. > > > - You might want to specify that allow_dhe_resumption doesn't > > > change key exchange, only authentication (so DHE_CERT becomes > > > DHE_PSK and ECDHE_CERT becomes ECDHE_PSK). > > > > I'm not sure I follow. It changes key exchange. If we want to have > > a resumption mode that has the server sign, we'll need a different > > indicator here. > > Can ciphersuite C02B (ECDHE_ECDSA/...) become 00AA (DHE_PSK/...) > upon use of the created PSK? Ah, I see. I thought about whether we should prohibit that and decided against it. But I could be convinced the other way. > > [1] There are many extensions that are not relevant because those > > > control server authentication (e.g. status_request, status_request_v2, > > > signed_certificate_timestamp, server_certificate_type). And some that > > > are low-level connection control (e.g. max_fragment_length) > > > > Yes, I am being conservative here because false positives don't seem like > > they will happen a lot. > > False positives? Try implementation errors. > Well, it seems like there are two concerns here re: implementation errors. 1. That servers will bungle this check and reject 0-RTT when they should accept it [false positive] 2. That servers will bungle this check and accept 0-RTT when they should reject it (and that we'll be relying on that). Is your concern the first or the second? > ALPN is special here tho: It needs to match the impiled 0-RTT ALPN > > > (does one want that extension in 0-RTT case anyway?). > > > > > > > Yes, you absolutely need ALPN for early data. > > I mean do you need explicit indication, as opposed to taking the > protocol the accepted 0-RTT data was for and not signaling it. > Well, the current draft does not have explicit indication. All of the 0-RTT context is tied to the ticket. -Ekr > Otherwise you need MUST abort requirement for the client. > > > -Ilari > --94eb2c07c412777cb5053192d2e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 28, 2016 at 2:40 PM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On Thu, Apr 28, 2016 at 01:43:41PM -0700, Eric Rescorla wrote: > On Thu, Apr 28, 2016 at 12:32 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
>
> > - I presume 0-RTT used in retried ClientH= ello uses (and for the verify
> >=C2=A0 =C2=A0mechanism to work, that needs to be allowed!) uses Cl= ientHello1...
> >=C2=A0 =C2=A0ClientHello2 as its base hash?
> >
>
> I don't think I understand what you are asking. Can you rephrase.<= br>
Client sends ClientHello with 0RTT data, gets HelloRetryRequest back= and
resends ClientHello. For hash continuation to work, the new ClientHello
needs to contain the EarlyData extension, which would imply there is
0RTT data following that too.

No, I don= 't think you need to have the extension. Either the server is keeping
state and there's no problem or the server is offloading state= in a cookie
(mechanism TBD) and in either case it just needs the= state as of the
beginning of the new ClientHello.

=

> > - Server can send CertificateRequest in GDHE-PSK or PSK mode??? > >
>
> Is there a reason that's undesirable? Note that it can always do > post-handshake
> authentication, so we need to ensure that this is secure. My understan= ding
> is
> that because it covers the server's Finished, it therefore builds = in the PSK
> value (per the analyis from Scott et al.). Do you have a concern with = this.

Note that carelessly doing post-handshake auth can lead to nasty iss= ues
(fortunately it is not allowed for HTTP/2!).

I expect that post-handshake client auth will be allowed for HTTP/2. = Can you
elaborate on your concern.


<= /div>
And wonder what it would do to the handshake state machine to have the
possibility of the CertificateRequest message (you need state machine to avoid all sorts of attacks).

Well note that= the EncryptedExtensions.

=C2=A0
> - What are 'etc' for parameters for 0-RTT data? Use the presen= t
> >=C2=A0 =C2=A0extension list here and have any future extensions th= at matter here
> >=C2=A0 =C2=A0explicitly define their interaction.
> >
>
> The list is an example. The operative word is "all".

And what is "all" with current extensions (defined as what= ever is in
registry currently + whatever TLS 1.3 base defines)? I think ciphersuite (apporiately transformed) and ALPN. Are there others?
=
Yes, that's what I meant.

=C2= =A0
> > - 1 RTT server context presumably ends in CertificateRequest, not=
> >=C2=A0 =C2=A0CertificateVerify (the Certificate and CertificateVer= ify are
> >=C2=A0 =C2=A0impiled).
> >
>
> I'm not sure which section of the draft you're referring too h= ere.

The table of authentication block (Certificate+CertificateVerify+Fin= ished
sequences) base keys and hashes (section 6.3.4 in current Editor's Copy= ).

Thanks, I've fixed this


> - You might want flag for if server promises replay protection or
> >=C2=A0 =C2=A0not in NST.
> >
>
> We discussed this in BE and the consensus was that it was not clear ho= w
> the server implemented this and so it was unwise to promise it.

You can replay-cache on ClientHello hash.

<= /div>
Unfortunately this does not work perfectly in distributed systems= , which is the original
source of the concern.


> > - You might want to specify that allow_dhe_resumption doesn't=
> >=C2=A0 =C2=A0change key exchange, only authentication (so DHE_CERT= becomes
> >=C2=A0 =C2=A0DHE_PSK and ECDHE_CERT becomes ECDHE_PSK).
>
> I'm not sure I follow. It changes key exchange. If we want to have=
> a resumption mode that has the server sign, we'll need a different=
> indicator here.

Can ciphersuite C02B (ECDHE_ECDSA/...) become 00AA (DHE_PSK/...)
upon use of the created PSK?

Ah, I see. I t= hought about whether we should prohibit that and decided against
= it. But I could be convinced the other way.

=C2=A0=
> [1] There are many extensions that are not relevant because those
> > control server authentication (e.g. status_request, status_reques= t_v2,
> > signed_certificate_timestamp, server_certificate_type). And some = that
> > are low-level connection control (e.g. max_fragment_length)
>
> Yes, I am being conservative here because false positives don't se= em like
> they will happen a lot.

False positives? Try implementation errors.
Well, it seems like there are two concerns here re: implementat= ion errors.

1. That servers will bungle this check= and reject 0-RTT when they should
accept it [false positive]
2. That servers will bungle this check and accept 0-RTT when they sh= ould
reject it (and that we'll be relying on that).

Is your concern the first or the second?

> ALPN is special here tho: It needs to match the impiled 0-RTT ALPN
> > (does one want that extension in 0-RTT case anyway?).
> >
>
> Yes, you absolutely need ALPN for early data.

I mean do you need explicit indication, as opposed to taking the
protocol the accepted 0-RTT data was for and not signaling it.

Well, the current draft does not have explicit indi= cation. All of the 0-RTT
context is tied to the ticket.

-Ekr


Otherwise you need MUST abort requirement for the client.


-Ilari

--94eb2c07c412777cb5053192d2e8-- From nobody Thu Apr 28 17:21:21 2016 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 50FCB12D51C for ; Thu, 28 Apr 2016 17:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.093 X-Spam-Level: X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqYts33YCoVV for ; Thu, 28 Apr 2016 17:21:18 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DD312D51F for ; Thu, 28 Apr 2016 17:21:18 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id j74so135833514ywg.1 for ; Thu, 28 Apr 2016 17:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=DNtC5l1HFCp+qWgN/QffQdWLOAHWLJ65ikXLHQ+gabk=; b=GLvidLdwsapZknx+8V0ktW3GzlEbWIOjqdfTbvSJ0Di2HOC1W8HWJPDOguIFM84O6d od7/bHNkjW0Jyy6n5lSfCte1dUDB85IBxeTXf2Jy+iR/SptKEkysCa3auzgJP+RierRl 0xlrdrTp4UhHqXCKZjR7gorLactKvITnO44F4DqjsDD9M5GqQ6GDxijxE7lnhwXr6JBc oJo8CuDYivm27yuRbJV3VMRxGtvW8S3czyeFf8JnAiv9C2zi6VBkuifWoypy8tLLlqfl Zc10rlautpKULmJYKuGdmRw3jj7XF8xAXYXbiP0s1+xUUY6VhsMyxJfQY2x+o2TnF531 kxhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DNtC5l1HFCp+qWgN/QffQdWLOAHWLJ65ikXLHQ+gabk=; b=W2yYuOUa64/vE1hOhbRmlLktegkApfZruohQvUm5FXzZMZ7yBgtNO8WBrtaW+Slgzs LSmhJ4g6HvSJyg4kKJpkCpPj8pAH4Qw3tEejPjNlJJvGYBuZylbtk8HDn6lR77iUzWCH n1UVxqQkgcx8FLJL3bZa7xGze14xqhAxxZJli9xym60MnwKF5ODWsrRs2mwX18od+J6q gbpRCTX5vHug1dOfx02aCa8D7PWR8N6WzfDXK3s3r1kYlG/r/ot3XIw5trh3nDeVBuQd DANlGEC54Sx60Y0qoxo81iDD0P2aqTtydpm8UB4EBqn2DER0yKjKVxlP7EqXM4goiVbM VWOw== X-Gm-Message-State: AOPr4FXKGZ3JJB1ALrBXrtMzM1/C40IfDK7dHOmGfTcWquKl65MN1z5JVb79dQ9QfC/KGfXex1inRbP3eI7WlQ== X-Received: by 10.37.80.146 with SMTP id e140mr5120114ybb.162.1461889277974; Thu, 28 Apr 2016 17:21:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Thu, 28 Apr 2016 17:20:38 -0700 (PDT) From: Eric Rescorla Date: Thu, 28 Apr 2016 17:20:38 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113ea0601d94270531949fb9 Archived-At: Subject: [TLS] PR# 444, 445 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Apr 2016 00:21:20 -0000 --001a113ea0601d94270531949fb9 Content-Type: text/plain; charset=UTF-8 Hi folks, I've posted two PRs: https://github.com/tlswg/tls13-spec/pull/444 https://github.com/tlswg/tls13-spec/pull/445 These enact several consensus decisions from Buenos-Aires: 1. Remove 0-RTT (EC)DHE leaving only PSK-based 0-RTT (444) 2. Remove 0-RTT client auth (444) 3. Enhance the NewSessionTicket message to include indicators about permissible cipher suites and whether 0-RTT is allowed (445, but based on 444). These are still a bit of a WIP but should be ready for people to take a look (Ilari already has) to make sure that they are what you expect. In particular, please take a look at the way I've handled the 0-RTT parameters, which is to not expliclty signal any of them and to require that the server use the ones from the ticket and validate that essentially all of them match the newly negotiated parameters for the resumed session. Ilari has suggested that we should instead only require matching for a small number (based on individualized analysis). -Ekr P.S. I know that these are missing EncryptedExtensions from the client. That's on my list to do soon. --001a113ea0601d94270531949fb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi folks,

I've posted two PRs:

These enact several consensus decisions= from Buenos-Aires:

1. Remove 0-RTT (EC)DHE leavin= g only PSK-based 0-RTT (444)
2. Remove 0-RTT client auth (444)
3. Enhance the NewSessionTicket message to include indicators about= permissible
cipher suites and whether 0-RTT is allowed (445, but= based on 444).

These are still a bit of a WIP but= should be ready for people to take a look (Ilari
already has) to= make sure that they are what you expect. In particular, please
t= ake a look at the way I've handled the 0-RTT parameters, which is to no= t expliclty
signal any of them and to require that the server use= the ones from the ticket and
validate that essentially all of th= em match the newly negotiated parameters for
the resumed session.= Ilari has suggested that we should instead only require
matching= for a small number (based on individualized analysis).

-Ekr

P.S. I know that these are missing Encr= yptedExtensions from the client.
That's on my list to do soon= .



--001a113ea0601d94270531949fb9-- From nobody Thu Apr 28 20:41:00 2016 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 4F93412D1C9 for ; Thu, 28 Apr 2016 20:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kk4hH4S-izfJ for ; Thu, 28 Apr 2016 20:40:57 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C8512D14E for ; Thu, 28 Apr 2016 20:40:57 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id u185so112000318iod.3 for ; Thu, 28 Apr 2016 20:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=3BZoH5z8zCQ7z5eKvD38k4PzNZ626W1Wv4srsWm8LDQ=; b=xmReZWlF0kaG7wOvlrPNS0NWi31lD7t5EfDDm8vfz4tjIap7TL75K20hKGlcIoYpLi 0kjNKaI2K1eEKYBtypEudUvd4QfSA2pjxQ3ntPHXBD4HyLP2WHWhC6u71OKsuUDLQ2jG OEZaJwNf4Jounj+CTKAytnJe5t0E/flhMuAtS3teKeVGXA21lR6p5PgZWOCybMVgCW8J BK0gxtPT7Jk9slIO4gzUJcwLIAEuk+5kilvSIWDFLfu/rlHueEBamZZnQfUWpIcyKIht iC/wINI3F97AqilGuFWOWxhJacV3lD63qMUQ9dI6MA9el12XhYlGI84k6imb3Yiw+v4L NPWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=3BZoH5z8zCQ7z5eKvD38k4PzNZ626W1Wv4srsWm8LDQ=; b=e9Ba5cOLBIRyDS/ErXeDZBxgwwioh4n0SwKGwN/si6hzpv8Dy8ZDQtlRPaMI69zdIP 2MtefKKx4I21hhYl+44imKekYy0MHW31xUkj9IUbL3L6WAddLHCsYn4kIAHPFIGEQrVY qS6NihMzHQjXQo9aqMZ/b62Vyb2UkFf5vqopm+C5Emr6zRk+MBCkBUBEob44Q7vZLmMy /fm/upFKtBzn5yAVfJUhad3T20uFkV7nWhanTnaZ2WLffrtv1C87UvpX3dOwknVh4UTH 5Mepitgy71W0PkKRfme0AqlIgh4Zu9Yy+9L7JTn9AD0/g4Y5BlQtuYe5MHsXFPxm1Xud X4MQ== X-Gm-Message-State: AOPr4FUZ4Bu2g0NmRwL7zAipKODh+k5frJnJ/TERk37VyBZq0yNwD3q/oLwj+dU0ygVPChJSifFUpP1tWj9cPg== MIME-Version: 1.0 X-Received: by 10.107.59.85 with SMTP id i82mr20121878ioa.108.1461901256861; Thu, 28 Apr 2016 20:40:56 -0700 (PDT) Received: by 10.36.43.82 with HTTP; Thu, 28 Apr 2016 20:40:56 -0700 (PDT) In-Reply-To: <78f6d6778c608a99e276c2efa561d2ab@esat.kuleuven.be> References: <78f6d6778c608a99e276c2efa561d2ab@esat.kuleuven.be> Date: Fri, 29 Apr 2016 13:40:56 +1000 Message-ID: From: Martin Thomson To: aluykx Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data Volume Limits Analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Apr 2016 03:40:59 -0000 On 9 March 2016 at 09:16, aluykx wrote: > Kenny Paterson and I prepared a document providing an overview of how much > data ChaCha20+Poly1305 and AES-GCM can process with a single key. Besides > summarizing the results, the document also gives an explanation of why the > limits are there. The document confirms the analysis done by Watson and > others in the thread on "Data Volume Limits", but goes into more detail. Hi Atul, Just to confirm, but this analysis is for all variants of AES-GCM regardless of key size? From formula (7) it shows that attack probability is directly a function of block size and the number of blocks. --Martin From nobody Thu Apr 28 22:58:41 2016 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 7FEE812B008 for ; Thu, 28 Apr 2016 22:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQSLfmIi6p5s for ; Thu, 28 Apr 2016 22:58:38 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id CF04912B071 for ; Thu, 28 Apr 2016 22:58:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 713B76274; Fri, 29 Apr 2016 08:58:35 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id BV2GMulOm8z5; Fri, 29 Apr 2016 08:58:35 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 05F89285; Fri, 29 Apr 2016 08:58:35 +0300 (EEST) Date: Fri, 29 Apr 2016 08:58:31 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160429055831.GA16405@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160428193252.GA16096@LK-Perkele-V2.elisa-laajakaista.fi> <20160428214046.GB16096@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] #445: Enhanced New Session Ticket X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Apr 2016 05:58:40 -0000 On Thu, Apr 28, 2016 at 03:11:50PM -0700, Eric Rescorla wrote: > On Thu, Apr 28, 2016 at 2:40 PM, Ilari Liusvaara > wrote: > > > On Thu, Apr 28, 2016 at 01:43:41PM -0700, Eric Rescorla wrote: > > > On Thu, Apr 28, 2016 at 12:32 PM, Ilari Liusvaara < > > ilariliusvaara@welho.com> > > > wrote: > > > > > > > > > > - I presume 0-RTT used in retried ClientHello uses (and for the verify > > > > mechanism to work, that needs to be allowed!) uses ClientHello1... > > > > ClientHello2 as its base hash? > > > > > > > > > > I don't think I understand what you are asking. Can you rephrase. > > > > Client sends ClientHello with 0RTT data, gets HelloRetryRequest back and > > resends ClientHello. For hash continuation to work, the new ClientHello > > needs to contain the EarlyData extension, which would imply there is > > 0RTT data following that too. > > > > No, I don't think you need to have the extension. Either the server is > keeping > state and there's no problem or the server is offloading state in a cookie > (mechanism TBD) and in either case it just needs the state as of the > beginning of the new ClientHello. That enlarges the state that needs to be kept. If one keeps extensions, one only needs ~40 bytes. Whereas saving full hash state needs IIRC 114 bytes (SHA-256) or 228 bytes (SHA-384). And cookies are max. 255 bytes. And not many hash implementations support dumping and reloading state. > > > - Server can send CertificateRequest in GDHE-PSK or PSK mode??? > > > > > > > > > > Is there a reason that's undesirable? Note that it can always do > > > post-handshake > > > authentication, so we need to ensure that this is secure. My > > understanding > > > is > > > that because it covers the server's Finished, it therefore builds in the > > PSK > > > value (per the analyis from Scott et al.). Do you have a concern with > > this. > > > > Note that carelessly doing post-handshake auth can lead to nasty issues > > (fortunately it is not allowed for HTTP/2!). > > > > I expect that post-handshake client auth will be allowed for HTTP/2. Can you > elaborate on your concern. They will apparently use their own mechanism. The problem being that client and server end up being confused about authority the data is sent as, resulting exploitable security issues (avoiding this in HTTP/2 takes application-layer coordination). > And wonder what it would do to the handshake state machine to have the > > possibility of the CertificateRequest message (you need state machine to > > avoid all sorts of attacks). > > Well note that the EncryptedExtensions. EncryptedExtensions (or its "premessages") always follow ServerHello, so no problem there. I place CertificateRequest as "premessage" of server Certificate. But PSK and GDHE-PSK don't have server Certificate, so it would have to be "premessage" of server Finished. > > > - What are 'etc' for parameters for 0-RTT data? Use the present > > > > extension list here and have any future extensions that matter here > > > > explicitly define their interaction. > > > > > > > > > > The list is an example. The operative word is "all". > > > > And what is "all" with current extensions (defined as whatever is in > > registry currently + whatever TLS 1.3 base defines)? I think ciphersuite > > (apporiately transformed) and ALPN. Are there others? > > Yes, that's what I meant. So the 'etc' stands for "whatever will be defined by future extensions"? One might want to make that clearer. Also, things get screwy with SNI, and I think it is better not to try to use SNI with PSK. The rest besides ALPN and SNI looks to me those are either meaningless or should be taken anew. > > - You might want flag for if server promises replay protection or > > > > not in NST. > > > > > > > > > > We discussed this in BE and the consensus was that it was not clear how > > > the server implemented this and so it was unwise to promise it. > > > > You can replay-cache on ClientHello hash. > > > > Unfortunately this does not work perfectly in distributed systems, which is > the original > source of the concern. Well, by CAP theorem, since you need the "C" and "A", it impiles that you won't have "P". So implementing the guarantee is very difficult in any sort of distributed system. But that doesn't mean it is difficult in centralized system. (But then, it is infeasible to eliminate 0-RTT replay completely, so relying too much on replay-caching, even if known available is probably a bad idea). > > > [1] There are many extensions that are not relevant because those > > > > control server authentication (e.g. status_request, status_request_v2, > > > > signed_certificate_timestamp, server_certificate_type). And some that > > > > are low-level connection control (e.g. max_fragment_length) > > > > > > Yes, I am being conservative here because false positives don't seem like > > > they will happen a lot. > > > > False positives? Try implementation errors. > > > > Well, it seems like there are two concerns here re: implementation errors. > > 1. That servers will bungle this check and reject 0-RTT when they should > accept it [false positive] > 2. That servers will bungle this check and accept 0-RTT when they should > reject it (and that we'll be relying on that). > > Is your concern the first or the second? Well, first is only performance problem. The second can be safety problem, so yes, my concern is the second. > > ALPN is special here tho: It needs to match the impiled 0-RTT ALPN > > > > (does one want that extension in 0-RTT case anyway?). > > > > > > > > > > Yes, you absolutely need ALPN for early data. > > > > I mean do you need explicit indication, as opposed to taking the > > protocol the accepted 0-RTT data was for and not signaling it. > > > > Well, the current draft does not have explicit indication. All of the 0-RTT > context is tied to the ticket. I mean for the subsequent handshake. Since 0-RTT ALPN and connection ALPN needs to match, either: 1) Take the 0-RTT ALPN implicitly as connection ALPN. 2) Signal the same ALPN again, and have that client MUST check it matches and abort otherwise. -Ilari From nobody Thu Apr 28 23:52:11 2016 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 4229212D547 for ; Thu, 28 Apr 2016 23:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4sRhDDpoj5d for ; Thu, 28 Apr 2016 23:52:08 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C239212D535 for ; Thu, 28 Apr 2016 23:52:08 -0700 (PDT) Received: by mail-ig0-x22b.google.com with SMTP id u10so14073548igr.1 for ; Thu, 28 Apr 2016 23:52:08 -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; bh=a4NKjlZ+7F9ZQep4mbjiqRDMkCK1NiGoOU9+N/zcYJ4=; b=RQJtKLgp6sbIpaiW7drXssd4HYac7v7QJ2hm1RGZNq2nnzkW29yMOIrYuSG1EldZlm xuQ6r3jYKvPqwG2IqzUKjPE3w+q0/JRJDrGW0YeV8tXEGthIApvGLjbUbCTWYPuQxDd7 4DmMDQd9VHjuUe4MwFqwHWIlkJWUHr5UgoQI8I2LKF8IL8/q1b4DIuZH7knZQWBR6yOv bWQQIEmVrTI4PHuLt71gDe6e6JezV+GONmG/sP/xkQpUbN4bTBv3B4GWUk+0cYYV5T/2 FbvkiLbEGjEBDhtG/gnjjIqLFl2FvVolIzoAPkUINtXlhMS27zQOw239OYC64Q6fSULx usLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=a4NKjlZ+7F9ZQep4mbjiqRDMkCK1NiGoOU9+N/zcYJ4=; b=IpI9audPh7I+O5FzT2hn93lhXravaQYuksRYi+0Q8xZlVJ0g0Z3JJBV1x1I5IFuBza UtfOFmIYXLPdQtxxNcluAT53unCRrYxk+aWEZDfPMLDHULyBJ7cIhuMDSiUTL0NmVmBY 8YENLKEQ2TcRl1jI0lp8TtMY3TYkdIoDtddqN46k8LlsvGzORxZrg7gumyd3NdH15/lE U7WmBFpZSg2+VfGW7zq5SX8tezq+cA7breV+xkjO5q79hFad52guRN1V6l6qwm2H47cm saoTovxqnyhHeGi1p8yEwhRnez8h/rBOd8HTDT+w24GD/hDhLV0mnQiE8jdVV0MDj9ZE Cfkw== X-Gm-Message-State: AOPr4FVxv56XgEaFwJwts1nMswljxfgNcEmegQ5wzM8h4eUHhY7czPRuCRjrumt7/BWclc/IE8XYmKuHwSqKiA== MIME-Version: 1.0 X-Received: by 10.50.111.15 with SMTP id ie15mr2554903igb.94.1461912728178; Thu, 28 Apr 2016 23:52:08 -0700 (PDT) Received: by 10.36.43.82 with HTTP; Thu, 28 Apr 2016 23:52:08 -0700 (PDT) In-Reply-To: <20160429055831.GA16405@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160428193252.GA16096@LK-Perkele-V2.elisa-laajakaista.fi> <20160428214046.GB16096@LK-Perkele-V2.elisa-laajakaista.fi> <20160429055831.GA16405@LK-Perkele-V2.elisa-laajakaista.fi> Date: Fri, 29 Apr 2016 16:52:08 +1000 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] #445: Enhanced New Session Ticket X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Apr 2016 06:52:10 -0000 On 29 April 2016 at 15:58, Ilari Liusvaara wrote: >> [HRR state] > > That enlarges the state that needs to be kept. If one keeps extensions, > one only needs ~40 bytes. Whereas saving full hash state needs IIRC 114 > bytes (SHA-256) or 228 bytes (SHA-384). And cookies are max. 255 bytes. Cookies are as yet undefined, but I would imagine that these would be just the same size as the pre-shared-key identity for all the same reasons. > And not many hash implementations support dumping and reloading state. What would you prefer? We could specify some very strict rules about what changes a client can make to their ClientHello so that the server can simply store things that might change (like the early_data extension, which will disappear on the second attempt, and whether a key share was needed, and so forth). >> [client auth] > > The problem being that > client and server end up being confused about authority the data is sent > as, resulting exploitable security issues (avoiding this in HTTP/2 takes > application-layer coordination). The confused deputy problem, yes. That's a "feature" that we have to retain, so I don't see much point bellyaching over it. That said, we can (and are) improving things in HTTP/2. >> [extension checking on resumption] > > So the 'etc' stands for "whatever will be defined by future extensions"? > One might want to make that clearer. > > Also, things get screwy with SNI, and I think it is better not to try to > use SNI with PSK. The primary function of SNI is routing. Remove it and stuff breaks. Thus, I would say include it, but make sure it doesn't result in a change in configuration. The simplest thing to do is reject PSK if the old SNI != the new SNI. > The rest besides ALPN and SNI looks to me those are either meaningless > or should be taken anew. That is probably true for a lot of them. But we can't say that for certain. For instance, when we defined EMS, which is irrelevant here, it was important that it be present when resuming or bad things happened. I'm not suggesting that exact thing will happen again, but we can't presume that we won't need this. > I mean for the subsequent handshake. Since 0-RTT ALPN and connection > ALPN needs to match, either: > > 1) Take the 0-RTT ALPN implicitly as connection ALPN. > 2) Signal the same ALPN again, and have that client MUST check it matches > and abort otherwise. I believe that we have to do the latter. Since we can't be sure that the server knows the ALPN from before if it has to reject 0-RTT. My plan for this is: 1. store ALPN in the ticket/session 2. if doing 0-RTT, before accepting 0-RTT data, perform the normal ALPN negotiation 3. check the negotiated ALPN with the stored value, and if they don't match reject the 0-RTT data Note that this means that clients will have to deal with having to change protocols when 0-RTT data is rejected. But I don't see any other way to do this. This also assumes that TLS session resumption is not carrying over application state in addition to TLS state. I believe that is reasonable, though it's worth stating. From nobody Fri Apr 29 08:35:47 2016 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 0A20112D0A7 for ; Fri, 29 Apr 2016 08:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeNJXS1NRTuX for ; Fri, 29 Apr 2016 08:35:42 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6640D12B062 for ; Fri, 29 Apr 2016 08:35:42 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id B381DD4B8C615; Fri, 29 Apr 2016 15:35:37 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u3TFZdfT019091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Apr 2016 15:35:40 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u3TFZcWo025697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Apr 2016 17:35:39 +0200 Received: from FR712WXCHMBA13.zeu.alcatel-lucent.com ([169.254.5.182]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 29 Apr 2016 17:35:39 +0200 From: "Guballa, Jens (Nokia - DE)" To: EXT Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] Review of draft-guballa-tls-terminology-03 Thread-Index: AQHRn+OajlsB1fq5YkaB5/d7nIrDGp+fYaGA Date: Fri, 29 Apr 2016 15:35:38 +0000 Message-ID: <547EE95EB794FD4DB8062F7A4C86D0BC4A442FEA@FR712WXCHMBA13.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02F3_01D1A23D.8A8DAB20" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Review of draft-guballa-tls-terminology-03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Apr 2016 15:35:46 -0000 ------=_NextPart_000_02F3_01D1A23D.8A8DAB20 Content-Type: multipart/alternative; boundary="----=_NextPart_001_02F4_01D1A23D.8A8DAB20" ------=_NextPart_001_02F4_01D1A23D.8A8DAB20 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Eric, =20 See below. =20 From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of EXT Eric Rescorla Sent: Dienstag, 26. April 2016 19:46 To: tls@ietf.org Subject: [TLS] Review of draft-guballa-tls-terminology-03 =20 I recently reviewed draft-guballa-tls-terminology-03. Comments below. =20 OVERALL I'm sympathetic to concerns that TLS terminology may not be as precise as one would like, but IMO this document doesn't make things = significantly clearer and in some cases makes it worse. Specifically: =20 - (D)TLS is intentionally defined without any tight binding to the = underlying transport. However, this document tries to tie it to IP semantics, = which is not helpful and doesn't match existing practice. [JG] I don=E2=80=99t think this is consistently true for all (D)TLS = related RFCs. E.g. from RFC5764 (DTLS-SRTP), section 3: =E2=80=9CA = single DTLS-SRTP session only protects data carried over a single UDP = source and destination port pair.=E2=80=9D=20 The terminology draft has been based on the existing (D)TLS RFC = landscape so far and thus intends to represent a status quo. I quite = agree that this needs to be revised, given new technologies like WebRTC = and =E2=80=9CDTLS over ICE=E2=80=9D. =20 - This document introduces a number of terms that don't exist in the = (D)TLS documents (e.g., "Transient (D)TLS session"). This is just going to = cause confusion. [JG] The intended rationale behind those terms: A hierarchical = information model has been created first, and the terms defined = represent that hierarchy. So even if those terms are not directly used = in RFCs they are essential from information model persepctive. =20 In general, I don't think that having a second document that acts as a glossary for (D)TLS but isn't part of the main documents is going to = help much. If the authors feel like the terminology in TLS is imprecise, it would be more helpful to suggest changes to TLS 1.3 (e.g., via PRs). =20 =20 DETAILED COMENTS S 3.1.1. There's no restriction on TLS that a given endpoint is attached to one IP address, and in fact, it's common to run DTLS in multihomed configs (e.g., DTLS over ICE). =20 S 3.2.1. Again, (D)TLS isn't bound to the port or IP. =20 S 3.2.2. This whole notion of semi-permanent versus transient isn't helpful, especially in the face of tickets. [JG] The terminology is reflecting the lifetime of a session and is by = intention independent on how session resumption is performed (tickets or = via base TLS RFC).=20 =20 S 3.2.2. This is just a new invented term. Please don't =20 S 3.3.1. Destruction point doesn't seem useful since in many cases it's "unknown" since it's in the future [JG] That=E2=80=99s a good catch, thanks! =20 =20 S 3.3.4. In DTLS you can respond to a ClientHello with a HelloVerifyRequest as well. [JG] Again, good catch. =20 S 3.4.4. "message sequence" seems invented. =20 S 3.4.7. I don't think it's helpful to import ITU notions of connection state = here, especially in the face of stuff like false start. [JG] I see your point, the states are separated in Rx and Tx direction.=20 =20 S 3.4.12. Copying the session state here doesn't seem that useful, especially = splitting it into two states. [JG] I see your point for repeating the session state in the draft. But = I think the server_address at the client side differentiates both = objects. =20 Thanks, Jens ------=_NextPart_001_02F4_01D1A23D.8A8DAB20 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Eric,

 

See below.

 

From:<= /b> = TLS [mailto:tls-bounces@ietf.org] On Behalf Of EXT Eric = Rescorla
Sent: Dienstag, 26. April 2016 19:46
To: = tls@ietf.org
Subject: [TLS] Review of = draft-guballa-tls-terminology-03

 

I = recently reviewed draft-guballa-tls-terminology-03. Comments = below.

 

OVERALL

I'm sympathetic to concerns that TLS terminology may = not be as precise

as one = would like, but IMO this document doesn't make things = significantly

clearer and = in some cases makes it worse. Specifically:

 

- = (D)TLS is intentionally defined without any tight binding to the = underlying

  = transport. However, this document tries to tie it to IP semantics, = which

  is not = helpful and doesn't match existing practice.

[JG] I don=E2=80=99t think this is consistently true for all (D)TLS = related RFCs. E.g. from RFC5764 (DTLS-SRTP), section 3: =E2=80=9CA = single DTLS-SRTP session only protects data carried over a single UDP = source and destination port pair.=E2=80=9D =

The terminology draft has been based on the existing (D)TLS RFC = landscape so far and thus intends to represent a status quo. I quite = agree that this needs to be revised, given new technologies like WebRTC = and =E2=80=9CDTLS over = ICE=E2=80=9D.

 

- = This document introduces a number of terms that don't exist in the = (D)TLS

  documents = (e.g., "Transient (D)TLS session"). This is just going to = cause

  = confusion.

[JG] The intended rationale behind those terms: A hierarchical = information model has been created first, and the terms defined = represent that hierarchy. So even if those terms are not directly used = in RFCs they are essential from information model = persepctive.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0

In general, I = don't think that having a second document that acts = as

a glossary for (D)TLS = but isn't part of the main documents is going to = help

much. If the authors = feel like the terminology in TLS is imprecise, = it

would be more helpful = to suggest changes to TLS 1.3 (e.g., via = PRs).

 

 

DETAILED COMENTS

S 3.1.1.

There's no restriction on TLS that a given endpoint is = attached

to one IP = address, and in fact, it's common to run DTLS = in

multihomed configs = (e.g., DTLS over ICE).

 

S = 3.2.1.

Again, (D)TLS isn't = bound to the port or IP.

 

S = 3.2.2.

This whole notion = of semi-permanent versus transient isn't = helpful,

especially in the = face of tickets.

[JG] The terminology is reflecting the lifetime of a session and is by = intention independent on how session resumption is performed (tickets or = via base TLS RFC).

 

S = 3.2.2.

This is just a new = invented term. Please don't

 

S = 3.3.1.

Destruction point = doesn't seem useful since in many cases it's = "unknown"

since = it's in the future

[JG] That=E2=80=99s a good catch, = thanks!

 

 

S = 3.3.4.

In DTLS you can = respond to a ClientHello with a HelloVerifyRequest = as

well.

[JG] Again, good catch.

 

S = 3.4.4.

"message = sequence" seems invented.

 

S = 3.4.7.

I don't think it's = helpful to import ITU notions of connection state = here,

especially in the = face of stuff like false start.

[JG] I see your point, the states are separated in Rx and Tx direction. =

 

S = 3.4.12.

Copying the = session state here doesn't seem that useful, especially = splitting

it into two = states.

[JG] I see your point for repeating the session state in the draft. But = I think the server_address at the client side differentiates both = objects.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0

Thanks,

Jens

------=_NextPart_001_02F4_01D1A23D.8A8DAB20-- ------=_NextPart_000_02F3_01D1A23D.8A8DAB20 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/DCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr 4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0 ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3 dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93 d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy 7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6 /XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYjCCBkqgAwIBAgIKE1mSVAAAAADt+zANBgkq hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDI0MDYyNDM5WhcNMTcwNDIz MDYyNDM5WjBCMRAwDgYDVQQDEwdsdnBzYWFlMS4wLAYJKoZIhvcNAQkBFh9qZW5zLmd1YmFsbGFA YWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuZZTGrNK 9hSyYEI9w2lnABbWQBeU1DyJ9jX33JSOfgMGYaQ0ZZZFRwX5vDIgj499CxaWmpImbQTxdYa/vxpS U7SfqtYF7B2AB2irUYdCu/GGjTqHaXmPyyktPaiEOgR7AOz8oXxUdaECsKmTBANOpkE1J6yA3KPJ Yxde3h5bTqnjxvJB5IJhr9rIvcf5V3v6ZyW0MHOkDXn20xjEDJVMVdhhjlnwM4WmUiA/SNq7IiQ8 elmivF5NuEK9mwZEXqkR6aXHVcgPc1fuMxwsxJbdfdmMyIDV62kSTVlb/iXNJDByQJ/GRnuYHCFA qIld1HgdJCpECl+ohveGLG46CvD6iwIDAQABo4IEFDCCBBAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIhb3FWYPjsTmHpYEqhr/DQoWUmBmBC/nmTIT9tVoCAWQCAQUwHwYDVR0lBBgwFgYKKwYB BAGCNwoDBAYIKwYBBQUHAwQwCwYDVR0PBAQDAgWgMCkGCSsGAQQBgjcVCgQcMBowDAYKKwYBBAGC NwoDBDAKBggrBgEFBQcDBDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG 9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFPUv0vuw2MQvQ81rxR/PDOlK po4KMB8GA1UdIwQYMBaAFNnsa72WWCL32KZ3zf5Nge+6l70SMIIBXQYDVR0fBIIBVDCCAVAwggFM oIIBSKCCAUSGgdlsZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQlMjBJbnRlcm5hbCUyMFN1YiUy MENBLENOPXVzbmF2c3BraTAzcCxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1sdWFkLERDPWx1Y2VudCxEQz1jb20/Y2VydGlm aWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50 hixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNybIY4aHR0cDovL3Nl cnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmwwggFhBggrBgEF BQcBAQSCAVMwggFPMIHMBggrBgEFBQcwAoaBv2xkYXA6Ly8vQ049QWxjYXRlbCUyMEx1Y2VudCUy MEludGVybmFsJTIwU3ViJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NBQ2Vy dGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDgGCCsGAQUF BzAChixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNydDBEBggrBgEF BQcwAoY4aHR0cDovL3NlcnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJD QS5jcnQwKgYDVR0RBCMwIYEfamVucy5ndWJhbGxhQGFsY2F0ZWwtbHVjZW50LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAXRHvujXQqqJMH1wCrG+0UrRv0v7CpjhIyuLwJ5XDhTj9JcKsYLpWREi/zXhN Sy6TC61uUKLrAuX0uXAXW0zsBYgPDFkq481gTgdxG/brcg8lXF8Xm787ixPR8Mp8j80ZHZ5OnA1k +Xuw/QPsE4wp8RZrjqvoJQpSXtXPdX3+XBE0VsANBYszCWfrR0ByI4hZ9Saoc26umYnOY8sU0UZ/ 1XnEcRfUmVWRxTydYAFdTtOHRjBn3V7TZnfeGYpKSxrqdh6nTqk0FR832p8Z8RyNjEv3qdaX9BK7 jsjQgGNH0gxWPf+wARDdk5abnalyChTjv8B70KeLOYbsrF0greiw3TGCBCkwggQlAgEBMIGUMIGF MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPy LGQBGRYEbmEwMjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVj ZW50IEludGVybmFsIFN1YiBDQQIKE1mSVAAAAADt+zAJBgUrDgMCGgUAoIICaTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA0MjkxNTM1MzdaMCMGCSqGSIb3DQEJ BDEWBBSPl1jyENEPdaNBY6RxSMUnRnaUKzCBpQYJKwYBBAGCNxAEMYGXMIGUMIGFMRMwEQYKCZIm iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy bmFsIFN1YiBDQQIKE1mSVAAAAADt+zCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYUxEzARBgoJkiaJ k/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJkiaJk/IsZAEZFgRuYTAy MRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRlbCBMdWNlbnQgSW50ZXJu YWwgU3ViIENBAgoTWZJUAAAAAO37MIG3BgkqhkiG9w0BCQ8xgakwgaYwCwYJYIZIAWUDBAEqMAsG CWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsO AwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzAL BglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBACuS 4SP32Xcf8GkBbXGVBMl6Kp6yQ8dSQEiyy9Yjf/6V+fQ5cYTOSHXSN3GD5I8ZJ36wQ6SF+3hexKqi 9nIU51X2uTT215OlVNFMYGENV5ez1Uvvn3e3fmT977+mzpc4qW1DrvzFBJSmNMSRMwtVHt7JC2Xc 7B48VmxPyZEwl97kSvSEntFngAaFm46dMJGmEui6WzvTDOtMKbsbfPc7Zji9VPtGQ6WyEWCs2YGi QrLrVguGwE0gAoh5wHWfObkMG8788MOu+F9aYFB51MGQChwcntzMER8CZxi0/UOS0fjudrZdkN4J O9GBuHG9wO5lN6Hr7pwHhai1Cd1/6TD0IIoAAAAAAAA= ------=_NextPart_000_02F3_01D1A23D.8A8DAB20-- From nobody Fri Apr 29 08:38:41 2016 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 33A6E12B03A for ; Fri, 29 Apr 2016 08:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AETzAP04J0Vv for ; Fri, 29 Apr 2016 08:38:37 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4059B12B02C for ; Fri, 29 Apr 2016 08:38:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id D1CE25680; Fri, 29 Apr 2016 18:38:35 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id rInaiSnLEBNd; Fri, 29 Apr 2016 18:38:35 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 644242310; Fri, 29 Apr 2016 18:38:35 +0300 (EEST) Date: Fri, 29 Apr 2016 18:38:31 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20160429153831.GA16797@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160428193252.GA16096@LK-Perkele-V2.elisa-laajakaista.fi> <20160428214046.GB16096@LK-Perkele-V2.elisa-laajakaista.fi> <20160429055831.GA16405@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] #445: Enhanced New Session Ticket X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Apr 2016 15:38:40 -0000 On Fri, Apr 29, 2016 at 04:52:08PM +1000, Martin Thomson wrote: > On 29 April 2016 at 15:58, Ilari Liusvaara wrote: > >> [HRR state] > > > > That enlarges the state that needs to be kept. If one keeps extensions, > > one only needs ~40 bytes. Whereas saving full hash state needs IIRC 114 > > bytes (SHA-256) or 228 bytes (SHA-384). And cookies are max. 255 bytes. > > Cookies are as yet undefined, but I would imagine that these would be > just the same size as the pre-shared-key identity for all the same > reasons. Well, this is about the size one needs for the required state. > > And not many hash implementations support dumping and reloading state. > > What would you prefer? We could specify some very strict rules about > what changes a client can make to their ClientHello so that the server > can simply store things that might change (like the early_data > extension, which will disappear on the second attempt, and whether a > key share was needed, and so forth). That ~40 bytes (IIRC, it was actually 37) was done by exploiting every- thing I could out of the rules in WIP #344 and relied on EDI being preserved. EDI looks like rather sizable structure currently (even after compressing the configuration_id by obvious means). > >> [extension checking on resumption] > > > > So the 'etc' stands for "whatever will be defined by future extensions"? > > One might want to make that clearer. > > > > Also, things get screwy with SNI, and I think it is better not to try to > > use SNI with PSK. > > The primary function of SNI is routing. Remove it and stuff breaks. > Thus, I would say include it, but make sure it doesn't result in a > change in configuration. The simplest thing to do is reject PSK if > the old SNI != the new SNI. That kind of non-obvious stuff really needs to be included. They way it is right now written, I think very few TLS stacks are going to get it right. > > The rest besides ALPN and SNI looks to me those are either meaningless > > or should be taken anew. > > That is probably true for a lot of them. But we can't say that for > certain. For instance, when we defined EMS, which is irrelevant here, > it was important that it be present when resuming or bad things > happened. I'm not suggesting that exact thing will happen again, but > we can't presume that we won't need this. My point is: Future extensions can give their rules, TLS 1.3 spec needs to give rules about present ones. > > I mean for the subsequent handshake. Since 0-RTT ALPN and connection > > ALPN needs to match, either: > > > > 1) Take the 0-RTT ALPN implicitly as connection ALPN. > > 2) Signal the same ALPN again, and have that client MUST check it matches > > and abort otherwise. > > I believe that we have to do the latter. Since we can't be sure that > the server knows the ALPN from before if it has to reject 0-RTT. My > plan for this is: > > 1. store ALPN in the ticket/session > 2. if doing 0-RTT, before accepting 0-RTT data, perform the normal > ALPN negotiation > 3. check the negotiated ALPN with the stored value, and if they don't > match reject the 0-RTT data 4. If 0-RTT is accepted, client checks the ALPN server sent and compares it with value it impiled. If those don't match, the client MUST abort. 1) would be: 1. store ALPN in the ticket/session 2. if doing 0-RTT, before accepting 0-RTT data, check if the 0-RTT ALPN is acceptable. If it isn't, reject 0-RTT. 3. If 0-RTT was rejected, select new ALPN, signal it in Encrypted Extensions. That would make ALPN and EDI mutually exclusive in EncryptedExtensions. > Note that this means that clients will have to deal with having to > change protocols when 0-RTT data is rejected. But I don't see any > other way to do this. Well, the applications obviously have to be able to deal with the protocol possibly changing. > This also assumes that TLS session resumption is not carrying over > application state in addition to TLS state. I believe that is > reasonable, though it's worth stating. Well, any state they can't recover. -Ilari From nobody Fri Apr 29 08:43:04 2016 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 0FA5312B039 for ; Fri, 29 Apr 2016 08:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSfpkjf_kART for ; Fri, 29 Apr 2016 08:43:00 -0700 (PDT) Received: from cavuit02.kulnet.kuleuven.be (rhcavuit02.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D585412B02C for ; Fri, 29 Apr 2016 08:42:59 -0700 (PDT) X-KULeuven-Envelope-From: atul.luykx@esat.kuleuven.be X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: 635F812827D.A23D3 X-KULeuven-Information: Katholieke Universiteit Leuven Received: from icts-p-smtps-1.cc.kuleuven.be (icts-p-smtps-1e.kulnet.kuleuven.be [134.58.240.33]) by cavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id 635F812827D; Fri, 29 Apr 2016 17:42:57 +0200 (CEST) Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by icts-p-smtps-1.cc.kuleuven.be (Postfix) with ESMTP id 6126E40AC; Fri, 29 Apr 2016 17:42:54 +0200 (CEST) Received: from cobalt.esat.kuleuven.be (cobalt.esat.kuleuven.be [134.58.56.187]) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id 5CC5A6002E; Fri, 29 Apr 2016 17:42:54 +0200 (CEST) Received: from webmail.esat.kuleuven.be (localhost [127.0.0.1]) by cobalt.esat.kuleuven.be (Postfix) with ESMTP id 59E6040; Fri, 29 Apr 2016 17:42:54 +0200 (CEST) Received: from marckloff.esat.kuleuven.be ([10.33.137.112]) by webmail.esat.kuleuven.be with HTTP (HTTP/1.1 POST); Fri, 29 Apr 2016 17:42:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 29 Apr 2016 17:42:54 +0200 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Atul Luykx To: Martin Thomson In-Reply-To: References: <78f6d6778c608a99e276c2efa561d2ab@esat.kuleuven.be> Message-ID: X-Sender: aluykx@esat.kuleuven.be User-Agent: ESAT webmail service, powered by Roundcube X-Virus-Scanned: clamav-milter 0.99 at cobalt X-Virus-Status: Clean Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Data Volume Limits Analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Apr 2016 15:43:02 -0000 Hey Martin, You're right, this analysis works for any block cipher with 128 bit output that is "good enough" (a pseudorandom permutation), and so for all versions of AES regardless of the key size. Determining the appropriate key size for the block cipher relies on accounting for possible attacks against the block cipher itself, and estimating the computational power of the adversaries you want to protect against. You could also use formula (7) to recompute the bounds with a different block size (e.g. 64 bits). Atul On 2016-04-29 05:40, Martin Thomson wrote: > On 9 March 2016 at 09:16, aluykx wrote: >> Kenny Paterson and I prepared a document providing an overview of how >> much >> data ChaCha20+Poly1305 and AES-GCM can process with a single key. >> Besides >> summarizing the results, the document also gives an explanation of why >> the >> limits are there. The document confirms the analysis done by Watson >> and >> others in the thread on "Data Volume Limits", but goes into more >> detail. > > Hi Atul, > > Just to confirm, but this analysis is for all variants of AES-GCM > regardless of key size? From formula (7) it shows that attack > probability is directly a function of block size and the number of > blocks. > > --Martin From nobody Fri Apr 29 09:16:51 2016 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 E72BB12D186 for ; Fri, 29 Apr 2016 09:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gqRe5NxW9kD for ; Fri, 29 Apr 2016 09:16:47 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A20ED12D0B8 for ; Fri, 29 Apr 2016 09:16:47 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id g133so174489076ywb.2 for ; Fri, 29 Apr 2016 09:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=m/UmRWIxYpSiieneeVF0K6kBmAi/PKSpc7Dfi6zZz/k=; b=jWeYP1If3c+0FHolW+C+oYqbfwsCIBZYvyNqX2FUJmbnZxQhutCd0iREbdZZ1tLqjU VzLLNISzLu36aEvRnVPolBobNKrrmARXfup3eQAxmyKg96QIps7vfQwGdeIjnU60Dte1 /QpyrdVyU+Y5wW1z3f0PbV9AzKxdEhboG8PJvdr2sx7a6PnH0MedA39bs8MqrcJtJqP2 yw5m5tFIrp+FQ6vban9GskBMdbVfx3ibuFEWILiE/hM9jmuUIWjiBaAF34K+84rz4i22 7hPjjgFzZjJBjNHxagHxtiBGbpkOk73jta5zqlJ5ZqnntPOMS1LXI9GevhAj2VbBI30g ++UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=m/UmRWIxYpSiieneeVF0K6kBmAi/PKSpc7Dfi6zZz/k=; b=X0j4pA1tHokaJaoiB+UhjBEQoqVtHVn2an9ELPQDrphIx1OKSkk346c43bKCJKWYcP Exb1lCsXrmhQSUf8d6D8Vs8X/VYF0xFHthYVueiQrA0bzxyI0TcGNgqYMC01D7E4FbM2 OMjfq50l7v7+utN8Q1Pv+jZARMi5U1WW+Z0qnqm0eecVHcDRGwAUwxSwJeYYmJ8wb1KE nXM4nLC4rzsdoG6GBjg6MzFthJG/bXIeqtuinxnpHi6hbk0G0ix2/NjxEKx7nS51vddQ J3s9GYhVihlwohOOP3Nc/XdoXmlA+lqpqz/zePinfRoHSuOICTklTkvGSvJoCwdonuHQ 6v2w== X-Gm-Message-State: AOPr4FXgjUw3+PkIo5EJ1cgnr+INwWb9pIokU+bqPL7G+b81f9HsG+r4qmRj5FeTBUfSk0yRyT6H/euTDCaWPw== X-Received: by 10.129.163.146 with SMTP id a140mr5109142ywh.254.1461946606853; Fri, 29 Apr 2016 09:16:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Fri, 29 Apr 2016 09:16:07 -0700 (PDT) In-Reply-To: <20160429153831.GA16797@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160428193252.GA16096@LK-Perkele-V2.elisa-laajakaista.fi> <20160428214046.GB16096@LK-Perkele-V2.elisa-laajakaista.fi> <20160429055831.GA16405@LK-Perkele-V2.elisa-laajakaista.fi> <20160429153831.GA16797@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Fri, 29 Apr 2016 09:16:07 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c1287ee2ed19e0531a1f821 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] #445: Enhanced New Session Ticket X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Apr 2016 16:16:50 -0000 --94eb2c1287ee2ed19e0531a1f821 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 29, 2016 at 8:38 AM, Ilari Liusvaara wrote: > On Fri, Apr 29, 2016 at 04:52:08PM +1000, Martin Thomson wrote: > > On 29 April 2016 at 15:58, Ilari Liusvaara > wrote: > > >> [HRR state] > > > > > > That enlarges the state that needs to be kept. If one keeps extensions, > > > one only needs ~40 bytes. Whereas saving full hash state needs IIRC 114 > > > bytes (SHA-256) or 228 bytes (SHA-384). And cookies are max. 255 bytes. > > > > Cookies are as yet undefined, but I would imagine that these would be > > just the same size as the pre-shared-key identity for all the same > > reasons. > > Well, this is about the size one needs for the required state. > > > > And not many hash implementations support dumping and reloading state. > > > > What would you prefer? We could specify some very strict rules about > > what changes a client can make to their ClientHello so that the server > > can simply store things that might change (like the early_data > > extension, which will disappear on the second attempt, and whether a > > key share was needed, and so forth). > > That ~40 bytes (IIRC, it was actually 37) was done by exploiting every- > thing I could out of the rules in WIP #344 and relied on EDI being > preserved. > > EDI looks like rather sizable structure currently (even after compressing > the configuration_id by obvious means). > Are you looking at a different document than I am: EDI currently is: struct { select (Role) { case client: opaque context<0..255>; case server: struct {}; } } EarlyDataIndication; And the context is basically a placeholder. > >> [extension checking on resumption] > > > > > > So the 'etc' stands for "whatever will be defined by future > extensions"? > > > One might want to make that clearer. > > > > > > Also, things get screwy with SNI, and I think it is better not to try > to > > > use SNI with PSK. > > > > The primary function of SNI is routing. Remove it and stuff breaks. > > Thus, I would say include it, but make sure it doesn't result in a > > change in configuration. The simplest thing to do is reject PSK if > > the old SNI != the new SNI. > > That kind of non-obvious stuff really needs to be included. > > They way it is right now written, I think very few TLS stacks are going > to get it right. > Proposed text would be welcome here. > > I mean for the subsequent handshake. Since 0-RTT ALPN and connection > > > ALPN needs to match, either: > > > > > > 1) Take the 0-RTT ALPN implicitly as connection ALPN. > > > 2) Signal the same ALPN again, and have that client MUST check it > matches > > > and abort otherwise. > > > > I believe that we have to do the latter. Since we can't be sure that > > the server knows the ALPN from before if it has to reject 0-RTT. My > > plan for this is: > > > > 1. store ALPN in the ticket/session > > 2. if doing 0-RTT, before accepting 0-RTT data, perform the normal > > ALPN negotiation > > 3. check the negotiated ALPN with the stored value, and if they don't > > match reject the 0-RTT data > > 4. If 0-RTT is accepted, client checks the ALPN server sent and > compares it with value it impiled. If those don't match, the client > MUST abort. > > > 1) would be: > > 1. store ALPN in the ticket/session > 2. if doing 0-RTT, before accepting 0-RTT data, check if the 0-RTT > ALPN is acceptable. If it isn't, reject 0-RTT. > 3. If 0-RTT was rejected, select new ALPN, signal it in Encrypted > Extensions. > > That would make ALPN and EDI mutually exclusive in EncryptedExtensions. > This doesn't seem awesome from the client's perspective. I'm trying to make the ordinary PSK-resumption design less of a special case. -Ekr > > Note that this means that clients will have to deal with having to > > change protocols when 0-RTT data is rejected. But I don't see any > > other way to do this. > > Well, the applications obviously have to be able to deal with the > protocol possibly changing. > > > > This also assumes that TLS session resumption is not carrying over > > application state in addition to TLS state. I believe that is > > reasonable, though it's worth stating. > > Well, any state they can't recover. > > > -Ilari > --94eb2c1287ee2ed19e0531a1f821 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 29, 2016 at 8:38 AM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On F= ri, Apr 29, 2016 at 04:52:08PM +1000, Martin Thomson wrote:
> On 29 April 2016 at 15:58, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> >> [HRR state]
> >
> > That enlarges the state that needs to be kept. If one keeps exten= sions,
> > one only needs ~40 bytes. Whereas saving full hash state needs II= RC 114
> > bytes (SHA-256) or 228 bytes (SHA-384). And cookies are max. 255 = bytes.
>
> Cookies are as yet undefined, but I would imagine that these would be<= br> > just the same size as the pre-shared-key identity for all the same
> reasons.

Well, this is about the size one needs for the required state.

> > And not many hash implementations support dumping and reloading s= tate.
>
> What would you prefer?=C2=A0 We could specify some very strict rules a= bout
> what changes a client can make to their ClientHello so that the server=
> can simply store things that might change (like the early_data
> extension, which will disappear on the second attempt, and whether a > key share was needed, and so forth).

That ~40 bytes (IIRC, it was actually 37) was done by exploiting eve= ry-
thing I could out of the rules in WIP #344 and relied on EDI being
preserved.

EDI looks like rather sizable structure currently (even after compressing the configuration_id by obvious means).

Are you looking at a different document than I am: EDI currently is:
=

=C2=A0 =C2=A0 =C2=A0 =C2=A0struct {
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0select (Role) {
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case client:
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque contex= t<0..255>;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0case server:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 struct {};
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0} EarlyDataI= ndication;

And the context is basically a pl= aceholder.



> >> [extension checking on resumption]
> >
> > So the 'etc' stands for "whatever will be defined by= future extensions"?
> > One might want to make that clearer.
> >
> > Also, things get screwy with SNI, and I think it is better not to= try to
> > use SNI with PSK.
>
> The primary function of SNI is routing.=C2=A0 Remove it and stuff brea= ks.
> Thus, I would say include it, but make sure it doesn't result in a=
> change in configuration.=C2=A0 The simplest thing to do is reject PSK = if
> the old SNI !=3D the new SNI.

That kind of non-obvious stuff really needs to be included.

They way it is right now written, I think very few TLS stacks are going
to get it right.

Proposed text would be= welcome here.


> > I mean for the subsequent handshake. Since 0-RTT ALPN and connect= ion
> > ALPN needs to match, either:
> >
> > 1) Take the 0-RTT ALPN implicitly as connection ALPN.
> > 2) Signal the same ALPN again, and have that client MUST check it= matches
> >=C2=A0 =C2=A0 and abort otherwise.
>
> I believe that we have to do the latter.=C2=A0 Since we can't be s= ure that
> the server knows the ALPN from before if it has to reject 0-RTT.=C2=A0= My
> plan for this is:
>
> 1. store ALPN in the ticket/session
> 2. if doing 0-RTT, before accepting 0-RTT data, perform the normal
> ALPN negotiation
> 3. check the negotiated ALPN with the stored value, and if they don= 9;t
> match reject the 0-RTT data

4. If 0-RTT is accepted, client checks the ALPN server sent and
compares it with value it impiled. If those don't match, the client
MUST abort.


1) would be:

1. store ALPN in the ticket/session
2. if doing 0-RTT, before accepting 0-RTT data, check if the 0-RTT =C2=A0 =C2=A0ALPN is acceptable. If it isn't, reject 0-RTT.
3. If 0-RTT was rejected, select new ALPN, signal it in Encrypted
=C2=A0 =C2=A0Extensions.

That would make ALPN and EDI mutually exclusive in EncryptedExtensions.
=

This doesn't seem awesome from the cli= ent's perspective. I'm trying to make
the ordinary PSK-re= sumption design less of a special case.

-Ekr
=


=C2=A0
> Note that this means that clients will have to deal with having to
> change protocols when 0-RTT data is rejected.=C2=A0 But I don't se= e any
> other way to do this.

Well, the applications obviously have to be able to deal with the protocol possibly changing.

=C2=A0

> This also assumes that TLS session resumption is not carrying over
> application state in addition to TLS state.=C2=A0 I believe that is > reasonable, though it's worth stating.

Well, any state they can't recover.


-Ilari

--94eb2c1287ee2ed19e0531a1f821-- From nobody Fri Apr 29 09:21:19 2016 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 1E17312D1AD for ; Fri, 29 Apr 2016 09:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z70JaaGa2Yo5 for ; Fri, 29 Apr 2016 09:21:16 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EB7112D186 for ; Fri, 29 Apr 2016 09:21:16 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id j74so174740244ywg.1 for ; Fri, 29 Apr 2016 09:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nMDe19he4b9MBU2kd/jtFiIJcUrT+5thgkj/itSGUJE=; b=LqTOsjE1AgUuA6mZfbXqxvhHToof6zIj4GljcKD9tvTLgpA1TIx1A+MWkuu+pE3lPA DaM7DaTx4OBb9LlZngCfSYoeqVkRmqjGr1rWObKRnGGkSJgVfDvSbxjzOr+qxmbNUo6v vr7TATlyNEFjNeUgGZUTr9vIDtFYbUrv3jlEW6kqrC34Zztu6Rb0VFj9nP/xQi3RLMeS hAY2TuZftWCvpC2d+7+6q1ldlcQO2n33MoYd+ckwda8MOoPxw/m6c15bHvm+oxyucZwh XHeCWHsqc+4SGciiyDEaaYrPf3Q1iY9GzpORRriBQ1B6YVmYQLaY8CccjJ7wDV+NQXtp y1Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nMDe19he4b9MBU2kd/jtFiIJcUrT+5thgkj/itSGUJE=; b=ZP7V4Ul9pdZWWBI9N1UsUUvmoxCM+cGMq6T3GFjwC2DZ4NKOUPy3CR40Jl0DDqqoUn CV2EsGfpYtnorombijUdwL7eUzZC7aj7MSj9I9zdBw1ZY3cTpDBTaEYYXVPZOTP7doLh qYeTJDqjg3uX2z036PQptI8ZEwbeHFqsLJiQeQTOpfM8AUo0L0N8Z30pBm4K210hST8V rCYIhLPaFTlZEXHO3mBmx5JkCApF1kQWv91fuQ3sZurn1iQTaXv+E12+gLnMtaaax5wp DeVbljRJPphIxfKYS4pijevTj+OU0DuU6tUSoWPiVlG5TUvHL2NdPFbBs9g82YFhE3J3 FiTg== X-Gm-Message-State: AOPr4FUGCueAh0dXcNj5+oBe2D1B43M7mLGgxaS9b+cy7Z8LwkTHLKGIK99vxxc90Q3hGbp7PPrM3RNufltHkw== X-Received: by 10.129.46.193 with SMTP id u184mr11620828ywu.180.1461946875558; Fri, 29 Apr 2016 09:21:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Fri, 29 Apr 2016 09:20:36 -0700 (PDT) In-Reply-To: <547EE95EB794FD4DB8062F7A4C86D0BC4A442FEA@FR712WXCHMBA13.zeu.alcatel-lucent.com> References: <547EE95EB794FD4DB8062F7A4C86D0BC4A442FEA@FR712WXCHMBA13.zeu.alcatel-lucent.com> From: Eric Rescorla Date: Fri, 29 Apr 2016 09:20:36 -0700 Message-ID: To: "Guballa, Jens (Nokia - DE)" Content-Type: multipart/alternative; boundary=001a11408a1c32f6f10531a208d1 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Review of draft-guballa-tls-terminology-03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Apr 2016 16:21:18 -0000 --001a11408a1c32f6f10531a208d1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 29, 2016 at 8:35 AM, Guballa, Jens (Nokia - DE) < jens.guballa@nokia.com> wrote: > Hi Eric, > > > > See below. > > > > *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *EXT Eric Rescorl= a > *Sent:* Dienstag, 26. April 2016 19:46 > *To:* tls@ietf.org > *Subject:* [TLS] Review of draft-guballa-tls-terminology-03 > > > > I recently reviewed draft-guballa-tls-terminology-03. Comments below. > > > > OVERALL > > I'm sympathetic to concerns that TLS terminology may not be as precise > > as one would like, but IMO this document doesn't make things significantl= y > > clearer and in some cases makes it worse. Specifically: > > > > - (D)TLS is intentionally defined without any tight binding to the > underlying > > transport. However, this document tries to tie it to IP semantics, whic= h > > is not helpful and doesn't match existing practice. > > *[JG] I don=E2=80=99t think this is consistently true for all (D)TLS rela= ted RFCs. > E.g. from RFC5764 (DTLS-SRTP), section 3: =E2=80=9CA single DTLS-SRTP ses= sion only > protects data carried over a single UDP source and destination port pair.= =E2=80=9D * > > *The terminology draft has been based on the existing (D)TLS RFC landscap= e > so far and thus intends to represent a status quo. I quite agree that thi= s > needs to be revised, given new technologies like WebRTC and =E2=80=9CDTLS= over > ICE=E2=80=9D.* > Well, this isn't a DTLS requirement, at most it's a 5764 requirement, but even then, it's not something we're maintaining. > - This document introduces a number of terms that don't exist in the (D)T= LS > > documents (e.g., "Transient (D)TLS session"). This is just going to cau= se > > confusion. > > *[JG] The intended rationale behind those terms: A hierarchical > information model has been created first, and the terms defined represent > that hierarchy. So even if those terms are not directly used in RFCs they > are essential from information model persepctive.* > Yeah, I'm not finding it helpful for comprehension. > > In general, I don't think that having a second document that acts as > > a glossary for (D)TLS but isn't part of the main documents is going to he= lp > > much. If the authors feel like the terminology in TLS is imprecise, it > > would be more helpful to suggest changes to TLS 1.3 (e.g., via PRs). > > > > > > DETAILED COMENTS > > S 3.1.1. > > There's no restriction on TLS that a given endpoint is attached > > to one IP address, and in fact, it's common to run DTLS in > > multihomed configs (e.g., DTLS over ICE). > > > > S 3.2.1. > > Again, (D)TLS isn't bound to the port or IP. > > > > S 3.2.2. > > This whole notion of semi-permanent versus transient isn't helpful, > > especially in the face of tickets. > > *[JG] The terminology is reflecting the lifetime of a session and is by > intention independent on how session resumption is performed (tickets or > via base TLS RFC). * > > > > S 3.2.2. > > This is just a new invented term. Please don't > > > > S 3.3.1. > > Destruction point doesn't seem useful since in many cases it's "unknown" > > since it's in the future > > *[JG] That=E2=80=99s a good catch, thanks!* > > > > > > S 3.3.4. > > In DTLS you can respond to a ClientHello with a HelloVerifyRequest as > > well. > > *[JG] Again, good catch.* > > > > S 3.4.4. > > "message sequence" seems invented. > > > > S 3.4.7. > > I don't think it's helpful to import ITU notions of connection state here= , > > especially in the face of stuff like false start. > > *[JG] I see your point, the states are separated in Rx and Tx direction. = * > > > > S 3.4.12. > > Copying the session state here doesn't seem that useful, especially > splitting > > it into two states. > > *[JG] I see your point for repeating the session state in the draft. But = I > think the server_address at the client side differentiates both objects.* > But this isn't a TLS concept. -Ekr > > *Thanks,* > > *Jens* > --001a11408a1c32f6f10531a208d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a11408a1c32f6f10531a208d1-- From nobody Fri Apr 29 10:46:52 2016 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 2444812D6BA for ; Fri, 29 Apr 2016 10:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5LEhsgg9h6u for ; Fri, 29 Apr 2016 10:46:49 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 958B212D185 for ; Fri, 29 Apr 2016 10:46:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id AF0715D3A; Fri, 29 Apr 2016 20:46:47 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 4sXUcg8pfeoe; Fri, 29 Apr 2016 20:46:47 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 500212313; Fri, 29 Apr 2016 20:46:47 +0300 (EEST) Date: Fri, 29 Apr 2016 20:46:43 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160429174643.GA17765@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160428193252.GA16096@LK-Perkele-V2.elisa-laajakaista.fi> <20160428214046.GB16096@LK-Perkele-V2.elisa-laajakaista.fi> <20160429055831.GA16405@LK-Perkele-V2.elisa-laajakaista.fi> <20160429153831.GA16797@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] #445: Enhanced New Session Ticket X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Apr 2016 17:46:51 -0000 On Fri, Apr 29, 2016 at 09:16:07AM -0700, Eric Rescorla wrote: > On Fri, Apr 29, 2016 at 8:38 AM, Ilari Liusvaara > wrote: > > > On Fri, Apr 29, 2016 at 04:52:08PM +1000, Martin Thomson wrote: > > > On 29 April 2016 at 15:58, Ilari Liusvaara > > wrote: > > > > EDI looks like rather sizable structure currently (even after compressing > > the configuration_id by obvious means). > > > > Are you looking at a different document than I am: EDI currently is: > > struct { > select (Role) { > case client: > opaque context<0..255>; > > case server: > struct {}; > } > } EarlyDataIndication; > > And the context is basically a placeholder. Ah, I didn't see a PR about it and then looked at Editor's Copy. Clearly a different document. > > >> [extension checking on resumption] > > > > > > > > So the 'etc' stands for "whatever will be defined by future > > extensions"? > > > > One might want to make that clearer. > > > > > > > > Also, things get screwy with SNI, and I think it is better not to try > > to > > > > use SNI with PSK. > > > > > > The primary function of SNI is routing. Remove it and stuff breaks. > > > Thus, I would say include it, but make sure it doesn't result in a > > > change in configuration. The simplest thing to do is reject PSK if > > > the old SNI != the new SNI. > > > > That kind of non-obvious stuff really needs to be included. > > > > They way it is right now written, I think very few TLS stacks are going > > to get it right. > > > > Proposed text would be welcome here. Well, the more I think about this, the messier things about interaction between SNI, "static" PSKs and "dynamic" PSKs seem to be... And unlike ALPN, where problems only appear in context of 0-RTT, now you also get the issues without 0-RTT: > > > I mean for the subsequent handshake. Since 0-RTT ALPN and connection > > > > ALPN needs to match, either: > > > > > > > > 1) Take the 0-RTT ALPN implicitly as connection ALPN. > > > > 2) Signal the same ALPN again, and have that client MUST check it > > matches > > > > and abort otherwise. > > > > > > I believe that we have to do the latter. Since we can't be sure that > > > the server knows the ALPN from before if it has to reject 0-RTT. My > > > plan for this is: > > > > > > 1. store ALPN in the ticket/session > > > 2. if doing 0-RTT, before accepting 0-RTT data, perform the normal > > > ALPN negotiation > > > 3. check the negotiated ALPN with the stored value, and if they don't > > > match reject the 0-RTT data > > > > 4. If 0-RTT is accepted, client checks the ALPN server sent and > > compares it with value it impiled. If those don't match, the client > > MUST abort. > > > > > > 1) would be: > > > > 1. store ALPN in the ticket/session > > 2. if doing 0-RTT, before accepting 0-RTT data, check if the 0-RTT > > ALPN is acceptable. If it isn't, reject 0-RTT. > > 3. If 0-RTT was rejected, select new ALPN, signal it in Encrypted > > Extensions. > > > > That would make ALPN and EDI mutually exclusive in EncryptedExtensions. > > > > This doesn't seem awesome from the client's perspective. I'm trying to make > the ordinary PSK-resumption design less of a special case. Well, the client needs to keep track of the ALP anyway. If for nothing else, to check that the server isn't trying to do anything crazy. I think it is easier for the client just to imply the ALP in presence of accepted 0-RTT. -Ilari From nobody Fri Apr 29 11:33:45 2016 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 BBED212D519 for ; Fri, 29 Apr 2016 11:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmDxrh-Et59u for ; Fri, 29 Apr 2016 11:33:41 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id C5EA712D4FD for ; Fri, 29 Apr 2016 11:33:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id B0A9053C3; Fri, 29 Apr 2016 21:33:35 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id 2kPw_WylR4mm; Fri, 29 Apr 2016 21:33:35 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 72CEA286; Fri, 29 Apr 2016 21:33:35 +0300 (EEST) Date: Fri, 29 Apr 2016 21:33:32 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160429183332.GB17765@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160428193252.GA16096@LK-Perkele-V2.elisa-laajakaista.fi> <20160428214046.GB16096@LK-Perkele-V2.elisa-laajakaista.fi> <20160429055831.GA16405@LK-Perkele-V2.elisa-laajakaista.fi> <20160429153831.GA16797@LK-Perkele-V2.elisa-laajakaista.fi> <20160429174643.GA17765@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] #445: Enhanced New Session Ticket X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Apr 2016 18:33:44 -0000 On Fri, Apr 29, 2016 at 11:30:02AM -0700, Eric Rescorla wrote: > On Fri, Apr 29, 2016 at 10:46 AM, Ilari Liusvaara > wrote: > > > > > > This doesn't seem awesome from the client's perspective. I'm trying to > > make > > > the ordinary PSK-resumption design less of a special case. > > > > Well, the client needs to keep track of the ALP anyway. If for nothing > > else, to check that the server isn't trying to do anything crazy. > > > > I don't see why that's true in the absence of 0-RTt. There's no reason why > the > server shouldn't be able to select any ALPN offers the client provides > regardless > of the original offer.. I mean in case where 0-RTT was accepted. Otherwise normal ALPN negotiation can take place (and by existing definition of ALPN, has to). -Ilari From nobody Fri Apr 29 11:37:34 2016 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 72E6F12D6EB for ; Fri, 29 Apr 2016 11:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhHoLI8HpkjP for ; Fri, 29 Apr 2016 11:37:31 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3826A12D6E6 for ; Fri, 29 Apr 2016 11:30:42 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id t10so205708796ywa.0 for ; Fri, 29 Apr 2016 11:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OqtUOw8otbHklIpTGnzipD/DxMAtWbsyfp1E2YdU+P4=; b=kCaZ2v71PojI/qxledvYriURTiAmg2Ek3ipj8XQ9dAry8PHCC7AbKvD1+X7oUy1J4K 63IbpINJOh2qHzXSYzqCE3hHGEWp3l7//nNON5nY+xi53fLVhr6vZro4F0n0X7SH2Bwt k/GNSZJBpLeSDcJ3y6LA+ayN2Q6svZy6vxRx3A2rxPJ7PSo51rPsHUWRxXs97rH6xkXp qfTaPD4Br/DBpk6gKelza8CzFQpTETKhAQ9y1o7krNfxF5wgl2VxElWuKKTWh9meyis5 WxcsAjCqR0YxKupiNRc7EqbYZi72eAwBUl8OVLRgWSlGyX8A8IcVKm9V6c1Z1HGNs6rh CrRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OqtUOw8otbHklIpTGnzipD/DxMAtWbsyfp1E2YdU+P4=; b=TRQCLkzA6LRUC/NytdtXeNZCA+UEXD4yYBxK3aH2nDjFnLRhibUUWQtfCdo7m9wLTU 0sxNDIV+DWivBsOLL194/wfOJcd0xq8moO5qZgDWIknn6S4fhWNxzH8v3EwVK3zZvSqo Rxw86lMDgh34gnIbJBkllrt1DWl2rlryTjmEMDHHTHSGLEqYSBWZMggmnpDtUvemOapT Y2ZSXFBfk9Ykkx8WMlsIoBpus9twsFxvWOXJSegQxMdubaa8TeWRGzGRuZDnEPLXZZUG SoC2yBBXM7lwHM5u+TEP+CqJE/eWLjPvE5TS/QKUmnsura1imz8K3XS8sjwbTJly3Bd/ gMOA== X-Gm-Message-State: AOPr4FV4nTccGXDKiZYZYGX9lDQT71R3DQoSUVyJFFoiu16NDMAX4FwK31nEKWFdFPBiMjPIwhz0XmD53qTfLQ== X-Received: by 10.13.237.1 with SMTP id w1mr12122324ywe.62.1461954641506; Fri, 29 Apr 2016 11:30:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Fri, 29 Apr 2016 11:30:02 -0700 (PDT) In-Reply-To: <20160429174643.GA17765@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160428193252.GA16096@LK-Perkele-V2.elisa-laajakaista.fi> <20160428214046.GB16096@LK-Perkele-V2.elisa-laajakaista.fi> <20160429055831.GA16405@LK-Perkele-V2.elisa-laajakaista.fi> <20160429153831.GA16797@LK-Perkele-V2.elisa-laajakaista.fi> <20160429174643.GA17765@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Fri, 29 Apr 2016 11:30:02 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c0864a815ebb20531a3d74e Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] #445: Enhanced New Session Ticket X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 29 Apr 2016 18:37:32 -0000 --94eb2c0864a815ebb20531a3d74e Content-Type: text/plain; charset=UTF-8 On Fri, Apr 29, 2016 at 10:46 AM, Ilari Liusvaara wrote: > On Fri, Apr 29, 2016 at 09:16:07AM -0700, Eric Rescorla wrote: > > On Fri, Apr 29, 2016 at 8:38 AM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > > On Fri, Apr 29, 2016 at 04:52:08PM +1000, Martin Thomson wrote: > > > > On 29 April 2016 at 15:58, Ilari Liusvaara > > > > wrote: > > > > > > EDI looks like rather sizable structure currently (even after > compressing > > > the configuration_id by obvious means). > > > > > > > Are you looking at a different document than I am: EDI currently is: > > > > struct { > > select (Role) { > > case client: > > opaque context<0..255>; > > > > case server: > > struct {}; > > } > > } EarlyDataIndication; > > > > And the context is basically a placeholder. > > Ah, I didn't see a PR about it and then looked at Editor's Copy. > Clearly a different document. > Yes, 445 builds on 444. > > > Proposed text would be welcome here. > > Well, the more I think about this, the messier things about interaction > between SNI, "static" PSKs and "dynamic" PSKs seem to be... > > And unlike ALPN, where problems only appear in context of 0-RTT, now you > also get the issues without 0-RTT: > > > > > I mean for the subsequent handshake. Since 0-RTT ALPN and connection > > > > > ALPN needs to match, either: > > > > > > > > > > 1) Take the 0-RTT ALPN implicitly as connection ALPN. > > > > > 2) Signal the same ALPN again, and have that client MUST check it > > > matches > > > > > and abort otherwise. > > > > > > > > I believe that we have to do the latter. Since we can't be sure that > > > > the server knows the ALPN from before if it has to reject 0-RTT. My > > > > plan for this is: > > > > > > > > 1. store ALPN in the ticket/session > > > > 2. if doing 0-RTT, before accepting 0-RTT data, perform the normal > > > > ALPN negotiation > > > > 3. check the negotiated ALPN with the stored value, and if they don't > > > > match reject the 0-RTT data > > > > > > 4. If 0-RTT is accepted, client checks the ALPN server sent and > > > compares it with value it impiled. If those don't match, the client > > > MUST abort. > > > > > > > > > 1) would be: > > > > > > 1. store ALPN in the ticket/session > > > 2. if doing 0-RTT, before accepting 0-RTT data, check if the 0-RTT > > > ALPN is acceptable. If it isn't, reject 0-RTT. > > > 3. If 0-RTT was rejected, select new ALPN, signal it in Encrypted > > > Extensions. > > > > > > That would make ALPN and EDI mutually exclusive in EncryptedExtensions. > > > > > > > This doesn't seem awesome from the client's perspective. I'm trying to > make > > the ordinary PSK-resumption design less of a special case. > > Well, the client needs to keep track of the ALP anyway. If for nothing > else, to check that the server isn't trying to do anything crazy. > I don't see why that's true in the absence of 0-RTt. There's no reason why the server shouldn't be able to select any ALPN offers the client provides regardless of the original offer.. -Ekr > > I think it is easier for the client just to imply the ALP in presence of > accepted 0-RTT. > > > -Ilari > --94eb2c0864a815ebb20531a3d74e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 29, 2016 at 10:46 AM, Ilari Liusvaara <= ;ilariliusvaa= ra@welho.com> wrote:
On Fri, Apr 29, 2016 at 09:16:07AM -0700, Eric Rescorla wrote: > On Fri, Apr 29, 2016 at 8:38 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> > On Fri, Apr 29, 2016 at 04:52:08PM +1000, Martin Thomson wrote: > > > On 29 April 2016 at 15:58, Ilari Liusvaara <ilariliusvaara@welho.com>
> > wrote:
> >
> > EDI looks like rather sizable structure c= urrently (even after compressing
> > the configuration_id by obvious means).
> >
>
> Are you looking at a different document than I am: EDI currently is: >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 select (Role) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case client: >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 o= paque context<0..255>;
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case server: >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0st= ruct {};
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 } EarlyDataIndication;
>
> And the context is basically a placeholder.

Ah, I didn't see a PR about it and then looked at Editor's C= opy.
Clearly a different document.

Yes, 445 = builds on 444.


>
> Proposed text would be welcome here.

Well, the more I think about this, the messier things about interact= ion
between SNI, "static" PSKs and "dynamic" PSKs seem to b= e...

And unlike ALPN, where problems only appear in context of 0-RTT, now you also get the issues without 0-RTT:

> > > I mean for the subsequent handshake. Since 0-RTT ALPN and co= nnection
> > > > ALPN needs to match, either:
> > > >
> > > > 1) Take the 0-RTT ALPN implicitly as connection ALPN. > > > > 2) Signal the same ALPN again, and have that client MUS= T check it
> > matches
> > > >=C2=A0 =C2=A0 and abort otherwise.
> > >
> > > I believe that we have to do the latter.=C2=A0 Since we can&= #39;t be sure that
> > > the server knows the ALPN from before if it has to reject 0-= RTT.=C2=A0 My
> > > plan for this is:
> > >
> > > 1. store ALPN in the ticket/session
> > > 2. if doing 0-RTT, before accepting 0-RTT data, perform the = normal
> > > ALPN negotiation
> > > 3. check the negotiated ALPN with the stored value, and if t= hey don't
> > > match reject the 0-RTT data
> >
> > 4. If 0-RTT is accepted, client checks the ALPN server sent and > > compares it with value it impiled. If those don't match, the = client
> > MUST abort.
> >
> >
> > 1) would be:
> >
> > 1. store ALPN in the ticket/session
> > 2. if doing 0-RTT, before accepting 0-RTT data, check if the 0-RT= T
> >=C2=A0 =C2=A0 ALPN is acceptable. If it isn't, reject 0-RTT. > > 3. If 0-RTT was rejected, select new ALPN, signal it in Encrypted=
> >=C2=A0 =C2=A0 Extensions.
> >
> > That would make ALPN and EDI mutually exclusive in EncryptedExten= sions.
> >
>
> This doesn't seem awesome from the client's perspective. I'= ;m trying to make
> the ordinary PSK-resumption design less of a special case.

Well, the client needs to keep track of the ALP anyway. If for = nothing
else, to check that the server isn't trying to do anything crazy.

I don't see why that's true in the a= bsence of 0-RTt. There's no reason why the
server shouldn'= ;t be able to select any ALPN offers the client provides regardless
of the original offer..

-Ekr

=C2=A0

I think it is easier for the client just to imply the ALP in presence of accepted 0-RTT.


-Ilari

--94eb2c0864a815ebb20531a3d74e--


On Fri, Apr 29, 2016 at 8:35 AM, Guballa, Jens (Nokia - DE) <je= ns.guballa@nokia.com> wrote:

Hi Eric,

=C2=A0

= See below.

=C2=A0

= From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of EXT Eric Rescor= la
Sent: Dienstag, 26. April 2016 19:46
To: tls@ietf.org
Subject: = [TLS] Review of draft-guballa-tls-terminology-03

=C2=A0

<= p class=3D"MsoNormal">I recently reviewed draft-guballa-tls-terminology-03.= Comments below.

<= u>=C2=A0

OVERALL<= /u>

I'm sympathetic to concerns th= at TLS terminology may not be as precise

as one would like, but IMO this document doesn't make = things significantly

cle= arer and in some cases makes it worse. Specifically:

=C2=A0

- (D)TLS is intentionally defined without any tight binding to = the underlying

=C2=A0 tr= ansport. However, this document tries to tie it to IP semantics, which

=C2=A0 is not h= elpful and doesn't match existing practice.

[JG] I don=E2=80=99t think this is= consistently true for all (D)TLS related RFCs. E.g. from RFC5764 (DTLS-SRT= P), section 3: =E2=80=9CA single DTLS-SRTP session only protects data carri= ed over a single UDP source and destination port pair.=E2=80=9D <= /u>

The termi= nology draft has been based on the existing (D)TLS RFC landscape so far and= thus intends to represent a status quo. I quite agree that this needs to b= e revised, given new technologies like WebRTC and =E2=80=9CDTLS over ICE=E2= =80=9D.

<= br>
Well, this isn't a DTLS requirement, at most it's a 5= 764 requirement, but even then,
it's not something we're = maintaining.

=C2=A0
<= div>

- T= his document introduces a number of terms that don't exist in the (D)TL= S

=C2=A0 documents (e.g.= , "Transient (D)TLS session"). This is just going to cause=

=C2=A0 confusion.

[JG] The intended r= ationale behind those terms: A hierarchical information model has been crea= ted first, and the terms defined represent that hierarchy. So even if those= terms are not directly used in RFCs they are essential from information mo= del persepctive.


=
Yeah, I'm not finding it helpful for comprehension.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

In general, I don't think that having a second document that= acts as

a glossary for = (D)TLS but isn't part of the main documents is going to help<= /u>

much. If the authors feel like the= terminology in TLS is imprecise, it

would be more helpful to suggest changes to TLS 1.3 (e.g., v= ia PRs).

=C2=A0

=C2=A0

DETAILED COMENTS

S 3.1.1.

There's no restriction on TLS that a given endpoint is attached<= /u>

to one IP address, and in f= act, it's common to run DTLS in

multihomed configs (e.g., DTLS over ICE).

= =C2=A0

S 3.2.1.

Again, (D)TLS isn't bound to the po= rt or IP.

=C2=A0<= u>

S 3.2.2.

This whole notion of semi-permanent versus tra= nsient isn't helpful,

especially in the face of tickets.

<= p class=3D"MsoNormal">[JG] The terminology is reflecti= ng the lifetime of a session and is by intention independent on how session= resumption is performed (tickets or via base TLS RFC).

=C2=A0<= /p>

S 3.2.2.

<= p class=3D"MsoNormal">This is just a new invented term. Please don't=

=C2=A0

S 3.3.1.

Destruction point doesn't seem useful since in many ca= ses it's "unknown"

<= p class=3D"MsoNormal">since it's in the future

=

[JG] That=E2=80=99s a good catc= h, thanks!

= =C2=A0

=C2=A0

S 3.3.4.

In DTLS you can respond to a ClientHello with a He= lloVerifyRequest as

well.

[JG] = Again, good catch.

=C2=A0

S= 3.4.4.

"message se= quence" seems invented.

=C2=A0

S 3.4.7.<= /u>

I don't think it's = helpful to import ITU notions of connection state here,

especially in the face of stuf= f like false start.

[JG] I see your point, the states are separated in Rx and Tx d= irection.

= =C2=A0

S 3.4.12.

Copying the session state here d= oesn't seem that useful, especially splitting

it into two states.

[JG] I see your point for= repeating the session state in the draft. But I think the server_address a= t the client side differentiates both objects.


But this isn't a TLS concept.<= /div>

-Ekr

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

Thanks,=

Jens