From nobody Sun Apr 2 19:15:05 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5A1126DCA for ; Sun, 2 Apr 2017 19:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbwwf0YTm1rq for ; Sun, 2 Apr 2017 19:14:59 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7376B127071 for ; Sun, 2 Apr 2017 19:14:58 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id z204so123611435vkd.1 for ; Sun, 02 Apr 2017 19:14:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=jCECSWXEukNTiqBBOIaxhzSbFF/5RgbjaphFbQOjAl0=; b=nymRFK1bNW+Ic4JNgbkjvZoqfDqXsmAsDasc3vMPSdiov6+liPedKTRJahGcAavoH/ rUp0GWCoGjVx9ors2f487p6Tf5lKK9hTbkIClkjoTu5QoyX4ZG6Qhsvb7aW7ToPoQ7nZ 1DVakZRyYTHdAl2elXzGeNoSxG9/OxcpNeOHG/xxtnA0Dg1ovgMZPTkpD7EJH2R4sN0K pvIBuTZvF0Df2zBuBtAMWYXpPK8Eezy3zWAB68IjuVvDeSMj2q/Oixi9SrIuTuOr+T+6 OvzgxdbezJkmf2Kn4bmIjJu2SqOHECOE9whnBlGgxFFtqqZVTPGt+wlYKkhaoKIGz15v I9nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jCECSWXEukNTiqBBOIaxhzSbFF/5RgbjaphFbQOjAl0=; b=fgLyyDxMj5CdWSwtQ/+DSUSMDwfpIdLS009pGE97eTKtg98TmA28mslat4h94LzZ9E whb5hPSDneZrDd7Ss7aERbpS5ekf54/JmM9Bx+VAwhP5nid2gSgSXcQjvgumvL05pIha C8ca14TelFcA2nFmfNhHccS1rQXxuyYDv0pwUTbmNzsjIrXvi6PkLFOQrXVegv7Zm7c9 9LSIhHWD0UxjhZKG2ultvzy3/MYyMD4+9sXEACN+F/GbMkkvRYC/9sVa0X7qEvT2aZ7B pe6ilby08SnCYkPT/9UQp4hNX5n00Zhk6w61KV+v/fFeXHLlnvs20gzyQ6nCahWAg0y/ edsA== X-Gm-Message-State: AFeK/H2OcfvLzcFCbakn913R8PV4DNVpuyvBWGYvqOwJdR/hUatbJrKwKU/QZ/7xuRClrXLnkDlSgdr0jv/qkg== X-Received: by 10.159.55.142 with SMTP id q14mr5386032uaq.40.1491185697487; Sun, 02 Apr 2017 19:14:57 -0700 (PDT) MIME-Version: 1.0 From: Nick Sullivan Date: Mon, 03 Apr 2017 02:14:46 +0000 Message-ID: To: unbearable@ietf.org Content-Type: multipart/alternative; boundary=94eb2c041276cb027f054c39b916 Archived-At: Subject: [Unbearable] Removing explicit public key crypto from Token Binding X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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, 03 Apr 2017 02:15:02 -0000 --94eb2c041276cb027f054c39b916 Content-Type: text/plain; charset=UTF-8 Please pardon the timing of this review, I know it's not fun receiving critiques and large suggestions so late in the process but I think there are serious issues with the Token Binding Protocol draft that should be discussed. The introduction of public key crypto at the application layer seems like a major downside to the current Token Binding Protocol draft. We went through a similar design in the Secondary Certificate Authentication in HTTP/2 draft, and learned a bunch of lessons that could be applied to Token Binding. From these lessons, I have some suggestions that could result in a much shorter draft that is less complex and will result in a lower maintenance burden going forward. Long story short: I think the explicit public key crypto pieces should be removed from this draft. First, let me spell out some of the downsides of introducing public key crypto to the application layer: a) Public key crypto is hard to do right. Historically, applications have done a bad job at handling public key cryptography. You don't have to look far past the recent curve point validation issues in JWS libraries to see this. Exposing "low-level" APIs like digital signature validation to applications is best avoided if you want a secure application. For example, things like asking an HTTP server to properly seed the randomness in an ECDSA signature expands the scope of what developers at this layer are used to dealing with. b) Maintenance burden. Every new signature algorithm to be used here needs to be added to the new IANA registry. Every time this happens, this document needs to be updated. Which working group is responsible for updating drafts to add new algorithms or remove compromised ones once TOKBIND is over and we're discussing post-quantum signatures? This document is already behind the curve by supporting P-256 instead of the CFRG-chosen signature algorithms ed25519 and ed448. c) It's done better elsewhere. Correctly defining how to do public key crypto in a draft like this seems duplicative of other work. Defining the tricky part of actually binding a public key into TLS should be done with the support of those who have experience with doing this wrong and learning from their mistakes, like the TLS working group itself. d) Layering. This draft in particular is bound the semantics of several TLS extensions. Not only does the application need to know the result of the token binding extension, it needs to know whether or not the extended master secret has been used. Depending on the correct calculation of a master secret is an esoteric point that applications may forget to enforce. Channel-ID is problematic because it introduces additional complexity at the TLS layer and introduces privacy issues. Token Binding improves this by putting the messages at the application layer, but at the cost of also bringing the public key cryptography into the application. Is there a middle ground? I suggest there is. Here's a proposal: rather than defining the signature algorithm and the binding to the exporter at the application layer, leverage the TLS library itself to do the binding. This can be done with Exported Authenticators ( https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-01). The basic idea is that the application provides a private key and certificate to the TLS library and the TLS library returns a binding of that certificate to the connection called an "exported authenticator". This opaque binding can be transported by the application from one party to another. The receiving party can pass the exported authenticator into the TLS library, which returns the certificate if it's valid and bound to the current connection. Under the hood, the exported authenticator looks like the triplet of TLS messages {Certificate, CertificateVerify and Finished} with an exporter as the handshake context. It maps very closely to what Token Binding is doing now, but eliminates the need for public key crypto in the application. Instead, the application layer just needs to pass around opaque blobs that can be decoded by the TLS library into certificates. To be more concrete about how this could work for the Token Binding protocol, a self-signed certificate could be used in place of the TokenBindingPublicKey and the exported authenticator could be used in place of the TokenBinding. The tokenbinding_type and extensions could be embedded in the certificate as X.509 extensions. Or application-defined TLS extensions. I don't know the exact right mapping, but it doesn't seem difficult to define. My proposed change would bring the following benefits: - signature algorithms support would evolve with TLS libraries rather than with application libraries and updates to this document - the "token binding key parameters" registry would no longer be needed - several pages would be eliminated from this draft - no public key crypto functions added to applications that don't currently use public key crypto Nick P.S. This proposal also has the interesting benefit of allowing token binding to be symmetrical. Both clients and servers could created token bindings. Currently the same exporter is used for both so there's a possibility of putting server token binding in the place of client token bindings. --94eb2c041276cb027f054c39b916 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Please pardon the timing of this review, I know it= 9;s not fun receiving critiques and large suggestions so late in the proces= s but I think there are serious issues with the Token Binding Protocol draf= t that should be discussed.

The introduction of public ke= y crypto at the application layer seems like a major downside to the curren= t Token Binding Protocol draft. We went through a similar design in the Sec= ondary Certificate Authentication in HTTP/2 draft, and learned a bunch of l= essons that could be applied to Token Binding. From these lessons, I have s= ome suggestions that could result in a much shorter draft that is less comp= lex and will result in a lower maintenance burden going forward. Long story= short: I think the explicit public key crypto pieces should be removed fro= m this draft.

First, let me spell out some of the downsid= es of introducing public key crypto to the application layer:
a) Public key crypto is hard to do right.
Historically, applications ha= ve done a bad job at handling public key cryptography. You don't have t= o look far past the recent curve point validation issues in JWS libraries t= o see this. Exposing "low-level" APIs like digital signature vali= dation to applications is best avoided if you want a secure application. Fo= r example, things like asking an HTTP server to properly seed the randomnes= s in an ECDSA signature expands the scope of what developers at this layer = are used to dealing with.
b) Maintenance burden.
Every new= signature algorithm to be used here needs to be added to the new IANA regi= stry. Every time this happens, this document needs to be updated. Which wor= king group is responsible for updating drafts to add new algorithms or remo= ve compromised ones once TOKBIND is over and we're discussing post-quan= tum signatures? This document is already behind the curve by supporting P-2= 56 instead of the CFRG-chosen signature algorithms ed25519 and ed448.
c) It's done better elsewhere.
Correctly defining how to do= public key crypto in a draft like this=20 seems duplicative of other work. Defining the tricky part of actually bindi= ng a public key into TLS should be done with the support of those who have = experience with doing this wrong and=20 learning from their mistakes, like the TLS working group itself.
d) Laye= ring.
This draft in particular is bound the semantics of several TLS ext= ensions. Not only does the application need to know the result of the token= binding extension, it needs to know whether or not the extended master sec= ret has been used. Depending on the correct calculation of a master secret = is an esoteric point that applications may forget to enforce.

=
Channel-ID is problematic because it introduces additional complexity = at the TLS layer and introduces privacy issues. Token Binding improves this= by putting the messages=C2=A0 at the application layer, but at the cost of= also bringing the public key cryptography into the application. Is there a= middle ground? I suggest there is.


Here&#= 39;s a proposal: rather than defining the signature algorithm and the bindi= ng to the exporter at the application layer, leverage the TLS library itsel= f to do the binding. This can be done with Exported Authenticators (https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-01= ). The basic idea is that the application provides a private key and ce= rtificate to the TLS library and the TLS library returns a binding of that = certificate to the connection called an "exported authenticator".= This opaque binding can be transported by the application from one party t= o another. The receiving party can pass the exported authenticator into the= TLS library, which returns the certificate if it's valid and bound to = the current connection.

Under the hood, the exported authenticator l= ooks like the triplet of TLS messages {Certificate, CertificateVerify and F= inished} with an exporter as the handshake context. It maps very closely to= what Token Binding is doing now, but eliminates the need for public key cr= ypto in the application. Instead, the application layer just needs to pass = around opaque blobs that can be decoded by the TLS library into certificate= s.

To be more concrete about how this could work for the Token Bindi= ng protocol, a self-signed certificate could be used in place of the TokenB= indingPublicKey and the exported authenticator could be used in place of th= e TokenBinding. The tokenbinding_type and extensions could be embedded in t= he certificate as X.509 extensions. Or application-defined TLS extensions. = I don't know the exact right mapping, but it doesn't seem difficult= to define.

My proposed change would bring the following benefits:
- signature algorithms support would evolve with TLS libraries= rather than with application libraries and updates to this document
- the "token binding key parameters" registry would no lo= nger be needed
- several pages would be eliminated from this = draft
- no public key crypto functions added to applications = that don't currently use public key crypto

Nick

P.S.
This proposal also ha= s the interesting benefit of allowing token binding to be symmetrical. Both= clients and servers could created token bindings. Currently the same expor= ter is used for both so there's a possibility of putting server token b= inding in the place of client token bindings.

--94eb2c041276cb027f054c39b916-- From nobody Mon Apr 3 09:47:56 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7F5129478 for ; Mon, 3 Apr 2017 09:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-yUAlKLSRZM for ; Mon, 3 Apr 2017 09:47:52 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9377612709D for ; Mon, 3 Apr 2017 09:47:52 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id d188so144305348vka.0 for ; Mon, 03 Apr 2017 09:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Dgbq0d1Vw9sqJ3ZtDXgbDdNZFJJmE5Yh4abYtISFQGU=; b=L6pwMEqZkF/NezCNAxbBJCi/cXmh9AczHFvbcC0rXKM8OZh8vXsuD9YKrC7otVON97 7b4hwHgahYqOzWkRBbPNIZxXN5mMnwSoeTC5DkwmR/PCEUpV4TxsItk0laKOcEQTQaGo Ug34B7BZvKegbEipKFbscHzvTx7Lfb/OmLGKu2yzR3bw4Zmzz6NflDiHIDVUPfUnrYUq j/BVW+NTMdgHEWdN1ETYz7ESPbkXL3RdEDONLgBYVFooCMqJGuXT9GaDZPTZpgT2AklM CgfPpvjxI/2HP2Dm++0DUjoL0DlP5hEe3sexszdDXohmB1sbuq+7aZU3i5JMPF4lqwMn bG+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Dgbq0d1Vw9sqJ3ZtDXgbDdNZFJJmE5Yh4abYtISFQGU=; b=MJF8mORTYcaEMcIay44P4jz0Bfnox2vM/s3C5pSfSRL1TkHgHgjqG2KCdoxSXNnSCu 86m9NFSV9zbshMOdmg2OUjLuZR0BnI/oIDG+jm/lcswlih1zxFxvdeAoBDEYtGEFj1eT 6P6Lab0ZsjZJHUckaGRUWiqjWUtim1ppqvdcaazsZ9RPjIwmTAqQALSxOElqrFDdqaW+ s4fkvfzAnRkz1DZyWDEvWMF3Oz8BunVfs9TwpuekEQ/cZnIaJq3hhVCddWwClqRqVc/m OeecC+h2i/Cc8iUAS56etlJS/Y4zczYEaW1fLakrwpPoH9RG46N6HiHizVJdKZO1dYxy J4Lg== X-Gm-Message-State: AFeK/H3S9lylfQTUQot5NGSe2RO55MtMQG6Nj+LrBORxewp1GDjrvVNIGlW6IOK8jpqw0EeHWp2TENxq5OD5jA== X-Received: by 10.176.83.124 with SMTP id y57mr7909621uay.141.1491238070850; Mon, 03 Apr 2017 09:47:50 -0700 (PDT) MIME-Version: 1.0 From: Nick Sullivan Date: Mon, 03 Apr 2017 16:47:40 +0000 Message-ID: To: "unbearable@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1927007d1c32054c45eb5c Archived-At: Subject: [Unbearable] Binding tokens to scope in HTTP X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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, 03 Apr 2017 16:47:55 -0000 --94eb2c1927007d1c32054c45eb5c Content-Type: text/plain; charset=UTF-8 The token binding header does not have any identity bound to it. This is potentially problematic because it makes it much more likely that this protocol is vulnerable to unknown key share issues. Unknown key share attacks happen when a public key is used without binding it to an identity by a signature. For example, Richard Barnes recently published a draft describing how DANE with raw keys was vulnerable to this style of: https://tools.ietf.org/html/draft-barnes-dane-uks-00. In section 2.1. of draft-ietf-tokbind-https, the key pair scoping is defined to be eTLD+1. Depending on the threat model, this requirement can be subverted. Consider an attacker who has access to read and modify headers, but not private keys. Imagine a buggy/malicious service worker or something else of this sort. Now imagine a site with a.example.com and b.example.com and a wildcard *.example.com certificate. The attacker can take token binding headers from a.example.com and put them on requests to b.example.com and the cookies set on b.example.com will be bound to a.example.com's key. This doesn't sound like a large issue, but it's indicative of the type of subtle problems not binding the key to a context can cause. If the token context was bound to the scope by including the eTLD+1 in the (or the origin if the browser intends to use stricter token scoping), *and* this scope was covered by the signature then this would not be possible. The server could check the host header against the token context and then refuse the token binding for new cookies. A logical place to put this would be in the extensions of the token binding structure, but unfortunately the extensions is not signed and so can be modified. Is there a reason the extensions field of the TokenBinding structure is not signed by the private key? Nick --94eb2c1927007d1c32054c45eb5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The token binding header doe= s not have any=20 identity bound to it. This is potentially problematic because it makes it m= uch more likely that this protocol=20 is vulnerable to unknown key share issues.
Unknown key share attacks happen when a pu= blic key is used without binding it to an identity by a signature. For exam= ple, Richard Barnes recently published a draft describing how DANE with raw= keys was vulnerable to this style of: https://tools.ietf.org/html/draft-barnes-dane-= uks-00.

In section 2.1. of draft-ietf-tokbind-https, the key pair scoping is = defined to be eTLD+1. Depending on the threat model, this requirement can b= e subverted.

Consider an attacker who has access to read and modify headers, but = not private keys. Imagine a buggy/malicious service worker or something els= e of this sort. Now imagine a site with a.= example.com and b.example.com and = a wildcard *.example.com certificate. Th= e attacker can take token binding headers from a.example.com and put them on requests to b.example.com and the cookies set on b.example.com will be bound to a.example.com's key.

This doesn't sound like a large is= sue, but it's indicative of the type=20 of subtle problems not binding the key to a context can cause.

If the token context was bound to the scope by in= cluding the eTLD+1 in the (or the origin if the browser intends to use stri= cter token scoping), *and* this scope was covered by the signature then thi= s would not be possible. The server could check the host header against the= token context and then refuse the token binding for new cookies.

A = logical place to put this would be in the extensions of the token binding s= tructure, but unfortunately the extensions is not signed and so can be modi= fied. Is there a reason the extensions field of the TokenBinding structure = is not signed by the private key?

