Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-26: (with COMMENT)

Eric Rescorla <ekr@rtfm.com> Wed, 07 March 2018 18:06 UTC

Return-Path: <ekr@rtfm.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 BF3621274D2 for <tls@ietfa.amsl.com>; Wed, 7 Mar 2018 10:06:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 fesuxA21Mvvk for <tls@ietfa.amsl.com>; Wed, 7 Mar 2018 10:05:58 -0800 (PST)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 E3D9B12420B for <tls@ietf.org>; Wed, 7 Mar 2018 10:05:57 -0800 (PST)
Received: by mail-qk0-x229.google.com with SMTP id s188so3742927qkb.2 for <tls@ietf.org>; Wed, 07 Mar 2018 10:05:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uiyUfH8qCJVwRTmBZ2IHVhG8MxhnL6UuQYdBtXkrEko=; b=Dpm6YGM3bT8rfwdJ0ECq/ypEUxFTshItFCXEHAmRab27IFfvzixwILslPEDsc+HamJ sHO0MgcSZlb1qdd/ZEb+TEFpc1XSjz4GF7qtjei3awTAr0UEa2v1RicudmecHffg7lD/ aw+h6dKWwVoNazfkXm2QFp6eLoGZNe1qm71b6owzgCT0pZw51udROfH06BUZzZaZ6KjB WAbc6YMCa9AJSrEgyamc9j4Yn43iNhYnsuwnhbGTgC629v6CeQRVGPzxy8JsQRnVx2Im NxDILF9H5qOxqrbdpfuR5t0X1gpR/HtaoPBk7Iv5JqKh9tZnLbZUuiZABbdZeR1Po1IG AQ3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uiyUfH8qCJVwRTmBZ2IHVhG8MxhnL6UuQYdBtXkrEko=; b=stGtcrC2j8ClkMRox5zLpVX3weFicu4bJMqy15f+69bBGU17riAWoPmdOy/LSUiBhB /2kOt/GXLpHk9nplkAk7ykwHblI/H4lnjuQFqCoOQZfwZFJMRrs6JzW69O7NILqHc0rQ XYsSBb8qwmAXZ8rUx1OqaB9Okiq+ck78liLNAa8JJBQh4UYOx5BX7L0BeRVv8RkVoZuG V0PNOAef6qVRYKYHqJayXKnKnPsUovGQHPDafthi9DkDV/pEit1EY+tUVz2uhURcdK8B Q95w5uutv7E3endCvuhNZc6VgB8aadUD9XyWv7fWpPsW8gxLUeZjE13YD3ixGpkX9L8a BF3g==
X-Gm-Message-State: AElRT7F522sMFPIJNpbw9zKZhG2aPCTMjl0hu0PNTAZhWWPBzLh/Ns2G Xol/FqH2UJPG+d1C5DEvaGlyPi253oA70HCrgftYyw==
X-Google-Smtp-Source: AG47ELun5j6hCSoLYRjTdMZorfMN704PUj86ukKpLV/kmGA6dpBLbXhaiRDiWvc385xPx20BJhYy4nNVySI8MP0cOq4=
X-Received: by 10.55.118.6 with SMTP id r6mr35870850qkc.211.1520445956900; Wed, 07 Mar 2018 10:05:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.37.176 with HTTP; Wed, 7 Mar 2018 10:05:16 -0800 (PST)
In-Reply-To: <152044072045.17779.18123788753031746068.idtracker@ietfa.amsl.com>
References: <152044072045.17779.18123788753031746068.idtracker@ietfa.amsl.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 07 Mar 2018 10:05:16 -0800
Message-ID: <CABcZeBML9yhXvzA53QxVNk0-3pis=8pF9LYzYXqTmUvCaVRisQ@mail.gmail.com>
To: Mirja Kühlewind <ietf@kuehlewind.net>
Cc: The IESG <iesg@ietf.org>, draft-ietf-tls-tls13@ietf.org, Sean Turner <sean@sn3rd.com>, tls-chairs <tls-chairs@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0627382961990566d66943"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/5PEnw3iSv3HtK-U0YZWcp0uB4Pc>
Subject: Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-tls13-26: (with COMMENT)
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: Wed, 07 Mar 2018 18:06:01 -0000

> 1) I'm a bit uncertain if obsoleting is the right approach as many
> other protocols usually do not obsolete older versions. However, I
> understand that this has been the approach TLS has previously taken
> and is supported by the way the document is written.

Well:
https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
says:
A document is obsolete when there is a newer version that replaces it.

I believe that that's the relationship between TLS 1.3 and TLS 1.2.


> Still, I find it
> especially confusing that also two TLS1.2 extensions are deprecated
> which are not needed with TLS1.3 anymore but still probably valid to
> be used with TLS1.2, right?

Which extensions are you referring to.


> I would recommend for this version to at
> least already note in the abstract or very early in the intro that it
> changes the versioning mechanism itself, and thereby basically
> declares the TLS handshake as an invariant for all future versions and
> extensibility is only provided using extensions anymore.

It's true that we are deprecating the version mechanism, but that
does not mean that it is the only extension mechanism.



> 2) Can you provide further explanation (potentially in the draft) why
> the Pre-Shared Key Exchange Modes are provided in an extra/separate
> extension?

I'm sorry, I'm not following this. As opposed to what?


> 3) I know previous versions of TLS didn't say that much either, but I
> find it a bit wired that there are NO requirements for the underlaying
> transport in this document. Previous version this at least said in the
> intro that a reliable transport (like TCP) is assumed, but even this
> minimal information seems to have gotten lost in this
> document. However, I would usually also expect to seen some minimal
> text about connection handling, e.g. is it okay to transparently try
> to reestablish the connection by the underlying transport protocol if
> it broke for some reason? Or it is okay to use the same TCP connection
> to first send other data and then start the TLS handshake?

This is pretty explicitly outside the scope of TLS. It's just the job
of the underlying transport to simulate a reliable stream. I can add
some text that that's expected.


> 4) Regarding the registration policies: I assume the intend of
> changing them is to make it easier to specify and use new
> extensions/mechanism. However, I am wondering why the policies have
> been changed to "Specification Required" and not "IETF consensus" or
> RFC Required"?

The changes aren't in this document, but the WG feeling was that
both of those were creating bad incentives for people to publish
RFCs just to get a code point. The "Recommended" flag was intended
to address that need instead.


> 5) I find it a bit strange that basically the whole working group is
> listed as contributors. My understanding was that Contributors are
> people that have contributed a "significant" amount of text, while
> everybody else who e.g. brought ideas in during mailing list
> discussion would be acknowledged only.

I don't think we have any IETF-wide standard here, but traditionally
we have adopted a pretty generous attitude towards acknowledgements
of this type. Given that electrons are basically free, I don't see a real
problem here.

-Ekr


On Wed, Mar 7, 2018 at 8:38 AM, Mirja Kühlewind <ietf@kuehlewind.net> wrote:

> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-tls-tls13-26: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 1) I'm a bit uncertain if obsoleting is the right approach as many other
> protocols usually do not obsolete older versions. However, I understand
> that
> this has been the approach TLS has previously taken and is supported by
> the way
> the document is written. Still, I find it especially confusing that also
> two
> TLS1.2 extensions are deprecated which are not needed with TLS1.3 anymore
> but
> still probably valid to be used with TLS1.2, right? I would recommend for
> this
> version to at least already note in the abstract or very early in the intro
> that it changes the versioning mechanism itself, and thereby basically
> declares
> the TLS handshake as an invariant for all future versions and
> extensibility is
> only provided using extensions anymore.
>
> 2) Can you provide further explanation (potentially in the draft) why the
> Pre-Shared Key Exchange Modes are provided in an extra/separate extension?
>
> 3) I know previous versions of TLS didn't say that much either, but I find
> it a
> bit wired that there are NO requirements for the underlaying transport in
> this
> document. Previous version this at least said in the intro that a reliable
> transport (like TCP) is assumed, but even this minimal information seems to
> have gotten lost in this document. However, I would usually also expect to
> seen
> some minimal text about connection handling, e.g. is it okay to
> transparently
> try to reestablish the connection by the underlying transport protocol if
> it
> broke for some reason? Or it is okay to use the same TCP connection to
> first
> send other data and then start the TLS handshake?
>
> 4) Regarding the registration policies: I assume the intend of changing
> them is
> to make it easier to specify and use new extensions/mechanism. However, I
> am
> wondering why the policies have been changed to "Specification Required"
> and
> not "IETF consensus" or RFC Required"?
>
> 5) I find it a bit strange that basically the whole working group is
> listed as
> contributors. My understanding was that Contributors are people that have
> contributed a "significant" amount of text, while everybody else who e.g.
> brought ideas in during mailing list discussion would be acknowledged only.
>
>
>