From nobody Wed Aug 2 10:52:44 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 47178129562; Wed, 2 Aug 2017 10:52:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: unbearable@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150169636325.5791.16128248741008174399@ietfa.amsl.com> Date: Wed, 02 Aug 2017 10:52:43 -0700 Archived-At: Subject: [Unbearable] I-D Action: draft-ietf-tokbind-ttrp-01.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: Wed, 02 Aug 2017 17:52:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Token Binding WG of the IETF. Title : HTTPS Token Binding with TLS Terminating Reverse Proxies Author : Brian Campbell Filename : draft-ietf-tokbind-ttrp-01.txt Pages : 10 Date : 2017-08-02 Abstract: This document defines common HTTP header fields that enable a TLS terminating reverse proxy to convey information about the validated Token Binding Message sent by the client to a backend server, which enables that backend server to bind, or verify the binding of, cookies and other security tokens to the client's Token Binding key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-01 https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-ttrp-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-ttrp-01 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 Wed Aug 2 10:59: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 9591C129417 for ; Wed, 2 Aug 2017 10:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=0.001] autolearn=ham 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 xHNw2ann6Y7t for ; Wed, 2 Aug 2017 10:59:49 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 65A4E1201F2 for ; Wed, 2 Aug 2017 10:59:49 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id z129so23925566pfb.3 for ; Wed, 02 Aug 2017 10:59:49 -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=ebAosDZzRsArg5IuDsKAbMifPWwwVSsVnnIX4Huqy0w=; b=oYHTX1QsZFK1YcPwUERSqpjuucvMw6WKc2UYHXDNXEPYkPpcVBvkxh+w0t7gHFLP2/ bCUDPpxq0R5K2TIioR5b2HojojF35h5evSTdMy3FsLBby7HtYp7mY7wZww8On1QrRHzN LjD5c2U1PCo58bilrdzEgde+Ppz/oo1J5v250= 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=ebAosDZzRsArg5IuDsKAbMifPWwwVSsVnnIX4Huqy0w=; b=pPfIJV2TuUt1sOErqTAAoXSQpP35epGRvsqYM6qOV9D2oF+fZRDLeCLz+XG4ACnFyU XoPyO4T00nCwMeyN37FnmdtsdtZ3deaIMIrbSVHlpBQyOUqi83fY890Rf7LYw5uaTLCl lug94oYW+LEwlkQy3PGzZoPiVJW9borRWLl/vTsj7DNuR2qPlCGSFoQ6wjvzIBDF2km2 /mRSzel8jcZ2/M1idLy85HWBPFKfLOtCCCPnfTjDy8e5t0FVIccPWFTgZN5w1ynZ/KHz bkcIaSJ/UHDg9mtvcff20Pfq01QGqyCAFdv5utCwN0RbMdTtw+lP8PQyfM5TuRNjGs/L 8pZQ== X-Gm-Message-State: AIVw111rauAbBMDA0RkewOUbvNf8lhDzhrOHLeJtiZYqTX62ues3zxE8 JX5jIV79e3OEwDqp+M9aFBcJDPRUSWK/TMQKRe5Ho09tzj5qcnKc92hqAmi4aHbLn9Jf95mxapl hiGiwTHcixEQ6Zw== X-Received: by 10.99.103.129 with SMTP id b123mr19291022pgc.14.1501696788799; Wed, 02 Aug 2017 10:59:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.182.230 with HTTP; Wed, 2 Aug 2017 10:59:18 -0700 (PDT) In-Reply-To: <150169636325.5791.16128248741008174399@ietfa.amsl.com> References: <150169636325.5791.16128248741008174399@ietfa.amsl.com> From: Brian Campbell Date: Wed, 2 Aug 2017 11:59:18 -0600 Message-ID: To: IETF Tokbind WG Content-Type: multipart/alternative; boundary="94eb2c0568cea840240555c9078a" Archived-At: Subject: [Unbearable] Fwd: I-D Action: draft-ietf-tokbind-ttrp-01.txt 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, 02 Aug 2017 17:59:52 -0000 --94eb2c0568cea840240555c9078a Content-Type: text/plain; charset="UTF-8" Just published the -01 draft of "HTTPS Token Binding with TLS Terminating Reverse Proxies" with the changes listed below. Use of the "Sec-" prefix for the header names is the only big change and I didn't want to wait long on getting a draft out that has the new header names. draft-ietf-tokbind-ttrp-01 o Prefix the header names with "Sec-" so that they are denoted as forbidden header names by Fetch https://fetch.spec.whatwg.org/ o Removed potentially confusing sentence from Security Considerations per https://mailarchive.ietf.org/arch/msg/unbearable/ O0IpppyyEqMrQjEkyEi8p8CeBGA o Editorial fixes. ---------- Forwarded message ---------- From: Date: Wed, Aug 2, 2017 at 11:52 AM Subject: [Unbearable] I-D Action: draft-ietf-tokbind-ttrp-01.txt To: i-d-announce@ietf.org Cc: unbearable@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Token Binding WG of the IETF. Title : HTTPS Token Binding with TLS Terminating Reverse Proxies Author : Brian Campbell Filename : draft-ietf-tokbind-ttrp-01.txt Pages : 10 Date : 2017-08-02 Abstract: This document defines common HTTP header fields that enable a TLS terminating reverse proxy to convey information about the validated Token Binding Message sent by the client to a backend server, which enables that backend server to bind, or verify the binding of, cookies and other security tokens to the client's Token Binding key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-01 https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-ttrp-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-ttrp-01 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/ _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --94eb2c0568cea840240555c9078a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just published the -01 draft of "HTTPS Token Binding = with TLS Terminating Reverse Proxies" with the changes listed below.= =C2=A0 Use of the "Sec-" prefix for the header names is the only = big change and I didn't want to wait long on getting a draft out that h= as the new header names.=C2=A0 

  =
 draft-i=
etf-tokbind-ttrp-01

   o  Prefix the header names with "Sec-" so that they are denote=
d as
      forbidden header names by Fetch https://fetch.spec.whatwg.org/

   o  Removed potentially confusing sentence from Security
      Considerations per
      https://mailarchive.ietf.org/arch/msg/unbearable/
      O0IpppyyEqMrQjEkyEi8p8CeBGA

   o  Editorial fixes.


-------= --- Forwarded message ----------
From: <interne= t-drafts@ietf.org>
Date: Wed, Aug 2, 2017 at 11:52 AM
S= ubject: [Unbearable] I-D Action: draft-ietf-tokbind-ttrp-01.txt
To: i-d-announce@ietf.org
Cc: unbearable@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Token Binding WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= HTTPS Token Binding with TLS Terminating Reverse Proxies
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Bria= n Campbell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-tokbind-ttrp-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-08-02

Abstract:
=C2=A0 =C2=A0This document defines common HTTP header fields that enable a = TLS
=C2=A0 =C2=A0terminating reverse proxy to convey information about the vali= dated
=C2=A0 =C2=A0Token Binding Message sent by the client to a backend server, = which
=C2=A0 =C2=A0enables that backend server to bind, or verify the binding of,=
=C2=A0 =C2=A0cookies and other security tokens to the client's Token Bi= nding key.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dra= ft-ietf-tokbind-ttrp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-to= kbind-ttrp-01
https://datatracker.ietf.org/do= c/html/draft-ietf-tokbind-ttrp-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-tokbind-ttrp-01


