X-List-Received-Date: Tue, 25 Aug 2015 13:54:11 -0000 --001a1135d69273720b051e231117 Content-Type: text/plain; charset=UTF-8 Sorry for having missed the discussions so far. This has probably already been discussed to death... I am worried there will be bugs, such as sending a Token Binding Message header when cookies have been disabled by the user. I've just started reading about cookie policy, and so far, it seems insanely complex. Some browsers might block third party cookies, or cookies to particular third party domains that are advertisers known to track users. Should we send our Token Binding ID in this case? A simple way to insure we are not leaking user information might be to check that the Token Binding Message is only sent if the cookie header is present. If the browser is blocking cookies for some reason, I suspect we should also block Token Binding Messages. Are there good use-cases for the Token Binding Message when there is no cookie present? As for HTTP2 compression, this would only result in increased traffic when the cookie policy changes. In general, if we do 50 requests to a web site, we send the same cookies 50 times. In that case, we'd also send the Token Binding Message header 50 times. Is it rare to change to sending cookies, and then not, to the same domain. I read that Yahoo and Google recommend having separate static content domains so that when loading static content, the browser does not bother sending any cookies. This makes page loading faster. In this case, we could also slightly speed things up over HTTP by not sending any Token Binding Message header. What do you think? Bill --001a1135d69273720b051e231117 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Sorry for having missed the discussions so far.=C2=A0= This has probably already been discussed to death...

I= am worried there will be bugs, such as sending a Token Binding Message hea= der when cookies have been disabled by the user.=C2=A0 I've just starte= d reading about cookie policy, and so far, it seems insanely complex.=C2=A0= Some browsers might block third party cookies, or cookies to particular th= ird party domains that are advertisers known to track users.=C2=A0 Should w= e send our Token Binding ID in this case?

A simple way t= o insure we are not leaking user information might be to check that the Tok= en Binding Message is only sent if the cookie header is present.=C2=A0 If t= he browser is blocking cookies for some reason, I suspect we should also bl= ock Token Binding Messages.=C2=A0 Are there good use-cases for the Token Bi= nding Message when there is no cookie present?

As = for HTTP2 compression, this would only result in increased traffic when the= cookie policy changes.=C2=A0 In general, if we do 50 requests to a web sit= e, we send the same cookies 50 times.=C2=A0 In that case, we'd also sen= d the Token Binding Message header 50 times.=C2=A0 Is it rare to change to = sending cookies, and then not, to the same domain.

I read that Yahoo and Google recommend having separate static content doma= ins so that when loading static content, the browser does not bother sendin= g any cookies.=C2=A0 This makes page loading faster.=C2=A0 In this case, we= could also slightly speed things up over HTTP by not sending any Token Bin= ding Message header.

What do you think?

Bill

