IETF Logo Mail Archive

Re: [CDNi] Jon's commet on draft-ietf-cdni-redirection

"Peterson, Jon" <jon.peterson@neustar.biz> Thu, 15 October 2015 23:52 UTC

Return-Path: <jon.peterson@neustar.biz>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE13E1A8957 for <cdni@ietfa.amsl.com>; Thu, 15 Oct 2015 16:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.267
X-Spam-Level:
X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 QD7CQeTL98Kt for <cdni@ietfa.amsl.com>; Thu, 15 Oct 2015 16:52:08 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 6C66E1A8954 for <cdni@ietf.org>; Thu, 15 Oct 2015 16:52:08 -0700 (PDT)
Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t9FNhH3B012968; Thu, 15 Oct 2015 19:52:06 -0400
Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 1xjbnnh8e7-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 15 Oct 2015 19:52:06 -0400
Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Thu, 15 Oct 2015 19:52:05 -0400
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "Francois Le Faucheur (flefauch)" <flefauch@cisco.com>
Thread-Topic: Jon's commet on draft-ietf-cdni-redirection
Thread-Index: AQHRB0Sd6BAt8jKfVkKtIgZAGUcIrZ5tCBuA
Date: Thu, 15 Oct 2015 23:52:05 +0000
Message-ID: <D24513A6.162A5C%jon.peterson@neustar.biz>
References: <73F3A4F6-FC5D-4BC8-BEEC-82F27BA3641F@tno.nl> <102272CE-9EF0-4959-B9E2-8A2F10147BF7@cisco.com> <853CC284-D147-4A1F-8C47-213775F47768@cisco.com>
In-Reply-To: <853CC284-D147-4A1F-8C47-213775F47768@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.9.150325
x-originating-ip: [192.168.128.89]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <7058D5764B345E4F92C364D6D7297A93@neustar.biz>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-10-16_01:2015-10-15,2015-10-15,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1510150307
Archived-At: <http://mailarchive.ietf.org/arch/msg/cdni/QnFIlIbT2ZFwNwsrMHbR1nbTNIc>
Cc: "cdni@ietf.org" <cdni@ietf.org>
Subject: Re: [CDNi] Jon's commet on draft-ietf-cdni-redirection
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" <cdni.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cdni>, <mailto:cdni-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cdni/>
List-Post: <mailto:cdni@ietf.org>
List-Help: <mailto:cdni-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cdni>, <mailto:cdni-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Oct 2015 23:52:09 -0000

If I recall the substance of my comment was that the cdni-redirection
mechanism works for HTTPS redirection a lot more securely than for DNS
redirection, and that the particular problem with DNS redirection when
using HTTPS (that you will end up seeing a surprising certificate on the
other side of your TLS connection) should be noted since DNS redirection
is in scope of cdni-redirection draft. I don't think the problem needs to
be solved there, but it needs to be acknowledged. Because DNS responses
are insecure (barring DNSSEC), then using DNS for redirection can
introduce the problems discussed in draft-fieau-https-delivery-delegation.
Dropping in a reference to that draft, or summarizing the problem, would
suffice.

I don't think the text below really captures that. If this is super
confusing I can send text.

Jon Peterson
Neustar, Inc.

On 10/15/15, 5:25 AM, "Francois Le Faucheur (flefauch)"
<flefauch@cisco.com> wrote:

>Hi Jon,
>
>We¹ll wait a couple more days to hear back from you on the point below,
>and then move the document forward.
>
>Thanks
>
>Francois
>
>> On 7 Oct 2015, at 14:04, Francois Le Faucheur (flefauch)
>><flefauch@cisco.com> wrote:
>> 
>> Jon,
>> 
>> Can you confirm this new rev addresses your comment appropriately?
>> I believe the text that was added for that purpose is:
>> ³
>> 3.1.  Redirection of encrypted traffic
>> 
>>      The Redirection Interface defined in this document might be used to
>> 
>>      redirect a request where the User Agent will subsequently attempt
>>to
>> 
>>      establish a TLS session with the Redirection Target.  In such a
>>case,
>> 
>>      any surrogate or request router to which the User Agent is
>>redirected
>> 
>>      needs to be able to successfully complete the TLS handshake and to
>> 
>>      perform encryption of the TLS channel.  Mechanisms to distribute
>>the
>> 
>>      required information and/or configuration, such as private keys, to
>> 
>>      surrogates and request routers in dCDNs are outside the scope of
>>this
>> 
>>      document.
>> ³
>> 
>

v2.23.0 | Report a Bug | By Email