Please note that it may take a couple of minutes from the time of submissio= n
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/

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


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --94eb2c0568cea840240555c9078a-- From nobody Thu Aug 3 06:34:02 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 89057131FF2 for ; Thu, 3 Aug 2017 06:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] 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 sw51nA9pSc4X for ; Thu, 3 Aug 2017 06:33:42 -0700 (PDT) Received: from p3plsmtpa06-02.prod.phx3.secureserver.net (p3plsmtpa06-02.prod.phx3.secureserver.net [173.201.192.103]) (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 5B438131FE7 for ; Thu, 3 Aug 2017 06:33:32 -0700 (PDT) Received: from [192.168.0.101] ([78.130.190.73]) by :SMTPAUTH: with SMTP id dGFGd6DtncYpUdGFIdQ9z9; Thu, 03 Aug 2017 06:33:00 -0700 To: unbearable@ietf.org References: <150169636325.5791.16128248741008174399@ietfa.amsl.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <0618fbec-ce24-d608-bab8-b1a2a24ece47@connect2id.com> Date: Thu, 3 Aug 2017 16:32:27 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060605020301070509040501" X-CMAE-Envelope: MS4wfMpOarkNdbMl/PIFUm7kERyTFTx/vo4626vuvQdXLrAgI9VRwFbJtmiBxIFuJKYnuEU/G2MJhCvn29VgtwabrRdE6KuZpcRp4Yr650XPnszxzHxSRbZQ h3dTpcVAkETWB8XaAG1aJqd3lk5EVFqzqzXe3CJq4HozfgvGP1iwdvKkazuGoqOpFe7jb4KcBeygUA== Archived-At: Subject: Re: [Unbearable] Fwd: I-D Action: draft-ietf-tokbind-ttrp-01.txt 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, 03 Aug 2017 13:33:45 -0000 This is a cryptographically signed message in MIME format. --------------ms060605020301070509040501 Content-Type: multipart/alternative; boundary="------------F2B3C993E64E7355C79DD2BE" Content-Language: en-US This is a multi-part message in MIME format. --------------F2B3C993E64E7355C79DD2BE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To me forgetting to configure scrubbing of the headers is the worst thing that can potentially happen in a TLS terminating proxy setup. When implementing mTLS we decided to make the header names configurable, and insist on them having a random portion, to make them hard to guess, e.g. X-Client-X509-Cert-alaeLuL8geiqu3OhOg1Mafa4Ecu9ahsh. The prefix was put there to ease debugging. By doing this the header name essentially becomes a secret, shared between the TLS proxy and the backend server. Someone probing the TLS proxy to see if scrubbing was accidentally left out will have a much harder job with this. I don't know if something like that was discussed in Prague. I understand that there's great interop value in making header names standard. The downside of having set header names is that attacks on badly configured TLS proxies become much easier to carry out. This is my concern about the TTRP spec in this form. Thanks, Vladimir On 02/08/17 20:59, Brian Campbell wrote: > Just published the -01 draft of "HTTPS Token Binding with TLS Terminati= ng > Reverse Proxies" with the changes listed below. Use of the "Sec-" pref= ix > for the header names is the only big change and I didn't want to wait l= ong > on getting a draft out that has the new header names. > > draft-ietf-tokbind-ttrp-01 > > > o Prefix the header names with "Sec-" so that they are denoted as > forbidden header names by Fetch https://fetch.spec.whatwg.org/ > > o Removed potentially confusing sentence from Security > Considerations per > https://mailarchive.ietf.org/arch/msg/unbearable/ > > O0IpppyyEqMrQjEkyEi8p8CeBGA > > > o Editorial fixes. > > > > ---------- Forwarded message ---------- > From: > Date: Wed, Aug 2, 2017 at 11:52 AM > Subject: [Unbearable] I-D Action: draft-ietf-tokbind-ttrp-01.txt > To: i-d-announce@ietf.org > Cc: unbearable@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Token Binding WG of the IETF. > > Title : HTTPS Token Binding with TLS Terminating Reve= rse > Proxies > Author : Brian Campbell > Filename : draft-ietf-tokbind-ttrp-01.txt > Pages : 10 > Date : 2017-08-02 > > Abstract: > This document defines common HTTP header fields that enable a TLS > terminating reverse proxy to convey information about the validated > Token Binding Message sent by the client to a backend server, which > enables that backend server to bind, or verify the binding of, > cookies and other security tokens to the client's Token Binding key.= > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-01 > https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-ttrp-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tokbind-ttrp-01 > > > Please note that it may take a couple of minutes from the time of submi= ssion > 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/ > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > > --------------F2B3C993E64E7355C79DD2BE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

To me forgetting to configure scrubbing of the headers is the worst thing that can potentially happen in a TLS terminating proxy setup.

When implementing mTLS we decided to make the header names configurable, and insist on them having a random portion, to make them hard to guess, e.g. X-Client-X509-Cert-alaeLuL8geiqu3OhOg1Mafa4Ecu9ahsh. The prefix was put there to ease debugging. By doing this the header name essentially becomes a secret, shared between the TLS proxy and the backend server. Someone probing the TLS proxy to see if scrubbing was accidentally left out will have a much harder job with this.

I don't know if something like that was discussed in Prague. I understand that there's great interop value in making header names standard. The downside of having set header names is that attacks on badly configured TLS proxies become much easier to carry out. This is my concern about the TTRP spec in this form.

Thanks,

Vladimir


On 02/08/17 20:59, Brian Campbell wrote:
Just published the -01 draft of "HTTPS Token Binding=
 with TLS Terminating
Reverse Proxies" with the changes listed below.  Use of the "Sec-" prefix=

for the header names is the only big change and I didn't want to wait lon=
g
on getting a draft out that has the new header names.

   draft-ietf-tokbind-ttrp-01
<https://tools.ietf.org/html/draft-ietf-tokb=
ind-ttrp-01>

   o  Prefix the header names with "Sec-" so that they are denoted as
      forbidden header names by Fetch https://fetch.spec.whatwg.org/

   o  Removed potentially confusing sentence from Security
      Considerations per
      https://mailarchive.ietf.org/arch/msg/unbear=
able/
<https://mailarchive.i=
etf.org/arch/msg/unbearable/O0IpppyyEqMrQjEkyEi8p8CeBGA>
      O0IpppyyEqMrQjEkyEi8p8CeBGA
<https://mailarchive.i=
etf.org/arch/msg/unbearable/O0IpppyyEqMrQjEkyEi8p8CeBGA>

   o  Editorial fixes.



---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Wed, Aug 2, 2017 at 11:52 AM
Subject: [Unbearable] I-D Action: draft-ietf-tokbind-ttrp-01.txt
To: i-d-announce@ietf.org
Cc: unbearable@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Token Binding WG of the IETF.

        Title           : HTTPS Token Binding with TLS Terminating Revers=
e
Proxies
        Author          : Brian Campbell
        Filename        : draft-ietf-tokbind-ttrp-01.txt
        Pages           : 10
        Date            : 2017-08-02

Abstract:
   This document defines common HTTP header fields that enable a TLS
   terminating reverse proxy to convey information about the validated
   Token Binding Message sent by the client to a backend server, which
   enables that backend server to bind, or verify the binding of,
   cookies and other security tokens to the client's Token Binding key.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-=
tokbind-ttrp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tokbind-=
ttrp-01
https://datatracker.ietf.org/doc/html=
/draft-ietf-tokbind-ttrp-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddra=
ft-ietf-tokbind-ttrp-01


Please note that it may take a couple of minutes from the time of submiss=
ion
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/

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



--------------F2B3C993E64E7355C79DD2BE-- --------------ms060605020301070509040501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAlSsBX16i/yGZZkfkyj/exMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTcwNDA2MDAwMDAwWhcNMTgwNDA2MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMHntIxpX2yNwHUcSrxfJihY9EtYTwC4VArv/C03YlEV92AQljLFYVKtRp+iKT8WDKo2 CqzPYaIHbKD0ivoou0qXQgv4yOk8rQxFmpTzCCe2c1KercueHfy595CnMz1u8GsQyblZqFMD HmzoEvD1YZiI3FEh049tVixBnHwPD9fyiGlf8+QdjwmBLMQwdrrib7xcswNXKYIsfj6Qm5oa d83bsz8VmYm5U39DbNPh01SzqAzwZt3jMuhy0su7lMs75lKYzWMA7b/9qrp40E3vR0yDvOn5 7Ijs+LFE2wPDTebVVfYT+m24e5/v/2w6sX5g/6oJsZnwPM737zIXV7x6jqECAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQA+4E14UMY HyjzXHClSV9VfWHpPzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBACYLv9z6ZOucvt5MlRhNY6SJISDN 880UmdH7IdeP2kJjS3GwuVaVUCQY/frypeIm3A+y0fKEVNJAJO7tfL88yOW4wjA9JMGokpy5 RswZ0uikkNSOt6CF3YGagsfr4VnrcoUxCH+FoGZcWvWYHajJy+QkVG2i6XvsTE7jv1PIsoDU SJuCW+Dvg6iJI9Etpfv1ZrBeDEL05PkPBZfazKMj4MkVirkfbG3qgbzRzAb+7Vsm309NKQ+i EUfoxt83ByC6+URLl3PoR2UTZv7M1JQmTtaQWe1LrAEKlBGHkfnSlxueLnmpCUJRS7Ldyfh5 60OdVFcB5twXPnYWtoZfdTlbv5oxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAlSsBX16i/yGZZkfkyj/exMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA4MDMxMzMyMjdaMC8GCSqGSIb3DQEJBDEiBCBtjWOplcpV6xlrpqXp2Bx77ph0qkiv 5Dn678pHZVyd2TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQC/NfIRM+KH Uk7GvvbFLeCZPBLK2w8rq9HUMSWPwLVICQ1lzBhFVC2f6R3Ky1UcNvJJxPfEN49DUY/Ciw6K gAdAYrC2YvyQr+oyvclCxGKrFZE3hXg9H0SYhkngHSA9a4aJ8dqd50/O5ztDGewnuRn+VL0h Y8C4YbWuUiSPagkILOmRvbGQxFFFxYqkcXqWuGASgE7ux6ZcblsTNbHdsG+AkqZttBxEGLxm BaC2iZ7mJoU71Nr9lgcYCCY5Kh+HVYnlBnjhj8VqOPu9bOX2zEYaGbqXJPDWzLOjO97jiN9e ICpXzHhziWh8Q0SrRLP6lUT/3xHcktBQEXG/WmK1VXZaAAAAAAAA --------------ms060605020301070509040501-- From nobody Thu Aug 3 08:31:24 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 66F33131FF3 for ; Thu, 3 Aug 2017 08:31:22 -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 vh7Qk2HdewrS for ; Thu, 3 Aug 2017 08:31:21 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2BAE132409 for ; Thu, 3 Aug 2017 08:31:19 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id u207so10610325ywc.3 for ; Thu, 03 Aug 2017 08:31:19 -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=0in+IilebASAutKnaY1PMs/QwEnA4V1obWe4lUP4Ahk=; b=vuYB9rDiQNiajiJ0Wrx55f/uGOMRvk0Vu3CP16JahyZtqQB7+Hje56emJSJzDdzGPq zV6aAbrTKF24xolPo/odRldogVR+liPPN3eO8uKkJXT3DrOA3xkdQ8s9Lw+tfnaBSTKe gbqPsznu1CvIbcOgjIsTUpUk9TsjtEzMLWcP7d5Ivf02N5Lcn4zXfHsyEJlnN14J31sO xCKgwbAF8RWIb4M6iIQZyWJrfMq+s9DuUuADIcM5ak+XZykShu2KfW8zXfLo5sIjhi3c 8YedfTbhn1TqfBBZtoFwjTky+CVdsCTxNDixT2ltz2usUKvgbBjEltBWVTqQKneXswgL Z0oA== 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=0in+IilebASAutKnaY1PMs/QwEnA4V1obWe4lUP4Ahk=; b=NHr0a/1J1zDMcnyHSO+jXyOn8p+hOgbAefe3diRuKc/TcllqLPyyk4MzviPmYJ/qkf 1W201VsKztEmamib9NAxaX+zaAvgzlHZ9rTIGpVSP7Rw+mm4IjpkmEpucTzcxgV9+okB xJZBNvU4ojmYvKQ2XbcWR5CDBohh8B600DyMrrYhp9JRinLFMdkCmRoC3Cymt9WLa3VT /b0kxwpTu0zIvZLV/XkCRH4YHqm5jBxAS/3Fe5V9IhO+ONfT+enGr7iosJFSjipyn7W0 7QMd3kJEyg0ucIeag7kz3pnKbbEIybfGTs6PLg7k8iO20d1ochnB9IMW/1k+iHUKWSsc mRfg== X-Gm-Message-State: AIVw11187SWgEK1UwfX7V//F1Tt8KPFvPuz6K2I4/NkI6Aq15JjlGwJo 1RjFB5AXutsP6zVJJIlGvDgddVbQceFkreI= X-Received: by 10.129.47.200 with SMTP id v191mr1498728ywv.27.1501774278489; Thu, 03 Aug 2017 08:31:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.222.135 with HTTP; Thu, 3 Aug 2017 08:31:17 -0700 (PDT) In-Reply-To: <0618fbec-ce24-d608-bab8-b1a2a24ece47@connect2id.com> References: <150169636325.5791.16128248741008174399@ietfa.amsl.com> <0618fbec-ce24-d608-bab8-b1a2a24ece47@connect2id.com> From: Bill Cox Date: Thu, 3 Aug 2017 08:31:17 -0700 Message-ID: To: Vladimir Dzhuvinov Cc: Tokbind WG Content-Type: multipart/alternative; boundary="001a113aafc667c4bc0555db12af" Archived-At: Subject: Re: [Unbearable] Fwd: I-D Action: draft-ietf-tokbind-ttrp-01.txt 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, 03 Aug 2017 15:31:22 -0000 --001a113aafc667c4bc0555db12af Content-Type: text/plain; charset="UTF-8" On Thu, Aug 3, 2017 at 6:32 AM, Vladimir Dzhuvinov wrote: > The downside of having set header names is that attacks on badly > configured TLS proxies become much easier to carry out. This is my concern > about the TTRP spec in this form. > > Thanks, > > Vladimir > I think most coders adding the standard header will the RFC, and will be more likely to remember to scrub the header. One question about the spec: Why must the "sec-token-binding" header be removed? I did that originally in an implementation, and was asked to stop "molesting the headers". Bill --001a113aafc667c4bc0555db12af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 3, 2017 at 6:32 AM, Vladimir Dzhuvinov &l= t;vladimir@con= nect2id.com> wrote:
=20 =20 =20

The downside of having set header names is that attacks on badly configured TLS proxies become much easier to carry out. This is my concern about the TTRP spec in this form.

Thanks,

Vladimir

I think most coders adding the standard he= ader will the RFC, and will be more likely to remember to scrub the header.=

One q= uestion about the spec: Why must the "sec-token-binding" header b= e removed?=C2=A0 I did that originally in an implementation, and was asked = to stop "molesting the headers".
=
Bill
--001a113aafc667c4bc0555db12af-- From nobody Thu Aug 3 08:47: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 0B1631325D6 for ; Thu, 3 Aug 2017 08:47:52 -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 BCXwIkKyK3PN for ; Thu, 3 Aug 2017 08:47:50 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76D6D1325D4 for ; Thu, 3 Aug 2017 08:47:50 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id l82so10916111ywc.2 for ; Thu, 03 Aug 2017 08:47:50 -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=1z9nBsgVAMsdRL/1U3H3IbKqk5Ky5pjluv586BP4Vqs=; b=haPUdkEPynPGZOoiHriC8oTtedWsUyrabhveRKJxYgv/jBrbxI4dM6/w36Yj67rOwn xQ/5hBLyP47YjeAOIJvW6NHuJ0Mwh3PL03KgjzInsIATGHg0aSX6HKSh+KqZYsb8VrQy f+eqmAKurY2l0SeSX1KbkHI3rAMDPeX6e0JJSH9kOKtFeIkrDgJ/Lh44TgsFi5GiP648 l73LtgExGpciu2gYVwwLab1lwDnackgjeu34Fgk1s23uHCfn2lwlYX+MNX7A4/jNeWJz UeddSnXOAahNd5u2gLDO6HQXIC4BdA+JIn63309JkzhhKGoA7aKgivGcJLUrD0ex+P7e 3Sog== 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=1z9nBsgVAMsdRL/1U3H3IbKqk5Ky5pjluv586BP4Vqs=; b=sQzsDzZHsg9I/jly3ow1r569uh54E661qIamvLExLvO+1tkg3gyVuyTf4BX+JZ25MO mtpnHC5sBgPfPownK6wWZS/dN+qKiAw6vYgD7PzKNLZqo6rpMnhi1brWvuwtMBezimPZ Ta27DJ92VzDEE6B/P2gHq+htRk+DoZXW1WumyxBBy9qX7e4M9vp49xie+MOA0KilWJqP nuwYZ10iKGTqeaibWVz9ZIsPrrBEJ4HKU9WD73Ju8y9BM9EV9FpJYmWQUuewcnIa+LpH 4kSHs0f7/SWKELpadH4Ie+3jSZbAcb7gUmKQGSyFF2kbs/ph4y9Cr8pe0VvgxiiRJy4H 2f6Q== X-Gm-Message-State: AIVw113UECK8wigcqxIIqFXJxtBUUqTgOcE+bIIMHfIVIRk4bPyM7XnW qRnF9O//7iSZeFgFBNoHkgyCmMSw/p78uXT9ag== X-Received: by 10.129.147.67 with SMTP id k64mr1661393ywg.56.1501775269206; Thu, 03 Aug 2017 08:47:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.222.135 with HTTP; Thu, 3 Aug 2017 08:47:48 -0700 (PDT) From: Bill Cox Date: Thu, 3 Aug 2017 08:47:48 -0700 Message-ID: To: Tokbind WG Content-Type: multipart/alternative; boundary="94eb2c07e73474a9a80555db4db2" Archived-At: Subject: [Unbearable] More thoughts on reverse-proxies 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, 03 Aug 2017 15:47:52 -0000 --94eb2c07e73474a9a80555db4db2 Content-Type: text/plain; charset="UTF-8" I like the TTRP spec, but there are at least two other modes of operation a reverse proxy might want to use. The simplest way for an organization that uses NGINX to enable token binding is to use Piotr's token-binding module . Piotr did great work on that, but there is room for improvement, such as using a more modern and shorter MAC appended to the cookie. Would it make sense to have an RFC for this mode of operation? That way, javascript that manipulates the cookie cleartext would be simpler to write: it would only have to look for one token-bound cookie format. The other mode of operation is one I favor for large scale deployments: The proxy could compute the EKG value needed for verification and pass this in a new header to the back-end. Then, the cookie server could verify cookie TB signatures in the back-end. This scheme has several advantages: --94eb2c07e73474a9a80555db4db2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I like the TTRP spec, but there are at least two other mod= es of operation a reverse proxy might want to use.

The s= implest way for an organization that uses NGINX to enable token binding is = to use Piotr's = token-binding module.=C2=A0 Piotr did great work on that, but there is = room for improvement, such as using a more modern and shorter MAC appended = to the cookie.=C2=A0 Would it make sense to have an RFC for this mode of op= eration?=C2=A0 That way, javascript that manipulates the cookie cleartext w= ould be simpler to write: it would only have to look for one token-bound co= okie format.

The other mode of operation is one I = favor for large scale deployments: The proxy could compute the EKG value ne= eded for verification and pass this in a new header to the back-end.=C2=A0 = Then, the cookie server could verify cookie TB signatures in the back-end.= =C2=A0 This scheme has several advantages:


--94eb2c07e73474a9a80555db4db2-- From nobody Thu Aug 3 08:50:08 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 070101320D3 for ; Thu, 3 Aug 2017 08:50:07 -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, HTML_MESSAGE=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=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahirIC9pXTT7 for ; Thu, 3 Aug 2017 08:50:05 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AED761320D6 for ; Thu, 3 Aug 2017 08:50:04 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id y15so7788184lfd.5 for ; Thu, 03 Aug 2017 08:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pEbubMC4wL7A6dK8dkYDfrTechrTo4k86vcaYqWRIBU=; b=VoJDOTsbQkdwQq4mNabacteT9VrhXFWHnyZaxTYQHwIcPYwt4SEoOwEOLv2nqJ7Whj L+2E4o4vDsr5abCzLGMc9czyDX82Ec5IzZB0UWEKu4BSjGbao3/rikS/uM6Bwq8YPNTK 8bZx9FCeroMq7XKyVz+CMKHlim1zDLxeo0JJmO3wR/iMYlmWf7e86U8ifokcPBY+drHb B/dIoHw9LglrPzgWK3TqHvw3N5t28X8CQS2oL/vqJjTMr5TkIKhAEtt2ZGLeWM7tq2Uv QYe9wOuKXXLMjfUqL8BcRVlLvcEESAW0ugOIINFAIgkauQFzTHIrwB6e5gj1kqlbRp9W OwoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=pEbubMC4wL7A6dK8dkYDfrTechrTo4k86vcaYqWRIBU=; b=pf0CszzOenEfaSQKRh3mPFdkwbEXTazDYEHsx2XfTqHzf3F6DeFzMZ8HDIdeQfaR1B be6+1bBDKYfPDb1LClTeXLugsUBcbtmjVubzE3+bOvaVh6SihGz2nCz6k+UGpOJHEY0t UJ5jBfQSATFCiAyDCUlmlYgXtMjrhIYLk1haBXVlE/+n3GAgQ8dOVSQ5syfJhYHxuWyG EoJG3NK+Ym4HeYys39/Hbr9NjUcWqXP1+vlAeYqyUpE8ICNgc11WfDZe8xZianfoR+Nk mC1oWA2KLMDALKXAjeyiuui6XBqRmNlkk+ZnMCKp7sEsRr8LXQHF1te2SCRYFSFJclEP 6JkA== X-Gm-Message-State: AHYfb5iFGJZmxqvY3kXd6khTesJHDEXd7JsVg4WFF7pPuZlGTaYB/izp UHl3GbgluYY6IG27at1AlQ== X-Received: by 10.25.161.209 with SMTP id k200mr827970lfe.132.1501775402759; Thu, 03 Aug 2017 08:50:02 -0700 (PDT) Received: from [192.168.86.103] ([191.115.81.54]) by smtp.gmail.com with ESMTPSA id h11sm458122ljb.55.2017.08.03.08.50.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 08:50:02 -0700 (PDT) From: John Bradley Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 3 Aug 2017 11:49:52 -0400 In-Reply-To: Cc: Vladimir Dzhuvinov , Tokbind WG To: Bill Cox References: <150169636325.5791.16128248741008174399@ietfa.amsl.com> <0618fbec-ce24-d608-bab8-b1a2a24ece47@connect2id.com> X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11403c44701a520555db5517" Archived-At: Subject: Re: [Unbearable] Fwd: I-D Action: draft-ietf-tokbind-ttrp-01.txt 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, 03 Aug 2017 15:50:07 -0000 --001a11403c44701a520555db5517 Content-Type: multipart/alternative; boundary="Apple-Mail=_B34432D9-199F-4348-AA10-33D87FDEA591" --Apple-Mail=_B34432D9-199F-4348-AA10-33D87FDEA591 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think the main concern is sanitizing the Referred-Token-Binding-ID and = Sec-Provided-Token-Binding-ID headers rather than the original = Sec-Token-Binding header. The concern is if the TTP is not properly configured an attacker could = send the=20 Referred-Token-Binding-ID and Sec-Provided-Token-Binding-ID headers = directly to bypass security. At the F2F a number of suggestions were made around how to = prevent/detect misconfiguration of one of a set of TTP that is not = configured to sanitize those headders. John B > On Aug 3, 2017, at 11:31 AM, Bill Cox wrote: >=20 >=20 >=20 > On Thu, Aug 3, 2017 at 6:32 AM, Vladimir Dzhuvinov = > wrote: > The downside of having set header names is that attacks on badly = configured TLS proxies become much easier to carry out. This is my = concern about the TTRP spec in this form. >=20 > Thanks, > Vladimir > I think most coders adding the standard header will the RFC, and will = be more likely to remember to scrub the header. >=20 > One question about the spec: Why must the "sec-token-binding" header = be removed? I did that originally in an implementation, and was asked = to stop "molesting the headers". >=20 > Bill > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable --Apple-Mail=_B34432D9-199F-4348-AA10-33D87FDEA591 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I think the main concern is sanitizing the Referred-Token-Binding-ID and Sec-Provided-Token-Binding-ID headers rather than the = original Sec-Token-Binding header.

The concern is if the TTP is not = properly configured an attacker could send = the 
Referred-Token-Binding-ID = and Sec-Provided-Token-Binding-ID headers directly to bypass = security.

At = the F2F a number of suggestions were made around how to = prevent/detect misconfiguration of one of a set of TTP that is not = configured to sanitize those headders.

John B

On Aug 3, 2017, at 11:31 AM, Bill Cox <waywardgeek@google.com> wrote:



On Thu, Aug 3, 2017 at 6:32 AM, Vladimir Dzhuvinov = <vladimir@connect2id.com> wrote:
=20 =20 =20

The = downside of having set header names is that attacks on badly configured TLS proxies become much easier to carry out. This is my concern about the TTRP spec in this form.

Thanks,

Vladimir

I think most coders adding the standard = header will the RFC, and will be more likely to remember to scrub the = header.

One question about the spec: Why must the = "sec-token-binding" header be removed?  I did that originally in an = implementation, and was asked to stop "molesting the headers".

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

= --Apple-Mail=_B34432D9-199F-4348-AA10-33D87FDEA591-- --001a11403c44701a520555db5517 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIKnCXA2drh/PkM4ymlMZR28liTOx RDCmkJnFuws49G/SMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDgwMzE1NTAwM1owaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQAm630x5NsDtH7+Zj7QQ+lW3UM0nECe3qSgfEcS+0dlKJek PHrVNArI/WYKDmj2wH3pHWPM1E/smXy0pT89Q2SkkQ4bkZLrerqgQVq6ONr9X9qubtMluRRxuh8J c3lz3r/+V2pAou6xOx7lxbo8OHZW7pJBYoqyZg59ulEns444H6DOlSbtuK52hQ139yLLfENar2HV nClfDHN/UUAOnxrGD6zmWTLzLiYGCVV0r/vLIGoZxvlYh9cqT0nyBZmtKB6NTRrKqEicj61mMPIh ytUQD7pAT3jZzwQGk7YHScUgQF8RtjwjzH0ntW4heDrCfQw8blOngiZRr+lxWKtULpfo --001a11403c44701a520555db5517-- From nobody Thu Aug 3 09:09: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 79FE01324A1 for ; Thu, 3 Aug 2017 09:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HM3flTRAUIKO for ; Thu, 3 Aug 2017 09:09:11 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1B81324BE for ; Thu, 3 Aug 2017 09:09:11 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id t128so8120080lff.2 for ; Thu, 03 Aug 2017 09:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=8MyVpKoRYADk01ZuoGYyc+Z5DSBUd6E3/9h18qVy46s=; b=KLTYp7QSdc6rUVHpBJyixWrOZiIPDMy4BYJ2XQi5B2QNVHevosrGFMmv95q3F05SnD Hl4r/xesXA63fVfKbSNYx9uVNo7jHPmwhemXm38zFqj0oAS8Ua+4FfhoHYEBRpWZFJPy Ch9m9/5b76N6j43CxMOZQbHssevaRCYFRvDdtXASBIBXWwcz8n6FS4w6m6Q9u7pbyOUR KFqc6ki7HDvnhiykYZDL9XlkasXsZC/kr5PQZ0OqCD2Odw+DS40HlKcEwtIJ63IFyFea NcnwrMvZQrEHcUWZtBZMaVQW3cC3h1wQnx2trutkAw4hfG7BUmCYpcZMcurAo6e+39Jm lThg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=8MyVpKoRYADk01ZuoGYyc+Z5DSBUd6E3/9h18qVy46s=; b=l1jIW+deGKotM1iZwd2MB9Tvg43bE18v2erzbz0uVnb0WxHVIbekykELvIxHPKqaBY HK8aSoaZzgMWop69s2U6xSWyGRUDVNTAFMs2jMYLUNv6lkVjHMttirHbCeEn7Wcgui+E 0mGLTsAV1qMeDG2FL/eUlcyvbWQQao7fP3RIBa9M32A2mbOvAanrjAPCfwB/kxZkh/pf XAYpgTvugX+Og/YJSX7vc9AD0c7DTmEMK4R33kZ0oaWxTVUg/zkRUAYSGaadt0uaLrt0 OvJeou45neI2RHwRdhye9KPskDFtNG1HgCdZeUiZ+rEFAfjFhJ1mQvkHwr7C3UOtweeQ T7wg== X-Gm-Message-State: AIVw113K4r4+QEleUp09MF0Q2oU2wjBl9UKPMlMhj48I/mqJt/AUaNK9 oEdeapdCNfwxK2nJ X-Received: by 10.46.25.218 with SMTP id 87mr1041003ljz.103.1501776548790; Thu, 03 Aug 2017 09:09:08 -0700 (PDT) Received: from [192.168.86.103] ([191.115.81.54]) by smtp.gmail.com with ESMTPSA id p76sm6724491lfe.2.2017.08.03.09.09.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 09:09:08 -0700 (PDT) From: John Bradley Message-Id: <06C33AEC-A825-486A-B9A3-86DB31EDF89B@ve7jtb.com> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 3 Aug 2017 12:09:03 -0400 In-Reply-To: Cc: Tokbind WG To: Bill Cox References: X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c1a6394c156f10555db99b6" Archived-At: Subject: Re: [Unbearable] More thoughts on reverse-proxies 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, 03 Aug 2017 16:09:13 -0000 --94eb2c1a6394c156f10555db99b6 Content-Type: multipart/alternative; boundary="Apple-Mail=_44EFF2EC-41C7-451D-A7F6-B40469AF4400" --Apple-Mail=_44EFF2EC-41C7-451D-A7F6-B40469AF4400 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The version of the spec passed the EKM to the backend. The WG asked = the author to change it to this method. Both work and have advantages and disadvantages. One problem with the = EKM approach was the possibility of multiple EKM sizes when the original = draft was done. However a separate decision was made to fix the EKM = size for this version to a single value making the EKM approach simpler. = In that case it would be the EKM header that would need sanitizing. I suspect documenting both methods in a spec will just add to the = confusion and delay support in products. Nothing stops someone from implementing both in a product if they see = value. I think there may be an advantage to the EKM method if new token binding = types are added( I think MS may be using some but Tony as not provided = any details to the WG yet) With having the TTP validate the provided and referred token binding ID = the TTP has to know a lot more and would need to be updated to validate = other types. With the EKM method the proxy is much simpler and jan just extract the = EKM and allow the Sec-Token-Binding header to pass through untouched. The EKM approach is probably best for more sophisticated deployments as = alter apps need to validate the token binding. The validate in TTP method covers all current documented use cases and = could be extended in future. It is much simpler for apps and may be = best to drive adoption. I do think the NGINX approach has value, but question if it really needs = standardization and what value that would have. It is strictly focused = on cookies. I thought NGINX stripped the over signing before it passed = the cookie to the app, so that it was transparent. The only thing that = might see the wrapped cookie is the browser and I don=E2=80=99t know = that standardizing the wrapping so that browser JS can inspect it has = value. I could perhaps see it if you hat TTP from multiple vendors that all = needed to deal with the same cookie. That might be a reason if someone = wanted to write it up as a ID and submit it to the WG. I don=E2=80=99t = know if people would see value in working on it for what might be = considered a edge case. Thanks for the feed back John B. > On Aug 3, 2017, at 11:47 AM, Bill Cox wrote: >=20 > I like the TTRP spec, but there are at least two other modes of = operation a reverse proxy might want to use. >=20 > The simplest way for an organization that uses NGINX to enable token = binding is to use Piotr's token-binding module = . Piotr did great work on = that, but there is room for improvement, such as using a more modern and = shorter MAC appended to the cookie. Would it make sense to have an RFC = for this mode of operation? That way, javascript that manipulates the = cookie cleartext would be simpler to write: it would only have to look = for one token-bound cookie format. >=20 > The other mode of operation is one I favor for large scale = deployments: The proxy could compute the EKG value needed for = verification and pass this in a new header to the back-end. Then, the = cookie server could verify cookie TB signatures in the back-end. This = scheme has several advantages: >=20 >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable --Apple-Mail=_44EFF2EC-41C7-451D-A7F6-B40469AF4400 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The version of the spec passed the EKM to the backend.   =  The WG asked the author to change it to this method.

Both work and have = advantages and disadvantages.   One problem with the EKM approach = was the possibility of multiple EKM sizes when the original draft was = done.   However a separate decision was made to fix the EKM size = for this version to a single value making the EKM approach simpler. =   In that case it would be the EKM header that would need = sanitizing.

I = suspect documenting both methods in a spec will just add to the = confusion and delay support in products.

Nothing stops someone from implementing = both in a product if they see value.

I think there may be an advantage to = the EKM method if new token binding types are added( I think MS may be = using some but Tony as not provided any details to the WG yet)

With having the TTP = validate the provided and referred token binding ID the TTP has to know = a lot more and would need to be updated to validate other = types.

With = the EKM method the proxy is much simpler and jan just extract the EKM = and allow the Sec-Token-Binding header to pass through = untouched.

The = EKM approach is probably best for more sophisticated deployments = as alter apps need to validate the token binding.

The validate in TTP method = covers all current documented use cases and could be extended in future. =  It is much simpler for apps and may be best to drive = adoption.

I do = think the NGINX approach has value, but question if it really = needs standardization and what value that would have.   It is = strictly focused on cookies.  I thought NGINX stripped = the over signing before it passed the cookie to the app, so that it = was transparent.   The only thing that might see the wrapped = cookie is the browser and I don=E2=80=99t know that standardizing = the wrapping so that browser JS can inspect it has = value.

I = could perhaps see it if you hat TTP from multiple vendors that all = needed to deal with the same cookie.  That might be a reason if = someone wanted to write it up as a ID and submit it to the WG.   =  I don=E2=80=99t know if people would see value in working on it = for what might be considered a edge case.

Thanks for the feed = back
John = B.

On = Aug 3, 2017, at 11:47 AM, Bill Cox <waywardgeek@google.com> wrote:

I like the TTRP spec, but there are at least two other modes = of operation a reverse proxy might want to use.

The simplest way for an organization = that uses NGINX to enable token binding is to use Piotr's = token-binding module.  Piotr did great work on that, but there = is room for improvement, such as using a more modern and shorter MAC = appended to the cookie.  Would it make sense to have an RFC for = this mode of operation?  That way, javascript that manipulates the = cookie cleartext would be simpler to write: it would only have to look = for one token-bound cookie format.

The other mode of operation is one I = favor for large scale deployments: The proxy could compute the EKG value = needed for verification and pass this in a new header to the = back-end.  Then, the cookie server could verify cookie TB = signatures in the back-end.  This scheme has several = advantages:


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

= --Apple-Mail=_44EFF2EC-41C7-451D-A7F6-B40469AF4400-- --94eb2c1a6394c156f10555db99b6 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIFlj8FN6cMiiBHquWXHxt/mgqSkV M7CQt18oaKM5i3bwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDgwMzE2MDkwOVowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQAKBYqsO4t/rROUXwGIUBXKYreH9hk8ZLcb3OVTxTNLO2TO pYriEMJ3tGkMyKe8QhuvtOl2gZxTknqQEqkg+vp4L5MFNfySFxQfWXF/SFnrbwJNxeKphTgKn7RT jywLTS0pO5aSz/gGvzvWkUd6QKy98aRedNp/6h+RnDov89+YQvOAy4UtmSBgJs/K5zhRgYnynMYf B1f6FuIEUgQxcIPKqF+2q2c9PlBMqH6/vhRxONjXHLud01UferT5gemkK1nd1ktP3CH2dj+lU42N iFmo4XgMQDton9r588S19CORTyzm4s5+ON+25Y5Z9gbpPavTlyS8p1VGQriuLrboQodP --94eb2c1a6394c156f10555db99b6-- From nobody Thu Aug 3 09:09:59 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 9D202132521 for ; Thu, 3 Aug 2017 09:09:57 -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 dcuyShiGv7bc for ; Thu, 3 Aug 2017 09:09:55 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B731324C5 for ; Thu, 3 Aug 2017 09:09:55 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id l82so11330267ywc.2 for ; Thu, 03 Aug 2017 09:09:55 -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; bh=GFwsOOqTa/tS4sOAZW4a6+wPXH9hiH1vcGChZFFA1Mc=; b=FRI+RwpTp01/kjh0vq1XRchJ8+ChP7LbfDxMCYTE/rrY2cUbU+tXF8a7N6rIlHMAkH xg3RTJvc9PWWYnjNdrKzJ6Rlx7PPUTT0hzQHoHQscxSWflen8w0y4AjYfIXJ01iANvFx EQi7yIYZ6PpRs/rIBVi9i9Zha2WrMX8Sf867IIIchd9mBsBuoMlL49YCnFOBK+XNksvj zmq+kQEd5mrD6NI/7sa/a0EqpYDuu7IfpuvZXPGROS47GTfNpO4J7aPkZ/BhR3J1mRen OOduMEAXbvsCMAdsweD2j41hh/h8rMBR6Mzfb+logJqm1jXI6GtCGxLpQvfUA+J+naSd ezxg== 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=GFwsOOqTa/tS4sOAZW4a6+wPXH9hiH1vcGChZFFA1Mc=; b=JMWRWvZ1yH3bXFjASVUt2NMSnY767mZII6EM1+dbSLa3Dg6fe0VD5Y6LwT594gCxdq Gp7d7qevkeN5Z0J3vQvzAD4MHR1bnnyw0osn38xMNBJCgmdxLTT9AgxSXIfF0R6P1pmd NO03/fJjZY7x3ev8yXPmHUxj+LFHh06FddkNwo9IZnvcutYE8262nVmRD7iIT52psuJT fJcfNrYM1EMhom0c+84KUFTqTErLY2YRiZcGOBfQZqXRwz/4gsCSP6IZkx3sF63Bsgn8 G1UgjXWq7p86b8FinxRB4Kp2SBXfnLL8HN9TAcrnuDs8LxNE4/cJE9KXIFp45ZSMAcKu vihQ== X-Gm-Message-State: AIVw110n7kF89OeXWCEuFoqFoJoHrRdbjJiouC60ScgvjLsNc6uZkbyQ FkkzQUya+lEp09QLPCUh5ryETDNVOc4LJSU= X-Received: by 10.13.209.135 with SMTP id t129mr1521667ywd.15.1501776594406; Thu, 03 Aug 2017 09:09:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.222.135 with HTTP; Thu, 3 Aug 2017 09:09:53 -0700 (PDT) In-Reply-To: References: From: Bill Cox Date: Thu, 3 Aug 2017 09:09:53 -0700 Message-ID: To: Tokbind WG Content-Type: multipart/alternative; boundary="001a114e58f071b2e30555db9c19" Archived-At: Subject: Re: [Unbearable] More thoughts on reverse-proxies 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, 03 Aug 2017 16:09:57 -0000 --001a114e58f071b2e30555db9c19 Content-Type: text/plain; charset="UTF-8" Grr... my finger muscle memory expects TAB to indent, not set the focus on SEND. This is my #1 gmail complaint. I can't see what I'm typing very well, and Chrome does not work with my Linux screen reader (yet - I'm working on that), so I can't hear it either. I make this mistake often. Sorry! Anyway, the advantages of TB verification in the back-end are: - The application can continue processing the request in parallel with TB verification. If it is done in the front-end, this adds ~120us in series to every request. - Requests that don't need TB signature verification don't see the signature verification overhead. This can be a high fraction of requests. - 0-RTT replay protection is very expensive in the proxy, but cheap in the cookie back-end. A large organization may have several different types of reverse proxies, and replay protection has to be developed and maintained for each. However, they only need one back-end cache for TB replay protection. 0-RTT replay protection forces proxies to communicate over an entire metro area, slowing everything down by maybe 1ms for every resumption. This does not happen with replay protection in the TB verification back-end. A downside is likely worse protection against cookie theft and reuse. Applications typically only verify auth cookies for new sessions, IIUC, so the TB credentials would not be checked. On Thu, Aug 3, 2017 at 8:47 AM, Bill Cox wrote: > I like the TTRP spec, but there are at least two other modes of operation > a reverse proxy might want to use. > > The simplest way for an organization that uses NGINX to enable token > binding is to use Piotr's token-binding module > . Piotr did great work on > that, but there is room for improvement, such as using a more modern and > shorter MAC appended to the cookie. Would it make sense to have an RFC for > this mode of operation? That way, javascript that manipulates the cookie > cleartext would be simpler to write: it would only have to look for one > token-bound cookie format. > > The other mode of operation is one I favor for large scale deployments: > The proxy could compute the EKG value needed for verification and pass this > in a new header to the back-end. Then, the cookie server could verify > cookie TB signatures in the back-end. This scheme has several advantages: > > > --001a114e58f071b2e30555db9c19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Grr... my finger muscle memory expects TAB to indent, not = set the focus on SEND.=C2=A0 This is my #1 gmail complaint.=C2=A0 I can'= ;t see what I'm typing very well, and Chrome does not work with my Linu= x screen reader (yet - I'm working on that), so I can't hear it eit= her.=C2=A0 I make this mistake often.=C2=A0 Sorry!

Anywa= y, the advantages of TB verification in the back-end are:

- The application can continue processing the request in parallel w= ith TB verification.=C2=A0 If it is done in the front-end, this adds ~120us= in series to every request.
- Requests that don't need TB si= gnature verification don't see the signature verification overhead.=C2= =A0 This can be a high fraction of requests.
- 0-RTT replay prote= ction is very expensive in the proxy, but cheap in the cookie back-end.=C2= =A0 A large organization may have several different types of reverse proxie= s, and replay protection has to be developed and maintained for each.=C2=A0= However, they only need one back-end cache for TB replay protection. =C2= =A00-RTT replay protection forces proxies to communicate over an entire met= ro area, slowing everything down by maybe 1ms for every resumption.=C2=A0 T= his does not happen with replay protection in the TB verification back-end.=

A downside is likely worse protection against coo= kie theft and reuse.=C2=A0 Applications typically only verify auth cookies = for new sessions, IIUC, so the TB credentials would not be checked.

On Thu, Aug 3= , 2017 at 8:47 AM, Bill Cox <waywardgeek@google.com> wr= ote:
I like the TTRP spe= c, but there are at least two other modes of operation a reverse proxy migh= t want to use.

The simplest way for an organization that= uses NGINX to enable token binding is to use Piotr's token-binding modu= le.=C2=A0 Piotr did great work on that, but there is room for improveme= nt, such as using a more modern and shorter MAC appended to the cookie.=C2= =A0 Would it make sense to have an RFC for this mode of operation?=C2=A0 Th= at way, javascript that manipulates the cookie cleartext would be simpler t= o write: it would only have to look for one token-bound cookie format.

The other mode of operation is one I favor for large s= cale deployments: The proxy could compute the EKG value needed for verifica= tion and pass this in a new header to the back-end.=C2=A0 Then, the cookie = server could verify cookie TB signatures in the back-end.=C2=A0 This scheme= has several advantages:



--001a114e58f071b2e30555db9c19-- From nobody Thu Aug 3 12:44:19 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 E22F91317C1 for ; Thu, 3 Aug 2017 12:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] autolearn=ham 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 Vx-RXkoCQQVl for ; Thu, 3 Aug 2017 12:44:16 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFFC7129B26 for ; Thu, 3 Aug 2017 12:44:15 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id v189so10073436pgd.2 for ; Thu, 03 Aug 2017 12:44:15 -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 :cc; bh=FQwitYw84J4oFAn/pH0q3fbHTPXz1qJPX9aVb2b+oIk=; b=MB0Wvuw6lvnhvbT4kGYKfE57gEmhCPZCrAooDHq5Wx/MsgQfK+qbsbCSEma6WXOFwN za7QYhExL+erl448sgZGlMM96ug92DI/abLakeH882pGLS6RathXPI65xV/jgJM3QiNp AqYmdmlL/XbH9Hv1CQ8GxeeDzIjvxRHPAvBjM= 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=FQwitYw84J4oFAn/pH0q3fbHTPXz1qJPX9aVb2b+oIk=; b=uiikjk/1AGiLKmdCpilIPEe+4bhmRtavL2YHOR/mAdhFn33cuKmTUJ5YMXOV9eEUhb a9mMjgzoWHZzfMtP8jCT+HVdxXhQYVb0hde1nycvyQfKHrn7E7RWJCs2dw8AxjhcSvlh jo9Y6cMKf6wSfjIattagup0UZxIr1R3XUDmehdyH+YBlJJdDxn0Lj4EvtEacyJMT8SoW P8qVBijwb62g+JM57xKXnrKbB4GSPqo94PMxiFbma2/GhS5aipgz+LtOpx6MOueLgkgb +/IurD0H8TOKH6KAaGSJdruazhr5vifELCoq7kFEbuUfj3vK38M74e0n6hbTptr0nKv2 MFHw== X-Gm-Message-State: AIVw110RDnVu48hdRpqtOXTaI2avyjZegm8kvP/Dczn/unMD7LvsvBsz NNlbGmPvgBtO3TH7i9T2yICnmwDEVTRZfbxCcZ49E4I4LNhR+ze7OPJ0EmtKRFRNaQkLb7fyoWf HFcjqGAmQ4sg= X-Received: by 10.84.236.4 with SMTP id q4mr3045019plk.423.1501789455389; Thu, 03 Aug 2017 12:44:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.182.230 with HTTP; Thu, 3 Aug 2017 12:43:44 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 3 Aug 2017 13:43:44 -0600 Message-ID: To: Bill Cox Cc: Tokbind WG Content-Type: multipart/alternative; boundary="f403045fe2d40430b90555de9bee" Archived-At: Subject: Re: [Unbearable] More thoughts on reverse-proxies 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, 03 Aug 2017 19:44:18 -0000 --f403045fe2d40430b90555de9bee Content-Type: text/plain; charset="UTF-8" Yeah, there are advantages and disadvantages to both approaches. The approach of providing the EKM to the back-end was what I wrote up in my first cut individual draft. But as John mentioned, the winds of WG consensus moved to the other approach being written up and adopted as a WG item. >From a standardization standpoint, I believe that documenting only a single approach is important to avoid confusion and facilitate interop and adoption. But nothing is requiring anyone to follow the (hopefully someday) RFC approach - it is intended for off-the-shelf products (including open source) and services that need to be mixed and matched in deployments and work together. A large scale deployment that owns all the infrastructure is, of course, free to do it however is deemed most appropriate. Similarly, the approach the NGINX module uses has value and will be appropriate for some deployments. But I don't see value in standardization of it. On Thu, Aug 3, 2017 at 10:09 AM, Bill Cox wrote: > Grr... my finger muscle memory expects TAB to indent, not set the focus on > SEND. This is my #1 gmail complaint. I can't see what I'm typing very > well, and Chrome does not work with my Linux screen reader (yet - I'm > working on that), so I can't hear it either. I make this mistake often. > Sorry! > > Anyway, the advantages of TB verification in the back-end are: > > - The application can continue processing the request in parallel with TB > verification. If it is done in the front-end, this adds ~120us in series > to every request. > - Requests that don't need TB signature verification don't see the > signature verification overhead. This can be a high fraction of requests. > - 0-RTT replay protection is very expensive in the proxy, but cheap in the > cookie back-end. A large organization may have several different types of > reverse proxies, and replay protection has to be developed and maintained > for each. However, they only need one back-end cache for TB replay > protection. 0-RTT replay protection forces proxies to communicate over an > entire metro area, slowing everything down by maybe 1ms for every > resumption. This does not happen with replay protection in the TB > verification back-end. > > A downside is likely worse protection against cookie theft and reuse. > Applications typically only verify auth cookies for new sessions, IIUC, so > the TB credentials would not be checked. > > On Thu, Aug 3, 2017 at 8:47 AM, Bill Cox wrote: > >> I like the TTRP spec, but there are at least two other modes of operation >> a reverse proxy might want to use. >> >> The simplest way for an organization that uses NGINX to enable token >> binding is to use Piotr's token-binding module >> . Piotr did great work on >> that, but there is room for improvement, such as using a more modern and >> shorter MAC appended to the cookie. Would it make sense to have an RFC for >> this mode of operation? That way, javascript that manipulates the cookie >> cleartext would be simpler to write: it would only have to look for one >> token-bound cookie format. >> >> The other mode of operation is one I favor for large scale deployments: >> The proxy could compute the EKG value needed for verification and pass this >> in a new header to the back-end. Then, the cookie server could verify >> cookie TB signatures in the back-end. This scheme has several advantages: >> >> >> > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --f403045fe2d40430b90555de9bee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, there are advantages and disadvantages to both = approaches. The approach of providing the EKM to the back-end was what I wr= ote up in my first cut individual draft. But as John mentioned, the winds o= f WG consensus moved to the other approach being written up and adopted as = a WG item. =C2=A0

