Re: [TLS] TLS Impact on Network Security draft updated

Eric Rescorla <ekr@rtfm.com> Tue, 23 July 2019 22:12 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 1676A1209CA for <tls@ietfa.amsl.com>; Tue, 23 Jul 2019 15:12:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 IiMNB33_1UYb for <tls@ietfa.amsl.com>; Tue, 23 Jul 2019 15:12:36 -0700 (PDT)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 1F75B1209AA for <tls@ietf.org>; Tue, 23 Jul 2019 15:12:36 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id m23so42476503lje.12 for <tls@ietf.org>; Tue, 23 Jul 2019 15:12:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4SYcA7fyl3TTz/ykUJqMvDHwiySpFlaO3LtZWGrx9xw=; b=IOfmCCSBsPkgr4Nhps0f5pwbaSD0PthBrzGvwZ5hbsWisQlZ6klwUFxrUIawKBXQhL KqUUYOX7c9XkLSWQ+k7E0baZwJy9kr5nS4Puh4WEh6RDt6Pvs+J5jc3FHdCpzU3mmbDv EwcnUwpP8qmnK9W1kL+6Lj1EQ6By1OE3sFaq1xB7qVrTbY8uC2meFljA4m8WAzuf5sl/ 7DB6HFusFqU1+Z3QJbmehYkgyAB+9bDBoIrXBlV/KGoZlRLbCcAiBbAG/UTzCnKxA/KL OTecZs3F6scLa8CqUQjO10t1VAbmpinqDFAyeTTXK6SfdQYfeChEoHd9GitLrZpPbQ9l 7B/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4SYcA7fyl3TTz/ykUJqMvDHwiySpFlaO3LtZWGrx9xw=; b=QDnps0kjeGZ09bu6YSnxxdaEiDZyS8A5zzMMwmzsW3B2z4AbAGAwRe1+G8LQMaqPU+ MvHRkQKWXX15gUP473yjDXXMg/fPE9jg2oTkTzDNTuSSxpIsDv3AWJ9BZUHZcvck7NJg B2x3oY6Vy4M4WlchN4zoaIXoActOiNiOF4LfSf8k6ynONAr3ZSC0AGrQBbPXGU83Wpaw TiuRdxtyL/DHHDfaBWAWYinWSZ7ZvrvMkQXkpmM/ObjO3tTDObSVsv+yi0PqWFp2lEX0 1r7aSRtV+eh7cQ3kRgo1x9LOUOFiXkXgKxX6A9EGhSb2htO2m6MUB2TO1KUI22s+HEje MlLQ==
X-Gm-Message-State: APjAAAUqUC7B9juigA2r7JQjj2Z3e/E3+xAlJTQO3AWHzi/hII8HUYXf K1OC2E7hV1VGIMV0NnutMUB7pmVXEZI8s5LJNfM=
X-Google-Smtp-Source: APXvYqwH4glxKGmDYB/icIexxXT6DTtZW7rdLfqju2P2KkxSk0ijTmrXo9eddZVwrwsYy3732Je5lH8EBZ71FETY4Kk=
X-Received: by 2002:a2e:8892:: with SMTP id k18mr41471571lji.239.1563919954386; Tue, 23 Jul 2019 15:12:34 -0700 (PDT)
MIME-Version: 1.0
References: <6AF48228-19C2-41C7-BA86-BA16940C3CFF@cisco.com>
In-Reply-To: <6AF48228-19C2-41C7-BA86-BA16940C3CFF@cisco.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 23 Jul 2019 15:11:57 -0700
Message-ID: <CABcZeBMTSsfmyNZ0d7yrx67W-BM-mD+5FWDXJcXAFqkPBSAvYQ@mail.gmail.com>
To: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000056b57e058e607dba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/RLKM04bYTS9K54uR6zHjZZRuLUI>
Subject: Re: [TLS] TLS Impact on Network Security draft updated
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: Tue, 23 Jul 2019 22:12:49 -0000

Document: draft-camwinget-tls-use-cases-05.txt

I have some technical comments on the current draft.


S 2.2.1.
   Note that even _if_ the SNI is provided by the client, there is no
   guarantee that the actual server responding is the one indicated in
   the SNI from the client.  SNI alone, without comparison of the server
   certificate, does not provide reliable information about the server
   that the client attempts to reach.  Where a client has been
   compromised by malware and connects to a command and control server,
   but presents an innocuous SNI to bypass protective filters, it is
   undetectable under TLS 1.3.

This actually applies to TLS 1.2 as well, because nothing requires
that a nonconformant client use the key supplied in the server certificate
(for instance, it might just just encrypt with a fixed key or tunnel
a key exchange in the TLS handshake somehow). This cannot be detected
by a passive observer.


S 2.2.2.
I don't understand the point of this section. TLS 1.3 resumption PSK
and TLS 1.2 resumption (with tickets, for instance) are largely
isomorphic. In both cases, the client can decline resumption, but that
is true in 1.2 as well (though there's no formal way to do it in 1.2).
As a practical matter, there's no real chance that a standard client
will not let you fall back to a full handshake.

In earlier versions of this document, it didn't recognize this point
and so this section (while misleading) made some sense, but at this
point I would just remove it.


S 2.2.3.
I don't get what this section is trying to say. Previous TLS versions
included anti-downgrade mechanisms, so you could never silently
downgrade versions. The TLS 1.3 anti-downgrade mechanisms are
designed to be stronger than TLS 1.2, but they don't fundamentally
change this situation.


S 2.2.4.
Yes, ESNI causes you problems, but if you are a selective MITM proxy,
you should just disable ESNI on clients using the same mechanisms
that you use to add your own trust anchor.


-Ekr








On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) <
ncamwing@cisco.com> wrote:

> Hi,
>
> Thanks to all the feedback provided, we have updated the
> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04
>
> draft.  At this point, we believe the draft is stable and would like to
> request its publication as an informational draft.
>
>
>
> Warm regards,
>
>     Nancy
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>