Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05

Benjamin Kaduk <bkaduk@akamai.com> Thu, 14 November 2019 20:53 UTC

Return-Path: <bkaduk@akamai.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 C1AE8120921; Thu, 14 Nov 2019 12:53:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 n2Ku1x2TKUpp; Thu, 14 Nov 2019 12:53:19 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A139512080D; Thu, 14 Nov 2019 12:53:18 -0800 (PST)
Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAEKqNgc001269; Thu, 14 Nov 2019 20:53:16 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=sYaksfaMYU157lOqmn1/OqrbV7ojboMnqG2SK19gF28=; b=Ca0Azfm3jBEUhGxOW67O6o9XsA8k4D4DEkzxRRxaULEzGgdXrRkmVGnyLLo09GePVTrP UlGSkptT/NFRGpQhluYJx0bLaN2rMaSiJt3QH19t+7W/j6O8Ghk8q8NZbnNYj0Tiq63z g2K/iDdeuuIgLVlyAxAewtNkQmbin0yaG/Fu+3amM8pmn9OofvUWZsnp8v1dVHmRzWc+ DOiBE3AqU5p8SHzvT7prv9cfI2vkl4E9dNEpDYQusLSzY9EpegLRjMMCeWusf+EcSiZQ VEQaz1vr495cN8ILjOjoxFq+CDSmqAmurNGqeOmCQkgG6AobAgMN/Qe6QJVQxfBU6uha SA==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2w5p6ead1t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 14 Nov 2019 20:53:16 +0000
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAEKlPAP017956; Thu, 14 Nov 2019 15:53:15 -0500
Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint1.akamai.com with ESMTP id 2w5sp0n73m-1; Thu, 14 Nov 2019 15:53:13 -0500
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id BB0D91FC6A; Thu, 14 Nov 2019 20:53:13 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1iVM76-00058P-CI; Thu, 14 Nov 2019 12:53:12 -0800
Date: Thu, 14 Nov 2019 12:53:11 -0800
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, draft-ietf-tls-oldversions-deprecate.all@ietf.org, "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <20191114205311.GP20609@akamai.com>
References: <20191111195325.GE32847@kduck.mit.edu> <CAHbuEH5mCW9aUJva=+umYeTLbOvHQUTSexxVjhn3zNDOv5Sb7A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHbuEH5mCW9aUJva=+umYeTLbOvHQUTSexxVjhn3zNDOv5Sb7A@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-14_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911140172
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-14_05:2019-11-14,2019-11-14 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 adultscore=0 lowpriorityscore=0 bulkscore=0 malwarescore=0 priorityscore=1501 impostorscore=0 phishscore=0 mlxscore=0 mlxlogscore=999 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911140172
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3tBpm1YHY1rVK13BS6TULuVPiWg>
Subject: Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05
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: Thu, 14 Nov 2019 20:53:24 -0000

On Wed, Nov 13, 2019 at 06:29:44AM -0500, Kathleen Moriarty wrote:
> Hi Ben,
> 
> Just replying to the parts of the tread that were not responded to already
> as Stephen will likely be looking at the headers/updates per his message.
> Thanks for your careful review.
> 
> On Mon, Nov 11, 2019 at 2:54 PM Benjamin Kaduk <kaduk@mit.edu>; wrote:
> 
> > Hi all,
> >
> > This is a "preliminary" review only because there's some strangeness
> > relating to the Updates: (and Obsoletes:) headers, and any changes there
> > would make me need to go and recheck the relationship of this document to
> > the ones listed.  So, I haven't done any of that yet, in an attempt to only
> > have to do it once.
> >
> > Specifically, there's skew between the list of documents updated in the top
> > header and the list in Section 1.1.  Evern more annoyingly, the (tools)
> > HTML version seems to be missing some numbers from the document header,
> > that are present in the TXT version.  (Henrik is going to take a look, per
> >
> > https://mailarchive.ietf.org/arch/msg/tools-discuss/Maeh0f_WfOy5sfnGQpwGPs_sYcU
> > .)
> >
> 
> Thanks.
> 
> >
> > Additionally, Section 1.1 lists some RFCs that "have been obsoleted", but
> > there is no "Obsoletes:" header at the top of the document.
> >
> > I think nits is right about references (square-bracketed "[RFC6347]") in
> > the Abstract; we should change those to normal textual (parenthesed
> > "(RFC 6347)") before IETF LC.
> >
> > Some other notes from a quick pass over the main text (though I'll probably
> > read it again once the above are addressed) follow.
> >
> > Section 1
> >
> > It feels a little backwards for a "primary technical reason" to
> > deprecate a protocol version being that "at least one widely-used
> > library has plans to drop [it]".
> >
> 
> I see what you are saying.  The major library dropping it has to do with
> the number of versions available and supporting them all is cumbersome and
> could lead to configuration errors on the part of the user.  Would you just
> like "primary" removed or would you prefer more of a change to the text?

The main reason I raised it is that it doesn't feel like a *technical* reason;
it's done for expediency and perhaps with a bit of politics, but there's nothing
technical about the protocol involved.

> 
> >
> > I do appreciate that we give discussion about what we intend
> > "deprecation" to mean and for whom -- thank you for that!
> >
> > Section 2
> >
> >       TLS 1.3, specified in TLSv1.3 [RFC8446], represents a significant
> >       change to TLS that aims to address threats that have arisen over
> >       the years.  Among the changes are a new handshake protocol, a new
> >       key derivation process that uses the HMAC-based Extract-and-Expand
> >       Key Derivation Function (HKDF), and the removal of cipher suites
> >       that use static RSA or DH key exchanges, the CBC mode of
> >       operation, or SHA-1.  The list of extensions that can be used with
> >       TLS 1.3 has been reduced considerably.
> >
> > While it's true that the initial list of extensions usable with TLS 1.3
> > is smaller than the list of extensions usable at TLS 1.2 taken at the
> > same time, it's also true that the requirements for allocating a new
> > extension codepoint have been reduced dramatically.  So I think I'd say
> > that this reflects not a desire to reduce the attack surface (as
> > "measured" by number of extensions) but rather a paradigm shift in how
> > the protocol works, which leaves some existing functionality
> > incompatible with the new model.  I don't really get a clear sense of
> > what this current last sentence is trying to say (i.e., whether it's one
> > of those two descriptions I offered above).
> >
> 
> Would you prefer "a significant change", be "a paradigm shift"? If not,
> could you propose text?

I'm trying to say that the reduced size of the list of extensions is just
a side effect, not an end in its own right.  
But, I seem to have missed that this paragraph is part of a quotation from a
NIST document, so I don't get to wordsmith it :)

> 
> 
> > Section 3
> >
> >    Similarly, the authentication of the handshake depends on signatures
> >    made using SHA-1 hash or a not stronger concatenation of MD-5 and
> >    SHA-1 hashes, allowing the attacker to impersonate a server when it
> >    is able to break the severely weakened SHA-1 hash.
> >
> > My recollection of the WG discussions (which I will go review) is that
> > we don't really have consensus on the "not stronger" portion of this.
> > Is that a key component of the document here?  (N.B. this is *not* an
> > invitation to rehash that discussion again!  The chairs or I can provide
> > a summary of points not resolved by previous discussion and points
> > believed to be adequately agreed upon, which would be a trigger for any
> > additional discussion that might be needed.)
> >
> 
> Since you are already looking at the consensus of this with the chairs, we
> can wait for your guidance.

Okay.  That might not happen until after Singapore, though.

-Ben