From a standardization standpoint, I believ= e that documenting only a single approach is important to avoid confusion a= nd facilitate interop and adoption. But nothing is requiring anyone to foll= ow the (hopefully someday) RFC approach - it is intended for off-the-shelf = products (including open source) and services that need to be mixed and mat= ched in deployments and work together. A large scale deployment that owns = all the infrastructure is, of course, free to do it however is deemed most = appropriate. Similarly, the approach the NGINX module uses= has value and will be appropriate for some deployments. But I don't se= e value in standardization of it.




On Thu, Aug 3, 2017 at 10:09 AM, Bill Cox <waywardgeek@googl= e.com> wrote:
Grr... my finger muscle memory expects TAB to indent, not set the focus= on SEND.=C2=A0 This is my #1 gmail complaint.=C2=A0 I can't see what I= 'm typing very well, and Chrome does not work with my Linux screen read= er (yet - I'm working on that), so I can't hear it either.=C2=A0 I = make this mistake often.=C2=A0 Sorry!

Anyway, the advant= ages of TB verification in the back-end are:

- The= application can continue processing the request in parallel with TB verifi= cation.=C2=A0 If it is done in the front-end, this adds ~120us in series to= every request.
- Requests that don't need TB signature verif= ication don't see the signature verification overhead.=C2=A0 This can b= e a high fraction of requests.
- 0-RTT replay protection is very = expensive in the proxy, but cheap in the cookie back-end.=C2=A0 A large org= anization may have several different types of reverse proxies, and replay p= rotection has to be developed and maintained for each.=C2=A0 However, they = only need one back-end cache for TB replay protection. =C2=A00-RTT replay p= rotection forces proxies to communicate over an entire metro area, slowing = everything down by maybe 1ms for every resumption.=C2=A0 This does not happ= en with replay protection in the TB verification back-end.

