IETF Logo Mail Archive

Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

"Salz, Rich" <rsalz@akamai.com> Thu, 30 August 2018 14:13 UTC

Return-Path: <rsalz@akamai.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B01E130E58; Thu, 30 Aug 2018 07:13:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level:
X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 3k-A4NFrMRiJ; Thu, 30 Aug 2018 07:13:48 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77C73130E24; Thu, 30 Aug 2018 07:13:48 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w7UEBvBu026954; Thu, 30 Aug 2018 15:13:48 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=0SPQs14yU6w+pytG0tIEueXBxfvqweukjx78qR8FTe8=; b=eajNo/QMGPJrhmFdoIWQ3mmIwbOao1/zlG0qvk5P63HylIbI4xFtrx04MqHGznz6bwgG tbOf2WDUwd+mJ51QA/4fftsAlQ06gTJwtNlI//6gMFbRZJ7hkg2oKTFvaFQq+PYAXrJy DFESOpSCWDe4EUnw2f4D8NIhsbIA1jclordY36xMPk8wQDvV7WOOly4BtpS7BEDO7TAG +RW9GH8aY4detFP6OBL4MLF64JrB2RvJXvPxbXxnYPsKzodvxYCmNUaVV/ja8AGm0T5/ 1YFqmNMulQhXeaGy252CqnrmqoXbK4DatWSeh8ydlKTr3gMwC63btz7g2fsukXbhUgKy Tg==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050095.ppops.net-00190b01. with ESMTP id 2m5w3jkkfs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Aug 2018 15:13:47 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w7UE5EoN010207; Thu, 30 Aug 2018 10:13:46 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint1.akamai.com with ESMTP id 2m32ev95bp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 30 Aug 2018 10:13:45 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 30 Aug 2018 10:13:45 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1365.000; Thu, 30 Aug 2018 10:13:45 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: Richard Barnes <rlb@ipv.sx>, Adam Roach <adam@nostrum.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-acme-acme@ietf.org" <draft-ietf-acme-acme@ietf.org>, IETF ACME <acme@ietf.org>
Thread-Topic: Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
Thread-Index: AQHUQBz+hoOlty8ouU2i67BLdEbZL6TYhEMA///SvwA=
Date: Thu, 30 Aug 2018 14:13:44 +0000
Message-ID: <33EF29F5-3B83-48D3-A3B0-EA6D67D4A50A@akamai.com>
References: <153560463159.14901.5253843942494748934.idtracker@ietfa.amsl.com> <CAL02cgS0_d5qfraPoN2rmrZ9qGqmVdGdHu_a8knNkFcD1kcwpQ@mail.gmail.com>
In-Reply-To: <CAL02cgS0_d5qfraPoN2rmrZ9qGqmVdGdHu_a8knNkFcD1kcwpQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.0.180812
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.32.213]
Content-Type: text/plain; charset="utf-8"
Content-ID: <7BF900D34D1A0F4B95BF71C427488E53@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-30_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=795 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808300147
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-30_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=784 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808300148
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/zs8twkVdmnCL7PwUAEbufi5h8TE>
Subject: Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Aug 2018 14:13:50 -0000

> I guess you could argue that if you made a random URL and only
    distributed it in authenticated channels, then you could allow GETs to it,
    using the URL itself as an authenticator.

Yuk.

We have seen too many instances where "guessable" private URL's exposed data where they shouldn't.  I don't think treating URL's as both the content-id and a security token is the way to go.

v2.23.0 | Report a Bug | By Email