Re: [bfcpbis] Kathleen Moriarty's Discuss on draft-ietf-bfcpbis-rfc4582bis-13: (with DISCUSS and COMMENT)

"Paul E. Jones" <paulej@packetizer.com> Wed, 23 September 2015 07:17 UTC

Return-Path: <paulej@packetizer.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E940B1A6EF0; Wed, 23 Sep 2015 00:17:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.712
X-Spam-Level:
X-Spam-Status: No, score=-2.712 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 b1lgeDNlEpgP; Wed, 23 Sep 2015 00:17:41 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 311CB1A6F71; Wed, 23 Sep 2015 00:17:41 -0700 (PDT)
Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id t8N6QqRG003660 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Sep 2015 02:26:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1442989612; bh=tLLnc22QCfwt63xDzhhQfkUHu6c3bjEESi8gpCYv1Ko=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=IZLiO0JACQAFG6cw6BvPjBwCv4BoPhc8nr5WBcjpPAdCeq5Wsbyzfz7zODb/fLVYa C+UkeGQltn9xm9tusIsvjNcJ+5tDg6oZds/3rme5BNmb4LJNy6ue3zjL1O3qGlFMmk uLX7nfUoVTrVi2YOl/nt4fOlErPN6Qb0kQ7U1WJw=
From: "Paul E. Jones" <paulej@packetizer.com>
To: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>, The IESG <iesg@ietf.org>
Date: Wed, 23 Sep 2015 06:26:54 +0000
Message-Id: <em32a27159-0960-4ceb-89ca-e75cd66919c1@sydney>
In-Reply-To: <20150305152202.28872.54032.idtracker@ietfa.amsl.com>
User-Agent: eM_Client/6.0.23181.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (dublin.packetizer.com [10.109.150.103]); Wed, 23 Sep 2015 02:26:52 -0400 (EDT)
Archived-At: <http://mailarchive.ietf.org/arch/msg/bfcpbis/rgP1uFp-bSlLozo1EXLGGfLeJCQ>
Cc: bfcpbis@ietf.org, draft-ietf-bfcpbis-rfc4582bis.all@ietf.org, mary.ietf.barnes@gmail.com, bfcpbis-chairs@ietf.org
Subject: Re: [bfcpbis] Kathleen Moriarty's Discuss on draft-ietf-bfcpbis-rfc4582bis-13: (with DISCUSS and COMMENT)
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Sep 2015 07:17:43 -0000

Kathleen,

Following up on this email (and building a growing to-do list)....

------ Original Message ------
From: "Kathleen Moriarty" <Kathleen.Moriarty.ietf@gmail.com>
To: "The IESG" <iesg@ietf.org>
Cc: mary.ietf.barnes@gmail.com; 
draft-ietf-bfcpbis-rfc4582bis.all@ietf.org; bfcpbis@ietf.org; 
bfcpbis-chairs@ietf.org
Sent: 3/5/2015 10:22:02 AM
Subject: [bfcpbis] Kathleen Moriarty's Discuss on 
draft-ietf-bfcpbis-rfc4582bis-13: (with DISCUSS and COMMENT)

>Kathleen Moriarty has entered the following ballot position for
>draft-ietf-bfcpbis-rfc4582bis-13: Discuss
>
>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 
>http://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:
>http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/
>
>
>
>----------------------------------------------------------------------
>DISCUSS:
>----------------------------------------------------------------------
>
>Thanks for your work on this draft, it was very well written which is
>much appreciated.
>
>I just have one item I'd like to discuss that should be very easy to
>resolve.
>This should be considered with Spencer's question on what happens when
>the fragments are larger or smaller than the path MTU.  It's important 
>to
>state this to prevent fragmentation overlap attacks (unless you can
>explain why we don't need to worry about that).

Are you concerned about IP-packet level fragmentation overlap or payload 
level fragmentation overlap issues?  I think the former should be 
addressed with "do not fragment IP packets".  The latter is an area that 
is not addressed in the spec at present.  However, if there is overlap 
in the application data, I do not see any harm.  Of course, it would be 
important to check to ensure lengths are all correct to prevent buffer 
overruns.

Am I missing something here?


>In the second sentence on page 42, adding the ending clause may be
>helpful:
>   The size of each of these N messages MUST be
>    smaller than the path MTU to help prevent fragmentation overlap
>attacks.

This would be a good addition.  We have other text we need to add re: 
path MTU and it is the intent that all messages fit within the path MTU.


>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>
>Spencer asked what happens when TLS/DTLS is not used, so perhaps
>rewording of the intro to the security considerations section would 
>help
>to clear up his point.  TLS/DTLS is the MTI with flexibility left in to
>support some other undefined mechanism to secure the channel.  Since no
>MTU is set, but recommended, the first few sentences are a bit 
>confusing.
>  The rest of the paragraph is clear in terms of MTI and recommendations
>when TLD/DTLS is used as well as alternates options supporting the 
>listed
>desired security properties.
>
>Security Considerations
>
>    BFCP uses TLS/DTLS to provide mutual authentication between clients
>    and servers.  TLS/DTLS also provides replay and integrity protection
>    and confidentiality.

At present, TLS/DTLS are recommended, but not mandatory.  Without them, 
there is a host of attacks one could perform against either a client or 
server, especially over UDP, and there is no authentication or 
confidentiality.  Much of that is spelled out in the security 
considerations section.

I apologize, but I'm missing what your request is here.  Can you clarify 
for me?

Paul