Re: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09

Benjamin Kaduk <kaduk@mit.edu> Mon, 22 July 2019 05:05 UTC

Return-Path: <kaduk@mit.edu>
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 D11EC120163; Sun, 21 Jul 2019 22:05:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 IPrMfjYrbWqC; Sun, 21 Jul 2019 22:05:00 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 DE93112013D; Sun, 21 Jul 2019 22:04:59 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6M54q8e009951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Jul 2019 01:04:54 -0400
Date: Mon, 22 Jul 2019 00:04:51 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: secdir@ietf.org, tls@ietf.org
Message-ID: <20190722050451.GU99187@kduck.mit.edu>
References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> <20190721015659.GL23137@kduck.mit.edu> <a5b0c119-b0fb-42e3-8795-9d4cfbda99d3@www.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a5b0c119-b0fb-42e3-8795-9d4cfbda99d3@www.fastmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/DZ0HXU4l4u1w4YnsLJHm34tGdHI>
Subject: Re: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 22 Jul 2019 05:05:02 -0000

It seemed worth copying this to the WG list; sorry for those getting an
extra copy.

-Ben

On Sun, Jul 21, 2019 at 10:26:56AM -0400, Martin Thomson wrote:
> On Sat, Jul 20, 2019, at 21:57, Benjamin Kaduk wrote:
> > > already supported by TLS libraries? Also, are we in effect deprecating this TLS
> > > 1.3 feature because of the security issue of the mismatched record boundaries?
> > 
> > I think in some peoples' minds that would be a good thing, though it's not
> > entirely clear that we are actually doing so.
> 
> This wouldn't deprecate post-HS auth.  It is intended to cover the cases where post-HS auth does not work.  See draft-ietf-httpbis-http2-secondary-certs.
> 
> > > "SHOULD use TLS", change to MUST. There's no way it can work otherwise anyway.
> > 
> > What about QUIC?
> 
> I think that we can safely regard QUIC (at least those versions that use TLS) as TLS.  An informative mention might help avoid any confusion regarding this point.  We might also regard DTLS-SRTP as one such protocol.
> 
> > > * Is
> > > there a requirement for all protocol messages to be sent over a single TLS
> > > connection? If so, please mention it. Certainly this is true for the
> > > Authenticator message that must be sent over a single connection and cannot be
> > > multiplexed by the high-level protocol. I think this protocol actually assumes
> > > "nice" transport properties (no message reorder, reliability) that also require
> > > a single, clean TLS connection.
> > 
> > It seems like we should be more clear about what we do (and do not)
> > require.  Though IIRC we can do separate authenticators in parallel and not
> > require them to be ordered with respect to each other.
> 
> See above regarding DTLS-SRTP.  Being too crisp might constrain usage inappropriately.
> 
> > > * Why no authenticator request for servers?
> > > Don't we care about replay? OTOH if the client wants to detect replays, it
> > > would need to keep state on received authenticators, which would be very messy.
> > 
> > IIUC the thinking is that there's no way to revoke an authenticator for a
> > connection, so replay (if  not detected by another layer anyway) would not
> > cause the authentication state to change.
> 
> Ben is correct.
> 
> > > *  7.1: this is
> > > changing TLS 1.3 by allowing this extension in Cert Request! I think it's a
> > > really bad idea. Better to hack special support to existing libraries, allowing
> > > this specific extension for this special case, than to change the base
> > > protocol. Otherwise, this document should UPDATE 8446.
> > 
> > Or, since extension codepoints are cheap, just use a newcodepoint.
> 
> We might want to discuss this one this week if we can.
>