Re: [secdir] secdir review of draft-ietf-dane-srv-12

Peter Saint-Andre - &yet <peter@andyet.net> Tue, 14 April 2015 17:02 UTC

Return-Path: <peter@andyet.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9931B2EE9 for <secdir@ietfa.amsl.com>; Tue, 14 Apr 2015 10:02:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 LZSUs6ztPkLH for <secdir@ietfa.amsl.com>; Tue, 14 Apr 2015 10:02:15 -0700 (PDT)
Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (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 0F5301B2F36 for <secdir@ietf.org>; Tue, 14 Apr 2015 10:02:12 -0700 (PDT)
Received: by iedfl3 with SMTP id fl3so22753354ied.1 for <secdir@ietf.org>; Tue, 14 Apr 2015 10:02:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TGWsB3s020s9RPatNjN8wB8kQVqhhoswFRsJKfv9964=; b=RTaV49NlwGFDtEpeynEwEtg8abmbm9wnkVLpfs8GIzJquEnd5yEkboivL4I01NUepJ H8h0qe7BddK5+SppmJtnHIuaVY+FXg3hdQIk3bV5KJ4231PPgqzHgIvvvXE294uyrAMe VZ/XzIRzc+uIc+dGgrWW1VMQHxIANQRkRd19gvnVvuS99UW1hQ2wXJ/upnH0Bjgn7kQT m/qnZEJdk5UuZDtabRn96PSbkfHCuOCxWuvsadkjS4WBemm44l0F4/+gIXyY0OEiHJzB RznO3Ah1py71GnKat85ebvVSQWJN0Qk375d+lgieY1d3o4+pjr8N+fcUb5d6YeZoL4/R 15yQ==
X-Gm-Message-State: ALoCoQmvPPH7ZkESLe4vzq4EK1oEKFwhQPEmSnDvdxZGwOXaJoYVxog7QtJ44hWXGdxB4g4Ijgpq
X-Received: by 10.50.143.42 with SMTP id sb10mr25429834igb.49.1429030931433; Tue, 14 Apr 2015 10:02:11 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id l128sm780371iol.1.2015.04.14.10.02.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Apr 2015 10:02:10 -0700 (PDT)
Message-ID: <552D4811.7010507@andyet.net>
Date: Tue, 14 Apr 2015 11:02:09 -0600
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Carl Wallace <carl@redhoundsoftware.com>, mamille2@cisco.com, dot@dotat.at
References: <D1517899.32B98%carl@redhoundsoftware.com> <D15178CF.32BA3%carl@redhoundsoftware.com> <552C229C.1030701@andyet.net> <D1528310.32CC0%carl@redhoundsoftware.com>
In-Reply-To: <D1528310.32CC0%carl@redhoundsoftware.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/O74VKjjNDfRQ6Jl17oaOkJKbeHA>
Cc: The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-dane-srv-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Apr 2015 17:02:16 -0000

On 4/14/15 6:58 AM, Carl Wallace wrote:
>
>
> On 4/13/15, 4:10 PM, "Peter Saint-Andre - &yet" <peter@andyet.net> wrote:
> <snip>
>>>> In section 1
>>>> - May be worth adding a note to the third bullet to clarify that
>>>> multiple
>>>> target endpoints may be defined for a given service domain, including a
>>>> mix of endpoints that have and do not have TLSA records.
>>
>> IMHO that's implicit, but maybe it would be clearer if we say something
>> like this:
>>
>> OLD
>>     o  When DNSSEC-validated TLSA records are published for a particular
>>        connection endpoint, clients always use TLS when connecting (even
>>        if the connection endpoint supports cleartext communication).
>>
>> NEW
>>     o  When DNSSEC-validated TLSA records are published for a particular
>>        connection endpoint, clients always use TLS when connecting (even
>>        if the connection endpoint supports cleartext communication
>>        or some SRV records for the service domain map to connection
>>        endpoints that do not support TLS).
>
> I think you are right a second bullet is better but if changing this
> maybe: When DNSSEC-validated TLSA records are published for a particular
> connection endpoint, clients always use TLS when connecting to that
> connection endpoint even if the endpoint supports cleartext communication.
>
>>
>> Is that what you had in mind? Do you feel it's helpful? I'm not so sure,
>> myself. Instead, I wonder if the point would be better handled by adding
>> another bullet point, such as:
>>
>>     o  Although in accordance with [RFC2782] a service domain can
>>        advertise a number of SRV records (some of which might map to
>>        connection endpoints that do not support TLS), the intent of this
>>        specification is for an endpoint to securely discover connection
>>        endpoints that support TLS.
>>
>> Does that capture your suggestion?
>
> Mostly, though I was thinking of endpoints that supported TLS but did not
> publish TLSA.

Ah, thanks for the clarification - I had not understood your concern.

> The new bullet seems a little out of sync with the security
> considerations w.r.t. the intent of the spec, which claims no special
> effort is made to accommodate mixed results.

As I see it, the purpose of this spec is to document how SRV and TLSA 
records interact with the intent that a client can securely discover at 
least one connection endpoint that supports TLS, and then establish a 
TLS-protected connection to the service domain at that endpoint.

Although that is the focus here, of course we don't want to degrade 
security in any way, so it's important to mention appropriate caveats.

> Maybe: In accordance with
> [RFC2782] a service domain can advertise a number of SRV records (some of
> which might map to connection endpoints that do not support TLS or that
> support TLS but do not publish TLSA records), this specification enables
> clients to securely authenticate connection endpoints that support TLS and
> publish TLSA records.

Strictly speaking, a connection endpoint does not publish TLSA records, 
since that's the responsibility of the service domain.

     o  In accordance with [RFC2782] a service domain can advertise a
        variety of SRV records; some of these might map to connection
        endpoints that do not support TLS, and others might map to
        connection endpoints that support TLS but for which no TLSA
        records are available. This specification makes no special
        effort to accommodate such mixed results, since it is focused on
        enabling a client to securely discover at least one connection
        endpoint that supports TLS and then to establish a TLS-protected
        connection to the service domain.

Somehow that feels awfully wordy for an informational summary, but if it 
is accurate and causes no harm then we might as well include it...

Peter