Re: [TLS] draft-sullivan-tls-post-handshake-auth-00

Martin Thomson <> Mon, 08 August 2016 01:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4910F12D550 for <>; Sun, 7 Aug 2016 18:19:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J9PL2BBsRvkI for <>; Sun, 7 Aug 2016 18:19:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 38FA212D181 for <>; Sun, 7 Aug 2016 18:19:41 -0700 (PDT)
Received: by with SMTP id w38so197504066qtb.0 for <>; Sun, 07 Aug 2016 18:19:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w/TrJfKbi8odNN21BxT4+zCRvq+GMBKLDU5hdEbPddA=; b=ygGvvrp5BYAKUp5knOgLKUhEMCoHyg8ttLF8HOpUzSLirH8X6X+zlV99vhfmiT3Ulk XBa756JUQL30zzu/gKVV85Gh/TsetUE56TII8GEQyN5wdpYWM6nTcunOuEe/iQZNL/Fb EhryD5MXs3ABSZGuY+RiqY01M/UMa7Ls7rwMLp3CC7txR+jvBf+uUmJkGpHw6Z33KHGN AZRHHE2t4h7RhzWLFqMddixY4T6fqDLJ0r+Cw7BX2A47b0pnc4To9xJcjdmzp3lGYP1E w6/QHXCRFaTdOwToUMZpXxe30ZxNCTxIDLjHYq3LX8mh9RswbdH8DxU/PrQj9A2i5y0D TGZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=w/TrJfKbi8odNN21BxT4+zCRvq+GMBKLDU5hdEbPddA=; b=YmW5Qt8CzmRUcq9UqHM6w7PKXFZp+34bB9FZojIsSkji32U03Jt+um9EqpIwkgDG2+ 6cklAwW/7RGO6FriMdrEeYVlmiYCDYnH7BMDmCYzmGTdNrgFfmLwsEXkYT38T+plusfb UzJzeTQvXYmi1baR4hTZpouaNIiaQ2H0qXxp0rCnTIptjOLM97JwGk8Obj+21i8yuYm3 n1ol2nt+U7cV2iBF3GuMWRigzcFoO3pbg+BtDHq6KyeVOoyHg3pv0T6Nn7eetmd5RclE pz8INzxDmBq7d5syURizQ+ODGwLzCJOY2dT8i6r2efbdVHsjeYDFqCAo6x/WLEESe6Xl hR5g==
X-Gm-Message-State: AEkoouvYEkgALytSfAE6YfhHQxGjZMFxcjvRiGER4vu6txHytB3f8LVBS8eqYfL/JYipBjDyeextLjpbwleDiQ==
X-Received: by with SMTP id x88mr25440314qtd.24.1470619180368; Sun, 07 Aug 2016 18:19:40 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 7 Aug 2016 18:19:39 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Martin Thomson <>
Date: Mon, 8 Aug 2016 11:19:39 +1000
Message-ID: <>
To: Ilari Liusvaara <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] draft-sullivan-tls-post-handshake-auth-00
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Aug 2016 01:19:42 -0000

On 7 August 2016 at 03:26, Ilari Liusvaara <> wrote:
> Also, how would this be used in applications that need higher-level
> coordination above TLS layer (like HTTP/2)?

The companion h2 draft hasn't been updated, but this will need support
from the application layer to use.  The intent is to take the
structure of draft-bishop-httpbis-http2-additional-certs and remove
the stream 0 components and replace them with this draft.

> Can applications specify and receive the context values used? E.g.
> to act as handles to refer to the resulting authority objects
> (HTTP/2 absolutely needs to be able to refer to client authority).

The API might take one of two forms:
1. an application requests that authentication happen and get the
identifier that TLS uses in return
2. an application requests authentication and specifies the identifier
(the TLS stack will have to verify that this is unique and conforms to
the restrictions)

> Also, are all errors (including things like getting extensions
> wrong or CA wrong) fatal to the whole connection, or how is error
> reporting handled? One can't use alerts for non-fatal reports.

Good question.  Errors in encoding or otherwise problems following the
rules in the spec should result in a connection-level fatal error.
But if the certificate isn't trusted, handling that will be up to the

> Also, are applications expected to be able to specify exactly
> where in stream to put an authentication (response)? Especially
> so they can immediately follow with appdata coordinating the
> usage.

Not sure where you are going here.