--001a1135d69273720b051e231117-- From nobody Tue Aug 25 08:20:51 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0321B2FF7 for ; Tue, 25 Aug 2015 08:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANIOM-Opm19Z for ; Tue, 25 Aug 2015 08:20:48 -0700 (PDT) Received: from mail-qk0-f178.google.com (mail-qk0-f178.google.com [209.85.220.178]) (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 B93291B2FDF for ; Tue, 25 Aug 2015 08:20:48 -0700 (PDT) Received: by qkbm65 with SMTP id m65so101904150qkb.2 for ; Tue, 25 Aug 2015 08:20:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=sSBHmLl+VECuryj2EUomhzB3YO9sUdBuLCNDUVVX5EI=; b=OjO/8Yo2Awkfww6jBBaOGlQoGtDhTDRxOyvhGuRdHfy0K/pu4PlM/BC4yphDGrT8k0 gA9iE13ML4TszvSxRpQ68C8gKGNHlHKfXRQsgGbLhmVb/NDIzbU0+uuzWcXFBafCFxDR ALnEXkDwbQolSFYa2EZSVgJtJ1wmT2XHD9dZsHXR2+u/3pMF/Hq4JJYhdLD2QM4ErCFF 7iIF+aDBb9YakoY42l+rtssoIwBHvcziVGs3WvUMIB2ESuB1jz0LYXsE2y+A47jx2Tsi UdkUnTjZ4Jtzub3pEZsonyVXsgiTR08q6GJ6xj9MbzZezOaZvhzknicAkJcPzRqG2HgH fjWg== X-Gm-Message-State: ALoCoQlm02IbKBu9Ytf4lw20ULTD7olCKdQAcAPBs4tDISqcZ1JqUU6tGqzxcHXWYzFbaks9vkON X-Received: by 10.55.198.9 with SMTP id b9mr33583666qkj.97.1440516047815; Tue, 25 Aug 2015 08:20:47 -0700 (PDT) Received: from [192.168.1.216] (186-106-169-204.baf.movistar.cl. [186.106.169.204]) by smtp.gmail.com with ESMTPSA id k32sm11899190qkh.39.2015.08.25.08.20.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Aug 2015 08:20:47 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_DC46826E-297F-438A-9A3C-ED16D88F4AED"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: Date: Tue, 25 Aug 2015 12:20:37 -0300 Message-Id: <6F09B2F6-C6C3-4F78-944D-D4F341B9B746@ve7jtb.com> References: To: Bill Cox X-Mailer: Apple Mail (2.2104) Archived-At: Cc: unbearable@ietf.org Subject: Re: [Unbearable] Should we only send Token Binding Message when sending cookies? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 15:20:50 -0000 --Apple-Mail=_DC46826E-297F-438A-9A3C-ED16D88F4AED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Token Binding may also be used to protect redirect based messages like = OpenID Connect and SAML. So while I would expect both a IdP and SP to = be setting cookies under normal circumstances, not every token protected = by token binding is a cookie. Interesting observations though. John B. > On Aug 25, 2015, at 10:54 AM, Bill Cox wrote: >=20 > Sorry for having missed the discussions so far. This has probably = already been discussed to death... >=20 > I am worried there will be bugs, such as sending a Token Binding = Message header when cookies have been disabled by the user. I've just = started reading about cookie policy, and so far, it seems insanely = complex. Some browsers might block third party cookies, or cookies to = particular third party domains that are advertisers known to track = users. Should we send our Token Binding ID in this case? >=20 > A simple way to insure we are not leaking user information might be to = check that the Token Binding Message is only sent if the cookie header = is present. If the browser is blocking cookies for some reason, I = suspect we should also block Token Binding Messages. Are there good = use-cases for the Token Binding Message when there is no cookie present? >=20 > As for HTTP2 compression, this would only result in increased traffic = when the cookie policy changes. In general, if we do 50 requests to a = web site, we send the same cookies 50 times. In that case, we'd also = send the Token Binding Message header 50 times. Is it rare to change to = sending cookies, and then not, to the same domain. >=20 > I read that Yahoo and Google recommend having separate static content = domains so that when loading static content, the browser does not bother = sending any cookies. This makes page loading faster. In this case, we = could also slightly speed things up over HTTP by not sending any Token = Binding Message header. >=20 > What do you think? >=20 > Bill > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable --Apple-Mail=_DC46826E-297F-438A-9A3C-ED16D88F4AED Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTA4MjUxNTIwMzdaMCMGCSqGSIb3DQEJBDEWBBT+hmRsNOV8Af5kyQvTrqnK RjQ9CzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBFI2YGw8PY8qLyb2X1cGPAyQom9DW8Z+KSqGWJg4s2tCRi3jTwnr2+ G/Hd9yedAWYFAlRM5Id3M9rinR57oJSVlBhL0zN6Jz0iyuMYRXqTBc7vCnCkmMSL0rIasJxdQp6w ZnlzBysouirzQgyV3tHShkEzMxnUVf189OfOn7WeXC2gm6zv+zCJEy74sl1yggnbp8n1TZ/y/+Ob 20GwnAzkiCAlKjzBhqp5Y4kKiJi8xyMVAvhHHltI+mN9t5xxnJWUSP2hypJCkdW0KYKOSPpWQIGN WksooGurrQWo0diz3psJRRDpe+u2BOiD4MKkpjuBHgSH+MT3lphY4PeMvhlOAAAAAAAA --Apple-Mail=_DC46826E-297F-438A-9A3C-ED16D88F4AED-- From nobody Tue Aug 25 09:30:28 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463191A079D for ; Tue, 25 Aug 2015 09:30:24 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UoNqEJXIxUf for ; Tue, 25 Aug 2015 09:30:22 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0116.outbound.protection.outlook.com [207.46.100.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 534CF1A0385 for ; Tue, 25 Aug 2015 09:30:05 -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=jAzdemHp2awCVE4AQScAnneGkhnf2timBvPEoEbL9bA=; b=b/S2HaiWCokT5tD4px3FGVOs2SD6WNBr21uiiqrJW36U3nR5kakmmDBt8wujYQmShllzxiiGdx6i+X3aaAwLt51GskEUyYayWjL63M+Rdvyq7PJUhhJlcR6cPuKK4pD9CCDRr5MfajNrceeHpJGCZ1PL2Q4W6rXOYt+VloLoMuU= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1393.namprd03.prod.outlook.com (10.163.81.14) with Microsoft SMTP Server (TLS) id 15.1.231.21; Tue, 25 Aug 2015 16:30:04 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0231.024; Tue, 25 Aug 2015 16:30:04 +0000 From: Andrei Popov To: John Bradley , Bill Cox Thread-Topic: [Unbearable] Should we only send Token Binding Message when sending cookies? Thread-Index: AQHQ30milh09kL7jF029bU5i8WKfq54c5ldw Date: Tue, 25 Aug 2015 16:30:04 +0000 Message-ID: References: <6F09B2F6-C6C3-4F78-944D-D4F341B9B746@ve7jtb.com> In-Reply-To: <6F09B2F6-C6C3-4F78-944D-D4F341B9B746@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:4::1d2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1393; 5:gwfukMvSmLsI40YMEEn1rAychkp0ejoMi3jNJ18Dz8Ym5CaENaH/xh4xe1n98g8/E4amk2NwhdqWOYngqmAlDv3HOffs87OpJQSu9FiKpZ6jDIAMXW0Qxt9Ejzw6/2mnaIPYhPt26fWdM9CneF7AIw==; 24:u0DK11XQFZwOEBbDrWuhyq3YEjKkIZ44SWQvddw+WjTShDDmfZsZjtjNal/TopK7GKsAIbiUbXHTQJDkz95DOUQ+5RMVsKCiZowQNe35l/o=; 20:O6deHd4ScNe3xfPVEJ6fKXkLk0yJyCeTi1AZltiZEb0ct4ixcgrOgTTscrnxlqOOj66DLj3VXSSlPJPLKdYcmw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1393; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(8121501046)(5005006)(3002001); SRVR:BLUPR03MB1393; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; x-forefront-prvs: 06793E740F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(76104003)(377454003)(189002)(199003)(102836002)(19580395003)(122556002)(5001770100001)(40100003)(50986999)(106356001)(99286002)(76176999)(189998001)(5001830100001)(5004730100002)(4001540100001)(68736005)(97736004)(54356999)(106116001)(5001860100001)(62966003)(77096005)(81156007)(86612001)(2900100001)(76576001)(87936001)(77156002)(5002640100001)(5003600100002)(5001920100001)(15975445007)(2656002)(19580405001)(105586002)(33656002)(64706001)(86362001)(101416001)(5005710100001)(46102003)(2950100001)(92566002)(5007970100001)(5001960100002)(10290500002)(10090500001)(8990500004)(10400500002)(74316001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1393; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) 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: 25 Aug 2015 16:30:04.1963 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1393 Archived-At: Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] Should we only send Token Binding Message when sending cookies? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 16:30:24 -0000 Token Binding messages are encapsulated in the application protocol and han= dled at the application protocol layer, therefore it seems feasible to only= send them when needed. There has been a separate discussion about removing the requirement that th= e Provided binding is sent in the very first application_data payload after= TB has been negotiated. Perhaps we can combine both ideas and say that the application MUST send To= ken Binding messages whenever it is requesting or supplying tokens? Cheers, Andrei -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of John Bra= dley Sent: Tuesday, August 25, 2015 8:21 AM To: Bill Cox Cc: unbearable@ietf.org Subject: Re: [Unbearable] Should we only send Token Binding Message when se= nding cookies? Token Binding may also be used to protect redirect based messages like Open= ID Connect and SAML. So while I would expect both a IdP and SP to be setti= ng cookies under normal circumstances, not every token protected by token b= inding is a cookie. Interesting observations though. John B. > On Aug 25, 2015, at 10:54 AM, Bill Cox wrote: >=20 > Sorry for having missed the discussions so far. This has probably alread= y been discussed to death... >=20 > I am worried there will be bugs, such as sending a Token Binding Message = header when cookies have been disabled by the user. I've just started read= ing about cookie policy, and so far, it seems insanely complex. Some brows= ers might block third party cookies, or cookies to particular third party d= omains that are advertisers known to track users. Should we send our Token= Binding ID in this case? >=20 > A simple way to insure we are not leaking user information might be to ch= eck that the Token Binding Message is only sent if the cookie header is pre= sent. If the browser is blocking cookies for some reason, I suspect we sho= uld also block Token Binding Messages. Are there good use-cases for the To= ken Binding Message when there is no cookie present? >=20 > As for HTTP2 compression, this would only result in increased traffic whe= n the cookie policy changes. In general, if we do 50 requests to a web sit= e, we send the same cookies 50 times. In that case, we'd also send the Tok= en Binding Message header 50 times. Is it rare to change to sending cookie= s, and then not, to the same domain. >=20 > I read that Yahoo and Google recommend having separate static content dom= ains so that when loading static content, the browser does not bother sendi= ng any cookies. This makes page loading faster. In this case, we could al= so slightly speed things up over HTTP by not sending any Token Binding Mess= age header. >=20 > What do you think? >=20 > Bill > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable From nobody Tue Aug 25 10:03:32 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA141A21AA for ; Tue, 25 Aug 2015 10:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVEjRhLPsYuM for ; Tue, 25 Aug 2015 10:03:29 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d: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 A29401A0181 for ; Tue, 25 Aug 2015 10:03:29 -0700 (PDT) Received: by qkfh127 with SMTP id h127so104189111qkf.1 for ; Tue, 25 Aug 2015 10:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HoPEraDI6zbticW4YKLDNYXi9y4Gli0NrioETAz8OCE=; b=WDy94vdayS8zZyhcaSgOeOYIafWEWvXMZkOwHBptlHSV87FWiO+AvNZjWEiAeF+weZ T9i2nzepHXvSwRAqZybpWVpWEgODNIjZ+qbYRg4jfW1Ku8NpSpfVSQK85P06RpUIM3Iy WPOF8lVL3PQKa75vvurlnT3gQXR5ye1i9F0tQJ2ZHjMP6Gf/2qkb5UVMSPA4CbyiiGWH DYar+p84xLnOKc+AUGyTRio3nMHPKMvlWyLDLZJkFxUcFoxZDEgwFnrWNk+mE/tSYWFz dXieA61psjbmwL6utnz0p+FjoPysvQHMVj31EvnkNbCNd3NSb52XDha2hrSRja7zX9cI xi3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HoPEraDI6zbticW4YKLDNYXi9y4Gli0NrioETAz8OCE=; b=Xpr6vDdfMVoMgfdraAaT+1LFFX+xPgOCH+sEka9HU/f8RWN2XKz2flerqB2pm4akqO EsV5c7+C3b98Rulfw0dQMEBVlEpo0ZeGF9YJOTTmfU2tqh7dPLcicWqWn69342+1YItx GpmH757dcRDoqWBSwtHfnL5FwXsWhAlPYFSldnj0twTmZc+AzzUvAcANXLbyDxqcmLA4 wbgkOeOI6WcZq0m8CHq8kZJ7tZigZ3CkTNSL7Pw+G95wT+M36hb727EzoDcgpQ0Dw4rH TZtYLANO0BYGrvbx49DH9k65UYzFnLk1tKgECQphVXS6x9yE8kC2YTDsYMueCRVpS/vA 0yhw== X-Gm-Message-State: ALoCoQnxN8UDJpZ97a+fbETG0kDdhx271j6OvPwTjRAMy8Tcz0kqyBtZb5UTAgi7u+P/oQM2VjQx MIME-Version: 1.0 X-Received: by 10.55.42.163 with SMTP id q35mr43100666qkq.107.1440522208756; Tue, 25 Aug 2015 10:03:28 -0700 (PDT) Received: by 10.55.84.65 with HTTP; Tue, 25 Aug 2015 10:03:28 -0700 (PDT) In-Reply-To: References: <6F09B2F6-C6C3-4F78-944D-D4F341B9B746@ve7jtb.com> Date: Tue, 25 Aug 2015 10:03:28 -0700 Message-ID: From: Bill Cox To: Andrei Popov Content-Type: multipart/alternative; boundary=001a11493ef48bf400051e25b640 Archived-At: Cc: John Bradley , "unbearable@ietf.org" Subject: Re: [Unbearable] Should we only send Token Binding Message when sending cookies? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 17:03:30 -0000 --001a11493ef48bf400051e25b640 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 25, 2015 at 9:30 AM, Andrei Popov wrote: > Token Binding messages are encapsulated in the application protocol and > handled at the application protocol layer, therefore it seems feasible to > only send them when needed. > > There has been a separate discussion about removing the requirement that > the Provided binding is sent in the very first application_data payload > after TB has been negotiated. > > Perhaps we can combine both ideas and say that the application MUST send > Token Binding messages whenever it is requesting or supplying tokens? > > Cheers, > > Andrei > > That sounds good to me. BIll --001a11493ef48bf400051e25b640 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On T= ue, Aug 25, 2015 at 9:30 AM, Andrei Popov <Andrei.Popov@microsoft= .com> wrote:

Token Binding = messages are encapsulated in the application protocol and handled at the ap= plication protocol layer, therefore it seems feasible to only send them whe= n needed.

There has been a separate discussion about removing the requirement that th= e Provided binding is sent in the very first application_data payload after= TB has been negotiated.

Perhaps we can combine both ideas and say that the application MUST send To= ken Binding messages whenever it is requesting or supplying tokens?

Cheers,

Andrei

T= hat sounds good to me.

BIll=C2=A0

--001a11493ef48bf400051e25b640-- From nobody Tue Aug 25 13:08:37 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816B91A888E for ; Tue, 25 Aug 2015 13:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.013 X-Spam-Level: X-Spam-Status: No, score=0.013 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5umdZgZgili for ; Tue, 25 Aug 2015 13:08:34 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 13C941A87CD for ; Tue, 25 Aug 2015 13:08:33 -0700 (PDT) Received: from [93.214.242.237] by 3capp-gmx-bs10.server.lan (via HTTP); Tue, 25 Aug 2015 22:08:31 +0200 MIME-Version: 1.0 Message-ID: From: D.Rogers@gmx.net To: "Bill Cox" Content-Type: text/html; charset=UTF-8 Date: Tue, 25 Aug 2015 22:08:31 +0200 Importance: normal Sensitivity: Normal In-Reply-To: References: X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:b1FI4NXB8BFCFereWWkusLFShM2inr9OaNm7Fu16sqn sOAY4TKwPPfbzhQH3rUTbUbVdSMqMsS4CYPiOYN12sYAhstyfJ fb8Zkx6NOvEPOnBKXWQos2rWKynoy/cYFdKyll+NvYZizFrKrb 5y94Fsw3njpt2HQNqlW+zpJ1P+gzZUt4kD/XBXn8YVZso4ZHo2 c8u+QzJRcPjTiGTmwk90zDyUcnZsWFJbWAQO9+iFpIBoTbLXs/ 1EmXiSVM452QgRI4TjkPiam9RShjTEQGO50yN1tiVgvFVuBAp9 ljJb4A= X-UI-Out-Filterresults: notjunk:1;V01:K0:h18IMw+IRWc=:UceTYPuDhjf0sG3D6h3XIk 01PKQVXPZfI9S1NwtKnTW1G7ZmkhmhPE8BYaiPqcCrsY/79xQYUaZSYFsljNYaupAkOZlE7yl JRwJiDtD6Od/D0dHzQy5N0ttwkIEn4zZVveiD2k5RWtnX5IortfkBaFyKNYYc9+QZ6uDYxIP2 aPaepZLiD9agya3JneAwVaa0UDzIlUzVoP1cawwLDlkeIid75tJDPKIUEuzpw/A/jwsUAQ+XD qKMaYbC/hLGTuvv+EW7WXlALAPLweBBt4Qf+MiP24B2MKTm2vZ6eW/xtVTieJAsy1hZpR3OlZ hSsaBKG19lp+XOlndgYuw4jpeeoCtmaZdL36CThWfp/A2plF+e63uVrSNZq8JqFqlS7B6PpAn rvCLnqLo6oHzo1OuMBAjMuRfHaE/QhpzWrrO26XoAD3XUG9DMiuOLvhJIUtVTgEVpmXsEDlPj 0ozbEW6vyA== Archived-At: Cc: unbearable@ietf.org Subject: Re: [Unbearable] Should we only send Token Binding Message when sending cookies? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 20:08:35 -0000

Hi Bill,

I dont know how to say this, so theres only one way - I have a basic gut aversion to the use of cookies in general in any security enhancing function. All of your concerns only express and enhance that.

On HTTP compression possibly speeding page loading, thats one of those theoretical novelties, affecting the real world like a drop in the ocean. Most of the pages I visist, particularly this last say 18 months or so, load slowly because of the adverts included, meaning the page cannot be scrolled until a flash finishes loading, a 2% speed up wont be noticed by most users.

Dean

Gesendet: Dienstag, 25. August 2015 um 15:54 Uhr
Von: "Bill Cox" <waywardgeek@google.com>
An: unbearable@ietf.org
Betreff: [Unbearable] Should we only send Token Binding Message when sending cookies?

Sorry for having missed the discussions so far. This has probably already been discussed to death...

I am worried there will be bugs, such as sending a Token Binding Message header when cookies have been disabled by the user. I've just started reading about cookie policy, and so far, it seems insanely complex. Some browsers might block third party cookies, or cookies to particular third party domains that are advertisers known to track users. Should we send our Token Binding ID in this case?

A simple way to insure we are not leaking user information might be to check that the Token Binding Message is only sent if the cookie header is present. If the browser is blocking cookies for some reason, I suspect we should also block Token Binding Messages. Are there good use-cases for the Token Binding Message when there is no cookie present?

As for HTTP2 compression, this would only result in increased traffic when the cookie policy changes. In general, if we do 50 requests to a web site, we send the same cookies 50 times. In that case, we'd also send the Token Binding Message header 50 times. Is it rare to change to sending cookies, and then not, to the same domain.

I read that Yahoo and Google recommend having separate static content domains so that when loading static content, the browser does not bother sending any cookies. This makes page loading faster. In this case, we could also slightly speed things up over HTTP by not sending any Token Binding Message header.

What do you think?

Bill

_______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable

From nobody Sat Aug 29 12:46:28 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD5F1B3EC5 for ; Sat, 29 Aug 2015 12:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tG8JaY7klfxo for ; Sat, 29 Aug 2015 12:46:26 -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 872101B3E57 for ; Sat, 29 Aug 2015 12:46:26 -0700 (PDT) Received: by qgj62 with SMTP id 62so46659949qgj.2 for ; Sat, 29 Aug 2015 12:46:25 -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:cc:content-type; bh=Viw4JZAAGQVCMrH0ZvZlhqniR6uwFA/bg80aMxIvwgY=; b=KCzHKMJ4SaRWjHPyE+N7Gc6aHxFH5jwIRTB3uupg3pOJnXLtysfxoiHrQPtp0PZTZl MIrwZm/scHksmnS/VZSETrMMJLJxyXa2/8r6QkpL5ui7p9g+XTOaVuR08zTuX5dKo/cI m+DWVdPEQDIFgOy4UtRzte6fA98x9ffMbqhIrvYgCMTc/dVo79Mqz4skjaH/iOdApLpy IuGW06s34MkIqOYhl1XYk7CNFMQ2s7W16eoZL3l3VDxVWfmbXqCtZ9Qoya0eAZm70X/u da+Q6+GjH74+nY+xSlR6nPBmNoQZDH0rVn8NiW85LHcvntP3/dmAjThr0Uw+duW0xWzU WTtg== 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:cc :content-type; bh=Viw4JZAAGQVCMrH0ZvZlhqniR6uwFA/bg80aMxIvwgY=; b=ArWPm/oemMzoih6qck3pSAAEZqDioVkAsaaJSlVstkZIaLckAHSAJYHpfMTDhsu9Gw 8z4UDvcNXmuAgcVRiF9WEte8vHTTDwYtuRSzdP8WdA5SutaKr7X66WHVOsDqDmhhp7jA UEf9+5eN03041z5gl9MVuvqHdjp0CWxaYwhk5IyUnfDXJRHjrHneE+GazWL/KhVqpc1g BH7b4nxeQer/zLHkTjG+Ehmk/DyR6bX5zrlBncjbOoO4nDRde2CLMwcfHivznDqrfYbp t94IzZOKlttgRYsr3PGFsiRbN7h3zfPLn7UgAvLrg9KYlinOpzQ2xbo307fBj3IA3IRU dGCw== X-Gm-Message-State: ALoCoQk3469ltrlVO0CKs48LRw0XnknX5tg45bX8ps9d7O37MlMYH2DOFgl3l09UWkkApIBqTKmR MIME-Version: 1.0 X-Received: by 10.140.232.20 with SMTP id d20mr27310579qhc.72.1440877585768; Sat, 29 Aug 2015 12:46:25 -0700 (PDT) Received: by 10.55.84.65 with HTTP; Sat, 29 Aug 2015 12:46:25 -0700 (PDT) Date: Sat, 29 Aug 2015 12:46:25 -0700 Message-ID: From: Bill Cox To: unbearable@ietf.org Content-Type: multipart/alternative; boundary=001a1135482caa62f3051e78743b Archived-At: Cc: Nick Harper Subject: [Unbearable] Token Binding extension has incorrect size for key array X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 19:46:28 -0000 --001a1135482caa62f3051e78743b Content-Type: text/plain; charset=UTF-8 The spec and used a uint16 for the length of the key type array, but the keys are 8-bit values and are not allowed to repeat. This is clearly an error in the spec. I used a 1-byte length instead. No point wasting a byte :) Two other issues in this spec: 1) The server has to ignore this extension if the client broadcasts support for a newer version than the server knows about. This will result in Token Binding being disabled whenever the client supports a newer version than the server, or alternatively, clients will have to be careful to only broadcast older well supported versions. This should probably be a range of versions rather than just one. My preference is to simplify the version number to 1 byte ,and send a 2-byte range. 0 would be the prototype version, and 1, would be the first official version. The server would pick a version from the range sent by the client and send the same version repeated (so that server and client headers are the same size). I do not think we need a 2-byte version for this simple extension. Every byte counts :) 2) The server currently has no way to inform the client what it's preferences are. Instead, the server has to pick just one. In the case where the server prefers ECDSA, but the client already has an RSA key pair, the server is likely to pick ECDSA, invalidating the client's key pair. Instead, I send a list of acceptable parameters both ways, in order of preference, where the server sends a subset of the list received from the client. This allows the client to know that the server prefers ECDSA but is willing to continue support for RSA, and the client can choose to continue using the new key or not. Thanks, Bill --001a1135482caa62f3051e78743b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The spec and used a uint16 for the length of the key= type array, but the keys are 8-bit values and are not allowed to repeat.= =C2=A0 This is clearly an error in the spec.=C2=A0 I used a 1-byte length i= nstead.=C2=A0 No point wasting a byte :)

