Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
Shumon Huque <shuque@gmail.com> Thu, 22 February 2018 15:44 UTC
Return-Path: <shuque@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 23DBB12D7F2; Thu, 22 Feb 2018 07:44:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-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=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 USzc5pSAahD3; Thu, 22 Feb 2018 07:44:52 -0800 (PST)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 E857212741D; Thu, 22 Feb 2018 07:44:51 -0800 (PST)
Received: by mail-io0-x22c.google.com with SMTP id t22so6460649iob.3; Thu, 22 Feb 2018 07:44:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q/pYiT0v1rDqBRiIZ9E5Bda7OGkgMbcD1fXU8zCTFbg=; b=ZxllBV4NSFVYXuCqfaiYKesHFkVx6IZQH4k/9YSctstAI7n8O9DePXr4Nk5tlR+ong ZmDlZzTBaizqV/gnjRDCSHJBKx8U3dErimWsbGG5q91YwhzKFBQ7rgf5Of1nXnTernea jtlrWwGtCgnv2gLOthNuy+cVnPaU4kmzRx43oOI7fjiIX+q0Vv61wlIdfUQMHbMOi7f8 OCNUvDhzWGkroltiYOAaV0GLogcVLpEaXvZ+qUVRTmJaut/+ZX74BJwE9hwtBjSNe8Pc UwlRBe8rXWgBm5ny5iFiYAAwt86n19cxmESpgesnUcg5lvZNhUKBLuuQ5yy6RPji2P9T DCog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q/pYiT0v1rDqBRiIZ9E5Bda7OGkgMbcD1fXU8zCTFbg=; b=hpf1rdGRWREcB9Gl/wSbFHulzSzrI8P1MGPNZoLj4zyAUGcuwfWtTXEmecccSOhjMD oGmELjc/jXj8dMUD/qNa15KWiByt7AwxEa4zWdGQhO/3VZpyDhEp3CzGpJja06wyaY6V bPmT+3ac22wwQJDH0/gHa+YVBN+OUHjKyYIaD8fJZ97fXiR2ByVUQ3uI7pK2e0kl43On LM3IO9hpnS4z15k147ZNAjrk8SQVwfuYhnl0WB4nbJaI3wZoYfES5H3VfzfsDn9+4Vjp ADL5YJtSX82OCt14Qif9uLl5xlG/GPClCUdyZk+AFv4UW6WQJqJPp6ukJ7rFG1veiwcF A15w==
X-Gm-Message-State: APf1xPB86OU2XRphbVUqEOp0eJEK3nkf+3yM5ePYMSFvLshfm7CpQy7r VxY/DQxad8OvOyiFB6AMKNsSy0H1JR4bA23+j1A=
X-Google-Smtp-Source: AG47ELuweQ63RWoDSEd3ETfSYWF812TcIt6j9BdwdFXQQ7+9cV+A4dp2ej7AOkmMT8E+pFHKTiEnouecGTjkcfluSns=
X-Received: by 10.107.137.104 with SMTP id l101mr9275223iod.179.1519314291148; Thu, 22 Feb 2018 07:44:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.79.201.198 with HTTP; Thu, 22 Feb 2018 07:44:50 -0800 (PST)
In-Reply-To: <alpine.LRH.2.21.1802211425260.7767@bofh.nohats.ca>
References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> <CAHPuVdUgZLUf5M8ir=610mvERwQzPhbhGGOyW5s552JtP8d05g@mail.gmail.com> <CABcZeBOST2X0-MH2hhzpPJaUkbY++udsUV1bMnMhH2V2wQRPmA@mail.gmail.com> <CAHPuVdUs7mUJiqZjFjLDCNmHHGR9AP-g5YaLLbJj-zkDKd=_-w@mail.gmail.com> <alpine.LRH.2.21.1802211425260.7767@bofh.nohats.ca>
From: Shumon Huque <shuque@gmail.com>
Date: Thu, 22 Feb 2018 10:44:50 -0500
Message-ID: <CAHPuVdX=_6b5g572-T-9Ccwek-WwL11KdTVwV9oNC9LaO5=0=Q@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: Eric Rescorla <ekr@rtfm.com>, TLS WG <tls@ietf.org>, draft-ietf-tls-dnssec-chain-extension@ietf.org, The IESG <iesg@ietf.org>, tls-chairs <tls-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="001a113eb134a052420565ceeca8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/suPLgrcA36X2mRgiDby8fXM8mEY>
Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 22 Feb 2018 15:44:54 -0000
On Wed, Feb 21, 2018 at 2:48 PM, Paul Wouters <paul@nohats.ca> wrote: > On Wed, 21 Feb 2018, Shumon Huque wrote: > > Okay, got it. For people that have already implemented this, I think >> there has been an implicit understanding that the format of the chain >> data is a sequence of concatenated wire format RRs exactly as they appear >> in a DNS message section >> > > Note, I would not call it "sequence of concatenated wire format RRs", as > it is simply the wireformat of a DNS message. The fact that some parts > are concatenated RR's is just part of the wireformat of the DNS reply > message. That is, this isn't introducing some new form of concatenated > content - it is _just_ a regular DNS wire format message, and the > document should not go deeper into its explanation. > It would _not_ be correct to say that this is a "DNS wire format message" - that would mean there is a DNS header section with flags and response codes, and other sections. The chain data structure as currently specified really is concatenated wire-format RRs (as they appear _within_ a DNS message _section_). Let me know if that is unclear in the draft (or my proposed edits). I recall at one point way back there was a discussion about whether the chain data should just be a fully formed DNS message, but I don't believe that idea had much support in the working group (personally I would have been fine with that choice too, if it did have support). > I noticed some discussion about the ordering of this content. I am not > sure why that should be done. DNS doesn't care about the order, and > neither should producers or consumers of this extension. DNS has no > ordering inside its message. > Yes, that is in fact where we ended up, roughly. The draft does currently say that the answer record(s) appear first. And then the authentication chain records follow and that TLS client should be prepared to receive the authentication chain records in any order. Requiring the answer records first seems logical to me - it is what existing libraries do, and also what the EDNS chain query spec does (answer records appear first in the ANSWER section, and DNSSEC authentication chain records appear in the AUTHORITY section in any order). There is some residual wording in the draft about ordering of CNAMEs etc in the answer records part. Assuming the WG agrees, I am fine with relaxing that requirement - that ended up in there because although there is no defined ordering of RRs within a DNS message section, as a practical matter CNAMEs are almost always ordered since there are some DNS queriers that get confused otherwise. This is a new protocol though, so we can be more faithful to the DNS spec. I don't think getting unrelated DNSSEC records would be an issue. TLS > has its maximum sizes for the handshake. In fact, it could allow the > extension to have some useful data in the case of MX or SRV. (and could > be a feature to build a nice resolver over TLS using 1 tor circuit). > The draft currently doesn't address the MX or SRV use case. I suggest that we tackle that in a future version. I'm also not sure about the talking of unsigned CNAME records from > DNAME. The above pseudo code (extended with special cases) should be > in some DNS library, and that library will know what records to expect > unsigned which are proven by the DNAME (or wildcard) synthesis and knows > when/if to add it to the validated cache. I don't think that should be > explained in this RFC at all. The DNS implementation does not need > to be specified in this document and it should just focus on saying > that "the DNS message response is validated and upon validation the > content can be considered DANE validated". Where we ended up, is that WG participants asked for some level of DNSSEC detail to be included in this doc. Shumon.
- [TLS] Eric Rescorla's Discuss on draft-ietf-tls-d… Eric Rescorla
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Shumon Huque
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Eric Rescorla
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Viktor Dukhovni
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Eric Rescorla
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Shumon Huque
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Shumon Huque
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Viktor Dukhovni
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Shumon Huque
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Eric Rescorla
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Paul Wouters
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Paul Wouters
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Viktor Dukhovni
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Eric Rescorla
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Shumon Huque
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Shumon Huque
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Willem Toorop
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Paul Wouters
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Viktor Dukhovni
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Benjamin Kaduk
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Viktor Dukhovni
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Willem Toorop
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Shumon Huque
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Viktor Dukhovni
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Shumon Huque
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Nico Williams
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Nico Williams
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Nico Williams
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Shumon Huque
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Shumon Huque
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Viktor Dukhovni
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Paul Wouters
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Eric Rescorla
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Viktor Dukhovni
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Willem Toorop
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Willem Toorop
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Viktor Dukhovni
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Paul Wouters
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Paul Wouters
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Kathleen Moriarty
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Ilari Liusvaara
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Shumon Huque