A downside is likely worse protection against cookie theft and reu= se.=C2=A0 Applications typically only verify auth cookies for new sessions,= IIUC, so the TB credentials would not be checked.

On Thu, Aug 3, 2017 at 8:47 AM, Bill Cox <waywardgeek@googl= e.com> wrote:
I like the TTRP spec, but there are at least two other modes of operati= on a reverse proxy might want to use.

The simplest way f= or an organization that uses NGINX to enable token binding is to use Piotr&#= 39;s token-binding module.=C2=A0 Piotr did great work on that, but ther= e is room for improvement, such as using a more modern and shorter MAC appe= nded to the cookie.=C2=A0 Would it make sense to have an RFC for this mode = of operation?=C2=A0 That way, javascript that manipulates the cookie cleart= ext would be simpler to write: it would only have to look for one token-bou= nd cookie format.

The other mode of operation is o= ne I favor for large scale deployments: The proxy could compute the EKG val= ue needed for verification and pass this in a new header to the back-end.= =C2=A0 Then, the cookie server could verify cookie TB signatures in the bac= k-end.=C2=A0 This scheme has several advantages:

<= br>


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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --f403045fe2d40430b90555de9bee-- From nobody Thu Aug 3 13:21:14 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 33BEF12ECEF for ; Thu, 3 Aug 2017 13:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] autolearn=ham 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 hliH2L1nkAXG for ; Thu, 3 Aug 2017 13:21:11 -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 8B9AE126DEE for ; Thu, 3 Aug 2017 13:21:11 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id y129so10364689pgy.4 for ; Thu, 03 Aug 2017 13:21:11 -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 :cc; bh=Cq1xSUIn1ycQttolfh2v6K7OLsiK5XOhZ8egwRpJw0k=; b=ANtzDIVOHu5Jpgi3gEjpFmCZ14zpCFfIxKKnM+A9IsdTLoVB9gxgiIBEeBIzCzINCn 3eR35I2tvjUUllWUX2xy4naXieQCJNRNfAM4BmvaULwPexkZZ8jf+zv+1HJOspIGyLM6 e2L+roSAOg+rDzFFuuMSSHNr1xlaH7EKrH1Ok= 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=Cq1xSUIn1ycQttolfh2v6K7OLsiK5XOhZ8egwRpJw0k=; b=bYEb+oq8BpH6nHJssMrQvEeCVNjHrTigxUM52xo+OiPN0n9TVW8AXmWFJUiM9ftJAY Apn/PxdR4xcmKxozHwvn5QA6o6dhQv4DYWxQ5YqWjI7FrS3DM9IjYA6muPm5T6ZA1Jai 45bRMrwTEoHGyvelUZQ2YNupSofFRK5cgqtlCgNHNNGII45Bx/eOzvERjGOWUgU3DTAG zth+WwUqJv2YCRxztCt/PEUSLmHUuPlgtQZalgCG/4xX/FlYHJMoQ7D1IXvijyPv50+1 ZjeVAWOt8KcdipkGbvIkSs1l8kf4g+K1SeP9QZaAQ81g/a+HZgERZihQ2UoTwagnkqO2 XGvA== X-Gm-Message-State: AIVw113WPgjhMGR45UeI2Jo7TgobnzNnSNr17oOHtZLU7llWovyd7MX9 aaD5QRd1JdT1cY5QqRfEFUnfHYdzL/RDOzYgwnZKTHRgqZrOO0Xo+WVERMHCNnJ5TCDvetwpDPE njZgphXs3Xt4= X-Received: by 10.98.63.10 with SMTP id m10mr42210pfa.232.1501791671123; Thu, 03 Aug 2017 13:21:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.182.230 with HTTP; Thu, 3 Aug 2017 13:20:40 -0700 (PDT) In-Reply-To: References: <150169636325.5791.16128248741008174399@ietfa.amsl.com> <0618fbec-ce24-d608-bab8-b1a2a24ece47@connect2id.com> From: Brian Campbell Date: Thu, 3 Aug 2017 14:20:40 -0600 Message-ID: To: Bill Cox Cc: Vladimir Dzhuvinov , Tokbind WG Content-Type: multipart/alternative; boundary="94eb2c112c3e159f490555df1fc3" Archived-At: Subject: Re: [Unbearable] Fwd: I-D Action: draft-ietf-tokbind-ttrp-01.txt 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, 03 Aug 2017 20:21:13 -0000 --94eb2c112c3e159f490555df1fc3 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 3, 2017 at 9:31 AM, Bill Cox wrote: > > One question about the spec: Why must the "sec-token-binding" header be > removed? I did that originally in an implementation, and was asked to stop > "molesting the headers". > This is largely to try and comply with HTTPSTB that says the "Sec-Token-Binding" header is sent by the client when TB is negotiated on the TLS connection. On the connection from the TTRP to the backend, the TTRP is the client and TB isn't negotiated (most likely anyway). -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --94eb2c112c3e159f490555df1fc3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Thu, Aug 3, 2017 at 9:31 AM, Bill Cox <waywardgeek@google.com&= gt; wrote:

