From nobody Wed Oct 4 08:51:47 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA37124207 for ; Wed, 4 Oct 2017 08:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggps5w0Q-0gj for ; Wed, 4 Oct 2017 08:51:43 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 144D513430D for ; Wed, 4 Oct 2017 08:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1507132302; d=isode.com; s=june2016; i=@isode.com; bh=/nOncHeRb494VhuN6f7CWK530lTSAARIsYTH8o5NAK4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=RGoZbxELvHTB9Mt9IRZO/YdVDbjbqaFdp8kxovYqsAJtXtC505v8/tQuzkS5SH6XTx+ocn FPEhYaADqoh7jz9wdycsAAr9QvncVNhAxXsf9yPt9/alJ6LkxDiW7ZyVZH+3De50sS1qwz VNTUDf3mnRMgfeYwON+mcNY5w9xIpF4=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 4 Oct 2017 16:51:42 +0100 References: To: "art@ietf.org" Cc: "Ali C. Begen" From: Alexey Melnikov X-Forwarded-Message-Id: Message-ID: Date: Wed, 4 Oct 2017 16:50:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------D0AD2DE52B19735933DD57B6" Content-Language: en-US Archived-At: Subject: [art] Fwd: [media-types] Need guidance on overloading an existing mime type parameter vs. defining a new parameter X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 15:51:46 -0000 --------------D0AD2DE52B19735933DD57B6 Content-Type: multipart/alternative; boundary="------------D1FEECFE667EE6F57D5BB291" --------------D1FEECFE667EE6F57D5BB291 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi, Any comments on Ali's question? Thank you, Alexey -------- Forwarded Message -------- Subject: [media-types] Need guidance on overloading an existing mime=20 type parameter vs. defining a new parameter Date: Thu, 14 Sep 2017 12:25:05 +0300 From: Ali C. Begen To: ietf-types@iana.org CC: Joey Parrish , Christian Timmerer (ITEC)=20 , Alexey Melnikov=20 Hi there, Alexey M. suggested that I wrote my question to this list. I hope to get=20 some advice on something we are dealing with in MPEG. The core discussion is here: https://github.com/w3c/encrypted-media/issues/400=20 (At the bottom, there is the text we presented in the last mpeg meeting) I personally think overloading the codecs parameter to indicate every=20 media future (the encryption scheme in this specific discussion but the=20 main problem is broader) is not a good idea just for the sake of using=20 it as implicit signaling. Admittedly, defining a new parameter is not perfect, either but maybe we=20 can find a way to make it work nicely. What are your thoughts on this? Comments are welcome. Thanks. -acbegen m41135 (Joint contribution to July 2017 meeting by Comcast, Google and=20 AAU/Bitmovin) Title: MIME Type Parameters for Signaling Encryption and Other Media=20 Features 1) Introduction RFC 6381 specifies parameters that are used with various MIME types or=20 type/subtype combinations to allow for unambiguous specification of the=20 codecs employed by the media formats contained within, or the profile(s)=20 of the overall container format. However, the MIME type parameters do=20 not indicate the type of encryption. This could create a problem for the=20 receivers when the encapsulating environment is not capable of declaring=20 separately that the content is protected (such as in the MPD for DASH)=20 since in that case the receivers cannot infer whether they can decode=20 the media without first fetching and parsing the media tracks. ISO/IEC 14496-12 defect report (N16618) reported this issue, and the=20 revised defect report (N16785) proposed an annex that defined certain=20 rules on how to use MIME type parameters for ISOBMFF and derived=20 specifications. The proposed annex in N16785 specifies the following: If the 4CC of a sample entry indicates protected content (e.g., =E2=80=98enc= v=E2=80=99,=20 =E2=80=98enca=E2=80=99, =E2=80=98enct=E2=80=99 etc.), the =E2=80=98codecs=E2= =80=99 parameter value for that track is any=20 the following values, separated by =E2=80=9C.=E2=80=9D: * the 4CC indicating protected content (e.g., =E2=80=98encv=E2=80=99); * the scheme-type (e.g., =E2=80=98cenc=E2=80=99); * the original_format (e.g., =E2=80=98avc1=E2=80=99), followed by any sub-pa= rameters as=20 defined for that original format As a result, the following values would be possible for the =E2=80=98codecs= =E2=80=99=20 parameter: encv.cbcs.avc1.402567 or encv.cenc.avc1.402567 The motivation here is that when a receiver reads such a value, it can=20 determine whether it can decode the media (i.e., whether it supports the=20 encryption mode). If it does not understand the value, by definition it=20 will ignore the value and will not fetch the media to avoid waste of=20 (server, network or time) resources. While the motivation for this approach seems just, overloading the=20 =E2=80=98codecs=E2=80=99 parameter value has several drawbacks and may lead = us to more=20 problems in the future. 2) Proposal A cleaner and more future-proof approach is to put the additional values=20 out of the =E2=80=98codecs=E2=80=99 parameter. For example, to indicate the = encryption=20 mode for the following existing media video/mp4; codecs=3D=E2=80=9Davc1.640028=E2=80=9D we could rather say video/mp4; codecs=3D=E2=80=9Davc1.640028=E2=80=9D; encscheme=3D=E2=80=9Dcbcs= =E2=80=9D or video/mp4; codecs=3D=E2=80=9Davc1.640028=E2=80=9D; encscheme=3D=E2=80=9Dcenc= =E2=80=9D Indeed, the older receivers who do not understand the =E2=80=98encsheme=E2= =80=99=20 parameter will ignore it and may unnecessarily fetch the media (this is=20 a behavior by design). However, we need to worry more about the newer=20 clients who will understand this and other newly-defined parameters=20 since very likely the usage will be dominated by such newer clients. Note that on the respective Github discussion page [1], other issues=20 have also been listed for using the =E2=80=98codecs=E2=80=99 parameter to in= dicate the=20 encryption mode. They are: * The protection scheme is more related to the container than the codec.=20 So, it should not be signaled as a part of the =E2=80=98codecs=E2=80=99 para= meter. * Codec strings are currently container-independent, and the same string=20 can be used with multiple containers. However, the protection scheme is=20 not container-independent and this complicates the decoder APIs. * Codec strings are more likely to be passed around into deeper layers=20 of a system than container. Implementations would need to strip this=20 prefix before doing so. * Strings for some codecs are already quite long. While the above uses the encryption mode as the example, the same=20 approach equally applies to other media features. For example, a media=20 could be HDR or non-HDR, supports (or not) WCG, could be omnidirectional=20 video, etc. One should not signal these types of features in the=20 =E2=80=98codecs=E2=80=99 parameter. It is recommended that the MPEG community reaches an agreement on these=20 principles at this meeting and the work is coordinated between the IETF,=20 W3C and MPEG to implement the necessary changes as an update to RFC 6381. 3) References [1] https://github.com/w3c/encrypted-media/issues/400#issue --------------D1FEECFE667EE6F57D5BB291 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi,

Any comments on Ali's question?


Thank you,
Alexey

-------- Forwarded Message --------
Subjec= t: [media-types] Need guidance on overloading an existing mime type parameter vs. defining a new parameter
Date: = Thu, 14 Sep 2017 12:25:05 +0300
From: = Ali C. Begen <ali.begen@networked.media>
To: ietf-types@iana.org
CC: Joey Parrish <joeyparrish@google.com>, Christian Timmerer (ITEC) <christian.timmerer@itec.uni-klu.ac.at>= , Alexey Melnikov <aamelnikov@fastmail.fm>


Hi there,

Alexey M. suggested that I wrote my question to this list. I hope to get some advice on something we are dealing with in MPEG.

The core discussion is here:

(At the bottom, there is the text we presented in the last mpeg meeting)

I personally think overloading the codecs parameter to indicate every media future (the encryption scheme in this specific discussion but the main problem is broader) is not a good idea just for the sake of using it as implicit signaling.

Admittedly, defining a new parameter is not perfect, either but maybe we can find a way to make it work nicely.

W= hat are your thoughts on this?=C2=A0Comments are welcome.
Tha= nks.
-ac= begen
m411= 35 (Joint contribution to July 2017 meeting by Comcast, Google and AAU/Bitmovin)

Title: MIME Type Parameters for Signaling Encryption and Other Media Features

1) Introduction

RFC 6381 specifies parameters that are used with various MIME types or type/subtype combinations to allow for unambiguous specification of the codecs employed by the media formats contained within, or the profile(s) of the overall container format. However, the MIME type parameters do not indicate the type of encryption. This could create a problem for the receivers when the encapsulating environment is not capable of declaring separately that the content is protected (such as in the MPD for DASH) since in that case the receivers cannot infer whether they can decode the media without first fetching and parsing the media tracks.

ISO/IEC 14496-12 defect report (N16618) reported this issue, and the revised defect report (N16785) proposed an annex that defined certain rules on how to use MIME type parameters for ISOBMFF and derived specifications.

The proposed annex in N16785 specifies the following:
If the 4CC of a sample entry indicates protected content (e.g., =E2=80=98encv=E2=80=99, =E2=80=98enca=E2=80=99, =E2=80=98enct=E2=80= =99 etc.), the =E2=80=98codecs=E2=80=99 parameter value for that track is any the following values, separated by =E2=80=9C.=E2= =80=9D:
* the 4CC indicating protected content (e.g., =E2=80=98encv=E2=80=99= );
* the scheme-type (e.g., =E2=80=98cenc=E2=80=99);
* the original_format (e.g., =E2=80=98avc1=E2=80=99), followed by an= y sub-parameters as defined for that original format

As a result, the following values would be possible for the =E2=80=98codecs=E2=80=99 parameter:
encv.cbcs.avc1.402567
or
encv.cenc.avc1.402567

The motivation here is that when a receiver reads such a value, it can determine whether it can decode the media (i.e., whether it supports the encryption mode). If it does not understand the value, by definition it will ignore the value and will not fetch the media to avoid waste of (server, network or time) resources.

While the motivation for this approach seems just, overloading the =E2=80=98codecs=E2=80=99 parameter value has several drawbacks a= nd may lead us to more problems in the future.

2) Proposal

A cleaner and more future-proof approach is to put the additional values out of the =E2=80=98codecs=E2=80=99 parameter. For= example, to indicate the encryption mode for the following existing media
video/mp4; codecs=3D=E2=80=9Davc1.640028=E2=80=9D
we could rather say
video/mp4; codecs=3D=E2=80=9Davc1.640028=E2=80=9D; encscheme=3D=E2= =80=9Dcbcs=E2=80=9D
or
video/mp4; codecs=3D=E2=80=9Davc1.640028=E2=80=9D; encscheme=3D=E2= =80=9Dcenc=E2=80=9D

Indeed, the older receivers who do not understand the =E2=80=98encsh= eme=E2=80=99 parameter will ignore it and may unnecessarily fetch the media (this is a behavior by design). However, we need to worry more about the newer clients who will understand this and other newly-defined parameters since very likely the usage will be dominated by such newer clients.
Note that on the respective Github discussion page [1], other issues have also been listed for using the =E2=80=98codecs=E2=80=99 = parameter to indicate the encryption mode. They are:
* The protection scheme is more related to the container than the codec. So, it should not be signaled as a part of the =E2=80=98codecs=E2=80=99 parameter.
* Codec strings are currently container-independent, and the same string can be used with multiple containers. However, the protection scheme is not container-independent and this complicates the decoder APIs.
* Codec strings are more likely to be passed around into deeper layers of a system than container. Implementations would need to strip this prefix before doing so.
* Strings for some codecs are already quite long.
While the above uses the encryption mode as the example, the same approach equally applies to other media features. For example, a media could be HDR or non-HDR, supports (or not) WCG, could be omnidirectional video, etc. One should not signal these types of features in the =E2=80=98codecs=E2=80=99 parameter.

It is recommended that the MPEG community reaches an agreement on these principles at this meeting and the work is coordinated between the IETF, W3C and MPEG to implement the necessary changes as an update to RFC 6381.

