[Uta] Review of draft-ietf-uta-mta-sts-04

Alexey Melnikov <alexey.melnikov@isode.com> Wed, 19 April 2017 11:06 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014D21294A5 for <uta@ietfa.amsl.com>; Wed, 19 Apr 2017 04:06:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 syvtWs9ncnfy for <uta@ietfa.amsl.com>; Wed, 19 Apr 2017 04:06:04 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 5F76E129489 for <uta@ietf.org>; Wed, 19 Apr 2017 04:06:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1492599963; d=isode.com; s=june2016; i=@isode.com; bh=4Dr288JgOSePKV5HzK+CmGcfNHJ0bdnTHytGyVA1B+c=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=eOzl2v8mHcw1Ai066Ok1C3gpGab6MqwGRVsTXa4KkIWOZq5WQYeuqhsRZTJiYDhFk+wZql LPqKxqz8KOPf7iXQkR2lzSuKhyBq27YAzj/G96larCMTjMtBGNiXLC3FM3WBRM9YKQSmOq 1wxTKWLEuZVlR4Q2K8JDMzHFNTdtKHs=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <WPdEmgB2XYoS@waldorf.isode.com>; Wed, 19 Apr 2017 12:06:03 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
To: "uta@ietf.org" <uta@ietf.org>
Message-ID: <ba6b46ba-ad6b-2270-0113-3e8006ef5a8b@isode.com>
Date: Wed, 19 Apr 2017 12:05:47 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/YE4SKCnbdAemNevDI_E7YQ6Dbxg>
Subject: [Uta] Review of draft-ietf-uta-mta-sts-04
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Apr 2017 11:06:06 -0000

Hi,
Below is my early "AD review" of the document. I think it is in pretty 
good shape and is ready for WG Last Call (I am Ok with the question of 
JSON versa something else be settled during or after WGLC.)

1) In 1.1:

    o  Policy Domain: The domain for which an MTA-STS Policy is defined.
       This is the next-hop domain; when sending mail to
       "alice@example.com"; this would ordinarly be "example.com", but
       this may be overriden by explicit routing rules (as described in
       "Policy Selection for Smart Hosts").

Nit: This needs an internal section reference.
I think there was another place in the document when an internal section 
number is not mentioned.

2) In 3.1:

       sts-version     = "v" *WSP "=" *WSP %x53 %x54        ; "STSv1"
                         %x53 %x76 %x31

Do you intend for this to be matched case-sensitively?
What you wrote above is that "v" is case-insensitive, but "STSv1" is.

3) Section 3.2 says that unrecognized fields are to be ignored, so you 
need to update ABNF in 3.1 to make it clear.

Current ABNF:

       sts-text-record = sts-version *WSP %x3B *WSP sts-id [%x3B]

       sts-version     = "v" *WSP "=" *WSP %x53 %x54        ; "STSv1"
                         %x53 %x76 %x31

       sts-id          = "id" *WSP "=" *WSP 1*32(ALPHA / DIGIT)

I suggest something like the following (this implies that position of 
the first 2 fields is fixed, extensions at the end. If you prefer that 
any fields are in any order (other than the version), I can update the 
ABNF):

       sts-text-record = sts-version *WSP field-delim *WSP sts-id 
[field-delim [sts-extensions]]

       field-delim     = %x3B

       sts-version     = "v" *WSP "=" *WSP %x53 %x54        ; "STSv1"
                         %x53 %x76 %x31

       sts-id          = "id" *WSP "=" *WSP 1*32(ALPHA / DIGIT)

       sts-extensions  = sts-extension *(field-delim sts-extension) 
[field-delim]
                         ; Extension fields at the end in any order

       sts-extension   = sts-ext-name *WSP "=" *WSP sts-ext-value

       sts-ext-name    = (ALPHA / DIGIT) *31(ALPHA / DIGIT / "_" / "-" / 
".")

       sts-ext-value   = 1*(%x21-3A / %x3C / %x3E-7E)
                         ; like esmtp-value from RFC 5321, but doesn't 
allow ";".
                         ; So basically any CHAR excluding "=", ";", SP, 
and control
                         ; characters.

4) In 3.2: Should "SHOULD ignore unrecognized fields" be a MUST? I.e., 
why would it not be Ok to ignore unrecognized fields?

5) In 3.3: RFC 6125 use needs more details, because you need to specify 
answers to every question in section 3 of RFC 6125.
In particular you should say that when checking certificates, you only 
use DNS-ID and CN-ID (SRV-ID and URI-ID are not used) and that you allow 
wildcards in them.

6) Last para on page 7: this is also true in RFC 6125.

7) In 5.1, last para: I think you mean that if there are too many 
failures to deliver when using MTA-STS, regular SMTP rules for 
generating a bounce apply? I think this needs rewording to say that.

8) If you want to allow for extensibility, you probably need an IANA 
registry of fields allowed, so that developers can find them easily. I 
can help with some text.

9) On page 13: I think pseudocode should make it clear that you retrieve 
DNS-ID SAN.

Best Regards,
Alexey

P.S. I might have a couple of extra items, but I need to double check a 
few things first.