IETF Logo Mail Archive

Re: [TLS] Alexey Melnikov's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

Shumon Huque <shuque@gmail.com> Wed, 21 February 2018 16:06 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 2606012D870; Wed, 21 Feb 2018 08:06:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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] 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 rekCMnLrJqgk; Wed, 21 Feb 2018 08:06:50 -0800 (PST)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 6A3F012D7F8; Wed, 21 Feb 2018 08:06:50 -0800 (PST)
Received: by mail-io0-x232.google.com with SMTP id b34so2648895ioj.6; Wed, 21 Feb 2018 08:06:50 -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=hzd5z9oYQ9YZKHT3pfPnFo/DRRgD+yzzvFHTTv5Cyjc=; b=Spo/61T9GvEM3bPr8YRdgNEBa5vlG3VXnrGR0cIjpFMPGO9sANYiovshI5YUp4o9rf AV81K7zp6T3XjSIx8kT/xABsVSfFjsreMln8fkBdkIik8byrHHJ8pfVET9o1ruKBROCk iElmhMNeQf9nt7xG1LJU9Nu4ftgyk/QflFiRfEGLoIS59/QUx+6cVO5LXsQl55ZGFff/ Y5COn2l07X/nkQsPFFVIo/5KZIarb9VgY9kJAYVBGkmXO13MBqj9hqVjRNveRSzDnIyn 6QnFkmxyyPP/Ctp4DcA81K4JPiz49RyB0S17laQuyT1DFqJqmjsWLvzW7kleR5z7vrY0 EAGA==
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=hzd5z9oYQ9YZKHT3pfPnFo/DRRgD+yzzvFHTTv5Cyjc=; b=m70EjvDFysarPkTpsvJl6AsvPrdHajLltkid7UD7zNUO0+uYFinrP5+KW1zjxCFgxk h9+TbuLuFXDDgN1MD9ZqxZVjBhZRnd32ZXOXyeSLLkw2ENptO+++MNiF0HkzzEC3tVEy LFLJt6QvfCUxoCyH2KfxoMU1TyDSQf1Y/02mG3HGxiTNNvjVfVdjJVO2MnVjpDfIGGAW Bnhv8vQOm7zem6eDfsnBSac/Q1/NGX+2VEOZvi17JOdKXbPqCke4otGGk/QOzyOb+/G5 +OKwnLQwkf78Qlw2I534AWg6GHuyi4TUo+8x8dnTpk/EpRjwGzGaVJWr/wp40OLKAhIR d7Nw==
X-Gm-Message-State: APf1xPB8YC9XKanZLXCkYF9XlqTcq4RACkpLPhfFlANwKenhHpB6rXrm uZaWf7E2I0mRJruaBdGMv6H7y6GStc/Lh8CfLH/4Tg==
X-Google-Smtp-Source: AH8x225KW1uPGffiazUQautXaJ6vS/a3m/SDUolr3tNYw/u09QJk7IRcNIzCoADscJP/1GaX184YIO+B094G9zyFHyc=
X-Received: by 10.107.29.205 with SMTP id d196mr4937515iod.18.1519229209616; Wed, 21 Feb 2018 08:06:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.79.201.198 with HTTP; Wed, 21 Feb 2018 08:06:49 -0800 (PST)
In-Reply-To: <CAHPuVdUmPPFY2rxq0cdtwGaoDJ0Bkdt1PFsQmVm3Et5n9cU_Uw@mail.gmail.com>
References: <151802776446.4849.12008167318274714913.idtracker@ietfa.amsl.com> <CAHPuVdUmPPFY2rxq0cdtwGaoDJ0Bkdt1PFsQmVm3Et5n9cU_Uw@mail.gmail.com>
From: Shumon Huque <shuque@gmail.com>
Date: Wed, 21 Feb 2018 11:06:49 -0500
Message-ID: <CAHPuVdXF1j83r_4zRWc6pR7jB8LO9BWgj6KZv9FS52Fb+jj+8w@mail.gmail.com>
To: Alexey Melnikov <aamelnikov@fastmail.fm>
Cc: The IESG <iesg@ietf.org>, draft-ietf-tls-dnssec-chain-extension@ietf.org, Joseph Salowey <joe@salowey.net>, tls-chairs <tls-chairs@ietf.org>, TLS WG <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a1140a7445f6a860565bb1d3a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/4FYSR54xIifeENt8wPiqcx0blPQ>
Subject: Re: [TLS] Alexey Melnikov'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: Wed, 21 Feb 2018 16:06:52 -0000

On Wed, Feb 7, 2018 at 9:05 PM, Shumon Huque <shuque@gmail.com> wrote:

> On Wed, Feb 7, 2018 at 1:22 PM, Alexey Melnikov <aamelnikov@fastmail.fm>
> wrote:
>
>> Alexey Melnikov has entered the following ballot position for
>> draft-ietf-tls-dnssec-chain-extension-06: Discuss
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> I think this is a useful document and I will ballot Yes once my small
>> issues are resolved:
>>
>> 1) In 3.4:
>>
>>    The first RRset in the chain MUST contain the TLSA record set being
>>    presented.  However, if the owner name of the TLSA record set is an
>>    alias (CNAME or DNAME), then it MUST be preceded by the chain of
>>    alias records needed to resolve it.  DNAME chains should omit
>>
>> SHOULD? What are the implications if this is not followed?
>>
>
> Ok. I guess we need the upper case word here, yes.
>
> Implication: If the synthesized CNAME records are included in the chain
> then the client will have to ignore them (they aren't signed and thus
> can't be
> validated) - the signed DNAME record is sufficient for the client to
> securely
> validate the mapping and continue processing.
>
> It might make things simpler to just make this a MUST. I would guess this
> would not raise any objections from the working group.
>

A quick follow-up on this. I think we just keep this as a SHOULD. I looked
at what an existing DNS library implementation does, and it includes the
synthesized CNAME. It's easy enough for the client to just ignore it when
validating the chain.

Shumon.

v2.23.0 | Report a Bug | By Email