Two other issue= s in this spec:

1) The server has to ignore this e= xtension if the client broadcasts support for a newer version than the serv= er knows about.=C2=A0 This will result in Token Binding being disabled when= ever the client supports a newer version than the server, or alternatively,= clients will have to be careful to only broadcast older well supported ver= sions.=C2=A0 This should probably be a range of versions rather than just o= ne.=C2=A0 My preference is to simplify the version number to 1 byte ,and se= nd a 2-byte range. =C2=A00 would be the prototype version, and 1, would be = the first official version.=C2=A0 The server would pick a version from the = range sent by the client and send the same version repeated (so that server= and client headers are the same size).=C2=A0 I do not think we need a 2-by= te version for this simple extension.=C2=A0 Every byte counts :)

2) The server currently has no way to inform the client what= it's preferences are.=C2=A0 Instead, the server has to pick just one.= =C2=A0 In the case where the server prefers ECDSA, but the client already h= as an RSA key pair, the server is likely to pick ECDSA, invalidating the cl= ient's key pair.=C2=A0 Instead, I send a list of acceptable parameters = both ways, in order of preference, where the server sends a subset of the l= ist received from the client.=C2=A0 This allows the client to know that the= server prefers ECDSA but is willing to continue support for RSA, and the c= lient can choose to continue using the new key or not.

Thanks,

Bill