Nick
--94eb2c1927007d1c32054c45eb5c-- From nobody Mon Apr 3 10:24:15 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67767129495 for ; Mon, 3 Apr 2017 10:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38r4YauXccB7 for ; Mon, 3 Apr 2017 10:24:11 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C668129469 for ; Mon, 3 Apr 2017 10:24:11 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id g195so48482328qke.2 for ; Mon, 03 Apr 2017 10:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NvXiYhGhHEIquZ/eAOJzkKWr0ZySgYRotIf48nY1Y1I=; b=kFDjcUdH8FpENXbKSan2OXSiuSD6sKHgHkRf0/XP8gZuE3DkcBzmMSkwQ4w3mCEM75 W7VQAEWbS4M0TkipBMMOCJ7Ra3LpEpBz5NNAuTCGLdnzsO5LQEkxUgmnAGZxNTbhYrSu wHzcPMEbUAz0Kh7rRdKS+dr1w/c6A/fHAZQZLtejpCOmcyTt4ENpPbvP+5xyKNluLbq4 D0voM5jl7b0/gZogWcsKbMMX82Vrf9LhY3gtvdLibGDDam57y5j86R1G9BhyhXuzufUb feJssitMWDGWfsgzxYJMl1oTJsbLXTqkP/LvHG8BfnuJhkVjF50zBnMfpklgiNQNlMJw vePw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NvXiYhGhHEIquZ/eAOJzkKWr0ZySgYRotIf48nY1Y1I=; b=Bb5Bq1xG8QbYUl9WnHVX+lcaxjCsCSUAE9f3nMBQifOWIS1E5G2lXCTd0j7dB3vvDY JBGgZTwUI2e3+3dUdk54cHrcaW2104uyHU+27yPAx5MTJyExyYCo2qJw/C2Z5H+bTGi+ yrOwvopJSI/5Lr3SFqALkC8KcSasVrXU47O5cuW1hhN72YzISud3YE/mTwtWsQbDWxIJ cayuPf04GgXmQUha8osx72wwPGsuKZ+WS9Pz6xlEyY3btmPEk9NQVYjef65epfOCEvdH clnXY1E9zEdmMPvqHZ0lWkfKWn0IV972ABJHEvnHCXq2accMxi9QRZHB5TnM0RSAFwKF ZDlQ== X-Gm-Message-State: AFeK/H1/TLAqyrpHTMT0/03CZZYnUOohpC1NH9AiPCKuwCuEOuUxcvnaWECoCbXyuCP67om/SWqT0zB2gPcY02It X-Received: by 10.55.147.129 with SMTP id v123mr16787013qkd.230.1491240250140; Mon, 03 Apr 2017 10:24:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.21.134 with HTTP; Mon, 3 Apr 2017 10:24:09 -0700 (PDT) In-Reply-To: References: From: Bill Cox Date: Mon, 3 Apr 2017 10:24:09 -0700 Message-ID: To: Nick Sullivan Cc: "unbearable@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c08bb6262e436054c466d55 Archived-At: Subject: Re: [Unbearable] Binding tokens to scope in HTTP X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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, 03 Apr 2017 17:24:14 -0000 --94eb2c08bb6262e436054c466d55 Content-Type: text/plain; charset=UTF-8 The extensions used to be covered in earlier drafts. I forget why this was dropped, but IIRC, it was discussed on this list. In any case, it sounds like there are a number of people who would prefer to change TB extension numbers and effectively be a new extension rather than use the header's extension capability. Your example has a minor error: eTLD+1 for example.com is example.com, so a.example.com would have the same TB key as b.example.com. However, the idea for the attack is valid. eTLD+1 based security seems to be a kludge. I felt that binding to the sites covered by a certificate might make sense, but it does not work out. For example, we have certs for gmail.com and youtube.com, and certificates covering both, IIRC. We could use the same TB sig, bound to that certificate, for a lot of sites, reducing TB signature overhead. It also makes sense to me from a security perspective: the server has proven ownership of a collection of domains, so just bind to that. This would eliminate all the eTLD+1 security issues. However, we can't count on seeing the same certificate all the time. Sometimes a server will present a login.example.com certificate on one connection, and *.example.com on another. Most likely, the cookie that is used for auth would be bound to login.example.com, and would be rejected for all other *. example.com domains. I like the idea of signing extensions and also the host name from the host header. Bill On Mon, Apr 3, 2017 at 9:47 AM, Nick Sullivan wrote: > The token binding header does not have any identity bound to it. This is > potentially problematic because it makes it much more likely that this > protocol is vulnerable to unknown key share issues. > > Unknown key share attacks happen when a public key is used without binding > it to an identity by a signature. For example, Richard Barnes recently > published a draft describing how DANE with raw keys was vulnerable to this > style of: https://tools.ietf.org/html/draft-barnes-dane-uks-00. > > In section 2.1. of draft-ietf-tokbind-https, the key pair scoping is > defined to be eTLD+1. Depending on the threat model, this requirement can > be subverted. > > Consider an attacker who has access to read and modify headers, but not > private keys. Imagine a buggy/malicious service worker or something else of > this sort. Now imagine a site with a.example.com and b.example.com and a > wildcard *.example.com certificate. The attacker can take token binding > headers from a.example.com and put them on requests to b.example.com and > the cookies set on b.example.com will be bound to a.example.com's key. > > This doesn't sound like a large issue, but it's indicative of the type of > subtle problems not binding the key to a context can cause. > > If the token context was bound to the scope by including the eTLD+1 in the > (or the origin if the browser intends to use stricter token scoping), *and* > this scope was covered by the signature then this would not be possible. > The server could check the host header against the token context and then > refuse the token binding for new cookies. > > A logical place to put this would be in the extensions of the token > binding structure, but unfortunately the extensions is not signed and so > can be modified. Is there a reason the extensions field of the TokenBinding > structure is not signed by the private key? > > Nick > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --94eb2c08bb6262e436054c466d55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The extensions used to be covered in earlier drafts.=C2=A0= I forget why this was dropped, but IIRC, it was discussed on this list.=C2= =A0 In any case, it sounds like there are a number of people who would pref= er to change TB extension numbers and effectively be a new extension rather= than use the header's extension capability.

Your ex= ample has a minor error: =C2=A0eTLD+1 for ex= ample.com is example.com, so a.example.com would have the same TB key as <= a href=3D"http://b.example.com">b.example.com.=C2=A0 However, the idea = for the attack is valid. =C2=A0eTLD+1 based security seems to be a kludge.= =C2=A0 I felt that binding to the sites covered by a certificate might make= sense, but it does not work out.=C2=A0 For example, we have certs for gmail.com and y= outube.com, and certificates covering both, IIRC.=C2=A0 We could use th= e same TB sig, bound to that certificate, for a lot of sites, reducing TB s= ignature overhead.=C2=A0 It also makes sense to me from a security perspect= ive: the server has proven ownership of a collection of domains, so just bi= nd to that.=C2=A0 This would eliminate all the eTLD+1 security issues.=C2= =A0 However, we can't count on seeing the same certificate all the time= .=C2=A0 Sometimes a server will present a login.example.com certificate on one connection, and *.example.com on another.=C2=A0 Most likely, the cooki= e that is used for auth would be bound to login.example.com, and would be rejected for all other *.example.com domains.

I li= ke the idea of signing extensions and also the host name from the host head= er.

Bill


On Mon, Apr 3, 2017 at 9:47 AM, = Nick Sullivan <nicholas.sullivan@gmail.com> wrote:=
The token binding header does not have any=20 identity bound to it. This is potentially problematic because it makes it m= uch more likely that this protocol=20 is vulnerable to unknown key share issues.

= Unknown key share attacks happen when a public key is used without binding = it to an identity by a signature. For example, Richard Barnes recently publ= ished a draft describing how DANE with raw keys was vulnerable to this styl= e of: https://tools.ietf.org/html/draft-barnes-dane-uks-00= .

In section 2.1. of draft-ietf-tokbind= -https, the key pair scoping is defined to be eTLD+1. Depending on the thre= at model, this requirement can be subverted.

Consider an attacker who has access to read and modify headers, but n= ot private keys. Imagine a buggy/malicious service worker or something else= of this sort. Now imagine a site with a.example.com and b.example.com and a wildcard *.example.com certificate. The attacker can take to= ken binding headers from a.example.com and put them on requests to b.example.com and the cookies set on b.example.com will be bound to = a.example.com's = key.

This doesn't sound like a large issue, but it's indicat= ive of the type=20 of subtle problems not binding the key to a context can cause.

If the token context was bou= nd to the scope by including the eTLD+1 in the (or the origin if the browse= r intends to use stricter token scoping), *and* this scope was covered by t= he signature then this would not be possible. The server could check the ho= st header against the token context and then refuse the token binding for n= ew cookies.

A logical place to put this would be in the extensions o= f the token binding structure, but unfortunately the extensions is not sign= ed and so can be modified. Is there a reason the extensions field of the To= kenBinding structure is not signed by the private key?

Nick

_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearabl= e


--94eb2c08bb6262e436054c466d55-- From nobody Mon Apr 3 10:58:44 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93921294BB for ; Mon, 3 Apr 2017 10:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZkHxf414Zlz for ; Mon, 3 Apr 2017 10:58:39 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0104.outbound.protection.outlook.com [104.47.40.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55BD912946D for ; Mon, 3 Apr 2017 10:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sr+RDtNbXw7FnTNyJLlYGuMnQJQuTcaB+5wFlq0KGVg=; b=X3ILblv35idBdccmhWsFRNoZw8TkSi9Pguhwn03bG3R3mec/+nfN2CZs+MGQqysK2lIc/FmJrqJW9dcFD0O7Qb0DNEJuvlzwjZ87Dmr704nXBF8xFfGlWZSBdPtzpwUDtQRmlkKh6+dvWhTHiKez96ArRuZdlUlqLH0Ur6cewxg= Received: from SN1PR21MB0096.namprd21.prod.outlook.com (10.161.254.16) by SN1PR21MB0096.namprd21.prod.outlook.com (10.161.254.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.0; Mon, 3 Apr 2017 17:58:38 +0000 Received: from SN1PR21MB0096.namprd21.prod.outlook.com ([10.161.254.16]) by SN1PR21MB0096.namprd21.prod.outlook.com ([10.161.254.16]) with mapi id 15.01.1019.015; Mon, 3 Apr 2017 17:58:37 +0000 From: Andrei Popov To: Nick Sullivan , "unbearable@ietf.org" Thread-Topic: [Unbearable] Removing explicit public key crypto from Token Binding Thread-Index: AQHSrCAeHzgU+tdKjkadVTeO7pYsxqGz6wVA Date: Mon, 3 Apr 2017 17:58:37 +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: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:1::4ca] x-microsoft-exchange-diagnostics: 1; SN1PR21MB0096; 7:qB8WD61AMnrplWmUNTDHB2pLSFvbykWaLxIvzOj7nL72i1W6Ms1p55Ve51ZSts0OABITAZxq1mt7KiEECZU7ldibE8eSQ5X/qFBszlCJXw10s7zXFaDgIXeZ1zKRkyH+M1FiH8MTLiOWFF6ygz5n3LcoOQ8/PJH8CdyrubgT2DITjJ+HmFc7DQCr9PYAz0pV/b0vKtzyegv7FaF5iitijVPJiXVr0pPGEmfzFAFav3HWWlr85Snlyo27FRgqJnOHEJY3WxZYphFz+sfGi971X1FGy0NFjz1vAvIHmiXa7hvGxJe9fSHIyjYIMhnPoFyVXKHn9bWP3FiB3NLRKB4OT1REMN8xRInFH6eWCxajJPg= x-ms-office365-filtering-correlation-id: 246c0bc6-f618-426f-1100-08d47abb0e14 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:SN1PR21MB0096; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:SN1PR21MB0096; BCL:0; PCL:0; RULEID:; SRVR:SN1PR21MB0096; x-forefront-prvs: 0266491E90 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39860400002)(39410400002)(39400400002)(39850400002)(3280700002)(6506006)(5660300001)(9686003)(53936002)(99286003)(8990500004)(2950100002)(8936002)(7696004)(5005710100001)(10290500002)(6306002)(54896002)(3660700001)(9326002)(6436002)(10090500001)(19609705001)(8676002)(77096006)(55016002)(2900100001)(7736002)(229853002)(81166006)(86362001)(6246003)(2501003)(6116002)(790700001)(74316002)(102836003)(76176999)(54356999)(50986999)(86612001)(39060400002)(189998001)(33656002)(2906002)(106356001)(38730400002)(122556002)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR21MB0096; H:SN1PR21MB0096.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR21MB0096C6DB755979539128FC978C080SN1PR21MB0096namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2017 17:58:37.7407 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR21MB0096 Archived-At: Subject: Re: [Unbearable] Removing explicit public key crypto from Token Binding X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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, 03 Apr 2017 17:58:42 -0000 --_000_SN1PR21MB0096C6DB755979539128FC978C080SN1PR21MB0096namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmljaywNCg0KVGhhbmtzIGZvciByZXZpZXdpbmcgdGhlIFRva2VuIEJpbmRpbmcgSS1Eczsg aXTigJlzIG5ldmVyIGxhdGUgdG8gZG8gdGhpcy4NCg0KDQogICogICBUaGUgaW50cm9kdWN0aW9u IG9mIHB1YmxpYyBrZXkgY3J5cHRvIGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciBzZWVtcyBsaWtl IGEgbWFqb3IgZG93bnNpZGUgdG8gdGhlIGN1cnJlbnQgVG9rZW4gQmluZGluZyBQcm90b2NvbCBk cmFmdC4NClRoZSBpZGVhIGlzIGZvciBhcHBsaWNhdGlvbnMgdG8gdXNlIGEgVG9rZW4gQmluZGlu ZyBwcm90b2NvbCBpbXBsZW1lbnRhdGlvbiAoYSBsaWJyYXJ5LCBvciBhIHNldCBvZiBPUy1wcm92 aWRlZCBBUElzKSwgcmF0aGVyIHRoYW4gcmUtaW1wbGVtZW50aW5nIHB1YmxpYyBjcnlwdG8gaW4g ZWFjaCBhcHAuDQoNCg0KICAqICAgRXZlcnkgbmV3IHNpZ25hdHVyZSBhbGdvcml0aG0gdG8gYmUg dXNlZCBoZXJlIG5lZWRzIHRvIGJlIGFkZGVkIHRvIHRoZSBuZXcgSUFOQSByZWdpc3RyeS4gRXZl cnkgdGltZSB0aGlzIGhhcHBlbnMsIHRoaXMgZG9jdW1lbnQgbmVlZHMgdG8gYmUgdXBkYXRlZC4g V2hpY2ggd29ya2luZyBncm91cCBpcyByZXNwb25zaWJsZSBmb3IgdXBkYXRpbmcgZHJhZnRzIHRv IGFkZCBuZXcgYWxnb3JpdGhtcyBvciByZW1vdmUgY29tcHJvbWlzZWQgb25lcyBvbmNlIFRPS0JJ TkQgaXMgb3ZlciBhbmQgd2UncmUgZGlzY3Vzc2luZyBwb3N0LXF1YW50dW0gc2lnbmF0dXJlcz8N CknigJlkIGV4cGVjdCB0aGF0IG5ldyBzaWduYXR1cmUgc2NoZW1lcyB3b3VsZCBiZSBpbnRyb2R1 Y2VkIGJ5IG5ldyBJLURzIGluIHRoZSBUb2tiaW5kIFdHLCB3aGljaCBieSB0aGUgd2F5IHNob3dz IG5vIHNpZ24gb2Ygc2xvd2luZyBkb3duIHNvIGZhcvCfmIouDQoNCg0KICAqICAgVGhpcyBkcmFm dCBpbiBwYXJ0aWN1bGFyIGlzIGJvdW5kIHRoZSBzZW1hbnRpY3Mgb2Ygc2V2ZXJhbCBUTFMgZXh0 ZW5zaW9ucy4gTm90IG9ubHkgZG9lcyB0aGUgYXBwbGljYXRpb24gbmVlZCB0byBrbm93IHRoZSBy ZXN1bHQgb2YgdGhlIHRva2VuIGJpbmRpbmcgZXh0ZW5zaW9uLCBpdCBuZWVkcyB0byBrbm93IHdo ZXRoZXIgb3Igbm90IHRoZSBleHRlbmRlZCBtYXN0ZXIgc2VjcmV0IGhhcyBiZWVuIHVzZWQuIERl cGVuZGluZyBvbiB0aGUgY29ycmVjdCBjYWxjdWxhdGlvbiBvZiBhIG1hc3RlciBzZWNyZXQgaXMg YW4gZXNvdGVyaWMgcG9pbnQgdGhhdCBhcHBsaWNhdGlvbnMgbWF5IGZvcmdldCB0byBlbmZvcmNl Lg0KVGhlIHJlYXNvbiBhIFRMUyBleHRlbnNpb24gaXMgdXNlZCB0byBuZWdvdGlhdGUgVG9rZW4g QmluZGluZyBpcyB0aGF0IHdlIHdvdWxkIGxpa2UgdG8gYXZvaWQgZXh0cmEgcm91bmQtdHJpcHMu DQpSZWdhcmRpbmcgRU1TLCBhcmd1YWJseSBpdOKAmXMgYSBnb29kIGlkZWEgdG8gZW5mb3JjZSBp dCByZWdhcmRsZXNzIG9uIFRva2VuIEJpbmRpbmfigKYNCg0KDQogICogICBUaGUgYmFzaWMgaWRl YSBpcyB0aGF0IHRoZSBhcHBsaWNhdGlvbiBwcm92aWRlcyBhIHByaXZhdGUga2V5IGFuZCBjZXJ0 aWZpY2F0ZSB0byB0aGUgVExTIGxpYnJhcnkgYW5kIHRoZSBUTFMgbGlicmFyeSByZXR1cm5zIGEg YmluZGluZyBvZiB0aGF0IGNlcnRpZmljYXRlIHRvIHRoZSBjb25uZWN0aW9uIGNhbGxlZCBhbiAi ZXhwb3J0ZWQgYXV0aGVudGljYXRvciIuDQpUaGUgcG9pbnQgb2YgVG9rZW4gQmluZGluZyBpcyB0 aGF0IHRoZSBhcHBsaWNhdGlvbiBkb2VzIG5vdCBoYXZlIHRoZSBwcml2YXRlIGtleS4gVGhlIHBy aXZhdGUga2V5IGlzIHNlY3VyZWx5IGdlbmVyYXRlZCBhbmQgc3RvcmVkLCBwb3NzaWJseSBpbiBh IGhhcmR3YXJlIG1vZHVsZS4NCk9uY2UgdGhlIGNsaWVudCBoYXMgYmVlbiBhdXRoZW50aWNhdGVk IChlLmcuLCB3aXRoIFRMUyBjbGllbnQgYXV0aCBhbmQgZXhwb3J0ZWQgYXV0aGVudGljYXRvcnMp LCB0aGUgc2VydmVyIG1heSBpc3N1ZSB0b2tlbnMgZm9yIHRoZSBjbGllbnQgdG8gdXNlIHdoZW4g Y29ubmVjdGluZyB0byB0aGlzIG9yIG90aGVyIHNlcnZlcnMuDQpUb2tlbiBCaW5kaW5nIG1ha2Vz IGl0IGhhcmRlciB0byBleHBvcnQgYW5kIHJlcGxheSBzdWNoIHRva2Vucy4NCg0KQ2hlZXJzLA0K DQpBbmRyZWkNCg== --_000_SN1PR21MB0096C6DB755979539128FC978C080SN1PR21MB0096namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA bGlzdCBsMA0KCXttc28tbGlzdC1pZDo5ODk2NzY0NjA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi00Mzg0MjgzMzAgLTQzMDQxNzIyMiA2NzY5ODY5MSA2 NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5 ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1m b250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdp bi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBOaWNrLDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHJldmlld2luZyB0aGUgVG9rZW4gQmluZGluZyBJLURz OyBpdOKAmXMgbmV2ZXIgbGF0ZSB0byBkbyB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6 MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+VGhlIGludHJvZHVjdGlvbiBv ZiBwdWJsaWMga2V5IGNyeXB0byBhdCB0aGUgYXBwbGljYXRpb24gbGF5ZXIgc2VlbXMgbGlrZSBh IG1ham9yIGRvd25zaWRlIHRvIHRoZSBjdXJyZW50IFRva2VuIEJpbmRpbmcgUHJvdG9jb2wgZHJh ZnQuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaWRlYSBp cyBmb3IgYXBwbGljYXRpb25zIHRvIHVzZSBhIFRva2VuIEJpbmRpbmcgcHJvdG9jb2wgaW1wbGVt ZW50YXRpb24gKGEgbGlicmFyeSwgb3IgYSBzZXQgb2YgT1MtcHJvdmlkZWQgQVBJcyksIHJhdGhl ciB0aGFuIHJlLWltcGxlbWVudGluZyBwdWJsaWMgY3J5cHRvIGluIGVhY2ggYXBwLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8dWwg c3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ RXZlcnkgbmV3IHNpZ25hdHVyZSBhbGdvcml0aG0gdG8gYmUgdXNlZCBoZXJlIG5lZWRzIHRvIGJl IGFkZGVkIHRvIHRoZSBuZXcgSUFOQSByZWdpc3RyeS4gRXZlcnkgdGltZSB0aGlzIGhhcHBlbnMs IHRoaXMgZG9jdW1lbnQgbmVlZHMgdG8gYmUgdXBkYXRlZC4gV2hpY2ggd29ya2luZyBncm91cCBp cyByZXNwb25zaWJsZQ0KIGZvciB1cGRhdGluZyBkcmFmdHMgdG8gYWRkIG5ldyBhbGdvcml0aG1z IG9yIHJlbW92ZSBjb21wcm9taXNlZCBvbmVzIG9uY2UgVE9LQklORCBpcyBvdmVyIGFuZCB3ZSdy ZSBkaXNjdXNzaW5nIHBvc3QtcXVhbnR1bSBzaWduYXR1cmVzPzxvOnA+PC9vOnA+PC9saT48L3Vs Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmWQgZXhwZWN0IHRoYXQgbmV3IHNpZ25hdHVyZSBz Y2hlbWVzIHdvdWxkIGJlIGludHJvZHVjZWQgYnkgbmV3IEktRHMgaW4gdGhlIFRva2JpbmQgV0cs IHdoaWNoIGJ5IHRoZSB3YXkgc2hvd3Mgbm8gc2lnbiBvZiBzbG93aW5nIGRvd24gc28gZmFyPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJIEVtb2ppJnF1b3Q7LHNhbnMtc2Vy aWYiPiYjMTI4NTIyOzwvc3Bhbj4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9 ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5UaGlzIGRyYWZ0IGluIHBhcnRpY3VsYXIgaXMg Ym91bmQgdGhlIHNlbWFudGljcyBvZiBzZXZlcmFsIFRMUyBleHRlbnNpb25zLiBOb3Qgb25seSBk b2VzIHRoZSBhcHBsaWNhdGlvbiBuZWVkIHRvIGtub3cgdGhlIHJlc3VsdCBvZiB0aGUgdG9rZW4g YmluZGluZyBleHRlbnNpb24sIGl0IG5lZWRzIHRvIGtub3cgd2hldGhlcg0KIG9yIG5vdCB0aGUg ZXh0ZW5kZWQgbWFzdGVyIHNlY3JldCBoYXMgYmVlbiB1c2VkLiBEZXBlbmRpbmcgb24gdGhlIGNv cnJlY3QgY2FsY3VsYXRpb24gb2YgYSBtYXN0ZXIgc2VjcmV0IGlzIGFuIGVzb3RlcmljIHBvaW50 IHRoYXQgYXBwbGljYXRpb25zIG1heSBmb3JnZXQgdG8gZW5mb3JjZS48bzpwPjwvbzpwPjwvbGk+ PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSByZWFzb24gYSBUTFMgZXh0ZW5zaW9uIGlz IHVzZWQgdG8gbmVnb3RpYXRlIFRva2VuIEJpbmRpbmcgaXMgdGhhdCB3ZSB3b3VsZCBsaWtlIHRv IGF2b2lkIGV4dHJhIHJvdW5kLXRyaXBzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UmVnYXJkaW5nIEVNUywgYXJndWFibHkgaXTigJlzIGEgZ29vZCBpZGVhIHRvIGVuZm9y Y2UgaXQgcmVnYXJkbGVzcyBvbiBUb2tlbiBCaW5kaW5n4oCmPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2lu LXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5UaGUgYmFzaWMgaWRl YSBpcyB0aGF0IHRoZSBhcHBsaWNhdGlvbiBwcm92aWRlcyBhIHByaXZhdGUga2V5IGFuZCBjZXJ0 aWZpY2F0ZSB0byB0aGUgVExTIGxpYnJhcnkgYW5kIHRoZSBUTFMgbGlicmFyeSByZXR1cm5zIGEg YmluZGluZyBvZiB0aGF0IGNlcnRpZmljYXRlIHRvIHRoZSBjb25uZWN0aW9uIGNhbGxlZA0KIGFu ICZxdW90O2V4cG9ydGVkIGF1dGhlbnRpY2F0b3ImcXVvdDsuPG86cD48L286cD48L2xpPjwvdWw+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcG9pbnQgb2YgVG9rZW4gQmluZGluZyBpcyB0aGF0 IHRoZSBhcHBsaWNhdGlvbiBkb2VzIG5vdCBoYXZlIHRoZSBwcml2YXRlIGtleS4gVGhlIHByaXZh dGUga2V5IGlzIHNlY3VyZWx5IGdlbmVyYXRlZCBhbmQgc3RvcmVkLCBwb3NzaWJseSBpbiBhIGhh cmR3YXJlIG1vZHVsZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uY2Ug dGhlIGNsaWVudCBoYXMgYmVlbiBhdXRoZW50aWNhdGVkIChlLmcuLCB3aXRoIFRMUyBjbGllbnQg YXV0aCBhbmQgZXhwb3J0ZWQgYXV0aGVudGljYXRvcnMpLCB0aGUgc2VydmVyIG1heSBpc3N1ZSB0 b2tlbnMgZm9yIHRoZSBjbGllbnQgdG8gdXNlIHdoZW4gY29ubmVjdGluZyB0byB0aGlzIG9yIG90 aGVyIHNlcnZlcnMuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRva2Vu IEJpbmRpbmcgbWFrZXMgaXQgaGFyZGVyIHRvIGV4cG9ydCBhbmQgcmVwbGF5IHN1Y2ggdG9rZW5z LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QW5kcmVpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_SN1PR21MB0096C6DB755979539128FC978C080SN1PR21MB0096namp_-- From nobody Mon Apr 3 11:07:54 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B411294DA for ; Mon, 3 Apr 2017 11:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.198 X-Spam-Level: X-Spam-Status: No, score=0.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, THIS_AD=2.198] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2G7Cxtv6YU6 for ; Mon, 3 Apr 2017 11:07:52 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C2E71294B8 for ; Mon, 3 Apr 2017 11:07:52 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id 81so127822643pgh.2 for ; Mon, 03 Apr 2017 11:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Z80+QJSk1gYo09NqIQdhGITM+8DMEpYM0kFbqijTGho=; b=FTvHb5ZGmYXwbXx5NJjj8duPYiuT12tTM2Tz2zbTHsF4i4SIJB19boC2xHFU+I5Gfo ahDBcOv497Iv8BB/uPrZy/tHt9QQ9SZ15AYviZsd5LmNbS6XSIOSFsBdMppKmNVWYGvN 7XsVdR5C4tkT/2N/CjT54zTi7mvD7Kr7spJHE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Z80+QJSk1gYo09NqIQdhGITM+8DMEpYM0kFbqijTGho=; b=g8oXne+5aidpJOQEWwpG41Q3co5/YyK6bZmSpfBC3zFYrcQpVFltqy/ZzZA6i94rTb 8yairyH0tg2YU7ywTg9nZi/D1HHBbAcy6bxSNAq17dj69eYI+pzkDbqIsWUGhNZDV2UN rqyNkMNdhs6GUl24rK+AA6nR2pI+Xoym2Sl+oL3aLWncGaeOTxbQFb7uwoSvMD/i3wRQ v4aE/9QtxEoBQqqtZwHDzaDNRv/Yd7zAoKgDpHIC8Llpb5mux2sXlY/la7wx0IK9envp 5sQrdHEYPNAQYJZPvOFpN5NT8qv5RbnqV5beCL4e2YCcsOfiW/LcZB4pwm6KM5QKD/9B x/hg== X-Gm-Message-State: AFeK/H3p1xPB20zwEPTGzo1Y3jgrS13mJPUFZCSC77ldEmR4PB8C30FGTRas/c5qPaFnROmUBdZTrKN0onozsRgX X-Received: by 10.99.109.137 with SMTP id i131mr19237999pgc.103.1491242871492; Mon, 03 Apr 2017 11:07:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.165.172 with HTTP; Mon, 3 Apr 2017 11:07:20 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Mon, 3 Apr 2017 12:07:20 -0600 Message-ID: To: IETF Tokbind WG Content-Type: multipart/alternative; boundary=f403045c3bfca12fe0054c47094d Archived-At: Subject: Re: [Unbearable] Thurs 9am-10am in Lugano: additional TB TTRP meeting X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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, 03 Apr 2017 18:07:53 -0000 --f403045c3bfca12fe0054c47094d Content-Type: text/plain; charset=UTF-8 Thanks to the several people who came out on Thursday morning to discuss the approach around TTRP & TB. The (more than rough) consensus that morning was that it was more appropriate for the TTRP to do the validation of the Token Binding Message in the Sec-Token-Binding header. That is contrary to the approach described in -00 of draft-campbell-tokbind-tls-term . In order to move forward and facilitate discussion,I plan to write a new draft that reflects that preference of having the TTRP do the validation. Don't have an ETA on that just yet but I'll post it to this list when I have something readable. On Tue, Mar 28, 2017 at 8:57 AM, Brian Campbell wrote: > Unfortunately, the presentation and discussion on Token Binding and TLS > Terminating Reverse Proxies was cut short by the end of Monday's meeting. > I would like to invite (or maybe beg) anyone who's interested in, or has > input into, the topic to meet again this week to discuss it more. Ideally > I'd like to have some sense of consensus on a preferred approach so I can > proceed with document work. > > I've reserved Lugano, the attendee sign-up room, for an hour starting at > 9am on Thursday (trying to find a good time was hard, sorry, I hope this > works okay for folks) for this ad hoc meeting. > > Lugano is on the 2nd floor. See https://datatracker.ietf.org/ > meeting/98/floor-plan?room=lugano#chicago-swissotel-floor-2 > > The slides that were partially presented at yesterday's meeting are > attached for background and context. > > Hope to see many of you there! > --f403045c3bfca12fe0054c47094d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks to the several people who came out on Thu= rsday morning to discuss the approach around TTRP & TB.

