Re: [TLS] draft-ietf-tls-tls13-15

David Benjamin <> Thu, 18 August 2016 15:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 40D1E12DF6C for <>; Thu, 18 Aug 2016 08:00:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.946
X-Spam-Status: No, score=-3.946 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=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iTvjR5Pmzmm5 for <>; Thu, 18 Aug 2016 08:00:22 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6312212DF67 for <>; Thu, 18 Aug 2016 08:00:22 -0700 (PDT)
Received: by with SMTP id e63so2277731ith.1 for <>; Thu, 18 Aug 2016 08:00:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iRA+zlg4wJK7ohR1PFyRVYcT01Bv9VV+soVnFSILqLc=; b=H3IdVhBG3RcrhSHo0mFGS3Fq0qU23S/F/kBAHQzU7/NcLB7iVwNRlHWkR3TFsMvwbP tIJF340qIbQD1zjubOna2yMJC6CmmgbOvw64m3N4hhDCTG2ZpBW/WB902EZ9B3btopNs IxkKjHIh9rDRo7SuUJkbrPnLe9bEk86HBKkg8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iRA+zlg4wJK7ohR1PFyRVYcT01Bv9VV+soVnFSILqLc=; b=d6zF9eOhcaEdUmaTOA6h5yqxmwtQmTLNO/Nv7Zvz6R7WGwYmsongad2ujVQtJLrSGY MGG552SyZ2a6u+p4XH19euDE6dqYGD28k2sRFy2Z8vJRr4DQqaL+GNc+co2hC/SFpbHq OBxqWw50nPNtC2h2PDsw1GSRwL7M2+KdczqkSu9nWUYl89O2F7y4f/PXaw29pKj2vHGH IZRc6ZcYG82IU+eZBA7U+QbDqbdFjPIJUkXXi0Oa8ncDq40QlRsTbFbeZSwJogXD8+OD z38lGt6eLg+1gudjn4fgquFhJXvXpEAgtxgP5eOTEOAvjmVPyVAPrlcT9hjYKk8IbSVe T9Yw==
X-Gm-Message-State: AEkoouuzRlnfEa+dB2OpTWWEQ7XIM/bEU+xrr7XJAYyEOw5bS585/+Ynr2vAN0n05K9+8Vaw+0nSIE0E/lP9whXB
X-Received: by with SMTP id w128mr3900233itf.92.1471532421706; Thu, 18 Aug 2016 08:00:21 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Thu, 18 Aug 2016 15:00:10 +0000
Message-ID: <>
To: Ilari Liusvaara <>, Eric Rescorla <>
Content-Type: multipart/alternative; boundary=94eb2c05797845cc28053a59d7cc
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] draft-ietf-tls-tls13-15
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Aug 2016 15:00:24 -0000

On Thu, Aug 18, 2016 at 9:35 AM Ilari Liusvaara <>

> > > David Bejamin already posted a PR about that. Doesn't clearly say
> > > that unknown reason handling.
> > >
> >
> > Yeah, I read the list before the PRs. I'll take a look but if you want to
> > comment that would be great.
> The only comment is that I would prefer to allow extensions the without
> client including them in ClientHello[1] (obviously fatal if unknown one is
> seen[2]), instead of special-casing Cookie.

FWIW, I'm not a fan of special-casing Cookie either. I just left it alone
for that PR and only bothered about moving to an extension since I wasn't
sure how it should work.

Just removing the requirement altogether seems reasonable? Although it
doesn't give much guidance on which are and aren't MTI. Is a TLS client
over TCP obligated to implement Cookie to avoid interop issues? Seems kind
of pointless to require it there, just more things to remember. Whereas a
DTLS client over UDP which doesn't implement cookie is unlikely to work
well. But probably that kind of guidance ought to live elsewhere anyway. Or
maybe we should just declare cookie MTI everywhere and leave it at that.

(Though, I'm sure, in practice, no one will ever send cookie over TLS and
thus some clients won't honor it.)


> [1] Of course, if the error is related to values in extension, then the
> client had to include it in its ClientHello.
> [2] Basically, if client is told that its ClientHello is wrong in some
> way it does not understand, obviously it can't fix it.