--001a1135482caa62f3051e78743b-- From nobody Mon Aug 31 12:32:32 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED9A1B29BB for ; Mon, 31 Aug 2015 12:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5omXZI26arm for ; Mon, 31 Aug 2015 12:32:28 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0799.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::799]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0141A9251 for ; Mon, 31 Aug 2015 12:32:28 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.256.15; Mon, 31 Aug 2015 19:32:25 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0256.013; Mon, 31 Aug 2015 19:32:25 +0000 From: Andrei Popov To: Bill Cox , "unbearable@ietf.org" Thread-Topic: [Unbearable] Token Binding extension has incorrect size for key array Thread-Index: AQHQ4pNoYyV6p4vPnkefMel8qjcth54mfgoQ Date: Mon, 31 Aug 2015 19:32:25 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:4::1d2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:KtqTSdzOayVE9FthnTgqoUiB8JaW1L5wl87MYCwDjSS9Wf9CGdOc+0VlXJ/a8pKFQCFvO2usTDskP8ifWWpZXX2rQ/FTVhEE3ekWuncEykpY7cLKWTur54AyPfK5MeS/3R6eOM5sqH5Z2NArtTIGZA==; 24:76qP5a9dThdhEVD1YVYmgGPnnzA3fFKI8M61VpV2Whf0ik1p/Sma8ukpJyYZ9oJBsk3O9fsXXniPE/PvARNd3lKav22nTaMXO3YHm5nR5GA=; 20:Ob6j7Lfx+Z2INBUFjRL1B3KaUmhZGbam8L2Mjo3qTST3VGix7hYQwcXkgnKW2y1h6UKWMDn1kL/1hbfsTdiDSg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(8121501046)(5005006)(3002001); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 0685122203 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(164054003)(377454003)(199003)(5002640100001)(64706001)(2656002)(46102003)(10290500002)(5007970100001)(8990500004)(106356001)(19617315012)(10400500002)(77096005)(105586002)(5004730100002)(76576001)(16236675004)(19609705001)(122556002)(15975445007)(40100003)(2900100001)(86362001)(102836002)(19625215002)(99286002)(33656002)(76176999)(10090500001)(5001830100001)(19580395003)(189998001)(2501003)(5001960100002)(50986999)(97736004)(86612001)(5005710100001)(106116001)(87936001)(77156002)(68736005)(74316001)(5003600100002)(5001770100001)(62966003)(19580405001)(2950100001)(5001860100001)(54356999)(81156007)(101416001)(4001540100001)(92566002)(19300405004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB139668D227DFFF3D644055A78C6B0BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2015 19:32:25.3347 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Cc: Nick Harper Subject: Re: [Unbearable] Token Binding extension has incorrect size for key array X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 19:32:31 -0000 --_000_BLUPR03MB139668D227DFFF3D644055A78C6B0BLUPR03MB1396namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmlsbCwNCg0KMSkgSSBicm91Z2h0IHRoaXMgdXAgZm9yIGRpc2N1c3Npb24gaW4gUHJhZ3Vl IGFuZCB0aGUgZ3JvdXAgc2VlbWVkIHRvIGhhdmUgbm8gaW50ZXJlc3QgaW4gYSBtb3JlIGVsYWJv cmF0ZSB2ZXJzaW9uIG5lZ290aWF0aW9uIG1lY2hhbmlzbS4gSWYgZW5vdWdoIHBlb3BsZSBhcmUg aW50ZXJlc3RlZCBpbiByZW9wZW5pbmcgdGhpcyBjb252ZXJzYXRpb24sIHN1cmUgd2UgY2FuIGNv bWUgdXAgd2l0aCBhIHJhbmdlIG9mIHZlcnNpb25zLCBhIGxpc3Qgb2YgdmVyc2lvbnMsIG9yIGEg VExTLXN0eWxlIOKAnGhpZ2hlc3Qgc3VwcG9ydGVkIHZlcnNpb27igJ0gbWVjaGFuaXNtLg0KMikg VGhpcyB3YXMgdGhlIDJuZCBwb2ludCBJIGJyb3VnaHQgdXAgaW4gUHJhZ3VlLiBBZ2FpbiwgY29u c2Vuc3VzIGluIHRoZSByb29tIHdhcyB0byBrZWVwIG5lZ290aWF0aW5nIG9ubHkgb25lIGFsZ29y aXRobSAoYnV0IHRvIGFsbG93IHRoZSBjbGllbnQgc2VuZCBvdGhlciB0eXBlcyBvZiBrZXlzIGlu IHRoZSBmZWRlcmF0aW9uIGNhc2UpLg0KDQpQZXJoYXBzIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBt YWtlIGNvbnNlbnN1cyBjYWxscyBvbiB0aGUgbWFpbGluZyBsaXN0LCB0byBjb25maXJtIChvciBv dmVydHVybikgdGhlIGRlY2lzaW9ucyBtYWRlIGluIFByYWd1ZT8NCg0KQ2hlZXJzLA0KDQpBbmRy ZWkNCg0KRnJvbTogVW5iZWFyYWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEJpbGwgQ294DQpTZW50OiBTYXR1cmRheSwgQXVndXN0IDI5LCAyMDE1 IDEyOjQ2IFBNDQpUbzogdW5iZWFyYWJsZUBpZXRmLm9yZw0KQ2M6IE5pY2sgSGFycGVyIDxuaGFy cGVyQGdvb2dsZS5jb20+DQpTdWJqZWN0OiBbVW5iZWFyYWJsZV0gVG9rZW4gQmluZGluZyBleHRl bnNpb24gaGFzIGluY29ycmVjdCBzaXplIGZvciBrZXkgYXJyYXkNCg0KVGhlIHNwZWM8aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1wb3Bvdi10b2tiaW5kLW5lZ290aWF0aW9uLTAwLnR4 dD4gYW5kIHVzZWQgYSB1aW50MTYgZm9yIHRoZSBsZW5ndGggb2YgdGhlIGtleSB0eXBlIGFycmF5 LCBidXQgdGhlIGtleXMgYXJlIDgtYml0IHZhbHVlcyBhbmQgYXJlIG5vdCBhbGxvd2VkIHRvIHJl cGVhdC4gIFRoaXMgaXMgY2xlYXJseSBhbiBlcnJvciBpbiB0aGUgc3BlYy4gIEkgdXNlZCBhIDEt Ynl0ZSBsZW5ndGggaW5zdGVhZC4gIE5vIHBvaW50IHdhc3RpbmcgYSBieXRlIDopDQoNClR3byBv dGhlciBpc3N1ZXMgaW4gdGhpcyBzcGVjOg0KDQoxKSBUaGUgc2VydmVyIGhhcyB0byBpZ25vcmUg dGhpcyBleHRlbnNpb24gaWYgdGhlIGNsaWVudCBicm9hZGNhc3RzIHN1cHBvcnQgZm9yIGEgbmV3 ZXIgdmVyc2lvbiB0aGFuIHRoZSBzZXJ2ZXIga25vd3MgYWJvdXQuICBUaGlzIHdpbGwgcmVzdWx0 IGluIFRva2VuIEJpbmRpbmcgYmVpbmcgZGlzYWJsZWQgd2hlbmV2ZXIgdGhlIGNsaWVudCBzdXBw b3J0cyBhIG5ld2VyIHZlcnNpb24gdGhhbiB0aGUgc2VydmVyLCBvciBhbHRlcm5hdGl2ZWx5LCBj bGllbnRzIHdpbGwgaGF2ZSB0byBiZSBjYXJlZnVsIHRvIG9ubHkgYnJvYWRjYXN0IG9sZGVyIHdl bGwgc3VwcG9ydGVkIHZlcnNpb25zLiAgVGhpcyBzaG91bGQgcHJvYmFibHkgYmUgYSByYW5nZSBv ZiB2ZXJzaW9ucyByYXRoZXIgdGhhbiBqdXN0IG9uZS4gIE15IHByZWZlcmVuY2UgaXMgdG8gc2lt cGxpZnkgdGhlIHZlcnNpb24gbnVtYmVyIHRvIDEgYnl0ZSAsYW5kIHNlbmQgYSAyLWJ5dGUgcmFu Z2UuICAwIHdvdWxkIGJlIHRoZSBwcm90b3R5cGUgdmVyc2lvbiwgYW5kIDEsIHdvdWxkIGJlIHRo ZSBmaXJzdCBvZmZpY2lhbCB2ZXJzaW9uLiAgVGhlIHNlcnZlciB3b3VsZCBwaWNrIGEgdmVyc2lv biBmcm9tIHRoZSByYW5nZSBzZW50IGJ5IHRoZSBjbGllbnQgYW5kIHNlbmQgdGhlIHNhbWUgdmVy c2lvbiByZXBlYXRlZCAoc28gdGhhdCBzZXJ2ZXIgYW5kIGNsaWVudCBoZWFkZXJzIGFyZSB0aGUg c2FtZSBzaXplKS4gIEkgZG8gbm90IHRoaW5rIHdlIG5lZWQgYSAyLWJ5dGUgdmVyc2lvbiBmb3Ig dGhpcyBzaW1wbGUgZXh0ZW5zaW9uLiAgRXZlcnkgYnl0ZSBjb3VudHMgOikNCg0KMikgVGhlIHNl cnZlciBjdXJyZW50bHkgaGFzIG5vIHdheSB0byBpbmZvcm0gdGhlIGNsaWVudCB3aGF0IGl0J3Mg cHJlZmVyZW5jZXMgYXJlLiAgSW5zdGVhZCwgdGhlIHNlcnZlciBoYXMgdG8gcGljayBqdXN0IG9u ZS4gIEluIHRoZSBjYXNlIHdoZXJlIHRoZSBzZXJ2ZXIgcHJlZmVycyBFQ0RTQSwgYnV0IHRoZSBj bGllbnQgYWxyZWFkeSBoYXMgYW4gUlNBIGtleSBwYWlyLCB0aGUgc2VydmVyIGlzIGxpa2VseSB0 byBwaWNrIEVDRFNBLCBpbnZhbGlkYXRpbmcgdGhlIGNsaWVudCdzIGtleSBwYWlyLiAgSW5zdGVh ZCwgSSBzZW5kIGEgbGlzdCBvZiBhY2NlcHRhYmxlIHBhcmFtZXRlcnMgYm90aCB3YXlzLCBpbiBv cmRlciBvZiBwcmVmZXJlbmNlLCB3aGVyZSB0aGUgc2VydmVyIHNlbmRzIGEgc3Vic2V0IG9mIHRo ZSBsaXN0IHJlY2VpdmVkIGZyb20gdGhlIGNsaWVudC4gIFRoaXMgYWxsb3dzIHRoZSBjbGllbnQg dG8ga25vdyB0aGF0IHRoZSBzZXJ2ZXIgcHJlZmVycyBFQ0RTQSBidXQgaXMgd2lsbGluZyB0byBj b250aW51ZSBzdXBwb3J0IGZvciBSU0EsIGFuZCB0aGUgY2xpZW50IGNhbiBjaG9vc2UgdG8gY29u dGludWUgdXNpbmcgdGhlIG5ldyBrZXkgb3Igbm90Lg0KDQpUaGFua3MsDQpCaWxsDQo= --_000_BLUPR03MB139668D227DFFF3D644055A78C6B0BLUPR03MB1396namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdp bi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDAN Cgl7bXNvLWxpc3QtaWQ6MTk4MTI1OTIzOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczo3Mjc3MzQyNTAgNjc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3MTUgNjc2 OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxp c3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBo YS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05 LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3Qg bDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFu LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206 MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+SGkgQmlsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjEp IEkgYnJvdWdodCB0aGlzIHVwIGZvciBkaXNjdXNzaW9uIGluIFByYWd1ZSBhbmQgdGhlIGdyb3Vw IHNlZW1lZCB0byBoYXZlIG5vIGludGVyZXN0IGluIGEgbW9yZSBlbGFib3JhdGUgdmVyc2lvbiBu ZWdvdGlhdGlvbiBtZWNoYW5pc20uIElmIGVub3VnaCBwZW9wbGUgYXJlDQogaW50ZXJlc3RlZCBp biByZW9wZW5pbmcgdGhpcyBjb252ZXJzYXRpb24sIHN1cmUgd2UgY2FuIGNvbWUgdXAgd2l0aCBh IHJhbmdlIG9mIHZlcnNpb25zLCBhIGxpc3Qgb2YgdmVyc2lvbnMsIG9yIGEgVExTLXN0eWxlIOKA nGhpZ2hlc3Qgc3VwcG9ydGVkIHZlcnNpb27igJ0gbWVjaGFuaXNtLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4yKSBUaGlzIHdhcyB0aGUgMjxzdXA+bmQ8L3N1cD4gcG9pbnQgSSBicm91Z2h0IHVwIGluIFBy YWd1ZS4gQWdhaW4sIGNvbnNlbnN1cyBpbiB0aGUgcm9vbSB3YXMgdG8ga2VlcCBuZWdvdGlhdGlu ZyBvbmx5IG9uZSBhbGdvcml0aG0gKGJ1dCB0byBhbGxvdyB0aGUgY2xpZW50DQogc2VuZCBvdGhl ciB0eXBlcyBvZiBrZXlzIGluIHRoZSBmZWRlcmF0aW9uIGNhc2UpLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGVyaGFwcyBpdCB3b3VsZCBiZSB1c2VmdWwgdG8g bWFrZSBjb25zZW5zdXMgY2FsbHMgb24gdGhlIG1haWxpbmcgbGlzdCwgdG8gY29uZmlybSAob3Ig b3ZlcnR1cm4pIHRoZSBkZWNpc2lvbnMgbWFkZSBpbiBQcmFndWU/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5BbmRyZWk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVW5iZWFyYWJsZSBbbWFpbHRvOnVu YmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QmlsbCBDb3g8 YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEF1Z3VzdCAyOSwgMjAxNSAxMjo0NiBQTTxicj4N CjxiPlRvOjwvYj4gdW5iZWFyYWJsZUBpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gTmljayBIYXJw ZXIgJmx0O25oYXJwZXJAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1VuYmVh cmFibGVdIFRva2VuIEJpbmRpbmcgZXh0ZW5zaW9uIGhhcyBpbmNvcnJlY3Qgc2l6ZSBmb3Iga2V5 IGFycmF5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1wb3Bvdi10b2tiaW5kLW5lZ290aWF0aW9uLTAw LnR4dCI+VGhlIHNwZWM8L2E+IGFuZCB1c2VkIGEgdWludDE2IGZvciB0aGUgbGVuZ3RoIG9mIHRo ZSBrZXkgdHlwZSBhcnJheSwgYnV0IHRoZSBrZXlzIGFyZSA4LWJpdCB2YWx1ZXMgYW5kIGFyZSBu b3QgYWxsb3dlZCB0byByZXBlYXQuJm5ic3A7IFRoaXMgaXMgY2xlYXJseSBhbiBlcnJvciBpbiB0 aGUNCiBzcGVjLiZuYnNwOyBJIHVzZWQgYSAxLWJ5dGUgbGVuZ3RoIGluc3RlYWQuJm5ic3A7IE5v IHBvaW50IHdhc3RpbmcgYSBieXRlIDopPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Ud28gb3RoZXIgaXNzdWVzIGluIHRoaXMgc3BlYzo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MSkgVGhlIHNlcnZlciBo YXMgdG8gaWdub3JlIHRoaXMgZXh0ZW5zaW9uIGlmIHRoZSBjbGllbnQgYnJvYWRjYXN0cyBzdXBw b3J0IGZvciBhIG5ld2VyIHZlcnNpb24gdGhhbiB0aGUgc2VydmVyIGtub3dzIGFib3V0LiZuYnNw OyBUaGlzIHdpbGwgcmVzdWx0IGluIFRva2VuIEJpbmRpbmcgYmVpbmcgZGlzYWJsZWQgd2hlbmV2 ZXIgdGhlIGNsaWVudCBzdXBwb3J0cyBhIG5ld2VyIHZlcnNpb24gdGhhbiB0aGUgc2VydmVyLA0K IG9yIGFsdGVybmF0aXZlbHksIGNsaWVudHMgd2lsbCBoYXZlIHRvIGJlIGNhcmVmdWwgdG8gb25s eSBicm9hZGNhc3Qgb2xkZXIgd2VsbCBzdXBwb3J0ZWQgdmVyc2lvbnMuJm5ic3A7IFRoaXMgc2hv dWxkIHByb2JhYmx5IGJlIGEgcmFuZ2Ugb2YgdmVyc2lvbnMgcmF0aGVyIHRoYW4ganVzdCBvbmUu Jm5ic3A7IE15IHByZWZlcmVuY2UgaXMgdG8gc2ltcGxpZnkgdGhlIHZlcnNpb24gbnVtYmVyIHRv IDEgYnl0ZSAsYW5kIHNlbmQgYSAyLWJ5dGUgcmFuZ2UuICZuYnNwOzAgd291bGQNCiBiZSB0aGUg cHJvdG90eXBlIHZlcnNpb24sIGFuZCAxLCB3b3VsZCBiZSB0aGUgZmlyc3Qgb2ZmaWNpYWwgdmVy c2lvbi4mbmJzcDsgVGhlIHNlcnZlciB3b3VsZCBwaWNrIGEgdmVyc2lvbiBmcm9tIHRoZSByYW5n ZSBzZW50IGJ5IHRoZSBjbGllbnQgYW5kIHNlbmQgdGhlIHNhbWUgdmVyc2lvbiByZXBlYXRlZCAo c28gdGhhdCBzZXJ2ZXIgYW5kIGNsaWVudCBoZWFkZXJzIGFyZSB0aGUgc2FtZSBzaXplKS4mbmJz cDsgSSBkbyBub3QgdGhpbmsgd2UgbmVlZCBhIDItYnl0ZQ0KIHZlcnNpb24gZm9yIHRoaXMgc2lt cGxlIGV4dGVuc2lvbi4mbmJzcDsgRXZlcnkgYnl0ZSBjb3VudHMgOik8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MikgVGhlIHNlcnZlciBjdXJy ZW50bHkgaGFzIG5vIHdheSB0byBpbmZvcm0gdGhlIGNsaWVudCB3aGF0IGl0J3MgcHJlZmVyZW5j ZXMgYXJlLiZuYnNwOyBJbnN0ZWFkLCB0aGUgc2VydmVyIGhhcyB0byBwaWNrIGp1c3Qgb25lLiZu YnNwOyBJbiB0aGUgY2FzZSB3aGVyZSB0aGUgc2VydmVyIHByZWZlcnMgRUNEU0EsIGJ1dCB0aGUg Y2xpZW50IGFscmVhZHkgaGFzIGFuIFJTQSBrZXkgcGFpciwgdGhlIHNlcnZlciBpcyBsaWtlbHkN CiB0byBwaWNrIEVDRFNBLCBpbnZhbGlkYXRpbmcgdGhlIGNsaWVudCdzIGtleSBwYWlyLiZuYnNw OyBJbnN0ZWFkLCBJIHNlbmQgYSBsaXN0IG9mIGFjY2VwdGFibGUgcGFyYW1ldGVycyBib3RoIHdh eXMsIGluIG9yZGVyIG9mIHByZWZlcmVuY2UsIHdoZXJlIHRoZSBzZXJ2ZXIgc2VuZHMgYSBzdWJz ZXQgb2YgdGhlIGxpc3QgcmVjZWl2ZWQgZnJvbSB0aGUgY2xpZW50LiZuYnNwOyBUaGlzIGFsbG93 cyB0aGUgY2xpZW50IHRvIGtub3cgdGhhdCB0aGUgc2VydmVyIHByZWZlcnMNCiBFQ0RTQSBidXQg aXMgd2lsbGluZyB0byBjb250aW51ZSBzdXBwb3J0IGZvciBSU0EsIGFuZCB0aGUgY2xpZW50IGNh biBjaG9vc2UgdG8gY29udGludWUgdXNpbmcgdGhlIG5ldyBrZXkgb3Igbm90LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CaWxsPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BLUPR03MB139668D227DFFF3D644055A78C6B0BLUPR03MB1396namp_-- From nobody Mon Aug 31 12:44:40 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C837C1B5781 for ; Mon, 31 Aug 2015 12:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id St16qSWf0OBL for ; Mon, 31 Aug 2015 12:44:37 -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 AC4171B5A90 for ; Mon, 31 Aug 2015 12:44:37 -0700 (PDT) Received: by qgz60 with SMTP id 60so14766991qgz.2 for ; Mon, 31 Aug 2015 12:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wITpPZIjyv/r4MjAY5WJl+bE8yjRD3N5c5otGhghSHI=; b=oG7utZbcf8WKwT2r77TUp2FBebq71PqA6OU6zu1nuc3su5E2alG/idCWkhNgPUCitT vQsVu8irnYvd02/bcsDEyJ/vdVcO5O2YsumHp8fEaHWCQbGOlJMlGkTNGb8lOtT9fWl7 2CcXpB/o+1waKs3/EnI3sJ5JLV8XN/Yh/i8G7biVkq6SAZF2x5fmyaanU3B3WaTvumD5 YxqbgUFmETDkstgStFHG4Ouc7OlWYHy4/CDwFKDYOSfgwJkbG60hiV+mRuhcH3GjuLHa tCcsbHgErYc27Vi0g9gl6FhrBBWxNvxdv6m1g1hgUDqyQmhI+PvGacUcm09fIzE8bqlq lJGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wITpPZIjyv/r4MjAY5WJl+bE8yjRD3N5c5otGhghSHI=; b=KKRN7x78FLymVrt0JzzhzXpaz1oE00ukstXX4TomS/V06NYLKnQOXR9snv5OVSfgbc 2bDvGOAde8xLf1n6TGJWxrxmJeeObevMHepozP/+sw/Vd4u2huCCol7Nmmzt9XODrubS gXweJXmnSsyjzz4eoDhiFcptZcAIiHaRN3q1+ybY7YXyKvISzV4F2tCxxMjz5axuJ81i 0SJVuHxBqjXoqBNmyNrsBSdY2DLIY6oJ/sRKOjiDK5yZz9Y7xWGPJ5DnXdx9R+QKNn07 EJyDP75gJBVE5ww1JToiJO7BTBCImiexJqi6ml/UuxP0MwecRED5tX9I3JizClK8mfT9 JOAQ== X-Gm-Message-State: ALoCoQnvuf2CY4bsghkmy5MyQLZwed6Wy04E4OMW+37HFf56q0enEnVpVaBpJ6jurjGw2qgFDYu9 MIME-Version: 1.0 X-Received: by 10.140.133.135 with SMTP id 129mr42222313qhf.95.1441050276131; Mon, 31 Aug 2015 12:44:36 -0700 (PDT) Received: by 10.55.84.65 with HTTP; Mon, 31 Aug 2015 12:44:36 -0700 (PDT) In-Reply-To: References: Date: Mon, 31 Aug 2015 12:44:36 -0700 Message-ID: From: Bill Cox To: Andrei Popov Content-Type: multipart/alternative; boundary=001a1136fd7cd066e2051ea0a979 Archived-At: Cc: "unbearable@ietf.org" , Nick Harper Subject: Re: [Unbearable] Token Binding extension has incorrect size for key array X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 19:44:38 -0000 --001a1136fd7cd066e2051ea0a979 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 31, 2015 at 12:32 PM, Andrei Popov wrote: > Hi Bill, > > > > 1) I brought this up for discussion in Prague and the group seemed to hav= e > no interest in a more elaborate version negotiation mechanism. If enough > people are interested in reopening this conversation, sure we can come up > with a range of versions, a list of versions, or a TLS-style =E2=80=9Chig= hest > supported version=E2=80=9D mechanism. > > 2) This was the 2nd point I brought up in Prague. Again, consensus in the > room was to keep negotiating only one algorithm (but to allow the client > send other types of keys in the federation case). > > > > Perhaps it would be useful to make consensus calls on the mailing list, t= o > confirm (or overturn) the decisions made in Prague? > > > > Cheers, > > > > Andrei > As an implementer, I would appreciate tentative decisions on the list, since I'm currently writing the code. Thanks, Bill --001a1136fd7cd066e2051ea0a979 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On M= on, Aug 31, 2015 at 12:32 PM, Andrei Popov <Andrei.Popov@microsof= t.com> wrote:

Hi Bill,

=C2=A0

1) I brought this up for discussion i= n Prague and the group seemed to have no interest in a more elaborate versi= on negotiation mechanism. If enough people are interested in reopening this conversation, sure we can come up with a rang= e of versions, a list of versions, or a TLS-style =E2=80=9Chighest supporte= d version=E2=80=9D mechanism.

2) This was the 2^nd point = I brought up in Prague. Again, consensus in the room was to keep negotiatin= g only one algorithm (but to allow the client send other types of keys in the federation case).

=C2=A0

Perhaps it would be useful to make co= nsensus calls on the mailing list, to confirm (or overturn) the decisions m= ade in Prague?

=C2=A0

Cheers,

=C2=A0

Andrei

As an implementer, I would appreciate tentative de= cisions on the list, since I'm currently writing the code.
Thanks,
Bill

--001a1136fd7cd066e2051ea0a979-- From nobody Mon Aug 31 12:53:00 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8B31B5BD9 for ; Mon, 31 Aug 2015 12:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0ab7HWmJlOo for ; Mon, 31 Aug 2015 12:52:56 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0776.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:776]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 450D61B5BD7 for ; Mon, 31 Aug 2015 12:52:56 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.256.15; Mon, 31 Aug 2015 19:52:53 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0256.013; Mon, 31 Aug 2015 19:52:53 +0000 From: Andrei Popov To: Bill Cox , Leif Johansson , "John Bradley" Thread-Topic: [Unbearable] Token Binding extension has incorrect size for key array Thread-Index: AQHQ5CV4ucl9EyIOxk6EC6af19hkJZ4mgvBQ Date: Mon, 31 Aug 2015 19:52:53 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:4::1d2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:AmjPZk2CPbiovIrZuCKGhjlKG+fw8bY5GXcN9QHrjAC4mHJ39fdoEShh8FFTI4TLGwRSGswOtSqIJqX2cmcZV8EuP/gu83v1zRZ5n9aMi6+wRkTzfO5AEZ9guvwocCfYzpHur1CZ9628lz8B4bU/SA==; 24:Mzb1pQ56AatHNC/o0XyoXpd4t80y1Ob37EXrmlK67khSBGDk93LKuIa0FEj/hhPFxjRQY0i15boAR9qwtrJv+e5IsYOjdBR6J6YWflwYw4g=; 20:9Gxc2MKoWqQJnnER5u9H+oXxI0mU0QaCcTjxwL2eTLqiZ4HosVhWDdChj7u69WZOENPxOiiCPcQ64bcS2OEHsw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1395; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(8121501046)(5005006)(3002001); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; x-forefront-prvs: 0685122203 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(164054003)(377454003)(189002)(24454002)(2656002)(19580405001)(15975445007)(86362001)(54356999)(19580395003)(92566002)(5001770100001)(106356001)(10090500001)(105586002)(5001960100002)(76176999)(5001830100001)(64706001)(74316001)(2950100001)(46102003)(8990500004)(5001860100001)(68736005)(87936001)(97736004)(101416001)(50986999)(4001540100001)(81156007)(189998001)(86612001)(19625215002)(5003600100002)(10400500002)(10290500002)(5002640100001)(77156002)(19300405004)(40100003)(2900100001)(62966003)(77096005)(33656002)(102836002)(99286002)(122556002)(19609705001)(5004730100002)(106116001)(16236675004)(5005710100001)(5007970100001)(76576001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB13965B5E315AB53C1C1F9C098C6B0BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2015 19:52:53.0492 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395 Archived-At: Cc: "unbearable@ietf.org" , Nick Harper Subject: Re: [Unbearable] Token Binding extension has incorrect size for key array X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 19:52:58 -0000 --_000_BLUPR03MB13965B5E315AB53C1C1F9C098C6B0BLUPR03MB1396namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PCsgQ2hhaXJzPg0KDQpZZXMsIHVubGVzcyBJIG1pc3NlZCBpdCwgdGhlIHRlbnRhdGl2ZSBkZWNp c2lvbnMvbWludXRlcyBmcm9tIFByYWd1ZSB3ZXJlIG5vdCBwdWJsaXNoZWQgb24gdGhlIHVuYmVh cmFibGUgbWFpbGluZyBsaXN0Lg0KDQpGcm9tOiBCaWxsIENveCBbbWFpbHRvOndheXdhcmRnZWVr QGdvb2dsZS5jb21dDQpTZW50OiBNb25kYXksIEF1Z3VzdCAzMSwgMjAxNSAxMjo0NSBQTQ0KVG86 IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+DQpDYzogdW5iZWFyYWJs ZUBpZXRmLm9yZzsgTmljayBIYXJwZXIgPG5oYXJwZXJAZ29vZ2xlLmNvbT4NClN1YmplY3Q6IFJl OiBbVW5iZWFyYWJsZV0gVG9rZW4gQmluZGluZyBleHRlbnNpb24gaGFzIGluY29ycmVjdCBzaXpl IGZvciBrZXkgYXJyYXkNCg0KT24gTW9uLCBBdWcgMzEsIDIwMTUgYXQgMTI6MzIgUE0sIEFuZHJl aSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBt aWNyb3NvZnQuY29tPj4gd3JvdGU6DQpIaSBCaWxsLA0KDQoxKSBJIGJyb3VnaHQgdGhpcyB1cCBm b3IgZGlzY3Vzc2lvbiBpbiBQcmFndWUgYW5kIHRoZSBncm91cCBzZWVtZWQgdG8gaGF2ZSBubyBp bnRlcmVzdCBpbiBhIG1vcmUgZWxhYm9yYXRlIHZlcnNpb24gbmVnb3RpYXRpb24gbWVjaGFuaXNt LiBJZiBlbm91Z2ggcGVvcGxlIGFyZSBpbnRlcmVzdGVkIGluIHJlb3BlbmluZyB0aGlzIGNvbnZl cnNhdGlvbiwgc3VyZSB3ZSBjYW4gY29tZSB1cCB3aXRoIGEgcmFuZ2Ugb2YgdmVyc2lvbnMsIGEg bGlzdCBvZiB2ZXJzaW9ucywgb3IgYSBUTFMtc3R5bGUg4oCcaGlnaGVzdCBzdXBwb3J0ZWQgdmVy c2lvbuKAnSBtZWNoYW5pc20uDQoyKSBUaGlzIHdhcyB0aGUgMm5kIHBvaW50IEkgYnJvdWdodCB1 cCBpbiBQcmFndWUuIEFnYWluLCBjb25zZW5zdXMgaW4gdGhlIHJvb20gd2FzIHRvIGtlZXAgbmVn b3RpYXRpbmcgb25seSBvbmUgYWxnb3JpdGhtIChidXQgdG8gYWxsb3cgdGhlIGNsaWVudCBzZW5k IG90aGVyIHR5cGVzIG9mIGtleXMgaW4gdGhlIGZlZGVyYXRpb24gY2FzZSkuDQoNClBlcmhhcHMg aXQgd291bGQgYmUgdXNlZnVsIHRvIG1ha2UgY29uc2Vuc3VzIGNhbGxzIG9uIHRoZSBtYWlsaW5n IGxpc3QsIHRvIGNvbmZpcm0gKG9yIG92ZXJ0dXJuKSB0aGUgZGVjaXNpb25zIG1hZGUgaW4gUHJh Z3VlPw0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQpBcyBhbiBpbXBsZW1lbnRlciwgSSB3b3VsZCBh cHByZWNpYXRlIHRlbnRhdGl2ZSBkZWNpc2lvbnMgb24gdGhlIGxpc3QsIHNpbmNlIEknbSBjdXJy ZW50bHkgd3JpdGluZyB0aGUgY29kZS4NCg0KVGhhbmtzLA0KQmlsbA0K --_000_BLUPR03MB13965B5E315AB53C1C1F9C098C6B0BLUPR03MB1396namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZsdDsmIzQzOyBDaGFpcnMmZ3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5ZZXMsIHVubGVzcyBJIG1pc3NlZCBpdCwg dGhlIHRlbnRhdGl2ZSBkZWNpc2lvbnMvbWludXRlcyBmcm9tIFByYWd1ZSB3ZXJlIG5vdCBwdWJs aXNoZWQgb24gdGhlIHVuYmVhcmFibGUgbWFpbGluZyBsaXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBCaWxsIENveCBb bWFpbHRvOndheXdhcmRnZWVrQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5 LCBBdWd1c3QgMzEsIDIwMTUgMTI6NDUgUE08YnI+DQo8Yj5Ubzo8L2I+IEFuZHJlaSBQb3BvdiAm bHQ7QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiB1bmJlYXJh YmxlQGlldGYub3JnOyBOaWNrIEhhcnBlciAmbHQ7bmhhcnBlckBnb29nbGUuY29tJmd0Ozxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW1VuYmVhcmFibGVdIFRva2VuIEJpbmRpbmcgZXh0ZW5zaW9u IGhhcyBpbmNvcnJlY3Qgc2l6ZSBmb3Iga2V5IGFycmF5PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEF1ZyAzMSwgMjAxNSBhdCAxMjoz MiBQTSwgQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jv c29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgQmls bCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4xKSBJIGJy b3VnaHQgdGhpcyB1cCBmb3IgZGlzY3Vzc2lvbiBpbiBQcmFndWUgYW5kIHRoZSBncm91cCBzZWVt ZWQgdG8gaGF2ZSBubyBpbnRlcmVzdCBpbiBhIG1vcmUgZWxhYm9yYXRlDQogdmVyc2lvbiBuZWdv dGlhdGlvbiBtZWNoYW5pc20uIElmIGVub3VnaCBwZW9wbGUgYXJlIGludGVyZXN0ZWQgaW4gcmVv cGVuaW5nIHRoaXMgY29udmVyc2F0aW9uLCBzdXJlIHdlIGNhbiBjb21lIHVwIHdpdGggYSByYW5n ZSBvZiB2ZXJzaW9ucywgYSBsaXN0IG9mIHZlcnNpb25zLCBvciBhIFRMUy1zdHlsZSDigJxoaWdo ZXN0IHN1cHBvcnRlZCB2ZXJzaW9u4oCdIG1lY2hhbmlzbS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4y KSBUaGlzIHdhcyB0aGUgMjxzdXA+bmQ8L3N1cD4gcG9pbnQgSSBicm91Z2h0IHVwIGluIFByYWd1 ZS4gQWdhaW4sIGNvbnNlbnN1cyBpbiB0aGUgcm9vbSB3YXMgdG8ga2VlcA0KIG5lZ290aWF0aW5n IG9ubHkgb25lIGFsZ29yaXRobSAoYnV0IHRvIGFsbG93IHRoZSBjbGllbnQgc2VuZCBvdGhlciB0 eXBlcyBvZiBrZXlzIGluIHRoZSBmZWRlcmF0aW9uIGNhc2UpLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlBlcmhhcHMgaXQgd291bGQgYmUgdXNlZnVsIHRv IG1ha2UgY29uc2Vuc3VzIGNhbGxzIG9uIHRoZSBtYWlsaW5nIGxpc3QsIHRvIGNvbmZpcm0gKG9y IG92ZXJ0dXJuKSB0aGUNCiBkZWNpc2lvbnMgbWFkZSBpbiBQcmFndWU/PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuZHJlaTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BcyBhbiBpbXBsZW1lbnRlciwgSSB3b3VsZCBhcHByZWNpYXRlIHRlbnRhdGl2ZSBk ZWNpc2lvbnMgb24gdGhlIGxpc3QsIHNpbmNlIEknbSBjdXJyZW50bHkgd3JpdGluZyB0aGUgY29k ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QmlsbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BLUPR03MB13965B5E315AB53C1C1F9C098C6B0BLUPR03MB1396namp_-- From nobody Mon Aug 31 12:54:42 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CA61B5C0D for ; Mon, 31 Aug 2015 12:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuTrhV7zARnJ for ; Mon, 31 Aug 2015 12:54:40 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 808971B5C0C for ; Mon, 31 Aug 2015 12:54:40 -0700 (PDT) Received: by qkbp67 with SMTP id p67so14180147qkb.3 for ; Mon, 31 Aug 2015 12:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=YksK9x36Ls78MZyu3AKrfsKwBzIaN87bL1KCKuZMKAo=; b=K51LwimRXtzbfKNg0ng4wkpL7kBZCZFgBcYiHkSTHFNnHVFEwFUHr2kRIs8h8ykAYs l/FZeT0f0LgJz6AXROIBEJdcsdrMJ/u/Rndri2EKQCxAgsvR8c2uGdyq78mC73PYgDo6 HhJPWylSriUnhGkvNdQR5q7V2eJfkhJ8UKzBTSS0Ip08smgp9INW++azBYgQsWoSDSb4 uMDR6NIAS2ilc0kdCccn5lo4QvkRzGXVaNx06iTLX9f3lfWFHu3HsmOyuB13uhe42X5p uuHnMpvd1HMVSxD3GRgMrOZ/g19iSb7aJdYTrNIf+J9kZuzmyE4YpSfuRLhKFvx/Pz/V 5CuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=YksK9x36Ls78MZyu3AKrfsKwBzIaN87bL1KCKuZMKAo=; b=azensd1PWUoWn0lo7hHfNX3t4gzHXfJZSzDp8yPN/78FJNte/o5CHkHhEu/qJbVtoe Z3V6SE1zM887ohkIFChXNJSTQai55p8A0zJlhOrVTPkoGcM5GxBNwiDFKsWqCbnB6fwI dPdw4gfZzSlY8BoJQwlqnRoh5Nscs1MtuHF6NOGUeDcdxDdBQkfEmX4/MpkDbDHng/kw 2Ba9gQiAGuETUJDcHkJi7u24Juh4nF01INIY4ahdIg0btdc+Y/WOOkc9r29M75pnIVSZ mkuQFbqYn7gSN8tDl/rJQXnc2eEdyGAuRYqrDrSge2U750LOjXoh3Vl+iMLUBuDdzmN0 XviA== X-Gm-Message-State: ALoCoQmWjEfwKUc+Zq5xH5Ed35vYkZP/larcoABVCo44263FUKvZ9ah+6TvpT3VAEFimLyKUuxyo X-Received: by 10.129.90.138 with SMTP id o132mr4792503ywb.32.1441050879553; Mon, 31 Aug 2015 12:54:39 -0700 (PDT) MIME-Version: 1.0 From: Dirk Balfanz Date: Mon, 31 Aug 2015 19:54:30 +0000 Message-ID: To: Tokbind WG Content-Type: multipart/alternative; boundary=001a1149126ac80091051ea0cd2c Archived-At: Subject: [Unbearable] Interim meeting X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 19:54:41 -0000 --001a1149126ac80091051ea0cd2c Content-Type: text/plain; charset=UTF-8 Hi token binders, where are we at with scheduling an interim meeting before Yokohama? Dirk. --001a1149126ac80091051ea0cd2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi token binders, =C2=A0

where are we a= t with scheduling an interim meeting before Yokohama?

<= div>Dirk.

--001a1149126ac80091051ea0cd2c-- From nobody Mon Aug 31 13:05:49 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC74F1B5DA1 for ; Mon, 31 Aug 2015 13:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0vC--MWhtGf for ; Mon, 31 Aug 2015 13:05:45 -0700 (PDT) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (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 DE7C61B5DA7 for ; Mon, 31 Aug 2015 13:05:44 -0700 (PDT) Received: by labnh1 with SMTP id nh1so53687406lab.3 for ; Mon, 31 Aug 2015 13:05:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=+yY4luKxLXUX5QVwpio2loS3+ucxZpOoL+Y80s8A89k=; b=Wq9oMKNIUmdXgmd0Ts0IK39oh8D6ZCq2hkUQomS4sD4Lr0zigDo3qZg2+ffISlzSrs 6d+sUFChdcm1eFTPWJB1TPqfMuvza1ECfFe0DJepMYWqdsS3vMDihUvbzz9H3qLtlZDP /zFmZy7Nq9VFbeDTKsjQmJ/vaBuf5Jb+Go2sP9z8rDbJHBCve0zpZuhA4knFFBqdUO0O ofk0mjr0Z7nL29iMPUo+Kw5tSXvMvndQivQ9KagNzGdIpLnTCGJx7/kk6C1547kGHT7z fKe/y/TaO+pPSUu3pyfb2IK5x0kNU2Ebpr9ywNpf/B2yEQ4OC4KqaXaHMNH13WXv9ya1 zjeQ== X-Gm-Message-State: ALoCoQk7h4N+LKGBMZJ5uqKbLbhfO/kAHT0i7gLykTJAOBzjOWNWkLb5rLoZxfmowsYiVm62p9Ww X-Received: by 10.112.181.197 with SMTP id dy5mr10929283lbc.109.1441051542819; Mon, 31 Aug 2015 13:05:42 -0700 (PDT) Received: from [192.168.1.109] ([94.140.51.73]) by smtp.gmail.com with ESMTPSA id tv6sm4201379lbb.31.2015.08.31.13.05.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 31 Aug 2015 13:05:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Leif Johansson X-Mailer: iPhone Mail (12H321) In-Reply-To: Date: Mon, 31 Aug 2015 22:05:37 +0200 Content-Transfer-Encoding: 7bit Message-Id: <6B0DDBE0-0DC0-47B9-B46B-3259AF246CE9@mnt.se> References: To: Dirk Balfanz Archived-At: Cc: Tokbind WG Subject: Re: [Unbearable] Interim meeting X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 20:05:47 -0000 > 31 aug 2015 kl. 21:54 skrev Dirk Balfanz : > > Hi token binders, > > where are we at with scheduling an interim meeting before Yokohama? > I haven't seen anything close to consensus unfortunately. > Dirk. > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable From nharper@google.com Mon Aug 31 13:24:26 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2677F1B5F70 for ; Mon, 31 Aug 2015 13:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rvDVcZNJmhe for ; Mon, 31 Aug 2015 13:24:24 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003: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 2BB041B4A2E for ; Mon, 31 Aug 2015 13:24:24 -0700 (PDT) Received: by oigk185 with SMTP id k185so65827846oig.2 for ; Mon, 31 Aug 2015 13:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JtCF4jFquCWGptDWt+MSrLCkcfsGggzT3+zDWP05SC0=; b=foL8fi5FrwoeB+vuaV9R1K7uNZAk3g9qQTQzleGa8cMRgoFV4jW2jTWpoK0PD28uJF pPxIPT1attzzFY1v1KarAFcKdS8bVqZg79oYuqzgF4ZyWEogONlwpOv7zSOIZu7iQjlW gMCo0EIVCwqNn20lacByPlq/DMeyECw+AAIyxePPboE0tk458BEp0MUp47qmPQ4jH5DR kVbXYqLCD0ak3VJ3W8LWa5dIj/Fc0DQ9zjfCEewAYumKSZp7l0a/yidl44gJpmao9KS3 mpm04mPhvD3Rv1iLBbHu+yu4BYWrkNTnR/OzRDpsA+aIo3+HV8P3cY8B0RQyQhqU1tb5 w81g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JtCF4jFquCWGptDWt+MSrLCkcfsGggzT3+zDWP05SC0=; b=j8ft4vkaY5MINqdGHG/Fpi+d2HomZbTwUO7m6zqJBjyg9b6qb/p5fkXIUn4kBSaPqA q+YMZSOvbonF5E+QJbnTY+axsC4txZaNPGoorfUpG12XUXe3qTBLod540dC3pwfj7ywZ hOop95JDMftt1/yHA+SnHrSgqZL2QdaCPaexXDo+uAJhwCS7U1nfcz3SNGuDVZJpZfuy aqynnK6J0BthAOtRZRXkvwJGxTPosoMc7AxT/irJHhjXGkH3SPQU9W+JQjocuOmQM5Z3 ks5oHihUhPTq0KdcXZE0SpqNjlbSVEPaxb+aUsgU9wakFDaFPZ89lpOjmLAZ40QaXT5l C/nA== X-Gm-Message-State: ALoCoQm/M/orpLI7njQjsEoiSxspU53Y+VNNuS2yv2jBvbRha2y4IAVCDWGsdzUhkhBbvYlefEIr X-Received: by 10.202.225.136 with SMTP id y130mr14453754oig.16.1441052663503; Mon, 31 Aug 2015 13:24:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.63.132 with HTTP; Mon, 31 Aug 2015 13:24:04 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Mon, 31 Aug 2015 13:24:04 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a113d63241c9618051ea138b3 Archived-At: Cc: "unbearable@ietf.org" , Bill Cox Subject: Re: [Unbearable] Token Binding extension has incorrect size for key array X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 20:39:10 -0000 --001a113d63241c9618051ea138b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 31, 2015 at 12:32 PM, Andrei Popov wrote: > Hi Bill, > > > > 1) I brought this up for discussion in Prague and the group seemed to hav= e > no interest in a more elaborate version negotiation mechanism. If enough > people are interested in reopening this conversation, sure we can come up > with a range of versions, a list of versions, or a TLS-style =E2=80=9Chig= hest > supported version=E2=80=9D mechanism. > >From the client side implementation perspective, I would be in favor of version negotiation including a list or range of supported versions. With the current approach, the client can only support one version, and if it updates to support a newer version, it would break compatibility with servers still running the older version if the client switches too soon. > 2) This was the 2nd point I brought up in Prague. Again, consensus in the > room was to keep negotiating only one algorithm (but to allow the client > send other types of keys in the federation case). > > > > Perhaps it would be useful to make consensus calls on the mailing list, t= o > confirm (or overturn) the decisions made in Prague? > > > > Cheers, > > > > Andrei > > > > *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *Bi= ll > Cox > *Sent:* Saturday, August 29, 2015 12:46 PM > *To:* unbearable@ietf.org > *Cc:* Nick Harper > *Subject:* [Unbearable] Token Binding extension has incorrect size for > key array > > > > The spec > and > used a uint16 for the length of the key type array, but the keys are 8-bi= t > values and are not allowed to repeat. This is clearly an error in the > spec. I used a 1-byte length instead. No point wasting a byte :) > > > > Two other issues in this spec: > > > > 1) The server has to ignore this extension if the client broadcasts > support for a newer version than the server knows about. This will resul= t > in Token Binding being disabled whenever the client supports a newer > version than the server, or alternatively, clients will have to be carefu= l > to only broadcast older well supported versions. This should probably be= a > range of versions rather than just one. My preference is to simplify the > version number to 1 byte ,and send a 2-byte range. 0 would be the > prototype version, and 1, would be the first official version. The serve= r > would pick a version from the range sent by the client and send the same > version repeated (so that server and client headers are the same size). = I > do not think we need a 2-byte version for this simple extension. Every > byte counts :) > > > > 2) The server currently has no way to inform the client what it's > preferences are. Instead, the server has to pick just one. In the case > where the server prefers ECDSA, but the client already has an RSA key pai= r, > the server is likely to pick ECDSA, invalidating the client's key pair. > Instead, I send a list of acceptable parameters both ways, in order of > preference, where the server sends a subset of the list received from the > client. This allows the client to know that the server prefers ECDSA but > is willing to continue support for RSA, and the client can choose to > continue using the new key or not. > > > > Thanks, > > Bill > --001a113d63241c9618051ea138b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Aug 31, 2015 at 12:32 PM, Andrei Popov <Andrei.Popov@= microsoft.com> wrote:

Hi Bill,

=C2=A0

1) I brought this up for discussion i= n Prague and the group seemed to have no interest in a more elaborate versi= on negotiation mechanism. If enough people are interested in reopening this conversation, sure we can come up with a rang= e of versions, a list of versions, or a TLS-style =E2=80=9Chighest supporte= d version=E2=80=9D mechanism.

<= /div>

From the client side implementation perspective, I would be in fa= vor of version negotiation including a list or range of supported versions.= With the current approach, the client can only support one version, and if= it updates to support a newer version, it would break compatibility with s= ervers still running the older version if the client switches too soon.

=C2=A0

2) This was the 2^nd point = I brought up in Prague. Again, consensus in the room was to keep negotiatin= g only one algorithm (but to allow the client send other types of keys in the federation case).

