From nobody Mon Aug 1 13:55:31 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A927C12D8AB for ; Mon, 1 Aug 2016 13:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-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 sgQuvdwz_M5J for ; Mon, 1 Aug 2016 13:55:27 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (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 5EF1D12D9D0 for ; Mon, 1 Aug 2016 13:55:27 -0700 (PDT) Received: by mail-pa0-x22f.google.com with SMTP id pp5so55989750pac.3 for ; Mon, 01 Aug 2016 13:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=79jSj7QeF+HDIzsUD0n4RdAcrD9UxAUck6Ry/jo5fk0=; b=G2KtCaXKOKR9uJPNpxP2+YEzLmMLzaecIJgfe6Z35trfV3DFUnxhhgpqNP4zIAZb3z jleETkmxTn/3+U7PGy8Ow/Ih2j9MNBKmr4jlz4o+nGR7jaHkfMdjhs/WHbsQ6+eH92hI IL+vIOIftRr/5kEnMvwEga/lLCN7NjipwKjx1NlukRiLB3olfladw3rov6+GMLkxJNCE g26/5zz/EzO5hpWVtDgzlZVNZU9u27F4pZ6UeBS4tTVweQC5MlPoGKOJcS95Xaw9xwGD qeOvtRC9WhHIDWtVjVJ5ljRdCZoBGbvHSraAECwairm8swJAdNlhFQ9kvwYfW3MUTUqy et0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=79jSj7QeF+HDIzsUD0n4RdAcrD9UxAUck6Ry/jo5fk0=; b=KVqWIF60rDs/D8erM5fbWLxDFUXejDLPfBkg1cGECO7PRm48xW2onVuy5yORHxVCkT 1By/gHyJigvwwFU8ve2RjhZF+ELRpkIOEVb368Yc5MkuL/Zh3Fcqa2W1221jwXj07Vzx Ms9JV2W8+lG/cVyjZULK2k31Hu10juAch0aCo1LWdF7zVknYIUiz26dXWgX/nYM0Brgk uA3j0W2glOtVDna1bubUnpd2fI8dIe5qMQRE3PcuePkpiUzO8f3IWVI7QIG/S8X+qAHV oaiyXsmlh2f7lEKgGCFSSM4NbdO/mGgOlqsr5rfvn0P+SHfQmEhbKRk4yANo1izS5IV2 dKKg== X-Gm-Message-State: AEkoous9Eg36/0NuiHmOit5pl6ZJvSCXTyNOoeWxIlSW+RDgjW4xz8Judp/jvoYzEHhuxQ== X-Received: by 10.66.74.133 with SMTP id t5mr100898476pav.114.1470084926807; Mon, 01 Aug 2016 13:55:26 -0700 (PDT) Received: from [192.168.0.13] ([1.42.251.142]) by smtp.gmail.com with ESMTPSA id r21sm47802671pfi.52.2016.08.01.13.55.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 01 Aug 2016 13:55:25 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C6FC97D9-1C05-4B85-B35B-B5A6F007D803" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: James Winterbottom In-Reply-To: Date: Tue, 2 Aug 2016 06:55:20 +1000 Message-Id: <7B1495C7-CBB8-46A4-85C8-FEF0545CD0D0@gmail.com> References: <7BB6D8A6-86E4-48BE-A526-B8963791009A@gmail.com> <7a228246-90f0-3fc0-58f0-dc014897a6e4@alum.mit.edu> To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Strong concerns with location encoding in draft-vrs-rue-dispatch-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 20:55:31 -0000 --Apple-Mail=_C6FC97D9-1C05-4B85-B35B-B5A6F007D803 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks Gunnar, I very much support the concern of once it is implemented it is here to = stay and that once the Geo URI is used for this application the flood = gates will open for everything else. The draft talks heavily about the North American situation, and even the = authors' comments seem to suggest that North America is the focus of the = solution. I wonder if, rather than risking the above, whether this = specification might not better fit into NENA or ATIS or has that path = already been considered? Cheers James > On 1 Aug 2016, at 4:43 PM, Gunnar Hellstr=F6m = wrote: >=20 > Den 2016-07-26 kl. 23:32, skrev Paul Kyzivat: >> On 7/26/16 5:07 PM, James Winterbottom wrote:=20 >>> Thanks Henning and Paul,=20 >>>=20 >>> The argument still feels a bit like =93we don=92t have anything = today, HELD=20 >>> is too heavy weight, give us encoded location in the header=94. I = guess my=20 >>> worry with this is two fold:=20 >>> 1) providing this means there is never an incentive to move towards = a=20 >>> more standardised location approach, I will cite the eCall MSD is a = good=20 >>> example of where this has occurred.=20 >>> 2) It gives the first push down the very long slide of =93geo URIs = are=20 >>> fine for conveying target location=94.=20 >>=20 >> I think the incentive to move will be NG911.=20 >>=20 >> Also, this is a small community that operates under rules set by the = FCC.=20 >>=20 >>> My strongest preference would be to find someway for this to provide = a=20 >>> serious stepping-stone towards NG formats and protocols, rather than=20= >>> providing a mechanism that once implemented gives no incentive to = move=20 >>> mainstream.=20 >>=20 >> Just including location is a big step. And currently the VRS = providers handle their 911 calls via separate providers, using static = location information. Working through moving to dynamic location = information will also be a step.=20 >>=20 >> Thanks,=20 >> Paul=20 >>=20 >>> It would be good to hear if anyone else on the list has similar = concerns.=20 > GH: I see this as a step towards eternal interoperability problems and = finally requirements for geo: location acceptance in the NGxxx services.=20= >=20 > Some reasons: >=20 > When the services get direct interface with NG9-1-1, they will be = required to deliver location according to RFC 6442. Then it will be = tempting to force the terminals to do so from the source. But then the = terminals may need to deliver GEO: to some vrs services and PIDF-LO in = other calls, depending on at what step the services are in adaptation to = NG9-1-1.=20 >=20 > Further delaying proper multipart body handling in UEs and servers is = not good. More and more RFCs are appearing that require multipart body = handling. Support of RUE:s could instead be a good incentive to get = multipart body support implemented. >=20 > In the introduction, it is stated:=20 > " > This RUE profile supports the requirements of relay services in the > United States, as described in 47 CFR 64.601 et seq., but may be > applicable to similar uses elsewhere." >=20 > " > This limitation to USA should be stated in the scope as well. There = are many US-specific aspects in the draft that need to be modified = before applied elsewhere. The MUST for use of GEO: is likely one of = them. If not, the conflict between use of geo: and rfc 6442 compliant = location will spread. >=20 > What is the goal for the draft? Does it have ambitions to be = dispatched and accepted as a WG document?=20 >=20 > Regards > Gunnar >=20 >>>=20 >>> Cheers=20 >>> James=20 >>>=20 >>>=20 >>>> On 27 Jul 2016, at 2:17 AM, Henning Schulzrinne=20 >>>> = = > wrote:=20 >>>>=20 >>>> [Typing this from the Athen's airport]=20 >>>>=20 >>>> Adding to this:=20 >>>>=20 >>>> In this particular use case, there is indeed a "device location" - = the=20 >>>> only location reported is what the handset (Android/IOS) device=20 >>>> believes the location is - and this better be the location of the=20= >>>> device, not something else. Anything else would be a bug or = malicious=20 >>>> location spoofing. There is no HELD or other external reference = involved.=20 >>>>=20 >>>> Given that the privacy indicators convey no information in this = case=20 >>>> (and thus would have to be hard-coded to the no-restrictions values = to=20 >>>> avoid emergency call failures), I fail to see the substantive, as=20= >>>> opposed to protocol-lawyering, difference. The information is going = to=20 >>>> be exactly the same, whether I do this by cdata PIDF-LO attachment=20= >>>> "legally" or by geo URL "illegally".=20 >>>>=20 >>>> Also, the VRS 911 situation is somewhat unique in that there are = three=20 >>>> entities involved in the call: the VRS provider and its = communication=20 >>>> assistant (the person translating between voice and ASL), a=20 >>>> third-party emergency service provider and the PSAP with related=20 >>>> system service providers. Until native NG911/i3 is common, the most=20= >>>> likely case is that the VRS provider will pick apart the SIP = request=20 >>>> and inject the location via a proprietary API.=20 >>>>=20 >>>> All three entities have their own data retention and disclosure = rules,=20 >>>> which may vary by state, and are likely unknown upstream.=20 >>>>=20 >>>> Given the absence of HELD in this environment, at least for the=20 >>>> foreseeable future, insisting on carrying the same information in = an=20 >>>> XML attachment instead of a header, means that the emergency calls=20= >>>> need a completely different code path since they are the only ones=20= >>>> with multi-part. This is seen as a really bad trade-off of = reliability=20 >>>> and simplicity vs. formal requirements that serve no obvious = privacy=20 >>>> or functionality purpose.=20 >>>>=20 >>>> If there's a technical argument, rather than a legalistic one, = please=20 >>>> explain in more detail, as I'm obviously missing it.=20 >>>>=20 >>>> I assume you mean "illegal" figuratively, as I might need to get a=20= >>>> protocol lawyer otherwise :-)=20 >>>>=20 >>>>=20 >>>> Henning=20 >>>>=20 >>>> = ------------------------------------------------------------------------=20= >>>> *From:* dispatch =20 >>>> = > on behalf of Paul Kyzivat=20 >>>> = >=20 >>>> *Sent:* Tuesday, July 26, 2016 11:20:08 AM=20 >>>> *To:* dispatch@ietf.org = =20 >>>> *Subject:* Re: [dispatch] Strong concerns with location encoding in=20= >>>> draft-vrs-rue-dispatch-00=20 >>>>=20 >>>> James,=20 >>>>=20 >>>> Henning is traveling, so we may not hear from him for a bit.=20 >>>>=20 >>>> Using geo: was not my first choice, precisely because it isn't = included=20 >>>> among the permissible ways of conveying the information. But it is = a=20 >>>> hard sell among the VRS community. For this use the alternative = would be=20 >>>> putting the location in the body, which is felt to be complex.=20 >>>>=20 >>>> Note that the context for this usage is only 911 calls. I got the=20= >>>> following private comment from Henning:=20 >>>>=20 >>>> > Privacy indicators in US 911 SIP requests are both meaningless = and=20 >>>> > possibly disruptive. Since US VRS and 911 retention and = disclosure=20 >>>> > policies are given by law and custom and not subject to user = control,=20 >>>> > there are only two options:=20 >>>> >=20 >>>> > (1) Ignore the settings in PIDF-LO, i.e., the user believes one = thing=20 >>>> > that's happening, but reality is something else.=20 >>>> >=20 >>>> > (2) Reject the 911 call, since the VRS provider and 911 provider = cannot=20 >>>> > and will not honor the requested privacy policy. Clearly not = acceptable.=20 >>>>=20 >>>> (I'm not personally familiar with the US regulations - I trust = Henning=20 >>>> on this.)=20 >>>>=20 >>>> The current situation is that VRS users *are* using mobile devices = for=20 >>>> 911 calls, and the location initially communicated for those calls = is=20 >>>> currently *static*. The actual location must be provided within the = call=20 >>>> by the deaf caller, using ASL. We are trying to improve on that.=20 >>>>=20 >>>> Thanks,=20 >>>> Paul=20 >>>>=20 >>>> On 7/25/16 4:51 AM, James Winterbottom wrote:=20 >>>> > Hi Paul and Henning,=20 >>>> >=20 >>>> > I was reading through your draft but had to have a double take in=20= >>>> > Section 11.4, it says the following:=20 >>>> >=20 >>>> > "=20 >>>> >> location information MUST be conveyed with a "geo:" URI in a=20 >>>> >> Geolocation header field, as defined in [RFC5870 = = ].=20 >>>> >>=20 >>>> >> (While section 4.1 of [RFC6442] = = prohibits this usage,=20= >>>> the reasons=20 >>>> >> for doing so do not apply to emergency calls.)=20 >>>> > =93=20 >>>> >=20 >>>> > The problem here that this is an illegal used of the encoding in = RFC=20 >>>> > 5870. The reason is that the way it is being used directly = identifies as=20 >>>> > device or user and so it falls subject to the requirements of a = Geopriv=20 >>>> > using protocol. =46rom section 9.2 of RFC 5870:=20 >>>> > "=20 >>>> >> A 'geo' URI by itself is just an opaque reference to a physical=20= >>>> >> location, expressed by a set of spatial coordinates. This = does not=20 >>>> >> fit the "Location Information" definition according to = Section 5.2 = of=20 >>>> >> GEOPRIV Requirements [RFC3693 = = ], because there is not necessarily = a=20 >>>> >> "Device" involved.=20 >>>> >>=20 >>>> >> Because there is also no way to specify the identity of a = "Target"=20 >>>> >> within the confines of a 'geo' URI, it also does not fit the=20= >>>> >> specification of a "Location Object" (Section 5.2 of RFC 3693 = = ).=20 >>>> >>=20 >>>> >> However, if a 'geo' URI is used in a context where it = identifies the=20 >>>> >> location of a Target, it becomes part of a Location Object = and is=20 >>>> >> therefore subject to GEOPRIV rules.=20 >>>> >>=20 >>>> >> Therefore, when 'geo' URIs are put into such contexts, the = privacy=20 >>>> >> requirements of RFC 3693 = = MUST be met.=20 >>>> > =93=20 >>>> > In order for encoding of location to proceed in this form for the = VRS=20 >>>> > application I think far better rationale needs to be provided and = it=20 >>>> > needs to be demonstrated why the use case falls outside of the=20 >>>> > constraints imposed by RFC 3693.=20 >>>> >=20 >>>> > Cheers=20 >>>> > James=20 >>>> >=20 >>>> >=20 >>>> >=20 >>>> >=20 >>>> > _______________________________________________=20 >>>> > dispatch mailing list=20 >>>> > dispatch@ietf.org = =20 >>>> > https://www.ietf.org/mailman/listinfo/dispatch = =20 >>>> >=20 >>>>=20 >>>> _______________________________________________=20 >>>> dispatch mailing list=20 >>>> dispatch@ietf.org = =20 >>>> https://www.ietf.org/mailman/listinfo/dispatch = =20 >>>>=20 >>>> _______________________________________________=20 >>>> dispatch mailing list=20 >>>> dispatch@ietf.org = =20 >>>> https://www.ietf.org/mailman/listinfo/dispatch = =20 >>>=20 >>=20 >> _______________________________________________=20 >> dispatch mailing list=20 >> dispatch@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/dispatch = =20 >=20 > --=20 > ----------------------------------------- > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se --Apple-Mail=_C6FC97D9-1C05-4B85-B35B-B5A6F007D803 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Thanks Gunnar,

I very much support the concern of once it is implemented it = is here to stay and that once the Geo URI is used for this application = the flood gates will open for everything else.

The draft talks heavily about the North = American situation, and even the authors' comments seem to suggest that = North America is the focus of the solution. I wonder if, rather than = risking the above, whether this specification might not better fit into = NENA or ATIS or has that path already been considered?

Cheers
James


On 1 Aug 2016, at 4:43 PM, Gunnar Hellstr=F6m <gunnar.hellstrom@omnitor.se> wrote:

=20 =20

Den = 2016-07-26 kl. 23:32, skrev Paul Kyzivat:

On 7/26/16 5:07 PM, James Winterbottom wrote:
Thanks Henning and Paul,

The argument still feels a bit like =93we don=92t have anything today, HELD
is too heavy weight, give us encoded location in the header=94. = I guess my
worry with this is two fold:
1) providing this means there is never an incentive to move towards a
more standardised location approach, I will cite the eCall MSD is a good
example of where this has occurred.
2) It gives the first push down the very long slide of =93geo = URIs are
fine for conveying target location=94.

I think the incentive to move will be NG911.

Also, this is a small community that operates under rules set by the FCC.

My strongest preference would = be to find someway for this to provide a
serious stepping-stone towards NG formats and protocols, rather than
providing a mechanism that once implemented gives no incentive to move
mainstream.

Just including location is a big step. And currently the VRS providers handle their 911 calls via separate providers, using static location information. Working through moving to dynamic location information will also be a step.

    Thanks,
    Paul

It would be good to hear if = anyone else on the list has similar concerns.
GH: I see this as a step towards eternal interoperability problems and finally requirements for geo: location acceptance in the NGxxx services.

Some reasons:

When the services get direct interface with NG9-1-1, they will be required to deliver location according to RFC 6442. Then it will be tempting to force the terminals to do so from the source. But then the terminals may need to  deliver GEO: to some vrs services = and PIDF-LO in other calls, depending on at what step the services are in adaptation to NG9-1-1.

Further delaying proper multipart body handling in UEs and servers is not good. More and more RFCs are appearing that require multipart body handling. Support of RUE:s could instead be a good incentive to get multipart body support implemented.

In the introduction, it is stated:
"
   This RUE profile supports the requirements of relay =
services in the
   United States, as described in 47 CFR 64.601 et seq., but may be
   applicable to similar uses elsewhere."
 "
This limitation to USA should be stated in the scope as well. There are many US-specific aspects in the draft that need to be modified before applied elsewhere. The MUST for use of GEO:  is likely = one of them. If not, the conflict between use of geo: and rfc 6442 compliant location will spread.

What is the goal for the draft? Does it have ambitions to be dispatched and accepted as a WG document?

Regards
Gunnar


Cheers
James


On 27 Jul 2016, at 2:17 AM, = Henning Schulzrinne
<Henning.Schulzrinne@fcc.gov <mailto:Henning.Schulzrinne= @fcc.gov>> wrote:

[Typing this from the Athen's airport]

Adding to this:

In this particular use case, there is indeed a "device location" - the
only location reported is what the handset (Android/IOS) device
believes the location is - and this better be the location of the
device, not something else. Anything else would be a bug or malicious
location spoofing. There is no HELD or other external reference involved.

Given that the privacy indicators convey no information in this case
(and thus would have to be hard-coded to the no-restrictions values to
avoid emergency call failures), I fail to see the substantive, as
opposed to protocol-lawyering, difference. The information is going to
be exactly the same, whether I do this by cdata PIDF-LO attachment
"legally" or by geo URL "illegally".

Also, the VRS 911 situation is somewhat unique in that there are three
entities involved in the call: the VRS provider and its communication
assistant (the person translating between voice and ASL), a
third-party emergency service provider and the PSAP with related
system service providers. Until native NG911/i3 is common, the most
likely case is that the VRS provider will pick apart the SIP request
and inject the location via a proprietary API.

All three entities have their own data retention and disclosure rules,
which may vary by state, and are likely unknown upstream.

Given the absence of HELD in this environment, at least for the
foreseeable future, insisting on carrying the same information in an
XML attachment instead of a header, means that the emergency calls
need a completely different code path since they are the only ones
with multi-part. This is seen as a really bad trade-off of reliability
and simplicity vs. formal requirements that serve no obvious privacy
or functionality purpose.

If there's a technical argument, rather than a legalistic one, please
explain in more detail, as I'm obviously missing it.

I assume you mean "illegal" figuratively, as I might need to get a
protocol lawyer otherwise :-)


Henning

------------------------------------------------------------------------
*From:* dispatch <dispatch-bounces@ietf.org
<mailto:dispatch-bounces@ietf= .org>> on behalf of Paul Kyzivat
<pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>= >
*Sent:* Tuesday, July 26, 2016 11:20:08 AM
*To:* dispatch@ietf.org <mailto:dispatch@ietf.org>
*Subject:* Re: [dispatch] Strong concerns with location encoding in
draft-vrs-rue-dispatch-00