T= he (more than rough) consensus that morning was that it was more appropriat= e for the TTRP to do the validation of the Token Binding Message in the Sec= -Token-Binding header. That is contrary to the approach described in -00 of draft-campbell-tokbind-tls-term. In order to mo= ve forward and facilitate discussion,I plan to write a new draft that refle= cts that preference of having the TTRP do the validation. Don't have an= ETA on that just yet but I'll post it to this list when I have somethi= ng readable.



=C2=A0

On Tue, Mar 28, 2017= at 8:57 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
U= nfortunately, the presentation and discussion on Token Binding and TLS Term= inating Reverse Proxies was cut short by the end of Monday's meeting.= =C2=A0 I would like to invite (or maybe beg) anyone who's interested in= , or has input into, the topic to meet again this week to discuss it more. = Ideally I'd like to have some sense of consensus on a preferred approac= h so I can proceed with document work.

I've reserve= d Lugano, the attendee sign-up room, for an hour starting at 9am on Thursda= y (trying to find a good time was hard, sorry, I hope this works okay for f= olks) for this ad hoc meeting.

Lugano is on the 2nd floor. See https://datatracker.ietf.org/meeting/98/floor-plan?room=3Dlugano#chicago-swissotel-floor-2

The slides that were partially presented at y= esterday's meeting are attached for background and context.

Hope to see many of you there!

