Re: [tsvwg] Checksums in UDP options

"C. M. Heard" <heard@pobox.com> Thu, 06 September 2018 19:18 UTC

Return-Path: <heard@pobox.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F36130F0E for <tsvwg@ietfa.amsl.com>; Thu, 6 Sep 2018 12:18:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 fJHk6vofuNTn for <tsvwg@ietfa.amsl.com>; Thu, 6 Sep 2018 12:18:10 -0700 (PDT)
Received: from pb-smtp20.pobox.com (pb-smtp20.pobox.com [173.228.157.52]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 633CF130F02 for <tsvwg@ietf.org>; Thu, 6 Sep 2018 12:18:10 -0700 (PDT)
Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id E77392811A for <tsvwg@ietf.org>; Thu, 6 Sep 2018 15:18:06 -0400 (EDT) (envelope-from heard@pobox.com)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=3AhHCf9yeInX7tUVbn9XVnkeLS4=; b=LJARtF 7mSaUTJuTUSEFg/m/m+yzmcjmPI498I7ZerTmArrXAFiF5dATUgvY1nKOsq+weHi 0hS6dcP6qgSyU+LB73Reg1nw7/epVa9uMw+MgYgJ+pID6qcF+KovV9kcOZs9f65I bXzz4G/oQHOsbGCajix4ywtKzucqhJUcNOLUo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=n1fauKllOCCwng96MxvoaacCn8xHrON8 F1iG5tjcy6I442ZLqiZ/Whwd7LbKUTYPPeG0IqHSWbsV1v/SWQCIwWOPM9bBJlrY BZTvDqihDDYsgcInvCFAJKLDVZU5ocMM44kkqe1vUpkREJpEXVkOmCyinZRSfz15 T7cbSacoWSs=
Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id DFDAC28118 for <tsvwg@ietf.org>; Thu, 6 Sep 2018 15:18:05 -0400 (EDT) (envelope-from heard@pobox.com)
Received: from mail-oi0-f50.google.com (unknown [209.85.218.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id 7006128116 for <tsvwg@ietf.org>; Thu, 6 Sep 2018 15:18:03 -0400 (EDT) (envelope-from heard@pobox.com)
Received: by mail-oi0-f50.google.com with SMTP id c190-v6so22688582oig.6 for <tsvwg@ietf.org>; Thu, 06 Sep 2018 12:18:03 -0700 (PDT)
X-Gm-Message-State: APzg51Bp2K6zzxeDTfmbLwmkIp91nIuTZZfpLAGCuLYYMFEuTGiKRtni FEKap95vl+ty3Q7jCKpxPHutB/jMkQ37AALag1E=
X-Google-Smtp-Source: ANB0VdY6V9Y/+isGdjQYBqPp3T7p2rRvVBc9qEGbuAfJiwhb8/4RhLfqFTtex0q75vRgS3bLFfxNL//Ix1Ti94fg3ac=
X-Received: by 2002:aca:6206:: with SMTP id w6-v6mr4657946oib.201.1536261482201; Thu, 06 Sep 2018 12:18:02 -0700 (PDT)
MIME-Version: 1.0
References: <CACL_3VEh6rKDzS7rQoxsj8K+Uj9QL6CAR+mGSkB3u-xUet62pQ@mail.gmail.com> <CACL_3VGACAxiJk=6G0Nr2LMkFTMkPT-zbZo3J1+3fx4-Eqv+3Q@mail.gmail.com> <CALx6S34rzW+pnFOpe2MjcPiDGdvpz+zTHbnC8OfY3yTBU+qurw@mail.gmail.com> <CACL_3VFiJ1vCpr2SruU0dsyFbDczZteQQMG6O-tnPn3pb5ZXCA@mail.gmail.com> <CALx6S367eq-gee2a97UNdEgWQFZwjcr4gx5d01zECOm4jScPMw@mail.gmail.com> <CACL_3VHBt7gh29ZSjfFgZ9WjZx3E6wu_RbcGOg3VepYkEWD+wQ@mail.gmail.com> <CALx6S375LYkmMkS-AbbZbykQc7KJB3NVeZ9aD2=0xR4PQUQPww@mail.gmail.com> <CACL_3VEgTQW5JpUX61ffBMxf+tdwrtmHPwiTuer67tFE8=UF7A@mail.gmail.com> <CALx6S36KhEbWdqxzK+8Sp9M-4sF0pDf0TSMfoiGnJueZ9piLOg@mail.gmail.com>
In-Reply-To: <CALx6S36KhEbWdqxzK+8Sp9M-4sF0pDf0TSMfoiGnJueZ9piLOg@mail.gmail.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Thu, 06 Sep 2018 12:17:50 -0700
X-Gmail-Original-Message-ID: <CACL_3VHL0z+o7n=+L=G55nepD_SoC5p9pg6UUnyKJnVKuOLvLw@mail.gmail.com>
Message-ID: <CACL_3VHL0z+o7n=+L=G55nepD_SoC5p9pg6UUnyKJnVKuOLvLw@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
Cc: Joe Touch <touch@strayalpha.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsvwg <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
X-Pobox-Relay-ID: 938D147A-B209-11E8-BBC9-F5C31241B9FE-06080547!pb-smtp20.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/VeiUGfgQzVazO-zW5Vai4kOjAIM>
Subject: Re: [tsvwg] Checksums in UDP options
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Sep 2018 19:18:12 -0000

On Thu, Sep 6, 2018 at 12:10 PM Tom Herbert wrote:
> On Thu, Sep 6, 2018 at 12:00 PM, C. M. Heard wrote:
> > On Thu, Sep 6, 2018 at 11:30 AM Tom Herbert wrote:
> > Indeed, in the DNS case, the negotiation I describe is safe only if
> > the server does not retain memory of the client's ability to use FRAG
> > across transactions. The negotiation has to apply to exactly one
> > request -- which is what I was implicitly assuming. But subject to
> > that proviso, I fail to see any security vulnerabilities (either from a
> > spoofing attack or a MITM attack) that do not already exist today.
> >
> > I grant that this is a special case, but I believe that it is a potentially
> > important special case (though the DNSOP folks may not agree --
> > see draft-song-atr-large-resp for an alternative approach).
> >
> I'm not sure I would call DNS a special case. Isn't that one of the
> biggest users of UDP on the Internet?

That is my understanding. I call it a special case because of the
strict request-response pairing.

> > Again, though, you bring up a good point: negotiating the use of
> > options that transform the data can introduce security vulnerabilities
> > unless there is some means to authenticate the remote peer.
> >
> Look at it this way, we've spent about forty years trying to get TCP
> handshake to be secure and efficient and it's still not perfect. These
> are not easy problems to solve! :-)

Indeed.

Mike Heard