=C2=A0

Perhaps it would be useful to make co= nsensus calls on the mailing list, to confirm (or overturn) the decisions m= ade in Prague?

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Unbearable [mailto:unbearable-bounces@ie= tf.org] On Behalf Of Bill Cox
Sent: Saturday, August 29, 2015 12:46 PM
To: unbeara= ble@ietf.org
Cc: Nick Harper <nharper@google.com>
Subject: [Unbearable] Token Binding extension has incorrect size for= key array

=C2=A0

The spec and used a uint16 f= or the length of the key type array, but the keys are 8-bit values and are = not allowed to repeat.=C2=A0 This is clearly an error in the spec.=C2=A0 I used a 1-byte length instead.=C2=A0 No point wasting a byte = :)

=C2=A0

Two other issues in this spec:

=C2=A0

1) The server has to ignore this extension if the cl= ient broadcasts support for a newer version than the server knows about.=C2= =A0 This will result in Token Binding being disabled whenever the client su= pports a newer version than the server, or alternatively, clients will have to be careful to only broadcast older = well supported versions.=C2=A0 This should probably be a range of versions = rather than just one.=C2=A0 My preference is to simplify the version number= to 1 byte ,and send a 2-byte range. =C2=A00 would be the prototype version, and 1, would be the first official version.=C2= =A0 The server would pick a version from the range sent by the client and s= end the same version repeated (so that server and client headers are the sa= me size).=C2=A0 I do not think we need a 2-byte version for this simple extension.=C2=A0 Every byte counts :)

