IETF Logo Mail Archive

Re: [TLS] handling of duplication of extensions between ServerHello and EncryptedExtensions

David Benjamin <davidben@chromium.org> Fri, 02 September 2016 19:21 UTC

Return-Path: <davidben@google.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 5E1B412D1CA for <tls@ietfa.amsl.com>; Fri, 2 Sep 2016 12:21:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.247
X-Spam-Level:
X-Spam-Status: No, score=-3.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 FNRZk1pfJdhd for <tls@ietfa.amsl.com>; Fri, 2 Sep 2016 12:21:21 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 78FA612B029 for <tls@ietf.org>; Fri, 2 Sep 2016 12:21:21 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id i184so55295201itf.1 for <tls@ietf.org>; Fri, 02 Sep 2016 12:21:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=xSAeakH5PDxuObAwWRUBc3PkOw24HaGCfEUcEnngHaE=; b=i3nYlUVlqHt266AqMVnLT64EY4P/X8HZge3FV9bLcYi3wtFmBmA9cLEoIK2Tv8/6i+ U5d6KzatVD7ggrd+R60aqve4sdbbsx7UdtsId5JLr3dwK8b0EFlad+UKnSdPsPa1plNE 54yPHRwzIqxCEkvcJrRtxFfWI1vh1FYlMt8LM=
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; bh=xSAeakH5PDxuObAwWRUBc3PkOw24HaGCfEUcEnngHaE=; b=aFrBUF1O89Y+AEIlQkaDbrh4TRvyiI7o9LMJWBkKVbLyh+iiJufjRRT+SqiBxQxt2q g3qpoDilQ7JqNRRR51oLIYXIyLCHjlqYaVAn2086hS3PlcQxoBC/ITQT+XldYYXEXBII w2t9iDLz2R4n0KnS18UaT7BQSfYXKpB3/McFV5CRkhXaRQhs7oGM4rk2iqOlCKpb9q5X 3EE87TsxyQnYqiGxMBRz6g4/cBGScCrzs1MoFNdY6QtNEnR+DIRLhrvmK48IsNVJQurm ZKfuyYAAw4obeTi/NWX9unwFqEQnsxX5x32qmJcEmoyloONP+wugBMvBooLkvZI48TS1 MrtQ==
X-Gm-Message-State: AE9vXwPty2qoU19YFBzWcOlcPCPlJMEIH/GB0ha4afNbCw3xSNJ1asvSfdZWYifiufQTxmzmvWMfmNiDiR01aLg8
X-Received: by 10.36.200.134 with SMTP id w128mr7360345itf.92.1472844080740; Fri, 02 Sep 2016 12:21:20 -0700 (PDT)
MIME-Version: 1.0
References: <2847810.DkTLEJYpS7@pintsize.usersys.redhat.com>
In-Reply-To: <2847810.DkTLEJYpS7@pintsize.usersys.redhat.com>
From: David Benjamin <davidben@chromium.org>
Date: Fri, 02 Sep 2016 19:21:10 +0000
Message-ID: <CAF8qwaCg6NkDNJ0x5g=67MVwTMj++ku=g-hvgS+R24u5ifqAFA@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0579783e6d65053b8b3cd1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/movA1UJ4YhhFxNzajURpb5hGSSI>
Subject: Re: [TLS] handling of duplication of extensions between ServerHello and EncryptedExtensions
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: Fri, 02 Sep 2016 19:21:23 -0000

Huh. I agree that text is weird. We should probably remove it. I think we
actually get something akin to what you suggest basically implicitly:

Servers aren't allowed to send unsolicited extensions, so your SH and EE
parsers should be rejecting any unknown extensions. If you combine that
with not accepting known extensions in the wrong context (unencrypted ALPN
or encrypted key_share) since extensions already specify which messages
they may live in, this all works out.

So even if we explicitly say this rule, I don't think reflecting it in code
is the cleanest implementation strategy. (It requires one keep a list of SH
extensions and compare against it.) It might be better to say that
extensions in unexpected contexts should be rejected like any other
unexpected extension.

David


On Fri, Sep 2, 2016 at 1:31 PM Hubert Kario <hkario@redhat.com> wrote:

> So, the draft has following text:
>
>     The same extension types MUST NOT appear in both the ServerHello and
>     EncryptedExtensions.  If the same extension appears in both locations,
>     the client MUST rely only on the value in the EncryptedExtensions
>     block.
>
> if the extension "MUST NOT" be in both ServerHello and EncryptedExtensions,
> why the client should continue with the handshake if a server makes such a
> major mistake? Why aborting the connection in such situation isn't safer?
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech
> Republic_______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.15.0 | Report a Bug | By Email