IETF Logo Mail Archive

Re: [TLS] Summary of discussion regarding spontaneuous authentication

Martin Thomson <martin.thomson@gmail.com> Mon, 27 October 2014 23:05 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681881A1B8D for <tls@ietfa.amsl.com>; Mon, 27 Oct 2014 16:05:39 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4AkFk1slEDj for <tls@ietfa.amsl.com>; Mon, 27 Oct 2014 16:05:36 -0700 (PDT)
Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0D91A6EF4 for <tls@ietf.org>; Mon, 27 Oct 2014 16:03:50 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id gf13so444402lab.31 for <tls@ietf.org>; Mon, 27 Oct 2014 16:03:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZK2pBefBwbUSJjybDr3xaa3Rs/vXX2l2QTmSLmJZOdo=; b=HefkWqJ56ifWaAQDHluvQXs/pzOrhO7xxH46lJ42q9+tPpU9lqRRKyA5Sdd5pTe+mY wvs3Dnb972U9ui8YFQzHCOnf09fN7QR0qAeC0stKDfdsi22Aw/fEYcNxRvftnNHprSjY q6mkdWPlu77YqWfvrC29axTQr8Z00E/Giz3z6X0RENBVVHGCfL5gA9uSPep2FAtcVdkV sPzf9WWyxwJfG02GttenkTxqNKIFpBMGUXtGMwvg3Mnyw20X641oK9Lhg5cxaSWngEpc BPziyRM1FUHjZdMI/yhNj0UNunNpZCR8h47eBJ3RIJfvf8nr39wBDsb8RzIshFj3kM+P 9y1g==
MIME-Version: 1.0
X-Received: by 10.152.120.199 with SMTP id le7mr26533719lab.67.1414451028669; Mon, 27 Oct 2014 16:03:48 -0700 (PDT)
Received: by 10.25.215.217 with HTTP; Mon, 27 Oct 2014 16:03:48 -0700 (PDT)
In-Reply-To: <CABcZeBNvtOi9UuQGdbuxvPGqZqRx+ZCw9CvMp830Dpq47WwxVg@mail.gmail.com>
References: <CABkgnnUAhEV=wLZyTew=ne7VgSq50XYR3Fo5EfjNXc8=_hbpyg@mail.gmail.com> <CABkgnnXAk+HU2yaUJdOQ0w-heHwYrPK6Zf3HrH5tU+2Tk7_cCA@mail.gmail.com> <20141022125359.GA18704@LK-Perkele-VII> <CABkgnnW=aVzsi+cq=icpn4z9PjFuoiu_LQz_mnfeyPPom6LROQ@mail.gmail.com> <20141022132623.GA19894@LK-Perkele-VII> <CABkgnnVe3T56ia-bxgqNrpF_vXQD=T7xisrZb0Szu+L1X05+NQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C4F98@USMBX1.msg.corp.akamai.com> <CABcZeBNvtOi9UuQGdbuxvPGqZqRx+ZCw9CvMp830Dpq47WwxVg@mail.gmail.com>
Date: Mon, 27 Oct 2014 16:03:48 -0700
Message-ID: <CABkgnnXRA7SnnyiBmae1dSv1GBHPfne+Hz2h=JZT0DLgiXs+gg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/v70pZ8eR62uQhPGyc9TTsqYGPfk
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Summary of discussion regarding spontaneuous authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Oct 2014 23:05:39 -0000

On 27 October 2014 15:07, Eric Rescorla <ekr@rtfm.com> wrote:
> If we make this change, we could still leave CertificateRequest in place,
> but
> it could be empty, just indicating that the server wants some kind of client
> auth and let the client decide. We might also allow the client to say that
> he is going to provide it and let the server say OK, to match MT's CANT
> draft. The point is that this would leave us with an orthogonal design that
> detached capabilities from requests.


I think that your proposed change makes a lot of sense.  I think that
what I'd like to see is something very definite: either a certificate
is provided, or not.  If Finished is at all at risk (and I think that
it is), then we'll need a clear demarcation point at the end of the
handshake.

Also, as the discussion on Update highlighted, I think that we want
explicit acknowledgment of any attempt to authenticate.  This is only
really relevant for the client, which needs to be able to know that
the server has received credentials (authorization is, of course, a
decision separate from that).

v2.23.0 | Report a Bug | By Email