IETF Logo Mail Archive

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

Nick Sullivan <nicholas.sullivan@gmail.com> Wed, 17 August 2016 21:50 UTC

Return-Path: <nicholas.sullivan@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BD812D0E5 for <tls@ietfa.amsl.com>; Wed, 17 Aug 2016 14:50:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytc2c6l68zse for <tls@ietfa.amsl.com>; Wed, 17 Aug 2016 14:50:48 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 A93A012D7C0 for <TLS@ietf.org>; Wed, 17 Aug 2016 14:50:43 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id f6so3546220ith.0 for <TLS@ietf.org>; Wed, 17 Aug 2016 14:50:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MTvNbKMRvLM41pbIw4TXG3w09RVw12bEBMYNes8Ed1o=; b=qLEDiFA7OViPu3bVG7MzSAVH5UFLvdKyOXVaqVGknlQHdAm7FJQ61KDa3u3Zedpqtd KbUmD95hQyZFQlDOK6nVFF+uEaCkhpUBDuCC5eQR24Ig8Mn5u4sss53Je5lvLRPI+ITB kSO5OWq6PIm5qstPkqzgDtx2dLzRrOsfA5Uo2jCuh3qtWbAERPGDMEAddRwaC6XkrVPq Mr6duNc4h9uUcKM+DHBQgX7V8VADtpjJDd9NcVwhm4RDfEMC+qyU+1jTTOEx1MdD2841 98+pqMiGQt722YPlAGZLRJzytrEqcdlgqgXx/QfTzeeoRZ4JcWaJzPULFrq5IeY4jA59 9EAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MTvNbKMRvLM41pbIw4TXG3w09RVw12bEBMYNes8Ed1o=; b=mOFwQqZc9vgmNPcNTpYI2Nz6XwNqIB9Jp/5GrEBp4Ia6VBd3FhKgFXUzh0buexckqM RquRfCYMwNKbXz02Cu0sG66SufQeNmKORTrGG0nCfmD3a6mw3naJbZOtbU1i7G2jmSfF FMSb5/Y51i5gIb5ng8NMEikOdT20iIVagAGiji7n8d5HCLzWCkfulKDqeYRg6NBrSRvt rUNMnArCOrjjT147LrLLPTVfqulMS9X7EW7UYn1KINwG6CS6IGy/QSsmxrEWtp11d29A ZeH5tBQ9ZWu8JWdCJRmargLbWjiO86vQAGsiHMIlyGwkEG09Ca6/+4DMJKcSTocv6s2F rg6A==
X-Gm-Message-State: AEkoouvCPpC5BUFZd+WUr4+oy9H0AMLH9AQy3V5IC4EwYmxZt8M8bOQpl01XhFHwRPJ9vreJJp/NVJjVIHcuKQ==
X-Received: by 10.36.139.129 with SMTP id g123mr22914613ite.0.1471470642995; Wed, 17 Aug 2016 14:50:42 -0700 (PDT)
MIME-Version: 1.0
References: <CAOjisRyH6Fz-_FbOaE7gMK-WXQetP=R6hJwAevRdsMYVBv95uw@mail.gmail.com> <20160806172605.fqgtphnurlqzxfpo@LK-Perkele-V2.elisa-laajakaista.fi> <CABkgnnXOwS9Tgx06x3q99R2nU2TRR5aCo9oSPn21mTvTOtqpCQ@mail.gmail.com> <20160808061413.ylqaytfxxckted4j@LK-Perkele-V2.elisa-laajakaista.fi> <CABkgnnUG9tS-KfNUBoZU8jeyih9j2xrHxTqds73vCNr93bFnYg@mail.gmail.com>
In-Reply-To: <CABkgnnUG9tS-KfNUBoZU8jeyih9j2xrHxTqds73vCNr93bFnYg@mail.gmail.com>
From: Nick Sullivan <nicholas.sullivan@gmail.com>
Date: Wed, 17 Aug 2016 21:50:32 +0000
Message-ID: <CAOjisRxLqoCS8P5pZo=OL1TjbTbhFWsc4xfJbPeer9muyP94ng@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>, Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary="94eb2c04b39af92aa8053a4b7424"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/W8e8CseZJVtIruosupOHKssbuTY>
Cc: "tls@ietf.org" <TLS@ietf.org>
Subject: Re: [TLS] draft-sullivan-tls-post-handshake-auth-00
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Wed, 17 Aug 2016 21:50:51 -0000

Is there any support for either of the following ideas:

1) moving the OCSP and SCT server extensions to inside the Certificate
message
2) removing post-handshake client authentication from TLS 1.3 in favor of
dedicated and more detailed draft



On Sun, Aug 7, 2016 at 11:42 PM Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 8 August 2016 at 16:14, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
> > In 2, I would imagine the context is probably usually a sequence
> > number of some kind.
>
> The draft defines some rules for construction of identifiers that
> prevent collisions and the like.
>
> >> 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
> >> application.
> >
> > And that should presumably be communicated somehow...
>
> Of course.  See
> https://github.com/grittygrease/tls13-post-handshake-auth/issues/18
> (feel free to contribute)
>
> > Being able for application to to wait for certificate/cv/finised
> > message to be sent, so it can do something special in application
> > layer immediately after that.
>
> Sure.  The usual async API guarantees apply here; I don't know that
> this needs special treatment in the spec though.  If you disagree, I'm
> sure that my coauthors would be happy to take suggestions for
> improvements.
>

v2.23.0 | Report a Bug | By Email