Re: [TLS] A flags extension

Yoav Nir <ynir.ietf@gmail.com> Sat, 30 March 2019 17:30 UTC

Return-Path: <ynir.ietf@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 C3AB612003E for <tls@ietfa.amsl.com>; Sat, 30 Mar 2019 10:30:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, 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=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 6RVyLx9oXRuE for <tls@ietfa.amsl.com>; Sat, 30 Mar 2019 10:29:58 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 62A9B120013 for <tls@ietf.org>; Sat, 30 Mar 2019 10:29:58 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id r4so6448773wrq.8 for <tls@ietf.org>; Sat, 30 Mar 2019 10:29:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=cVfZnLXx9jNM+P8/XI7KeZVRm0PMPoQYOGSzdnKOJYw=; b=CTI7xp53/JOecq/dLSO7/RFVXsaCCtK/sFJkmJ+3ljreIxOz4kHt8rl6jXnSPz/XTS QlJMwmIO6vYbdfSgJupLA2ixA2gb51tyZ5moX17UfRH0sQraWvK1NAA8YT15KjXUZ12X iEDB0T6Gw636CqC7rxxGCWZVMcKm2MtsjQ+izb4pgPnc+8Hh4EysApncRaSY5Xs6FGui lUod6e9uhuw8/ViOsP2Kg48LiVQ2HZTm3wbsFuTQq8lSr+WFpp3Je1Mkcrgjp5LJ+Tgf om0IBgOJHo36+AVEDXPNmAub6ELSWSsJImKZcBmGQ1We765Emq9rvflUDMKK+ZQFLTIN sb6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=cVfZnLXx9jNM+P8/XI7KeZVRm0PMPoQYOGSzdnKOJYw=; b=oyPywT65hd7pvwc4cdmGVIR/Rh1kfVr7Y9kmYo1jZu7nGIM0UNubYrZ6NvqhyN1ra2 Iu87Yqn3Pa6Wv5z2nWYmYuaAfmuKc/VumLqEL58OXy51pe1xQmabrBkh5xvuEkeU2SWg X2O6jR7pDUP7in+TTppGxZC11z2lDB1r8BwUO01nUFWdUBwF1tqcltiLEDtYtjetyZqG E6BtAXFBMHDi07Yh9AH36tLFzEMxkyMy5Z1oS3MHEF3NUTf8BOlElF3+0ze23ZyB47wo wgStj6w2hG6Jpscfups8TTY8HJqy6/cBUr5SNc3MqsTb5x3t/gl/eeR9O5OlQKB/yO9j tQTg==
X-Gm-Message-State: APjAAAUdNYO3n3qAWwFa4euKdfKclUJVjsJ4BpyPslIlDnxlhP5Xdhay 9C4XFJTQlkTbNGZ/3dkFjO1ZTkNbQzA=
X-Google-Smtp-Source: APXvYqzDsIXwY439wzM8MZNcZ8qiAmN8uBoSNEdNQagbUCiRBUCQBeV/ONqdgl+drZvKdAHzh7dVgQ==
X-Received: by 2002:adf:f110:: with SMTP id r16mr30831303wro.153.1553966996922; Sat, 30 Mar 2019 10:29:56 -0700 (PDT)
Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id y1sm16044175wrd.34.2019.03.30.10.29.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Mar 2019 10:29:55 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <005EAA50-5E7B-419F-B9F1-18EDD8E2D441@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3E762E1B-114F-434B-8883-F5B8FFBDD75A"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Sat, 30 Mar 2019 20:29:47 +0300
In-Reply-To: <6b114845-b819-4eec-94cd-17c1dd88d092@www.fastmail.com>
Cc: tls@ietf.org
To: Martin Thomson <mt@lowentropy.net>
References: <FA7952BB-8BB9-498E-9C7B-E4CF7DB2DB25@ericsson.com> <6b114845-b819-4eec-94cd-17c1dd88d092@www.fastmail.com>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/jb1fmxEfCAH-OJlrdXcYLj7L4FA>
Subject: Re: [TLS] A flags extension
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: Sat, 30 Mar 2019 17:30:01 -0000

I think I only allow the server to set bits that had been set by the client.

   A server that supports this extension and also supports at least one
   of the flag-type features that use this extension and that were
   declared by the ClientHello extension SHALL send this extension with
   the intersection of the flags it supports with the flags declared by
   the client.


> On 29 Mar 2019, at 22:30, Martin Thomson <mt@lowentropy.net> wrote:
> 
> In addition to this, the document would seem to allow a server to set bit k if the client did not set that bit. (Or more generally, the responder can set bits the initiator did not set. )
> 
> In fitting with the TLS model, I would recommend allowing a responder to set only bits that the initiator sets. Other bits being set would be an error. 
> 
> On Fri, Mar 29, 2019, at 19:59, John Mattsson wrote:
>> Hi,
>> 
>> The document only talks about use in ClientHello, ServerHello, and 
>> EncryptedExtensions. I think it should also discuss usage in 
>> CertificateRequest, Certificate from the server, and Certificate from 
>> the client. It should likely be left to the document that specifies a 
>> specific feature to determine where it can be used. 
>> draft-thomson-tls-sic-00 uses the tls_flags extension in 
>> CertificateRequest.
>> 
>> Cheers,
>> John
>> 
>> 
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls