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

"Martin Thomson" <mt@lowentropy.net> Thu, 10 October 2019 01:26 UTC

Return-Path: <mt@lowentropy.net>
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 C5352120044 for <tls@ietfa.amsl.com>; Wed, 9 Oct 2019 18:26:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=Anb2rW4R; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IQY0rHr8
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 kbf7tWIQOwm8 for <tls@ietfa.amsl.com>; Wed, 9 Oct 2019 18:26:33 -0700 (PDT)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEF6C120020 for <tls@ietf.org>; Wed, 9 Oct 2019 18:26:33 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 06FA8601 for <tls@ietf.org>; Wed, 9 Oct 2019 21:26:32 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 09 Oct 2019 21:26:33 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=uB+uDpkmxaQLisE2mEDxpaCpp/T0Rwu jiyWe3KL+6PE=; b=Anb2rW4RmOAMRZdop4aCePZNjADQR1tiCTuwvOlu6Qo4KY1 z5kaMrAwkY+Di44abMRaV8qLfHKY5MQd/U6YOkM6pUfFAKfkMwz+vYn0IMHCdaIH OvJTxOsPk5oX0xQ14WaOzNl8BDtkmZcYCfCzTSlhP1kk8vaJE+sX775LNtUYhTg9 GYfoZ17g0DcfAeLSXkinqt6jDeLjcOAOpmDxNxju4XGCSq9rRufVP5aWvJuV42RJ 9v3TC4teR3A2o+rRYcqJhbu1ykHOXpjsA/vKBqKuFCZIpzFIV1fw/YwWpo3u2/DP doK8D1lBGKYvVERZ0Wju2b5SNsdZ6oNv4f/DvBA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=uB+uDp kmxaQLisE2mEDxpaCpp/T0RwujiyWe3KL+6PE=; b=IQY0rHr8L/kyssuo7dJEBp wkyaYHUci6g/13UzryLdnNFhKGnptBv3o5Da3tPullXBDsw5ieEe+unVG3f9Y4+Q 8Q4nx6VmXj5CpZDn0CZGiUu0j4iiFmqQovqHfupoTbye60u8i/jJJepnnMsHl5b1 WXio6U+UoKBLP0w+YrKKuT9OXKuBRU2ZjlhOm4wRlTZ4o0Hu4EFck5ORdblq/wi7 E9WAHI9VKTzA+ZN3mPMu8ALIImaWJMskWIon6HPJ1d9rYGMnM0FytCiqNNY+xdnK 6r3dbiKKLZpOyFApcq8IlUnRvWdj0k4oFHuIGm4RHnKW5Iyk1QUR/XEWQXNQP+sQ ==
X-ME-Sender: <xms:yIieXcd6LlY3-mUNcOuV0-DBCukleLTWWMarhWm1h-9P1mLDv1fMEg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedriedvgdegkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvth hfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophih rdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:yIieXScGstbLNhEjFTST6VBYbAyWF8vEWPG6hwVhtsfPwLnMQtgwVw> <xmx:yIieXYiV8ppT9hT5tZy51g5opCGtIZKOgrg1iuf2RLTeKAQAEupeeA> <xmx:yIieXWTkAMSJZo1vw7n-iHgXiZKW0UKhVdSUTxBiYgBAhX1jIgsZJA> <xmx:yIieXSG3Rhtr2FtjAuQ_FfvZydSwseD7so363mcWVyYeiPB5b5-wpg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2A097E00A5; Wed, 9 Oct 2019 21:26:32 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2
Mime-Version: 1.0
Message-Id: <0cf4806b-3825-4d25-8be0-13c27533b08d@www.fastmail.com>
In-Reply-To: <CAFDDyk-T_+RHDwEJ+8AQFTvZKykPxwd+A5+8xiZp22bOs48S8w@mail.gmail.com>
References: <156249708979.14501.13745976049183757305@ietfa.amsl.com> <CAFDDyk8iG0R2rT7x-t7fHkFxcYBBkf8j1-mg1xbexoh8gXts6A@mail.gmail.com> <7BDE969A-7B5F-4979-B4E9-7E6C03C0A1B1@ericsson.com> <CAFDDyk_yoOu01nBPrBj_AVBugFRGUCOthYDysOuAGCrKNWG8dg@mail.gmail.com> <57E5EB36-6A59-45A7-A2F4-1E1626391742@ericsson.com> <CAFDDyk-T_+RHDwEJ+8AQFTvZKykPxwd+A5+8xiZp22bOs48S8w@mail.gmail.com>
Date: Thu, 10 Oct 2019 12:26:11 +1100
From: "Martin Thomson" <mt@lowentropy.net>
To: tls@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/XIoLJeWCteMQDK_9_12PJaib3lI>
Subject: Re: [TLS] =?utf-8?q?Genart_last_call_review_of_draft-ietf-tls-export?= =?utf-8?q?ed-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: Thu, 10 Oct 2019 01:26:36 -0000

