Re: [secdir] Secdir last call review of draft-ietf-uta-smtp-tlsrpt-17

Phillip Hallam-Baker <hallam@gmail.com> Tue, 13 March 2018 15:50 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E31A126C22; Tue, 13 Mar 2018 08:50:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, 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 JliTzj5aomEq; Tue, 13 Mar 2018 08:50:20 -0700 (PDT)
Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (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 3B83D1205F0; Tue, 13 Mar 2018 08:50:20 -0700 (PDT)
Received: by mail-ot0-x22a.google.com with SMTP id 79-v6so54629oth.11; Tue, 13 Mar 2018 08:50:20 -0700 (PDT)
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=dgfGdl1hsU9WapP5cN2aj8blAJ9sk7hT+T60G6+qo6s=; b=Ak/6jOeRBc3F3HVeXWsbZx7LOx65R4HlbBvvsL17PjDCt1r3AdHISxJyn8mHTdjx0a l1RtKOncdE2Vw9MWnTWuamY4OHaJROYzGLyIFp261ljs+/xwOZ5fCQWioDshyb/kYSi2 zjbivEWH/1My7w+3sp/zUqh5VIIr356kgQ4vxQBJp382rjATBCyuun+/1Ztp2fhKP62M T4jdTF+BO8Mphz9h89pz/uZGv5R6ekOt+dQ0D0baUpGdJi7K1rEDwCViigJo+qpQAzP1 HXPTShLt3k95mTwMSu6vZZPkBlkKQb9e0JASyapiSLSQoDWiaLydv4FAYh2AMSE86+4K LN0A==
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=dgfGdl1hsU9WapP5cN2aj8blAJ9sk7hT+T60G6+qo6s=; b=p8MNzp3qeXrGOjjVIacfm21SyM3XaLekbqg6ZKW5gqcjiHhBVFITAuuEsouxsS93Ok 1FZvjKjHxSDX3Fz3Mu2GkUynTORGwGxjUE42HAgTvFyQZtHsNvH6QkpRJgnjtG6t4C72 DgpzgviZGcYEpvXTna8I3kojImHhIhUiiAp9Xi5AAdSG96Tfyle1Y2jxH4yQ8cbCP4G0 kK5+UtvQ16hSEwJJUo6QwCCr5HjmMNEMN7Q1ftl4PyGybe09gb3RDAtXffRhpYU0jgu/ c/AZ/bLLIshH16QKnaVE2bc8pOzgLGX4DHzzYkRzUeQYIQn8N5cBCvPpcI+jz0qbNa3j OLAA==
X-Gm-Message-State: AElRT7ESOfZ+fYP2IlHwcJTZV/7ddoKjUHZ0YF8huEcYVrZZegDPu6wG uFCipc3jnblUSCbbP4nQ1voiZOJlw69YHDdVsfY=
X-Google-Smtp-Source: AG47ELurHm7SdONxJBYIYowkyGVbA7fzqGop1Iv9P++R8ULt4PSnugTaM+g3HWXpsgbe7jBuIQB20aHWSBkyxqNUyVg=
X-Received: by 10.157.62.93 with SMTP id h29mr232014otg.129.1520956219441; Tue, 13 Mar 2018 08:50:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:505:0:0:0:0:0 with HTTP; Tue, 13 Mar 2018 08:50:18 -0700 (PDT)
In-Reply-To: <e114c12f91fb442399cc37176fc685e0@COPDCEX19.cable.comcast.com>
References: <152053794569.13938.10396254284390037265@ietfa.amsl.com> <e114c12f91fb442399cc37176fc685e0@COPDCEX19.cable.comcast.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Tue, 13 Mar 2018 11:50:18 -0400
Message-ID: <CAMm+LwgRYAC1ZQE8AuO2kWNECyRUuV-s5hbXAuwsnARTw-e5yw@mail.gmail.com>
To: "Brotman, Alexander" <Alexander_Brotman@comcast.com>
Cc: "secdir@ietf.org" <secdir@ietf.org>, "uta@ietf.org" <uta@ietf.org>, "draft-ietf-uta-smtp-tlsrpt.all@ietf.org" <draft-ietf-uta-smtp-tlsrpt.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="f403045e1fae2dc82205674d3703"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Z8aYhI5Px8bhUlXVkjXa8rUgjZ0>
Subject: Re: [secdir] Secdir last call review of draft-ietf-uta-smtp-tlsrpt-17
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 13 Mar 2018 15:50:22 -0000

If folk are in London, lets talk to IANA and maybe some DNS folk.

I am pretty sure this is a straightforward issue. But it is one we need to
get right.



On Mon, Mar 12, 2018 at 6:34 PM, Brotman, Alexander <
Alexander_Brotman@comcast.com>; wrote:

> I'm not opposed to change this to be in that form.  I don't believe this
> would cause any technical issues.
>
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse
> Comcast
>
> -----Original Message-----
> From: Phillip Hallam-Baker [mailto:hallam@gmail.com]
> Sent: Thursday, March 08, 2018 2:39 PM
> To: secdir@ietf.org
> Cc: uta@ietf.org; draft-ietf-uta-smtp-tlsrpt.all@ietf.org; ietf@ietf.org
> Subject: Secdir last call review of draft-ietf-uta-smtp-tlsrpt-17
>
> Reviewer: Phillip Hallam-Baker
> Review result: Has Issues
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security area
> directors. Document editors and WG chairs should treat these comments just
> like any other last call comments.
>
> General comments:
>
> Five minutes after I received the review request, a very similar proposal
> was made in CABForum for reporting PKIX cert issues.
>
> The Security Considerations section proposes use of DNSSEC, what happens
> if that is misconfigured? Well it should be reported.
>
> The logic of this proposal is that something like it become a standard
> deliverable for a certain class of service specification. I don't think we
> should delay this and meta-think it. But we should anticipate it being
> joined by others like it sharing syntax, DDoS mitigation, etc.
>
> Specific issues
>
> The DNS prefix _smtp-tlsrpt is defined. This is not mentioned in the IANA
> considerations. It is a code point being defined in a protocol that is
> outside the scope of UTA and therefore MUST have an IANA assignment and is
> a DNS code point which is shared space and therefore MUST have an
> assignment.
>
> If no IANA registry exists, one should be created.
>
> In general, the approach should be consistent with the following:
>
> [RFC6763] S. Cheshire and M. Krochmal "DNS-Based Service Discovery" RFC
> 6763 DOI 10.17487/RFC6763 February 2013
>
> It might well be appropriate to create a separate IANA prefix registry
> 'report'. That is probably easier since this prefix does not fit well with
> the existing ones.
>
> _smtp-tlsrpt._report
>
>
>


-- 
Website: http://hallambaker.com/