3) References
[1] https://github.com/w3c/encrypted-media/is= sues/400#issue
--------------D1FEECFE667EE6F57D5BB291-- --------------D0AD2DE52B19735933DD57B6 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1lZGlh LXR5cGVzIG1haWxpbmcgbGlzdA0KbWVkaWEtdHlwZXNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWVkaWEtdHlwZXMNCg0K --------------D0AD2DE52B19735933DD57B6-- From nobody Wed Oct 4 11:01:13 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161D4132193 for ; Wed, 4 Oct 2017 11:01:11 -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, URIBL_BLOCKED=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 m04gD0M2NTqp for ; Wed, 4 Oct 2017 11:01:08 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 540F913430F for ; Wed, 4 Oct 2017 11:01:08 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1dznyk-0002y5-LN; Wed, 04 Oct 2017 14:01:06 -0400 Date: Wed, 04 Oct 2017 14:01:00 -0400 From: John C Klensin To: Alexey Melnikov , art@ietf.org cc: "Ali C. Begen" Message-ID: <1011E8AC59E57DCA8E405938@PSB> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [art] Fwd: [media-types] Need guidance on overloading an existing mime type parameter vs. defining a new parameter X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 18:01:11 -0000 Alexey and Ali, (Small warning -- the first part of this note may not be applicable to the current case but is, I think, important for background and to understand the conclusion in context. Also, this note is a personal opinion. While I had a role in defining the media type and associated registration mechanisms, I have not consulted my co-authors, I do not follow the ietf-types list, and a lot of what follows is not in the documents.) A media type and its parameters should be as precise as possible and applications should be able to rely on whatever those things tell them. I don't understand MPEG, much less this particular case, and haven't read RFC 6381 in the last half-dozen years if ever, but, if an early implementation of the file format looks at the media type and parameters, it should be able to figure out whether it can interpret the file and interpret it in the same way that a contemporary rendering implementation would. If that means looking at a parameter and saying "don't understand this, maybe you need an updated implementation", that is just fine and produces a clear error message, while putting out gibberish or failing midway through the file is less desirable. One way to look at the whole media type idea is that it is intended to prevent or eliminate the need for heuristics in determining what should be used to render or interpret a file and how it should do it. If retroactively interpreting a parameter (or even a primary type) puts implementations back in the business of trying to guess whether they can interpret the file or not, that is a violation of at least the spirit of the idea. What makes this a bit complicated is that there can be some non-heuristic cases. For example, if a file format contains a well-defined version number that is always in the same place regardless of versions and there are clear rules about what an implementa6ion is supposed to do when an unrecognized version is encountered, having a media type that is version independent and either no version parameter or a version parameter that is purely advisory (with the one in the file overriding) may be perfectly reasonable. Now, from what I understand from Ali's note, if the codecs parameter is precisely enough defined and implementations simply reject a file whose associated codec name they don't understand, then the odds are low that serious harm would be caused by overloading codec names to also include encryption type information. That makes it mostly a matter of taste. However, multiplying parameter values to incorporate essentially orthogonal types of information is rarely a good idea and, as Ali's note sort of points out, it gets worse, exponentially worse, with each new type of information that is added in. So my sense of good taste and instinct match Ali's and the proposal -- it is probably better to go through the pain of adding one or more parameters now than to overload "codecs". On the other hand, if I were told that most implementations just ignore parameters they don't understand even while they don't accept unknown parameter values for parameters they do recognize, I might well hold my nose, suggest that overloading the parameter is the least bad solution for the present, and that people should start looking carefully at updating RFC 6381 and current practice to be sure that the next logical extension to come along doesn't dig this hole even deeper. best, john --On Wednesday, October 4, 2017 16:50 +0100 Alexey Melnikov wrote: > Hi, > > Any comments on Ali's question? > > > Thank you, > Alexey > > -------- Forwarded Message -------- > Subject: [media-types] Need guidance on overloading an > existing mime type parameter vs. defining a new parameter > Date: Thu, 14 Sep 2017 12:25:05 +0300 > From: Ali C. Begen > To: ietf-types@iana.org > CC: Joey Parrish , Christian Timmerer > (ITEC) , Alexey > Melnikov > > > > Hi there, > > Alexey M. suggested that I wrote my question to this list. I > hope to get some advice on something we are dealing with in > MPEG. > > The core discussion is here: > https://github.com/w3c/encrypted-media/issues/400 > > > (At the bottom, there is the text we presented in the last > mpeg meeting) > > I personally think overloading the codecs parameter to > indicate every media future (the encryption scheme in this > specific discussion but the main problem is broader) is not a > good idea just for the sake of using it as implicit signaling. > > Admittedly, defining a new parameter is not perfect, either > but maybe we can find a way to make it work nicely. > > What are your thoughts on this? Comments are welcome. > > Thanks. > -acbegen > > > m41135 (Joint contribution to July 2017 meeting by Comcast, > Google and AAU/Bitmovin) > > Title: MIME Type Parameters for Signaling Encryption and Other > Media Features > > 1) Introduction > > RFC 6381 specifies parameters that are used with various MIME > types or type/subtype combinations to allow for unambiguous > specification of the codecs employed by the media formats > contained within, or the profile(s) of the overall container > format. However, the MIME type parameters do not indicate the > type of encryption. This could create a problem for the > receivers when the encapsulating environment is not capable of > declaring separately that the content is protected (such as in > the MPD for DASH) since in that case the receivers cannot > infer whether they can decode the media without first fetching > and parsing the media tracks. > > ISO/IEC 14496-12 defect report (N16618) reported this issue, > and the revised defect report (N16785) proposed an annex that > defined certain rules on how to use MIME type parameters for > ISOBMFF and derived specifications. > > The proposed annex in N16785 specifies the following: > If the 4CC of a sample entry indicates protected content > (e.g., 'encv', 'enca', 'enct' etc.), the > 'codecs' parameter value for that track is any the > following values, separated by ".": > * the 4CC indicating protected content (e.g., 'encv'); > * the scheme-type (e.g., 'cenc'); > * the original_format (e.g., 'avc1'), followed by any > sub-parameters as defined for that original format > > As a result, the following values would be possible for the > 'codecs' parameter: > encv.cbcs.avc1.402567 > or > encv.cenc.avc1.402567 > > The motivation here is that when a receiver reads such a > value, it can determine whether it can decode the media (i.e., > whether it supports the encryption mode). If it does not > understand the value, by definition it will ignore the value > and will not fetch the media to avoid waste of (server, > network or time) resources. > > While the motivation for this approach seems just, overloading > the 'codecs' parameter value has several drawbacks and may > lead us to more problems in the future. > > 2) Proposal > > A cleaner and more future-proof approach is to put the > additional values out of the 'codecs' parameter. For > example, to indicate the encryption mode for the following > existing media > video/mp4; codecs="avc1.640028" > we could rather say > video/mp4; codecs="avc1.640028"; encscheme="cbcs" > or > video/mp4; codecs="avc1.640028"; encscheme="cenc" > > Indeed, the older receivers who do not understand the > 'encsheme' parameter will ignore it and may unnecessarily > fetch the media (this is a behavior by design). However, we > need to worry more about the newer clients who will understand > this and other newly-defined parameters since very likely the > usage will be dominated by such newer clients. > Note that on the respective Github discussion page [1], other > issues have also been listed for using the 'codecs' > parameter to indicate the encryption mode. They are: > * The protection scheme is more related to the container than > the codec. So, it should not be signaled as a part of the > 'codecs' parameter. > * Codec strings are currently container-independent, and the > same string can be used with multiple containers. However, the > protection scheme is not container-independent and this > complicates the decoder APIs. > * Codec strings are more likely to be passed around into > deeper layers of a system than container. Implementations > would need to strip this prefix before doing so. > * Strings for some codecs are already quite long. > While the above uses the encryption mode as the example, the > same approach equally applies to other media features. For > example, a media could be HDR or non-HDR, supports (or not) > WCG, could be omnidirectional video, etc. One should not > signal these types of features in the 'codecs' parameter. > > It is recommended that the MPEG community reaches an agreement > on these principles at this meeting and the work is > coordinated between the IETF, W3C and MPEG to implement the > necessary changes as an update to RFC 6381. > > 3) References > [1] https://github.com/w3c/encrypted-media/issues/400#issue From nobody Wed Oct 4 18:49:15 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7AA13450B for ; Wed, 4 Oct 2017 18:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 QtGplnw-maNp for ; Wed, 4 Oct 2017 18:49:14 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 EF4351344ED for ; Wed, 4 Oct 2017 18:49:13 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-08v.sys.comcast.net with ESMTP id zvHJdVEDCtsN5zvHldesyQ; Thu, 05 Oct 2017 01:49:13 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-17v.sys.comcast.net with SMTP id zvHjdhsvVsLILzvHkdjivF; Thu, 05 Oct 2017 01:49:12 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v951nBaf022451; Wed, 4 Oct 2017 21:49:11 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v951nAHo022448; Wed, 4 Oct 2017 21:49:10 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Alexey Melnikov Cc: art@ietf.org, ali.begen@networked.media In-Reply-To: (alexey.melnikov@isode.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 04 Oct 2017 21:49:10 -0400 Message-ID: <87bmlm74a1.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfKP2I7RekIpU0vp6g+NJZh7vXZ6wCZytPcMAPp+VKdbcP1koQxv7T4xu/aV36Ay+yY7fJQueV3QyzYJRWoWQapubxgLpFswleJVdlw0GGVAvPoQLrOdV Fo4OA/oIqP3U29lEHbkZ04KxCmfrfl5ikMI37gCwnMX9cjx0UFz4A7+zjBq3LclqXKWrBznRzkOGEHLtktpIIjo8M7hc3GDXnoHzE/kTm6qM5wyCsIVCKO9C Archived-At: Subject: Re: [art] Fwd: [media-types] Need guidance on overloading an existing mime type parameter vs. defining a new parameter X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 01:49:15 -0000 > From: Ali C. Begen > ISO/IEC 14496-12 defect report (N16618) reported this issue, and the > revised defect report (N16785) proposed an annex that defined certain > rules on how to use MIME type parameters for ISOBMFF and derived > specifications. > > The proposed annex in N16785 specifies the following: > If the 4CC of a sample entry indicates protected content (e.g., 'encv', > 'enca', 'enct' etc.), the 'codecs' parameter value for that track is any > the following values, separated by ".": > * the 4CC indicating protected content (e.g., 'encv'); > * the scheme-type (e.g., 'cenc'); > * the original_format (e.g., 'avc1'), followed by any sub-parameters as > defined for that original format > > As a result, the following values would be possible for the 'codecs' > parameter: > encv.cbcs.avc1.402567 > or > encv.cenc.avc1.402567 I favor John's observation: However, multiplying parameter values to incorporate essentially orthogonal types of information is rarely a good idea and, as Ali's note sort of points out, it gets worse, exponentially worse, with each new type of information that is added in. So my sense of good taste and instinct match Ali's and the proposal -- it is probably better to go through the pain of adding one or more parameters now than to overload "codecs". It seems to me that there are interacting factors of upward-compatibility and priority: I assume that the higher-priority goal is to achieve communication when possible, and it is a lower-priority goal to prevent the resource-wasting situation of setting up a media stream, only to discover once media is flowing that the the receiver can't decode the media stream. Adopting the N16785 proposal assumes that (1) New receivers will be rolled out fairly quickly that can interpret the composite codec values, and (2) Senders will know this and start generating the composite codec values. Because in order to avoid unnecessary media failures, senders will not generate composite codec values until all receivers in the ecosystem they are deployed in upgraded. And as long as senders don't generate composite codec values, none of the benefits of this proposal can be realized. So benefits can only be obtained at the end of the roll-out of updated senders and receivers. OTOH, once the IETF defines "encscheme" (or any other new parameter), senders can start using it, because sending it does not cause unnecessary failures. And receivers can implement it without causing upward-compatibility problems, as non-updated senders won't send that parameter. The benefits of avoiding useless media set-ups grow as approximately the product of the adoption level among senders and the adoption level among receivers. Unnecessary media failures are avoided completely. Deployment can proceed among senders and receivers at whatever pace is convenient. Dale From nobody Sun Oct 8 22:08:32 2017 Return-Path: X-Original-To: art@ietf.org Delivered-To: art@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 355DE132F8F; Sun, 8 Oct 2017 22:08:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Thomson To: Cc: mile@ietf.org, ietf@ietf.org, draft-ietf-mile-rolie.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150752570618.18384.5615358468704377459@ietfa.amsl.com> Date: Sun, 08 Oct 2017 22:08:26 -0700 Archived-At: Subject: [art] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 05:08:26 -0000 Reviewer: Martin Thomson Review result: Almost Ready I have reviewed this document, and - despite what appears to be a lengthy list of issues - I think that it is in pretty good shape. It's clear, readable, and addresses the requirements well. Most of my comments should be trivial to resolve. Major: The decision to define a .well-known URI without a discovery story is - in my opinion - inadvisable. Such a registration is usually appropriate if you design a protocol that depends on discovery by hostname and port. As such, this does not use that at all. A configuration system can (and should) accept a complete URI for the service endpoint. It would be better to defer creation of yet another .well-known URI registration until the working group is certain that discovery requires it. The same comment applies to the .well-known resource for the category document. Given that this sort of document is readily discoverable via the service document, I would say that the need for a .well-known resource is less well-justified than the service document. The requirements in Section 5.3 on TLS use are unnecessarily strict. It's great to recommend the use of TLS 1.2, but given that the document has no real requirement on any particular version of TLS, the use of "MUST" here is not needed. Similarly, the prohibition on the use of 0-RTT is groundless. The lengthy list of requirements around certificate validation only risk creating a conflict with advice in other RFCs. Many, if not all, of these requirements are transitively included by way of referencing HTTPS documents. I would prefer to see this entire section reduced to a simple RFC 7525 reference. User authentication is under-specified. * Section 5.3 mandates the use of TLS cipher suites that support client authentication using certificates, but offers no further advice. Aside from being an unnecessary requirement - cipher suites that support certificate-based authentication of servers all allow for client authentication - this sort of requirement is rarely sufficient for interoperation. For instance, you need to specify how a server will request a certificate such that clients can select the correct certificate. If a client and server have agreed to share information on terms that rely on authentication of clients, it is better for those peers to arrange the terms on which they will authenticate. * Section 5.4 uses "SHOULD" regarding client authentication using federation, but offers no hints about what this entails. It also uses "SHOULD" regarding authorization checks, which isn't an interoperability requirement. It's more of a "don't be silly" type of requirement, which doesn't need to be written down in an RFC. Section 5.5 prohibits the use of GET on "/". This prohibits use of the resource for other purposes. It seems reasonable to accept POST messages as defined in RFC 6546, but this requirement is overly strict (and further entrenches the violation of RFC 7320). If, for instance, the server operator wishes to provide HTML in response to a GET request to "/", this would prohibit that. The requirement to return 404 if RFC 6546 is not supported is worse; not supporting RFC 6546 might be a choice that a deployment makes to avoid the need to reserve "/" for that protocol. In Section 6.2.3, what is the advantage of "rolie:format" over having a well-defined media type? Media types can take advantage of content negotiation, existing support in link relations, and other existing tools. This rolie:format element has namespace, format, and schema; these are not useful to anyone that is ignorant of their contents. The only advantage I see is that syntax might be validated, but semantics can't be extracted. There's a lot of implied work in adding this element, but that doesn't seem to be justified by that advantage. (I see that RFC 7970 doesn't define a media type, but it seems like it would be easier to correct that than to define an element like this.) Section 6.2.4 defines a generic key-value mechanism. But that is something that XML is actually good at. Why can't users that require additional metadata use additional metadata as originally defined by Atom? That is, replace with something like 12345. The final paragraph of the section recognizes this possibility. Minor: Section 5.1.1 recommends the use of workspaces to separate "private" and "public" information. But workspaces don't really contain enough information to signal their status to a consumer of the information. I would suggest mentioning this, removing the recommendation, or expanding on the manner in which the status of information is signaled. Section 6.1.1 says "zero or more atom:category elements", but this contradicts the text and amendment to the schema in Section 6.1. Section 6.1.3 requires updating the "atom:updated" element when the representation changes. I don't think that this is what was intended. I think that the element needs to be updated when the contents of the feed change in any way. Question: it's fairly widely accepted that use of IRIs in Atom has been less than successful. Do you want to mandate use of URIs instead? This would apply to both link relations and the "src" attribute. In Section 7.1, the definition of the namespace prefix "urn:ietf:params:rolie:category:local" seems unnecessary. Namespace URIs are cheap and it seems reasonable to experiment with feeds that produce non-ROLIE information by omitting the "urn:ietf:params:rolie:category:information-type" category, even if that feed might comply with the requirements of ROLIE. The other way to experiment would be to use the category, but define a way to identify "term" attributes that are for use in private or experimental contexts. In Section 7.4, how is "...:rolie:property:content-author-name" superior to "atom:author"? In Section 8.4, is there a uniqueness requirement on "name"? I understand this to be the thing that being registered. Assuming that, what purpose does the "index" serve? This statement from Section 9, "As described in the discovery section, DNS SRV Records are a possible secure solution to discovery." is false without further qualification. SRV with DNSSEC might be secure, but a lot depends on the input to the discovery process and its provenance. In Section 10, the following statement is false (all of the described privacy violations are available to a client or server, not third parties): "Proper usage of TLS as described in Section 5.3 will in many cases aid in the mitigation of these issues." I think that you can strike this statement (most of the reason for use of TLS is justified by the security considerations anyway). Nits: Is it "Feed" or "feed"? RFC 4287 uses the latter, but this document seems to prefer the Proper Noun form. Section 6.2 should say what changed in the schema. It's hard to eyeball the schema to discover that "atomContent" is no longer optional. The two new elements are easy to spot and might cause the first change to be missed. Section 6.2.1 is the same. It should explicitly say that it only permits the atomOutOfLineContent formulation. I found the formulation of Section 7.1.1 confusing. It includes a list that seems to be authoritative, then disclaims any attempt to register these terms. Maybe this is because the statement "This document does not specify any information types." appears too late. Some reordering might help. The formatting of the table in Section 8.3 makes most of the columns unreadable. I would recommend a simple nested list. In section 9, the use of the term "well-known" to refer to information that is either public or widely available risks misinterpretation. FWIW, I would reword this entire paragraph to say simply "Access control to information published using ROLIE should use mechanisms that are appropriate to the sensitivity of the information. Primitive authentication mechanisms like HTTP Basic Authentication [RFC7617] are rarely appropriate for sensitive information." I didn't find the remainder of the text on authentication especially helpful. The text seems to equivocate on the subject of federation, where it would be easier to say nothing. Also in Section 9, the use of the term "message" is used in the context of using additional security controls. I think that the word "representation" is what was intended here. From nobody Mon Oct 9 09:19:08 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851B713456C; Mon, 9 Oct 2017 09:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.822 X-Spam-Level: X-Spam-Status: No, score=-0.822 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=T9ujnNDV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FsX3WZab 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 Zj2A5lEeIgcQ; Mon, 9 Oct 2017 09:18:53 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2495F13465C; Mon, 9 Oct 2017 09:18:53 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7D89F20DA6; Mon, 9 Oct 2017 12:18:52 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 09 Oct 2017 12:18:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=vvkwI/mlKI0khE1aoV dvA4ZiKqv0KOSg1GnG+t8bgG8=; b=T9ujnNDVTtkI8DpV5M/anSy9UeEs55LV4Y w4EKKU2fvcS1QWfI4xORR47cIcGZil8C9QlzeRie4ZY9OEUrJk9oubPYzQZm7x2X EUWA39piYhW4NEDh6QcUF5RQSqQv0BoWTnHm2SOmSOGcLouXh6wqJtrQyK2tkJU+ qmkNPMUfv53xM4/cz0SL+70z0Yiikjo4sZQSUMM4Un9bHooa+IGa+RB8qO2xz2fh HLOfYlExNmmv5z+4hB8ozncwEayITP3kNMEAbl1YT95MwLsyY7wlFQJO3Ehopna+ iP1zzLZOTZuDdI/hTGF8uTOKeRoG1KRd6UwapGBAGPrZWsaLBRlQ== DKIM-Signature: v=1; a=rsa-sha256; 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-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=vvkwI/mlKI0khE1aoVdvA4ZiKqv0KOSg1GnG+t8bgG8=; b=FsX3WZab gDycx7T2Ho5pp3CHSheGpJpVgdKXKlAkKNrnFTZJtRxhGP4N2ebEQrZFm8G265oQ cXEq2u21pqtm/y5+SzYpLqSBT1Zve5lsoIA5BCR9ym68iCltcrFINWIRr6wBo3gp xet/RoV8CFpk+hVygHzlH1ErnKdrL4ttIvYYHPXd+pISBun1WZa3x6oxr0xbqTAx vfvgkc4O2j83WP2PK+cS5r8y+O3lQEP0eopWL50vPO1ncicpGxF8gnv15/8GuuAd iM4A7K/bdeQXEOdQdH7/qS+gVLzP9mfXEFh+3OZxiQBH9SyrNupPYzKHTT8F9LcF kPj3iaNkG565kw== X-ME-Sender: X-Sasl-enc: UJ1nunGy0ofHQVWk9eKtshY7NegoDsltz1SLET1BMZuS 1507565932 Received: from [10.100.20.97] (unknown [8.18.217.202]) by mail.messagingengine.com (Postfix) with ESMTPA id CB16D2413F; Mon, 9 Oct 2017 12:18:51 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) From: Mark Nottingham In-Reply-To: <150752570618.18384.5615358468704377459@ietfa.amsl.com> Date: Mon, 9 Oct 2017 09:18:50 -0700 Cc: art@ietf.org, mile@ietf.org, ietf@ietf.org, draft-ietf-mile-rolie.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> To: Martin Thomson X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 16:18:55 -0000 On 8 Oct 2017, at 10:08 pm, Martin Thomson = wrote: >=20 > The decision to define a .well-known URI without a discovery story is = - in my > opinion - inadvisable. Such a registration is usually appropriate if = you > design a protocol that depends on discovery by hostname and port. As = such, > this does not use that at all. A configuration system can (and = should) accept > a complete URI for the service endpoint. It would be better to defer = creation > of yet another .well-known URI registration until the working group is = certain > that discovery requires it. I'll second this.=20 Generally, you only want to register a .well-known when there's a good = story for why using a URL isn't possible. Typically, this is when you = genuinely need to convey policy or metadata applicable to the whole = origin.=20 =46rom 5785: """ well-known URIs are not intended for general information retrieval or = establishment of large URI namespaces on the Web. Rather, they are = designed to facilitate discovery of information on a site when it isn't = practical to use other mechanisms; for example, when discovering policy = that needs to be evaluated before a resource is accessed, or when using = multiple round-trips is judged detrimental to performance. As such, the well-known URI space was created with the expectation that = it will be used to make site-wide policy information and other metadata = available directly (if sufficiently concise), or provide references to = other URIs that provide such metadata. """ Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon Oct 9 16:57:33 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250E31270AB; Mon, 9 Oct 2017 16:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 uTrp0yXobhIK; Mon, 9 Oct 2017 16:57:24 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 9CF06120720; Mon, 9 Oct 2017 16:57:23 -0700 (PDT) X-AuditID: 1209190e-823ff7000000797d-18-59dc0ce29c97 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id E8.4E.31101.2EC0CD95; Mon, 9 Oct 2017 19:57:22 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v99NvLDx011267; Mon, 9 Oct 2017 19:57:21 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v99NvHCE015911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Oct 2017 19:57:19 -0400 Date: Mon, 9 Oct 2017 18:57:17 -0500 From: Benjamin Kaduk To: Martin Thomson Cc: art@ietf.org, mile@ietf.org, ietf@ietf.org, draft-ietf-mile-rolie.all@ietf.org Message-ID: <20171009235717.GN96685@kduck.kaduk.org> References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <150752570618.18384.5615358468704377459@ietfa.amsl.com> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixCmqrPuI506kwa7jKhYr7npY/L/zl93i 2cb5LBbXzvxjtNjzv4/JgdVj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4s/Aic8EBzoo9 878wNjCeY+9i5OSQEDCR+H/sIROILSSwmEli++rYLkYuIHsDo8TlDdcZIZwrTBIPF11jBqli EVCR2LrkJ1g3G5Dd0H0ZLC4ioCux6OwDsDizQLTEwp6JbCC2sICDxPYfTWA1vEDbjs04wNrF yAE01Fni/GFpiLCgxMmZT1ggWrUkbvx7yQRSwiwgLbH8HwdImFPAReL4zjZGEFtUQFli3r5V bBMYBWYh6Z6FpHsWQvcCRuZVjLIpuVW6uYmZOcWpybrFyYl5ealFusZ6uZkleqkppZsYweEr ybeDcVKD9yFGAQ5GJR7eBZNvRwqxJpYVV+YeYpTkYFIS5b3CfSdSiC8pP6UyI7E4I76oNCe1 +BCjBAezkgiv832gct6UxMqq1KJ8mJQ0B4uSOO+2oF2RQgLpiSWp2ampBalFMFkZDg4lCd7X IEMFi1LTUyvSMnNKENJMHJwgw3mAhm8BqeEtLkjMLc5Mh8ifYlSUEuc1AEkIgCQySvPgekHp RSJ7f80rRnGgV4R5+0GqeICpCa77FdBgJqDBjMU3QAaXJCKkpBoYt9+O+t2x0CnDzkaTb5fE yg0TVixieXXT/znLz/pSx9L0N5e3vbrywmDGOi7j41EMmrKbbHie1iaEvIud/iHixvwZWqyG axddeXSV+dSZr1/2iLkVtu3yX+oibKeQHnZ6bUHgrLt5Btk3c9Q+1c6bcFmP6V5ahhPXxrme 61nO7JD9Gj9h9uvHi5VYijMSDbWYi4oTARfoVwgKAwAA Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 23:57:25 -0000 On Sun, Oct 08, 2017 at 10:08:26PM -0700, Martin Thomson wrote: > > The requirements in Section 5.3 on TLS use are unnecessarily strict. It's > great to recommend the use of TLS 1.2, but given that the document has no real > requirement on any particular version of TLS, the use of "MUST" here is not I think that one could make the case that using TLS 1.2 (or higher) greatly facilitates having a secure system, and so it could plausibly be required by a consuming protocol. > needed. Similarly, the prohibition on the use of 0-RTT is groundless. The I am a little surprised to hear you say that this prohibition is "groundless". Given that we require consumers of TLS 1.3 0-RTT data to explictly specify an application profile for how it may be used, with the intent to induce a careful analysis of the security considerations for sending early data messages, it seems quite reasonable to me that a protocol author might wish to defer such a painstaking analysis and take the easy choice of prohibiting early data. -Ben > lengthy list of requirements around certificate validation only risk creating a > conflict with advice in other RFCs. Many, if not all, of these requirements From nobody Mon Oct 9 18:11:28 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A53134323; Mon, 9 Oct 2017 18:11:27 -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 AhlsbGx76X-2; Mon, 9 Oct 2017 18:11:26 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 10F5413239C; Mon, 9 Oct 2017 18:11:26 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id v132so23292267oie.1; Mon, 09 Oct 2017 18:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q4Eq1jDPoG6fhlfjvLM+/r13zvpZimaEHBa7Od1rm4M=; b=GctBaEpSmbLOh5jg1J6I6d3FHZg31S7XkkFW1DlFDHVVi0Jnp0ZEXr2c5fzPcOZMGe +J9FZeAX1ZhPbvrgJvd+OwfOcaO19L6WfHZ2lLyT/g7J9iAlC5AmSOfO2mKC3DHLGmxr /VVmhYSnhY2HPfa7VY4KWwqJNGqVGZR7vUfoubq9XsjTBnEwiW+G6VEA6d2v4Z4Ywhwa xn/AS5rv8KesVYYjG/q6bJDYbKH/5ENp7JRagUfUhK+wwXPbzmKl9cxyIoeym55BLaNC H8461G5kXMiYXaEtTtpHWiIswETXwevLJNjiHjFRmvJ20E9V9kq7NQQTGbTYOs98evK5 uvwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q4Eq1jDPoG6fhlfjvLM+/r13zvpZimaEHBa7Od1rm4M=; b=CM6p9/w24NiWAjmmtTOrYVBX7/EyOmAaCh4++W/ww5nD5kBe/NptYaikAk+w7SHBWZ QXg9XPbc43HUDLrH0bLXLrgowjJc50M0wPbOgj3GA3V9M9WVCOUv2hkQEqjcFs5CC7DF NFSNd3dweBB1XSzWUHqTuYi0YeZA6GUnR/9Pdfmq4c1lHWEj9neSf/GQQMdGDTEnm7d/ qj2eDmuIqcrbjbVtwDrIGxpcHKO6AU5mRhp8qlXMwCIi4ASpTOBPJWbl++hmpCRTNX9H qtn0xuFoLKAG3HwHnIz20uOZJmftI36cmgsFEeJA9Io0bqsak90Ac7TRHyRN2Zs/dY8A /BWQ== X-Gm-Message-State: AMCzsaWV5HcpFbCM7UBc6ngIPJy55QgOionHrv2Zy+7wDgBEsP4k5TH0 iLbuW3OSzDJgCZ6+juH90o4dHaTPXmbw9iM7PkA= X-Google-Smtp-Source: AOwi7QA3JHBN/5yc/M5T5LK5P11PXSxKTlJn3bbXmM/zlmRhTUEzSu7jCRFEZA1Ix6Y/GUHaZTXTVSaF+qRsWbJwxlI= X-Received: by 10.202.166.141 with SMTP id t13mr6412585oij.392.1507597885358; Mon, 09 Oct 2017 18:11:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Mon, 9 Oct 2017 18:11:24 -0700 (PDT) In-Reply-To: <20171009235717.GN96685@kduck.kaduk.org> References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> From: Martin Thomson Date: Tue, 10 Oct 2017 12:11:24 +1100 Message-ID: To: Benjamin Kaduk Cc: ART Area , mile@ietf.org, "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 01:11:27 -0000 On Tue, Oct 10, 2017 at 10:57 AM, Benjamin Kaduk wrote: > I think that one could make the case that using TLS 1.2 (or higher) greatly > facilitates having a secure system, and so it could plausibly be required > by a consuming protocol. The problem here is that the protocol is actually HTTP. And that protocol has requirements already. A recommendation to use TLS 1.2 is fine, but that is already part of RFC 7525. >> needed. Similarly, the prohibition on the use of 0-RTT is groundless. The > > I am a little surprised to hear you say that this prohibition is "groundless". > Given that we require consumers of TLS 1.3 0-RTT data to explictly specify > an application profile for how it may be used, with the intent to induce > a careful analysis of the security considerations for sending early data > messages, it seems quite reasonable to me that a protocol author might > wish to defer such a painstaking analysis and take the easy choice of > prohibiting early data. This is quite explicitly using HTTP, which has a profile (work in progress). If that profile is somehow inadequate, then a case should be made in the draft explaining why (hence the choice of the word). A reference to TLS 1.3 also has the unfortunate effect of delaying publication of this draft. From nobody Mon Oct 9 18:23:43 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293DD134460; Mon, 9 Oct 2017 18:23:36 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 vg-Uxlv5Apr8; Mon, 9 Oct 2017 18:23:34 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 D25BC1342E6; Mon, 9 Oct 2017 18:23:34 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id x7so5236424pfa.1; Mon, 09 Oct 2017 18:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+cwGECz2Zewz7vzKsz0xC0QZoBKScFC71kLn7OYbhl4=; b=ZkafJ6AXRlHlWmiJ5FE3SFH6pXyV84GlRNnhnr3HNdbpuITRdipzIXTYDnMbvIbWRZ NeZ/gkSGLNuVyCZEqMey8uLxABgLWMgIHZDrL3M7hVOYHw/abjGSBPEk6Uu7qKP4x6zk gHPmFIYqxne6c7NOm0g52z6hJs/c/uIOQ/QxMKDbCv9IkoraE6+/bxvvu+3HJn9xocNJ pIlLBIfQU5GFGKdOKB+gdzWtkRmPsRSuJUTUL3XInAvyzQ8VM2BWjWGYr/rxEuE/n+h5 Pdah/F5SWbuw9rx0sAACG7oXsebLD/2yIXcosPQ2TQPeZ3Ts6sWZAY3pVaV1MQBEGyCp ZUEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+cwGECz2Zewz7vzKsz0xC0QZoBKScFC71kLn7OYbhl4=; b=K1R/eZgQMxhq8jWCYcATV7bxVl7Y0GRtmdJq3RNG/mhltSKwEK8QeTr4rnP2Cap2HT mYAZp5V8YGtLr1my3O28XqsfOQ2BzbneHoIdfSbX3G3Ue2sfgt8ozOOVgxZPxeOki14Q jmSJ7AdmvmZ7W9E5s0o/Id/+jfm6KlBMsZPNmutjbzrEhDuNhYSMFR2Oz8WnERweRUuL kWE+nEwJhpokEfZkDxY5NCx6HnDn6srU+WC6ADY86P6F7PfCi6CY588up2tOZ7TAsPpG e58X8kmzh8F4zxIJCDrMKTnjtn968jhwwHnLO9WUoOSnCgL7pLG9AAuUauPMJyR/mqCU sr+g== X-Gm-Message-State: AMCzsaVGCVzzgrA+R8JQzExFoMOchOFuY0N5B11EHoD/8g80LbDyL+sR /AwbwEQMwzjZUYgOpf+QFlNB6na+YfE2h8mOLwc= X-Google-Smtp-Source: AOwi7QC7LFUH+TeEYcHhSL69MpNxhqjwhZfgro+msbntCYP4OqbKNKoFsWI/Y6w/YVt/esTiMqL3zuiTXPzt4KCAjy0= X-Received: by 10.159.244.23 with SMTP id x23mr4494575plr.64.1507598614371; Mon, 09 Oct 2017 18:23:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.151.131 with HTTP; Mon, 9 Oct 2017 18:22:53 -0700 (PDT) In-Reply-To: <20171009235717.GN96685@kduck.kaduk.org> References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> From: Kathleen Moriarty Date: Mon, 9 Oct 2017 21:22:53 -0400 Message-ID: To: Benjamin Kaduk Cc: Martin Thomson , "gen-art@ietf.org" , MILE IETF , IETF , draft-ietf-mile-rolie.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 01:23:36 -0000 On Mon, Oct 9, 2017 at 7:57 PM, Benjamin Kaduk wrote: > On Sun, Oct 08, 2017 at 10:08:26PM -0700, Martin Thomson wrote: >> >> The requirements in Section 5.3 on TLS use are unnecessarily strict. It's >> great to recommend the use of TLS 1.2, but given that the document has no real >> requirement on any particular version of TLS, the use of "MUST" here is not > > I think that one could make the case that using TLS 1.2 (or higher) greatly > facilitates having a secure system, and so it could plausibly be required > by a consuming protocol. +1 and this has pretty much been standard practice on all protocols using TLS for at least the last 3 years. RFC7525 has been a requirement on most protocols using TLS since it was published. This is a protocol that will carry sensitive data and strict requirements are necessary. Examples of data that might be exchanged with this protocol include threat actor information or indicators of compromise. Strict security is necessary and completely expected by those deploying this protocol. > >> needed. Similarly, the prohibition on the use of 0-RTT is groundless. The > > I am a little surprised to hear you say that this prohibition is "groundless". > Given that we require consumers of TLS 1.3 0-RTT data to explictly specify > an application profile for how it may be used, with the intent to induce > a careful analysis of the security considerations for sending early data > messages, it seems quite reasonable to me that a protocol author might > wish to defer such a painstaking analysis and take the easy choice of > prohibiting early data. +1. In the case of this protocol, there is no tolerance for replay attacks. Many other protocols use TLS and will have similar requirements. This is likely to be a theme. The performance gain isn't worth the tradeoffs - of defining a profile, risking configuration mistakes, the careful analysis, and weighing the security considerations. The 0-RTT decision in the TLS WG has a big impact on other protocols using it. Kathleen > > -Ben > >> lengthy list of requirements around certificate validation only risk creating a >> conflict with advice in other RFCs. Many, if not all, of these requirements -- Best regards, Kathleen From nobody Mon Oct 9 18:33:13 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73656133073; Mon, 9 Oct 2017 18:33:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 L5ixnntTmmMS; Mon, 9 Oct 2017 18:33:04 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 3F8241320D8; Mon, 9 Oct 2017 18:33:04 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id n73so8876833pfg.10; Mon, 09 Oct 2017 18:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lxPaFcwotAe8FJLtX+D/Z0yQd0C4i4xGtiNOF+8VQ0E=; b=WSMEn23r9MoeeCWwMYfVW9yyyvXPLmOnCMzyVcQ9ru9bLgFSnUowq40Yh4vqOb4lbK k3jK6I+OS/MDWOt/ZvgaQOcR7LSD1FjBGu+Bru23Pv2z5GZg4FOQwVN3Eepb+5UjsuQz lE+EnfH/UU/mjK4HdRIlUABq5eQtNAbOwKvZri9CZFTDPnSUQd7pOnU0SK1Y8uH3xcch YN/ap6E12oN5zRaARMZwXayT76z13vi/hHwXT99IjfBwXajTh4WYnR7qzhzrQ3s3UXH1 tqstp1U1aVxT4oCXJgdt036LDmOExmTBezy6OQS4IWlP2r1lvn4zlRCTveiFUyTAcnbQ TDgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lxPaFcwotAe8FJLtX+D/Z0yQd0C4i4xGtiNOF+8VQ0E=; b=WWDT3vjDZlJipUgdm7HElDu5Wrgo/SFt+fGv3WbsyRGWKAvGKxIc+ClzSFrZ6sipHN nSYRZlSon+MhH/OI2k8olikB2Awem9FQ7cXy/8Rt9dAG5/3T5Tv9fuMPejiAKzoVCVE8 tTetXfUivwIXBjsMTmbduajtvkwgPuk88OhXXzZ4yxgcjgyeSTwkfFnwVBL6GWiM5RWK rzdH42iuq2JDgyIFnzgfdt6LO1n7YeJrs/mNkkwySZV3vzUEOa2F6UWXivL5ho5N5IN7 PfEnjYPTZuWDhFUU/4fRP7MzOORDwh3kwdgeG6Pnb0cYu3YHUnk8jMKjMAocRoOTh7aB FHmA== X-Gm-Message-State: AMCzsaV9nadAyRJmdiGF82jngisRsTKPpiGxmUSKfTQmIrqk0cymxCm7 EXe4wRSUPKV1WlcA1coWSXpvnnVsQ6jeuKPMflg= X-Google-Smtp-Source: AOwi7QBeFzTpkWPhBxy1IfbDFu5XWEaln8qqjx7pnl/Rqy2P19ErSmXcGE9R8eq1l0bdK29CRDidgMlliR3RQRnPbto= X-Received: by 10.98.194.8 with SMTP id l8mr11750823pfg.253.1507599183904; Mon, 09 Oct 2017 18:33:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.151.131 with HTTP; Mon, 9 Oct 2017 18:32:23 -0700 (PDT) In-Reply-To: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> From: Kathleen Moriarty Date: Mon, 9 Oct 2017 21:32:23 -0400 Message-ID: To: Martin Thomson Cc: Benjamin Kaduk , ART Area , MILE IETF , "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 01:33:05 -0000 On Mon, Oct 9, 2017 at 9:11 PM, Martin Thomson wrote: > On Tue, Oct 10, 2017 at 10:57 AM, Benjamin Kaduk wrote: >> I think that one could make the case that using TLS 1.2 (or higher) greatly >> facilitates having a secure system, and so it could plausibly be required >> by a consuming protocol. > > The problem here is that the protocol is actually HTTP. And that > protocol has requirements already. A recommendation to use TLS 1.2 is > fine, but that is already part of RFC 7525. > >>> needed. Similarly, the prohibition on the use of 0-RTT is groundless. The >> >> I am a little surprised to hear you say that this prohibition is "groundless". >> Given that we require consumers of TLS 1.3 0-RTT data to explictly specify >> an application profile for how it may be used, with the intent to induce >> a careful analysis of the security considerations for sending early data >> messages, it seems quite reasonable to me that a protocol author might >> wish to defer such a painstaking analysis and take the easy choice of >> prohibiting early data. > > This is quite explicitly using HTTP, which has a profile (work in > progress). If that profile is somehow inadequate, then a case should > be made in the draft explaining why (hence the choice of the word). A > reference to TLS 1.3 also has the unfortunate effect of delaying > publication of this draft. Can you provide a pointer? The profile is likely inadequate for this and many other uses of HTTP/TLS if early data is permitted. 0RTT has a large impact across many protocols including those that use HTTP/TLS. If there is no normative language, then it can continue on to be published with the draft for TLS 1.3 being used. This is an application where security is very important, so decisions like this that can be made now should be prior to implementers testing TLS 1.3. Best, Kathleen -- Best regards, Kathleen From nobody Mon Oct 9 18:56:22 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75EF133221; Mon, 9 Oct 2017 18:56:11 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 lGUJbG9Efl0a; Mon, 9 Oct 2017 18:56:09 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 90B061342E6; Mon, 9 Oct 2017 18:55:55 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id w197so38188343oif.6; Mon, 09 Oct 2017 18:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tqwLXpPx+1ogVGN6/nJv2z6hUOALnPEXYFHQdIKXsYg=; b=Tb9q2oX54MnHKUcr3vHh4HL29RSwq/L+FltyLPYec/1yrl40k4RQVWPE0J7F5NkUcZ eawDcgFYpgnMIb8+S8814uI7WQFDLtg3Fs5X/5dhktpkQa72yfm/UNfBtRyHUH28d5Sl 2ZakFuHgNvyvgDnGn3htiFRnWdFjE/MRy7HeOpTtgsJeHVoOkKZx0qyNaHDYAH01tARA GVUIoNJeqGjoOiRu+TViMlUkQo/TH0hl3G9INp4R2JWDvttiUcK/r/Pm8E/pfn/WRb/n FYNFOxUqPalofpRWWFe1MMtdqqkFjhtvsTQmUfnrqaDlAOT74974fpXmmeVrZG0uAELn xYKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tqwLXpPx+1ogVGN6/nJv2z6hUOALnPEXYFHQdIKXsYg=; b=d/QbNIOKdOHmi/Xv3j3HojJZIBVj+Tmvbpk6TG3oGeaefbc9GkRUOymisoFodSX1RX t0SrF76+tbMw8vUcC5bTeL4+S+Wz/G+VEWOUhNRjruv4zPDLyu234Jq2L4IzyqiooBtN JkrK8TNLzx8trRW1J6HkS6BRroBR3exBewZSvZYBZIzacuW1zVIlQ1MhQ4nEMIF3bpZS XCdOs7AsF+uEPkQcDNJKenJgBBi8beuCgkHUR8ZIpTCIqGgNb5Ay/PRbTvFLitFocYpg ZZ5Gejg9Kion3JAaencpmIl0J1CKMgG5YbrpTvcYcZbq/SBxox1Kc7fq3SXA8yz5h0UN xGoA== X-Gm-Message-State: AMCzsaXMLgH6kWLml6aW3LZTUrj8q9/pHkZq6GdZ6w7ff6FCi3fQz2d4 jOCYbHQynNnrR2vbU1ETtEm1kAja4CG0i78qThI= X-Google-Smtp-Source: AOwi7QCC+J4gGidHZ+zlvg91ga3CBP99fIN8Vhw3EvxNUN8wpRGgnZOzyXX4cjsx2XCTEvC1iviZ4uVzwXf8vKg2hQo= X-Received: by 10.157.37.90 with SMTP id j26mr746772otd.401.1507600554870; Mon, 09 Oct 2017 18:55:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Mon, 9 Oct 2017 18:55:54 -0700 (PDT) In-Reply-To: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> From: Martin Thomson Date: Tue, 10 Oct 2017 12:55:54 +1100 Message-ID: To: Kathleen Moriarty Cc: Benjamin Kaduk , ART Area , MILE IETF , "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 01:56:12 -0000 On Tue, Oct 10, 2017 at 12:32 PM, Kathleen Moriarty wrote: >> This is quite explicitly using HTTP, which has a profile (work in >> progress). If that profile is somehow inadequate, then a case should >> be made in the draft explaining why (hence the choice of the word). A >> reference to TLS 1.3 also has the unfortunate effect of delaying >> publication of this draft. > > Can you provide a pointer? The profile is likely inadequate for this > and many other uses of HTTP/TLS if early data is permitted. 0RTT has > a large impact across many protocols including those that use > HTTP/TLS. https://datatracker.ietf.org/doc/draft-ietf-httpbis-replay/ Editor's copy (with a number of changes): http://httpwg.org/http-extensions/replay.html > If there is no normative language, then it can continue on to be > published with the draft for TLS 1.3 being used. This is an > application where security is very important, so decisions like this > that can be made now should be prior to implementers testing TLS 1.3. Currently there is normative language, and it wouldn't make sense to make any sort of statement with respect to 0-RTT without making that statement normative. However, I think that it would be wiser to rely on HTTP doing the right thing here. I would of course encourage you and the document authors to review the draft above to see if we're making completely unsuitable recommendations. I realize that security is very important here, but I don't think that it is so significantly special that a whole new application profile of HTTP is needed. HTTP can be very secure with the right configuration. Strong recommendations about good practices for both configuration and operation are appropriate. RFC 7525 is what I would use for that. RFC 7525 covers all that the draft does and more. From nobody Mon Oct 9 20:06:01 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5DF13431D; Mon, 9 Oct 2017 20:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 6k5615ee3IV7; Mon, 9 Oct 2017 20:05:57 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 64ADF1323B4; Mon, 9 Oct 2017 20:05:57 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id q4so47407772qtq.8; Mon, 09 Oct 2017 20:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pPNso3UHrRR1l5704Hozpp4yXMwx0f/qKXq03DR27ic=; b=YfOhzwM0+CDrTAtmm4oKcbnLmHZUv1Wb7S+5yRyDlp+sch1qLtq4dnMXweUBUiIbY+ 4spH1Rmf5rfpaqeghAbP8LFDNOvhzmtQJnkkpNNzwZUh8xWrA2lfLNfJ3D3iTTfFtRCJ plg0RwrSd+fFtqVo4O6cTL7omH7KIZQ5PB3GR9FOqmNvoPSTjmm5urAEr3+EilSiorty zkmnMv9KcN3C0AueFVyor2pjPes11MYOQBTQerSzthcJzrstMq2zELwFGXhxbyAYaNPI 6X0dlio7KqHPglUujetPtfigWy/JkGRp5tjlFLfPtxISv14mzQ0NQ9hAHOMaIH9Dvq/9 Lwsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pPNso3UHrRR1l5704Hozpp4yXMwx0f/qKXq03DR27ic=; b=sNb2Jcpqnb/89fHBflsZQxyrSWhx4p+7hjvghfEVRl4/ljeRe4vQoC/ugZ79PnGbMJ jT8oEJGCIGs6CvVlS6t5WoPrxq7VNpQ/euQQOuYgIPOH0st1aw9nadllGgWHUicwDaYj Yd3gXMb42zs9TFPvNwxANktthZmvQablafb8Yo4vAbg8pg5x8DoU6XRVwtwTqKPzQFFF C+Us0xZYkmBqRspHjwLjvFrKm0kAq7kB4fPNlaIPlI02HWeX6yd5rxQac5/C7b/70bbS 9a1lk7G1sJ2SUN2x54Hqo2U7p5WVKdmyt1gkzGJdy8PV2K6GIRgEi4+6/2rrgENdklFy dajQ== X-Gm-Message-State: AMCzsaXPwpiCeh9Y7nO0aA0ezjK3eyH2BdLJqdQkE0M6P385Vu2ts4+A sN9lyXW/ejQ/asgyeOfCYZg= X-Google-Smtp-Source: AOwi7QDQwiTaErKRdgFINE0id3LKPUWwSvNVGk+WnTV8JZ2xjo8Ebj0ZPnj5D6mAQ4AJ9dZmVa1fsQ== X-Received: by 10.55.126.2 with SMTP id z2mr12631313qkc.39.1507604756549; Mon, 09 Oct 2017 20:05:56 -0700 (PDT) Received: from [192.168.1.6] (209-6-124-204.s3530.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id n4sm5650376qkf.49.2017.10.09.20.05.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Oct 2017 20:05:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Mon, 9 Oct 2017 23:05:53 -0400 Cc: Benjamin Kaduk , ART Area , MILE IETF , "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1D786709-4F2C-4D39-B55D-A4F9EBE82C99@gmail.com> References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> To: Martin Thomson Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 03:05:59 -0000 Sent from my iPhone > On Oct 9, 2017, at 9:55 PM, Martin Thomson wrot= e: >=20 > On Tue, Oct 10, 2017 at 12:32 PM, Kathleen Moriarty > wrote: >>> This is quite explicitly using HTTP, which has a profile (work in >>> progress). If that profile is somehow inadequate, then a case should >>> be made in the draft explaining why (hence the choice of the word). A >>> reference to TLS 1.3 also has the unfortunate effect of delaying >>> publication of this draft. >>=20 >> Can you provide a pointer? The profile is likely inadequate for this >> and many other uses of HTTP/TLS if early data is permitted. 0RTT has >> a large impact across many protocols including those that use >> HTTP/TLS. >=20 > https://datatracker.ietf.org/doc/draft-ietf-httpbis-replay/ > Editor's copy (with a number of changes): > http://httpwg.org/http-extensions/replay.html >=20 >> If there is no normative language, then it can continue on to be >> published with the draft for TLS 1.3 being used. This is an >> application where security is very important, so decisions like this >> that can be made now should be prior to implementers testing TLS 1.3. >=20 > Currently there is normative language, and it wouldn't make sense to > make any sort of statement with respect to 0-RTT without making that > statement normative. However, I think that it would be wiser to rely > on HTTP doing the right thing here. I would of course encourage you > and the document authors to review the draft above to see if we're > making completely unsuitable recommendations. >=20 I'll review and see if the WG participants can as well. I think there will b= e many applications to follow with high security requirements and no toleran= ce for replay attacks. > I realize that security is very important here, but I don't think that > it is so significantly special that a whole new application profile of > HTTP is needed. HTTP can be very secure with the right configuration. Configuration mistakes happen and lead to big problems. > Strong recommendations about good practices for both configuration and > operation are appropriate. RFC 7525 is what I would use for that. > RFC 7525 covers all that the draft does and more. Yes, I had pointed that out in my review. Best, Kathleen=20= From nobody Mon Oct 9 20:46:00 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866E9120724; Mon, 9 Oct 2017 20:45:53 -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 LCjj1zwaMB6T; Mon, 9 Oct 2017 20:45:52 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 5C7C2132F3F; Mon, 9 Oct 2017 20:45:52 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id u130so43081945oib.11; Mon, 09 Oct 2017 20:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6z19sJx3lmC8z1rr9CiF77kCoEfnrTkfkXaBssBIbFA=; b=OW19ZklbLc4UaB33lFbyU68DVo9zbU0zOcAXZRn1TVo2K+Gmdb9U7SEYo7oZqLREvD 22IGOnyU7WeAi5JEkJPh6jEzd+n/NnFWVG8mbAbSW+t1KO5ii4tvIUqC4OuFsAi/92YP PHeEAsg3u7wEPT2WLHSVna9pq+BsoH4UcrYSD2CmDs4k+q3gwzfXBaz/iW1FmlwUraz7 6cbmie7U03CiSlgm50HQJFO+RL6lb5FSQzQpJOoOEmUZapnYXzFtHHKPj+rmsBU45Mhj MXdDz/WyAl9F96PhfYuIs+IfLoth3VKlmn7X1vpYSwuCLqDowUVdznPm0vxIwm14eCat wzJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6z19sJx3lmC8z1rr9CiF77kCoEfnrTkfkXaBssBIbFA=; b=WlgbDc3rmSbTlYsnmllu4gMQ571TKjflXESJLmcMSiPyIsCdsuNKwTW+8kb18VJkzb VmtcexKIhlVyEcg3ydVkE5LsbyA3NdqljY/gzOXfynkIMeLiIUi0/yX2eLqiwIxcNE0a 9Mrf7N4Nved48dZsGR7RqI5ruqJxnmSWD5FQG9v4OmkFMsHO+HLEkp4fQ/8Ugqto+GWv siTH979QXQ84zM3xKYih4nAGh8Rojg91oGl/Un4bGv2apDD77NhzcglAgSGBCdxSrlWT F1uN8mbOJWOpkDnNUGk+Xg05iJ4sOkwX+6A4u8zSe9R0UBy2k+B9XXJZeWyH1ZP7jEOA GYXw== X-Gm-Message-State: AMCzsaWGH7Z0DCfF8Abz7afgKfoEUGbSDaWNpzDG5HMPOuTXenT1Ct7v ZFvDMNZwqaBqwueqNXlfv8G6BoYWq6KWG8Bzhvo= X-Google-Smtp-Source: AOwi7QDFlnwbIzSKGpA7c2DhiakBucXCeB2QnBvzLMbhxpJa52JN9V/VnwwQTh9qz+XTCVMBSipMlH3bqRluZW3avKs= X-Received: by 10.202.102.39 with SMTP id a39mr5488399oic.83.1507607151655; Mon, 09 Oct 2017 20:45:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Mon, 9 Oct 2017 20:45:51 -0700 (PDT) In-Reply-To: <1D786709-4F2C-4D39-B55D-A4F9EBE82C99@gmail.com> References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> <1D786709-4F2C-4D39-B55D-A4F9EBE82C99@gmail.com> From: Martin Thomson Date: Tue, 10 Oct 2017 14:45:51 +1100 Message-ID: To: Kathleen Moriarty Cc: Benjamin Kaduk , ART Area , MILE IETF , "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 03:45:53 -0000 On Tue, Oct 10, 2017 at 2:05 PM, Kathleen Moriarty wrote: > I'll review and see if the WG participants can as well. I think there will be many applications to follow with high security requirements and no tolerance for replay attacks. That is true, but it's not clear to me that this is a protocol that is intolerant of replay. AtomPub follows a pattern that limits exposure fairly well. The primary thing to safeguard in ROLIE is the confidentiality of the content, and replay won't generally compromise that. The sorts of things you might see is duplicate resource creation (we recommend against POST in early data for that reason; we also recommend against PUT), and the sort of traffic analysis and timing side channel information that reveals if resources exist or have been updated (which shouldn't be an issue here). From nobody Fri Oct 13 07:21:18 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B511320C9; Fri, 13 Oct 2017 07:21:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 f__3lQf2T95D; Fri, 13 Oct 2017 07:21:04 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 463EA120720; Fri, 13 Oct 2017 07:21:04 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id l188so10435190pfc.6; Fri, 13 Oct 2017 07:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=71cgjs9Yt2MqZcSaV5HJSutli3rMlIiG6jtDQWbNGSQ=; b=sI0R2R25ZLgqxlnkvsVOj3cUEQJlDJMjvHrPiJJhdFmaTcor/P/mbJF33MlhJtkU0D jz6b1KEe3gG+9m/kyniRP+4pLasNn3FnZqVfverwE1oAmR0eJ9GQWP8opjlzxstjhzHE PcEr0bwg9n0GpS8bbyqzzTrwMPEduPioHqzbgSngT9x8k/preXx3t7H+iWi4Kfxgr4Zz +IFUlehMgZZtnKgLjUA8ZHzglNYs7IB8PZZ+PziRmFTKAojmoe0DhdNNy0Z2lQNWjx9E Fyns6Fb7RhhjNtgEOhLzTGLJRj1old+h56/3/YEgL8HLGlPe4vl522ap39Nb3e0dHlII fxUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=71cgjs9Yt2MqZcSaV5HJSutli3rMlIiG6jtDQWbNGSQ=; b=Fq42EVeYl6MDfuXtGS669MOlKTAaGw03otBF12AN5SFQceQgJuaCOgiz5SB2wzfmQZ ZJ0nItl/BAU9nL13dIrHOZEG5V6Qqw+FRE0Ek9K1Xka2BY5nnj7B5gO7iMbKm708WxEk cvdG57vZ+5AU7LHuNd7ZbwYjW7qMDAEeoWkQP8j8kK9KsAhF0oShZCQwfYAPnrfz/tMS ItgLCGVbtXCa4KCtJVm3MVhRaLOssHaX6+JS3MZRVHJ0GmwuQrukvErumWZNbE85OAAZ Czqi0ZcczLWrceknuJLCukqK/bymDT1f81eAv8dLZd5mJ4rRGD9ZadJ6MRMxE0O2u8G+ uI/Q== X-Gm-Message-State: AMCzsaUYC8BAd2YsveacDIVnGK9oRKxBhsIKBH3Pe6PJm9FKeD6HXdGI 0lSxl17lbpmuvZ5x71utYnMyhnEYUXriXEbzKws= X-Google-Smtp-Source: AOwi7QAXF5iZCwosIRCer0YIDh/8hPLrKycPws4yc47QdQ2BbEq7TATycBWK+/hmLKtbUQp7WGDEdIOXQHBMA7pKFyE= X-Received: by 10.101.83.12 with SMTP id m12mr1450021pgq.153.1507904463823; Fri, 13 Oct 2017 07:21:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.194 with HTTP; Fri, 13 Oct 2017 07:20:23 -0700 (PDT) In-Reply-To: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> <1D786709-4F2C-4D39-B55D-A4F9EBE82C99@gmail.com> From: Kathleen Moriarty Date: Fri, 13 Oct 2017 10:20:23 -0400 Message-ID: To: Martin Thomson Cc: Benjamin Kaduk , ART Area , MILE IETF , "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2017 14:21:06 -0000 The telechat prep delayed my response. Inline. On Mon, Oct 9, 2017 at 11:45 PM, Martin Thomson wrote: > On Tue, Oct 10, 2017 at 2:05 PM, Kathleen Moriarty > wrote: >> I'll review and see if the WG participants can as well. I think there will be many applications to follow with high security requirements and no tolerance for replay attacks. > > That is true, but it's not clear to me that this is a protocol that is > intolerant of replay. AtomPub follows a pattern that limits exposure > fairly well. The primary thing to safeguard in ROLIE is the > confidentiality of the content, and replay won't generally compromise > that. The sorts of things you might see is duplicate resource > creation (we recommend against POST in early data for that reason; we > also recommend against PUT), and the sort of traffic analysis and > timing side channel information that reveals if resources exist or > have been updated (which shouldn't be an issue here). I see what you are saying and that makes sense, but you also lose forward secrecy with 0RTT and that is a problem. I think we need to accept that there will be uses of HTTP that will not allow for 0RTT. In the draft you mentioned in the HTTP working group, section 3 even starts out with, "When a server enables early data", meaning it won't always be appropriate. I do think that draft should be more clear on the risks, with a pointer back to Section 2.3 of TLS 1.3. I think there will also be cases where HTTP is used and the profile isn't a fit. Since some implementations of TLS 1.3 keep the streams separate (0RTT and full negotiation), just using the full negotiation stream will reduce configuration problems for implementers. Lots of security problems are the result of configuration mistakes and if we can avoid them in places where it matters, we should. The systems running ROLIE will be ones that enterprises will regard as high value assets. Replay attack and lack of forward secrecy aren't acceptable. The same will be true of many other HTTP enabled services. A performance gain isn't worth the trade off. Even with the profile you've created, the server has the option to not enable early data, although that's not as clear as I think it should be in the draft and is something that would be good to improve, If developers implementing the HTTP profile only look at this draft, they have to have enough context to understand the implications that they must in turn ensure implementors of their code/applications using code have the information to make appropriate decisions for their environment. I hope that's helpful enough for an update of your profile draft. My opinion is that for ROLIE, there is no need for 0RTT. I'm not sure a slight delay in publication would matter much since TLS 1.3 is getting closer to publication. If it is, we could also play with the language so it's an informational reference if there is a rush. Thanks for your thoughtful review. -- Best regards, Kathleen From nobody Sat Oct 14 02:31:04 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E23C13303F for ; Sat, 14 Oct 2017 02:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 9UZTB-vAXPYi for ; Sat, 14 Oct 2017 02:31:01 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-oln040092066050.outbound.protection.outlook.com [40.92.66.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 737C8132FB1 for ; Sat, 14 Oct 2017 02:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sz0GfDFkTRvILKBHGeCtgJ5G/TrFu5nHm8gsEgkxJmY=; b=YHuK+EW1sYd/A+IXcV/uivKEaROd3S/CGmBDRlDhYfAkHin4ud5B5b+p47Cr9etfu9Ru7HpEISlZMvOrPm1YZDTKq778KXcYstEBgVTJp+dkJ7rq8tt3BoZYqQWed72aRKSMUDK7ED/DB58KAtR2hzLWxwqhFcWCko9P1RsTMHVQ7khNBKDAaIPinNwURTkOgwkEXbgchD3ILqxzM6Q4MdT3PLuXdHACQFj+uYoZ6YtgbA0NyTqYP+sviCaL5A3jY4s9Lkd6zspEgX5pdd2kPq8C5lExpvM/qG/dk5+HNpOY8UoBRvPbfQ+kaPt41QRxI1ZF6zgTLK+5pLap/2Qhiw== Received: from HE1EUR01FT012.eop-EUR01.prod.protection.outlook.com (10.152.0.56) by HE1EUR01HT044.eop-EUR01.prod.protection.outlook.com (10.152.1.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.77.10; Sat, 14 Oct 2017 09:30:58 +0000 Received: from AM5PR0401MB2627.eurprd04.prod.outlook.com (10.152.0.57) by HE1EUR01FT012.mail.protection.outlook.com (10.152.0.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.77.10 via Frontend Transport; Sat, 14 Oct 2017 09:30:58 +0000 Received: from AM5PR0401MB2627.eurprd04.prod.outlook.com ([fe80::7958:1df3:aa34:f86f]) by AM5PR0401MB2627.eurprd04.prod.outlook.com ([fe80::7958:1df3:aa34:f86f%17]) with mapi id 15.20.0077.022; Sat, 14 Oct 2017 09:30:58 +0000 From: Antoine Germanos To: "art@ietf.org" Thread-Topic: Creative Commons Attribution-ShareAlike License Thread-Index: AQHTRM8klYCc2i8KW02oEk14W7QcZA== Date: Sat, 14 Oct 2017 09:30:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: hotmail.com; dkim=none (message not signed) header.d=none;hotmail.com; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:B268E6C49B50C5B73A7AAFF539725F8F59E581BEE0FDFC7473C26AAF6F1CC0FC; UpperCasedChecksum:378E7D6C0EC780063B4C955F4BE7C74C1ACB3272D36613BEFB1D1B620D3E574B; SizeAsReceived:7074; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [X/rD4gbAomffoxm0yRi48Fbd1Ee6Rcgf] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1EUR01HT044; 6:pmbDLC07HXKjvZQbqk2YZa8QxA/sOZQ4y4cY8bkg689KFpulKJYBb+II64rwm4YWC8IHzhjDix9YzRF9J/y052tyGG31PQpSOXO3Kk73IFxuu4nfjW/Ux33xigkOdzYCXKS5og4UxAZXt6JR3wV/PZQTOvK9xlAIQ/P9Yo/+C/TPr0Cbv/hz3J/3Vi4rJZJAWZZTTsmjDeMT23vby+WtyS3my8WR3srEUdhy07fKrmTOJX52Kys5HfuGA3ctrdAPCmETbORiAg9bWY2Ck7t4i875kZyGmqthErfKs0GuBgQTOevS7BT2kVHN/n+qzllblPoghEotsq09u4tYS4tjcA==; 5:nK6ZzsUbJ7zAvjVUxmn8XtbIZHRl91abFpiGvBSyq7CZXVlxW3zeKS0Q2ibuk6w0pSAI4PcNbAUD1uGMNovHR0wrfnbKqd18fCYKg3wC5Hf5bWXiSaby8BeG05MjkKm7YVqMBJAzMTcjYflEtca5/A==; 24:CZAEQeHcbTnZCnUoJUcae/F36xAuMvOGi/RD3JHvaSQX2+oDXZb9K2QhZxvj/P7g4keVFrbI8mky4U/LB+KPIVkAyEKFjOXYBB++ZBz+zNg=; 7:B526Qm85k5XGXZrKmht2jf0WcDMCfw42qg+RNBVCk34lLT1r51bxZaO6SU+uP8dhvxYUWXds+wVWL+YeDSh6yohUJ+Jdw5a4fz4y3qfeOj0tJ8duzM1EStUzqCQUBMe/tB9WBHPdM//wsO3rH58fLGEQZpqaB3psDdvB6allC1dzp5Do8+UAyd2JO/rpPQkfXqA8D/bRfw4PXc39emXAlJAE6rtDoDa4jcwlK9eGdls= x-incomingheadercount: 46 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: e393fb19-57ff-4c8b-244c-08d512e646d0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(201702181274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:HE1EUR01HT044; x-ms-exchange-slblob-mailprops: 28a0PtNssKnEFTd/Cyrm0WON78pPHDLfg7y2eiX8ut1dJ8dKjnOFpmKIL60qBUUzUPMUPdkVKgJrOJIzdkCmBhWYcl8kfPlk+IfgNMHOOfrBqxCpdoZxSdS0OtHeVm+5SkDEeO9tpUQxvwckbK3QpGcEC3NzZ2gxywiZGBYeZyZnraBAo8KRfQ8hfC2Lu+W3oY+k5TS8fAKEmnaRghjPe6M4/Chf55tFIPaCxqFPegEZj2PdAg11d3N1vRPB/MYdxhUma0gpTGPz9Xd0NnEiGKL7htsBrihXaIcOwydTmi0Y0Kt186PndJDkSe1TBPg5AszTIQoL8uA2iPIA0fq/gq7Pk2J/OzKzmHDpt4c9BkEgy/JmWfyOpLA+eWZ/+beg2twEmc0/YWosSYbsuc14omCWeBofyWTt69F5Td5BkiksKsf0J8UPGMcxka1ypzaM4NJvwdMR1vNNKDpAHxtT37Mupsmvj2+ySRSPnjlm0crgakURyiGJNh8EGiu+zFBCnZiFYqp6RBGkEmrylB7AgzWpBiCI40E5/EP2eMBooC6SxRhOIOhSst2Eil9YfHEVROjnZvIzbT9Lc8q5CRqqxHOM2wO2l2fPsIgHy7uAKpBMz9AP7e8YR49IRYmrKWMPcr2cEAkt1kYsXqce40yN/rnZWjbxuG8sCxC3hjxJIYU8INxsHnBlQ/dI2rtxzm1rWNqVJClyev9+9WvUhRK8VUkTkdhwQzBlIBZcMHH8y14dBzI11ifxHtuBisYmOJvj2Ae3G5wQWfNAmBOISPomJEJ9jg0H9werAXh+Sa3LTf/p26lbN4varhxQ8oYQQGr+FIhRB1wjCZOS5fScur2uBtVnzYmVaBYwFkjiEq0UcRwdDm3srRy5pXKz/z63XkiQ/zN30tzH9ETJ7UYhFPrK3A== x-ms-traffictypediagnostic: HE1EUR01HT044: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:HE1EUR01HT044; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1EUR01HT044; x-forefront-prvs: 046060344D x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:HE1EUR01HT044; H:AM5PR0401MB2627.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0401MB2627710AD180A5D611CC4C4299490AM5PR0401MB2627_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2017 09:30:58.1835 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1EUR01HT044 Archived-At: Subject: Re: [art] Creative Commons Attribution-ShareAlike License X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 09:31:03 -0000 --_000_AM5PR0401MB2627710AD180A5D611CC4C4299490AM5PR0401MB2627_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VW5sZXNzIG90aGVyd2lzZS4NClRoYW5rIHUNCg0KICBBbnRvaW5lIEdlcm1hbm9zDQoNCg0KT24g T2N0IDEwLCAyMDE3LCBhdCAxMDowMCBQTSwgImFydC1yZXF1ZXN0QGlldGYub3JnPG1haWx0bzph cnQtcmVxdWVzdEBpZXRmLm9yZz4iIDxhcnQtcmVxdWVzdEBpZXRmLm9yZzxtYWlsdG86YXJ0LXJl cXVlc3RAaWV0Zi5vcmc+PiB3cm90ZToNCg0KU2VuZCBhcnQgbWFpbGluZyBsaXN0IHN1Ym1pc3Np b25zIHRvDQogICBhcnRAaWV0Zi5vcmc8bWFpbHRvOmFydEBpZXRmLm9yZz4NCg0KVG8gc3Vic2Ny aWJlIG9yIHVuc3Vic2NyaWJlIHZpYSB0aGUgV29ybGQgV2lkZSBXZWIsIHZpc2l0DQogICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FydA0Kb3IsIHZpYSBlbWFpbCwgc2Vu ZCBhIG1lc3NhZ2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRvDQogICBhcnQtcmVxdWVz dEBpZXRmLm9yZzxtYWlsdG86YXJ0LXJlcXVlc3RAaWV0Zi5vcmc+DQoNCllvdSBjYW4gcmVhY2gg dGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdA0KICAgYXJ0LW93bmVyQGlldGYub3JnPG1h aWx0bzphcnQtb3duZXJAaWV0Zi5vcmc+DQoNCldoZW4gcmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlv dXIgU3ViamVjdCBsaW5lIHNvIGl0IGlzIG1vcmUgc3BlY2lmaWMNCnRoYW4gIlJlOiBDb250ZW50 cyBvZiBhcnQgZGlnZXN0Li4uIg0KVG9kYXkncyBUb3BpY3M6DQoNCiAgMS4gUmU6IEFydGFydCBs YXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbWlsZS1yb2xpZS0xMA0KICAgICAoTWFydGlu IFRob21zb24pDQo8bWltZS1hdHRhY2htZW50Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCmFydCBtYWlsaW5nIGxpc3QNCmFydEBpZXRmLm9yZzxtYWls dG86YXJ0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9h cnQNCg== --_000_AM5PR0401MB2627710AD180A5D611CC4C4299490AM5PR0401MB2627_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpV bmxlc3Mgb3RoZXJ3aXNlLg0KPGRpdj5UaGFuayB1PGJyPg0KPGJyPg0KPGRpdj48Yj4mbmJzcDsg QW50b2luZSBHZXJtYW5vczwvYj4NCjxkaXY+PGI+Jm5ic3A7Jm5ic3A7PC9iPjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pjxicj4NCk9uIE9jdCAxMCwgMjAxNywgYXQgMTA6MDAgUE0sICZxdW90OzxhIGhy ZWY9Im1haWx0bzphcnQtcmVxdWVzdEBpZXRmLm9yZyI+YXJ0LXJlcXVlc3RAaWV0Zi5vcmc8L2E+ JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YXJ0LXJlcXVlc3RAaWV0Zi5vcmciPmFydC1yZXF1 ZXN0QGlldGYub3JnPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj4NCjxkaXY+PHNwYW4+U2VuZCBhcnQgbWFpbGluZyBsaXN0IHN1Ym1pc3Np b25zIHRvPC9zcGFuPjxicj4NCjxzcGFuPiZuYnNwOyAmbmJzcDs8YSBocmVmPSJtYWlsdG86YXJ0 QGlldGYub3JnIj5hcnRAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+ DQo8c3Bhbj5UbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdl YiwgdmlzaXQ8L3NwYW4+PGJyPg0KPHNwYW4+Jm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXJ0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2FydDwvYT48L3NwYW4+PGJyPg0KPHNwYW4+b3IsIHZpYSBlbWFpbCwg c2VuZCBhIG1lc3NhZ2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRvPC9zcGFuPjxicj4N CjxzcGFuPiZuYnNwOyAmbmJzcDs8YSBocmVmPSJtYWlsdG86YXJ0LXJlcXVlc3RAaWV0Zi5vcmci PmFydC1yZXF1ZXN0QGlldGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0K PHNwYW4+WW91IGNhbiByZWFjaCB0aGUgcGVyc29uIG1hbmFnaW5nIHRoZSBsaXN0IGF0PC9zcGFu Pjxicj4NCjxzcGFuPiZuYnNwOyAmbmJzcDs8YSBocmVmPSJtYWlsdG86YXJ0LW93bmVyQGlldGYu b3JnIj5hcnQtb3duZXJAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+ DQo8c3Bhbj5XaGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5b3VyIFN1YmplY3QgbGluZSBzbyBp dCBpcyBtb3JlIHNwZWNpZmljPC9zcGFuPjxicj4NCjxzcGFuPnRoYW4gJnF1b3Q7UmU6IENvbnRl bnRzIG9mIGFydCBkaWdlc3QuLi4mcXVvdDs8L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+PHNwYW4+VG9kYXkncyBUb3BpY3M6 PC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj4mbmJzcDsmbmJzcDsxLiBSZTog QXJ0YXJ0IGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1taWxlLXJvbGllLTEwPC9zcGFu Pjxicj4NCjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyhNYXJ0aW4gVGhvbXNv bik8L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj4NCjxkaXY+Jmx0O21pbWUtYXR0YWNobWVudCZndDs8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+DQo8c3Bhbj5hcnQgbWFpbGlu ZyBsaXN0PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Im1haWx0bzphcnRAaWV0Zi5vcmciPmFy dEBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcnQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYXJ0PC9hPjwvc3Bhbj48YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM5PR0401MB2627710AD180A5D611CC4C4299490AM5PR0401MB2627_-- From nobody Sun Oct 15 17:46:11 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E8D1332D4; Sun, 15 Oct 2017 17:46:02 -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 i9G13exjYFbK; Sun, 15 Oct 2017 17:46:01 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 F2FF11321A4; Sun, 15 Oct 2017 17:46:00 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id c77so22552556oig.0; Sun, 15 Oct 2017 17:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q0tGNwqGIwnQjYbYltOIcifuQmb8I7/BcIytxvpnU1I=; b=sLzsNn++IwhX3r92s4rlJrfjSX9RMYx9Su6zRyqsKBOGx1QN3l2gSzYbcG7766I5YC KGxLONbgYY4BrGt1Qm1OyCGV/pAhAM4gK6doNjFHSK3TFmKnoNmjVM9H6ItlAhZ6Dsxd oiprNsLOP1MPjToiOWxpLMT9mwHMTkotbEYYewbYv0f/Y9kzQ+xg0eo0vRvMYAKaSwHm Cwz2kbOpQrTE+6NPuqvWp6TWLQz+KzgtCZEo+BDj3lDzb2KQ4hWQDIsN06gA53dzmhLQ O1+/g8/2JIZ9GdRCqshYCe39lSJfgAT/OcIw9v/MrH2h4I9PjHHf6Z4Ll03DqWtLVBPG mOrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q0tGNwqGIwnQjYbYltOIcifuQmb8I7/BcIytxvpnU1I=; b=F9e9EaWqw3U8o5w8DWUfFts4sM7Se0mapE+Lt5ELRifhE97/3zpNyRi8fVBmaTkBCL NGD1m5N8ywHcfEpL/yrL3CM+83xcvSFxPuffRq7RdDDMYMDWCwXcd8bZFID7fjZXvVHH In6ixh8YIjiy46bR870keb0fndoPu7ue+3ZNyA4jUDNp/tfblvKwyjmoFTKosmWZSADQ 3kIavwAwEsoYV8M7lKMVvi+41ztf8u2xQQSEZ9Dkuu3KIoRTaUAjzwMKEC57wbOz7KvR R6+c4WTDI2ULylgKslC1+mBaN1m1ZLjP0lZnOV0ogJH+I5ryXjJVwJSzMrwzjpu+ZwKe CVhg== X-Gm-Message-State: AMCzsaWzMD0yD3J4JeJ2kufV2RPvp/RnPoEgjmj7qnecOSUF29+aY7sj AepipArSSdxnEJJErhE0NuD52fW2+K8EQ+LLn/c= X-Google-Smtp-Source: ABhQp+R+nsaXB6wXT7UXf53FTH8UvyE9ceffNHzXtg3FCa2wanZRvG9KinR4McP+SvcrmwsumkXDp3dqr8fuTg8KMt8= X-Received: by 10.157.53.17 with SMTP id o17mr2687144otc.35.1508114760103; Sun, 15 Oct 2017 17:46:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Sun, 15 Oct 2017 17:45:59 -0700 (PDT) In-Reply-To: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> <1D786709-4F2C-4D39-B55D-A4F9EBE82C99@gmail.com> From: Martin Thomson Date: Mon, 16 Oct 2017 11:45:59 +1100 Message-ID: To: Kathleen Moriarty Cc: Benjamin Kaduk , ART Area , MILE IETF , "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 00:46:03 -0000 On Sat, Oct 14, 2017 at 1:20 AM, Kathleen Moriarty wrote: > The systems running ROLIE will be ones that enterprises will regard as > high value assets. Replay attack and lack of forward secrecy aren't > acceptable. The same will be true of many other HTTP enabled > services. A performance gain isn't worth the trade off. My point isn't to reject this sort of analysis, which is possibly correct, but to point out that this analysis is one that a deployment makes based on the circumstances Everyone thinks that their thing is a special snowflake, and that's OK, but you are asking for a levy on all implementations that would prevent use of 0-RTT in all deployments. I think that is inappropriate. I don't want to see every draft that the IETF ever published making its own assessment and a policy statement regarding this particular feature. (We don't mandate a particular authentication mechanism here either.) Note that TLS 1.3 permits resumption without forward secrecy. It's not widely implemented that way, but it is possible. If you care about forward secrecy (I'm not sure that it's especially critical in this context given the time-sensitive nature of the information you are talking about), then you have to make statements about that as well. But again, I would not on the same grounds: the purpose of this work is to define what interoperability looks like, not to legislate deployment configuration. Explain the trade-off and let the operational teams do their work. From nobody Sun Oct 15 18:43:15 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEEF41332DA; Sun, 15 Oct 2017 18:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 auoN8ggvMH8W; Sun, 15 Oct 2017 18:43:06 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 B68F812895E; Sun, 15 Oct 2017 18:43:05 -0700 (PDT) X-AuditID: 12074424-8a5ff70000004fa7-d2-59e40ea61300 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 45.E4.20391.7AE04E95; Sun, 15 Oct 2017 21:43:03 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v9G1h1NZ009738; Sun, 15 Oct 2017 21:43:01 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9G1guMP002994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 15 Oct 2017 21:42:59 -0400 Date: Sun, 15 Oct 2017 20:42:57 -0500 From: Benjamin Kaduk To: Martin Thomson Cc: Kathleen Moriarty , ART Area , MILE IETF , "ietf@ietf.org" , draft-ietf-mile-rolie.all@ietf.org Message-ID: <20171016014256.GK96685@kduck.kaduk.org> References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> <20171009235717.GN96685@kduck.kaduk.org> <1D786709-4F2C-4D39-B55D-A4F9EBE82C99@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUixCmqrbuc70mkwasnyhYr7npY/L/zl93i 2cb5LBYNO/Mtrp35x2ix538fkwObx85Zd9k9liz5yRTAFMVlk5Kak1mWWqRvl8CV8fuWa8Fh iYpJcw+yNzBeF+5i5OSQEDCRaH5zhLWLkYtDSGAxk8TaxQ8ZIZyNjBJH7j9kB6kSErjKJPFn UQyIzSKgKrF9TwNYnE1ARaKh+zIziC0ioCux6OwDdpBmZoHDjBJrz58HKxIWcJDY/qMJrIgX aN3xX++hNpxmkTh4chEbREJQ4uTMJywgNrOAlsSNfy+Zuhg5gGxpieX/OEDCnAKBEruvXQYr ERVQlpi3bxXbBEaBWUi6ZyHpnoXQvYCReRWjbEpulW5uYmZOcWqybnFyYl5eapGuuV5uZole akrpJkZQKLO7qOxg7O7xPsQowMGoxMO74tzjSCHWxLLiytxDjJIcTEqivOdaH0YK8SXlp1Rm JBZnxBeV5qQWH2KU4GBWEuHdy/skUog3JbGyKrUoHyYlzcGiJM67LWhXpJBAemJJanZqakFq EUxWhoNDSYJ3FUijYFFqempFWmZOCUKaiYMTZDgP0PAesOHFBYm5xZnpEPlTjIpS4rySIAkB kERGaR5cLyjVSGTvr3nFKA70ijDvdpAqHmCagut+BTSYCWjwu4gHIINLEhFSUg2MK6NKy6LX Of9w+ul4umZXUO6sBaJNZnbXF7zdfeW2nULSkbd7zRrbuDd3PGz46/92QdOXQruy+rfqvj+/ hE/TkbjO6ujkM7f+aPKB3Ng/tzqZrmWfVv/uJpDc/3C1zaM/HLMvLk9t/7IwPuhtt6Fj/+XT Fz9snuCXpz/5Q9eVEN6dH2+2B+0PUWIpzkg01GIuKk4EAMPnNXcQAwAA Archived-At: Subject: Re: [art] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 01:43:08 -0000 Sorry for the slow response to this thread; I wanted to have a closer read of the ROLIE document itself (and not just the cherry-picked TLS-specific bits). On Mon, Oct 16, 2017 at 11:45:59AM +1100, Martin Thomson wrote: > On Sat, Oct 14, 2017 at 1:20 AM, Kathleen Moriarty > wrote: > > The systems running ROLIE will be ones that enterprises will regard as > > high value assets. Replay attack and lack of forward secrecy aren't > > acceptable. The same will be true of many other HTTP enabled > > services. A performance gain isn't worth the trade off. > > My point isn't to reject this sort of analysis, which is possibly > correct, but to point out that this analysis is one that a deployment > makes based on the circumstances > > Everyone thinks that their thing is a special snowflake, and that's > OK, but you are asking for a levy on all implementations that would > prevent use of 0-RTT in all deployments. I think that is > inappropriate. I don't want to see every draft that the IETF ever > published making its own assessment and a policy statement regarding > this particular feature. (We don't mandate a particular > authentication mechanism here either.) Every draft doesn't have to; in the absense of an explicit statement it is assumed that 0-RTT should not be used. But, for protocols built on top of HTTP, perhaps things are not as clear cut. > Note that TLS 1.3 permits resumption without forward secrecy. It's > not widely implemented that way, but it is possible. If you care > about forward secrecy (I'm not sure that it's especially critical in > this context given the time-sensitive nature of the information you > are talking about), then you have to make statements about that as > well. But again, I would not on the same grounds: the purpose of this > work is to define what interoperability looks like, not to legislate > deployment configuration. Explain the trade-off and let the > operational teams do their work. My main consideration is that the ROLIE document we're talking about is a framework, and does not define any information types itself. So, you are asking the operational teams to know and anlayze not just what events they are currently handling but also all types that might be handled in the future, which seems like an intractable analysis for them to perform. But yes, you are right that a statement about forward secrecy as a requirement would be appropriate. I'm also quite reluctant to provide a general recommendation to send client-authenticated requests in 0-RTT, as it still seems too risky to me. I also don't see how preventing the use of 0-RTT is supposed to be a "levy on all implementations". It seems to only require *not* adding additional code/logic to handle 0-RTT. I could perhaps see calling it a "levy on deployments" that are unable to take advantage of the performance benefits, but given the large number of unknowns in what will be conveyed via ROLIE, it seems to me an unwarranted risk to try to take advantage of those benefits in general. -Ben From nobody Tue Oct 17 09:18:49 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643EE13303F; Tue, 17 Oct 2017 09:18:48 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (1024-bit key) header.d=nistgov.onmicrosoft.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 9B8LQMlJZ6-G; Tue, 17 Oct 2017 09:18:45 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0096.outbound.protection.outlook.com [23.103.200.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B514613303A; Tue, 17 Oct 2017 09:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=a6CWE8WdepRFBt5RUnfrCLipNFza/3XI2pyemx2RKUA=; b=ZuZWXbKIirXJjukkIRBS+Ba1oLuD5Gz38+4Mab2oF4Ns+WHY4gDzodNTsQod4CNq3/fD+AqDzc4pMLqEYWCGfttDunOmVNfOP0kpsu0e6fSgsos2ftwpdVSN24DLF855mh+/2INWE2Xp29RnphbUpusiGlwpWt6/ch+TV0cHLPM= Received: from DM5PR09MB1307.namprd09.prod.outlook.com (10.172.34.141) by DM5PR09MB1306.namprd09.prod.outlook.com (10.172.34.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 17 Oct 2017 16:18:44 +0000 Received: from DM5PR09MB1307.namprd09.prod.outlook.com ([10.172.34.141]) by DM5PR09MB1307.namprd09.prod.outlook.com ([10.172.34.141]) with mapi id 15.20.0077.022; Tue, 17 Oct 2017 16:18:44 +0000 From: "Banghart, Stephen A. (Fed)" To: Martin Thomson , "art@ietf.org" CC: "mile@ietf.org" , "ietf@ietf.org" , "draft-ietf-mile-rolie.all@ietf.org" Thread-Topic: [mile] Artart last call review of draft-ietf-mile-rolie-10 Thread-Index: AQHTQLy5EiZhxIKVNkSNg/Bn547ThKLoNUig Date: Tue, 17 Oct 2017 16:18:43 +0000 Message-ID: References: <150752570618.18384.5615358468704377459@ietfa.amsl.com> In-Reply-To: <150752570618.18384.5615358468704377459@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stephen.banghart@nist.gov; x-originating-ip: [129.6.251.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR09MB1306; 6:dkd+O0N5w+qf3GTS+sYsq2EkaTpimjDipPCA8fig60zWodhqO0TyJdu34Q/v6509QBKS88zkVEWAK95keN8DbJ54nUCokOPhIPoUW6uqMasY+8DmjppotYj9fFP9x/f863EmwAsNjBP3PtTSCYMKGfdHiZP12VNl5tFfvOnSiOAcgdxxk0IOmxmtsRrR0O+cuK7rqwBem9cfenAZFJh2c8g2GQwlm4db+/rdP9eDf7gZ8sOASM9QI2h4Iq7OuiP1Z+8kYxK4OH9FKt8Kwr1tIaMxLY3k3W+kzpWXOxCp4El/ckuZyLWFKToE+/xpAwEWTgQBBTw66NTNNu6AAgEMEA==; 5:tDlekDwNF64zk24+NiNF2//HE+OWJZgV+30ZK4VVUyqEesoF5HN3nwmWGqXugkNIqT1sz+/8tsDh+nGPd52Wt72aTxHW4prAYrop91dD1HAhcB6Ea6Ip78xJca2cWmvGYXcL5ibDnsBYzERubdSJ3A==; 24:s3Z2iIqGwjo/w8mbyaAw/zagSIzG7GJZWEnbOM9Q9ghtBPLLDu8MwCQqRMEnKYsfOVh8Dc9GZIFLt12vh9nweiTALDjqFs2aeCfpvwlG5qY=; 7:Sh2kTrhVSsnetIrCTXB+2FbATGcsUzMX7v2IYqjZZ1ci5JAYEtakrDhVRoDDcxtZl5FZ/zjCoiyQIshHLMjDlkGHBLcKyNdnVNJr+RipxEc2kLG/URADvxLB/xsIAiupfhid/O5XYwn3/EsW8JZaCMo3unorU1PO1kNpkOGk5C/8OKDqVsAz9sk5yolVxCH3rUJYiciCf4giRguMtoNIw4u6uG8y6UehMtxlxJzIXIE= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 757d0b2b-5c4f-40e7-aeb4-08d5157abcc8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR09MB1306; x-ms-traffictypediagnostic: DM5PR09MB1306: x-exchange-antispam-report-test: UriScan:(43050042349365)(158342451672863)(192374486261705)(189930954265078)(131327999870524)(150554046322364)(788757137089)(219752817060721); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR09MB1306; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR09MB1306; x-forefront-prvs: 04631F8F77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(346002)(199003)(55674003)(51444003)(189002)(3905003)(51914003)(13464003)(377454003)(43784003)(4326008)(316002)(25786009)(9686003)(7736002)(106356001)(74316002)(6246003)(105586002)(6306002)(99286003)(68736007)(55016002)(14454004)(76176999)(3846002)(6116002)(39060400002)(2906002)(305945005)(33656002)(53936002)(66066001)(102836003)(101416001)(54356999)(50986999)(97736004)(77096006)(81166006)(230783001)(229853002)(3660700001)(966005)(2900100001)(54906003)(110136005)(8936002)(189998001)(478600001)(2950100002)(2501003)(6506006)(6436002)(86362001)(8676002)(45080400002)(53546010)(7696004)(5660300001)(3280700002)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR09MB1306; H:DM5PR09MB1307.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2017 16:18:43.8593 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1306 Archived-At: Subject: Re: [art] [mile] Artart last call review of draft-ietf-mile-rolie-10 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 16:18:48 -0000 Martin, Thanks for the great review. We've been working through your comments and p= reparing a -11 version. I'll have a full response to your comments out to t= he list once we've completed addressing them all, but wanted to open a disc= ussion on a few points in the meantime. The .well-known registration for /servicedocument has a use case/discovery = story that we feel is important enough for registration, or at least for st= andardization. In the case where there is no standardized location template= for the service document, a vendor/company/site that wants to stand up a R= OLIE repository and provide regular syndicated information must provide a l= ink to the service document somewhere on their regular site, or otherwise d= istribute the URL. While this potentially provides a means for humans to fi= nd the repository (although the link would likely be hidden in some strange= place), it doesn't help automated tools locate the repository. As a user of ROLIE, I'd like to be able to provide a tool with the hostname= :port of a vendor whose syndicated information I'd like to receive, and hav= e the tool return the status of any repository that is or in not hosted by = that top level site. For example, I'd like to give a tool "www.microsoft.co= m" and have it provide me all the ROLIE (and non-ROLIE AtomPub if provided = in the same ServDoc) Collections provided by that host. Without a .well-kno= wn registration, the standard would have to provide a defined non-/.well-kn= own URL template location, which we felt was bad practice. Its likely that the standard doesn't provide enough context around the /.we= ll-known registration, and that adding more explanatory text around our dis= covery story would help make the need for a URL template more clear. If the issue is with the use of /.well-known, and not with the standardized= URL template, we could simply remove the .well-known registration and inst= ead provide a non-registered requirement for a {host}/rolie/servicedocument= URL template. We agree that the discovery story for /categorydocument is decidedly weaker= , as any out-of-line category documents would be linked to from the Service= Document. We would open to dropping this registration/requirement outright= as you suggest. Thanks again for the thorough review, Stephen Banghart > -----Original Message----- > From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Martin Thomson > Sent: Monday, October 09, 2017 1:08 AM > To: art@ietf.org > Cc: mile@ietf.org; ietf@ietf.org; draft-ietf-mile-rolie.all@ietf.org > Subject: [mile] Artart last call review of draft-ietf-mile-rolie-10 >=20 > Reviewer: Martin Thomson > Review result: Almost Ready >=20 > I have reviewed this document, and - despite what appears to be a lengthy > list of issues - I think that it is in pretty good shape. It's clear, re= adable, and > addresses the requirements well. Most of my comments should be trivial t= o > resolve. >=20 > Major: >=20 > The decision to define a .well-known URI without a discovery story is - i= n my > opinion - inadvisable. Such a registration is usually appropriate if you= design a > protocol that depends on discovery by hostname and port. As such, this > does not use that at all. A configuration system can (and should) accept= a > complete URI for the service endpoint. It would be better to defer creat= ion > of yet another .well-known URI registration until the working group is ce= rtain > that discovery requires it. >=20 > The same comment applies to the .well-known resource for the category > document. > Given that this sort of document is readily discoverable via the service > document, I would say that the need for a .well-known resource is less we= ll- > justified than the service document. >=20 > The requirements in Section 5.3 on TLS use are unnecessarily strict. It'= s great > to recommend the use of TLS 1.2, but given that the document has no real > requirement on any particular version of TLS, the use of "MUST" here is n= ot > needed. Similarly, the prohibition on the use of 0-RTT is groundless. T= he > lengthy list of requirements around certificate validation only risk crea= ting a > conflict with advice in other RFCs. Many, if not all, of these requireme= nts are > transitively included by way of referencing HTTPS documents. I would pre= fer > to see this entire section reduced to a simple RFC 7525 reference. >=20 > User authentication is under-specified. >=20 > * Section 5.3 mandates the use of TLS cipher suites that support client > authentication using certificates, but offers no further advice. Aside f= rom > being an unnecessary requirement - cipher suites that support certificate= - > based authentication of servers all allow for client authentication - thi= s sort of > requirement is rarely sufficient for interoperation. For instance, you n= eed to > specify how a server will request a certificate such that clients can sel= ect the > correct certificate. If a client and server have agreed to share informa= tion on > terms that rely on authentication of clients, it is better for those peer= s to > arrange the terms on which they will authenticate. >=20 > * Section 5.4 uses "SHOULD" regarding client authentication using federat= ion, > but offers no hints about what this entails. It also uses "SHOULD" regar= ding > authorization checks, which isn't an interoperability requirement. It's = more > of a "don't be silly" type of requirement, which doesn't need to be writt= en > down in an RFC. >=20 > Section 5.5 prohibits the use of GET on "/". This prohibits use of the r= esource > for other purposes. It seems reasonable to accept POST messages as > defined in RFC 6546, but this requirement is overly strict (and further > entrenches the violation of RFC 7320). If, for instance, the server oper= ator > wishes to provide HTML in response to a GET request to "/", this would > prohibit that. The requirement to return 404 if RFC 6546 is not supporte= d is > worse; not supporting RFC 6546 might be a choice that a deployment makes > to avoid the need to reserve "/" for that protocol. >=20 > In Section 6.2.3, what is the advantage of "rolie:format" over having a w= ell- > defined media type? Media types can take advantage of content > negotiation, existing support in link relations, and other existing tools= . > This rolie:format element has namespace, format, and schema; these are no= t > useful to anyone that is ignorant of their contents. The only advantage = I see > is that syntax might be validated, but semantics can't be extracted. The= re's a > lot of implied work in adding this element, but that doesn't seem to be > justified by that advantage. (I see that RFC 7970 doesn't define a media= type, > but it seems like it would be easier to correct that than to define an el= ement > like this.) >=20 > Section 6.2.4 defines a generic key-value mechanism. But that is somethi= ng > that XML is actually good at. Why can't users that require additional > metadata use additional metadata as originally defined by Atom? That is, > replace value=3D"12345"/> with something like > 12345. The final paragraph = of the > section recognizes this possibility. >=20 > Minor: >=20 > Section 5.1.1 recommends the use of workspaces to separate "private" and > "public" information. But workspaces don't really contain enough > information to signal their status to a consumer of the information. I w= ould > suggest mentioning this, removing the recommendation, or expanding on > the manner in which the status of information is signaled. >=20 > Section 6.1.1 says "zero or more atom:category elements", but this > contradicts the text and amendment to the schema in Section 6.1. >=20 > Section 6.1.3 requires updating the "atom:updated" element when the > representation changes. I don't think that this is what was intended. I= think > that the element needs to be updated when the contents of the feed > change in any way. >=20 > Question: it's fairly widely accepted that use of IRIs in Atom has been l= ess > than successful. Do you want to mandate use of URIs instead? This would > apply to both link relations and the "src" attribute. >=20 > In Section 7.1, the definition of the namespace prefix > "urn:ietf:params:rolie:category:local" seems unnecessary. Namespace URIs > are cheap and it seems reasonable to experiment with feeds that produce > non-ROLIE information by omitting the > "urn:ietf:params:rolie:category:information-type" > category, even if that feed might comply with the requirements of ROLIE. > The other way to experiment would be to use the category, but define a wa= y > to identify "term" attributes that are for use in private or experimental > contexts. >=20 > In Section 7.4, how is "...:rolie:property:content-author-name" superior = to > "atom:author"? >=20 > In Section 8.4, is there a uniqueness requirement on "name"? I understa= nd > this to be the thing that being registered. Assuming that, what purpose > does > the "index" serve? >=20 > This statement from Section 9, "As described in the discovery section, DN= S > SRV Records are a possible secure solution to discovery." is false withou= t > further qualification. SRV with DNSSEC might be secure, but a lot depend= s on > the input to the discovery process and its provenance. >=20 > In Section 10, the following statement is false (all of the described pri= vacy > violations are available to a client or server, not third parties): "Prop= er usage > of TLS as described in Section 5.3 will in many cases aid in the mitigati= on of > these issues." I think that you can strike this statement (most of the r= eason > for use of TLS is justified by the security considerations anyway). >=20 > Nits: >=20 > Is it "Feed" or "feed"? RFC 4287 uses the latter, but this document seem= s to > prefer the Proper Noun form. >=20 > Section 6.2 should say what changed in the schema. It's hard to eyeball = the > schema to discover that "atomContent" is no longer optional. The two new > elements are easy to spot and might cause the first change to be missed. >=20 > Section 6.2.1 is the same. It should explicitly say that it only permits= the > atomOutOfLineContent formulation. >=20 > I found the formulation of Section 7.1.1 confusing. It includes a list t= hat > seems to be authoritative, then disclaims any attempt to register these > terms. > Maybe this is because the statement "This document does not specify any > information types." appears too late. Some reordering might help. >=20 > The formatting of the table in Section 8.3 makes most of the columns > unreadable. I would recommend a simple nested list. >=20 > In section 9, the use of the term "well-known" to refer to information th= at is > either public or widely available risks misinterpretation. >=20 > FWIW, I would reword this entire paragraph to say simply "Access control = to > information published using ROLIE should use mechanisms that are > appropriate to the sensitivity of the information. Primitive authenticat= ion > mechanisms like HTTP Basic Authentication [RFC7617] are rarely appropriat= e > for sensitive information." I didn't find the remainder of the text on > authentication especially helpful. The text seems to equivocate on the > subject of federation, where it would be easier to say nothing. >=20 > Also in Section 9, the use of the term "message" is used in the context o= f > using additional security controls. I think that the word "representatio= n" is > what was intended here. >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i > etf.org%2Fmailman%2Flistinfo%2Fmile&data=3D02%7C01%7Cstephen.banghar > t%40nist.gov%7Caf3af91a1c684592007d08d50ed3d401%7C2ab5d82fd8fa4797 > a93e054655c61dec%7C1%7C0%7C636431225322845891&sdata=3DSykEasQlo1e > MarYmKXSA5HsOUpTLyjd9rslyvZPpxak%3D&reserved=3D0