Re: [TLS] draft-davidben-tls-grease-01
Hubert Kario <hkario@redhat.com> Mon, 05 September 2016 14:59 UTC
Return-Path: <hkario@redhat.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 386DE12B237 for <tls@ietfa.amsl.com>; Mon, 5 Sep 2016 07:59:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.41
X-Spam-Level:
X-Spam-Status: No, score=-8.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-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 dleuzXxI8OWD for <tls@ietfa.amsl.com>; Mon, 5 Sep 2016 07:59:26 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76FC012B21C for <tls@ietf.org>; Mon, 5 Sep 2016 07:59:26 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 35FD1C04B31F; Mon, 5 Sep 2016 14:59:26 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-191.brq.redhat.com [10.34.0.191]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u85ExOYe009042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Sep 2016 10:59:25 -0400
From: Hubert Kario <hkario@redhat.com>
To: David Benjamin <davidben@chromium.org>
Date: Mon, 05 Sep 2016 16:59:23 +0200
Message-ID: <1628702.M7tlMkopkf@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.7.2-201.fc24.x86_64; KDE/5.25.0; x86_64; ; )
In-Reply-To: <CAF8qwaBkNeiY25Rb4ZoBoPvsFP790hoXAMNHOCktMKsTJGa5WQ@mail.gmail.com>
References: <CAF8qwaCaW2Q+z_JoDqzQZaGCWJ2aqUiyK8_J8_CO4Ck_cqtaSA@mail.gmail.com> <8143099.xajr1xgLIA@pintsize.usersys.redhat.com> <CAF8qwaBkNeiY25Rb4ZoBoPvsFP790hoXAMNHOCktMKsTJGa5WQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart4375750.lD0BLZNFex"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Mon, 05 Sep 2016 14:59:26 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/8PokqLhMHJG5I8ACkBD3KDNxJUY>
Cc: tls@ietf.org
Subject: Re: [TLS] draft-davidben-tls-grease-01
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: Mon, 05 Sep 2016 14:59:28 -0000
On Monday, 5 September 2016 14:48:55 CEST David Benjamin wrote: > On Mon, Sep 5, 2016 at 7:07 AM Hubert Kario <hkario@redhat.com> wrote: > > On Friday, 2 September 2016 18:53:45 CEST David Benjamin wrote: > > > I've finally gotten to uploading > > > https://tools.ietf.org/html/draft-davidben-tls-grease-01 which hopefully > > > resolves the procedural issues (thanks again!). I've also revised the > > Clients MUST reject GREASE values when negotiated by the server. > > When processing a ServerHello containing a GREASE value in the > > ServerHello.cipher_suite or ServerHello.extensions fields, the client > > MUST fail the connection. When processing an ECParameters structure > > with a GREASE value in the ECParameter.namedcurve field, the client > > MUST fail the connection. > > > > Note that this requires no special processing on the client. Clients > > are already required to reject unknown values selected by the server. > > > > Don't the other RFCs just say that clients should reject values not > > advertised > > by client? Since GREASE values are advertised by clients, I don't think > > the > > "no special processing" applies. As such, handling how connections in > > which > > server selects GREASE values should be specified precisely. > > (I haven't checked the RFCs for that so I may be mistaken, but still is a > > bit > > dicey to say that programmers don't need to check error handling in their > > code...) > > Right. That's why this one says "no special processing" rather than > "restatements or corollaries of existing [client] requirements" as in the > server section. In the implementation I've tossed together, this never > makes it into the list of values the client believes it has advertised. The > serialization code just adds some u16s without remembering them anywhere. > As a result, all the existing logic works just fine. On the other hand, the implementation I work on keeps the sent Client Hello on hand and checks the server response against the exact values it sent. So for it, server selecting GREASE value would be fine, it would fail at key exchange processing time. Keeping the Client Hello in case server asks for certificate verification is not entirely unheard of either. So I think it's best to keep the specification implementation agnostic, without any assumptions about how the code is written, and describe just the externally visible behaviour. But describe it fully. -- 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
- Re: [TLS] Keeping TLS extension points working Hubert Kario
- [TLS] Keeping TLS extension points working David Benjamin
- Re: [TLS] Keeping TLS extension points working David Benjamin
- Re: [TLS] Keeping TLS extension points working Viktor Dukhovni
- Re: [TLS] Keeping TLS extension points working David Benjamin
- Re: [TLS] Keeping TLS extension points working David Benjamin
- Re: [TLS] Keeping TLS extension points working Hubert Kario
- Re: [TLS] Keeping TLS extension points working Geoffrey Keating
- Re: [TLS] Keeping TLS extension points working Raja ashok
- Re: [TLS] Keeping TLS extension points working David Benjamin
- Re: [TLS] Keeping TLS extension points working Raja ashok
- Re: [TLS] Keeping TLS extension points working David Benjamin
- Re: [TLS] Keeping TLS extension points working Steven Valdez
- Re: [TLS] Keeping TLS extension points working Hubert Kario
- Re: [TLS] Keeping TLS extension points working Watson Ladd
- Re: [TLS] Keeping TLS extension points working Sean Turner
- Re: [TLS] Keeping TLS extension points working Adam Langley
- Re: [TLS] Keeping TLS extension points working Wan-Teh Chang
- Re: [TLS] Keeping TLS extension points working David Benjamin
- Re: [TLS] Keeping TLS extension points working Sean Turner
- Re: [TLS] Keeping TLS extension points working Hubert Kario
- Re: [TLS] Keeping TLS extension points working David Benjamin
- [TLS] draft-davidben-tls-grease-01 Hubert Kario
- Re: [TLS] draft-davidben-tls-grease-01 David Benjamin
- Re: [TLS] draft-davidben-tls-grease-01 Hubert Kario
- Re: [TLS] draft-davidben-tls-grease-01 David Benjamin
- Re: [TLS] draft-davidben-tls-grease-01 Hubert Kario