IETF Logo Mail Archive

Re: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt

Dmitry Belyavsky <beldmit@gmail.com> Wed, 20 February 2019 07:01 UTC

Return-Path: <beldmit@gmail.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 A4E621294FA; Tue, 19 Feb 2019 23:01:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 H4pmwxBbC9bZ; Tue, 19 Feb 2019 23:01:47 -0800 (PST)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 48877127287; Tue, 19 Feb 2019 23:01:47 -0800 (PST)
Received: by mail-ed1-x52d.google.com with SMTP id m12so18930567edv.4; Tue, 19 Feb 2019 23:01:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fmgvQ2fwxKIjCfG8hOeuGHFlUmA0xHz57MlK81GRA6I=; b=XvTmlYlpWeAUvG2rugQuvspo6MNnpbnKBEGpRc7WeNfLm4TOGGdvkRfeaNC8DyCEP3 NqR72inBvF8VYrdpH0oZIzs8ZqVvOHaaAbyv6uYL+hInv7cZ6ZjtkE3sUvKVWnFuYmEN rZZb8pro0/DdyBA9V3lXQWjNNsLQwVYOtHh3xvBgGbu72JHfoaoDfDhjsFhy+xbIIPOt sRZE7WvSmiiE5o3xpHHv2KFG3jqOzUTvbNq9TLchmhjM22+AIyuOnUnNxOxv89y7Zyu1 4R4nI/wXXxuRzg8FM3gsLFKoaqiO1as36PZOTbhkMSXMEDnwZMwScQP3Ico0DtQqRmXA 0fdw==
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=fmgvQ2fwxKIjCfG8hOeuGHFlUmA0xHz57MlK81GRA6I=; b=fuoA6c7+3F6Ba6jh070TWEev4FvGh8BHVwprVDrw1iKqzBs46X8YnsrA8cAeyrmvhW E+4gC6b2oGLjGWNjziKTLxxnbWj7lhshKKAuGXkg8t/pDBT5uVT3a7OGQuX3fU+N4qMB cOJXlBDgwN+LQrYM95B66BkxxNO9R0N30O8WXaKNROq/fX5uh2rsgb3HfG2hqOTfYg2H UIfaP3QWMghkeeJfLNhjVa7wkSxmi8hcO9T4SROaG6z1BOTBA1EyxEDaOvrZ9X5LQIvv kcqUBtoSggwVkpRw11OHLNHSuA7/xX98akPn937BPs9LsRe6gsxHC3lof+rxPF70iaRf bZIw==
X-Gm-Message-State: AHQUAuZMdfESnT4KZNzYXuan3+4fA4K6z+tfTkld9jAdBE89kFvyProc 2FT22p+/2lstLpNYBfVQiIlht+6tJl7jc5cmWzI=
X-Google-Smtp-Source: AHgI3Ian6jKs/caKKQQlCGGN9HFb74DBAKJYw+rWPezBfs2kDU0CulCa7WzuVWFGxL8Am+nLXPBI155uHyELHuTsrwE=
X-Received: by 2002:a17:906:5944:: with SMTP id g4mr1786825ejr.105.1550646105348; Tue, 19 Feb 2019 23:01:45 -0800 (PST)
MIME-Version: 1.0
References: <155060540091.20709.12797700493315209480.idtracker@ietfa.amsl.com> <CADqLbzLt3sJhisojiEDA93zOymBE0QjVxT2T+NAZjYSGm2Nzmg@mail.gmail.com> <1550634231892.18369@cs.auckland.ac.nz>
In-Reply-To: <1550634231892.18369@cs.auckland.ac.nz>
From: Dmitry Belyavsky <beldmit@gmail.com>
Date: Wed, 20 Feb 2019 10:01:34 +0300
Message-ID: <CADqLbz+zYNTwCidJhrR9DFaj3NqJszdx4bg=qkzwptMY9mYXrg@mail.gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: TLS Mailing List <tls@ietf.org>, "secdispatch@ietf.org" <secdispatch@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000481f4205824dee5e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Xl_-VK2F4rda3KOpLjqiZnmaV54>
Subject: Re: [TLS] Fwd: New Version Notification for draft-belyavskiy-fakesni-00.txt
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: Wed, 20 Feb 2019 07:01:50 -0000

Dear Peter,

On Wed, Feb 20, 2019 at 6:43 AM Peter Gutmann <pgut001@cs.auckland.ac.nz>
wrote:

> Dmitry Belyavsky <beldmit@gmail.com> writes:
>
> >The draft describes a Fake SNI mechanism intended to cheat DPI systems in
> a
> >case when a DPI system blocks the connection if ESNI is present.
>
> Since this mechanism advertises the fact that a fake SNI is present,
> wouldn't
> the DPI then also block the connection for that?
>

The suggested mechanism does not advertise the presence of a Fake SNI.
Fake SNI is delivered out-of-band for the handshake and an observer has to
discover
that ClientHello message contains a SNI extension that does not match to
any host
present at the IP address where we try to connect.

Passive collection and blocking the Fake SNI values also has little sense
because the value can be changed relatively easily.

-- 
SY, Dmitry Belyavsky

v2.23.0 | Report a Bug | By Email