Re: [Unbearable] comments on draft-ietf-tokbind-tls13-0rtt-01

Nick Harper <nharper@google.com> Wed, 29 March 2017 22:30 UTC

Return-Path: <nharper@google.com>
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B808129573 for <unbearable@ietfa.amsl.com>; Wed, 29 Mar 2017 15:30:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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=google.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 dLbANQrw-7Rd for <unbearable@ietfa.amsl.com>; Wed, 29 Mar 2017 15:30:32 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 8DD23129535 for <unbearable@ietf.org>; Wed, 29 Mar 2017 15:30:32 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id i203so20858313ywc.3 for <unbearable@ietf.org>; Wed, 29 Mar 2017 15:30:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aTlY+Nh5YWJHYAiUYEFLeQXW9+HF/APFWDqnaINq+2Q=; b=p5QU+YwQRHfpchxAMkGqBPSnSnHH/rC/z35kEzAMP3FGkfEj3uphCoPwHcHKuLgeCl 8XZwSRx44tTmdwwEYcwNX1dDbGL+YxY1FGokexrp0LBWIwGEHo4qgWZsyfYLpF04ZA7T 6m7EHwdb1oLjIb6fMbBakjG6kgHNJY5pttKHYVhA7xx9YuYLJUXJ7Rjyeebs+irQTf4/ yopPSZkXnir+O88fC0Y8XfKa4WaFB3GSSZcmW545RXyotTJHJuQ4gw4O4z805dwfF90D NOmgbUB9QBqW2O42kaBcF45EJEfMFMKcQFFWPoyssWl1Gr+u2XPwwq4U/KPgMxw4gMfI ETsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aTlY+Nh5YWJHYAiUYEFLeQXW9+HF/APFWDqnaINq+2Q=; b=qO/cdg5gE9ljbj16/ARjuQFT4BKUPVEmPFmc/5j+1xsdaGD/2zNmWzHMPG5YIsbLt3 HkXnyg2NBWKHsqcpYMq93JrhjbMttW8ApwNTMTxpjMJ0m9iyIjZ7lCp4R452UUwM7Bb+ kgglDC42EsQAARDn3qfFgTPCwfip2HbAVjcXpebTpcMSLclKS8q6KqUre5JyamssOl1+ Dms6Pp8+KD/9neqidUSLWEWmSlLyv7J+F5Nt6Th8/8eMiWiayJtYcWTfOji7JG1E8/4V tu3922TQNa3wKzofNCjMgvmpuhBzmYTTP1Gso2U6odwRWyHYZ1LgzBlE2omz4rH0Qoue PXBQ==
X-Gm-Message-State: AFeK/H3Zu3HK8PSUT6sj0gpH9PetA7VILyxvvfktEjeNhb9mxFpASKmBLqHmBkFaEL912MTH7/oJq32j5fFMflQv
X-Received: by 10.37.98.80 with SMTP id w77mr3325763ybb.138.1490826631578; Wed, 29 Mar 2017 15:30:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.65.5 with HTTP; Wed, 29 Mar 2017 15:30:11 -0700 (PDT)
In-Reply-To: <CACdeXiKf9QmVKan_EZj6ZooJF=fNaFCmgp2VorO4hgzMZjQznw@mail.gmail.com>
References: <20170329024952.GS30306@kduck.kaduk.org> <CACdeXiKf9QmVKan_EZj6ZooJF=fNaFCmgp2VorO4hgzMZjQznw@mail.gmail.com>
From: Nick Harper <nharper@google.com>
Date: Wed, 29 Mar 2017 15:30:11 -0700
Message-ID: <CACdeXiKnWFyDG5NhanhpWP43aBidkL+652prs_COUgORExvZxA@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: IETF Tokbind WG <unbearable@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/EOYRsgDqj_VSVu5R7i70B5Av-Us>
Subject: Re: [Unbearable] comments on draft-ietf-tokbind-tls13-0rtt-01
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Mar 2017 22:30:34 -0000

Are the concerns around external PSKs based on how they are
provisioned, or them being used without (EC)DHE?

I see 4 possible combinations: (PSK from a NewSessionTicket,
externally provisioned PSK)x(ECDHE key exchange, pure PSK), all of
which have different security considerations. I'd be fine limiting
this to just NewSessionTicket PSKs used with ECDHE key exchange.