=C2=A0

2) The server currently has no way to inform the cli= ent what it's preferences are.=C2=A0 Instead, the server has to pick ju= st one.=C2=A0 In the case where the server prefers ECDSA, but the client al= ready has an RSA key pair, the server is likely to pick ECDSA, invalidating the client's key pair.=C2=A0 Instead, I se= nd a list of acceptable parameters both ways, in order of preference, where= the server sends a subset of the list received from the client.=C2=A0 This= allows the client to know that the server prefers ECDSA but is willing to continue support for RSA, and the client can choos= e to continue using the new key or not.

=C2=A0

Thanks,

Bill

--001a113d63241c9618051ea138b3-- From nobody Mon Aug 31 14:04:36 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1870E1A1B6B for ; Mon, 31 Aug 2015 14:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.511 X-Spam-Level: X-Spam-Status: No, score=0.511 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tH7anRc_hL8C for ; Mon, 31 Aug 2015 14:04:34 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d: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 CEC561B6242 for ; Mon, 31 Aug 2015 14:04:33 -0700 (PDT) Received: by qgeb6 with SMTP id b6so73951735qge.3 for ; Mon, 31 Aug 2015 14:04:32 -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:content-type; bh=skVD9bKjArTRwsD8o/VLizFUp2deIZJrkX9eROdBRAs=; b=i/P7Ytm2TuA3n/JzRPuH7sIX9N9t3wj3LPxzWLKTnM1WOlVTbgoDhEMKfOa+LxZG27 DJN4dhaLuolCteCh+5cGkY7FPvhGRFoA6Qiww84M8B4/g6qId4WF1zBT7H4KFuau/5xT +2p/toiFmKd9xBXovG3XmHh9ZMt1v18TXl50oUjBz+qoOZxhjrnfax07Pr+RC/4HPEGH 4+FGZKbZURF8guAsSR12W4z+TgTj8AETV6nknCguOuwc4OCXOLxFB78VeyzprIvHe9gq RGkPQyn+kt6FS2gWkwVGVzcKSYe+IpE7JmUT0z/1E6d685t0kX/otPWqMV5/K9ogGlbD 3zYg== 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 :content-type; bh=skVD9bKjArTRwsD8o/VLizFUp2deIZJrkX9eROdBRAs=; b=awlrP19IJd/k02Y+CrE6bd0LhXNiAmzwwFICJu3LCi9aKNxthE80nD7KjqwrPegDLM 1evVCjZYdvu7XEyf2JD+htkikoTXmi0VKEynnYqkhJTIUUBMw33Zj4F9wnq33vu6ER3m djbMsp8eQpl5PdXpEQBNt1L5HS3RfKpRDdmXGrgMGxPoMp0UEuRS4zo9i3n4nzodWt1V 9zCrm1MQ7GRRHlSMgFtsmpx8XcRlxtV465GfynxxiHVs8h+VsQXZmZpMLSydHHD158bS PdAAoTlFLAnGmcUc32XPWHB+Bz7qeua0HHUCDh1LTEkpVjRYPUqoAIyCm7Ew77se/2/f R3xw== X-Gm-Message-State: ALoCoQn54r1/9ueB33nsTVX7nZfnSpfBO1CI7DVg4u408MkrcsI8QK8kORJNvMKKUbTGbdD0oKwy MIME-Version: 1.0 X-Received: by 10.140.232.20 with SMTP id d20mr42544441qhc.72.1441055072524; Mon, 31 Aug 2015 14:04:32 -0700 (PDT) Received: by 10.55.84.65 with HTTP; Mon, 31 Aug 2015 14:04:32 -0700 (PDT) Date: Mon, 31 Aug 2015 14:04:32 -0700 Message-ID: From: Bill Cox To: unbearable@ietf.org Content-Type: multipart/alternative; boundary=001a1135482cb36dcd051ea1c7e9 Archived-At: Subject: [Unbearable] TLSUnique is only 96 bits. Is OK? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 21:04:35 -0000 --001a1135482cb36dcd051ea1c7e9 Content-Type: text/plain; charset=UTF-8 Sorry for bringing up another point that has already most likely been discussed in depth. The TLS unique value is 12 bytes of the hash of the first finish message. This is good enough probably for second pre-image resistance, but too weak for collision resistance. For use in Token Binding, I have not been able to come up with any realistic attack based on collisions. The basic attack would be someone trying to use your auth cookie on a machine/account that does not have access to the Token Binding private key. The attacker knows he needs to generate a signature of the TLS Unique value which will be accepted by the server. If he has your auth cookie, he might also have been able to monitor previous traffic, and could have collected a few thousand signed TLS Unique values. He might also be able to connect to the server a few thousand times trying to get a connection with a TLS Unique that he has seen before. Taking this attack to the extreme, suppose the attacker can cause the original device to make SSL connections to the server, and can generate 1 billion TLS Unique signatures. On the alternate device, he tries 1 billion new connections, to see if he gets a collision. The likelihood of such an attack succeeding is about 1 in 100 billion. I'm OK with these odds for this specific attack. However, I would not want people using the TLS Unique value for cryptographically binding other things to the TLS channel parameters. For example, I would not want credit card transactions to use the unique TLS unique as unique transaction identifier. Have we made it clear that the TLS Unique value should be used only in well understood cases, where collision resistance is not particularly important? Thanks, Bill --001a1135482cb36dcd051ea1c7e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Sorry for bringing up another point that has already most = likely been discussed in depth.

The TLS unique value is = 12 bytes of the hash of the first finish message.=C2=A0 This is good enough= probably for second pre-image resistance, but too weak for collision resis= tance.=C2=A0 For use in Token Binding, I have not been able to come up with= any realistic attack based on collisions.

The bas= ic attack would be someone trying to use your auth cookie on a machine/acco= unt that does not have access to the Token Binding private key.=C2=A0 The a= ttacker knows he needs to generate a signature of the TLS Unique value whic= h will be accepted by the server.=C2=A0 If he has your auth cookie, he migh= t also have been able to monitor previous traffic, and could have collected= a few thousand signed TLS Unique values.=C2=A0 He might also be able to co= nnect to the server a few thousand times trying to get a connection with a = TLS Unique that he has seen before.

Taking this at= tack to the extreme, suppose the attacker can cause the original device to = make SSL connections to the server, and can generate 1 billion TLS Unique s= ignatures.=C2=A0 On the alternate device, he tries 1 billion new connection= s, to see if he gets a collision.=C2=A0 The likelihood of such an attack su= cceeding is about 1 in 100 billion.

I'm OK wit= h these odds for this specific attack.=C2=A0 However, I would not want peop= le using the TLS Unique value for cryptographically binding other things to= the TLS channel parameters.=C2=A0 For example, I would not want credit car= d transactions to use the unique TLS unique as unique transaction identifie= r.=C2=A0 Have we made it clear that the TLS Unique value should be used onl= y in well understood cases, where collision resistance is not particularly = important?

