Re: [DNSOP] Stephen Farrell's Discuss on draft-ietf-dnsop-5966bis-05: (with DISCUSS)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 07 January 2016 14:44 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E61A1A8ACC; Thu, 7 Jan 2016 06:44:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 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_MED=-2.3, 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 cMLE1ChYU4Ku; Thu, 7 Jan 2016 06:44:53 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 769AC1A8AB6; Thu, 7 Jan 2016 06:44:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 31A24BE59; Thu, 7 Jan 2016 14:44:51 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psmRriknCY1S; Thu, 7 Jan 2016 14:44:51 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8DB69BE58; Thu, 7 Jan 2016 14:44:50 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1452177891; bh=tmiIUCMlw/go439msR5mwzUjCEy7nHV+OJPZhU31epI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=zs9spQR0iGHx3c+hI3C74L5An2OMORtlOjwh/QBFiJBX1cdLMhMD7yOsNUNWB0sSd OTGa1wMX/jc/16yobSfBxJ9TM+QQu6kFsFMOKPw23kL4Xz4Ga3/TTH5Em4Qit6rrNY g8M8Ec9GBBlJohTutWt7OpMRx6xsmtiVLi3g+yzA=
To: Allison Mankin <allison.mankin@gmail.com>
References: <20160107000918.2664.4578.idtracker@ietfa.amsl.com> <CAP8yD=uLFTuvgAFOTkXffNcOumjet+stgr3gXe2XZOtGqMn7Sw@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <568E79E2.6040209@cs.tcd.ie>
Date: Thu, 07 Jan 2016 14:44:50 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <CAP8yD=uLFTuvgAFOTkXffNcOumjet+stgr3gXe2XZOtGqMn7Sw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/JZ0h7WGwkEdxb0hQPc7YHE91O5U>
Cc: tjw.ietf@gmail.com, dnsop@ietf.org, draft-ietf-dnsop-5966bis@ietf.org, dnsop-chairs@ietf.org, IESG <iesg@ietf.org>
Subject: Re: [DNSOP] Stephen Farrell's Discuss on draft-ietf-dnsop-5966bis-05: (with DISCUSS)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2016 14:44:56 -0000

Hi Alison,

On 07/01/16 12:40, Allison Mankin wrote:
> Hi Stephen,
> 
> We're glad you drew this important  point to our attention, but it appears
> to be needed for draft-ietf-dprive-dns-over-tls rather than this draft. In
> this draft we don't touch on the privacy/TLS motivation for TCP at all,
> leaving all that for the dprive draft.
> 
> The dprive draft has just completed WGLC. Some of us are authors on both
> drafts and we'll propose  text on TFO privacy leakage risks to dprive and
> our dprive AD and you.

That's fine. I guess the only remaining question is whether this
document, which does discuss TFO, should have some sort of generic
warning that mixing plaintext and ciphertext is both possible and
dangerous with a pointer to the dprive draft (as an informative ref)
saying that the details are part of the dprive work. So perhaps
adding a sentence to section 9 that says something like:

"Implementers should be aware that if a DNS privacy mechanism is
being used then there are significant dangers in mixing unprotected
query or response data (from TFO) with protected data. See [dprive]
for the proper way to handle this situation."

And then [dprive] can say if that kind of mixing is a MUST NOT
or whatever, once that's figured out.

Cheers,
S.


> 
> Thanks,
> 
> Allison
> On Jan 6, 2016 7:09 PM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:
> 
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-dnsop-5966bis-05: 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 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-dnsop-5966bis/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>>
>> Don't we need text warning that TFO is likely problematic
>> with DNS privacy and that attacks that try to prepend
>> information (via TFO) to otherwise secured sessions could
>> occur? While that might sound a bit far-fetched we have
>> seen exactly that kind of issue with HTTPS that had
>> practical impact on Webdav. (The TLS renego and then
>> triple handshake attacks.) So while using TFO may not
>> enable a slam-dunk CVE level 10 attack, I think you do
>> need to consider and talk about it. (Or maybe you did and
>> figured out no attack can work, but then I'd guess you'd
>> be so happy, you'd say that too:-)
>>
>> I'm not sure how this'd best be resolved, but one thing
>> might be to talk to the folks thinking about TCPINC as
>> they have at least hit this as a potential issue for
>> tcpcrypt and for tcp-use-tls.
>>
>> Otherwise, this is a fine document on which I'll ballot
>> yes when the above is sorted.
>>
>>
>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>