Re: [Uta] draft-ietf-uta-mta-sts-04 Review

Daniel Margolis <dmargolis@google.com> Sat, 22 April 2017 17:11 UTC

Return-Path: <dmargolis@google.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 43A271294E2 for <uta@ietfa.amsl.com>; Sat, 22 Apr 2017 10:11:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 rb3lW_lx6CPO for <uta@ietfa.amsl.com>; Sat, 22 Apr 2017 10:11:14 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 3D2911294E1 for <uta@ietf.org>; Sat, 22 Apr 2017 10:11:14 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id 70so4310121ita.0 for <uta@ietf.org>; Sat, 22 Apr 2017 10:11:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bI6IswmyLUGdXzvqExrlcn2aiO2imTbdM93aw/0yTmY=; b=AtG+JcOYfjZoHg+wbSrxF+MpdQAT7cENTpUi6soiBTDwxF8D1hAcxBPs+0hteg3Udk VFOhXQ4JDvcG2kdPGTpveS4PqDAecFO8gF7T7MoLQMjCvBS1gROVFBxXSAfHcuclrhU3 BVPOoGa+1gLJyZFU6CC+1+Mlyl3c+GZr1Nc2T4Q0ehBvInOyS/BNnTizMtLfMqag1v65 3RvYNFmoIus300Gd7UaEl9H9cp7tMseVj9q1ZNRClCja3EqgN6D/n4/J7XK1lCGlBLzP 9283JXtyEFphx7KEZTm85cKszUJCM1W2A22FvpUma/RqDpUySCBVerkTP6AJEESEf8jk 3kqg==
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=bI6IswmyLUGdXzvqExrlcn2aiO2imTbdM93aw/0yTmY=; b=TFdr6TcZHOddk5YKYcpP6frFgALSAR0mklKEwBl56GOqEujdNnIDJBlcF+GPP7E2ZZ iTjxQBedp7GYh/P7czsdM0jrbqr4ZWHht/8COrUO0mlWkHsbY3se7ohFRqukJgQ286LV rKU7eQLPOV9wLGAORNKCMcapax4MGGFDlgFC1K/iLKWZXgH/x8Q69JlK8msMTFPpye6G jSGknCemyaXRMxFjI6oTWHnvuoh5NO1X9zJ41NfummB/4tb0cidCLSXbwt7hmPehfhHa lkE1ua3ciehGI9fE0w1+1W3ng5Kr9k3o4FB6kwpJuxaD7+Qj02IZUbVIBJqAQrxYOQuQ Fzuw==
X-Gm-Message-State: AN3rC/4JOyUwPMCahD96T6J2q5faoeLHcRSYxOyrPk3QgUQGCex0ix+U +hQ2pDVeseaHsFFjijj/5bZb6mk1ewcM
X-Received: by 10.36.152.196 with SMTP id n187mr4943716itd.28.1492881073063; Sat, 22 Apr 2017 10:11:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.111.11 with HTTP; Sat, 22 Apr 2017 10:11:11 -0700 (PDT)
In-Reply-To: <5c361c89-907b-ff65-8a11-8df08e0e46af@isode.com>
References: <2DB01F3A9898AE41BB3266315D9FDA2704903D88@S-DC-ESTE03-B.net1.cec.eu.int> <CANtKdUe3CS3A_czWURR_h9Z0r803sX-MQMZOMHioZJnCaauEWw@mail.gmail.com> <5c361c89-907b-ff65-8a11-8df08e0e46af@isode.com>
From: Daniel Margolis <dmargolis@google.com>
Date: Sat, 22 Apr 2017 19:11:11 +0200
Message-ID: <CANtKdUd2cu3BntMDPWiL-WKiDn1YyUMQm6bakMw++s9F8=65LA@mail.gmail.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Cc: Gerard.DRAPER-GIL@ec.europa.eu, uta@ietf.org
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="94eb2c05e9a21827f4054dc4761f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/2opAYAIJ98aNoGtplH0bAWo_W50>
Subject: Re: [Uta] draft-ietf-uta-mta-sts-04 Review
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: Sat, 22 Apr 2017 17:11:16 -0000

Thanks for the pointer.

Yes, I of course have no objections to checking CRL or OCSP. Given the
mixed state of deployments among browsers, it merely seems worrisome to me
to *require* that. MAY seems like a good clarification to have here.

On Tue, Apr 18, 2017 at 6:23 PM, Alexey Melnikov <alexey.melnikov@isode.com>
wrote:

> Hi Daniel,
>
> On 18/04/2017 17:15, Daniel Margolis wrote:
>
> On Thu, Apr 6, 2017 at 11:08 AM, <Gerard.DRAPER-GIL@ec.europa.eu> wrote:
>
>
> _ Section 3.3 HTTPS Policy Fetching
>>
>>
>>
>> "When fetching a new policy or updating a policy, the HTTPS endpoint
>>
>> MUST present a X.509 certificate which is valid for the "mta-sts"
>>
>> host (as described in [RFC6125]), chain to a root CA that is trusted
>>
>> by the sending MTA, and be non-expired."
>>
>>  Maybe it's redundant, but since it explicitly mention non-expired,
>>
>> should it also mention not revocated?
>>
>
> Do relevant RFCs for HTTPS specify CRL/OCSP checking? If not--and in
> practice it varies by implementation, such that some major browsers do not
> implement one or the other--I would not want to mandate it here, even if
> it's a good idea.
>
> (And I agree it's a good idea in the abstract, but to my very limited
> knowledge, the state of deployment is haphazard, so it seems a bit risky to
> require it.)
>
>
> RFC 5280 mention it. I think you need to make it clear that checking OCSP
> is not prohibited here. (Maybe say "MAY use OCSP to check for revocation"
> or similar.)
>
> Best Regards,
> Alexey
>
>
>
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta
>
>