James,

Henning is traveling, so we may not hear from him for a bit.

Using geo: was not my first choice, precisely because it isn't included
among the permissible ways of conveying the information. But it is a
hard sell among the VRS community. For this use the alternative would be
putting the location in the body, which is felt to be complex.

Note that the context for this usage is only 911 calls. I got the
following private comment from Henning:

> Privacy indicators in US 911 SIP requests are both meaningless and
> possibly disruptive. Since US VRS and 911 retention and disclosure
> policies are given by law and custom and not subject to user control,
> there are only two options:
>
> (1) Ignore the settings in PIDF-LO, i.e., the user believes one thing
> that's happening, but reality is something else.
>
> (2) Reject the 911 call, since the VRS provider and 911 provider cannot
> and will not honor the requested privacy policy. Clearly not acceptable.

(I'm not personally familiar with the US regulations - I trust Henning
on this.)

The current situation is that VRS users *are* using mobile devices for
911 calls, and the location initially communicated for those calls is
currently *static*. The actual location must be provided within the call
by the deaf caller, using ASL. We are trying to improve on that.

        Thanks,
        Paul

On 7/25/16 4:51 AM, James Winterbottom wrote:
> Hi Paul and Henning,
>
> I was reading through your draft but had to have a double take in
> Section 11.4, it says the following:
>
> "
>> location information MUST be conveyed with a "geo:" URI in a
>>       Geolocation = header field, as defined in [RFC5870 <https://tools.ietf.org/ht= ml/rfc5870>].
>>
>>       (While section = 4.1 of [RFC6442] <https://tools= .ietf.org/html/rfc6442#section-4.1> prohibits this usage,
the reasons
>>       for doing so do = not apply to emergency calls.)
> =93
>
> The problem here that this is an illegal used of the encoding in RFC
> 5870. The reason is that the way it is being used directly identifies as
> device or user and so it falls subject to the requirements of a Geopriv
> using protocol. =46rom section 9.2 of RFC 5870:
> "
>> A 'geo' URI by itself is just an opaque reference to a physical
>>    location, expressed by a set of = spatial coordinates.  This does not
>>    fit the "Location Information" = definition according to Section 5.2 <https://tools= .ietf.org/html/rfc5870#section-5.2> of
>>    GEOPRIV Requirements [RFC3693 <https://tools.ietf.org/ht= ml/rfc3693>], because there is not necessarily a
>>    "Device" involved.
>>
>>    Because there is also no way to = specify the identity of a "Target"
>>    within the confines of a 'geo' URI, = it also does not fit the
>>    specification of a "Location = Object" (Section 5.2 of RFC 3693 <https://tools= .ietf.org/html/rfc3693#section-5.2>).
>>
>>    However, if a 'geo' URI is used in = a context where it identifies the
>>    location of a Target, it becomes = part of a Location Object and is
>>    therefore subject to GEOPRIV rules.
>>
>>    Therefore, when 'geo' URIs are put = into such contexts, the privacy
>>    requirements of RFC 3693 <https://tools.ietf.org/ht= ml/rfc3693> MUST be met.
> =93
> In order for encoding of location to proceed in this form for the VRS
> application I think far better rationale needs to be provided and it
> needs to be demonstrated why the use case falls outside of the
> constraints imposed by RFC 3693.
>
> Cheers
> James
>
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org <mailto:dispatch@ietf.org>
> https://www.ietf.o= rg/mailman/listinfo/dispatch
>

_______________________________________________
dispatch mailing list
dispatch@ietf.org <mailto:dispatch@ietf.org>
https://www.ietf.o= rg/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
dispatch@ietf.org <mailto:dispatch@ietf.org>
https://www.ietf.o= rg/mailman/listinfo/dispatch


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.o= rg/mailman/listinfo/dispatch 

--=20
-----------------------------------------
Gunnar Hellstr=F6m
Omnitor
gunnar.hellstrom@omnitor.se

= --Apple-Mail=_C6FC97D9-1C05-4B85-B35B-B5A6F007D803-- From nobody Mon Aug 1 14:20:26 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459CB12D756 for ; Mon, 1 Aug 2016 14:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 7C2gjTxp7k2W for ; Mon, 1 Aug 2016 14:20:23 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (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 230A812B069 for ; Mon, 1 Aug 2016 14:20:23 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-02v.sys.comcast.net with SMTP id UKcLbdb3e0MKRUKdKbs5S8; Mon, 01 Aug 2016 21:20:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id UKdHbDWLoDgDkUKdJbKZni; Mon, 01 Aug 2016 21:20:21 +0000 To: James Winterbottom , =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= References: <7BB6D8A6-86E4-48BE-A526-B8963791009A@gmail.com> <7a228246-90f0-3fc0-58f0-dc014897a6e4@alum.mit.edu> <7B1495C7-CBB8-46A4-85C8-FEF0545CD0D0@gmail.com> From: Paul Kyzivat Message-ID: <437c527a-79b0-20ba-dd39-08b6fc3299de@alum.mit.edu> Date: Mon, 1 Aug 2016 17:20:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7B1495C7-CBB8-46A4-85C8-FEF0545CD0D0@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfJcAiKZhrzT09ARgBCoRmLLxBzDUOR57fLutK+WB+08C3cyCMpoD0iiCARAOwaW1zZ9p3Bzhlwth9CxgyxM0C4sIdh9L4n9+pxyx5RM3vlq73Rkkpzkc Fh4anzBDLvI4vl/2kr7wnUbgImFnEEowmfFpE0mi+hwtU/izU/gb3nXAUE0vKjzBdYZu6hmChorBinSGkz6+A6dPt0/rTmb3X8K9OpKCBUj0Ue124MVfkXvE wWY+lBjeVS5CmM38wQ6RGkh5u2DUVATRwtjSoIYVriefYS2yzmNkk3F4GNGL1FhZt/qpSrrXqDXAPxn75YbAZg== Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Strong concerns with location encoding in draft-vrs-rue-dispatch-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 21:20:25 -0000 On 8/1/16 4:55 PM, James Winterbottom wrote: > Thanks Gunnar, > > I very much support the concern of once it is implemented it is here to > stay and that once the Geo URI is used for this application the flood > gates will open for everything else. > > The draft talks heavily about the North American situation, and even the > authors' comments seem to suggest that North America is the focus of the > solution. I wonder if, rather than risking the above, whether this > specification might not better fit into NENA or ATIS or has that path > already been considered? Thank you for the feedback. I will discuss this further with Henning and the principals who will have to implement it. Thanks, Paul > Cheers > James > > >> On 1 Aug 2016, at 4:43 PM, Gunnar Hellström >> > wrote: >> >> Den 2016-07-26 kl. 23:32, skrev Paul Kyzivat: >> >>> On 7/26/16 5:07 PM, James Winterbottom wrote: >>>> Thanks Henning and Paul, >>>> >>>> The argument still feels a bit like “we don’t have anything today, HELD >>>> is too heavy weight, give us encoded location in the header”. I >>>> guess my >>>> worry with this is two fold: >>>> 1) providing this means there is never an incentive to move towards a >>>> more standardised location approach, I will cite the eCall MSD is a >>>> good >>>> example of where this has occurred. >>>> 2) It gives the first push down the very long slide of “geo URIs are >>>> fine for conveying target location”. >>> >>> I think the incentive to move will be NG911. >>> >>> Also, this is a small community that operates under rules set by the >>> FCC. >>> >>>> My strongest preference would be to find someway for this to provide a >>>> serious stepping-stone towards NG formats and protocols, rather than >>>> providing a mechanism that once implemented gives no incentive to move >>>> mainstream. >>> >>> Just including location is a big step. And currently the VRS >>> providers handle their 911 calls via separate providers, using static >>> location information. Working through moving to dynamic location >>> information will also be a step. >>> >>> Thanks, >>> Paul >>> >>>> It would be good to hear if anyone else on the list has similar >>>> concerns. >> GH: I see this as a step towards eternal interoperability problems and >> finally requirements for geo: location acceptance in the NGxxx services. >> >> Some reasons: >> >> When the services get direct interface with NG9-1-1, they will be >> required to deliver location according to RFC 6442. Then it will be >> tempting to force the terminals to do so from the source. But then the >> terminals may need to deliver GEO: to some vrs services and PIDF-LO >> in other calls, depending on at what step the services are in >> adaptation to NG9-1-1. >> >> Further delaying proper multipart body handling in UEs and servers is >> not good. More and more RFCs are appearing that require multipart body >> handling. Support of RUE:s could instead be a good incentive to get >> multipart body support implemented. >> >> In the introduction, it is stated: >> " >> This RUE profile supports the requirements of relay services in the >> United States, as described in 47 CFR 64.601 et seq., but may be >> applicable to similar uses elsewhere." >> >> " >> This limitation to USA should be stated in the scope as well. There >> are many US-specific aspects in the draft that need to be modified >> before applied elsewhere. The MUST for use of GEO: is likely one of >> them. If not, the conflict between use of geo: and rfc 6442 compliant >> location will spread. >> >> What is the goal for the draft? Does it have ambitions to be >> dispatched and accepted as a WG document? >> >> Regards >> Gunnar >> >>>> >>>> Cheers >>>> James >>>> >>>> >>>>> On 27 Jul 2016, at 2:17 AM, Henning Schulzrinne >>>>> > >>>>> wrote: >>>>> >>>>> [Typing this from the Athen's airport] >>>>> >>>>> Adding to this: >>>>> >>>>> In this particular use case, there is indeed a "device location" - the >>>>> only location reported is what the handset (Android/IOS) device >>>>> believes the location is - and this better be the location of the >>>>> device, not something else. Anything else would be a bug or malicious >>>>> location spoofing. There is no HELD or other external reference >>>>> involved. >>>>> >>>>> Given that the privacy indicators convey no information in this case >>>>> (and thus would have to be hard-coded to the no-restrictions values to >>>>> avoid emergency call failures), I fail to see the substantive, as >>>>> opposed to protocol-lawyering, difference. The information is going to >>>>> be exactly the same, whether I do this by cdata PIDF-LO attachment >>>>> "legally" or by geo URL "illegally". >>>>> >>>>> Also, the VRS 911 situation is somewhat unique in that there are three >>>>> entities involved in the call: the VRS provider and its communication >>>>> assistant (the person translating between voice and ASL), a >>>>> third-party emergency service provider and the PSAP with related >>>>> system service providers. Until native NG911/i3 is common, the most >>>>> likely case is that the VRS provider will pick apart the SIP request >>>>> and inject the location via a proprietary API. >>>>> >>>>> All three entities have their own data retention and disclosure rules, >>>>> which may vary by state, and are likely unknown upstream. >>>>> >>>>> Given the absence of HELD in this environment, at least for the >>>>> foreseeable future, insisting on carrying the same information in an >>>>> XML attachment instead of a header, means that the emergency calls >>>>> need a completely different code path since they are the only ones >>>>> with multi-part. This is seen as a really bad trade-off of reliability >>>>> and simplicity vs. formal requirements that serve no obvious privacy >>>>> or functionality purpose. >>>>> >>>>> If there's a technical argument, rather than a legalistic one, please >>>>> explain in more detail, as I'm obviously missing it. >>>>> >>>>> I assume you mean "illegal" figuratively, as I might need to get a >>>>> protocol lawyer otherwise :-) >>>>> >>>>> >>>>> Henning >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> *From:* dispatch >>>> > on behalf of Paul Kyzivat >>>>> > >>>>> *Sent:* Tuesday, July 26, 2016 11:20:08 AM >>>>> *To:* dispatch@ietf.org >>>>> *Subject:* Re: [dispatch] Strong concerns with location encoding in >>>>> draft-vrs-rue-dispatch-00 >>>>> >>>>> James, >>>>> >>>>> Henning is traveling, so we may not hear from him for a bit. >>>>> >>>>> Using geo: was not my first choice, precisely because it isn't >>>>> included >>>>> among the permissible ways of conveying the information. But it is a >>>>> hard sell among the VRS community. For this use the alternative >>>>> would be >>>>> putting the location in the body, which is felt to be complex. >>>>> >>>>> Note that the context for this usage is only 911 calls. I got the >>>>> following private comment from Henning: >>>>> >>>>> > Privacy indicators in US 911 SIP requests are both meaningless and >>>>> > possibly disruptive. Since US VRS and 911 retention and disclosure >>>>> > policies are given by law and custom and not subject to user >>>>> control, >>>>> > there are only two options: >>>>> > >>>>> > (1) Ignore the settings in PIDF-LO, i.e., the user believes one >>>>> thing >>>>> > that's happening, but reality is something else. >>>>> > >>>>> > (2) Reject the 911 call, since the VRS provider and 911 provider >>>>> cannot >>>>> > and will not honor the requested privacy policy. Clearly not >>>>> acceptable. >>>>> >>>>> (I'm not personally familiar with the US regulations - I trust Henning >>>>> on this.) >>>>> >>>>> The current situation is that VRS users *are* using mobile devices for >>>>> 911 calls, and the location initially communicated for those calls is >>>>> currently *static*. The actual location must be provided within the >>>>> call >>>>> by the deaf caller, using ASL. We are trying to improve on that. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 7/25/16 4:51 AM, James Winterbottom wrote: >>>>> > Hi Paul and Henning, >>>>> > >>>>> > I was reading through your draft but had to have a double take in >>>>> > Section 11.4, it says the following: >>>>> > >>>>> > " >>>>> >> location information MUST be conveyed with a "geo:" URI in a >>>>> >> Geolocation header field, as defined in [RFC5870 >>>>> ]. >>>>> >> >>>>> >> (While section 4.1 of [RFC6442] >>>>> prohibits this >>>>> usage, >>>>> the reasons >>>>> >> for doing so do not apply to emergency calls.) >>>>> > “ >>>>> > >>>>> > The problem here that this is an illegal used of the encoding in RFC >>>>> > 5870. The reason is that the way it is being used directly >>>>> identifies as >>>>> > device or user and so it falls subject to the requirements of a >>>>> Geopriv >>>>> > using protocol. From section 9.2 of RFC 5870: >>>>> > " >>>>> >> A 'geo' URI by itself is just an opaque reference to a physical >>>>> >> location, expressed by a set of spatial coordinates. This >>>>> does not >>>>> >> fit the "Location Information" definition according to >>>>> Section 5.2 of >>>>> >> GEOPRIV Requirements [RFC3693 >>>>> ], because there is not >>>>> necessarily a >>>>> >> "Device" involved. >>>>> >> >>>>> >> Because there is also no way to specify the identity of a >>>>> "Target" >>>>> >> within the confines of a 'geo' URI, it also does not fit the >>>>> >> specification of a "Location Object" (Section 5.2 of RFC 3693 >>>>> ). >>>>> >> >>>>> >> However, if a 'geo' URI is used in a context where it >>>>> identifies the >>>>> >> location of a Target, it becomes part of a Location Object >>>>> and is >>>>> >> therefore subject to GEOPRIV rules. >>>>> >> >>>>> >> Therefore, when 'geo' URIs are put into such contexts, the >>>>> privacy >>>>> >> requirements of RFC 3693 >>>>> MUST be met. >>>>> > “ >>>>> > In order for encoding of location to proceed in this form for the >>>>> VRS >>>>> > application I think far better rationale needs to be provided and it >>>>> > needs to be demonstrated why the use case falls outside of the >>>>> > constraints imposed by RFC 3693. >>>>> > >>>>> > Cheers >>>>> > James >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > dispatch mailing list >>>>> > dispatch@ietf.org >>>>> > https://www.ietf.org/mailman/listinfo/dispatch >>>>> > >>>>> >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se > From nobody Mon Aug 1 14:23:19 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840D812D890 for ; Mon, 1 Aug 2016 14:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 RCrpWUb1A4h4 for ; Mon, 1 Aug 2016 14:23:16 -0700 (PDT) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCE012D73B for ; Mon, 1 Aug 2016 14:23:16 -0700 (PDT) X-AuditID: 12074413-ab7ff70000000955-27-579fbdc054cf Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by (Symantec Messaging Gateway) with SMTP id 6D.9F.02389.0CDBF975; Mon, 1 Aug 2016 17:23:14 -0400 (EDT) Received: from Paul-Kyzivats-MacBook-Pro.local (c-73-218-51-154.hsd1.ma.comcast.net [73.218.51.154]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u71LNBtJ017374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 1 Aug 2016 17:23:11 -0400 To: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= , James Winterbottom , Henning Schulzrinne References: <7BB6D8A6-86E4-48BE-A526-B8963791009A@gmail.com> <7a228246-90f0-3fc0-58f0-dc014897a6e4@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Mon, 1 Aug 2016 17:23:10 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42IRYndR1D28d364waqLjBb3Nv1ksVg6aQGr xY73Z1gsfh7ZzerA4nH79hs2j52z7rJ7LFnyk8lj4uJPzAEsUVw2Kak5mWWpRfp2CVwZ72Ys YixYzFSx4HczawPjfcYuRk4OCQETiSVTHrGA2EICWxklmtbpdzFyAdlPmCQWr1kGlODgEBaI lehazQoSFxHYyyjRuf0bI0TRIyaJ22tmMoF0MwtoS1yavRXMZhPQkphz6D9YM6+AvcSmG1Ig YRYBFYn9NzqYQWxRgTSJ6Yf7wY7gFRCUODnzCdgRnAJ2EvO/HmeGGGkrcWfubihbXqJ562zm CYz8s5C0zEJSNgtJ2QJG5lWMcok5pbm6uYmZOcWpybrFyYl5ealFuuZ6uZkleqkppZsYIYEr vINx10m5Q4wCHIxKPLwBufPDhVgTy4orcw8xSnIwKYnyejYBhfiS8lMqMxKLM+KLSnNSiw8x SnAwK4nwLtgFlONNSaysSi3Kh0lJc7AoifOqLVH3ExJITyxJzU5NLUgtgsnKcHAoSfC67gFq FCxKTU+tSMvMKUFIM3FwggznARruAFLDW1yQmFucmQ6RP8Woy7Hgx+21TEIsefl5qVLivOog RQIgRRmleXBzYAnnFaM40FvCvC4gVTzAZAU36RXQEiagJYn2c0CWlCQipKQaGLeumfkp/Hl4 97yUo2tfW0RyBN6/r2ClzF/KsiJhhwGPdv+uosd82Zsyj/SsPSpgLvpXOHN75dXbkh+5fUzv MHFdMdt/wTneLHjRu96lhV6ncpa9ncyx9MQhayWNzVOXJL3fWJS56+3JTxasTQ1f5urrlPn6 zV4Y4XKwfPVmkz0Pt2R9bd021V2JpTgj0VCLuag4EQCT4w8zEwMAAA== Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Strong concerns with location encoding in draft-vrs-rue-dispatch-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 21:23:18 -0000 On 8/1/16 2:43 AM, Gunnar Hellström wrote: > What is the goal for the draft? Does it have ambitions to be dispatched > and accepted as a WG document? Given the (intentionally) bounded scope of the document it isn't entirely clear to me what the right path is. Thanks, Paul From nobody Mon Aug 1 14:34:15 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F1012D0EC for ; Mon, 1 Aug 2016 14:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-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 n19W8a-mQQmx for ; Mon, 1 Aug 2016 14:34:12 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (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 92ED112D0E9 for ; Mon, 1 Aug 2016 14:34:12 -0700 (PDT) Received: by mail-pa0-x229.google.com with SMTP id pp5so56230006pac.3 for ; Mon, 01 Aug 2016 14:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=AOfS+U/cfM4G8ucWuBVTw4G+4UAWVQKDLMJtcc10sQs=; b=wT29C7/Fsn8zKdGJXFt97bd/XwAL04iQGPbiEHPNiN6ELtaIuyuNR5ITCvY313YPYp k40UAejq27fXDYxa8KbzzjpvorXasaxI9Zo+S/zn06z8u1RK65ygNqY9wGFlNho5ReZG kRyoXpLLcHi9Ay7BcNE2DxU4b4Ft5VfOWuRcr5bCmy950bD0frZNf/i62+8zthIVd6zx Tt2GyPpxehexHgSbcVhKCjmpxT2g3YQ5QCoZgRfRW4xi0vOZ9rUuz75aQ8TC/aD6S/20 GTJJoGW2vVRnLIetHmSdt7lAUOkEEG6dlCS5h3xGxSjpUw04/yZP+pdF6Hgws0Rz6HdC gt5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=AOfS+U/cfM4G8ucWuBVTw4G+4UAWVQKDLMJtcc10sQs=; b=APIAQdwkwiUtQz4bY5DAqgvkys03kSi1KoVCn8LVk80Q1YxltdckJA0zf5AeRyJIye cpGLdOaY+Mvl9zZ/ZrRl6/yy25p2ezgrG4Sdu5+BnSGMha0Gvx4Qitrh+XX64YfMFRvg 2OwjW8H85BYsN+Q5uDWYTXLUnQ9p48dDPKhk/M4f4bkc8yr/E+1vnyYvnOOE8IXESr4g NRNQzNWM8XGtuwdWdd3MNLIi34qOa4Dy8/RGPrs6G7/BQzFa7zR4FhyWXRq52pPIQMcx ONehjAjVG4Y8sqrEMdLFUCLGg+7DglVrojL1b7urw+QpM6MuEu9deNz8JwKq0CvVG+YL ubwg== X-Gm-Message-State: AEkoousVPi9GQib0SbzWlaXDnG0sPdHXjT2PTZ3l291RjFwoF7/An/Pvx344o2ohQ3WQHA== X-Received: by 10.66.43.7 with SMTP id s7mr100900111pal.27.1470087252084; Mon, 01 Aug 2016 14:34:12 -0700 (PDT) Received: from [10.190.200.245] ([1.144.87.136]) by smtp.gmail.com with ESMTPSA id ps2sm48070620pab.10.2016.08.01.14.34.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 01 Aug 2016 14:34:10 -0700 (PDT) References: <7BB6D8A6-86E4-48BE-A526-B8963791009A@gmail.com> <7a228246-90f0-3fc0-58f0-dc014897a6e4@alum.mit.edu> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <854DB530-06CA-4282-8FF6-394EBD364ED9@gmail.com> X-Mailer: iPhone Mail (11D201) From: James Winterbottom Date: Tue, 2 Aug 2016 07:34:07 +1000 To: Paul Kyzivat Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Strong concerns with location encoding in draft-vrs-rue-dispatch-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 21:34:14 -0000 Then I think an alternative to current use of the Geo URI is required for th= e concerns Gunnar and I have raised. Cheers James Sent from my iPhone > On 2 Aug 2016, at 7:23 am, Paul Kyzivat wrote: >=20 >> On 8/1/16 2:43 AM, Gunnar Hellstr=C3=B6m wrote: >>=20 >> What is the goal for the draft? Does it have ambitions to be dispatched >> and accepted as a WG document? >=20 > Given the (intentionally) bounded scope of the document it isn't entirely c= lear to me what the right path is. >=20 > Thanks, > Paul >=20 From nobody Mon Aug 1 14:37:00 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152D312D64F for ; Mon, 1 Aug 2016 14:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 csy1PhlDM4fB for ; Mon, 1 Aug 2016 14:36:57 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 0796F12D647 for ; Mon, 1 Aug 2016 14:36:57 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id f93so124915468lfi.2 for ; Mon, 01 Aug 2016 14:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ke6FNijNUfYcdHkHIWzh3Wu9UrVrk5zdBjQVwTVDYpc=; b=ceIYwF0m5BCijWO6+2x6TxmerVTTnn5bL/Hul7Sk/m2IhlAHYiArb9JcLl7/1UFRSk rBHv/VfiQ8PZC5mScF8wpX5G8B3CoJh2twZ/bxKosf6PSVcmyPUzbTKmD4wV7o17Auft oJr1imF/783btMHCcLv1W0s8y8KAZ5VojNJaVR2BBDCV+Pext34HW35MxfACRA/50AEx h61nOt84nRtmwNiStU5vFZCa/iD4gjZd+ttjqP0XHvMbaGR0kAZndViDk9spcEfCbeZH RprRPeUT4UJVFXMleI+yUpjYckLFdBqd/X0/tPzREsyT+a6nO3D088Mm+6bUE6LF52L9 JrIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ke6FNijNUfYcdHkHIWzh3Wu9UrVrk5zdBjQVwTVDYpc=; b=NJ4yJ0le6YJWlWMqo6BJOm2bMEqco8YpZi05SDPPaf5hHDKFIUMZ2mecPTkXBVOBDT jsmxW/9eirrdp662PtBu0fVeqneSK3Uwf1FJFw1jFNkqUCYsweArJkkEUecBEb7BOiRV 0EJ/CIBZiiTNjfDxExxjSB8pCJEMw80p+ry/O9+iYNiivY16fuUPZFk3/TTFu/uTTnZT GEMUSFqEtwiemFHqFEiOH7m5IXNj5XhJVt6aK9g9GGeUibT0a9e6zI1vLVDvYNYetwQ1 dfRqon9Ws/KwSeuPdcNegvoQlRrJxZBuuAD/Vg7Wt25+BwUlKGmbPyd9+pkFxW94QDGJ 7vWA== X-Gm-Message-State: AEkoout7O1AKhNHadq9MY3e/TKVzc5BbSJ5FJOiDo7agbxt218dA00+Phe68oUmBNERlF2PaH7MWk/dcTfHPeA== X-Received: by 10.25.17.228 with SMTP id 97mr20073016lfr.154.1470087415092; Mon, 01 Aug 2016 14:36:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.144.203 with HTTP; Mon, 1 Aug 2016 14:36:54 -0700 (PDT) X-Originating-IP: [74.112.3.251] In-Reply-To: <854DB530-06CA-4282-8FF6-394EBD364ED9@gmail.com> References: <7BB6D8A6-86E4-48BE-A526-B8963791009A@gmail.com> <7a228246-90f0-3fc0-58f0-dc014897a6e4@alum.mit.edu> <854DB530-06CA-4282-8FF6-394EBD364ED9@gmail.com> From: Brian Rosen Date: Mon, 1 Aug 2016 17:36:54 -0400 Message-ID: To: James Winterbottom Content-Type: multipart/alternative; boundary=001a113f9cf82a6b600539096667 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Strong concerns with location encoding in draft-vrs-rue-dispatch-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 21:36:59 -0000 --001a113f9cf82a6b600539096667 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It may help to inform the providers that NG9-1-1 will require location in a PIDF-LO and its being implemented fairly widely now so they only have a short time before they have to deal with it anyway. Brian On Monday, August 1, 2016, James Winterbottom < a.james.winterbottom@gmail.com> wrote: > Then I think an alternative to current use of the Geo URI is required for > the concerns Gunnar and I have raised. > > Cheers > James > > Sent from my iPhone > > > On 2 Aug 2016, at 7:23 am, Paul Kyzivat > wrote: > > > >> On 8/1/16 2:43 AM, Gunnar Hellstr=C3=B6m wrote: > >> > >> What is the goal for the draft? Does it have ambitions to be dispatche= d > >> and accepted as a WG document? > > > > Given the (intentionally) bounded scope of the document it isn't > entirely clear to me what the right path is. > > > > Thanks, > > Paul > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --001a113f9cf82a6b600539096667 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It may help to inform the providers that NG9-1-1 will require location in a= PIDF-LO and its being implemented fairly widely now so they only have a sh= ort time before they have to deal with it anyway.=C2=A0

= Brian

On Monday, August 1, 2016, James Winterbottom <= ;a.james.winterbottom@gma= il.com> wrote:
Then I think an alt= ernative to current use of the Geo URI is required for the concerns Gunnar = and I have raised.

Cheers
James

Sent from my iPhone

> On 2 Aug 2016, at 7:23 am, Paul Kyzivat <pkyzi= vat@alum.mit.edu> wrote:
>
>> On 8/1/16 2:43 AM, Gunnar Hellstr=C3=B6m wrote:
>>
>> What is the goal for the draft? Does it have ambitions to be dispa= tched
>> and accepted as a WG document?
>
> Given the (intentionally) bounded scope of the document it isn't e= ntirely clear to me what the right path is.
>
>=C2=A0 =C2=A0 Thanks,
>=C2=A0 =C2=A0 Paul
>

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--001a113f9cf82a6b600539096667-- From nobody Mon Aug 1 14:55:51 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DFF12D873 for ; Mon, 1 Aug 2016 14:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 6yXEF8Nn1aIM for ; Mon, 1 Aug 2016 14:55:48 -0700 (PDT) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (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 9A42312D6B3 for ; Mon, 1 Aug 2016 14:55:48 -0700 (PDT) Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-05v.sys.comcast.net with SMTP id ULB9br73JcEL1ULBbbTnCG; Mon, 01 Aug 2016 21:55:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id ULBZbW3QEorbqULBabjjZc; Mon, 01 Aug 2016 21:55:47 +0000 To: Brian Rosen , James Winterbottom References: <7BB6D8A6-86E4-48BE-A526-B8963791009A@gmail.com> <7a228246-90f0-3fc0-58f0-dc014897a6e4@alum.mit.edu> <854DB530-06CA-4282-8FF6-394EBD364ED9@gmail.com> From: Paul Kyzivat Message-ID: Date: Mon, 1 Aug 2016 17:55:44 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfINSLxyE4eccZxjkyVkBCl6Jra8rGJR8wR3GfXeqh/MxfEVUqj9CY+BbW71UxJ88J5NJO3J8+z0kTtg5FR2ObWrcNMQrMrgR6r9x6nQ7pB8pSEFHsbSA qUS49A7nHOE3yB4Q+otdAZdqQ0+spsIl5ehHh1mV5eOCWdVkFF/wY8cDMHsWVA+YHFLZsMgZF9DQAJzryVlBa5ikyXwysqf7t33RA7zAuOOkiAdwA4fTyai3 TIu+pGoCDVoJgK6xOzS9o60/nnANiKaK6xY9LDfEtXM= Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Strong concerns with location encoding in draft-vrs-rue-dispatch-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 21:55:49 -0000 On 8/1/16 5:36 PM, Brian Rosen wrote: > It may help to inform the providers that NG9-1-1 will require location > in a PIDF-LO and its being implemented fairly widely now so they only > have a short time before they have to deal with it anyway. I already informed them. I had first proposed using PIDF-LO, but was a minority of one. There was *strong* desire (from providers) to use geo: and only geo:. I pointed out the need to migrate to adopt NG911, but that didn't sway them. My impression is that it is thought to be difficult to get existing sip stacks and SBCs to support the PIDF-LO in multipart bodies. Thanks, Paul > Brian > > On Monday, August 1, 2016, James Winterbottom > > > wrote: > > Then I think an alternative to current use of the Geo URI is > required for the concerns Gunnar and I have raised. > > Cheers > James > > Sent from my iPhone > > > On 2 Aug 2016, at 7:23 am, Paul Kyzivat > wrote: > > > >> On 8/1/16 2:43 AM, Gunnar Hellström wrote: > >> > >> What is the goal for the draft? Does it have ambitions to be > dispatched > >> and accepted as a WG document? > > > > Given the (intentionally) bounded scope of the document it isn't > entirely clear to me what the right path is. > > > > Thanks, > > Paul > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Mon Aug 1 16:12:13 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FC912D8F7 for ; Mon, 1 Aug 2016 16:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Ho92jqnEF6FI for ; Mon, 1 Aug 2016 16:12:08 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 855D112D8F0 for ; Mon, 1 Aug 2016 16:12:06 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id y134so59592340pfg.0 for ; Mon, 01 Aug 2016 16:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=YYt5Z8cmSyH9j0jQIlGiC+ukDdcA8xVck73enPsWef8=; b=LyhmXDX/spoFcyu9m/UgNmxqF3EZ6J3BusU63b5wnpmM3gn1B+wLzCs8rE5bVRUsfC fkQcaZ9MXRCAw3lgqoSgus5RhSRV8eTHr+ZaFj6i0WWX7hhmnp94nMIUT30mAIq018Pk bnG9d17exUgHPSnlhWZkWcUw94rSIl5+PLPJ3QJDVUVFmEBxi4H5pbFu7V8k+ye4zwp2 7Bl/6bLDH0Knyz1qfYmLHPGJRlEq8pm5Z5kBbK6RCJwn7WxbL/I22bpeIz4zTRDH6h4M 2G71aWYcKEgMcv/v1djf4qtqsyqnx9U6KaQOau2cQweI0eovbNJQ9VWg7zgBn7e6CHSu QXJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=YYt5Z8cmSyH9j0jQIlGiC+ukDdcA8xVck73enPsWef8=; b=T7Az3NyETFrPC+uOCUzri+L/tEF2jlvNoNKaagFv7Wc5/S0lP3C38lR8j468SJQMD6 kuRi4jf3hp6fvWS2R0jAJVQhRxqcWPSl3IjeohjXkbU28/IScJEeVuQXkNxw4q9iFcNT IDq9fvrupN6CrtjG0fI2aXO3YjImTaVnbB7R8zh8wtv1LTcSAvIyiOQ/qbxKRdjJCHqj 2HUtMnjDNTIFZ+iUtDd0VLakh7aFY/jf+lFapRMSBDnIqaOWxDTfFbruySumixHnsEy4 0IhvtmNSGKEk2al3baQjLUHsYvNArdrACyfK1rZ7wnlghcaqqvRCTynRJH/8DkCBYcZf uKGg== X-Gm-Message-State: AEkoousasAEfjcO/lRWAX/NTJKtqb6oSks5+T7isormHvsrvyYYDK1F/hNgPSQisustW0A== X-Received: by 10.98.157.12 with SMTP id i12mr100617232pfd.164.1470093126096; Mon, 01 Aug 2016 16:12:06 -0700 (PDT) Received: from [10.190.200.245] ([1.144.83.44]) by smtp.gmail.com with ESMTPSA id g10sm48114394pfc.57.2016.08.01.16.12.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 01 Aug 2016 16:12:05 -0700 (PDT) References: <7BB6D8A6-86E4-48BE-A526-B8963791009A@gmail.com> <7a228246-90f0-3fc0-58f0-dc014897a6e4@alum.mit.edu> <854DB530-06CA-4282-8FF6-394EBD364ED9@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-CD92D295-3724-4EF0-BB0A-9382A4526ED6 Content-Transfer-Encoding: 7bit Message-Id: <862FF6AB-EACE-46DA-880B-3DE3602ACB94@gmail.com> X-Mailer: iPhone Mail (11D201) From: James Winterbottom Date: Tue, 2 Aug 2016 09:12:03 +1000 To: Brian Rosen Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Strong concerns with location encoding in draft-vrs-rue-dispatch-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 23:12:12 -0000 --Apple-Mail-CD92D295-3724-4EF0-BB0A-9382A4526ED6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I don't think that this will help if we give them an easy out now. Nobody wi= ll spend money if there is an adequate cheap option. My view is that we should not allow this option. Cheers James Sent from my iPhone > On 2 Aug 2016, at 7:36 am, Brian Rosen wrote: >=20 > It may help to inform the providers that NG9-1-1 will require location in a= PIDF-LO and its being implemented fairly widely now so they only have a sho= rt time before they have to deal with it anyway.=20 >=20 > Brian >=20 >> On Monday, August 1, 2016, James Winterbottom wrote: >> Then I think an alternative to current use of the Geo URI is required for= the concerns Gunnar and I have raised. >>=20 >> Cheers >> James >>=20 >> Sent from my iPhone >>=20 >> > On 2 Aug 2016, at 7:23 am, Paul Kyzivat wrote: >> > >> >> On 8/1/16 2:43 AM, Gunnar Hellstr=C3=B6m wrote: >> >> >> >> What is the goal for the draft? Does it have ambitions to be dispatche= d >> >> and accepted as a WG document? >> > >> > Given the (intentionally) bounded scope of the document it isn't entire= ly clear to me what the right path is. >> > >> > Thanks, >> > Paul >> > >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail-CD92D295-3724-4EF0-BB0A-9382A4526ED6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I don't think that this will help if w= e give them an easy out now. Nobody will spend money if there is an adequate= cheap option.

My view is that we should not allow t= his option.

Cheers
James

Sent from= my iPhone

On 2 Aug 2016, at 7:36 am, Brian Rosen <br@brianrosen.net> wrote:

It may help to inform the providers that NG9-1-1= will require location in a PIDF-LO and its being implemented fairly widely n= ow so they only have a short time before they have to deal with it anyway.&n= bsp;

= --Apple-Mail-CD92D295-3724-4EF0-BB0A-9382A4526ED6-- From nobody Tue Aug 2 07:07:26 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155C412D684; Tue, 2 Aug 2016 07:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 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_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 PFsIHO4BPW6z; Tue, 2 Aug 2016 07:07:22 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 9E7D212D5CA; Tue, 2 Aug 2016 07:07:22 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id j185so237322100oih.0; Tue, 02 Aug 2016 07:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=Pn5Gf+Zwng9FBfE4yivny+H4GfQwznwb+D1OylSquu4=; b=M5CH0Eteclpf+8VPmt8d3/6eYzqnTZCMe9+4l00H9YnThV9k/u2eiBUfPUJr0awyEK uJwyrRbSDjleSYrprbgGIBpXfiKQDkuAZvhYIStSpVGfwe45t2pkW8Eo7toHpDK1LFXC ayRsG7ZqlNv8oF/D0AsK2JJ4sOV3p7bepyje0r5knYrjbd4V5qScX9GvuJsFq+XuImtd e5JpGcnYzqupJLZ+Pc9c7gVbNU9SRZgfGTMRcR/c16vniXWLm5zIYwqpiclw2zVm68xx IPsfdbhGsCEDwgr3R1uDAcFX33rV44ivj59YM98y42E6ZciECRLgZHtlnNQhr6dMuWKC lPjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Pn5Gf+Zwng9FBfE4yivny+H4GfQwznwb+D1OylSquu4=; b=ZNI3mJ9QXOQuQMG7rQpvOvUoppipQiF27k/3Pwp0OklUpBMQG6/ULgDgbjuxWiDF1V q04scjzWpqKTNAc7baQTUWT0JCj3BQsxxQW7bF7QHIj2pVPFEfEG6x97RznRWERVPwLU kbxGXECKDiiVlbmpOCyBq5pQLVGMtpLYFaz/O2Kdjsmz4fHLsmq31Mi4llOo/GYX0pyt bYUjXRb6pEhIJTegcyEkbvcaCMpuGNZ4r3N6UsNYkSiSlPYWLijyE6eOEGk8yNDB5SiD UV4tj2rNCL0XI0xt0avebwxrYPv9emLzOABnDQwSu/Z8WYML4ixeYtWYkhdYkhkxSY/I 71EA== X-Gm-Message-State: AEkooutRpWMup7RHiGlVl4lwXEY/TVcbk/eN7GptozxZ7MW4NQoEWYB3a51RgDHoJRi3Cr/eynHRshRTmZOYRg== X-Received: by 10.202.196.193 with SMTP id u184mr38752667oif.141.1470146841862; Tue, 02 Aug 2016 07:07:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.47.38 with HTTP; Tue, 2 Aug 2016 07:07:21 -0700 (PDT) From: Mary Barnes Date: Tue, 2 Aug 2016 09:07:21 -0500 Message-ID: To: DISPATCH Content-Type: multipart/alternative; boundary=001a1134e01246e7760539173c8b Archived-At: Cc: "dispatch-chairs@tools.ietf.org" , ART ADs Subject: [dispatch] Deadlines for IETF-97 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 14:07:24 -0000 --001a1134e01246e7760539173c8b Content-Type: text/plain; charset=UTF-8 Hi all, The wiki has been updated with the dates for IETF-97 and topics from IETF-96: https://trac.tools.ietf.org/wg/dispatch/trac/wiki The dates are as follows: - October 3, 2016. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal. - October 10, 2016. Cutoff for charter proposals for topics. - October 17, 2016. Announcement of topics that have been dispatched for IETF-97. - October 31, 2016. Draft deadline. As a reminder, it's extremely helpful if folks would use the usual draft naming convention of including the WG name (i.e., - dispatch) in the document name. That makes it a whole lot easier for us to make sure we're not missing documents and to find links to the docs for the wiki, minutes, etc. Regards, Mary. --001a1134e01246e7760539173c8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

The wiki has been updated with = the dates for IETF-97 and topics from IETF-96:

The dates are as follow= s:
  • October 3, 2016. Cutoff date to notify the chairs/DISPATCH WG of plan= s to submit a proposal.
  • October 10, 2016. Cutoff f= or charter proposals for topics.
  • October 17, 2016. Announce= ment of topics that have been dispatched for IETF-97.
  • October 31, 2016. Draft de= adline.
As a reminder, it's extremely helpful if folks would use the = usual draft naming convention of including the WG name (i.e., - dispatch) i= n the document name. That makes it a whole lot easier for us to make sure w= e're not missing documents and to find links to the docs for the wiki, = minutes, etc.

Regards,
Mary.=C2=A0=
--001a1134e01246e7760539173c8b-- From nobody Wed Aug 3 14:24:10 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A84B12D0C1 for ; Wed, 3 Aug 2016 14:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 myp90-4dyRMR for ; Wed, 3 Aug 2016 14:24:07 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 793BE12B065 for ; Wed, 3 Aug 2016 14:24:07 -0700 (PDT) Received: (qmail 90346 invoked from network); 3 Aug 2016 21:24:06 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 3 Aug 2016 21:24:06 -0000 Date: 3 Aug 2016 21:23:43 -0000 Message-ID: <20160803212343.59778.qmail@ary.lan> From: "John Levine" To: dispatch@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: johnl@taugh.com Subject: Re: [dispatch] Please dispatch draft-levine-herkula-oneclick-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 21:24:09 -0000 In article you write: >We've made a few minor changes after talking to people who plan to >implement this. > >I gather that AD sponsored seems the most plausible path, so could the >powers that be nudge it that way? Thanks. Hi again. Not to be overly impatient, but can I do anything to help move this along? R's, John From nobody Wed Aug 3 14:24:59 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD27A12D0C1 for ; Wed, 3 Aug 2016 14:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 6_rbzVo7GIAJ for ; Wed, 3 Aug 2016 14:24:56 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 630C712B065 for ; Wed, 3 Aug 2016 14:24:56 -0700 (PDT) Received: (qmail 90498 invoked from network); 3 Aug 2016 21:24:56 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 3 Aug 2016 21:24:56 -0000 Date: 3 Aug 2016 21:24:33 -0000 Message-ID: <20160803212433.59799.qmail@ary.lan> From: "John Levine" To: dispatch@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: johnl@taugh.com Subject: Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 21:24:58 -0000 In article you write: >The WG seemed OK with it. After talking to people who plan to implement >it I updated the draft with some editing fixes and a longer security >section. > >This also seems appropriate for AD sponsored, please. Hi again. Martin Thompson said he'd review this, otherwise I haven't heard anything. Signed, Fidgety From nobody Wed Aug 3 15:26:47 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E700412D73B for ; Wed, 3 Aug 2016 15:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 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_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 w7X3pKiuhexA for ; Wed, 3 Aug 2016 15:26:44 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 03C8212D125 for ; Wed, 3 Aug 2016 15:26:44 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id j185so300086403oih.0 for ; Wed, 03 Aug 2016 15:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wf5cJg9sLkhM9PNYMdqLEG/DgUtAhEHf9pAHWYJHm5E=; b=z9kveWznwE/o9W+qLYeHQopUEk/ygm/sDYDsTihuO0pwCXWMISZYoazndTh1b4qiRA +xDceg6l/3HYRA/l+UdNKnNLMCWlimBBp7aEr5NEnjq5hvzGMyxy1A4XijejO/Oxa4zb 0zabF9CTcYHWN+p8razkZgipXULNPVGbsVZ6CWKZNa895irWs9H32Tfa48cizg31TW5n iN0+WCyOv3m5uTsSOwg31TGTQ+TKicMWT1v0ZakkHWxduvAm5qvokjTrJPgtwIpLJwaS tlETQqgmOOgCG4XxmA41RuCMejMeR0e2EDFLJsT17Xt7Y1w0C2UwKiN638fXh6m+okTi reDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wf5cJg9sLkhM9PNYMdqLEG/DgUtAhEHf9pAHWYJHm5E=; b=IQLGvNiMpz/Kr1MhxwVs6qvBFgQZCWB4kdQm87/vsqUaX6vi/CG49JLSTS3WITHQ7e WHPFQaRZQ0tPLpfXwNMDuyzMkwcFro8WFlZ16zIrKbcc7a37dbv8SCFxA40Q4SHrcoTq UUoQXtnC9C3kNyv+Dy86DxPbscuv5PZDAARGcsO6sVhcdCY6Q4LqMx+lQMr1QpU6SHp0 XfhCxZS5Lx7U4phRoq0kWATP34IGPU7XrAHbAknU/B6baxCoBqwNgJrIuynWGpEEMfEg ZRrwzXcJHMMPMNtY5UQh9wLtWaUjCa30ISa+qFJNnpZRCNmNhuf24BKhAPmUL+pJPN5L bGcw== X-Gm-Message-State: AEkoous2z4ca2si+xxNrYNfyGIfrVHR7mjMIiCgLsFy0AdJ45WcLLU83FxzdYtETyFJ5Pf9ATy/Ba5u1p1yY8g== X-Received: by 10.202.8.210 with SMTP id 201mr38906657oii.107.1470263203256; Wed, 03 Aug 2016 15:26:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.47.38 with HTTP; Wed, 3 Aug 2016 15:26:42 -0700 (PDT) In-Reply-To: <20160803212343.59778.qmail@ary.lan> References: <20160803212343.59778.qmail@ary.lan> From: Mary Barnes Date: Wed, 3 Aug 2016 17:26:42 -0500 Message-ID: To: John Levine Content-Type: multipart/alternative; boundary=94eb2c12f1d6f4df8705393253b4 Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Please dispatch draft-levine-herkula-oneclick-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 22:26:46 -0000 --94eb2c12f1d6f4df8705393253b4 Content-Type: text/plain; charset=UTF-8 One thing that would be really good is for the folks that are going to implement it to please post comments on the list reflecting that it solves a problem that they need solved and they agree with the approach. At this point, there's only been one set of comments on the mailing list and I don't see that the authors have responded to those: https://mailarchive.ietf.org/arch/msg/dispatch/7WW5t556-8KYWkhLJ_DmO6sbaz4 You may have considered those in your update (I haven't looked) but it's super helpful for whomever shepherds to be able to trace this on the WG mailing list. Thanks, Mary. On Wed, Aug 3, 2016 at 4:23 PM, John Levine wrote: > In article > you write: > >We've made a few minor changes after talking to people who plan to > >implement this. > > > >I gather that AD sponsored seems the most plausible path, so could the > >powers that be nudge it that way? Thanks. > > Hi again. Not to be overly impatient, but can I do anything to help > move this along? > > R's, > John > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --94eb2c12f1d6f4df8705393253b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One thing that would be really good is for the folks that = are going to implement it to please post comments on the list reflecting th= at it solves a problem that they need solved and they agree with the approa= ch.=C2=A0 At this point, there's only been one set of comments on the m= ailing list and I don't see that the authors have responded to those:= =C2=A0

You =C2=A0may have = considered those in your update (I haven't looked) but it's super h= elpful for whomever shepherds to be able to trace this on the WG mailing li= st.=C2=A0

Thanks,
Mary.

On Wed,= Aug 3, 2016 at 4:23 PM, John Levine <johnl@taugh.com> wrote:<= br>
In article <= alpine.OSX.2.11.1607221118240.12864@dhcp-b1bb.meeting.ietf.org> you = write:
>We've made a few minor changes after talking to people who plan to<= br> >implement this.
>
>I gather that AD sponsored seems the most plausible path, so could the<= br> >powers that be nudge it that way?=C2=A0 Thanks.

Hi again.=C2=A0 Not to be overly impatient, but can I do anything to= help
move this along?

R's,
John

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--94eb2c12f1d6f4df8705393253b4-- From nobody Wed Aug 3 15:33:13 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2395412D8A6 for ; Wed, 3 Aug 2016 15:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=1IEz0Ad+; dkim=pass (1536-bit key) header.d=taugh.com header.b=oyCNvSYB 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 HH2jYBIdFJRK for ; Wed, 3 Aug 2016 15:33:10 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3613412B009 for ; Wed, 3 Aug 2016 15:33:10 -0700 (PDT) Received: (qmail 4248 invoked from network); 3 Aug 2016 22:33:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1097.57a27125.k1608; bh=sJhM2hNJduI3KmsrULd7Jx1Dc+v5I9n0B2nAo5Ux+4g=; b=1IEz0Ad+MUqC3wg/gzxKIu7LVG8xgkN3z72Cnz/S82kn2A8s+Y/OzH1U4AfvvBZGvpUcrTxS8EzUQKWib8BgUr+n/5hiR9+kjSbc+8XNGTRrKxi94Ur7jHgf3h9022uebft6vH+H8oOsVTV/VecZIhQJOfaJYl499Bi8Rw14JtjV9K2r7JmXLNKxhQz++vqh4lq+9Jba5bUqHhKiASXU7xdI/qvcTHh2fmt6nc6ftX134TdlJrikPICT70YjDfNa DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1097.57a27125.k1608; bh=sJhM2hNJduI3KmsrULd7Jx1Dc+v5I9n0B2nAo5Ux+4g=; b=oyCNvSYBwRuIG6+1Mhs6dLikVdrIColzKS1W6ZhG4aCZZP7LoYKTDM6wPuVIQi/WCjdJQPhxMAxzAUJOuUh9hM+JjdQp1NCFv4q0M8p6txYkKRJruTMlwzlTkAAgrZioXIZN7pmuKCNVLcwFsTjYzjnaX8hzINgw3h1ssx/kzjpPuU/aPAW5VTXkl12b6wkHI27qBWoK+cBETfMmUgIUyJ8lvTe+7/5w7bvlED8V2dNU4W/kTZaBDs5m4yMuBi9S Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 03 Aug 2016 22:33:09 -0000 Date: 3 Aug 2016 18:33:07 -0400 Message-ID: From: "John R Levine" To: "Mary Barnes" In-Reply-To: References: <20160803212343.59778.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Please dispatch draft-levine-herkula-oneclick-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 22:33:12 -0000 > One thing that would be really good is for the folks that are going to > implement it to please post comments on the list reflecting that it solves > a problem that they need solved and they agree with the approach. I'll write and ask them to do so. > At this point, there's only been one set of comments on the mailing > list and I don't see that the authors have responded to those: > https://mailarchive.ietf.org/arch/msg/dispatch/7WW5t556-8KYWkhLJ_DmO6sbaz4 Click "View by Thread" and you'll see the back and forth. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sat Aug 6 14:59:05 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B489D12D555; Sat, 6 Aug 2016 14:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.135 X-Spam-Level: **** X-Spam-Status: No, score=4.135 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SBL_CSS=3.335] autolearn=no autolearn_force=no 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 33lmmo3A5CUj; Sat, 6 Aug 2016 14:59:00 -0700 (PDT) Received: from mailhost.mobimail.mobitelnet.lk (mailhost.mobimail.mobitelnet.lk [202.129.235.2]) by ietfa.amsl.com (Postfix) with ESMTP id 27ADE12D513; Sat, 6 Aug 2016 14:59:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.mobimail.mobitelnet.lk (Postfix) with ESMTP id EADB29A4619; Sun, 7 Aug 2016 02:28:49 +0530 (IST) Received: from mailhost.mobimail.mobitelnet.lk ([127.0.0.1]) by localhost (mailhost.mobimail.mobitelnet.lk [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id zzRGiRRwE48P; Sun, 7 Aug 2016 02:28:49 +0530 (IST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.mobimail.mobitelnet.lk (Postfix) with ESMTP id 1D43A9A4610; Sun, 7 Aug 2016 02:28:48 +0530 (IST) X-Virus-Scanned: amavisd-new at mobimail.mobitelnet.lk Received: from mailhost.mobimail.mobitelnet.lk ([127.0.0.1]) by localhost (mailhost.mobimail.mobitelnet.lk [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9PGuQxb7K_ig; Sun, 7 Aug 2016 02:28:47 +0530 (IST) Received: from jodnv.org (unknown [107.190.197.85]) by mailhost.mobimail.mobitelnet.lk (Postfix) with ESMTPSA id A6C949A4609; Sun, 7 Aug 2016 02:28:44 +0530 (IST) From: toby To: "diplomaticunion 2yk" , "dispatch-bounces" , "dispatch" , "do-not-reply" Date: Sun, 7 Aug 2016 00:00:28 +0300 Message-ID: <0000404032e5$95de97f7$341bb74f$@moncaster.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0013_0101AD37.086B0F28" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdH8AEkLBkqHjEx8eTXac8CGQVJzmw== Content-Language: en-us Archived-At: Subject: [dispatch] =?utf-8?q?latest_news?= X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2016 21:59:04 -0000 ------=_NextPart_000_0013_0101AD37.086B0F28 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0014_0101AD37.086B0F28" ------=_NextPart_001_0014_0101AD37.086B0F28 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW8hIA0KRGlkIHlvdSBoZWFyICB0aGUgIGxhdGVzdCBuZXdzPyBZb3Ugc2hvdWxkIGRlZmluZXRl bHkgcmVhZCBtb3JlIGluZm8gaGVyZSAgPGh0dHA6Ly9ob3BlLmFwLW55Yy5jb20vZTRkam9jeGw+ DQoNCkFsbCBiZXN0LCB0b2J5DQo= ------=_NextPart_001_0014_0101AD37.086B0F28 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

<= span lang=3DEN-US>Yo!

Did you hear the latest news? You should definetely re= ad more info here http://= hope.ap-nyc.com/e4djocxl

 

<= span lang=3DEN-US>All best, toby

 

------=_NextPart_001_0014_0101AD37.086B0F28-- ------=_NextPart_000_0013_0101AD37.086B0F28 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCACAAIADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9M5Ha OofMffTLmRoYnkYMVQFiEUscD0A5J9hWbH4ktB/yxv8A/wAF1x/8RXzCTeyPX0RseZRJO+z5KoWu t295OsMcd4rtnBlspo16Z5ZkAH4mtMpvoaa3C6IPNkp8nVKJI6Mv/cpDBE8xPv0eX/t0Rx/JT9nz /wC3QQWEk/v0SESVXeSmRz5rTnJ5Ak/v0yST56fO+EpkdZmhPv8AMSiPf9yo4/3lSeYlakh5dLTv vik+4ny0CuPeHfTPsqUb8/demPJ/vo9afuxajHTyKPM+SmSUif6w1zGpP8tMk60eX89SnpQIXbTU TFO/hp8daKBBWkj/AIKZ9n/uVcmdNlU/MpzBO49LT5Pv1ImzfsqCN3jerTvhKAIHoo/4HT/ljrIs ZH1qZHT/AIHUMnWiOT5PuUQJeoRybKH/AHj/ACUyP95VlESiAFb/AH6j/wBXVp9if79Q+X+8oKCO Spu39+ofL+fZRH+7oAfJ8/yVH5mz7lTv3qlJ/rKJgXY5PPpnl+Y9QW8j76tImK0gSDx/O9M8v56s 7D6mmbylPkFch/1dM8z95VrApnl/PWXIO5HJ/fSiRNnz/wAdPf8Av/wUyd99ADPL/eVPHUcf7x/v 0eX5b1qBIn3jUuxKZsX79MefFH8MW4TfeFKJE/go37/v1B5fz/JQMsv8ifJTJI/M376ZH/v1Mn3B QLYrfJ5lWt1QeX5b/IlFAx6Sf3qfN1NVv46mg/uUvaAPhp1R/wC4lBfZWfOKw+T+Oqn2f5/nqeN3 30Psjf79ahsLs2ffp7ffFG/5M1HHP5ifcoAZHv2bKe8Hz0+R3f5Fpvz7KYBsen+X/sVB/q46Z9of fSGTv/fpPM8tvnpnmU94/P8AnoAHnxVWOTzHq1BHvh2PR9k8v7lLk5xENxHT/L+T56mdKqxx/Pse j2YySN9ke+iSNJP9+rOz5KheT+7RyCuGz5cUz/WfIj0yOR/46mjTZ96sxkNPj+/sqTy/kojj/jo5 AH/cFMd3x/t0kk/+x89PT50rUXqVvM8yiT9589TeQh+9RIibPv0uQYzy/wDvunvP8mxKZJ/rKZ8+ /ZTAfH/rKn+eo40eOpHTZ/HTEMR8vRG/yf7dO8xN+zPNMeD/AL4pAQ/PI/8A0zp6SbKZ5b7Pkp8f RKyGP+WjeKZJ/q6JN8iJsoAI5HNWfvpS7EeoJzsetf4ZO4skfmPUdT7/ADEpkdAx+z+89Qf6x/nq SR8Uz+OgYkm+nwDIR6X/AFibKJPkf5aYEu9Hoc4qtH/fqaN2+5/HV85NrC+Wj/79Gx9/3/kqC4/d 09J0Kf7dQMJ0/jpn2fy6WSSk+0f3KQxZI6cn7tH30yPrU5TfQJjn2vUPyT1N/vffqJ/9mioCAJsq P/lnv2Uv8dWET5aXIDdjPj/ePV1NiLTPLTf9yn71zTpgwRPk3VDJI+N6VZ85KhdPm2JWkwT7h56f 3DTN/wDHR9lokj/uVl74wkk30Rx+XTKf/rKzAJPk/wB96Z/q0q19nNMkt/3dacgucrp/rDV+P5Ko eY6P8lWPMfy6IBM//9k= ------=_NextPart_000_0013_0101AD37.086B0F28-- From nobody Fri Aug 12 07:23:03 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE16112D552 for ; Fri, 12 Aug 2016 07:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no 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 UKXIJ6eHDVpV for ; Fri, 12 Aug 2016 07:23:01 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 175A912D5D8 for ; Fri, 12 Aug 2016 07:23:01 -0700 (PDT) Received: from unnumerable.local ([173.57.161.14]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u7CEMxDe016880 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Fri, 12 Aug 2016 09:22:59 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.57.161.14] claimed to be unnumerable.local To: "dispatch@ietf.org" References: <618902ec-9fd6-71e3-c3ee-3c6bd22b056a@nostrum.com> From: Robert Sparks Message-ID: <6b797b33-8482-3cca-51c5-7c795962d8b6@nostrum.com> Date: Fri, 12 Aug 2016 09:23:03 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <618902ec-9fd6-71e3-c3ee-3c6bd22b056a@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dispatch] Registration for SIPit 32 closes 29Aug X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 14:23:03 -0000 If you plan to bring an implementation to this SIPit and have not yet registered, please do so asap. RjS On 7/7/16 4:42 PM, Robert Sparks wrote: > The SIP Forum's SIPit 32 will be held at the University of New > Hampshire Interoperability Laboratory September 12-16, 2016. > > In addition to the usual thorough testing, we expect this event to > focus on new evolutions in SIP Security such as the mechanisms defined > in the STIR working group. We also hope to inform the new SIPBRANDY > effort in the IETF. > > More information about the SIPit is available at https://www.sipit.net. > > Registration is open at https://www.regonline.com/sipit32 > > RjS > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Aug 15 00:45:41 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F3512D893 for ; Mon, 15 Aug 2016 00:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 YozmvjusSTle for ; Mon, 15 Aug 2016 00:45:39 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 C2C0712D589 for ; Mon, 15 Aug 2016 00:45:38 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id 52so18206830qtq.3 for ; Mon, 15 Aug 2016 00:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=Wfatry18B6kvtoqK0Ikn40++McENp6dPvewbsujx+BU=; b=zlwWWr6NU0aqTlDn0i7yznCTJq1Q5w4E0ejbMRqclwDZRENHWVUOFlF9rKlN/6cM5a ya2TSqAizpxCSIpZ21Dan3Ezk++BKUQrs9HY4dsplMiJiGqLLpziR7e2n73Z+LAX8UJ1 /2z7Kz1solS81svqUtRDrrfVfxfBOjH3OKx+r4H+r7RPc9kTNoyqTW3LVplhOGGgNv+/ kYIcLPTPBh8WGvd+8ZLQpPLQRGmkgfpEEJbrOcH9l56AQ6yQKsfFWGXR2sq49ls39+JR eTPi8KZgPdBWImIxboA8hBaZJ3AScsibJtg++iQR06xUZMaq0NB/k0+3il+LTdQPDMyM 3HFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Wfatry18B6kvtoqK0Ikn40++McENp6dPvewbsujx+BU=; b=LUSuflBEmQTOLrQb+R624ivuOZ/UNmbNwgUDNo0xXT3SSMCpOLfwgypxV0JXq3gJwj CuTxt0OmSln3+VTZCmvCjM3OoRMHoiAJERbqX6iA0sDsfuSDCmvSOYBl4Vl15bWlAd0A DaOY09VVmqtb6eE74yDXPJsS/p2Se+qMJ2olE1zXYwSH08L6agvi0pLA2A80WSKkgKno rQLsgOT7sEcRT7LGHX3kqZRLLxTBKEi0XXWxE3oxr/Bh71i5XNw0423pXw7EqkwimP67 Nyek2hj1G03qkF9rkvrik8+YFjdaAH+PvoQVDOcqPQau2+ZVU8/0KoyNd/tgPqVMLRkK qLEw== X-Gm-Message-State: AEkooutB7uNNEjohGHywlthsXCS7dvt71XXVVxDMSYf5bypiH2fS7CcFgkYHT75UCFy+3FYPbxRo1ZbGpDbsZA== X-Received: by 10.237.52.225 with SMTP id x88mr31200875qtd.24.1471247137876; Mon, 15 Aug 2016 00:45:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Mon, 15 Aug 2016 00:45:37 -0700 (PDT) From: Martin Thomson Date: Mon, 15 Aug 2016 17:45:37 +1000 Message-ID: To: draft-bhjl-x509-srv@tools.ietf.org, DISPATCH Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dispatch] Review of draft-bhjl-x509-srv-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 07:45:41 -0000 It seems like there are many similar sorts of approaches to this general problem floating around. If there is indeed interest in deploying something, then I am encouraged. However, I think that this document requires a lot of work. Meta: This looks very similar to draft-miller-saag-key-discovery-00. That uses webfinger. I would encourage the authors to talk to Matt and Suhas to see if they have any input on these designs. RFC 4387 isn't a great design. I'd be quite surprised to learn of independent, interoperable implementations given some of the omitted details there. The biggest problem with RFC 4387 is the use of fixed URL paths. It is excused because it predates RFC 7320 excuses it, but does not excuse any document that chooses to rely on it. That this is a service discovered via SRV alleviates some of the pressure on servers, but I think that a better approach would be to use .well-known URIs and avoid SRV. SRV is not a mechanism that is well-integrated into HTTP stacks, so you would forcing implementations to take on special resolver logic. I don't see much information in the document about how this might be deployed. Both SRV and DNSSEC have some deployment challenges. The document needs to be a lot clearer about where trust comes from. Much of the text talks about the use of DNSSEC and HTTPS in various ways, each of which might be relied upon to provide certain properties (authentication, integrity, etc...), but I don't think that the intent of this document is to rely on any of that stuff: this is just a way to find certificates and whether those certificates are trusted or not will be determined based solely on their contents and any configured trust anchors (or the equivalent of that for PGP). Section 2: The document never actually says how an implementation might choose the domain name to attach the _tcp to. That needs to be written down. Maybe this can subsume Section 4. Is the client expected to follow CNAME/DNAME when resolving this? What value does DNSSEC provide here? The implication is that integrity is used for something, but from responses to questions on this list, it's fairly clear that this isn't at all important. This: "The certificate of the https server SHOULD be validated by a DNSSEC signed TLSA record, and MAY also be validated by a certificate authority." disagrees with established practice for authenticating HTTPS servers. DANE is - at best - aspirational. More to the point, this needs to identify the name that will be used when authenticating the server. The introduction of SRV into the mix means that you are creating a delegation, which has huge risks if you pick the wrong answer. The best advice I have is to not permit the creation of delegations, because this reduces exposure to attacks on the integrity of the DNS. Section 3: Is bob@example.com an email address? The document needs to be more precise about how you go from inputs to produce these URIs. WebFinger [RFC7033] is quite precise about its inputs and how they are interpreted to form a URI. You also need to be much more precise about what requests are made, and the form of the responses. RFC 4387 is remarkably woolly about some of these important details, to the point that it might not be interoperable. Section 4: This seems a bit odd way of approaching the problem. You could just say that if FOO@example.com and f.o.o@example.com are considered equivalent by example.com then the same answer should be provided to requests for both names. And that you can use a redirect or the Content-Location header field to identify a single location if that is desirable. RFC 4387 is selective about what parts of HTTP it likes, but it is pretty big on the use of redirects, so no problem with using 3xx there. Section 5: The domain MAY publish validation certificates using TLSA records at the name _smimeca._tcp. This little throwaway line really needs its own section. The two sentences in the doc aren't nearly enough detail to produce an implementation. What do these certificates contain? Not trust anchors, I hope. What is the point of these being TLSA records? Is the intent to produce the missing pieces of a certification path [RFC 5280] that a client might be able to make a decision about the trustworthiness of the end-entity certificate that the certificate store has? Why would the certificate store not include that information directly? TLS includes multiple certificates from the certification path in its Certificate message, maybe you can find some way for the store to produce additional certificates. If you use HTTPS to retrieve them, then you don't have to stitch together more disparate protocols and you avoid some of the confidentiality issues that arise from sticking stuff in the DNS. Section 7: That last paragraph is unnecessary: if the trust in the certificate that is provided is based on information that is acquired independently of this protocol, then you don't need to say things like that. That sort of statement implies that there is some component of trust being conveyed, which would mean an entirely different analysis than what I've done here (which is of a direct acquisition protocol, not a security protocol). What if a user wanted to only make their certificate available to a certain subset of requesters? Is that possible? From nobody Mon Aug 15 15:29:28 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5FD612D776 for ; Mon, 15 Aug 2016 15:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 rcJnY1S2GVhY for ; Mon, 15 Aug 2016 15:29:25 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 197C212D759 for ; Mon, 15 Aug 2016 15:29:25 -0700 (PDT) Received: (qmail 71945 invoked from network); 15 Aug 2016 22:29:24 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 15 Aug 2016 22:29:24 -0000 Date: 15 Aug 2016 22:29:01 -0000 Message-ID: <20160815222901.10364.qmail@ary.lan> From: "John Levine" To: dispatch@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dispatch] Review of draft-bhjl-x509-srv-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 22:29:26 -0000 Thanks for the review. I can see this draft needs a lot more explanatory material for the benefit of people who aren't familiar with all the ways that mail is not like the web, or who don't understand the idea of a server that returns certificates for e-mail addresses. Specific points: >The document never actually says how an implementation might choose >the domain name to attach the _tcp to. That needs to be written down. It's the domain name in the e-mail address. I thought that was obvious, but I can try to make it clearer. >This looks very similar to draft-miller-saag-key-discovery-00. That >uses webfinger. I would encourage the authors to talk to Matt and >Suhas to see if they have any input on these designs. >That this is a service discovered via SRV alleviates some of the >pressure on servers, but I think that a better approach would be to >use .well-known URIs and avoid SRV. ... Unfortunately, unless I seriously misunderstand webfinger, it is a non-starter here. If you want to do a webfinger lookup for, say, bob@example.com, you look up the A or AAAA record for example.com and send an https request to a web server at that address. Domains in e-mail addresses have MX records, not A records. There are many e-mail domains with MX records but no A or AAAA. Even if there is an A or AAAA, there's no reason to expect to find a server listening on port 443, and if there is something listening, no reason to expect that whoever runs that server has anything to do with the mail system. (I provide mail for a whole bunch of domains whose web service is somewhere else and whose web managers I do not know and do not want to know.) RFC 7033 section 7 says that you can sort of get the same effect of MX records by using web redirects, but of course that only works if you have a web server in the first place, which we don't. SRV records were invented exactly to provide MX-style redirection for other services. If you think that SRV is too hard (which I don't, see below) the options are not great. The STS effort to provide cert pinning for mail servers has run into the same problem, and the least awful alternative is fixed host name prefixes which gives stomache aches to DNS types. So the Miller draft couldn't be used without some serious surgery to the discovery part, and if we need to do that, I'd rather use an existing standards track spec. >I don't see much information in the document about how this might be >deployed. Both SRV and DNSSEC have some deployment challenges. I had a long talk with some people from Gmail at the Berlin IETF. They didn't see any great problems. This is not a design that's likely to be implemented in web browsers; it's for mail clients (Outlook, Apple Mail, etc.) and within the servers of webmail providers. MUAs already do all sorts of things that web browsers don't, and I don't see a SRV lookup as a problem. >The document needs to be a lot clearer about where trust comes from. > ...: this is just a way >to find certificates and whether those certificates are trusted or not >will be determined based solely on their contents and any configured >trust anchors (or the equivalent of that for PGP). Quite right. For 20 years the trust models for PGP and S/MIME have been vague and I don't see that changing. >What value does DNSSEC provide here? If you believe that DNSSEC provides a chain of trust from the domain name to the SRV record to the TLSA for cert in the web server the SRV points to, that's what if provides. I am not wedded to it, which is why there's no MUST for the DNSSEC stuff. >Is bob@example.com an email address? Um, yes. This whole draft is about finding certs for e-mail addresses. >Section 4: > >This seems a bit odd way of approaching the problem. You could just >say that if FOO@example.com and f.o.o@example.com are considered >equivalent by example.com then the same answer should be provided to >requests for both names. There is no such thing as "equivalent" e-mail addresses. RFC 5321 and its predecessors are carefully written that way. Only the mail server that receives the mail gets to interpret the local part of an address, and I'm trying hard not to change that. >Section 5: > > The domain MAY publish validation certificates using TLSA > records at the name _smimeca._tcp. > >This little throwaway line really needs its own section. The two >sentences in the doc aren't nearly enough detail to produce an >implementation. What do these certificates contain? Not trust >anchors, I hope. Yes, they're trust anchors. They sign the S/MIME certificates the server returns, if your model is that the domain is authoritative for its mail users' certs. If that's not your model, you don't. >What if a user wanted to only make their certificate available to a >certain subset of requesters? Is that possible? I suppose if you wanted a private server, you could stick one of the usual web login protocols in front of the requests. But it's not a problem this draft tries to solve. R's, John From nobody Tue Aug 16 09:38:48 2016 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E625012B007; Tue, 16 Aug 2016 09:38:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147136552289.22922.9859477236301677475.idtracker@ietfa.amsl.com> Date: Tue, 16 Aug 2016 09:38:42 -0700 Archived-At: Cc: ben@nostrum.com, dispatch@ietf.org, dispatch-chairs@ietf.org Subject: [dispatch] dispatch - New Meeting Session Request for IETF 97 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 16:38:43 -0000 A new meeting session request has just been submitted by Mary Barnes, a Chair of the dispatch working group. --------------------------------------------------------- Working Group Name: Dispatch Area Name: Applications and Real-Time Area Session Requester: Mary Barnes Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 175 Conflicts to Avoid: First Priority: appsawg apparea avtcore avtext bfcpbis clue core dbound ecrit insipid mmusic netvc p2psip payload rmcat rtcweb sipcore siprec stir stox straw webpush xrblock Second Priority: tram tsvwg tsvarea opsarea lmap Special Requests: Please schedule in the 1st slot on Monday morning, list the meeting as coupled with ARTAREA, and avoid the same kind of conflicts with other area meetings and any Bofs and potential new ART WGs. --------------------------------------------------------- From nobody Sat Aug 20 08:26:46 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200B912D87F for ; Sat, 20 Aug 2016 08:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.768 X-Spam-Level: X-Spam-Status: No, score=-115.768 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 5k7mUHxOl6bP for ; Sat, 20 Aug 2016 08:26:43 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C48E12D1AC for ; Sat, 20 Aug 2016 08:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1540; q=dns/txt; s=iport; t=1471706803; x=1472916403; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=A0qKhBHm5eU3E9EYIS/rfoO/UCOYfnPPVerEgPmDmWM=; b=AliWUX3gJMTMqjidSGM1mIhAnD9Km5ngg/IMyFgt8FnCcZGHDIsCaE1W JG+2ZeKU0l8wCAEBuJtJG4TwAV1kCqswsW6nf02BO7PD8awhM4koS02Bi BP0aZzC9izx+tQnLNXYndph5R+QXdL4eHiSBqnkAq48CafBic6BvQGtHw 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtAgBldbhX/4MNJK1eg0RWfAe3bIF9J?= =?us-ascii?q?IUvSgKBOzgUAgEBAQEBAQFeJ4ReAQEEAQEBODQLBQsCAQgYHhAnCyUCBA4FiCk?= =?us-ascii?q?IDrsSAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWIIwiCTYQSEQEcgyyCLwWOH4spA?= =?us-ascii?q?Y8egW2EXIkHjD+DdwEeNoN6cIVFN38BAQE?= X-IronPort-AV: E=Sophos;i="5.28,550,1464652800"; d="scan'208";a="313154157" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Aug 2016 15:26:42 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u7KFQgKF027988 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 20 Aug 2016 15:26:42 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 20 Aug 2016 11:26:41 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1210.000; Sat, 20 Aug 2016 11:26:41 -0400 From: "Cullen Jennings (fluffy)" To: John R Levine Thread-Topic: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml Thread-Index: AQHR+vdAk+j6og5nDk2ppXLcWQ3uYg== Date: Sat, 20 Aug 2016 15:26:41 +0000 Message-ID: <922EDA7D-2269-4E9D-A72A-87327DE60410@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.249.165] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Dispatch WG Subject: Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 15:26:45 -0000 I find this interesting and would like to see something along these lines g= et published but I think there are a some area that probably need some diss= olution.... Security model ... I'm a big confused by the use of HTTPS and DNSSEC. They = both seem unneeded if the idea is a certificate is more or less self securi= ng and public The API. I'd like to see it clearly work for all types of URIs including em= ail. It also seems that perhaps a parameter that directly indicated the ret= urned type like x509, pgp, etc would be a better API design that using uri = vs email to indicate if it was x509 or pgp.=20 I don't get why the Name Matching parts happens.=20 I think what you are really talking about here designing a HTTP REST based = API for retrieval of certificates (and it happens to have an SRV entry). Th= at seems to be an idea worth discussing.=20 Cullen (in my individual contributor role) > On Jul 22, 2016, at 4:54 AM, John R Levine wrote: >=20 > The WG seemed OK with it. After talking to people who plan to implement = it I updated the draft with some editing fixes and a longer security sectio= n. >=20 > This also seems appropriate for AD sponsored, please. >=20 > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Sat Aug 20 10:41:24 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F7512B00D for ; Sat, 20 Aug 2016 10:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=WXJCLAQd; dkim=pass (1536-bit key) header.d=taugh.com header.b=GRDHyRYS 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 Cwx3j9o1XuyA for ; Sat, 20 Aug 2016 10:41:21 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76E60128874 for ; Sat, 20 Aug 2016 10:41:21 -0700 (PDT) Received: (qmail 44971 invoked from network); 20 Aug 2016 17:41:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=afaa.57b8963f.k1608; bh=5IH/gj/xlbpaqa4mbthcV0NdjR2IhicfltZZLIf1qBc=; b=WXJCLAQdTxcIB7HCDAGMzev/zuPz3KnEeAwGDirxLnmhNWANYVR4+X+cEqToG3UJ5ITfo1qKj55MlzwXquCYYJEbiuUq6TEBpM43ylcHa43EpFNqAhKWdBJZDy0Hq0jEHA1MCs/nOZNMDDfGvFLsJ5/zyQ7Rs26xd816ZwfRmqPL4LPArTU1btuxj+QXl7D8K3srd2aFVbQBZmO6RNOtEjbwXaMZ8msBKkIi4teflzANDCIgfDGwG3eV+mlWfYyC DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=afaa.57b8963f.k1608; bh=5IH/gj/xlbpaqa4mbthcV0NdjR2IhicfltZZLIf1qBc=; b=GRDHyRYS9WFwFWZmG9JszsMT/rjOS5v1xq3Ffq9JzVaFNw/tN/4XJTVpViIBbs0ScRw6TfDlNC2VcdIGqCZdI86qZuOOogxPzeTQPcr/sHGKToFmbX4stt2Jt3GelUod695vGfGCF1QBaHnnUG1sMxqLjbGSIFuaJC6ZgPKIsaKNSJSn8LGO1/RFywtF1OIpFc37ucfif2hwTwZrj35W5KfdPTid024S5nI1pyCY/pDgH8TYQjQGSk+xBvjZRvO1 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 20 Aug 2016 17:41:19 -0000 Date: 20 Aug 2016 13:41:19 -0400 Message-ID: From: "John R Levine" To: "Cullen Jennings (fluffy)" In-Reply-To: <922EDA7D-2269-4E9D-A72A-87327DE60410@cisco.com> References: <922EDA7D-2269-4E9D-A72A-87327DE60410@cisco.com> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: Dispatch WG Subject: Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 17:41:23 -0000 > Security model ... I'm a big confused by the use of HTTPS and DNSSEC. > They both seem unneeded if the idea is a certificate is more or less > self securing and public 1The security model is deliberately vague. Some people believe that if a domain publishes S/MIME certificates for its mail users, that cert is authoritative. If you do, the HTTPS and DNSSEC provide a chain of trust. If we think that publishing a signed TLSA for the S/MIME signing cert is adequate, we can ditch the rest of the DNSSEC, although https is best practice these days for anti-snooping purposes. > The API. I'd like to see it clearly work for all types of URIs including email. Please, no, not death by overgeneralization. We have at least one large mail system that wants to publish certs for its mail users. > It also seems that perhaps a parameter that directly indicated the > returned type like x509, pgp, etc would be a better API design that > using uri vs email to indicate if it was x509 or pgp. This is essentially a profile of RFC 5280, which has been a standards track RFC for eight years. Let's not invent any more new stuff than we have to. > I don't get why the Name Matching parts happens. Because email addresses are fuzzy. On some systems bobsmith@example and bob.smith@example and/or bobsmith-ext@example are equivalent, while on others they aren't. (A brief review of RFC 5321 will remind us that no, there is no such thing as a canonical version of a mail address.) So this says the cert lookup should use the same fuzz that the mail system does. > I think what you are really talking about here designing a HTTP REST > based API for retrieval of certificates (and it happens to have an SRV > entry). That seems to be an idea worth discussing. No, once again, it's just a profile of RFC 5280. R's, John From nobody Sat Aug 20 12:58:49 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A923C12D1E3 for ; Sat, 20 Aug 2016 12:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -113.169 X-Spam-Level: X-Spam-Status: No, score=-113.169 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 vP9W6T_1qgAg for ; Sat, 20 Aug 2016 12:58:47 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA2412D09C for ; Sat, 20 Aug 2016 12:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=484; q=dns/txt; s=iport; t=1471723127; x=1472932727; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=i4ib4gclty1VST+lbDzZWoizeLq9RAkFPxzBVTwmEuM=; b=VZzhRen18D5HE4mfRD2PiM/Un+b+3EFqTeUpTsihXHNKWduSvp7xXsA3 +zIUCdfDjqvRsZQsPJOqpMF3zsn9wteKh70aWahSmAkBQU2X0y3DXF52B CelVV2IbOSQGZHTe2i7lEIeV+glv5fVHv39UetjbgrSec+JLXj5dwNDCs Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlAgCdtbhX/4wNJK1eg0RWfAe3boF9h?= =?us-ascii?q?h0CgTs4FAIBAQEBAQEBXieEXgEBBAE6PwULAgEIGB4QMiUCBA4FiCkIuzQBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEciCMIgk2EQIMsgi8BBJlIAY8egVcWhFyJB4w/g?= =?us-ascii?q?3cBHjaDenCFfH8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,551,1464652800"; d="scan'208";a="139901388" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Aug 2016 19:58:46 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u7KJwkl1002767 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 20 Aug 2016 19:58:46 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 20 Aug 2016 15:58:45 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1210.000; Sat, 20 Aug 2016 15:58:45 -0400 From: "Cullen Jennings (fluffy)" To: John R Levine Thread-Topic: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml Thread-Index: AQHR+woeW4aPxydAW0uq4esxsgNcRqBSh38A Date: Sat, 20 Aug 2016 19:58:45 +0000 Message-ID: <6FEA81EA-1E1B-4211-AF83-443E1DC6B7C2@cisco.com> References: <922EDA7D-2269-4E9D-A72A-87327DE60410@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.249.165] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Dispatch WG Subject: Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 19:58:49 -0000 > On Aug 20, 2016, at 11:41 AM, John R Levine wrote: >=20 >>=20 >> I think what you are really talking about here designing a HTTP REST bas= ed API for retrieval of certificates (and it happens to have an SRV entry).= That seems to be an idea worth discussing. >=20 > No, once again, it's just a profile of RFC 5280. I'm just not seeing this. Walk me thought how this is a profile of 5280. I = don't even see what parts of 5280 this would profile.=20 From nobody Sat Aug 20 13:25:37 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B143312B043 for ; Sat, 20 Aug 2016 13:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=J3lXidPn; dkim=pass (1536-bit key) header.d=taugh.com header.b=jhgm6qog 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 1G9_ExSZCvH9 for ; Sat, 20 Aug 2016 13:25:33 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50C9A12B01F for ; Sat, 20 Aug 2016 13:25:33 -0700 (PDT) Received: (qmail 19655 invoked from network); 20 Aug 2016 20:25:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=4cc6.57b8bcb9.k1608; bh=0+tikXzRNe/Si6B6joAryK7UkC15oGzXWbaT+i7vz18=; b=J3lXidPn9ZLfAM+fc/bwTBs9kp3Z9A6Mja4kg59Q8oeK8cNYvyN2ER/vN2kYOXdh023DHKGjUS/4FGEH/07GVxaiUjgAASuPkRaKX4IAn+Ejy0HrJ7JHq0jbaoJak8uRQzbDtF91bGikgwMoi6Xepw6mjVWmf3eM5N9W85Ox7WBHPrNIOVk9l7qiYRxgcoUMOZAOiUzqkaMIrR3oS/yf6Avi5vOz8fap5mE7zNz8yNqkg7ixVXgPzU3p37pBf3+y DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=4cc6.57b8bcb9.k1608; bh=0+tikXzRNe/Si6B6joAryK7UkC15oGzXWbaT+i7vz18=; b=jhgm6qogG/O0YOQ0Q5rKNk6y77rjDJWqPigHwy56FHVSsMKmKRanjshwquP+xzSItp06KBK8AA1fPwWNgztL32QV0WjIHOqurI8Vjk7AU6McAP7mbEQeju+VwNscWGKf7ieSfoMTT7anJLgCKsUiPt/6UfyzYDUq+WWx6BNqFRKyNBc6XA//uu9wOXDSMW91ZSKDbUU+KskM7gp6YY4fp6FG3e8cGXAVeX4bRTugOlhNm5xbJVpkHIm6Q1HrRPsZ Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 20 Aug 2016 20:25:29 -0000 Date: 20 Aug 2016 16:25:28 -0400 Message-ID: From: "John R Levine" To: "Cullen Jennings (fluffy)" In-Reply-To: <6FEA81EA-1E1B-4211-AF83-443E1DC6B7C2@cisco.com> References: <922EDA7D-2269-4E9D-A72A-87327DE60410@cisco.com> <6FEA81EA-1E1B-4211-AF83-443E1DC6B7C2@cisco.com> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: Dispatch WG Subject: Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 20:25:35 -0000 >> No, once again, it's just a profile of RFC 5280. > > I'm just not seeing this. Walk me thought how this is a profile of 5280. I don't even see what parts of 5280 this would profile. Sorry, I can't read my own handwriting. It's a profile of RFC 4387. The SRVs come from section 3.2 and 3.5.1, the URL syntax comes from sections 2.2, 2.3, and 3.3, and the response format from section 2.5.4. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sat Aug 20 14:13:52 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E505E12D18C for ; Sat, 20 Aug 2016 14:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.069 X-Spam-Level: X-Spam-Status: No, score=-115.069 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 2TQ4ctbHGiCJ for ; Sat, 20 Aug 2016 14:13:49 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A4A12B005 for ; Sat, 20 Aug 2016 14:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=588; q=dns/txt; s=iport; t=1471727628; x=1472937228; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XtOoxNnWHgcj5AYHBEQChlPN4yQXBDH83GRNLE5BQ5M=; b=ayJnQb6OFST4rkUsYOsXzXSHN8U07T5yEHl/7pyIiOlEZzJjMdqdSqUy EwY6vidWrqoXL4gbgvNjS/eJnrF6/QQ1Qx+JcICBz1n2BU6Kdb0jlBf6x El4+9VlToyg3lEvB2Eir9sLaLKrcwaqytRUd4CvpD0U4tg72p2nXdOoIQ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9BgCzx7hX/4kNJK1eg0SBUge3cIF9h?= =?us-ascii?q?h0CgTs5EwIBAQEBAQEBXidBDoQPAQEEATo/BQsCAQgYHhAyJQIEDgWIKQi7PwE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBARyIIwiCTYRAgyyCLwEEmUgBjx6BVxaEXIMzh?= =?us-ascii?q?VSMP4N3ASABM4N6cIQbgWF/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,551,1464652800"; d="scan'208";a="140071820" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Aug 2016 21:13:47 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u7KLDlED024860 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 20 Aug 2016 21:13:47 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 20 Aug 2016 17:13:46 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1210.000; Sat, 20 Aug 2016 17:13:46 -0400 From: "Cullen Jennings (fluffy)" To: John R Levine Thread-Topic: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml Thread-Index: AQHR+woeW4aPxydAW0uq4esxsgNcRqBSS+2pgABQh4A= Date: Sat, 20 Aug 2016 21:13:46 +0000 Message-ID: <60C1700F-132E-4166-A01D-D5F588E50EB4@cisco.com> References: <922EDA7D-2269-4E9D-A72A-87327DE60410@cisco.com> <6FEA81EA-1E1B-4211-AF83-443E1DC6B7C2@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.249.165] Content-Type: text/plain; charset="us-ascii" Content-ID: <0EBB7A51608EDC4BBC2DEFCC8B3F4CF6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Dispatch WG Subject: Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 21:13:50 -0000 > On Aug 20, 2016, at 2:25 PM, John R Levine wrote: >=20 >>> No, once again, it's just a profile of RFC 5280. >>=20 >> I'm just not seeing this. Walk me thought how this is a profile of 5280.= I don't even see what parts of 5280 this would profile. >=20 > Sorry, I can't read my own handwriting. It's a profile of RFC 4387. >=20 > The SRVs come from section 3.2 and 3.5.1, the URL syntax comes from secti= ons 2.2, 2.3, and 3.3, and the r Ah, that makes more sense. Let me have a read of 4387 time some time and se= e if this all makes more sense.=20 From nobody Sun Aug 21 06:26:28 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E58F12D0AF for ; Sun, 21 Aug 2016 06:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 hNy25_GFKN3L for ; Sun, 21 Aug 2016 06:26:25 -0700 (PDT) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (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 C2B6E128B44 for ; Sun, 21 Aug 2016 06:26:24 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id z10so29513686ybh.2 for ; Sun, 21 Aug 2016 06:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WRIKOyezLtWqIehb8KYWZ+sNnT53JqATP4IXoAg4Ofg=; b=kvqy5BuBvNn4+tFAbT5b2bGIYSwxv5eWSff9M+plcypL8jx8amXyX5kHkjQqGkd3qK caZaZegpYGBUiRMZNjEHw5Pe/jZlH89vYcHN/Xu7EU/11Jj1h4NXk/V812EUuoAReyuw nWIZEGYH51Hkws+RMipkYrWtaTg4JAGGdMX1mGcgpyjkR7Wbq0psPuGleWpDwDbkgxBg LZKEci+KL/jB+qBm4pNuZlFx8RU/BOfQEihWeEg1/11vVPiBtYr8Ll3mhGbONzCH2h13 po0P4p4BeMB2x1N3lsqWh5hDcJHOpK8u1ZWAdRCS2wLv43hsc5Oy1+pivqqHwUF71k/l yZsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WRIKOyezLtWqIehb8KYWZ+sNnT53JqATP4IXoAg4Ofg=; b=moXP5pZMklr+GL8Ht49Eg68busNUXgD5l3OACWpReRLEvRFct7gsGS7EqgPXv4cIMp 4h0ydL9CD+J2C63iodM0oNngjkq3kLeJvjc5ovu619hMkYz1wFNSi41W3x26KdJqC4jH vrsrmYht6jlOccWtGi/JMsbk/3Sa8zttERcVrvXm+KRgM4L9JDXyGkZARo+/Pjaz/bEY BOZlp5ifVEUd6lglmEflBHB+g7Q2bFh5vz4Asr9UHFE8s8dWcbQZRhAqpWM891h7PEmG 7y610jjVDNkDROxkbp7StBmFzANOoCaP6jPFhImdbLTremkq8R/WmQS43i4lom+GuV7+ Nqig== X-Gm-Message-State: AEkoous5sUQpbqJrZ8FH3d2EdJArwpExMropuuZAvbNOMrVI6wUZPaIKvCWK+Hg+Q6SD0f9+334zA++5dYO3mw== X-Received: by 10.37.3.198 with SMTP id 189mr13266286ybd.57.1471785983857; Sun, 21 Aug 2016 06:26:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Sun, 21 Aug 2016 06:25:43 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 21 Aug 2016 06:25:43 -0700 Message-ID: To: John R Levine Content-Type: multipart/alternative; boundary=001a11c02ddac10952053a94e044 Archived-At: Cc: Dispatch WG Subject: Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 13:26:27 -0000 --001a11c02ddac10952053a94e044 Content-Type: text/plain; charset=UTF-8 Comments below: OVERALL The trust model of this document seems confusing. Typically we assume that certificates are self-authenticating, i.e., the certificate can be provided to you by the attacker and you can independently validate its acceptability. And graf 2 of section 5 implies this by talking about a signature from a CA. However, in this protocol, you have the following additional cryptographic protocols in play: - A DNSSEC-signed SRV record - A DNSSEC-signed TLSA record - An HTTPS connection to the server - A potentially WebPKI-valid server cert This document should define precisely what combination of these elements is sufficient for the client to accept the certificate. For instance, if we have a DNSSEC-signed SRV that leads to a WebPKI valid HTTPS server which serves a self-signed cert for the user, is that acceptable? This reflects a completely different trust model from that assumed by S/MIME traditionally. Another way to ask this question is: is this an untrusted directory or is it a substitute for a PKI for e-mail certificates. This also goes to the question of whether this document should be in the security or ART area. DETAIL S 2. Your requirements for what cryptographic technology is used here are all non-MUSTs, but how important they are depends entirely on the trust model (see above). If the certs are self-authenticating and this is just an untrusted directory, then this is largely an operational question. However, if it is acting as a substitute CA, then actually having a cryptographically valid chain of inference is imperative and there need to be some MUSTs here. It's somewhat odd to encourage TLSA records (at SHOULD level) but a WebPKI valid certificate at MAY level. This is pretty much the opposite of standard practice for HTTPS on the Internet today. It's not like it's particularly onerous for someone running a Web server to get WebPKI valid certs. S 5. This section also needs to be fleshed out. Questions include: - You say "a blob of binary data". Do you mean that they are DER? That seems implied, but it could be compressed DER or something. This needs to be specified. - What is the relationship between the multiple certificates that are provided? Are they alternatives? Are some of them intermediates that can be used to validate the EE certificate (this is commonly required)? If so, which one is the EE cert? - Are there any requirements about the format of the various subject name fields? Say I ask for "bob@example.com" and get a cert for "alice@example.invalid". What do I do? This section about how to publish domain-operated CA certificates kind of seems like an add-on and needs to be fleshed out quite a bit more. For instance, why aren't you defining the same mechanism for PGP, as they seem analagous in this case. If you want to define TLSA records for CA certs for e-mail that seems like it should probably be the subject of a separate document. -Ekr On Fri, Jul 22, 2016 at 3:54 AM, John R Levine wrote: > The WG seemed OK with it. After talking to people who plan to implement > it I updated the draft with some editing fixes and a longer security > section. > > This also seems appropriate for AD sponsored, please. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --001a11c02ddac10952053a94e044 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Comments below:
OVERALL The trust mode= l of this document seems confusing. Typically we
assume that cert= ificates are self-authenticating, i.e., the
certificate can be pr= ovided to you by the attacker and you can
independently validate = its acceptability. And graf 2 of section 5
implies this by talkin= g about a signature from a CA.

However, in this pr= otocol, you have the following additional
cryptographic protocols= in play:

- A DNSSEC-signed SRV record
-= A DNSSEC-signed TLSA record
- An HTTPS connection to the server<= /div>
- A potentially WebPKI-valid server cert

This document should define precisely what combination of these
= elements is sufficient for the client to accept the certificate. For
<= div>instance, if we have a DNSSEC-signed SRV that leads to a WebPKI valid
HTTPS server which serves a self-signed cert for the user, is that=
acceptable? This reflects a completely different trust model fro= m that
assumed by S/MIME traditionally. Another way to ask this q= uestion is:
is this an untrusted directory or is it a substitute = for a PKI for
e-mail certificates.

This = also goes to the question of whether this document should be in
t= he security or ART area.
=C2=A0 =C2=A0=C2=A0

=
DETAIL
S 2.
Your requirements for what cryptograph= ic technology is used here are
all non-MUSTs, but how important t= hey are depends entirely on the
trust model (see above). If the c= erts are self-authenticating and this
is just an untrusted direct= ory, then this is largely an operational
question. However, if it= is acting as a substitute CA, then actually
having a cryptograph= ically valid chain of inference is imperative and
there need to b= e some MUSTs here.

It's somewhat odd to encour= age TLSA records (at SHOULD level) but a
WebPKI valid certificate= at MAY level. This is pretty much the
opposite of standard pract= ice for HTTPS on the Internet today. It's
not like it's p= articularly onerous for someone running a Web server to
get WebPK= I valid certs.


S 5.
This = section also needs to be fleshed out. Questions include:

- You say "a blob of binary data". Do you mean that they a= re DER? That
=C2=A0 seems implied, but it could be compressed DER= or something. This
=C2=A0 needs to be specified.

<= /div>
- What is the relationship between the multiple certificates that= are
=C2=A0 provided? Are they alternatives? Are some of them int= ermediates that
=C2=A0 can be used to validate the EE certificate= (this is commonly
=C2=A0 required)? If so, which one is the EE c= ert?

- Are there any requirements about the format= of the various subject
=C2=A0 name fields? Say I ask for "<= a href=3D"mailto:bob@example.com">bob@example.com" and get a cert = for
=C2=A0 "alice@example.invalid". What do I do?
=

This section about how to publish domain-operated CA ce= rtificates kind
of seems like an add-on and needs to be fleshed o= ut quite a bit
more. For instance, why aren't you defining th= e same mechanism for
PGP, as they seem analagous in this case. If= you want to define TLSA
records for CA certs for e-mail that see= ms like it should probably be
the subject of a separate document.=

-Ekr



On Fri, Jul 22= , 2016 at 3:54 AM, John R Levine <johnl@taugh.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">The WG seemed OK with it.=C2=A0 After talking= to people who plan to implement it I updated the draft with some editing f= ixes and a longer security section.

This also seems appropriate for AD sponsored, please.

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--001a11c02ddac10952053a94e044-- From nobody Sun Aug 21 09:39:19 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F98D12D1B7 for ; Sun, 21 Aug 2016 09:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=FudCLKOI; dkim=pass (1536-bit key) header.d=taugh.com header.b=K+SJgh9M 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 7ZGoM7LOpW_0 for ; Sun, 21 Aug 2016 09:39:15 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FA1312D0F9 for ; Sun, 21 Aug 2016 09:39:15 -0700 (PDT) Received: (qmail 61508 invoked from network); 21 Aug 2016 16:39:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=f042.57b9d931.k1608; bh=/579iutHCbTN/qk1ZjyPwQNFAyjaoeqtawMBalWkTYs=; b=FudCLKOICN212zER4aZfJUM6Kyp1Qrim/LRHQ9S0NI/tYL3T0HQtOPCKz7JjnWWqAvcJwieup6XGDf183d0JjtkZEe9GmYBhpHw7gCjcfDOWM079atUSSmdFVgXb0xWZ8/xrXquFe5CGsoVQi0fSJutSKIw9zeROH2d2mmLnudXtJ0LnBTpVDCxGoPT6wQkbI1VEmIVN0qK1aUwe9OvffdK5hVcikE76QrhDonTfPkbyIMD3CDzROex3TfUq6XDH DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=f042.57b9d931.k1608; bh=/579iutHCbTN/qk1ZjyPwQNFAyjaoeqtawMBalWkTYs=; b=K+SJgh9MsZ3nasjT74haRWXgh2jnxgYN8yowMgF3+/SaD9SD86voeWAOKV2/5HkIcSBIRHnjk6vW+KBRi5I8qbbfHbE319R35t0KyKzQITOoKDutE8zQ7nULtnRxIc7YmphbPMnoL6H2Y5G0QxIWgexo96pIsnbA45UUZoesvXVOT+YkAIx4AW7bNLG4NaLx9da8oQij4OOxSqb4Y5uN6udwjlOMto2jaCHIe4/HAJVIcqi1/pMCk7iIf+Z4iRBX Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 21 Aug 2016 16:39:13 -0000 Date: 21 Aug 2016 12:39:13 -0400 Message-ID: From: "John R Levine" To: "Eric Rescorla" In-Reply-To: References: User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: Dispatch WG Subject: Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 16:39:17 -0000 > This document should define precisely what combination of these > elements is sufficient for the client to accept the certificate. If only. Existing practice for PGP seems to be rather different from what the theory is ("if it doesn't look totally bogus, use it" vs "check and score WoT signatures against your private list") and for S/MIME it depends on what set of CAs are in your MUA, which in my experience is generally pretty stale. Adding to the confusion, some people appear to believe that a domain is a reliable authority for certs for its email addresses. (See for example the third paragraph in the introduction in RFC 7929 which makes no sense otherwise.) Others of us don't, since the relationships between domain operators and mail users are incredibly variable. If you are in the domain is authoritative camp, you can use DNSSEC->SRV->https as a chain of trust for the cert, or for S/MIME you can use DNSSEC->TLSA as a chain of trust for the signature. If you aren't, you can do whatever you do now and the DNSSEC doesn't get you anything beyond the usual anti-spoofing. If people agree these are the two plausible scenarios, I could easily add text describing them. I don't see any chance of deciding on only one or the other. > It's somewhat odd to encourage TLSA records (at SHOULD level) but a > WebPKI valid certificate at MAY level. This is pretty much the > opposite of standard practice for HTTPS on the Internet today. It's > not like it's particularly onerous for someone running a Web server to > get WebPKI valid certs. Good point, MUST for https seems obvious. > S 5. > This section also needs to be fleshed out. Questions include: > > - You say "a blob of binary data". Do you mean that they are DER? That > seems implied, but it could be compressed DER or something. This > needs to be specified. That's supposed to be whatever RFC 4387 did. Looking at it, it's not clear to me what encoding it expects, so I agree it could use some clarification. > - What is the relationship between the multiple certificates that are > provided? Are they alternatives? Are some of them intermediates that > can be used to validate the EE certificate (this is commonly > required)? If so, which one is the EE cert? Again, this is out of RFC 4387. I was under the impression that the client could look at the certs and see what chained to what. > - Are there any requirements about the format of the various subject > name fields? Say I ask for "bob@example.com" and get a cert for > "alice@example.invalid". What do I do? RFC 4387 again. > This section about how to publish domain-operated CA certificates kind > of seems like an add-on and needs to be fleshed out quite a bit > more. For instance, why aren't you defining the same mechanism for > PGP, as they seem analagous in this case. If you want to define TLSA > records for CA certs for e-mail that seems like it should probably be > the subject of a separate document. I suppose I could wave my hands and say that the domain publishes an OPENPGPKEY record with postmaster@, but it's not clear to me whether anyone would care. S/MIME signatures are (as I understand it) supposed to be deterministic, if you trust the signer, you trust the cert, while WoT is squishy. As far as putting it in a separate document, I wouldn't object but it's not clear what the advantage would be. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sun Aug 21 09:52:07 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5455412D0B0 for ; Sun, 21 Aug 2016 09:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 SnC0JY7Tgw7u for ; Sun, 21 Aug 2016 09:52:04 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 5168D12B04B for ; Sun, 21 Aug 2016 09:52:04 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id z8so39328764ywa.1 for ; Sun, 21 Aug 2016 09:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XgzgGpAp7xwRCmA2lKyawDs4nCiVqHrL6Cj105fxNPU=; b=MpoxWSz4hya5v2lMd1w9wWsellhzRIDnsvfmeD+uTvwhyHt1Ddvtwk/7ggVyjGfhgW j8LLieUe/OKDODDdDRgeP5OxCW+kg/j3F/qbAS/rHHDUjwcbn2KVajlBOo7AmnZ1Rne+ gEEGn4brpMiGRjf3upGyLL6KRy87Th70bzutQsa4chykvliQCeVYpOSVTxwzLaXuJHQW WYQg1bTxqKvKMwx07t46l33a5JrdwVaTQgevlyxXIfcQlLJjhVeK4HU5Jq4XepsQlB98 bstGMIMeEg7A/JWVtPh38jXV9bdHQXn/FM8kqX5o2IecJsPfiw53zqxGGdAsgCZ6g4LI B4VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XgzgGpAp7xwRCmA2lKyawDs4nCiVqHrL6Cj105fxNPU=; b=COOe8LPV8rlge6G/RSZW9Uy1Kkz1EzlANPSpdWDzi9KgBw4K2+85W5laPhpyBgDjNr GidQku1JtSr62Id2GXsxH34sFtij679/a//R/8qaRf1CxABJnnXO79AIqZW3bG5swxN9 jEpIseuu2M6e6DPINAjx8z5O8teY5eDBsEjA+x23IrLuIGx0cFDJw3ug1xAoloc2//l8 K8o6tLn5m1Wz0cSSRm1iFNR/JDVKH9Yq85qxmo65/OBLr3pxjNJIzikw8hn9AdTY2QW2 RsdnYoeIXhTgHAYWzvmE4WkWNHd9kobR5mUz33sSaqBO9773ygB3U+7MKry3OfucUuZh v7og== X-Gm-Message-State: AEkooutJomDrQMw+I/ZhhSzdMJsA78YibjucQgqUo1cirRwjmKfh09uP0APW9nYGWSZ/8hfTmSNNdK7YD138hQ== X-Received: by 10.129.161.129 with SMTP id y123mr15306609ywg.214.1471798323573; Sun, 21 Aug 2016 09:52:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Sun, 21 Aug 2016 09:51:23 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 21 Aug 2016 09:51:23 -0700 Message-ID: To: John R Levine Content-Type: multipart/alternative; boundary=001a114f8db24224d8053a97c00c Archived-At: Cc: Dispatch WG Subject: Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 16:52:06 -0000 --001a114f8db24224d8053a97c00c Content-Type: text/plain; charset=UTF-8 On Sun, Aug 21, 2016 at 9:39 AM, John R Levine wrote: > This document should define precisely what combination of these >> elements is sufficient for the client to accept the certificate. >> > > If only. Existing practice for PGP seems to be rather different from what > the theory is ("if it doesn't look totally bogus, use it" vs "check and > score WoT signatures against your private list") and for S/MIME it depends > on what set of CAs are in your MUA, which in my experience is generally > pretty stale. > > Adding to the confusion, some people appear to believe that a domain is a > reliable authority for certs for its email addresses. (See for example the > third paragraph in the introduction in RFC 7929 which makes no sense > otherwise.) Others of us don't, since the relationships between domain > operators and mail users are incredibly variable. > > If you are in the domain is authoritative camp, you can use > DNSSEC->SRV->https as a chain of trust for the cert, or for S/MIME you can > use DNSSEC->TLSA as a chain of trust for the signature. If you aren't, you > can do whatever you do now and the DNSSEC doesn't get you anything beyond > the usual anti-spoofing. > > If people agree these are the two plausible scenarios, I could easily add > text describing them. I don't see any chance of deciding on only one or > the other. Yeah, that seems like it might be OK in some sort of informational document describing common practice, but this document is asking for Standards Track, and in that situation it seems like actually specifying one class of behavior is the superior direction. It's somewhat odd to encourage TLSA records (at SHOULD level) but a >> WebPKI valid certificate at MAY level. This is pretty much the >> opposite of standard practice for HTTPS on the Internet today. It's >> not like it's particularly onerous for someone running a Web server to >> get WebPKI valid certs. >> > > Good point, MUST for https seems obvious. I don't just mean MUST for HTTP, but also encouraging the use of valid certs. > > > S 5. >> This section also needs to be fleshed out. Questions include: >> >> - You say "a blob of binary data". Do you mean that they are DER? That >> seems implied, but it could be compressed DER or something. This >> needs to be specified. >> > > That's supposed to be whatever RFC 4387 did. Looking at it, it's not > clear to me what encoding it expects, so I agree it could use some > clarification. > > - What is the relationship between the multiple certificates that are >> provided? Are they alternatives? Are some of them intermediates that >> can be used to validate the EE certificate (this is commonly >> required)? If so, which one is the EE cert? >> > > Again, this is out of RFC 4387. I was under the impression that the > client could look at the certs and see what chained to what. The text in 4387 is not maximally clear. It appears that perhaps the idea is that this is just EE certs. If it's a mix of multiple EE and chain certs, it's not reasonable to expect the RP to make sense of it. In any case, this text should be clear. - Are there any requirements about the format of the various subject >> name fields? Say I ask for "bob@example.com" and get a cert for >> "alice@example.invalid". What do I do? >> > > RFC 4387 again. It seems like a citation to the relevant section would be in order here. > This section about how to publish domain-operated CA certificates kind >> of seems like an add-on and needs to be fleshed out quite a bit >> more. For instance, why aren't you defining the same mechanism for >> PGP, as they seem analagous in this case. If you want to define TLSA >> records for CA certs for e-mail that seems like it should probably be >> the subject of a separate document. >> > > I suppose I could wave my hands and say that the domain publishes an > OPENPGPKEY record with postmaster@, but it's not clear to me > whether anyone would care. S/MIME signatures are (as I understand it) > supposed to be deterministic, if you trust the signer, you trust the cert, > while WoT is squishy. As far as putting it in a separate document, I > wouldn't object but it's not clear what the advantage would be. As usual, functional decomposition. -Ekr > > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. > --001a114f8db24224d8053a97c00c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Aug 21, 2016 at 9:39 AM, John R Levine <johnl@taugh.com><= /span> wrote:
This document should define precisely what combination of these
elements is sufficient for the client to accept the certificate.

If only.=C2=A0 Existing practice for PGP seems to be rather different from = what the theory is ("if it doesn't look totally bogus, use it"= ; vs "check and score WoT signatures against your private list") = and for S/MIME it depends on what set of CAs are in your MUA, which in my e= xperience is generally pretty stale.

Adding to the confusion, some people appear to believe that a domain is a r= eliable authority for certs for its email addresses.=C2=A0 (See for example= the third paragraph in the introduction in RFC 7929 which makes no sense o= therwise.)=C2=A0 Others of us don't, since the relationships between do= main operators and mail users are incredibly variable.

If you are in the domain is authoritative camp, you can use DNSSEC->SRV-= >https as a chain of trust for the cert, or for S/MIME you can use DNSSE= C->TLSA as a chain of trust for the signature.=C2=A0 If you aren't, = you can do whatever you do now and the DNSSEC doesn't get you anything = beyond the usual anti-spoofing.

If people agree these are the two plausible scenarios, I could easily add t= ext describing them.=C2=A0 I don't see any chance of deciding on only o= ne or the other.

Yeah, that seems like it m= ight be OK in some sort of informational document describing common practic= e, but this document is asking for Standards Track, and in that situation i= t seems like actually specifying one class of behavior is the superior dire= ction.


It's somewhat odd to encourage TLSA records (at SHOULD level) but a
WebPKI valid certificate at MAY level. This is pretty much the
opposite of standard practice for HTTPS on the Internet today. It's
not like it's particularly onerous for someone running a Web server to<= br> get WebPKI valid certs.

Good point, MUST for https seems obvious.

I= don't just mean MUST for HTTP, but also encouraging the use of valid c= erts.=C2=A0


S 5.
This section also needs to be fleshed out. Questions include:

- You say "a blob of binary data". Do you mean that they are DER?= That
=C2=A0seems implied, but it could be compressed DER or something. This
=C2=A0needs to be specified.

 That's supposed to be whatever RFC 4387 did.=C2=A0 Looking at it, it= 9;s not clear to me what encoding it expects, so I agree it could use some = clarification.

- What is the relationship between the multiple certificates that are
=C2=A0provided? Are they alternatives? Are some of them intermediates that<= br> =C2=A0can be used to validate the EE certificate (this is commonly
=C2=A0required)? If so, which one is the EE cert?

 Again, this is out of RFC 4387.=C2=A0 I was under the impression that the c= lient could look at the certs and see what chained to what.

The text in 4387 is not maximally clear. It appears that p= erhaps the idea is that this is just EE certs. If it's a mix of multipl= e EE and chain certs, it's not reasonable to expect the RP to make sens= e of it. In any case, this text should be clear.

<= br>
- Are there any requirements about the format of the various subject
=C2=A0name fields? Say I ask for "bob@example.com" and get a cert for
=C2=A0"alice@example.invalid". What do I do?

 RFC 4387 again.

It seems like a citation to= the relevant section would be in order here.


This section about how to publish domain-operated CA certificates kind
of seems like an add-on and needs to be fleshed out quite a bit
more. For instance, why aren't you defining the same mechanism for
PGP, as they seem analagous in this case. If you want to define TLSA
records for CA certs for e-mail that seems like it should probably be
the subject of a separate document.

 I suppose I could wave my hands and say that the domain publishes an OPENPG= PKEY record with postmaster@<domain>, but it's not clear to me wh= ether anyone would care.=C2=A0 S/MIME signatures are (as I understand it) s= upposed to be deterministic, if you trust the signer, you trust the cert, w= hile WoT is squishy.=C2=A0 As far as putting it in a separate document, I w= ouldn't object but it's not clear what the advantage would be.

As usual, functional decomposition.
<= br>
-Ekr
=C2=A0


Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

--001a114f8db24224d8053a97c00c-- From nobody Sun Aug 21 10:52:12 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC42612D0B3 for ; Sun, 21 Aug 2016 10:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 4AoTLg7RM2t0 for ; Sun, 21 Aug 2016 10:52:09 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8156812D0B1 for ; Sun, 21 Aug 2016 10:52:09 -0700 (PDT) Received: (qmail 73234 invoked from network); 21 Aug 2016 17:52:07 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 21 Aug 2016 17:52:07 -0000 Date: 21 Aug 2016 17:51:45 -0000 Message-ID: <20160821175145.26541.qmail@ary.lan> From: "John Levine" To: dispatch@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 17:52:11 -0000 >Yeah, that seems like it might be OK in some sort of informational document >describing common practice, but this document is asking for Standards >Track, and in that situation it seems like actually specifying one class of >behavior is the superior direction. Sure, if that were feasible. I see no chance at all of getting a sufficient agreement that domains are authorititative, or that they aren't. From what I've seen so far, few people have even thought about it, and fewer still outside the context of whatever mail system they personally are running. People at gmail said they're interested in this, so I can ask if they've thought about it in the context of a very large public mail system. >> Good point, MUST for https seems obvious. > >I don't just mean MUST for HTTP, but also encouraging the use of valid >certs. OK. >> Again, this is out of RFC 4387. I was under the impression that the >> client could look at the certs and see what chained to what. > >The text in 4387 is not maximally clear. It appears that perhaps the idea >is that this is just EE certs. If it's a mix of multiple EE and chain >certs, it's not reasonable to expect the RP to make sense of it. In any >case, this text should be clear. I am not a great pkix expert, so pointers and suggestions are welcone. R's, John From nobody Sun Aug 21 11:14:17 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E115212B02C for ; Sun, 21 Aug 2016 11:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 2BgKrBdUSb-l for ; Sun, 21 Aug 2016 11:14:15 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (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 225DD12D10D for ; Sun, 21 Aug 2016 11:14:15 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id a88so4690186ybi.0 for ; Sun, 21 Aug 2016 11:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FpNHVKBIzCjtz2JtOPUdFNYGLxkZZrv63LjDZPN9BdY=; b=DA+AGumdUShqPmIZ45CLXV+hTnMh3AcBT6p8yqOgamTmWW2QNQiDKhO6E4wdbKv0j4 Wq94f6ReAsvlhSDIc5CQAGhIRL0rOXDFir9Oq76itpJyoemHNk+QCHTwGO8MCHG2QCi/ AJzYevvZkpkftoAcupNM5Jaz7K3y2LdlLb5zBBEw/neziOvy918O1yt8pZYSky2imsDF Hrlru2qm2PMV573G/cwgdZIkMUY+5w/bVG0EMD0N3vFb1kjiHOxLLUFl0XQ94r+fdcer 0O791i2E6c9xT2/2amM7komgL8tpFJuT4zmc1PRHkvnsh6jny3Le0b+YnHF8GtneDFMG QSJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FpNHVKBIzCjtz2JtOPUdFNYGLxkZZrv63LjDZPN9BdY=; b=DSxUQUsQDomHlVZ1gdqBaSmHGDTDaGyiJHiXWzI6bVJxMPBfGT5pxc3SMhv+4TWyd0 dsLTdKcScrfIciX6QvQlOPMoYVBWAQcoYff29qfdaYRo5N0Xa24bBp7QT393u2AqYrlz w/Sahu6mTOZG1srREfsAf2TPFA+xB2oUBsH4SALkmTA4hqqT+uh6VjFOvQ+SXpJ6Wz5O Ti3vUbj16LVRTlGrcOxrqagL7ZawAkWpE+LbhRyf4myXaA6Q8KGqKaBbWseTndXH3gqa Fe04WMbMecaniqADrWhBz4FI6dazovtabREUN6ZLb9DVXmbvkMIg1TJDWkqZhAJZysz8 DIDw== X-Gm-Message-State: AEkoouvGqLVvEPnNo8mDCGtLyHjeNAcgywYTBpi68SgZGbZj57mchc1jXdmB/5hoy49admjbav+NsafltOQ0tQ== X-Received: by 10.37.3.198 with SMTP id 189mr14061432ybd.57.1471803254281; Sun, 21 Aug 2016 11:14:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.48.193 with HTTP; Sun, 21 Aug 2016 11:13:33 -0700 (PDT) In-Reply-To: <20160821175145.26541.qmail@ary.lan> References: <20160821175145.26541.qmail@ary.lan> From: Eric Rescorla Date: Sun, 21 Aug 2016 11:13:33 -0700 Message-ID: To: John Levine Content-Type: multipart/alternative; boundary=001a11c02dda26c8ae053a98e6b9 Archived-At: Cc: DISPATCH Subject: Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 18:14:17 -0000 --001a11c02dda26c8ae053a98e6b9 Content-Type: text/plain; charset=UTF-8 On Sun, Aug 21, 2016 at 10:51 AM, John Levine wrote: > >Yeah, that seems like it might be OK in some sort of informational > document > >describing common practice, but this document is asking for Standards > >Track, and in that situation it seems like actually specifying one class > of > >behavior is the superior direction. > > Sure, if that were feasible. I see no chance at all of getting a > sufficient agreement that domains are authorititative, or that they > aren't. From what I've seen so far, few people have even thought > about it, and fewer still outside the context of whatever mail system > they personally are running. People at gmail said they're interested > in this, so I can ask if they've thought about it in the context of > a very large public mail system. > This seems like a potential indicator that this technology is not yet ready for standardization. >> Good point, MUST for https seems obvious. > > > >I don't just mean MUST for HTTP, but also encouraging the use of valid > >certs. > > OK. > > >> Again, this is out of RFC 4387. I was under the impression that the > >> client could look at the certs and see what chained to what. > > > >The text in 4387 is not maximally clear. It appears that perhaps the idea > >is that this is just EE certs. If it's a mix of multiple EE and chain > >certs, it's not reasonable to expect the RP to make sense of it. In any > >case, this text should be clear. > > I am not a great pkix expert, so pointers and suggestions are welcone. OK. I think the high order bit here is that there are two basic kinds of certs in play: - EE certs (i.e., the ones that allegedly correspond to the user in question) - Intermediate CA certs that somehow could be used to construct a chain to the EE. It's pretty common, at least on the Web, to have situations where there is 1 or more intermediate between the trust anchor and the EE cert (e.g., in the case where CAs are cross-signed), which is why you need the second bucket. Unfortunately, sad experience with the Web indicates that it's not really possible to construct a chain which is verifiable to all clients, so it's probably best to just have this be a "you might be interested in" class. As I said previously, I kind of suspect that 4387 just meant that the certs were all alternative EEs, but then you probably want some other way to get the intermediates for the reason listed above, but in any case you shouldn't just have them all in the same bucket. So, what's probably best is to concretize this by saying that this bucket is just for EE and then define some other mechanism for getting intermediates. -Ekr --001a11c02dda26c8ae053a98e6b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Aug 21, 2016 at 10:51 AM, John Levine <johnl@taugh.com> wrote:
>Yeah, that seems l= ike it might be OK in some sort of informational document
>describing common practice, but this document is asking for Standards >Track, and in that situation it seems like actually specifying one clas= s of
>behavior is the superior direction.

Sure, if that were feasible.=C2=A0 I see no chance at all of getting= a
sufficient agreement that domains are authorititative, or that they
aren't.=C2=A0 From what I've seen so far, few people have even thou= ght
about it, and fewer still outside the context of whatever mail system
they personally are running.=C2=A0 People at gmail said they're interes= ted
in this, so I can ask if they've thought about it in the context of
a very large public mail system.

This s= eems like a potential indicator that this technology is not yet ready for s= tandardization.=C2=A0


>> Good point, MUST for https seems obvious.
>
>I don't just mean MUST for HTTP, but also encouraging the use of va= lid
>certs.

OK.

>> Again, this is out of RFC 4387.=C2=A0 I was under the impression t= hat the
>> client could look at the certs and see what chained to what.
>
>The text in 4387 is not maximally clear. It appears that perhaps the id= ea
>is that this is just EE certs. If it's a mix of multiple EE and cha= in
>certs, it's not reasonable to expect the RP to make sense of it. In= any
>case, this text should be clear.

I am not a great pkix expert, so pointers and suggestions are welcon= e.
=C2=A0
OK.

I think t= he high order bit here is that there are two basic kinds of certs in play:<= /div>

- EE certs (i.e., the ones that allegedly correspo= nd to the user in question)
- Intermediate CA certs that somehow = could be used to construct a chain to the EE.

It&#= 39;s pretty common, at least on the Web, to have situations where there is = 1 or more
intermediate between the trust anchor and the EE cert (= e.g., in the case where CAs
are cross-signed), which is why you n= eed the second bucket. Unfortunately, sad
experience with the Web= indicates that it's not really possible to construct a chain
which is verifiable to all clients, so it's probably best to just have= this be a "you might
be interested in" class.

As I said previously, I kind of suspect that 4387 just mea= nt that the certs were all
alternative EEs, but then you probably= want some other way to get the intermediates
for the reason list= ed above, but in any case you shouldn't just have them all in the
=
same bucket. So, what's probably best is to concretize this by say= ing that this
bucket is just for EE and then define some other me= chanism for getting intermediates.

-Ekr
= =C2=A0

--001a11c02dda26c8ae053a98e6b9-- From nobody Sun Aug 21 11:39:07 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C3B12D0DC for ; Sun, 21 Aug 2016 11:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=22XznlHJ; dkim=pass (1536-bit key) header.d=taugh.com header.b=AkepMuTt 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 EqyaL7H5Ls22 for ; Sun, 21 Aug 2016 11:39:03 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FA0D12D0D9 for ; Sun, 21 Aug 2016 11:39:03 -0700 (PDT) Received: (qmail 86953 invoked from network); 21 Aug 2016 18:39:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=153a8.57b9f545.k1608; bh=rR2byMGcxhYXLUuY39MobCuFzDp9bgFoyWiuwvojWh0=; b=22XznlHJ1kYfZzODeC/+0vxc2iIMGov2gFna2dJdnb5at2S4HlswCB6qgFrhi3Xk4Shy22wfyFjYB/3HqF0gM0nwzj2jUuHeS8t3H4ye6r/GyYNDPBuxGruWb8B7LTnJOjSshrSJU+L6g5ryo9x8dcNhTe3u29YyYvYXQTkdrchr8sYMViwdeNaPZ2PRE0jkVtstbnWPRpPML40iDFw2g9n6hrEiv0ucdQqKSwCm7WJGDZEsKklJfVX44ky0PaXL DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=153a8.57b9f545.k1608; bh=rR2byMGcxhYXLUuY39MobCuFzDp9bgFoyWiuwvojWh0=; b=AkepMuTt5QVA4isOxqr7u9CeXETGrGQ9Vu6pWt821e+T61KhQWDyz9ESMWwy/B0/8LQdO6ajjKklwUQPrjE07xmLAoewXcwvbrN1KJrbe4YYP8ziSEVV1KAnlD7YcopjURbMZuwlalmi7Ljqcx8vBtOcYbZ+wqfBHWp7CeUQeiDCpQEc5B8+SVFd4JUxIsnOgogE1yRK8y7G/EvgSLMQ8V/r+IRgC5MEsDiLd3roSRCFUw67eqsOJzgnY6hSkL66 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 21 Aug 2016 18:39:01 -0000 Date: 21 Aug 2016 14:39:01 -0400 Message-ID: From: "John R Levine" To: "Eric Rescorla" In-Reply-To: References: <20160821175145.26541.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: DISPATCH Subject: Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 18:39:05 -0000 >> Sure, if that were feasible. I see no chance at all of getting a >> sufficient agreement that domains are authorititative, or that they >> aren't. ... > This seems like a potential indicator that this technology is not yet ready > for standardization. Possibly, although since I talked in Berlin to people from one of the world's largest mail systems about implementing this, it seems we can try and figure out what we can standardize or we can stick our heads in the sand. RFC 7929 and the forthcoming similar doc for S/MIME suggest that there is interest in domain authenticated certs. But it may be that the interest is only in the DANE clique, in which case it would be easy enough to take out the domain authentication stuff and perhaps move it to a separate experimental draft. > As I said previously, I kind of suspect that 4387 just meant that the > certs were all alternative EEs, but then you probably want some other > way to get the intermediates for the reason listed above, but in any > case you shouldn't just have them all in the same bucket. So, what's > probably best is to concretize this by saying that this bucket is just > for EE and then define some other mechanism for getting intermediates. OK. As I said, I'm not a great pkix expert, so whatever matches what S/MIME actually does would be great. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From sris@google.com Mon Aug 22 05:30:40 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D3A12D185 for ; Mon, 22 Aug 2016 05:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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.548, 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 KjcxiqO2BMkK for ; Mon, 22 Aug 2016 05:30:38 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 3AAC312D0EB for ; Mon, 22 Aug 2016 05:30:38 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id r9so50393269ywg.0 for ; Mon, 22 Aug 2016 05:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=QBBpJ4nMIwH399BA8/7jRjShebRLuVIzTQlUzjaMiLs=; b=RkLKkP9sbUEbBPW3yCpkEoFtlQaXq+tCNBE+CRR067FibjRbDD9kI11H1b/5Ua3Lwl 18f4lWtsoq0ntBz5B3FWeVGDeEYqLW5DCXtec9hXxS5g35U2/BpSXjPwqug9AxCFpfK6 fmMCP2hdCNrEnJZJETqMyNXOLiSINpv0cc7+p1Dj8nmwbq8F4p4Uj7/7mZNYK6zx0Pmd wu0oxPJHYkbg9Xwnr7BZzn7Arib18lqppAz/COvkK6WUL0gbzLzhhXsa4CzOgjpssk2u 5btVs8FYWUCMCY4X0F8ngUk8be/GWVS0YI7lAEVnYkj8rw2i0tbQr/I+tT0bWrE8lm6s xzOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=QBBpJ4nMIwH399BA8/7jRjShebRLuVIzTQlUzjaMiLs=; b=O6AtToOZ+zjsGoOg+33IZn5uduglwfmdGfTPFFgF14OMLpbwZrRbNMAKLad2Jm8X1V 8hdQcyyT4VGbZquDlqwHk/D3p4G+ftEaPfXM6VANk28E84Myo29MUABhhR4/dun5oJcC SvJbZe7UfDet6yus3mx31ZzezUPkJk2Z36V2vqEP2ngNjQ9uEaTYB/sKb1KIU96Q7WPA hY9ZTa5Bf0mqe54+hVv0JOrvXub18QTVK0HUGEcfsa7kZEroRB1UT+gIhndQjDHPZmKV MqK7FtomUNbsWKZvxpzOOtyubkmMPSCI1HLCxgvt1rzXnrMWtiuo+7SEnxo2BOkaPwnc 5sGA== X-Gm-Message-State: AEkooutzcGwYUf+0pAOBfjyM88SlEjp36k2NEaWagYdxI90/nxgOKGKE9fLeDd5GPkNLGNFrv20DVqWEhnvLUans X-Received: by 10.13.238.197 with SMTP id x188mr17560468ywe.98.1471869037127; Mon, 22 Aug 2016 05:30:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.197.16 with HTTP; Mon, 22 Aug 2016 05:30:16 -0700 (PDT) From: Sri Somanchi Date: Mon, 22 Aug 2016 05:30:16 -0700 Message-ID: To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=94eb2c033fe01d978f053aa8377d Archived-At: X-Mailman-Approved-At: Mon, 22 Aug 2016 06:15:00 -0700 Subject: Re: [dispatch] Please dispatch draft-levine-herkula-oneclick-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 12:34:40 -0000 --94eb2c033fe01d978f053aa8377d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Everyone, This is Sri Harsha Somanchi, Product Manager - Gmail spam filter. List-Unsubscribes URIs that lack clear markers to indicate whether they are one-click or not, present a major issue to large mailbox providers (including Gmail) that provide assisted unsubscribes in the MUA. The solution proposed via https://tools.ietf.org/html/draft-levine-herkula-oneclick-03 solves this problem by proposing a standard method for senders to distinctly designate one-click unsubscribe URIs; while also providing receivers with guidance on how to follow such links in a way that senders can (reasonably) trust the unsubscribes to be genuine (ie. not caused by random follows that lack user consent). The approach taken by the above draft is acceptable to Gmail and we plan to implement the same over the next few months. Background: If a qualifying message contains the List-Unsubscribe header, Gmail will surface an option in the MUA to enable the user to take an unsubscribe action from within the client. While this system works well enough with the 'mailto:' type (where the receiver silently sends an unsubscription email to the sender in the background), it its more complicated for the URI type. In URI based List-Unsubscribes, it is not readily apparent to the receiver whether the link is one-click or not =E2=80=94 due to which the unsubscript= ion option cannot be surfaced as a one-click action*** to the end user in the MUA . Surfacing the URI as-is to the end user to click is less desirable, given the context switch from the MUA to the browser (and back). Thus Gmail has been actively pushing for standardization of one-click URIs in the List-Unsubscribe header, so that senders can explicitly designate such links, and receivers only use those URIs in assisted unsubscribes. *** whereby the receiver silently follows the URI in the background, to generate an unsubscribe request to the sender - on the user's behalf. Thanks. --94eb2c033fe01d978f053aa8377d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Everyone,

This is Sri Harsha Somanch= i, Product Manager - Gmail spam filter.

List-Unsub= scribes URIs that lack clear markers to indicate whether they are one-click= or not, present a major issue to large mailbox providers (including Gmail)= that provide assisted unsubscribes in the MUA.

Th= e solution proposed via https://tools.ietf.org/html/draft-levine-herkula-onec= lick-03 solves this problem by proposing a standard method for senders = to distinctly designate one-click unsubscribe URIs; while also providing re= ceivers with guidance on how to follow such links in a way that senders can= (reasonably) trust the unsubscribes to be genuine (ie. not caused by rando= m follows that lack user consent).

The approach ta= ken by the above draft is acceptable to Gmail and we plan to implement the = same over the next few months.

Background:

If a qualifying message contains the List-Unsubscribe hea= der, Gmail will surface an option in the MUA to enable the user to take an = unsubscribe action from within=C2=A0the client. While this system works wel= l=C2=A0enough with the 'mailto:' type (where the receiver silently = sends an unsubscription email to the sender in the background), it its more= complicated for the URI type.

In URI based List-U= nsubscribes, it is not readily apparent to the receiver whether the=C2=A0li= nk is one-click or not=C2=A0=E2=80=94=C2=A0due to which the unsubscription = option cannot be surfaced as a one-click action* to the end=C2=A0use= r in the MUA . Surfacing the URI as-is to the end user to click is less des= irable, given the context switch from the MUA to the browser (and back).

Thus Gmail has been actively pushing for standardization of one= -click URIs in the List-Unsubscribe header, so that senders can explicitly = designate such links, and receivers only use those URIs in assisted unsubsc= ribes.

* whereby the receiver silently foll= ows the URI in the background, to generate an unsubscribe request to the se= nder - on the user's behalf.

Thanks.
--94eb2c033fe01d978f053aa8377d-- From nobody Mon Aug 22 11:45:47 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8FE12B00F for ; Mon, 22 Aug 2016 11:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 BxYnj49Q-RNn for ; Mon, 22 Aug 2016 11:45:45 -0700 (PDT) Received: from smtp104.iad3a.emailsrvr.com (smtp104.iad3a.emailsrvr.com [173.203.187.104]) (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 8F93012B020 for ; Mon, 22 Aug 2016 11:45:45 -0700 (PDT) Received: from smtp30.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp30.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id F0EEFE054F; Mon, 22 Aug 2016 14:45:39 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp30.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 8FCB8E0579; Mon, 22 Aug 2016 14:45:38 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.7.1); Mon, 22 Aug 2016 14:45:39 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Mon, 22 Aug 2016 12:45:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <581F9FFC-4F0B-455C-925B-7A5B18F05BAC@iii.ca> References: <20160821175145.26541.qmail@ary.lan> To: John Levine X-Mailer: Apple Mail (2.3124) Archived-At: Cc: DISPATCH Subject: Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 18:45:46 -0000 > On Aug 21, 2016, at 12:13 PM, Eric Rescorla wrote: >=20 > People at gmail said they're interested > in this, so I can ask if they've thought about it in the context of > a very large public mail system. Can we get some of those people directly involved in the conversation = here. Obviously I'd be very keen on doing something that ended up = deployed at multiple major providers.=20 From nobody Mon Aug 22 18:06:27 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6AA12D0A6 for ; Mon, 22 Aug 2016 18:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 vFWquVicSex6 for ; Mon, 22 Aug 2016 18:06:24 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65CA912B015 for ; Mon, 22 Aug 2016 18:06:24 -0700 (PDT) Received: (qmail 3854 invoked from network); 23 Aug 2016 01:06:22 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 23 Aug 2016 01:06:22 -0000 Date: 23 Aug 2016 01:06:01 -0000 Message-ID: <20160823010601.30503.qmail@ary.lan> From: "John Levine" To: dispatch@ietf.org In-Reply-To: <581F9FFC-4F0B-455C-925B-7A5B18F05BAC@iii.ca> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: fluffy@iii.ca Subject: Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 01:06:26 -0000 >> People at gmail said they're interested in this, so I can ask if they've thought about it in the context of >> a very large public mail system. > >Can we get some of those people directly involved in the conversation here. Obviously I'd be very keen on >doing something that ended up deployed at multiple major providers. Good thought. I'll try and loop them in. R's, John From nobody Wed Aug 24 06:30:41 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F1D12DD20 for ; Wed, 24 Aug 2016 06:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=jtRd54pE; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=XV9rY1Bi 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 qblpFdvi6zgF for ; Wed, 24 Aug 2016 06:30:37 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45CCD12DD43 for ; Wed, 24 Aug 2016 06:23:54 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id AE48C20531; Wed, 24 Aug 2016 09:23:53 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Wed, 24 Aug 2016 09:23:53 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=QdyVxHVRlMmIaDzB7IoWAboJt6k=; b=jtRd54 pEqt48XXxXkV10skFh6qdlWk57sPZqx7FIvYWPXsvRF2zgqEtvMK8aXBVP6MnBzh A7UIcdxImQf73s7vVf0RVbZNjEofxh59tlrOw+rpn0GkLupXbxOX+Ndmlqm+SX5q Pm67P0sUVU3+WlrvyA0f8BZWbypOnlPdao3Dw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=QdyVxHVRlMmIaDz B7IoWAboJt6k=; b=XV9rY1BiLKnUdDyHz/8IeROFEmXR5dJcLyHXseXfG2lFvsg 2/2W16rtswQvAWSlcCHyeP9vutxvKUwJKoVGJ8awt8br0hsmS9JE7gh/qEqdigLH 01J1UKXtmk/XqlauYyYX7218LKoHVDnwEsTq0OwnAf7MkTNQV9stpMbg0YI4= Received: by mailuser.nyi.internal (Postfix, from userid 99) id 7B56596BFA; Wed, 24 Aug 2016 09:23:53 -0400 (EDT) Message-Id: <1472045033.2121648.704720145.73535591@webmail.messagingengine.com> X-Sasl-Enc: 9tLohG/nfaTBbBuq+DGxSGpx0T1GDOKoiHjULr5t26Kq 1472045033 From: Alexey Melnikov To: John R Levine MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-5ae55197 In-Reply-To: References: <20160803212343.59778.qmail@ary.lan> Date: Wed, 24 Aug 2016 14:23:53 +0100 Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Please dispatch draft-levine-herkula-oneclick-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 13:30:39 -0000 Hi John, On Wed, Aug 3, 2016, at 11:33 PM, John R Levine wrote: > > One thing that would be really good is for the folks that are going to > > implement it to please post comments on the list reflecting that it solves > > a problem that they need solved and they agree with the approach. > > I'll write and ask them to do so. > > > At this point, there's only been one set of comments on the mailing > > list and I don't see that the authors have responded to those: > > https://mailarchive.ietf.org/arch/msg/dispatch/7WW5t556-8KYWkhLJ_DmO6sbaz4 > > Click "View by Thread" and you'll see the back and forth. If you can find somebody to be a document shepherd (ideally not from Gmail), than I would AD-sponsor it.