=
One question about the spec: Wh= y must the "sec-token-binding" header be removed?=C2=A0 I did tha= t originally in an implementation, and was asked to stop "molesting th= e headers".


This is la= rgely to try and comply with HTTPSTB that says the "Sec-Token-Binding&quo= t; header is sent by the client when TB is negotiated on the TLS connectio= n.=C2=A0 On the connection from the TTRP to the backend, the TTRP is the cl= ient and TB isn't negotiated (most likely anyway).=C2=A0



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --94eb2c112c3e159f490555df1fc3-- From nobody Thu Aug 3 14:14:45 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 4BA7912741D for ; Thu, 3 Aug 2017 14:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] autolearn=ham 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 w6xyaAPUXK-T for ; Thu, 3 Aug 2017 14:14:41 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e: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 3D89912EC48 for ; Thu, 3 Aug 2017 14:14:41 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id u185so10876278pgb.1 for ; Thu, 03 Aug 2017 14:14:41 -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 :cc; bh=/idcKwmV7S/Oy1ptGC/S0cDCNlKc9TAC6eus/HWDUUc=; b=LbcJJQb4bvstoSB6PiKdAlJHC+OilxuT0LpnRDvDcseoMpb9IyGFffVIbKvXaYHI2e OsRPqfZAaaxxVwHgtLtvawV6jVVR04DwG/tt5zHusHiGl2/Kt7VCNjpU91C+dXj+TtfB Bp5sJhIPPgKP2ehxp+nuQBv1JX01MIC1Q+4N8= 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=/idcKwmV7S/Oy1ptGC/S0cDCNlKc9TAC6eus/HWDUUc=; b=XSe4lsU4vuwyCsqOm4TKJ28uUj1QWEXUPe/1GP7fQs9ny3MiiIsw1tt0ifja5vhtlM +xpVyvd4BoIY6dKfH/i71i/uB8OravVyg+RJEFI/p8J9FnG9m7XovOm1xYPdhE3Z0C0Y jhIG/ddaD7dxyuPFglKSOy7Kg4UL9aybsNdYq5Mtrp6o0sgJdXH5qDNLEtafoi8CU/km 7KYMIkSfZJn5/t2NtSpDT5T4hNzH/NLJ2Bq3VHT0kkRFobJC4L0w/Xh7nG3oPKF2OzJ7 ccxKfLTGt8ai0YtF7eHphqL+39KC7Uy+1oGJVBf0SAFqLwTCOvvSw5jYMUeF1FPi9Vlh cNNA== X-Gm-Message-State: AIVw111OtBGf+ffiv9GzM4d/G+bw1p7VU24XzpK8OR49cJYYuG2vjwXF S1YbzcQB2YTC8rQ5kdkozSTLcAaFhquF2I8c4pBcbbq4F22iQdCEQISC9bKaHtG1gov5bnemzFI zpVjny19aEnU= X-Received: by 10.98.193.5 with SMTP id i5mr118052pfg.317.1501794880796; Thu, 03 Aug 2017 14:14:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.182.230 with HTTP; Thu, 3 Aug 2017 14:14:10 -0700 (PDT) In-Reply-To: References: <150169636325.5791.16128248741008174399@ietfa.amsl.com> <0618fbec-ce24-d608-bab8-b1a2a24ece47@connect2id.com> From: Brian Campbell Date: Thu, 3 Aug 2017 15:14:10 -0600 Message-ID: To: Bill Cox Cc: Vladimir Dzhuvinov , Tokbind WG Content-Type: multipart/alternative; boundary="94eb2c184714655a0e0555dfdecb" Archived-At: Subject: Re: [Unbearable] Fwd: I-D Action: draft-ietf-tokbind-ttrp-01.txt 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, 03 Aug 2017 21:14:43 -0000 --94eb2c184714655a0e0555dfdecb Content-Type: text/plain; charset="UTF-8" I agree that standardizing the header names significantly increases the likelihood that implementations will properly scrub them. I'm told that this mod_token_binding module for Apache , for example, was recently updated to do the header sanitation automatically in the course of processing rather than relying on configuration directives of other modules to overwrite the headers. So it can't be misconfigured, at least not with respect to this issue. Standardizing the header names allows and suggests for the sanitation to be an implementation thing rather than a configuration thing, which is a good thing. As John said, there were a number of suggestions in Prague and on-list around how to prevent/detect header injection in more of a fail closed way. Vladimir's specific idea didn't come up but there were conceptually similar ideas. I maintain that it would be very inappropriate for this draft to define a one-off mechanism for a backend server to detect client injection of the headers. The potential problem of client header injection is not at all unique to the functionality of the draft so the draft shouldn't define a unique solution. If there's the will and/or appetite to develop a common standardized mechanism detecting/preventing client header injection through reverse proxies, I'd be happy to help contribute to that effort. On Thu, Aug 3, 2017 at 9:31 AM, Bill Cox wrote: > > > On Thu, Aug 3, 2017 at 6:32 AM, Vladimir Dzhuvinov < > vladimir@connect2id.com> wrote: > >> The downside of having set header names is that attacks on badly >> configured TLS proxies become much easier to carry out. This is my concern >> about the TTRP spec in this form. >> >> Thanks, >> >> Vladimir >> > I think most coders adding the standard header will the RFC, and will be > more likely to remember to scrub the header. > > One question about the spec: Why must the "sec-token-binding" header be > removed? I did that originally in an implementation, and was asked to stop > "molesting the headers". > > Bill > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --94eb2c184714655a0e0555dfdecb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree that standardizing the header names= significantly increases the likelihood that implementations will properly = scrub them.