--f403045c3bfca12fe0054c47094d-- From nobody Mon Apr 3 12:48:21 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D42E129519 for ; Mon, 3 Apr 2017 12:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_l0KM6dNh4z for ; Mon, 3 Apr 2017 12:48:11 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0123.outbound.protection.outlook.com [104.47.32.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BCB712951E for ; Mon, 3 Apr 2017 12:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LowR5CnfqI9hafKM/Fa8z9mFP3IQ8Al05FhjjAhv40M=; b=fzfUSMwXU3vdbFdLAYQLCtbkelrViBirEEumT4BzfxfCHQGgxk5eHA74cZUn1xrlRQUQWYR0wNkwCWa1nw7ETuv9TqUw4KTFesQiDPfubT4kZgIftGo+s5D5dZZ53MT5JjbjVefUptFS9bkdNGSCPUOpbtTqsX3uV2L+Dy0uxfo= Received: from SN1PR21MB0096.namprd21.prod.outlook.com (10.161.254.16) by SN1PR21MB0093.namprd21.prod.outlook.com (10.161.254.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.0; Mon, 3 Apr 2017 19:48:09 +0000 Received: from SN1PR21MB0096.namprd21.prod.outlook.com ([10.161.254.16]) by SN1PR21MB0096.namprd21.prod.outlook.com ([10.161.254.16]) with mapi id 15.01.1019.015; Mon, 3 Apr 2017 19:48:09 +0000 From: Andrei Popov To: Bill Cox , Nick Sullivan CC: "unbearable@ietf.org" Thread-Topic: [Unbearable] Binding tokens to scope in HTTP Thread-Index: AQHSrJoOJcT6z0eA3UmiRYUmB69ibKGz5QCAgAAlP5A= Date: Mon, 3 Apr 2017 19:48:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:1::4ca] x-microsoft-exchange-diagnostics: 1; SN1PR21MB0093; 7:h7wDRuJQkLasCN1Tz60rjR5P7oYAFZUS99fsc9NO6MoflQ+hctB/KoaYLpd9vvAuAIWIib8XXBckBntctUYXQEVo8XId5c50h1zgLpdNyuQt3/m0MT6mwkoVznQfJgS/jOfCfYBA/lfrbgULUktBwLfgSAjSG3jJaPws7lstZ7XXLhXUfCGCFevV3GEQ/m04QfQJOXEs51HMgc0EPsLNkNdpO9CfJVVCkWy8DUHYd2ViPs92Ih9GiwPDzsfmS3C9gqhYHZIg641ZXDxj+fJ+4OCFr5VKemtSbPKv3cxg3jeVtlKrgjTdFXNbRZQDgJ289bDnKIQNCzKE4eBgGyk/TnE9GUg9fTkmmPThmr+zoFs= x-ms-office365-filtering-correlation-id: cd9a3511-13cf-45cf-9901-08d47aca5b1e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:SN1PR21MB0093; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(60795455431006)(158342451672863)(192374486261705)(100405760836317)(254730959083279)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:SN1PR21MB0093; BCL:0; PCL:0; RULEID:; SRVR:SN1PR21MB0093; x-forefront-prvs: 0266491E90 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39850400002)(39410400002)(39450400003)(39840400002)(39860400002)(24454002)(377454003)(102836003)(790700001)(6116002)(77096006)(8990500004)(7696004)(19609705001)(5005710100001)(54356999)(6506006)(76176999)(229853002)(5660300001)(50986999)(6246003)(10290500002)(122556002)(236005)(8936002)(2950100002)(2900100001)(189998001)(74316002)(86612001)(4326008)(33656002)(81166006)(39060400002)(53936002)(6436002)(86362001)(38730400002)(8676002)(53386004)(7736002)(25786009)(7906003)(606005)(53546009)(54896002)(9686003)(6306002)(2906002)(1680700002)(99286003)(55016002)(10090500001)(3280700002)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR21MB0093; H:SN1PR21MB0096.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR21MB0096465FDA68EB982F457CC08C080SN1PR21MB0096namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2017 19:48:09.4134 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR21MB0093 Archived-At: Subject: Re: [Unbearable] Binding tokens to scope in HTTP X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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, 03 Apr 2017 19:48:17 -0000 --_000_SN1PR21MB0096465FDA68EB982F457CC08C080SN1PR21MB0096namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGlkZWEgb2Ygc2lnbmluZyBUQiBleHRlbnNpb25zIGhhcyBiZWVuIGRpc2N1c3NlZCBtdWx0 aXBsZSB0aW1lcyBvdmVyIHRoZSB5ZWFycy4NCk5vdCBzaWduaW5nIGV4dGVuc2lvbnMgYWxsb3dz IGFuIGV4dGVuc2lvbiB0byBzaWduIHRoZSBUQiBtZXNzYWdlLCB3aGljaCBpcyB3aGF0IGNvdWxk IGJlIHVzZWQgZm9yIGhhbmR5IHRoaW5ncyBsaWtlIGtleSBhdHRlc3RhdGlvbi4NCkl0IGlzIGxp a2VseSBhbHNvIHBvc3NpYmxlIHRvIGRvIGtleSBhdHRlc3RhdGlvbiB3aXRob3V0IHNpZ25pbmcg dGhlIGVudGlyZSBUQiBtZXNzYWdlLCBzbyBpZiB0aGUgV0cgd2FudHMgdG8gY2hhbmdlIHRoaXMg cHJpb3IgY29uc2Vuc3VzLCB3ZSBjYW4gZG8gc28uDQoNClRoZSByZWFzb24gVEIga2V5cyBhcmUg c2NvcGVkIHRvIGVUTEQrMSAoaW4gdGhlIGNhc2Ugb2YgSFRUUFMpIGlzIHRoYXQgdGhlIGNvb2tp ZXMgdGhlc2UgVEIga2V5cyBwcm90ZWN0IGFyZSBzY29wZWQgdG8gZVRMRCsxLg0KUGVyIElFVEY5 OCBkaXNjdXNzaW9uLCB0aGUgbmV4dCByZXZpc2lvbiBvZiB0aGUgSS1EcyB3aWxsIGNsYXJpZnkg dGhhdCBicm93c2VycyBjYW5ub3QgZXhjZWVkIHRoZSBzY29wZSBvZiBlVExEKzEuIElmIGNvb2tp ZXMgYXJlIHNjb3BlZCBtb3JlIG5hcnJvd2x5LCB0aGUgc2FtZSBjYW4gYmUgZG9uZSB3aXRoIFRC IGtleXMuDQoNCkNoZWVycywNCg0KQW5kcmVpDQoNCkZyb206IFVuYmVhcmFibGUgW21haWx0bzp1 bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCaWxsIENveA0KU2VudDog TW9uZGF5LCBBcHJpbCAzLCAyMDE3IDEwOjI0IEFNDQpUbzogTmljayBTdWxsaXZhbiA8bmljaG9s YXMuc3VsbGl2YW5AZ21haWwuY29tPg0KQ2M6IHVuYmVhcmFibGVAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbVW5iZWFyYWJsZV0gQmluZGluZyB0b2tlbnMgdG8gc2NvcGUgaW4gSFRUUA0KDQpUaGUg ZXh0ZW5zaW9ucyB1c2VkIHRvIGJlIGNvdmVyZWQgaW4gZWFybGllciBkcmFmdHMuICBJIGZvcmdl dCB3aHkgdGhpcyB3YXMgZHJvcHBlZCwgYnV0IElJUkMsIGl0IHdhcyBkaXNjdXNzZWQgb24gdGhp cyBsaXN0LiAgSW4gYW55IGNhc2UsIGl0IHNvdW5kcyBsaWtlIHRoZXJlIGFyZSBhIG51bWJlciBv ZiBwZW9wbGUgd2hvIHdvdWxkIHByZWZlciB0byBjaGFuZ2UgVEIgZXh0ZW5zaW9uIG51bWJlcnMg YW5kIGVmZmVjdGl2ZWx5IGJlIGEgbmV3IGV4dGVuc2lvbiByYXRoZXIgdGhhbiB1c2UgdGhlIGhl YWRlcidzIGV4dGVuc2lvbiBjYXBhYmlsaXR5Lg0KDQpZb3VyIGV4YW1wbGUgaGFzIGEgbWlub3Ig ZXJyb3I6ICBlVExEKzEgZm9yIGV4YW1wbGUuY29tPGh0dHA6Ly9leGFtcGxlLmNvbT4gaXMgZXhh bXBsZS5jb208aHR0cDovL2V4YW1wbGUuY29tPiwgc28gYS5leGFtcGxlLmNvbTxodHRwOi8vYS5l eGFtcGxlLmNvbT4gd291bGQgaGF2ZSB0aGUgc2FtZSBUQiBrZXkgYXMgYi5leGFtcGxlLmNvbTxo dHRwOi8vYi5leGFtcGxlLmNvbT4uICBIb3dldmVyLCB0aGUgaWRlYSBmb3IgdGhlIGF0dGFjayBp cyB2YWxpZC4gIGVUTEQrMSBiYXNlZCBzZWN1cml0eSBzZWVtcyB0byBiZSBhIGtsdWRnZS4gIEkg ZmVsdCB0aGF0IGJpbmRpbmcgdG8gdGhlIHNpdGVzIGNvdmVyZWQgYnkgYSBjZXJ0aWZpY2F0ZSBt aWdodCBtYWtlIHNlbnNlLCBidXQgaXQgZG9lcyBub3Qgd29yayBvdXQuICBGb3IgZXhhbXBsZSwg d2UgaGF2ZSBjZXJ0cyBmb3IgZ21haWwuY29tPGh0dHA6Ly9nbWFpbC5jb20+IGFuZCB5b3V0dWJl LmNvbTxodHRwOi8veW91dHViZS5jb20+LCBhbmQgY2VydGlmaWNhdGVzIGNvdmVyaW5nIGJvdGgs IElJUkMuICBXZSBjb3VsZCB1c2UgdGhlIHNhbWUgVEIgc2lnLCBib3VuZCB0byB0aGF0IGNlcnRp ZmljYXRlLCBmb3IgYSBsb3Qgb2Ygc2l0ZXMsIHJlZHVjaW5nIFRCIHNpZ25hdHVyZSBvdmVyaGVh ZC4gIEl0IGFsc28gbWFrZXMgc2Vuc2UgdG8gbWUgZnJvbSBhIHNlY3VyaXR5IHBlcnNwZWN0aXZl OiB0aGUgc2VydmVyIGhhcyBwcm92ZW4gb3duZXJzaGlwIG9mIGEgY29sbGVjdGlvbiBvZiBkb21h aW5zLCBzbyBqdXN0IGJpbmQgdG8gdGhhdC4gIFRoaXMgd291bGQgZWxpbWluYXRlIGFsbCB0aGUg ZVRMRCsxIHNlY3VyaXR5IGlzc3Vlcy4gIEhvd2V2ZXIsIHdlIGNhbid0IGNvdW50IG9uIHNlZWlu ZyB0aGUgc2FtZSBjZXJ0aWZpY2F0ZSBhbGwgdGhlIHRpbWUuICBTb21ldGltZXMgYSBzZXJ2ZXIg d2lsbCBwcmVzZW50IGEgbG9naW4uZXhhbXBsZS5jb208aHR0cDovL2xvZ2luLmV4YW1wbGUuY29t PiBjZXJ0aWZpY2F0ZSBvbiBvbmUgY29ubmVjdGlvbiwgYW5kICouZXhhbXBsZS5jb208aHR0cDov L2V4YW1wbGUuY29tPiBvbiBhbm90aGVyLiAgTW9zdCBsaWtlbHksIHRoZSBjb29raWUgdGhhdCBp cyB1c2VkIGZvciBhdXRoIHdvdWxkIGJlIGJvdW5kIHRvIGxvZ2luLmV4YW1wbGUuY29tPGh0dHA6 Ly9sb2dpbi5leGFtcGxlLmNvbT4sIGFuZCB3b3VsZCBiZSByZWplY3RlZCBmb3IgYWxsIG90aGVy ICouZXhhbXBsZS5jb208aHR0cDovL2V4YW1wbGUuY29tPiBkb21haW5zLg0KDQpJIGxpa2UgdGhl IGlkZWEgb2Ygc2lnbmluZyBleHRlbnNpb25zIGFuZCBhbHNvIHRoZSBob3N0IG5hbWUgZnJvbSB0 aGUgaG9zdCBoZWFkZXIuDQoNCkJpbGwNCg0KDQpPbiBNb24sIEFwciAzLCAyMDE3IGF0IDk6NDcg QU0sIE5pY2sgU3VsbGl2YW4gPG5pY2hvbGFzLnN1bGxpdmFuQGdtYWlsLmNvbTxtYWlsdG86bmlj aG9sYXMuc3VsbGl2YW5AZ21haWwuY29tPj4gd3JvdGU6DQpUaGUgdG9rZW4gYmluZGluZyBoZWFk ZXIgZG9lcyBub3QgaGF2ZSBhbnkgaWRlbnRpdHkgYm91bmQgdG8gaXQuIFRoaXMgaXMgcG90ZW50 aWFsbHkgcHJvYmxlbWF0aWMgYmVjYXVzZSBpdCBtYWtlcyBpdCBtdWNoIG1vcmUgbGlrZWx5IHRo YXQgdGhpcyBwcm90b2NvbCBpcyB2dWxuZXJhYmxlIHRvIHVua25vd24ga2V5IHNoYXJlIGlzc3Vl cy4NCg0KVW5rbm93biBrZXkgc2hhcmUgYXR0YWNrcyBoYXBwZW4gd2hlbiBhIHB1YmxpYyBrZXkg aXMgdXNlZCB3aXRob3V0IGJpbmRpbmcgaXQgdG8gYW4gaWRlbnRpdHkgYnkgYSBzaWduYXR1cmUu IEZvciBleGFtcGxlLCBSaWNoYXJkIEJhcm5lcyByZWNlbnRseSBwdWJsaXNoZWQgYSBkcmFmdCBk ZXNjcmliaW5nIGhvdyBEQU5FIHdpdGggcmF3IGtleXMgd2FzIHZ1bG5lcmFibGUgdG8gdGhpcyBz dHlsZSBvZjogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJhcm5lcy1kYW5lLXVr cy0wMC4NCg0KSW4gc2VjdGlvbiAyLjEuIG9mIGRyYWZ0LWlldGYtdG9rYmluZC1odHRwcywgdGhl IGtleSBwYWlyIHNjb3BpbmcgaXMgZGVmaW5lZCB0byBiZSBlVExEKzEuIERlcGVuZGluZyBvbiB0 aGUgdGhyZWF0IG1vZGVsLCB0aGlzIHJlcXVpcmVtZW50IGNhbiBiZSBzdWJ2ZXJ0ZWQuDQoNCkNv bnNpZGVyIGFuIGF0dGFja2VyIHdobyBoYXMgYWNjZXNzIHRvIHJlYWQgYW5kIG1vZGlmeSBoZWFk ZXJzLCBidXQgbm90IHByaXZhdGUga2V5cy4gSW1hZ2luZSBhIGJ1Z2d5L21hbGljaW91cyBzZXJ2 aWNlIHdvcmtlciBvciBzb21ldGhpbmcgZWxzZSBvZiB0aGlzIHNvcnQuIE5vdyBpbWFnaW5lIGEg c2l0ZSB3aXRoIGEuZXhhbXBsZS5jb208aHR0cDovL2EuZXhhbXBsZS5jb20+IGFuZCBiLmV4YW1w bGUuY29tPGh0dHA6Ly9iLmV4YW1wbGUuY29tPiBhbmQgYSB3aWxkY2FyZCAqLmV4YW1wbGUuY29t PGh0dHA6Ly9leGFtcGxlLmNvbT4gY2VydGlmaWNhdGUuIFRoZSBhdHRhY2tlciBjYW4gdGFrZSB0 b2tlbiBiaW5kaW5nIGhlYWRlcnMgZnJvbSBhLmV4YW1wbGUuY29tPGh0dHA6Ly9hLmV4YW1wbGUu Y29tPiBhbmQgcHV0IHRoZW0gb24gcmVxdWVzdHMgdG8gYi5leGFtcGxlLmNvbTxodHRwOi8vYi5l eGFtcGxlLmNvbT4gYW5kIHRoZSBjb29raWVzIHNldCBvbiBiLmV4YW1wbGUuY29tPGh0dHA6Ly9i LmV4YW1wbGUuY29tPiB3aWxsIGJlIGJvdW5kIHRvIGEuZXhhbXBsZS5jb208aHR0cDovL2EuZXhh bXBsZS5jb20+J3Mga2V5Lg0KDQpUaGlzIGRvZXNuJ3Qgc291bmQgbGlrZSBhIGxhcmdlIGlzc3Vl LCBidXQgaXQncyBpbmRpY2F0aXZlIG9mIHRoZSB0eXBlIG9mIHN1YnRsZSBwcm9ibGVtcyBub3Qg YmluZGluZyB0aGUga2V5IHRvIGEgY29udGV4dCBjYW4gY2F1c2UuDQpJZiB0aGUgdG9rZW4gY29u dGV4dCB3YXMgYm91bmQgdG8gdGhlIHNjb3BlIGJ5IGluY2x1ZGluZyB0aGUgZVRMRCsxIGluIHRo ZSAob3IgdGhlIG9yaWdpbiBpZiB0aGUgYnJvd3NlciBpbnRlbmRzIHRvIHVzZSBzdHJpY3RlciB0 b2tlbiBzY29waW5nKSwgKmFuZCogdGhpcyBzY29wZSB3YXMgY292ZXJlZCBieSB0aGUgc2lnbmF0 dXJlIHRoZW4gdGhpcyB3b3VsZCBub3QgYmUgcG9zc2libGUuIFRoZSBzZXJ2ZXIgY291bGQgY2hl Y2sgdGhlIGhvc3QgaGVhZGVyIGFnYWluc3QgdGhlIHRva2VuIGNvbnRleHQgYW5kIHRoZW4gcmVm dXNlIHRoZSB0b2tlbiBiaW5kaW5nIGZvciBuZXcgY29va2llcy4NCg0KQSBsb2dpY2FsIHBsYWNl IHRvIHB1dCB0aGlzIHdvdWxkIGJlIGluIHRoZSBleHRlbnNpb25zIG9mIHRoZSB0b2tlbiBiaW5k aW5nIHN0cnVjdHVyZSwgYnV0IHVuZm9ydHVuYXRlbHkgdGhlIGV4dGVuc2lvbnMgaXMgbm90IHNp Z25lZCBhbmQgc28gY2FuIGJlIG1vZGlmaWVkLiBJcyB0aGVyZSBhIHJlYXNvbiB0aGUgZXh0ZW5z aW9ucyBmaWVsZCBvZiB0aGUgVG9rZW5CaW5kaW5nIHN0cnVjdHVyZSBpcyBub3Qgc2lnbmVkIGJ5 IHRoZSBwcml2YXRlIGtleT8NCg0KTmljaw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3QNClVuYmVhcmFibGVA aWV0Zi5vcmc8bWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUNCg0K --_000_SN1PR21MB0096465FDA68EB982F457CC08C080SN1PR21MB0096namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHls ZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBv c2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBpZGVhIG9mIHNpZ25pbmcgVEIgZXh0 ZW5zaW9ucyBoYXMgYmVlbiBkaXNjdXNzZWQgbXVsdGlwbGUgdGltZXMgb3ZlciB0aGUgeWVhcnMu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3Qgc2lnbmluZyBleHRlbnNp b25zIGFsbG93cyBhbiBleHRlbnNpb24gdG8gc2lnbiB0aGUgVEIgbWVzc2FnZSwgd2hpY2ggaXMg d2hhdCBjb3VsZCBiZSB1c2VkIGZvciBoYW5keSB0aGluZ3MgbGlrZSBrZXkgYXR0ZXN0YXRpb24u PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBpcyBsaWtlbHkgYWxzbyBw b3NzaWJsZSB0byBkbyBrZXkgYXR0ZXN0YXRpb24gd2l0aG91dCBzaWduaW5nIHRoZSBlbnRpcmUg VEIgbWVzc2FnZSwgc28gaWYgdGhlIFdHIHdhbnRzIHRvIGNoYW5nZSB0aGlzIHByaW9yIGNvbnNl bnN1cywgd2UgY2FuIGRvIHNvLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcmVhc29uIFRC IGtleXMgYXJlIHNjb3BlZCB0byBlVExEJiM0MzsxIChpbiB0aGUgY2FzZSBvZiBIVFRQUykgaXMg dGhhdCB0aGUgY29va2llcyB0aGVzZSBUQiBrZXlzIHByb3RlY3QgYXJlIHNjb3BlZCB0byBlVExE JiM0MzsxLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGVyIElFVEY5OCBk aXNjdXNzaW9uLCB0aGUgbmV4dCByZXZpc2lvbiBvZiB0aGUgSS1EcyB3aWxsIGNsYXJpZnkgdGhh dCBicm93c2VycyBjYW5ub3QgZXhjZWVkIHRoZSBzY29wZSBvZiBlVExEJiM0MzsxLiBJZiBjb29r aWVzIGFyZSBzY29wZWQgbW9yZSBuYXJyb3dseSwgdGhlIHNhbWUgY2FuIGJlIGRvbmUgd2l0aCBU QiBrZXlzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFuZHJlaTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gVW5iZWFy YWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+QmlsbCBDb3g8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAzLCAyMDE3IDEw OjI0IEFNPGJyPg0KPGI+VG86PC9iPiBOaWNrIFN1bGxpdmFuICZsdDtuaWNob2xhcy5zdWxsaXZh bkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiB1bmJlYXJhYmxlQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbVW5iZWFyYWJsZV0gQmluZGluZyB0b2tlbnMgdG8gc2NvcGUg aW4gSFRUUDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGV4dGVuc2lvbnMgdXNl ZCB0byBiZSBjb3ZlcmVkIGluIGVhcmxpZXIgZHJhZnRzLiZuYnNwOyBJIGZvcmdldCB3aHkgdGhp cyB3YXMgZHJvcHBlZCwgYnV0IElJUkMsIGl0IHdhcyBkaXNjdXNzZWQgb24gdGhpcyBsaXN0LiZu YnNwOyBJbiBhbnkgY2FzZSwgaXQgc291bmRzIGxpa2UgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIHBl b3BsZSB3aG8gd291bGQgcHJlZmVyIHRvIGNoYW5nZSBUQiBleHRlbnNpb24gbnVtYmVycyBhbmQN CiBlZmZlY3RpdmVseSBiZSBhIG5ldyBleHRlbnNpb24gcmF0aGVyIHRoYW4gdXNlIHRoZSBoZWFk ZXIncyBleHRlbnNpb24gY2FwYWJpbGl0eS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPllvdXIgZXhhbXBsZSBoYXMgYSBtaW5vciBlcnJvcjogJm5ic3A7ZVRM RCYjNDM7MSBmb3IgPGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tIj4NCmV4YW1wbGUuY29tPC9h PiBpcyA8YSBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20iPmV4YW1wbGUuY29tPC9hPiwgc28gPGEg aHJlZj0iaHR0cDovL2EuZXhhbXBsZS5jb20iPg0KYS5leGFtcGxlLmNvbTwvYT4gd291bGQgaGF2 ZSB0aGUgc2FtZSBUQiBrZXkgYXMgPGEgaHJlZj0iaHR0cDovL2IuZXhhbXBsZS5jb20iPmIuZXhh bXBsZS5jb208L2E+LiZuYnNwOyBIb3dldmVyLCB0aGUgaWRlYSBmb3IgdGhlIGF0dGFjayBpcyB2 YWxpZC4gJm5ic3A7ZVRMRCYjNDM7MSBiYXNlZCBzZWN1cml0eSBzZWVtcyB0byBiZSBhIGtsdWRn ZS4mbmJzcDsgSSBmZWx0IHRoYXQgYmluZGluZyB0byB0aGUgc2l0ZXMgY292ZXJlZCBieSBhIGNl cnRpZmljYXRlIG1pZ2h0IG1ha2UNCiBzZW5zZSwgYnV0IGl0IGRvZXMgbm90IHdvcmsgb3V0LiZu YnNwOyBGb3IgZXhhbXBsZSwgd2UgaGF2ZSBjZXJ0cyBmb3IgPGEgaHJlZj0iaHR0cDovL2dtYWls LmNvbSI+DQpnbWFpbC5jb208L2E+IGFuZCA8YSBocmVmPSJodHRwOi8veW91dHViZS5jb20iPnlv dXR1YmUuY29tPC9hPiwgYW5kIGNlcnRpZmljYXRlcyBjb3ZlcmluZyBib3RoLCBJSVJDLiZuYnNw OyBXZSBjb3VsZCB1c2UgdGhlIHNhbWUgVEIgc2lnLCBib3VuZCB0byB0aGF0IGNlcnRpZmljYXRl LCBmb3IgYSBsb3Qgb2Ygc2l0ZXMsIHJlZHVjaW5nIFRCIHNpZ25hdHVyZSBvdmVyaGVhZC4mbmJz cDsgSXQgYWxzbyBtYWtlcyBzZW5zZSB0byBtZSBmcm9tIGEgc2VjdXJpdHkgcGVyc3BlY3RpdmU6 DQogdGhlIHNlcnZlciBoYXMgcHJvdmVuIG93bmVyc2hpcCBvZiBhIGNvbGxlY3Rpb24gb2YgZG9t YWlucywgc28ganVzdCBiaW5kIHRvIHRoYXQuJm5ic3A7IFRoaXMgd291bGQgZWxpbWluYXRlIGFs bCB0aGUgZVRMRCYjNDM7MSBzZWN1cml0eSBpc3N1ZXMuJm5ic3A7IEhvd2V2ZXIsIHdlIGNhbid0 IGNvdW50IG9uIHNlZWluZyB0aGUgc2FtZSBjZXJ0aWZpY2F0ZSBhbGwgdGhlIHRpbWUuJm5ic3A7 IFNvbWV0aW1lcyBhIHNlcnZlciB3aWxsIHByZXNlbnQgYQ0KPGEgaHJlZj0iaHR0cDovL2xvZ2lu LmV4YW1wbGUuY29tIj5sb2dpbi5leGFtcGxlLmNvbTwvYT4gY2VydGlmaWNhdGUgb24gb25lIGNv bm5lY3Rpb24sIGFuZCAqLjxhIGhyZWY9Imh0dHA6Ly9leGFtcGxlLmNvbSI+ZXhhbXBsZS5jb208 L2E+IG9uIGFub3RoZXIuJm5ic3A7IE1vc3QgbGlrZWx5LCB0aGUgY29va2llIHRoYXQgaXMgdXNl ZCBmb3IgYXV0aCB3b3VsZCBiZSBib3VuZCB0bw0KPGEgaHJlZj0iaHR0cDovL2xvZ2luLmV4YW1w bGUuY29tIj5sb2dpbi5leGFtcGxlLmNvbTwvYT4sIGFuZCB3b3VsZCBiZSByZWplY3RlZCBmb3Ig YWxsIG90aGVyICouPGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tIj5leGFtcGxlLmNvbTwvYT4g ZG9tYWlucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSBsaWtlIHRoZSBpZGVhIG9mIHNpZ25pbmcgZXh0ZW5zaW9ucyBhbmQgYWxzbyB0aGUg aG9zdCBuYW1lIGZyb20gdGhlIGhvc3QgaGVhZGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CaWxsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBBcHIgMywgMjAxNyBhdCA5 OjQ3IEFNLCBOaWNrIFN1bGxpdmFuICZsdDs8YSBocmVmPSJtYWlsdG86bmljaG9sYXMuc3VsbGl2 YW5AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bmljaG9sYXMuc3VsbGl2YW5AZ21haWwuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHRva2VuIGJpbmRpbmcgaGVhZGVyIGRv ZXMgbm90IGhhdmUgYW55IGlkZW50aXR5IGJvdW5kIHRvIGl0LiBUaGlzIGlzIHBvdGVudGlhbGx5 IHByb2JsZW1hdGljIGJlY2F1c2UgaXQgbWFrZXMgaXQgbXVjaCBtb3JlIGxpa2VseSB0aGF0IHRo aXMgcHJvdG9jb2wgaXMgdnVsbmVyYWJsZSB0byB1bmtub3duIGtleSBzaGFyZSBpc3N1ZXMuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlVua25v d24ga2V5IHNoYXJlIGF0dGFja3MgaGFwcGVuIHdoZW4gYSBwdWJsaWMga2V5IGlzIHVzZWQgd2l0 aG91dCBiaW5kaW5nIGl0IHRvIGFuIGlkZW50aXR5IGJ5IGEgc2lnbmF0dXJlLiBGb3IgZXhhbXBs ZSwgUmljaGFyZCBCYXJuZXMgcmVjZW50bHkgcHVibGlzaGVkIGEgZHJhZnQgZGVzY3JpYmluZyBo b3cgREFORSB3aXRoIHJhdyBrZXlzIHdhcyB2dWxuZXJhYmxlIHRvIHRoaXMgc3R5bGUgb2Y6DQo8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmFybmVzLWRhbmUtdWtz LTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJh cm5lcy1kYW5lLXVrcy0wMDwvYT4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkluIHNlY3Rpb24gMi4xLiBvZiBkcmFmdC1pZXRmLXRva2JpbmQt aHR0cHMsIHRoZSBrZXkgcGFpciBzY29waW5nIGlzIGRlZmluZWQgdG8gYmUgZVRMRCYjNDM7MS4g RGVwZW5kaW5nIG9uIHRoZSB0aHJlYXQgbW9kZWwsIHRoaXMgcmVxdWlyZW1lbnQgY2FuIGJlIHN1 YnZlcnRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5Db25zaWRlciBhbiBhdHRhY2tlciB3 aG8gaGFzIGFjY2VzcyB0byByZWFkIGFuZCBtb2RpZnkgaGVhZGVycywgYnV0IG5vdCBwcml2YXRl IGtleXMuIEltYWdpbmUgYSBidWdneS9tYWxpY2lvdXMgc2VydmljZSB3b3JrZXIgb3Igc29tZXRo aW5nIGVsc2Ugb2YgdGhpcyBzb3J0LiBOb3cgaW1hZ2luZSBhIHNpdGUgd2l0aA0KPGEgaHJlZj0i aHR0cDovL2EuZXhhbXBsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5hLmV4YW1wbGUuY29tPC9hPiBh bmQgPGEgaHJlZj0iaHR0cDovL2IuZXhhbXBsZS5jb20iIHRhcmdldD0iX2JsYW5rIj4NCmIuZXhh bXBsZS5jb208L2E+IGFuZCBhIHdpbGRjYXJkICouPGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29t IiB0YXJnZXQ9Il9ibGFuayI+ZXhhbXBsZS5jb208L2E+IGNlcnRpZmljYXRlLiBUaGUgYXR0YWNr ZXIgY2FuIHRha2UgdG9rZW4gYmluZGluZyBoZWFkZXJzIGZyb20NCjxhIGhyZWY9Imh0dHA6Ly9h LmV4YW1wbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+YS5leGFtcGxlLmNvbTwvYT4gYW5kIHB1dCB0 aGVtIG9uIHJlcXVlc3RzIHRvDQo8YSBocmVmPSJodHRwOi8vYi5leGFtcGxlLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmIuZXhhbXBsZS5jb208L2E+IGFuZCB0aGUgY29va2llcyBzZXQgb24NCjxhIGhy ZWY9Imh0dHA6Ly9iLmV4YW1wbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+Yi5leGFtcGxlLmNvbTwv YT4gd2lsbCBiZSBib3VuZCB0bw0KPGEgaHJlZj0iaHR0cDovL2EuZXhhbXBsZS5jb20iIHRhcmdl dD0iX2JsYW5rIj5hLmV4YW1wbGUuY29tPC9hPidzIGtleS48YnI+DQo8YnI+DQpUaGlzIGRvZXNu J3Qgc291bmQgbGlrZSBhIGxhcmdlIGlzc3VlLCBidXQgaXQncyBpbmRpY2F0aXZlIG9mIHRoZSB0 eXBlIG9mIHN1YnRsZSBwcm9ibGVtcyBub3QgYmluZGluZyB0aGUga2V5IHRvIGEgY29udGV4dCBj YW4gY2F1c2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JZiB0aGUgdG9rZW4gY29udGV4dCB3YXMgYm91bmQgdG8gdGhlIHNjb3BlIGJ5IGluY2x1 ZGluZyB0aGUgZVRMRCYjNDM7MSBpbiB0aGUgKG9yIHRoZSBvcmlnaW4gaWYgdGhlIGJyb3dzZXIg aW50ZW5kcyB0byB1c2Ugc3RyaWN0ZXIgdG9rZW4gc2NvcGluZyksICphbmQqIHRoaXMgc2NvcGUg d2FzIGNvdmVyZWQgYnkgdGhlIHNpZ25hdHVyZSB0aGVuIHRoaXMgd291bGQgbm90IGJlIHBvc3Np YmxlLiBUaGUgc2VydmVyIGNvdWxkDQogY2hlY2sgdGhlIGhvc3QgaGVhZGVyIGFnYWluc3QgdGhl IHRva2VuIGNvbnRleHQgYW5kIHRoZW4gcmVmdXNlIHRoZSB0b2tlbiBiaW5kaW5nIGZvciBuZXcg Y29va2llcy48YnI+DQo8YnI+DQpBIGxvZ2ljYWwgcGxhY2UgdG8gcHV0IHRoaXMgd291bGQgYmUg aW4gdGhlIGV4dGVuc2lvbnMgb2YgdGhlIHRva2VuIGJpbmRpbmcgc3RydWN0dXJlLCBidXQgdW5m b3J0dW5hdGVseSB0aGUgZXh0ZW5zaW9ucyBpcyBub3Qgc2lnbmVkIGFuZCBzbyBjYW4gYmUgbW9k aWZpZWQuIElzIHRoZXJlIGEgcmVhc29uIHRoZSBleHRlbnNpb25zIGZpZWxkIG9mIHRoZSBUb2tl bkJpbmRpbmcgc3RydWN0dXJlIGlzIG5vdCBzaWduZWQgYnkgdGhlIHByaXZhdGUga2V5PzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImhvZW56YiI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPk5pY2s8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VW5i ZWFyYWJsZUBpZXRmLm9yZyI+VW5iZWFyYWJsZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGU8 L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_SN1PR21MB0096465FDA68EB982F457CC08C080SN1PR21MB0096namp_-- From nobody Tue Apr 4 15:55:42 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37E01293FF for ; Tue, 4 Apr 2017 15:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.021 X-Spam-Level: X-Spam-Status: No, score=-7.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGDNmCNmzahX for ; Tue, 4 Apr 2017 15:55:39 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1200D1294F0 for ; Tue, 4 Apr 2017 15:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1491346533; x=1522882533; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=w1gBTOEtgzUwDEFYtbZgWNmPgOEXoL5epsFdCTKBRsE=; b=BGUbZ2ovAEA4dFc+c+/2ExZjRGfndt19W3MZ5Pig8aUbidR6uAzipvCt cUhenIq0kWOM0cCaE768mNTx0Gal34KfnVr5DOnrAFPoqna/u0eecWNRI K12UJW7jPsC2vMWPT9S1qLz01wHiaq94rvp0H6mmDhGKQz44EO8iHNero g=; X-IronPort-AV: E=Sophos;i="5.36,276,1486454400"; d="scan'208";a="371381073" Received: from unknown (HELO ironmsg02-R.qualcomm.com) ([10.53.140.106]) by wolverine02.qualcomm.com with ESMTP; 04 Apr 2017 15:55:32 -0700 X-IronPort-AV: E=McAfee;i="5800,7501,8488"; a="932848981" X-MGA-submission: =?us-ascii?q?MDGG+A1cZaidaxg5PehyZ9DhkXKRNyeo1Lkckd?= =?us-ascii?q?KZ+G+m98uaj79yoMckgeOjRPVipPr9+QKcErvYNGeJk+pt3m2oYDeRZh?= =?us-ascii?q?05XEUHbkcfsKo1YCf1PbYpblLHevLC1g6S0xUodqueSCr4WFM8cy4PeP?= =?us-ascii?q?np?= Received: from nasanexm01e.na.qualcomm.com ([10.85.0.31]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Apr 2017 15:55:31 -0700 Received: from NASANEXM01C.na.qualcomm.com (10.85.0.83) by NASANEXM01E.na.qualcomm.com (10.85.0.31) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 4 Apr 2017 15:55:31 -0700 Received: from NASANEXM01C.na.qualcomm.com ([10.85.0.83]) by NASANEXM01C.na.qualcomm.com ([10.85.0.83]) with mapi id 15.00.1178.000; Tue, 4 Apr 2017 15:55:31 -0700 From: Giridhar Mandyam To: "unbearable@ietf.org" Thread-Topic: [Unbearable] question about draft-mandyam-tokbin-attest-01 Thread-Index: AQHSqDd8tx2aELMl9EyolbenQZRkMKG11icg Date: Tue, 4 Apr 2017 22:55:30 +0000 Message-ID: References: <20170329025208.GT30306@kduck.kaduk.org> In-Reply-To: <20170329025208.GT30306@kduck.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.80.80.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Unbearable] question about draft-mandyam-tokbin-attest-01 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2017 22:55:42 -0000 Thank you for your feedback. This document was not really meant to provide= justification for the usefulness of TLS Token binding with respect to MITM= - I believe that has already been done in Sec. 7.4 of [1]. Moreover in [2] the author describes TLS vulnerability to MITM due to attac= ks such as DROWN [3], and how TLS token binding can be used to address the = effects of such an attack (e.g. reuse of auth tokens). =20 I'll also ask for a clarification from you regarding what you mean by "(mod= ern) TLS". For instance, do you mean TLS 1.3? Could this include TLS 1.2 = (which allows for NULL cipher suite among other cipher suites with known vu= lnerabilities)? -Giri Mandyam [1] A. Popov et al. "Token Binding over HTTP." draft-ietf-tokbind-https-0= 8. February 16, 2017. https://tools.ietf.org/html/draft-ietf-tokbind-http= s-08#section-7.4. [2] Balfanz, D. "FIDO Tech Notes: Channel Binding and FIDO." https://fid= oalliance.org/fido-technotes-channel-binding-and-fido/. May 23, 2016. [3] Aviram, N. et al. "DROWN: Breaking TLS using SSLv2." Proceedings of = the 25th USENIX Security Symposium. August 2016. Available at https://dro= wnattack.com/drown-attack-paper.pdf. -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Benjamin= Kaduk Sent: Tuesday, March 28, 2017 7:52 PM To: unbearable@ietf.org Subject: [Unbearable] question about draft-mandyam-tokbin-attest-01 I only quickly looked at this document before the meeting, but had a questi= on about this line in the introduction that "this is useful for prevention = of man-in-the-middle attacks on TLS sessions"; (modern) TLS is supposed to prevent man in the middle attacks all on its ow= n, so I don't understand what this is attempting to say. -Ben _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable From nobody Tue Apr 4 16:28:50 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B07128B4E for ; Tue, 4 Apr 2017 16:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com; domainkeys=pass (1024-bit key) header.sender=andreipo=microsoft.com@github.com header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X14puHBa64Y8 for ; Tue, 4 Apr 2017 16:28:47 -0700 (PDT) Received: from m69-169.mailgun.net (m69-169.mailgun.net [166.78.69.169]) (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 843C11270A3 for ; Tue, 4 Apr 2017 16:28:45 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1491348524; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=aZP8PdHzLOoUxf3E3u7RTc9BctBsUp6WL6Zt9eTeG9U=; b=R1D505ZioY+pFS2CMkW7mYeUGZHbDE7+2N3O7h2XcfftYnvz2RufgXUgDNaaGypwNJ8LdXuy 5DJWSxkGM8CHuoVm+3p5/v3bLjgGcmKomXNg2qozJ3m4i4NXnZ40+Wj+2BS3hI+RZ/g/HRH6 hBPxoc/UKp21SFYcfwrifs+UXrw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=github.com; s=mailo; q=dns; h=Sender: Date: From: Reply-To: To: Message-ID: Subject: Mime-Version: Content-Type: Content-Transfer-Encoding; b=Z8d/CpLWECzsbKLn/0gpePTI8nbEv/ucsKjJv9DLcFWLfDXjHuRSHmwU/gmDocKdb0vocj xuqJ/zbJPjCaMiHB/5kppp/FKq3MLwg6nFBWRC+l5wPgezSpl9R50wWoh0vuGWEglYzImqsI /xnqw8tV4cJBxVtAnzMWAiN7LOgV0= Sender: andreipo=microsoft.com@github.com X-Mailgun-Sending-Ip: 166.78.69.169 X-Mailgun-Sid: WyIzMTNlNyIsICJ1bmJlYXJhYmxlQGlldGYub3JnIiwgIjQwZiJd Received: from github.com (Unknown [192.30.252.41]) by mxa.mailgun.org with ESMTP id 58e42c2c.7f7be81591b0-smtp-out-n01; Tue, 04 Apr 2017 23:28:44 -0000 (UTC) Date: Tue, 04 Apr 2017 16:28:44 -0700 From: Andrei Popov Reply-To: Andrei Popov To: unbearable@ietf.org Message-ID: <58e42c2c5b477_1b563fc7fb2b7c3c629d4@hookshot-fe5-cp1-prd.iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_58e42c2c5b110_1b563fc7fb2b7c3c62886"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Unbearable] [TokenBinding/Internet-Drafts] 24beef: Incorporating WGLC comments in TBNEGO. X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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, 04 Apr 2017 23:28:49 -0000 ----==_mimepart_58e42c2c5b110_1b563fc7fb2b7c3c62886 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/TokenBinding/Internet-Drafts Commit: 24beeffabcfc657f00df80a57faee86f9ef47821 https://github.com/TokenBinding/Internet-Drafts/commit/24beeffabcfc657f00df80a57faee86f9ef47821 Author: Andrei Popov Date: 2017-04-04 (Tue, 04 Apr 2017) Changed paths: M README.md R draft-ietf-tokbind-negotiation-07.xml A draft-ietf-tokbind-negotiation-08.xml Log Message: ----------- Incorporating WGLC comments in TBNEGO. ----==_mimepart_58e42c2c5b110_1b563fc7fb2b7c3c62886-- From nobody Tue Apr 4 17:31:48 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54BC5129436 for ; Tue, 4 Apr 2017 17:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dof5dgYGTnng for ; Tue, 4 Apr 2017 17:06:11 -0700 (PDT) Received: from o1.sgmail.github.com (o1.sgmail.github.com [192.254.114.176]) (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 632E012944F for ; Tue, 4 Apr 2017 17:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=IVxLHNGVVKnTfAxFvFr5r+pKbAI=; b=huwgw2gSGMV0x5HP icYjwDZ0BUNDWts3Liyupyyr1+ofWh2CCr8BPyJEMYGA4oQBobN4K3jccCzx3/gz VrhS3Lnez9HrvPvasHv++VZM8yCjoTebaQC4BplX9KxDHT+QQSV2j5a7RIUV+2u4 W0xZwsiKBtvEFD49bAg4W6unQhY= Received: by filter0426p1mdw1.sendgrid.net with SMTP id filter0426p1mdw1-21913-58E434F1-2B 2017-04-05 00:06:09.672855791 +0000 UTC Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2a-ext-cp1-prd.iad.github.net [192.30.253.16]) by ismtpd0002p1iad1.sendgrid.net (SG) with ESMTP id os8-vcMZQPqdVe-bC5JC2Q for ; Wed, 05 Apr 2017 00:06:09.615 +0000 (UTC) Date: Tue, 04 Apr 2017 17:06:09 -0700 From: Andrei-Popov Reply-To: TokenBinding/Internet-Drafts To: TokenBinding/Internet-Drafts Cc: Subscribed Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58e434f182295_53643f8c27a15c3c11862c"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: Andrei-Popov X-GitHub-Recipient: unbearable-ML X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org X-SG-EID: 9Yqp9dCIIwZxB0MVAPExrXlt7a4/46ALD9aG/N3UOYpt7nIKYoAPchMrhFpLu/T3Ny4RiC29wMx9fJ BcbCfcH8BUjhWB24+aBkGVgNCf3Dkmt+LcnTLCuVg4rXj8OF4eIG73vpOSPGMEwafoGzWmZO3bsk/w rOGOtZpMPsBSgBDuS6O4CBujmN28LKWCYcE+GJP/AYCAKvh0HQvKBZ0Q37melPsW+rF7kxFfuuSCPP A= Archived-At: X-Mailman-Approved-At: Tue, 04 Apr 2017 17:31:37 -0700 Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] Reconcile interactions between TBNEGO and TLS 1.3 (#98) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 00:06:13 -0000 ----==_mimepart_58e434f182295_53643f8c27a15c3c11862c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #98. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/TokenBinding/Internet-Drafts/issues/98#event-1029415693 ----==_mimepart_58e434f182295_53643f8c27a15c3c11862c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #98.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_58e434f182295_53643f8c27a15c3c11862c-- From nobody Tue Apr 4 17:31:53 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E7F129459 for ; Tue, 4 Apr 2017 17:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.474 X-Spam-Level: X-Spam-Status: No, score=-0.474 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnyGmk0yjggJ for ; Tue, 4 Apr 2017 17:06:49 -0700 (PDT) Received: from o10.sgmail.github.com (o10.sgmail.github.com [167.89.101.201]) (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 73FA7127449 for ; Tue, 4 Apr 2017 17:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=TforXo17VaOJa5MotHlQ4TJnKJs=; b=FOwmflTiQmwF+Kke OqXITng+jsDt17oaxMMo5mFUSW52D24t0Opzmc1yFms9iyRuJOehrW+ky7N1K3oP s9RygY6mmXF19zDUCjeotJ2b8z6jzlhQT1KpYR3XhrVR5X6l7TDYSTCt06h6mzsA algB+T/PGYH83FRBFdFsRyR+mAs= Received: by filter0841p1mdw1.sendgrid.net with SMTP id filter0841p1mdw1-13418-58E434F1-51 2017-04-05 00:06:09.719379404 +0000 UTC Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2b-ext-cp1-prd.iad.github.net [192.30.253.17]) by ismtpd0006p1iad1.sendgrid.net (SG) with ESMTP id HxtBW6mVRMOFsDEioI3ETg for ; Wed, 05 Apr 2017 00:06:09.698 +0000 (UTC) Date: Tue, 04 Apr 2017 17:06:09 -0700 From: Andrei-Popov Reply-To: TokenBinding/Internet-Drafts To: TokenBinding/Internet-Drafts Cc: Subscribed Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58e434f19737c_7bad3fa7bcbb7c3888656"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: Andrei-Popov X-GitHub-Recipient: unbearable-ML X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org X-SG-EID: 9Yqp9dCIIwZxB0MVAPExrXlt7a4/46ALD9aG/N3UOYr+ffBJNM2wNYFPgBGp1827k9m5Tm6Fxk+XlX nshbcO25LIxHa0LcCReDCz/yuaJYrC+sdMmiuwisezJRrJJ45cqiEz2P0SLnfU1EhznHligWMF/2OR 1XXPD57QeWIh7Ukrb40GrBBFsaJY2aUVxCkjw2UUM265+NbSQdmC0Kuh6shMFEyywwXQ1zHmWseb/6 E= Archived-At: X-Mailman-Approved-At: Tue, 04 Apr 2017 17:31:45 -0700 Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] Reconcile interactions between TBNEGO and TLS 1.3 (#98) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 00:06:55 -0000 ----==_mimepart_58e434f19737c_7bad3fa7bcbb7c3888656 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Fixed in TBNEGO-08. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/TokenBinding/Internet-Drafts/issues/98#issuecomment-291682163 ----==_mimepart_58e434f19737c_7bad3fa7bcbb7c3888656 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Fixed in TBNEGO-08.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_58e434f19737c_7bad3fa7bcbb7c3888656-- From nobody Wed Apr 5 12:59:01 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25571242F5 for ; Wed, 5 Apr 2017 12:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com; domainkeys=pass (1024-bit key) header.sender=andreipo=microsoft.com@github.com header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtDsGQ6Nsv-4 for ; Wed, 5 Apr 2017 12:58:58 -0700 (PDT) Received: from m69-170.mailgun.net (m69-170.mailgun.net [166.78.69.170]) (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 66856127A90 for ; Wed, 5 Apr 2017 12:58:58 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1491422337; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=onknTTFodFMmgqLx8JJekgaDwn8z89+M0ooKlTu2LFw=; b=BSirpHzUpEuczm2eBqwWiPCUWTivqzhTr1+pDWX/adhc5UAlqAkSPVoSkU9eEF3/ctr8IlEK eRXYZ8ZonktsfV1XglJMcrSHEop49Vx3kN1H3jN0eVXdQ4vmHvvR5dY/lxHgrO+NwHzx7SvC m81+cj6hbriR3/PqlC95+z7nPdk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=github.com; s=mailo; q=dns; h=Sender: Date: From: Reply-To: To: Message-ID: Subject: Mime-Version: Content-Type: Content-Transfer-Encoding; b=bm9FMRRO1fD2EyZhwC21TnvkDye1xqgpCEUtzyqeAWXoKgB70RWG77g01KnSyEBPQy/lms kTImtXKbJgxPuTtiTe4kFkx87nk9Dw2AtKXM5cqEalC0fFLwCuEask2itXbBa+NTqA2W0tDP Jl7N9bGTSCXm0iJxng5sDhAwcc5Ts= Sender: andreipo=microsoft.com@github.com X-Mailgun-Sending-Ip: 166.78.69.170 X-Mailgun-Sid: WyIzMTNlNyIsICJ1bmJlYXJhYmxlQGlldGYub3JnIiwgIjQwZiJd Received: from github.com (Unknown [192.30.252.40]) by mxa.mailgun.org with ESMTP id 58e54c80.7f06b939fba0-smtp-out-n03; Wed, 05 Apr 2017 19:58:56 -0000 (UTC) Date: Wed, 05 Apr 2017 12:58:56 -0700 From: Andrei Popov Reply-To: Andrei Popov To: unbearable@ietf.org Message-ID: <58e54c80105b3_7dcd3f81a6821c4099362@hookshot-fe6-cp1-prd.iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_58e54c80100a3_7dcd3f81a6821c40992dc"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Unbearable] [TokenBinding/Internet-Drafts] b14d90: Incorporating WGLC comments in TBPROTO. X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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: Wed, 05 Apr 2017 19:59:01 -0000 ----==_mimepart_58e54c80100a3_7dcd3f81a6821c40992dc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/TokenBinding/Internet-Drafts Commit: b14d902a2691e0221795ff028f0d2d181c52d950 https://github.com/TokenBinding/Internet-Drafts/commit/b14d902a2691e0221795ff028f0d2d181c52d950 Author: Andrei Popov Date: 2017-04-05 (Wed, 05 Apr 2017) Changed paths: M README.md R draft-ietf-tokbind-protocol-13.xml A draft-ietf-tokbind-protocol-14.xml Log Message: ----------- Incorporating WGLC comments in TBPROTO. ----==_mimepart_58e54c80100a3_7dcd3f81a6821c40992dc-- From nobody Tue Apr 18 15:25:09 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047A81314B7 for ; Tue, 18 Apr 2017 15:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80YtQ3okZHNI for ; Tue, 18 Apr 2017 15:25:04 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE5F1314B3 for ; Tue, 18 Apr 2017 15:25:03 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id c80so3370015lfh.3 for ; Tue, 18 Apr 2017 15:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ESPv51Q4Ex2ZPFdoJO2ij14aBnahT/O4KowNXE6rhF8=; b=m5nz7SsQHrnva6/wzom4vRnL/R4DgboYFAWSEPKRUZuHTJYKgAIiS//93Qhm5R2npE BofosHi3ztI52AsqiyYDGxub+QPr8LI1E1WMBqOA+gFt0gjsomxeT0m3NnJlA9FJ7g52 UuSllqXHgNwyLwSJjyAPD0Map/DbJjkIC0y7QcfT8r5NFRLNZ5Xkgdz7Zrp7pF8rx2cP hSVNv87+Xn7SIHZHPDN4X+vc3kThAr2L/P59dN/JzR1aRzlD4DaUQXZn0m0vAmaeske7 E7fL89qqZLhTfwCBv3uPGLB8OQfmcKpa7QP8dxXCd+2xFPm8vCCpBURltoxgAMHdr7zS kXIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ESPv51Q4Ex2ZPFdoJO2ij14aBnahT/O4KowNXE6rhF8=; b=sOwBHCeiQ531IEpKNX05+tL3BaKTtYNluSw6aPh6iE7J7xJ7v9p5bWCqvgxWL4d42b 65d2WsGepqftQHMr0j4UQ77t6Nkl8KiWl6i68kobZwYd59PXwphj2QEbx+SH9fl7jPpr DKmCbV3UeZQf60eBIW56Z/jfKZeYyeO5KM6La7pRNSCIysET9Ie7WfXSBWkChAihv4vT CsmiHRfa/gws4S4HQgVuWvxqh3DQJg8fln6pHNjs3zX+rHRSLG1/ATuCAI0c1cANxg4q g/8yViutPPoZPR5cV9T/yy9E5agMM86cS54WjGc3rxHCXH3O/d5mA8EwpO/zIJfQZzfB Mb/g== X-Gm-Message-State: AN3rC/4uWpD2sVwneZOxjG6Vi+iDQZxLosVSZ/a5mQY2HGC5UTg7L6bP Cgms+AWQ1oCQKp5lSixBoTDyzksPfu1agnA= X-Received: by 10.46.76.10 with SMTP id z10mr50278lja.8.1492554301254; Tue, 18 Apr 2017 15:25:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.150.7 with HTTP; Tue, 18 Apr 2017 15:24:40 -0700 (PDT) From: Nick Harper Date: Tue, 18 Apr 2017 15:24:40 -0700 Message-ID: To: IETF Tokbind WG Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Unbearable] Switching exporters for 0-RTT Token Binding X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 22:25:07 -0000 One of the issues raised in Chicago around 0-RTT Token Binding is whether or not to switch from the 0-RTT exporter to the normal exporter, and I'd like to get some feedback from the Working Group on this. The two options I'm considering are as follows: 1) Always use the 0-RTT exporter on connections where 0-RTT data is accepted. 2) Use the 0-RTT exporter for Token Binding messages sent in 0-RTT. The client switches to using the normal exporter soon after the handshake finishes, but it may send some Token Binding messages post-handshake using the 0-RTT exporter. In both cases, if the server rejects 0-RTT data, the client uses the normal exporter (i.e. the client behaves the same as in TBPROTO). I'm currently leaning towards option 1. Below are my arguments for each option. I'm interested in hearing additional arguments for/against each option and what people's preference is. I'm particularly interested in the opinion of server operators who would be implementing this. For option 1: Option 1 is simple to implement. No extension (or other mechanism) is needed in the TokenBinding struct to indicate which exporter was used to avoid the server needing to do trial verification. Code paths are simpler on both the client and server when the exporter value remains constant for the whole connection. When a server is choosing whether to accept or reject 0-RTT data, it cannot base this decision on the content of the 0-RTT data, which means that a server that chooses to accept a 0-RTT Token Binding makes that decision without knowing what the message contents are. It follows that said server finds the security properties of 0-RTT Token Binding acceptable on any request received in 0-RTT. If a server finds the security properties of 0-RTT Token Binding acceptable on a request when it is received in 0-RTT data, then it would only be logical for it to find those security properties acceptable when that request is not in 0-RTT data (i.e. post-handshake), and since that server will accept any message (with 0-RTT Token Binding) in 0-RTT data (because it can't choose whether or not to do 0-RTT based on message contents), there would be no case where the server would only accept the normal exporter. For option 2: A server might have some requests where it is fine with the security properties of 0-RTT Token Binding, and others where it wants the full protection of the (normal) exporter. If the server can ask the client to re-send a request with the normal Token Binding exporter, it can accept some requests sent in 0-RTT with the 0-RTT exporter, and for others it can request the client to re-send, which if the client is switching exporters, it will re-send with the normal exporter. Option 2 relies on the application layer having some mechanism that a server can use to ask a client to retry a request - TLS has no mechanism to reject 0-RTT data after it has been accepted (or to request the client to re-send the 0-RTT data under 1-RTT keys). For HTTP, I think this can be done with a 307 response code. Option 1 needs no such application layer support. From nobody Tue Apr 18 15:56:26 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA24B1314DC for ; Tue, 18 Apr 2017 15:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JT6qg8rio3cB for ; Tue, 18 Apr 2017 15:51:18 -0700 (PDT) Received: from o10.sgmail.github.com (o10.sgmail.github.com [167.89.101.201]) (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 939591314BA for ; Tue, 18 Apr 2017 15:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=TeKSsuXjfnBJzBoz2TAlpWnGX3w=; b=khCrc4ij4ky/ui0K KHiZ1SqSIRUb5BkNAmiTXwsgmc1ptfPtCcqZMyhnHNibQYbS0M6twuWJH7+ZvXe9 TD8h/E//zMcZhBr0ZPYLnyiYAaSjjS9OfbhpwrYHmH+//OQBWLnvt23i1QfyCUZX tARF+1xDSOciJLKYgQiCsT+R1Zg= Received: by filter0811p1mdw1.sendgrid.net with SMTP id filter0811p1mdw1-14127-58F69864-D 2017-04-18 22:51:16.186127953 +0000 UTC Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2a-ext-cp1-prd.iad.github.net [192.30.253.16]) by ismtpd0003p1iad1.sendgrid.net (SG) with ESMTP id xkH-7bSAT1uHjpOXNK4HmQ for ; Tue, 18 Apr 2017 22:51:16.159 +0000 (UTC) Date: Tue, 18 Apr 2017 15:51:16 -0700 From: =JeffH Reply-To: TokenBinding/Internet-Drafts To: TokenBinding/Internet-Drafts Cc: Subscribed Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58f69864b8b5_290a3fd434eb3c301346b0"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: equalsJeffH X-GitHub-Recipient: unbearable-ML X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org X-SG-EID: 9Yqp9dCIIwZxB0MVAPExrXlt7a4/46ALD9aG/N3UOYpTNOJsNaLBWNXyI+hiiEafIzojE6TcarmN+U 4Gj1iBsQIy57UN9d9VD/RFbnltqcYzCQAKfcBZ4VMhMndrZXQjh1mCKrj9q4XaNPF//mzWbp0i0kqg BtYuLypKnXvAXQenNutEX0DJSIrG24hwpaeXgI4G3V2URzk9+cCCpNJ6eA== Archived-At: X-Mailman-Approved-At: Tue, 18 Apr 2017 15:56:24 -0700 Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] HTTPSTB: apply Mike Jones' feedback (#96) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 22:51:20 -0000 ----==_mimepart_58f69864b8b5_290a3fd434eb3c301346b0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit equalsJeffH commented on this pull request. > @@ -391,16 +389,19 @@ the encompassing application. - The scoping for those Token Binding key pairs generated by Web browsers in - the context of the first-party and federation use cases defined in this - specification (below), and to be used for binding HTTP cookies MUST be at the - granularity of "effective top-level domain (public suffix) + 1" (eTLD+1), - i.e., at the same granularity at which cookies can be set - (see ). Key pairs used to bind other application + The scoping of Token Binding key pairs generated by Web browsers for use in + first-party and federation use cases defined in this + specification (, below), and intended for + binding HTTP cookies, MUST be at the done. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/TokenBinding/Internet-Drafts/pull/96#discussion_r112082891 ----==_mimepart_58f69864b8b5_290a3fd434eb3c301346b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@equalsJeffH commented on this pull request.

In draft-ietf-tokbind-https-09.xml:

> @@ -391,16 +389,19 @@
         the encompassing application. 
         </t>
         
-        <t>The scoping for those Token Binding key pairs generated by Web browsers in 
-        the context of the first-party and federation use cases defined in this 
-        specification (below), and to be used for binding HTTP cookies MUST be at the 
-        granularity of "effective top-level domain (public suffix) + 1" (eTLD+1), 
-          i.e., at the same granularity at which cookies can be set 
-          (see <xref target="RFC6265"/>).  Key pairs used to bind other application
+        <t>The scoping of Token Binding key pairs generated by Web browsers for use in 
+        first-party and federation use cases defined in this 
+        specification (<xref target="federation"/>, below), and intended for 
+        binding HTTP cookies, MUST be at the

done.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_58f69864b8b5_290a3fd434eb3c301346b0-- From nobody Tue Apr 18 15:56:32 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD75C1314BA for ; Tue, 18 Apr 2017 15:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.396 X-Spam-Level: X-Spam-Status: No, score=-8.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlvt2B9Cd-Yi for ; Tue, 18 Apr 2017 15:51:29 -0700 (PDT) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext4.iad.github.net [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFFD51314DD for ; Tue, 18 Apr 2017 15:51:28 -0700 (PDT) Date: Tue, 18 Apr 2017 15:51:28 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1492555888; bh=eI1jE6in2rdiDVntfeq5hBOoFOopA07rPqlIptsi/sc=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=y/HVrzl/NahRC5URl9zJPDxXC2REkJWrs9vQwjCSELDenxV/B6TIwI9RbYYWT3Kd8 jtdmCxMaVUZihWQs3equX5Zsu6f4+Gu/Hh+LGxNI7e5RdKoTNrLPcKHJIEUNG+vzTs HbhY1kzzblfYWsKrO69e0Z638sNt2gDaCPr0Lv18= From: =JeffH Reply-To: TokenBinding/Internet-Drafts To: TokenBinding/Internet-Drafts Cc: Subscribed Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58f6987014017_20b13fd5fe7f1c3c846e4"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: equalsJeffH X-GitHub-Recipient: unbearable-ML X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org Archived-At: X-Mailman-Approved-At: Tue, 18 Apr 2017 15:56:24 -0700 Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] HTTPSTB: apply Mike Jones' feedback (#96) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 22:51:31 -0000 ----==_mimepart_58f6987014017_20b13fd5fe7f1c3c846e4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit equalsJeffH commented on this pull request. > assertion). To better protect the security of the identity token, the Identity Provider may wish to bind the identity token to the TLS connection between the client and the Relying Party, thus - ensuring that only said client can use the identity token: The - Relying Party will compare the Token Binding ID in the identity - token with the Token Binding ID of the TLS connection between it - and the client. + ensuring that only said client can use the identity token; the + Relying Party will compare the Token Binding ID (or a cryptographic + hash of it) in the identity token with the Token Binding ID of the done, i think. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/TokenBinding/Internet-Drafts/pull/96#discussion_r112082913 ----==_mimepart_58f6987014017_20b13fd5fe7f1c3c846e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@equalsJeffH commented on this pull request.

In draft-ietf-tokbind-https-09.xml:

>  	assertion).</t>
 	<t>To better protect the security of the identity token, the
 	Identity Provider may wish to bind the identity token to the TLS
 	connection between the client and the Relying Party, thus
-	ensuring that only said client can use the identity token: The
-	Relying Party will compare the Token Binding ID in the identity
-	token with the Token Binding ID of the TLS connection between it
-	and the client.</t>
+	ensuring that only said client can use the identity token; the
+	Relying Party will compare the Token Binding ID (or a cryptographic 
+	hash of it) in the identity token with the Token Binding ID of the

done, i think.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_58f6987014017_20b13fd5fe7f1c3c846e4-- From nobody Tue Apr 18 15:56:38 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B931314DD for ; Tue, 18 Apr 2017 15:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.617 X-Spam-Level: X-Spam-Status: No, score=-0.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTVfLZQt9ASu for ; Tue, 18 Apr 2017 15:51:49 -0700 (PDT) Received: from o11.sgmail.github.com (o11.sgmail.github.com [167.89.101.202]) (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 C5BC41314DC for ; Tue, 18 Apr 2017 15:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=Ur47Ux8NFw9G66ORNGNWUSLrz1M=; b=qe/Nq++J9ISn3Jg1 Nr4N1fo+F21twapw5ekIMRsgMixhSWxC4+IdmjS0UHBXvd4xwFg3g0Qq5qhlh9J4 lcVITvVIUOZF0iu0N2pc66Uh7QJTePgTZ6RltnJ0aoWvOXUe2Iyc42L3+zgeIY1r /Y7XJ9UKkIm7gxRVKWeTDf40lIs= Received: by filter0599p1mdw1.sendgrid.net with SMTP id filter0599p1mdw1-12210-58F6987C-1 2017-04-18 22:51:40.016433703 +0000 UTC Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2b-ext-cp1-prd.iad.github.net [192.30.253.17]) by ismtpd0005p1iad1.sendgrid.net (SG) with ESMTP id xgAMYHXsS4WIUcQOKxOpvQ for ; Tue, 18 Apr 2017 22:51:40.008 +0000 (UTC) Date: Tue, 18 Apr 2017 15:51:39 -0700 From: =JeffH Reply-To: TokenBinding/Internet-Drafts To: TokenBinding/Internet-Drafts Cc: Subscribed Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58f6987be4f78_2ebf3f8527f6bc38629c"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: equalsJeffH X-GitHub-Recipient: unbearable-ML X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org X-SG-EID: 9Yqp9dCIIwZxB0MVAPExrXlt7a4/46ALD9aG/N3UOYpyqDuw6ES92fNJAf+zeo4pBmag5qybn/FgPV OteHYOkCEbyag0BB91nR+ejCc3OgESpQI4O/dd/4afGSRbV5FM7GxGFBffjdpSLchd5mM5CHuD158y /Swz9jtnvxaCz5/4PKxZ3YfZ1a1hqMOtiE8UinHnLZDkNC+Ac+iCkPXKTg== Archived-At: X-Mailman-Approved-At: Tue, 18 Apr 2017 15:56:24 -0700 Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] HTTPSTB: apply Mike Jones' feedback (#96) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 22:51:50 -0000 ----==_mimepart_58f6987be4f78_2ebf3f8527f6bc38629c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit equalsJeffH commented on this pull request. > any redirect URL issued by the Token Consumer (as well as with any Javascript running in the origin of the Token Consumer). The goal of - the man-in-the-middle is to trick the Token Provider to issue a token - bound to its Token Binding ID, not to + the man-in-the-middle is to trick the Token Provider to issuing a token done, thx. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/TokenBinding/Internet-Drafts/pull/96#discussion_r112082945 ----==_mimepart_58f6987be4f78_2ebf3f8527f6bc38629c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@equalsJeffH commented on this pull request.

In draft-ietf-tokbind-https-09.xml:

>            any redirect URL issued by the Token Consumer (as well as with any
           Javascript running in the origin of the Token Consumer). The goal of
-          the man-in-the-middle is to trick the Token Provider to issue a token
-          bound to <spanx style="emph">its</spanx> Token Binding ID, not to
+          the man-in-the-middle is to trick the Token Provider to issuing a token

done, thx.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_58f6987be4f78_2ebf3f8527f6bc38629c-- From nobody Tue Apr 18 15:56:42 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687C11314D8 for ; Tue, 18 Apr 2017 15:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.182 X-Spam-Level: X-Spam-Status: No, score=-8.182 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id besUMJ0ev4sq for ; Tue, 18 Apr 2017 15:52:58 -0700 (PDT) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext6.iad.github.net [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019661314DC for ; Tue, 18 Apr 2017 15:52:58 -0700 (PDT) Date: Tue, 18 Apr 2017 15:52:57 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1492555977; bh=kekNCREiWqdhrqv6t3zRF6OxD+fMHka2sfeFRJV3cww=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=NtgW7LlVKHLBdmzAjk/5nSpxQ22BI+W1eI9Hevr4ygLr9k4bij75dPBz1CPQ9mjCq YLUiRj6kljq6S6OsGt2I5UXuIrNNshSaoNUugkEUwxrYA0t6kKpuMAnJFqEqMECnbw hX3Oi5n3vfXhoyvLSHykSeE45+8giZn8mbhGdEXQ= From: =JeffH Reply-To: TokenBinding/Internet-Drafts To: TokenBinding/Internet-Drafts Cc: Push Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58f698c91c514_5283f8527f6bc382416f"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: equalsJeffH X-GitHub-Recipient: unbearable-ML X-GitHub-Reason: push X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org Archived-At: X-Mailman-Approved-At: Tue, 18 Apr 2017 15:56:24 -0700 Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] HTTPSTB: apply Mike Jones' feedback (#96) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 22:52:59 -0000 ----==_mimepart_58f698c91c514_5283f8527f6bc382416f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @equalsJeffH pushed 1 commit. 6f2c838 incorp @Andrei-Popov's comments - thx! -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/TokenBinding/Internet-Drafts/pull/96/files/7a8aea7cca2499e45c66be3c25e06aabd75dceb9..6f2c8386164172778e7de174d5b6dc0abfd40c1f ----==_mimepart_58f698c91c514_5283f8527f6bc382416f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@equalsJeffH pushed 1 commit.

  • 6f2c838 incorp @Andrei-Popov's comments - thx!

—
You are receiving this because you are subscribed to this thread.
View it on GitHub or mute the thread.

----==_mimepart_58f698c91c514_5283f8527f6bc382416f-- From nobody Tue Apr 18 15:56:46 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B1C1314E4 for ; Tue, 18 Apr 2017 15:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.475 X-Spam-Level: X-Spam-Status: No, score=-0.475 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TG1pa8MRGysb for ; Tue, 18 Apr 2017 15:53:50 -0700 (PDT) Received: from o10.sgmail.github.com (o10.sgmail.github.com [167.89.101.201]) (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 B2AB11314BA for ; Tue, 18 Apr 2017 15:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=rVn7xZjMJTkUlNICycUSLGy7lT4=; b=iTFqsBqgTVXYJ2p2 Na48HhqErfIr/hGdGwkWrRmNLGgazPxzDqggocZLTEB5rWr4ntjYjOviQxqgxcd2 AQHrBtqf89O6Sb5GkwHrqBoxnwFdp7w7/sytyT0N3XTXvVCwd8FMPmHhUO87Np6K TPDwYRzezqcYh2k2oR2PiFsfgdI= Received: by filter1100p1mdw1.sendgrid.net with SMTP id filter1100p1mdw1-9910-58F698FE-5 2017-04-18 22:53:50.063480643 +0000 UTC Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2a-ext-cp1-prd.iad.github.net [192.30.253.16]) by ismtpd0005p1iad1.sendgrid.net (SG) with ESMTP id A97C1XF2Shy0DtMAz9cgqQ for ; Tue, 18 Apr 2017 22:53:49.987 +0000 (UTC) Date: Tue, 18 Apr 2017 15:53:49 -0700 From: =JeffH Reply-To: TokenBinding/Internet-Drafts To: TokenBinding/Internet-Drafts Cc: Subscribed Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_58f698fdddd46_29f83fa74f4f9c381919c"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: equalsJeffH X-GitHub-Recipient: unbearable-ML X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org X-SG-EID: 9Yqp9dCIIwZxB0MVAPExrXlt7a4/46ALD9aG/N3UOYpIM5u0ElH5u1dmfvEATh9wkgRGb41gj5m1Vn rPWWDqlSi/FeFpl88JhDlxyVKTHTgc0LJLlc3yXoYh/ESq37jkKbwkK+DqAIGLXVll2Zp2rpDSH9hL mibSfyMbF4yEx2eL+YG9p8QTMqB+9F6P2dCngEaKRWg82rw5upRYg+15LA== Archived-At: X-Mailman-Approved-At: Tue, 18 Apr 2017 15:56:24 -0700 Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] HTTPSTB: apply Mike Jones' feedback (#96) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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, 18 Apr 2017 22:53:52 -0000 ----==_mimepart_58f698fdddd46_29f83fa74f4f9c381919c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @Andrei-Popov's comments incorp'd -- thx! -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/TokenBinding/Internet-Drafts/pull/96#issuecomment-295008224 ----==_mimepart_58f698fdddd46_29f83fa74f4f9c381919c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@Andrei-Popov's comments incorp'd -- thx!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_58f698fdddd46_29f83fa74f4f9c381919c-- From nobody Wed Apr 19 19:08:56 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6065E12778E for ; Wed, 19 Apr 2017 19:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fn1ZD0-ycti1 for ; Wed, 19 Apr 2017 19:08:52 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B339124D68 for ; Wed, 19 Apr 2017 19:08:52 -0700 (PDT) X-AuditID: 12074422-e03ff70000000cd4-54-58f81833b11d Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 50.50.03284.33818F85; Wed, 19 Apr 2017 22:08:51 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v3K28ocq026077; Wed, 19 Apr 2017 22:08:50 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v3K28kcf019049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Apr 2017 22:08:49 -0400 Date: Wed, 19 Apr 2017 21:08:46 -0500 From: Benjamin Kaduk To: Nick Harper Cc: IETF Tokbind WG Message-ID: <20170420020846.GY30306@kduck.kaduk.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBIsWRmVeSWpSXmKPExsUixG6nomss8SPC4MJWZYv+HfsYLc49Xsjk wOSxYFOpx5IlP5kCmKK4bFJSczLLUov07RK4MhZf3sNecFawYtqUN+wNjDP5uhg5OSQETCR6 TlxmA7GFBNqYJHoaBboYuYDsjYwSS67MZIZwrjJJrFv9mBGkikVAVeLsgUesIDabgIpEQ/dl ZhBbBMief/U6WJxZQFPiYsdvdhBbWMBV4tHls0C9HBy8QNta2+QglgVI/Nv6DqyVV0BQ4uTM JywQrVoSN/69ZAIpZxaQllj+jwMkzCkQKHH42WOwO0UFlCUaZjxgnsAoMAtJ9ywk3bMQuhcw Mq9ilE3JrdLNTczMKU5N1i1OTszLSy3SNdXLzSzRS00p3cQIDlAXpR2ME/95HWIU4GBU4uGN SPseIcSaWFZcmXuIUZKDSUmU1/UjUIgvKT+lMiOxOCO+qDQntfgQowQHs5II7zzRHxFCvCmJ lVWpRfkwKWkOFiVxXnGNxgghgfTEktTs1NSC1CKYrAwHh5IEr6k4UKNgUWp6akVaZk4JQpqJ gxNkOA/Q8CdiIMOLCxJzizPTIfKnGBWlxHk/gWwVAElklObB9YISiET2/ppXjOJArwjzLgdp 5wEmH7juV0CDmYAGRwR8ARlckoiQkmpgnOvSZHsqwOeOCP92GynuY4c3ef5ZwRB7/jRT6sdA gYuXA7pvvGITjano9Lx++wn73H9vJiyNUkyK3fT/rsHep4UrDHuUl18qXJXXlKmY/sz8aGHV Fx39xaxehzstFwrO0xRZubBtRmlI/90tdfOPu3xvrl/wLWmaZ9aqsGr7VVsupPwUWHHuuxJL cUaioRZzUXEiAFUGa8n7AgAA Archived-At: Subject: Re: [Unbearable] Switching exporters for 0-RTT Token Binding X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 20 Apr 2017 02:08:54 -0000 On Tue, Apr 18, 2017 at 03:24:40PM -0700, Nick Harper wrote: > One of the issues raised in Chicago around 0-RTT Token Binding is > whether or not to switch from the 0-RTT exporter to the normal > exporter, and I'd like to get some feedback from the Working Group on > this. > > The two options I'm considering are as follows: > 1) Always use the 0-RTT exporter on connections where 0-RTT data is accepted. > 2) Use the 0-RTT exporter for Token Binding messages sent in 0-RTT. > The client switches to using the normal exporter soon after the > handshake finishes, but it may send some Token Binding messages > post-handshake using the 0-RTT exporter. > In both cases, if the server rejects 0-RTT data, the client uses the > normal exporter (i.e. the client behaves the same as in TBPROTO). To make the obligatory statement of hopefully obvious facts, 0-RTT data MUST NOT be used absent a profile that defines its use. Presumably the situation of most interest here is HTTP right now, and many people would presume that the HTTP profile for early data will say "just concatenate the two streams", but those are just presumptions. Perhaps some other profile would be appropriate for non-HTTP cases, though with no concrete proposal it hardly seems worth time to think about other than to note that whatever decision may be reached here might be limited to HTTP in its applicability. If one presupposes that the profile for the use of 0-RTT is "concatenate the streams", then the arguments against (1) are weakened (though not entirely removed). But I'm not sure what level of consensus there is for such a (pre)supposition. Having not fully thought through the matter, I still lean towards (2), with the justification that token binding can be thought of as an attempt to prove live possession of a key [associated to a token] on a connection where that token is used. The 0-RTT exporter does not have a server contribution, so it's hard to really prove liveness of possession using just it. I acknowledge that there is engineering work remainng to be done in making (2) practical/usable, and am not really in a position to contribute much to that work, but that's my current thinking on the matter. -Ben From nobody Fri Apr 21 15:29:18 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEC61243FE for ; Fri, 21 Apr 2017 15:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com; domainkeys=pass (1024-bit key) header.sender=andreipo=microsoft.com@github.com header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3gBJpmlisEW for ; Fri, 21 Apr 2017 15:29:14 -0700 (PDT) Received: from m69-170.mailgun.net (m69-170.mailgun.net [166.78.69.170]) (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 AB77D128A32 for ; Fri, 21 Apr 2017 15:29:14 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1492813753; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=NPv0T3Ss8F6qnlTJh/IGlukYoegc3DVin1tuoaW4vR4=; b=o56tR9jTi7eOaP2EnRNPrpGhwrhTG//hz17slmiPoAiUBijcItcBhlz8+D8qqt5wWlh5+UpB ND3kP87LNeM0gNylAJ9IovP81RiJERl64YmQIyGGK099t0a44DHCdtLHUyL2sMTv/SKCrAYR wWBYAv5jLTI3gz3T3tZoOg62QPU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=github.com; s=mailo; q=dns; h=Sender: Date: From: Reply-To: To: Message-ID: Subject: Mime-Version: Content-Type: Content-Transfer-Encoding; b=CXYkiM0nSOc7tXobKCeX4T0OyGsGMJvBLSyexaXQz04JsvGrfy6w4jX0aWun0A4S90ppYF Ul3XBwfH6HGRUWmSOWPo0ofUQGkhEeO0s8ibB+R966pptot3SnNmQvP4yD6cTmh+M56d8GXV PnAiy9/N5+8EVsliITQIOgWrdxKnw= Sender: andreipo=microsoft.com@github.com X-Mailgun-Sending-Ip: 166.78.69.170 X-Mailgun-Sid: WyIzMTNlNyIsICJ1bmJlYXJhYmxlQGlldGYub3JnIiwgIjQwZiJd Received: from github.com (Unknown [192.30.252.34]) by mxa.mailgun.org with ESMTP id 58fa87b9.7f33473a62a0-smtp-out-n02; Fri, 21 Apr 2017 22:29:13 -0000 (UTC) Date: Fri, 21 Apr 2017 15:29:12 -0700 From: Andrei Popov Reply-To: Andrei Popov To: unbearable@ietf.org Message-ID: <58fa87b89373b_174d3ff548e3fc38191a0@hookshot-fe2-cp1-prd.iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_58fa87b893102_174d3ff548e3fc38190cd"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Unbearable] [TokenBinding/Internet-Drafts] beb03b: HTTPSTB: initialize -09 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 21 Apr 2017 22:29:16 -0000 ----==_mimepart_58fa87b893102_174d3ff548e3fc38190cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/TokenBinding/Internet-Drafts Commit: beb03b2de2e5436ba2803c875e12222a73b2fc05 https://github.com/TokenBinding/Internet-Drafts/commit/beb03b2de2e5436ba2803c875e12222a73b2fc05 Author: JeffH Date: 2017-03-27 (Mon, 27 Mar 2017) Changed paths: R draft-ietf-tokbind-https-08.xml A draft-ietf-tokbind-https-09.xml Log Message: ----------- HTTPSTB: initialize -09 Commit: 7a8aea7cca2499e45c66be3c25e06aabd75dceb9 https://github.com/TokenBinding/Internet-Drafts/commit/7a8aea7cca2499e45c66be3c25e06aabd75dceb9 Author: JeffH Date: 2017-03-27 (Mon, 27 Mar 2017) Changed paths: M draft-ietf-tokbind-https-09.xml Log Message: ----------- apply Mike Jones' feedback Commit: 6f2c8386164172778e7de174d5b6dc0abfd40c1f https://github.com/TokenBinding/Internet-Drafts/commit/6f2c8386164172778e7de174d5b6dc0abfd40c1f Author: JeffH Date: 2017-04-18 (Tue, 18 Apr 2017) Changed paths: M draft-ietf-tokbind-https-09.xml Log Message: ----------- incorp @Andrei-Popov's comments - thx! Commit: 399ef0ca02dff2a65aa12c2092add5e6e16b2086 https://github.com/TokenBinding/Internet-Drafts/commit/399ef0ca02dff2a65aa12c2092add5e6e16b2086 Author: Andrei Popov Date: 2017-04-21 (Fri, 21 Apr 2017) Changed paths: R draft-ietf-tokbind-https-08.xml A draft-ietf-tokbind-https-09.xml Log Message: ----------- Merge branch 'HTTPSTB-cleanup3' of https://github.com/equalsJeffH/Internet-Drafts into equalsJeffH-HTTPSTB-cleanup3 Commit: 368c4b84fbd124a241c8efc4430d27df3806a33f https://github.com/TokenBinding/Internet-Drafts/commit/368c4b84fbd124a241c8efc4430d27df3806a33f Author: Andrei Popov Date: 2017-04-21 (Fri, 21 Apr 2017) Changed paths: R draft-ietf-tokbind-https-08.xml A draft-ietf-tokbind-https-09.xml Log Message: ----------- Merge branch 'equalsJeffH-HTTPSTB-cleanup3' Commit: edc9d929024c0e1116453dbc16c4e9405d425f6c https://github.com/TokenBinding/Internet-Drafts/commit/edc9d929024c0e1116453dbc16c4e9405d425f6c Author: Andrei Popov Date: 2017-04-21 (Fri, 21 Apr 2017) Changed paths: M README.md M draft-ietf-tokbind-https-09.xml Log Message: ----------- Merging PR #96. Commit: c65453ef3ca0b774c4d493ff0d4134c14a4b59ca https://github.com/TokenBinding/Internet-Drafts/commit/c65453ef3ca0b774c4d493ff0d4134c14a4b59ca Author: Andrei Popov Date: 2017-04-21 (Fri, 21 Apr 2017) Changed paths: M draft-ietf-tokbind-https-09.xml Log Message: ----------- Merging PR #96: editorial changes. Compare: https://github.com/TokenBinding/Internet-Drafts/compare/b14d902a2691...c65453ef3ca0 ----==_mimepart_58fa87b893102_174d3ff548e3fc38190cd-- From nobody Fri Apr 21 15:44:22 2017 Return-Path: X-Original-To: unbearable@ietf.org Delivered-To: unbearable@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA6C129407; Fri, 21 Apr 2017 15:44:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: unbearable@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149281466154.25877.4209139186107905761@ietfa.amsl.com> Date: Fri, 21 Apr 2017 15:44:21 -0700 Archived-At: Subject: [Unbearable] I-D Action: draft-ietf-tokbind-protocol-14.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 21 Apr 2017 22:44:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Token Binding of the IETF. Title : The Token Binding Protocol Version 1.0 Authors : Andrei Popov Magnus Nyström Dirk Balfanz Adam Langley Jeff Hodges Filename : draft-ietf-tokbind-protocol-14.txt Pages : 17 Date : 2017-04-21 Abstract: This document specifies Version 1.0 of the Token Binding protocol. The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS [RFC5246] bindings spanning multiple TLS sessions and connections. Applications are then enabled to cryptographically bind security tokens to the TLS layer, preventing token export and replay attacks. To protect privacy, the Token Binding identifiers are only conveyed over TLS and can be reset by the user at any time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tokbind-protocol-14 https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-protocol-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-protocol-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 21 15:46:46 2017 Return-Path: X-Original-To: unbearable@ietf.org Delivered-To: unbearable@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F6A129B15; Fri, 21 Apr 2017 15:46:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: unbearable@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149281479962.25803.14714191067325793200@ietfa.amsl.com> Date: Fri, 21 Apr 2017 15:46:39 -0700 Archived-At: Subject: [Unbearable] I-D Action: draft-ietf-tokbind-negotiation-08.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 21 Apr 2017 22:46:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Token Binding of the IETF. Title : Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation Authors : Andrei Popov Magnus Nyström Dirk Balfanz Adam Langley Filename : draft-ietf-tokbind-negotiation-08.txt Pages : 8 Date : 2017-04-21 Abstract: This document specifies a Transport Layer Security (TLS) [RFC5246] extension for the negotiation of Token Binding protocol [I-D.ietf-tokbind-protocol] version and key parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-negotiation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-08 https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-negotiation-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-negotiation-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 21 15:48:38 2017 Return-Path: X-Original-To: unbearable@ietf.org Delivered-To: unbearable@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1CE120726; Fri, 21 Apr 2017 15:48:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: unbearable@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149281491114.25897.10506872069086396509@ietfa.amsl.com> Date: Fri, 21 Apr 2017 15:48:31 -0700 Archived-At: Subject: [Unbearable] I-D Action: draft-ietf-tokbind-https-09.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 21 Apr 2017 22:48:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Token Binding of the IETF. Title : Token Binding over HTTP Authors : Andrei Popov Magnus Nyström Dirk Balfanz Adam Langley Jeff Hodges Filename : draft-ietf-tokbind-https-09.txt Pages : 22 Date : 2017-04-21 Abstract: This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind security tokens (such as cookies and OAuth tokens) to TLS connections. We describe both first-party and federated scenarios. In a first- party scenario, an HTTP server is able to cryptographically bind the security tokens it issues to a client, and which the client subsequently returns to the server, to the TLS connection between the client and server. Such bound security tokens are protected from misuse since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections. Federated token bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS connection that the client has with a different server than the one issuing the token. This Internet-Draft is a companion document to The Token Binding Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tokbind-https-09 https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-https-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-https-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 21 16:07:13 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396F6128896 for ; Fri, 21 Apr 2017 16:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEpprqe--Q87 for ; Fri, 21 Apr 2017 16:07:10 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0126.outbound.protection.outlook.com [104.47.34.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 98C681242F5 for ; Fri, 21 Apr 2017 16:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+ys1hAufi5uyIAQWhCD+YcTkXrpP7OjXipJhNAn+GAI=; b=TQ8GHOskdNsULc0jWpjwoqZ0W36HlfzvIt5CUfegle+tnc661xPuln6RhOth1tEuAOkKbLkViBVF4/kgJMIL9uYFiFggBP/ahgGP90kRQQVSTtrh+5lgmmxvYXiZ3Mty0d3p+ohSueiZ73J3ZmK0LCvzs5ij8gkGWu/9b743gpM= Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0090.namprd21.prod.outlook.com (10.161.141.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.4; Fri, 21 Apr 2017 23:07:10 +0000 Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) by DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) with mapi id 15.01.1061.008; Fri, 21 Apr 2017 23:07:09 +0000 From: Andrei Popov To: "unbearable@ietf.org" Thread-Topic: Updated I-Ds Thread-Index: AdK68woLTVu6btkjRkK/gDFcN2E3LQ== Date: Fri, 21 Apr 2017 23:07:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:4::4ca] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR21MB0090; 7:T1nqIfi+6aQBeHZwc3+x/y/fZqY+rS21y3cf2g1Pgdmm6yY6p5tSkaZux2zMXKO5VMXV6bZulIkKPu50pUJ3MtAT2EwJM9xL0AFVlElB6VCkLUEtALRXldiuTh2+bUS1cv7xShdMFauSjD7HiePh5vWhCjzxiy/Rcw2q5I3xeG075jYgeI9liP1HhEcz799+Zih6ahOdUYlPdjQbJORiEFgeBx+wHrWgNIb9DbT/IRcmiHH1eBZtJdrRcT+E02fPe2ZudmIPM73a+L1NGlH8hkbV1EzL/ZpcJRUq8W2vEhy41qSOXGQUPCabqSzgAkrdI1PEEjYFsttom1d9Q4i0IQSb0fbBBcS8Lo7J3/Ad4w4= x-ms-office365-filtering-correlation-id: cbbad1cc-2a40-4283-3827-08d4890b236a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:DM2PR21MB0090; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406113)(20161123558060)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:DM2PR21MB0090; BCL:0; PCL:0; RULEID:; SRVR:DM2PR21MB0090; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39450400003)(39400400002)(39410400002)(39860400002)(39840400002)(55016002)(8676002)(8990500004)(189998001)(5640700003)(6306002)(38730400002)(54896002)(99286003)(7696004)(2900100001)(122556002)(77096006)(6436002)(606005)(5660300001)(33656002)(9686003)(236005)(25786009)(10090500001)(5005710100001)(10290500002)(54356999)(50986999)(6916009)(2501003)(81166006)(8936002)(790700001)(5630700001)(1730700003)(2420400007)(3280700002)(15650500001)(2906002)(102836003)(6116002)(3660700001)(10710500007)(7736002)(86362001)(7906003)(6506006)(74316002)(86612001)(2351001)(7110500001)(53936002)(110136004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0090; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR21MB00919337C1C1BF049E12706A8C1A0DM2PR21MB0091namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2017 23:07:09.5704 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0090 Archived-At: Subject: [Unbearable] Updated I-Ds X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 21 Apr 2017 23:07:12 -0000 --_000_DM2PR21MB00919337C1C1BF049E12706A8C1A0DM2PR21MB0091namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The updated versions of TBPROTO, TBNEGO and HTTPSTB have been uploaded: https://tools.ietf.org/html/draft-ietf-tokbind-protocol-14 https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-08 https://tools.ietf.org/html/draft-ietf-tokbind-https-09 The updated documents address the comments from WGLC #2 (including the disc= ussion at the IETF 98 meeting). On GitHub, we have 0 issues and 0 PRs at the time of this writing. Please review the updated I-Ds, Thanks, Andrei --_000_DM2PR21MB00919337C1C1BF049E12706A8C1A0DM2PR21MB0091namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The updated versions of TBPROTO, TBNEGO and HTTPSTB = have been uploaded:

https://tools.ietf.org/html/draft-ietf-tokbind-protocol-= 14

https://tools.ietf.org/html/draft-ietf-tokbind-negoti= ation-08

https://tools.ietf.org/html/draft-ietf-tokbind-https-09=

 

The updated documents address the comments from WGLC= #2 (including the discussion at the IETF 98 meeting).

On GitHub, we have 0 issues and 0 PRs at the time of= this writing.

 

Please review the updated I-Ds,

 

Thanks,

 

Andrei

 

--_000_DM2PR21MB00919337C1C1BF049E12706A8C1A0DM2PR21MB0091namp_-- From nobody Thu Apr 27 14:48:44 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9323A129412 for ; Thu, 27 Apr 2017 14:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYSRi3FqYj0M for ; Thu, 27 Apr 2017 14:48:41 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6397C129BEF for ; Thu, 27 Apr 2017 14:45:16 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id 75so24597195lfs.2 for ; Thu, 27 Apr 2017 14:45:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p9lxKzi+5z8Z13Ik6ZH73a/mcRMdBelBqsI9taAMLCI=; b=IaPwpEIgi+AraiwRFSAiNWzOnV+Iihkbl2iJcOZ7SW3HcH4FwPlUANj1zsbgXc/GxJ +8uhQlqGEQ/F2ywBAz2GxqA9j0JEJzOL5AmHMQGdYO9FXcbSyUy1rPf8XF9mBDkS3hIQ Lc4tDkXaNNPVFmezRGNsnC/dcdbHho3BLG65KAPlmxDACYUqE7+Kv0xsHGkK537xpFqm 5/aw/MackkNhwy3hmkO5SzLw2C7s04qmpn4mQ9PFfUcydM9i6vBnGLfWpOKa8kX8Kk/0 3DswRoPPPgReFgITkfH07j/uke0A+C9vkt5wTuTU9ueHluoTsvzeipUaw425HIyN59fk +muA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=p9lxKzi+5z8Z13Ik6ZH73a/mcRMdBelBqsI9taAMLCI=; b=pPcf0bOiMHPDqxz6GvOEMKJttO6JTzsOVwKiVb0VEHGz/uGG4QGPCSH3QikEMBpCfw hRCUMQzjGESnOTpIcirwRbaa/CW9NTcmJQ08J9RnuCLuVXUgnnG2XRh6k84sToqL3gwo ZTecbld1OJ9QJd/y4XxcQ7DJxguA1Q41U2Y5zEAgdT160Uc+6bRKueSTwU+mLMwf528s btAqlIjCd8wooVJJrIqwTd90AcvjmG+VRbJ7ypPhMaXdBh4nNelAbzAII8IjRVKC9tTW CdKF71xorA2H6sHGFG0wOLQtYT0J+Y0dLvhVrcPj0ikiFqf0wlXI3LsUCdWG/iUDJOey OECQ== X-Gm-Message-State: AN3rC/558CS/Cr1Vq0Ik5xeDD+ucqZTPLhv7tgZP8y3+gp4s0wo9tNLi XelT8b29lNx78dAT62zGiXMvzfi+CrL9 X-Received: by 10.46.76.10 with SMTP id z10mr3013964lja.8.1493329514455; Thu, 27 Apr 2017 14:45:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.150.149 with HTTP; Thu, 27 Apr 2017 14:44:53 -0700 (PDT) In-Reply-To: <20170420020846.GY30306@kduck.kaduk.org> References: <20170420020846.GY30306@kduck.kaduk.org> From: Nick Harper Date: Thu, 27 Apr 2017 14:44:53 -0700 Message-ID: To: Benjamin Kaduk Cc: IETF Tokbind WG Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Unbearable] Switching exporters for 0-RTT Token Binding X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 27 Apr 2017 21:48:44 -0000 On Wed, Apr 19, 2017 at 7:08 PM, Benjamin Kaduk wrote: > On Tue, Apr 18, 2017 at 03:24:40PM -0700, Nick Harper wrote: >> One of the issues raised in Chicago around 0-RTT Token Binding is >> whether or not to switch from the 0-RTT exporter to the normal >> exporter, and I'd like to get some feedback from the Working Group on >> this. >> >> The two options I'm considering are as follows: >> 1) Always use the 0-RTT exporter on connections where 0-RTT data is accepted. >> 2) Use the 0-RTT exporter for Token Binding messages sent in 0-RTT. >> The client switches to using the normal exporter soon after the >> handshake finishes, but it may send some Token Binding messages >> post-handshake using the 0-RTT exporter. >> In both cases, if the server rejects 0-RTT data, the client uses the >> normal exporter (i.e. the client behaves the same as in TBPROTO). > > To make the obligatory statement of hopefully obvious facts, 0-RTT > data MUST NOT be used absent a profile that defines its use. > Presumably the situation of most interest here is HTTP right now, > and many people would presume that the HTTP profile for early data > will say "just concatenate the two streams", but those are just > presumptions. Perhaps some other profile would be appropriate for > non-HTTP cases, though with no concrete proposal it hardly seems > worth time to think about other than to note that whatever decision > may be reached here might be limited to HTTP in its applicability. > > If one presupposes that the profile for the use of 0-RTT is > "concatenate the streams", then the arguments against (1) are > weakened (though not entirely removed). But I'm not sure what level > of consensus there is for such a (pre)supposition. I have definitely been assuming an application profile of HTTP that concatenates the streams, and the use-case in mind for 0-RTT Token Binding is with HTTP. > > Having not fully thought through the matter, I still lean towards > (2), with the justification that token binding can be thought of as > an attempt to prove live possession of a key [associated to a token] > on a connection where that token is used. The 0-RTT exporter does > not have a server contribution, so it's hard to really prove > liveness of possession using just it. I acknowledge that there is > engineering work remainng to be done in making (2) practical/usable, > and am not really in a position to contribute much to that work, but > that's my current thinking on the matter. > > -Ben I have similar reservations for (1) in that it doesn't really prove liveness of possession, but (2) only has this liveness of possession at some points in the protocol (i.e. after it has switched exporters). If a server is doing 0-RTT Token Binding, then it doesn't need the stronger exporter for all requests - the weaker exporter is fine for some. I don't see a reason to upgrade partway through to the stronger exporter just because it is stronger. However, if there are use cases for accepting the weaker exporter at the beginning of a connection but then requiring the stronger exporter later in the connection, then (2) sounds like a good idea. (Preferring the stronger exporter isn't enough for this use case - it would need to require it, and absent option (2) the implementer of this use case would put the requests needing the stronger exporter on a separate, non-0-RTT, connection.) For those considering implementing 0-RTT Token Binding, do you have any such use cases in mind or is option (1) good? From nobody Thu Apr 27 15:48:53 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E21129457 for ; Thu, 27 Apr 2017 15:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lc9QoWMEhvWl for ; Thu, 27 Apr 2017 15:48:49 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0091.outbound.protection.outlook.com [104.47.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0663412943C for ; Thu, 27 Apr 2017 15:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Hr66F7SAf5B7ww+C2DXvy0vijljWrLGccGNTx82XzpM=; b=k8FQzDh5+ZteGOqsKdc1wqU1yHGi5zaBxy0SaqOLJ5Pjw15+JGiAtanv1xUR/vI2LDO6yLTPXJG3m1c+YT9FqdDNx6xDconarrbSzRRDaleQz6iwVhjRqvkv5o6jrpnn17tqNtvjMVcRaCbATX5nUPG/0A5q60v+8Vj236eID1k= Received: from SN1PR21MB0096.namprd21.prod.outlook.com (10.161.254.16) by SN1PR21MB0095.namprd21.prod.outlook.com (10.161.254.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.0; Thu, 27 Apr 2017 22:46:19 +0000 Received: from SN1PR21MB0096.namprd21.prod.outlook.com ([10.161.254.16]) by SN1PR21MB0096.namprd21.prod.outlook.com ([10.161.254.16]) with mapi id 15.01.1075.000; Thu, 27 Apr 2017 22:46:19 +0000 From: Andrei Popov To: Nick Harper , Benjamin Kaduk CC: IETF Tokbind WG Thread-Topic: [Unbearable] Switching exporters for 0-RTT Token Binding Thread-Index: AQHSuJKlo0yoEMvGZUCTm+Pgzz+4KKHNhPAAgAxI7ICAAAxqsA== Date: Thu, 27 Apr 2017 22:46:18 +0000 Message-ID: References: <20170420020846.GY30306@kduck.kaduk.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:6::4ca] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1PR21MB0095; 7:+MMM9qO80CC0tLBUenvFmg/bekv+j5bg7UKJTGVtViXBrw2AowVkhL4H1x58MJo0Toq3ufY01/Aq8mWwI2CF9Ix8YSlonPw9UtFtgfFpYSxFZzuCX3qGsmT2XC5KRajal5Jl+gmbNfMUSUjg7pDDo+HfRYHDB8G6pKznZtEmGbbf6y/0A7f37btL9P36APpsh82ER8u7FxNiWzapPNkckp+80RfyI1kkHDfUs7WzdGSp5MNHstmqPX0zr7cXbTkelVYmeOAtc671ghbfj0IxCCmr4I9B2pNmhg/nBd8/tx3kWL7GHqSNKzJBT/8MLuRyqBXgvbdU13ULPlKPBxirFEuTSNU0qdR7JhB+wtHPVT4= x-ms-office365-filtering-correlation-id: c4a53800-8d6e-4c64-997f-08d48dbf3881 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:SN1PR21MB0095; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(189930954265078)(100405760836317)(219752817060721); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123558100)(6072148); SRVR:SN1PR21MB0095; BCL:0; PCL:0; RULEID:; SRVR:SN1PR21MB0095; x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39400400002)(39860400002)(39840400002)(39410400002)(39850400002)(377454003)(13464003)(24454002)(10090500001)(76176999)(54356999)(2171002)(122556002)(50986999)(6246003)(4326008)(53936002)(189998001)(99286003)(6306002)(55016002)(7736002)(9686003)(305945005)(53546009)(25786009)(38730400002)(81166006)(2900100001)(8990500004)(8936002)(8676002)(561944003)(5005710100001)(102836003)(6116002)(3280700002)(2950100002)(3660700001)(74316002)(7696004)(33656002)(10290500003)(2906002)(86362001)(77096006)(86612001)(6506006)(5660300001)(6436002)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR21MB0095; H:SN1PR21MB0096.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 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: 27 Apr 2017 22:46:19.0338 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR21MB0095 Archived-At: Subject: Re: [Unbearable] Switching exporters for 0-RTT Token Binding X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 27 Apr 2017 22:48:51 -0000 If one is willing to do TB without POP, then one will probably appreciate a= simpler way to do this, with fewer moving parts and less room for interop = issues. (IMHO, the value of TB without POP approaches zero, but that's a se= parate discussion.) The extra complexity of upgrading to secure TB after a bound token and asso= ciated application message(s) have been accepted and processed does not inc= rease security in the common use-cases that I can think of. Cheers, Andrei -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Nick Har= per Sent: Thursday, April 27, 2017 2:45 PM To: Benjamin Kaduk Cc: IETF Tokbind WG Subject: Re: [Unbearable] Switching exporters for 0-RTT Token Binding On Wed, Apr 19, 2017 at 7:08 PM, Benjamin Kaduk wrote: > On Tue, Apr 18, 2017 at 03:24:40PM -0700, Nick Harper wrote: >> One of the issues raised in Chicago around 0-RTT Token Binding is=20 >> whether or not to switch from the 0-RTT exporter to the normal=20 >> exporter, and I'd like to get some feedback from the Working Group on=20 >> this. >> >> The two options I'm considering are as follows: >> 1) Always use the 0-RTT exporter on connections where 0-RTT data is acce= pted. >> 2) Use the 0-RTT exporter for Token Binding messages sent in 0-RTT. >> The client switches to using the normal exporter soon after the=20 >> handshake finishes, but it may send some Token Binding messages=20 >> post-handshake using the 0-RTT exporter. >> In both cases, if the server rejects 0-RTT data, the client uses the=20 >> normal exporter (i.e. the client behaves the same as in TBPROTO). > > To make the obligatory statement of hopefully obvious facts, 0-RTT=20 > data MUST NOT be used absent a profile that defines its use. > Presumably the situation of most interest here is HTTP right now, and=20 > many people would presume that the HTTP profile for early data will=20 > say "just concatenate the two streams", but those are just=20 > presumptions. Perhaps some other profile would be appropriate for=20 > non-HTTP cases, though with no concrete proposal it hardly seems worth=20 > time to think about other than to note that whatever decision may be=20 > reached here might be limited to HTTP in its applicability. > > If one presupposes that the profile for the use of 0-RTT is=20 > "concatenate the streams", then the arguments against (1) are weakened=20 > (though not entirely removed). But I'm not sure what level of=20 > consensus there is for such a (pre)supposition. I have definitely been assuming an application profile of HTTP that concate= nates the streams, and the use-case in mind for 0-RTT Token Binding is with= HTTP. > > Having not fully thought through the matter, I still lean towards (2),=20 > with the justification that token binding can be thought of as an=20 > attempt to prove live possession of a key [associated to a token] on a=20 > connection where that token is used. The 0-RTT exporter does not have=20 > a server contribution, so it's hard to really prove liveness of=20 > possession using just it. I acknowledge that there is engineering=20 > work remainng to be done in making (2) practical/usable, and am not=20 > really in a position to contribute much to that work, but that's my=20 > current thinking on the matter. > > -Ben I have similar reservations for (1) in that it doesn't really prove livenes= s of possession, but (2) only has this liveness of possession at some point= s in the protocol (i.e. after it has switched exporters). If a server is doing 0-RTT Token Binding, then it doesn't need the stronger= exporter for all requests - the weaker exporter is fine for some. I don't = see a reason to upgrade partway through to the stronger exporter just becau= se it is stronger. However, if there are use cases for accepting the weaker= exporter at the beginning of a connection but then requiring the stronger = exporter later in the connection, then (2) sounds like a good idea. (Prefer= ring the stronger exporter isn't enough for this use case - it would need t= o require it, and absent option (2) the implementer of this use case would = put the requests needing the stronger exporter on a separate, non-0-RTT, co= nnection.) For those considering implementing 0-RTT Token Binding, do you have any suc= h use cases in mind or is option (1) good? _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Funbearable&data=3D02%7C01%7CAndrei.Popov%40micr= osoft.com%7Cc470223592b2491dd71c08d48db72ee5%7C72f988bf86f141af91ab2d7cd011= db47%7C1%7C0%7C636289265288924355&sdata=3DH98Owo1uWbXf11VGgzmau3XH3aGzYuNA2= 7pOOaJtxBc%3D&reserved=3D0 From nobody Thu Apr 27 19:16:30 2017 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7112D129B84 for ; Thu, 27 Apr 2017 19:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2jejykreeVs for ; Thu, 27 Apr 2017 19:16:27 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCF3F129BF8 for ; Thu, 27 Apr 2017 19:14:03 -0700 (PDT) X-AuditID: 1209190f-af3ff70000004ead-34-5902a568d2d8 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 6C.89.20141.865A2095; Thu, 27 Apr 2017 22:14:01 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v3S2E0OZ019129; Thu, 27 Apr 2017 22:14:00 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v3S2Dum5022972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Apr 2017 22:13:59 -0400 Date: Thu, 27 Apr 2017 21:13:56 -0500 From: Benjamin Kaduk To: Andrei Popov Cc: Nick Harper , IETF Tokbind WG Message-ID: <20170428021355.GY30306@kduck.kaduk.org> References: <20170420020846.GY30306@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKIsWRmVeSWpSXmKPExsUixG6nopu5lCnSYN4BRYsfk2YwW/Tv2Mdo ce7xQiYHZo8Fm0o9liz5yeTRuuMvewBzFJdNSmpOZllqkb5dAlfG9vYWpoJNnBXbXp5nbmA8 yt7FyMkhIWAiMf/QTeYuRi4OIYE2Jol1i/cyQTgbGSUu/loElbnKJDF5632wFhYBVYn/X2cx gdhsAioSDd2XmUFsEQFdiTmz/7GB2MwC3hKfZv1lBLGFBVwlHl0+C2bzAq07fn0vK8TQqUwS N7+/hkoISpyc+YQFollL4sa/l0ALOIBsaYnl/zhAwpwCsRJHr01lBbFFBZQlGmY8YJ7AKDAL SfcsJN2zELoXMDKvYpRNya3SzU3MzClOTdYtTk7My0st0jXRy80s0UtNKd3ECApdTkn+HYxz GrwPMQpwMCrx8EZ8YowUYk0sK67MPcQoycGkJMqbPIEpUogvKT+lMiOxOCO+qDQntfgQowQH s5IIr2QiUI43JbGyKrUoHyYlzcGiJM4rrtEYISSQnliSmp2aWpBaBJOV4eBQkuCtWALUKFiU mp5akZaZU4KQZuLgBBnOAzS8GKSGt7ggMbc4Mx0if4pRUUqcVwokIQCSyCjNg+sFpRaJ7P01 rxjFgV4R5j29GKiKB5iW4LpfAQ1mAhrM4sIAMrgkESEl1cDY97rPnVlD16KQKdyid007r49t QN27hKk2hTn30l+YXajI+PGMl3XDB69X6jnTWBdV7EvofnOFJTzG9/L5X1dz71xky9/lsfzm hwuWE78LpSbWPjbLXqZSOUt063vJ07dKDjz698tCoPB/kNHKi0uLbLvMI78riJytvn/iZs0b 1r5DWg33BQyVWIozEg21mIuKEwG7jU2JCAMAAA== Archived-At: Subject: Re: [Unbearable] Switching exporters for 0-RTT Token Binding X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 28 Apr 2017 02:16:28 -0000 On Thu, Apr 27, 2017 at 10:46:18PM +0000, Andrei Popov wrote: > If one is willing to do TB without POP, then one will probably appreciate a simpler way to do this, with fewer moving parts and less room for interop issues. (IMHO, the value of TB without POP approaches zero, but that's a separate discussion.) > > The extra complexity of upgrading to secure TB after a bound token and associated application message(s) have been accepted and processed does not increase security in the common use-cases that I can think of. One could perhaps concoct a case where the application layer agrees to only send certain mundane stuff over 0-RTT but for some reason still wants TB for it. (That is not intended to be a compelling argument.) But in general, I agree with Andrei (especially with the parenthetical). In particular, all these discussions of how once you've accepted 0-RTT TB it doesn't make sense to try to upgrade to 1-RTT are just serving to cement my feeling that doing 0-RTT TB is a bad idea. So, to answer Nick's question, I have no interest in implementing 0-RTT Token Binding, and thus don't have a use case in mind that would make me only implement (2). :) -Ben