On Wed, Mar 29, 2017 at 2:10 PM, Nick Harper <nharper@google.com> wrote:
> Thanks for your comments. Replies inline:
>
> On Tue, Mar 28, 2017 at 7:49 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
>> We appear to have a rather tight dependency between this document
>> and the core TLS 1.3 spec in section 2.2.1, where we require the
>> server to MUST NOT accept early data if the negotiated token binding
>> key parameter does not match teh parameter from the initial
>> connection, which is the same behavior as ALPN and SNI.  It seems
>> like this might require the formal "Updates: <TLS 1.3>" absent a
>> change to the TLS 1.3 document in the current state of the document,
>> since we only have a token_binding_replay_indication TLS extension,
>> which does not match up exactly with this requirement.  However, if
>> we went to a new TLS extension to indicate willingness to do 0-RTT
>> and token binding together (in addition to the existing early_data
>> and token binding extensions), that seems like it would not need the
>> formal "Updates:" marker.  (Ekr, can you check me on that?)
>
> The core TLS 1.3 spec also requires that any new extensions MUST
> define their interaction with 0-RTT (section 4.2.8). Assuming that TLS
> 1.3 is published before TBNEGO, I think TBNEGO would define an initial
> interaction (e.g. forbidding the combination of TB and 0-RTT), it
> would possibly update TLS 1.3, and this draft would update TBNEGO to
> redefine the interaction with 0-RTT. I'm removing the
> token_binding_replay_indication TLS extension, so that shouldn't
> matter.
>
> I'm leaning towards defining a new TLS extension for indicating
> support of TB and 0-RTT on the same connection. It would be nice to
> know more of the rules for when the "Updates: " marker is needed.
>>
>> Given the semantics of early data with external PSKs, I find it
>> rather dangerous to allow token binding in such setups, and would
>> prefer that we forbid it rather than just saying that the token
>> binding parameters must be provisioned along with the PSK.  (Does
>> anyone have a use case in mind for this?)
>
> I don't have a use-case in mind for Token Binding in early data with
> external PSKs, and would be fine with forbidding that combination.
>>
>> I think the last sentence of the second paragraph of section 3
>> should probably be more explictily scoped to clarify that it is
>> attempting to support 0-RTT that is problematic; the software for
>> one.example.com can support 0-RTT but not use it for that domain, in
>> which case sharing the cert for h2 is fine.
>
> That paragraph is already making assumptions about how h2 interacts
> with 0-RTT TLS 1.3 (which isn't specified). Specifically, it is
> assuming that both one.example.com and two.example.com support 0-RTT,
> and that requests for both domains could get coalesced onto a single
> connection in early data. (This is a lot to assume, and may be
> incorrect. A draft describing how to use h2 over 0-RTT TLS 1.3
> connections might be useful.) The problem is that two.example.com
> could receive a request with a 0-RTT Token Binding message and bound
> token, when two.example.com only expects Token Binding as specified in
> TBPROTO, and doesn't know how to handle that 0-RTT Token Binding
> message. I think it's fine for two.example.com to serve a cert with
> both one and two in its SAN, but not the other way around. I will work
> on clarifying and expanding the language in this section.
>>
>> I'm not sure that I believe the text in section 5.4 that claims that
>> when a peer implements complete replay protection, the other peer
>> does not need to implement such a mitigation; it seems to ignore the
>> possibility that the first peer could become compromised.
>
> I think the logic here was that if one peer does something that
> guarantees that a message can't be replayed, then even if the other
> peer is compromised and tries to replay a message, the first peer will
> prevent the replay from happening. Of course, this has no indication
> whether the first message was legitimate.
>>
>> I made a note that there should probably be more consideration of
>> external PSKs in the second paragraph of section 5.1 and in section
>> 5.5.
>
> Hopefully we can remove support for external PSKs and this point will
> be moot. If we don't, I agree there should be more consideration
> given, as I haven't given it much thought yet.
>>
>> -Ben
>>
>> _______________________________________________
>> Unbearable mailing list
>> Unbearable@ietf.org
>> https://www.ietf.org/mailman/listinfo/unbearable