I'm told that this mod_token_binding module= for Apache, for example, was recently updated to do the header sanitat= ion automatically in the course of processing rather than relying on config= uration directives of other modules to overwrite the headers. So it can'= ;t be misconfigured, at least not with respect to this issue. Standardizing= the header names allows and suggests for the sanitation to be an implement= ation thing rather than a configuration thing, which is a good thing.
As John said, there were a number of suggestions in Prague and on-list ar= ound how to prevent/detect header injection in more of a fail closed way. V= ladimir's specific idea didn't come up but there were conceptually = similar ideas.

I maintain that it would be very inappropriate = for this draft to define a one-off mechanism for a backend server to detect= client injection of the headers. The potential problem of client header in= jection is not at all unique to the functionality of the draft so the draft= shouldn't define a unique solution. If there's the will and/or app= etite to develop a common standardized mechanism detecting/preventing clien= t header injection through reverse proxies, I'd be happy to help contri= bute to that effort.


On Thu, Aug 3, 2017 at 9:31 AM, = Bill Cox <waywardgeek@google.com> wrote:


On Thu, Aug 3, 2017 at 6= :32 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> w= rote:
=20 =20 =20

The downside of having set header names is that attacks on badly configured TLS proxies become much easier to carry out. This is my concern about the TTRP spec in this form.

