Re: [Unbearable] Benjamin Kaduk's No Objection on draft-ietf-tokbind-https-15: (with COMMENT)

Nick Harper <> Thu, 10 May 2018 14:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF57412EB45 for <>; Thu, 10 May 2018 07:18:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -18.21
X-Spam-Status: No, score=-18.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ciqsSMljMR51 for <>; Thu, 10 May 2018 07:18:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4084312EB0F for <>; Thu, 10 May 2018 07:18:42 -0700 (PDT)
Received: by with SMTP id e20-v6so3327280itc.1 for <>; Thu, 10 May 2018 07:18:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xp6pn78dhNumOht0z87syMKxBq3E4u1mpyvYkjARP4A=; b=ifUmsNbbk61rb5sNtyGod31W6kwtZaUSi71DMyhOoMbKxVBjea+1xn9pV+XWhiM8Hz md5VNhluSn1dSjAdX18vELOd4mcGjUzJnyApRLKVCmCuegKfQqmuO6M/HlYzueJZtOmF 2F/bUAC0uViZEW6iq53Xpp7dZ7SHV6lByP2dnnbvfa6dmvfgpN38kxGfgdg23P5fvFvV QRQoLo8Nbwc0cWwEBravmw7xEcj5Yx/jYHYcF3SW4dtkl6fwBKXMZVSY+fJniOWDwt/7 ePhWQbqd1DhAMNYMlWwS87eDpouDHlu9DqmiJTtdc/HS/9DHpDPO1z/DPEH6oICYuv0O Szsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xp6pn78dhNumOht0z87syMKxBq3E4u1mpyvYkjARP4A=; b=EXNqeIq0+DEmZhEYC7GEPg89PQ8ZUUKQvl4haqsRy3rFh5udUMZgUOcwmf7UsnITjY Z0nWupwUBUY2cKQOX1lx+Oc2amYMhQMlhRlpZIRzGy/2X7uIsRtNSaJV6j7YU5sgQmZx 2y3fm29YPB6Br/QLkhT7EAdwru0mkmLab9/14/fgDbOmH24/zfsEO0XDnsb7ntkyHSz1 OnN9ktTVut7Rq+L3PyPxuOHvpXNdlKC5o5mwIEl6Y8a9/sraEU7/wSQ7WSrOtAmLzS/4 B1X3Rowvres6Xsv/W9joikgr/IbnGHkxJFd85SyPrdmtuUAfAQIXe+5TvlNjyYwuCCVm BGew==
X-Gm-Message-State: ALKqPwfnH9pJrdQ17xZoeEMeuxh3Cv5n0IoxBr24WK0o41Xher762hXV u/oIpd3rSjudnVXXOct+dWam0Q0cjVoerbslICL4Qg==
X-Google-Smtp-Source: AB8JxZrYRV12/bjU5LLyYtyirbPziiua216BuzE80Pr8kaSBB27gKiUPm8XEvwlqN8MKAuO5+VwVY5GRUBA0Ww9IlNE=
X-Received: by 2002:a24:1788:: with SMTP id 130-v6mr1889721ith.122.1525961921069; Thu, 10 May 2018 07:18:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:7b02:0:0:0:0:0 with HTTP; Thu, 10 May 2018 07:18:20 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Nick Harper <>
Date: Thu, 10 May 2018 07:18:20 -0700
Message-ID: <>
To: Benjamin Kaduk <>
Cc: The IESG <>,, John Bradley <>,, IETF Tokbind WG <>
Content-Type: multipart/alternative; boundary="0000000000003f8bf6056bdab268"
Archived-At: <>
Subject: Re: [Unbearable] Benjamin Kaduk's No Objection on draft-ietf-tokbind-https-15: (with COMMENT)
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, 10 May 2018 14:18:53 -0000

On Thu, May 10, 2018 at 6:51 AM, Benjamin Kaduk <> wrote:

> Section 3
> To be clear, this means that the EKM used is the one from before
> the renegotiation, corresponding in the somewhat-common use case of
> renegotiation for optional client authentication to the
> unauthenticated-client state, right?
> For Token Binding messages appearing after renegotiation, the EKM used is
the one computed after renegotiation (different from the one before
renegotiation). If we used the same EKM for the whole connection, then
draft-ietf-tokbind-protocol wouldn't have to require the application
mapping (in this case, draft-ietf-tokbind-https) to specify the interaction
with renegotiation, and draft-ietf-tokbind-https wouldn't need to impose
any restrictions on when renegotiation can occur.