Re: [TLS] comments on draft-ietf-tls-tls13-19

Nikos Mavrogiannopoulos <nmav@redhat.com> Tue, 25 April 2017 09:50 UTC

Return-Path: <nmav@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 04407129C1E for <tls@ietfa.amsl.com>; Tue, 25 Apr 2017 02:50:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.923
X-Spam-Level:
X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 CiYafKMiVIZn for <tls@ietfa.amsl.com>; Tue, 25 Apr 2017 02:50:08 -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 DA0EF126D85 for <tls@ietf.org>; Tue, 25 Apr 2017 02:50:08 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F414D61D04; Tue, 25 Apr 2017 09:50:07 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com F414D61D04
Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=nmav@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com F414D61D04
Received: from dhcp-10-40-1-102.brq.redhat.com (unknown [10.40.2.129]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E2E3D8367A; Tue, 25 Apr 2017 09:50:06 +0000 (UTC)
Message-ID: <1493113805.15667.7.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Ryan Sleevi <ryan-ietftls@sleevi.com>
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>, "tls@ietf.org" <tls@ietf.org>
Date: Tue, 25 Apr 2017 11:50:05 +0200
In-Reply-To: <CAErg=HHNpjp1252Zo5=xjmiwAJN1nHz8pscw2Hg8R7rM7mgfFw@mail.gmail.com>
References: <1490797726.28079.18.camel@redhat.com> <1490797957.28079.20.camel@redhat.com> <CABcZeBMCZrVKM959F3ycKN_WAky2NAZTy9OOetnC+KJAj3L+Pw@mail.gmail.com> <1492786351.14070.2.camel@redhat.com> <CABcZeBOe4-yEW8r15fsOtHJbQrnqGJ6oUaGYjoUwYS0MQE-rHQ@mail.gmail.com> <20170422120017.GA4201@LK-Perkele-V2.elisa-laajakaista.fi> <20170422214205.bxu5whfqzy5kshsw@roeckx.be> <20170423103442.GA16936@LK-Perkele-V2.elisa-laajakaista.fi> <CAErg=HEt9fvL1y2fdcYBPj-0geuMKepvDnPJWK=AJ_omCYMiyA@mail.gmail.com> <1493020692.3390.8.camel@redhat.com> <CAErg=HHNpjp1252Zo5=xjmiwAJN1nHz8pscw2Hg8R7rM7mgfFw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 25 Apr 2017 09:50:08 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YdR0Vk_Xxi1vB1tMXMIM8DpVdyg>
Subject: Re: [TLS] comments on draft-ietf-tls-tls13-19
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 25 Apr 2017 09:50:10 -0000

On Mon, 2017-04-24 at 09:26 -0400, Ryan Sleevi wrote:
> 
> 
> On Mon, Apr 24, 2017 at 3:58 AM, Nikos Mavrogiannopoulos <nmav@redhat
> .com> wrote:
> > That's intentional. 
> 
> And misguided. It violates the layering.

That's a respectable opinion. I disagree.

> > The reason they
> > cannot be expected to do that, is that it is not by way obvious
> > what to
> > do. Ilari's implentation closes the connection, mine sets a limit
> > of 15
> > days, and I guess each and every other one behaves differently. It
> > is
> > the role of the standards to clarify uncertainties for implementers
> > or
> > forbid such options (I'd equally be happy if we have a text that
> > forbids an empty nextUpdate field in OCSP responses to be used in
> > the
> > context of TLS 1.3 ocsp stapling).
> 
> Can you point to where the spec supports your behaviours? That is,
> where it's a valid reading of the spec to close the connection or to
> set a limit of 15 days.
> 
> The point is that it's not a valid reading of the spec. It is,
> instead, an application profile. And that's great. I don't think
> anyone would realistically be arguing that applications or other
> specifications cannot profile the spec to their needs. While I remain
> unconvinced that TLS is the right thing, what you're describing here
> is simply a decision you've made for your community. That doesn't
> mean that because you and Ilari have made different decisions, that
> should be imposed on the spec.

>  
> > >  Given that stapling "issues" exist even without stapling, it
> > does
> > > seem an unnecessary reach to include within the spec.
> > 
> > There is a usability and interoperability issue there. 
> 
> Not within the spec. Within the profile you've done for your
> community.

So you point is that as long as you don't use OCSP responses there is
no interoperability issue. That's very interesting point. More
interestingly you delegate that definition to an application profile. 
Could you refer to such application profiles for TLS which define how
OCSP responses are to be used?

regards,
Nikos