Thanks,

Vladimir

I think most coders adding the stan= dard header will the RFC, and will be more likely to remember to scrub the = header.

One question about the spec: Why must the "sec-token-binding" h= eader be removed?=C2=A0 I did that originally in an implementation, and was= asked to stop "molesting the headers".

Bill

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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --94eb2c184714655a0e0555dfdecb-- From nobody Fri Aug 4 12:02:51 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 E9BC2132006 for ; Fri, 4 Aug 2017 12:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=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 nTUZdN5eMnjx for ; Fri, 4 Aug 2017 12:02:48 -0700 (PDT) Received: from p3plsmtpa06-02.prod.phx3.secureserver.net (p3plsmtpa06-02.prod.phx3.secureserver.net [173.201.192.103]) (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 4ECF4131FE5 for ; Fri, 4 Aug 2017 12:02:48 -0700 (PDT) Received: from [192.168.0.101] ([78.130.190.73]) by :SMTPAUTH: with SMTP id dhrTdCoQZcYpUdhrUdS9ad; Fri, 04 Aug 2017 12:02:17 -0700 To: unbearable@ietf.org References: <150169636325.5791.16128248741008174399@ietfa.amsl.com> <0618fbec-ce24-d608-bab8-b1a2a24ece47@connect2id.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: Date: Fri, 4 Aug 2017 22:02:15 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030901030205030901020302" X-CMAE-Envelope: MS4wfK/uPQD/Z2DJLSXyvgnMkCc8XMTXhL3kC2+nJmZwXsZjYgu7QBStuDJ68SDscALR1CL8vqG1T1B8UPf9g8vIRZw8gyW+YLNMonN7yOr9jIrHExJZivc9 GgZxKMQfqDDzj9A56oVfmoizK+CfRAgabzy0VTI94UvrkQeW+G5fFp7a1TNgtdQYwpQfi+qyqztkRA== Archived-At: Subject: Re: [Unbearable] Fwd: I-D Action: draft-ietf-tokbind-ttrp-01.txt 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, 04 Aug 2017 19:02:50 -0000 This is a cryptographically signed message in MIME format. --------------ms030901030205030901020302 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 04/08/17 00:14, Brian Campbell wrote: > I agree that standardizing the header names significantly increases the= > likelihood that implementations will properly scrub them. > > I'm told that this mod_token_binding module for Apache > , for example, was rece= ntly > updated to do the header sanitation automatically in the course of > processing rather than relying on configuration directives of other mod= ules > to overwrite the headers. So it can't be misconfigured, at least not wi= th > respect to this issue. Standardizing the header names allows and sugges= ts > for the sanitation to be an implementation thing rather than a > configuration thing, which is a good thing. If the proxy implementers get on board with this, as you mention, it will be great. It helps that the implementations are relatively few. I wonder, has there been anywhere work on standardizing a header pattern that can only exist between a reverse proxy and a backend server? > As John said, there were a number of suggestions in Prague and on-list > around how to prevent/detect header injection in more of a fail closed = way. > Vladimir's specific idea didn't come up but there were conceptually sim= ilar > ideas. > > I maintain that it would be very inappropriate for this draft to define= a > one-off mechanism for a backend server to detect client injection of th= e > headers. The potential problem of client header injection is not at all= > unique to the functionality of the draft so the draft shouldn't define = a > unique solution. +1 > If there's the will and/or appetite to develop a common > standardized mechanism detecting/preventing client header injection thr= ough > reverse proxies, I'd be happy to help contribute to that effort. > > > On Thu, Aug 3, 2017 at 9:31 AM, Bill Cox wrote= : > >> >> On Thu, Aug 3, 2017 at 6:32 AM, Vladimir Dzhuvinov < >> vladimir@connect2id.com> wrote: >> >>> The downside of having set header names is that attacks on badly >>> configured TLS proxies become much easier to carry out. This is my co= ncern >>> about the TTRP spec in this form. >>> >>> Thanks, >>> >>> Vladimir >>> >> I think most coders adding the standard header will the RFC, and will = be >> more likely to remember to scrub the header. >> >> One question about the spec: Why must the "sec-token-binding" header b= e >> removed? I did that originally in an implementation, and was asked to= stop >> "molesting the headers". >> >> Bill >> >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >> >> --------------ms030901030205030901020302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAlSsBX16i/yGZZkfkyj/exMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTcwNDA2MDAwMDAwWhcNMTgwNDA2MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMHntIxpX2yNwHUcSrxfJihY9EtYTwC4VArv/C03YlEV92AQljLFYVKtRp+iKT8WDKo2 CqzPYaIHbKD0ivoou0qXQgv4yOk8rQxFmpTzCCe2c1KercueHfy595CnMz1u8GsQyblZqFMD HmzoEvD1YZiI3FEh049tVixBnHwPD9fyiGlf8+QdjwmBLMQwdrrib7xcswNXKYIsfj6Qm5oa d83bsz8VmYm5U39DbNPh01SzqAzwZt3jMuhy0su7lMs75lKYzWMA7b/9qrp40E3vR0yDvOn5 7Ijs+LFE2wPDTebVVfYT+m24e5/v/2w6sX5g/6oJsZnwPM737zIXV7x6jqECAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQA+4E14UMY HyjzXHClSV9VfWHpPzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBACYLv9z6ZOucvt5MlRhNY6SJISDN 880UmdH7IdeP2kJjS3GwuVaVUCQY/frypeIm3A+y0fKEVNJAJO7tfL88yOW4wjA9JMGokpy5 RswZ0uikkNSOt6CF3YGagsfr4VnrcoUxCH+FoGZcWvWYHajJy+QkVG2i6XvsTE7jv1PIsoDU SJuCW+Dvg6iJI9Etpfv1ZrBeDEL05PkPBZfazKMj4MkVirkfbG3qgbzRzAb+7Vsm309NKQ+i EUfoxt83ByC6+URLl3PoR2UTZv7M1JQmTtaQWe1LrAEKlBGHkfnSlxueLnmpCUJRS7Ldyfh5 60OdVFcB5twXPnYWtoZfdTlbv5oxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAlSsBX16i/yGZZkfkyj/exMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA4MDQxOTAyMTVaMC8GCSqGSIb3DQEJBDEiBCDYupT5ppqbpFm8RDKyIuKuUXlwLIKh EiMLYWACmc3E1TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQA49J3Wq5u4 /ir8IXmcvzg3zPja8/07P6JvDeXqMsXpc86Ga8lz2gDGIGvCBL/JPeE7KEXU65fJpycxI9rF aJSQgEsSJyj1GSkjM3II4WpEcJ5CSMkU0EWXWvRk+x+D84Pt+1oJn628OmNR9ZdPXrf7Smnc gJvBaTXbwWLDHJ/HE9jP+cbWyQNFFQ9alMVEQKyIGEV1aHIqHq8YlMXhS24AzqVSR9qeBYDV KH9jlHGkbKB34z1XIWfUaZroUTUClUhoTniSS21ltk8z9nfCHAHM9Ubld1mhEQ8tfBQ08ixX 1+udFxl78K5BxOfcRwnSS+WpNwDWTC2qe3jkb9jv+c9rAAAAAAAA --------------ms030901030205030901020302-- From nobody Sat Aug 5 09:36: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 2EAD0131D70 for ; Sat, 5 Aug 2017 09:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsaiGkWBSTvn for ; Sat, 5 Aug 2017 09:36:18 -0700 (PDT) Received: from treenet.co.nz (unknown [121.99.228.82]) by ietfa.amsl.com (Postfix) with ESMTP id 27F13131CEB for ; Sat, 5 Aug 2017 09:36:15 -0700 (PDT) Received: from [192.168.137.92] (unknown [121.98.43.66]) by treenet.co.nz (Postfix) with ESMTPA id 4E35C66044F for ; Sun, 6 Aug 2017 04:36:13 +1200 (NZST) To: unbearable@ietf.org References: <150169636325.5791.16128248741008174399@ietfa.amsl.com> <0618fbec-ce24-d608-bab8-b1a2a24ece47@connect2id.com> From: Amos Jeffries Message-ID: <275f8e4c-6b4b-8229-8e33-0c89b7bdd498@treenet.co.nz> Date: Sun, 6 Aug 2017 04:36:12 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Unbearable] Fwd: I-D Action: draft-ietf-tokbind-ttrp-01.txt 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: Sat, 05 Aug 2017 16:36:20 -0000 On 05/08/17 07:02, Vladimir Dzhuvinov wrote: > On 04/08/17 00:14, Brian Campbell wrote: >> I agree that standardizing the header names significantly increases the >> likelihood that implementations will properly scrub them. >> >> I'm told that this mod_token_binding module for Apache >> , for example, was recently >> updated to do the header sanitation automatically in the course of >> processing rather than relying on configuration directives of other modules >> to overwrite the headers. So it can't be misconfigured, at least not with >> respect to this issue. Standardizing the header names allows and suggests >> for the sanitation to be an implementation thing rather than a >> configuration thing, which is a good thing. > If the proxy implementers get on board with this, as you mention, it > will be great. It helps that the implementations are relatively few. > > I wonder, has there been anywhere work on standardizing a header pattern > that can only exist between a reverse proxy and a backend server? > The word I got from HTTPbis chair and seniors some years back when I suggested a pattern was that it was a bad idea to depend on header patterning. Sec-* was a necessary evil that was endured rather than encouraged. That said; there is Sec-*, the informal Accept-* in HTTP, and the semi-formal Content-* in SMTP which HTTP inherits quite a few headers from. So following a naming pattern is probably not as bad as formally defining it as a reserved pattern. In other areas, the ESI architecture defines several headers all prefixed Surrogate-* for use exclusively between origin and reverse proxy. Amos