I think that the DTLS thing doesn't require as much rewriting as observed.  Just say that when you say "TLS" you mean "TLS or DTLS" somewhere up front.

As to what a transport needs to provide, I think that there is no real text to add regarding DTLS.  You *could* say that as the application protocol is responsible for carrying the messages, might find that using a DTLS connection introduces new problems.  Specially, these are big messages and they are likely to require fragmentation and reassembly if DTLS is used.  Also, if the protocol depends on these messages being reliably delivered, it will want to provide some sort of loss recovery mechanism.

On Thu, Oct 10, 2019, at 11:47, Nick Sullivan wrote:
> Thanks again for your review! The PR is on Github 
> (https://github.com/tlswg/tls-exported-authenticator/pull/50) and will 
> be incorporated into a new version of the document that addresses both 
> your comments and those by Yaron Sheffer.
> 
> On Thu, Sep 19, 2019 at 11:29 PM Christer Holmberg 
> <christer.holmberg@ericsson.com>; wrote:
> > Hi,
> > 
> >  >Some answers to your questions inline. I'm not sure further changes along the lines suggested here are needed, but I'm open to arguments that point in that direction.
> > 
> >  I am mostly fine with your answers. Just a couple of comments inline still.
> > 
> >  ---
> > 
> >  MIN_2:
> > 
> >  >>>> Can the mechanism be used also for DTLS?
> >  >>>
> >  >>> I think the answer is yes. I don't see any reason to disallow the use of Exported Authenticators in DTLS.
> >  >>
> >  >> Would it be useful to clarify that?
> >  > 
> >  > Going through what the modified text would look like, it seems like a substantial amount of re-writing (even the title!) for what amounts to an unclear use case. 
> >  > Keeping in mind that DTLS 1.3 hasn't been finalized and doesn't directly define exporters, I'm disinclined to define how EAs would work with DTLS. If someone 
> >  > has a strong use case for EA in DTLS, it may be worth considering it. 
> > 
> >  Would it then be useful with a statement saying that it might be possible to use exporters also with DTLS, but that such usage is outside the scope of the document and needs to be specified in a separate document?
> 
> I added a line to this effect.
> > 
> >  ---
> > 
> >  MIN_3:
> > 
> >  >>>> The documents talk about additional certificates. If I only have one additional
> >  >>>> certificate, can I use that for multiple authenticators throughout the TLS
> >  >>>> session?
> >  >>>
> >  >>> Yes, there is nothing disallowing the creation of multiple exported authenticators with the same certificate.
> >  >>
> >  >> Would it be useful to clarify that?
> >  >
> >  > I'm not convinced this is a realistic use case. Since exported authenticators are based on the exporter, there is no inherent ordering. 
> >  > If you re-authenticate with the same certificate, there's nothing asserting freshness of the second certificate. Is there something in 
> >  > the text that suggests that using a certificate multiple times is disallowed? If there's no suggestion that this is not possible that 
> >  > needs to be corrected, I don't see the benefit of calling out this specific use case.
> > 
> >  I don't think there is any text suggesting that it is disallowed. But, if you don't think it is a realistic use case I'll take your word for it :)
> > 
> >  ---
> > 
> >  ED_2:
> > 
> >  >>>> Section 3 says: "The authenticator request is a structured message that can be
> >  >>>> created..." Section 4 says: "The authenticator is a structured message that can
> >  >>>> be exported..."
> >  >>>>
> >  >>>> In the 2nd paragraph of Section 4 it is stated that "authenticator" is sent
> >  >>>> based on an "authenticator request". I wonder if that could be stated already
> >  >>>> in the beginning of Section 4, to further clarify the difference between them.
> >  >>>> E.g.,
> >  >>>>
> >  >>>> "The authenticator is a structured message, triggered by an authenticator
> >  >>>> request, that can be exported from either party of a TLS connection."
> >  >>>
> >  >>> The issue is that servers can generate spontaneous exported authenticators without
> >  >>> an authenticator request. 
> >  >>
> >  >> Where is this written? Did I miss it?
> >  >
> >  > Section 4:
> >  > An authenticator message can be constructed by either the client or
> >  > the server given an established TLS connection, a certificate, and a
> >  > corresponding private key. Clients MUST NOT send an authenticator
> >  > without a preceding authenticator request; for servers an
> >  > authenticator request is optional. For authenticators that do not
> >  > correspond to authenticator requests, the certificate_request_context 
> >  > is chosen by the server.
> > 
> >  Ok. Looks good.
> > 
> >  Regards,
> > 
> >  Christer
> > 
> > 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>