Thanks,

Bill

--001a1135482cb36dcd051ea1c7e9-- From nobody Mon Aug 31 15:14:36 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48C11B5253 for ; Mon, 31 Aug 2015 15:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqeq9pDAnEtJ for ; Mon, 31 Aug 2015 15:14:33 -0700 (PDT) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (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 093C81B66EC for ; Mon, 31 Aug 2015 15:14:32 -0700 (PDT) Received: by qgtt94 with SMTP id t94so24144083qgt.1 for ; Mon, 31 Aug 2015 15:14:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=75hzqZfvx7AjXqqhpIJaQivI9qBaxwRszzuD9ZGzqF0=; b=SW3GlhyP6agPVTQtgp909wZRQ2Jabv9QO3d7UafbN00TZrOxlyFnzDJFx6t/dEt/MX uCtn2oODPUn68u9fJIbwJ5/00j0Fue+Jdq4S6DxmOEb4Crvx5gyL/JsGiqDStLbAPc2B fNyldvZVJOL49l8x+JB65tW013NR98MJo7Ojh5w8khgm2+1s19XLm4TnGDJLbbXLfaQb AR/JJXWbZdzH4Us0VLhonkwl32G9ToUJAgaYz0Db66XKIT02vZWJLk/7fENMBGjCMU5q VojckKUNs39tHCFMU0/OvPJkok7HKIXuF03O4br1qsg3J2EqBhxdfKLIcSsC+gTbF3N6 unFA== X-Gm-Message-State: ALoCoQk/zlCIsBCbahmhLk3bF8iYY5HavBoV+acOAJCOQUHcA5ZCsg6mz/Orfg5PRJNmu9G8jYTm X-Received: by 10.140.237.73 with SMTP id i70mr43885428qhc.37.1441059271797; Mon, 31 Aug 2015 15:14:31 -0700 (PDT) Received: from [192.168.8.102] ([181.202.55.19]) by smtp.gmail.com with ESMTPSA id p18sm4613825qge.40.2015.08.31.15.14.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 31 Aug 2015 15:14:31 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_63B7AFDF-7481-4B62-A96E-D9B2C4F1D85F"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: <6B0DDBE0-0DC0-47B9-B46B-3259AF246CE9@mnt.se> Date: Mon, 31 Aug 2015 19:14:28 -0300 Message-Id: References: <6B0DDBE0-0DC0-47B9-B46B-3259AF246CE9@mnt.se> To: Leif Johansson X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Tokbind WG , Dirk Balfanz Subject: Re: [Unbearable] Interim meeting X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 22:14:35 -0000 --Apple-Mail=_63B7AFDF-7481-4B62-A96E-D9B2C4F1D85F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 At this point I don=E2=80=99t expect to be in North America before the = week immediately preceding Yokohama now. John B. > On Aug 31, 2015, at 5:05 PM, Leif Johansson wrote: >=20 >=20 >=20 >> 31 aug 2015 kl. 21:54 skrev Dirk Balfanz : >>=20 >> Hi token binders, =20 >>=20 >> where are we at with scheduling an interim meeting before Yokohama? >>=20 >=20 > I haven't seen anything close to consensus unfortunately. >=20 >> Dirk. >>=20 >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable --Apple-Mail=_63B7AFDF-7481-4B62-A96E-D9B2C4F1D85F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTA4MzEyMjE0MjlaMCMGCSqGSIb3DQEJBDEWBBTNDQohik5UiWOsh8s/555Z zYHXOTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBQ+YJqZhbN2roZU+1y6NTFnxBGN57ob8H+fHi5cizkMJVloKtye821 Mwd/98RLqV/myCxvr1VAUtSlj7D6/mOkIt9AxMwCjYDMDNKy2S+mjECBMbOfw4K0vbaEmivnDOA/ 8ODtjtRbjcvc6eNx9WN6eaMx+enQfesliPJmYnQ4iGP8lWKFTACdfsFywPkX6BUkIpZkfcuxDFzM omoWEB8Dma/wFo3fxGCz6kdrKnJ7/eNbt40QeKYb74AqR6nSkbzAG4QOcAhGPW57xjRsZPGbYJRv PT/HQxRMeO+PQHtputG/lPjw0I3uO4id9j/rwzNBMnIIHG7HCjhO6kNpYPJoAAAAAAAA --Apple-Mail=_63B7AFDF-7481-4B62-A96E-D9B2C4F1D85F-- From nobody Mon Aug 31 15:48:57 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9FB1B364C for ; Mon, 31 Aug 2015 15:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0p4Y8_v1R3L for ; Mon, 31 Aug 2015 15:48:49 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0126.outbound.protection.outlook.com [207.46.100.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 340CF1B4A74 for ; Mon, 31 Aug 2015 15:48:49 -0700 (PDT) Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.256.15; Mon, 31 Aug 2015 22:48:48 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0256.013; Mon, 31 Aug 2015 22:48:48 +0000 From: Andrei Popov To: John Bradley , Leif Johansson Thread-Topic: [Unbearable] Interim meeting Thread-Index: AQHQ5CbjZ1Wqr+yK9ku/TlIEF0BDNZ4miICAgAAkAACAAAk7sA== Date: Mon, 31 Aug 2015 22:48:48 +0000 Message-ID: References: <6B0DDBE0-0DC0-47B9-B46B-3259AF246CE9@mnt.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:4::1d2] x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:/YH3aSsz5wV7AXP1lNnAc7BrDbnhozLArjTydKJG1J9Oywvzw6P48oOGEwX6j3cyWn7Ms4QHuhRggfn42fslbhgngu44fZEtJBbmREHLJg4FNQf0QdQo31QxioWYG9JuUcDz81LY6RE+JtDBGr3H3w==; 24:GeD9Sx+tkkdKFBM22+gTlzfNX4YBDqvSeDlwUmzuNaeBTNyG9tg27UnmVf1ZK3miU8IyyzGYILrtYMhjViLBGSPZtyrX8nD418E7kSvAqIs=; 20:ILixicx+pTkesCCs2FWkZZfbGSxEqqh9fQ/56hcQooOmzviWlct3z/2aN0ITOBxasvfQkvAQcE93cdqdhzlXXg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(8121501046)(5005006)(3002001); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 0685122203 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(13464003)(377454003)(24454002)(189002)(77156002)(87936001)(68736005)(5005710100001)(106116001)(74316001)(5001770100001)(5003600100002)(62966003)(5001960100002)(189998001)(19580395003)(97736004)(86612001)(50986999)(4001540100001)(101416001)(92566002)(2950100001)(54356999)(5001860100001)(19580405001)(81156007)(5001830100001)(106356001)(8990500004)(10400500002)(77096005)(105586002)(5004730100002)(5002640100001)(64706001)(10290500002)(5007970100001)(46102003)(2656002)(99286002)(10090500001)(33656002)(76176999)(122556002)(40100003)(15975445007)(76576001)(102836002)(2900100001)(86362001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) 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: 31 Aug 2015 22:48:48.0660 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Cc: Tokbind WG , Dirk Balfanz Subject: Re: [Unbearable] Interim meeting X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 22:48:51 -0000 VGhlbiBwZXJoYXBzIHdlIHNob3VsZCBqdXN0IHNraXAgdGhlIEludGVyaW0gYW5kIGdvIHN0cmFp Z2h0IHRvIFlva29oYW1hPw0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogVW5iZWFyYWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvaG4gQnJhZGxleQ0KU2VudDogTW9uZGF5LCBBdWd1c3Qg MzEsIDIwMTUgMzoxNCBQTQ0KVG86IExlaWYgSm9oYW5zc29uIDxsZWlmakBtbnQuc2U+DQpDYzog VG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZz47IERpcmsgQmFsZmFueiA8YmFsZmFuekBn b29nbGUuY29tPg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBJbnRlcmltIG1lZXRpbmcNCg0K QXQgdGhpcyBwb2ludCBJIGRvbuKAmXQgZXhwZWN0IHRvIGJlIGluIE5vcnRoIEFtZXJpY2EgYmVm b3JlIHRoZSB3ZWVrIGltbWVkaWF0ZWx5IHByZWNlZGluZyBZb2tvaGFtYSBub3cuDQoNCkpvaG4g Qi4NCg0KPiBPbiBBdWcgMzEsIDIwMTUsIGF0IDU6MDUgUE0sIExlaWYgSm9oYW5zc29uIDxsZWlm akBtbnQuc2U+IHdyb3RlOg0KPiANCj4gDQo+IA0KPj4gMzEgYXVnIDIwMTUga2wuIDIxOjU0IHNr cmV2IERpcmsgQmFsZmFueiA8YmFsZmFuekBnb29nbGUuY29tPjoNCj4+IA0KPj4gSGkgdG9rZW4g YmluZGVycywgIA0KPj4gDQo+PiB3aGVyZSBhcmUgd2UgYXQgd2l0aCBzY2hlZHVsaW5nIGFuIGlu dGVyaW0gbWVldGluZyBiZWZvcmUgWW9rb2hhbWE/DQo+PiANCj4gDQo+IEkgaGF2ZW4ndCBzZWVu IGFueXRoaW5nIGNsb3NlIHRvIGNvbnNlbnN1cyB1bmZvcnR1bmF0ZWx5Lg0KPiANCj4+IERpcmsu DQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+PiBVbmJlYXJhYmxlIG1haWxpbmcgbGlzdA0KPj4gVW5iZWFyYWJsZUBpZXRmLm9yZw0KPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBVbmJlYXJh YmxlIG1haWxpbmcgbGlzdA0KPiBVbmJlYXJhYmxlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZQ0KDQo= From nobody Mon Aug 31 19:39:03 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2A61B5B56 for ; Mon, 31 Aug 2015 19:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.743 X-Spam-Level: X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_2ITT0ui6yi for ; Mon, 31 Aug 2015 19:39:00 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9021B5931 for ; Mon, 31 Aug 2015 19:39:00 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 2DD4959407C for ; Mon, 31 Aug 2015 19:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=EkysHQYuph61vlyoXzIv 9Jl7fuY=; b=I7eLY3W/defcliMwp1M39KmdRdmj74Gn6LW7z/V6AE8nRXrOLInf NhJ9mnpuIJpWJWwMX8JdkfSfpYvebulInWRrdA9Uq6pdIHrmorf1N486T4pIjzCo GP6atbkhQM01TWo7jjbIXta32AC2elACY5EopWWma9AF3RHz0kXEqxk= Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com [209.85.220.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 1BD0159405E for ; Mon, 31 Aug 2015 19:39:00 -0700 (PDT) Received: by qkcj187 with SMTP id j187so27614569qkc.2 for ; Mon, 31 Aug 2015 19:38:59 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.129.59.9 with SMTP id i9mr24150516ywa.100.1441075139660; Mon, 31 Aug 2015 19:38:59 -0700 (PDT) Received: by 10.129.109.88 with HTTP; Mon, 31 Aug 2015 19:38:59 -0700 (PDT) In-Reply-To: References: Date: Mon, 31 Aug 2015 21:38:59 -0500 Message-ID: From: Nico Williams To: Bill Cox Content-Type: multipart/alternative; boundary=001a114325bccb5a5e051ea673ff Archived-At: Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] TLSUnique is only 96 bits. Is OK? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 02:39:01 -0000 --001a114325bccb5a5e051ea673ff Content-Type: text/plain; charset=UTF-8 On Monday, August 31, 2015, Bill Cox wrote: > [...] The use cases envisioned in RFC5056 are somewhat limited. Uses of channel bindings in new ways require additional analysis. I'll have to refresh my memory as to the token binding use... But yes, if the threat model allows the attacker to know the change binding and to attempt many connections then yes, 96 bits behind to look short. Nico -- --001a114325bccb5a5e051ea673ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, August 31, 2015, Bill Cox <waywardgeek@google.com> wrote:

> [...]

The use cases envisioned in RFC5056 are somewhat limited.=C2=A0 Us= es of channel bindings in new ways require=C2=A0additional analysis.=C2=A0 = I'll have to refresh my memory as to the token binding use...=C2=A0 But= yes, if=C2=A0the threat model allows the attacker to know the change bindi= ng and to attempt many connections then yes, 96 bits behind to look short.<= span>

Nico

--=C2=A0

--001a114325bccb5a5e051ea673ff--