From nobody Mon Jun 1 05:26:07 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A051A88C8; Mon, 1 Jun 2015 05:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzCuCaLbeF21; Mon, 1 Jun 2015 05:26:00 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EAB21A1AD9; Mon, 1 Jun 2015 05:26:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 943AEBEB5; Mon, 1 Jun 2015 13:25:58 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2U9M2RWxNwq; Mon, 1 Jun 2015 13:25:55 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.31.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 88A96BE3F; Mon, 1 Jun 2015 13:25:55 +0100 (IST) Message-ID: <556C4F53.1040702@cs.tcd.ie> Date: Mon, 01 Jun 2015 13:25:55 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, 'Charlie Kaufman' References: <554CAAE8.9090800@pi.nu> <5564375E.9060306@pi.nu> <00b601d09a41$58cdd2e0$0a6978a0$@olddog.co.uk> In-Reply-To: <00b601d09a41$58cdd2e0$0a6978a0$@olddog.co.uk> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org, mpls@ietf.org, mpls-chairs@tools.ietf.org, 'secdir' Subject: Re: [secdir] [mpls] FYI - Early review of draft-farrelll-mpls-opportunistic-encrypt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 12:26:04 -0000 Hi Charlie, I've finally gotten around to the detail of this as we get ready to shoot out a -05 addressing the mpls review team comments and your security review. (And thanks to you and the mpls-rt folks for the good comments.) On 29/05/15 19:57, Adrian Farrel wrote: > Charlie, > > Thanks for this. Forgive me for stumbling through the security aspects: I'm sure > Stephen will pick me up on whatever I get wrong. > >> All-- >> Draft-farrelll-mpls-opportunistic-encrypt-04 specifies the details of a >> protocol for doing opportunistic encryption of MPLS connections. It permits >> encryption at any of two scopes: between adjacent Label Switching Routers >> (LSRs) on an MPLS Label Switched Path (LSP), and/or between end points of an >> LSP. Opportunistic encryption in this case means that there is no mechanism >> specified for authenticating the endpoints of the encrypted channel. The two >> endpoints do an anonymous Diffie-Hellman exchange and use the resulting key >> to encrypt the connection. The protocol is not protected from a >> man-in-the-middle attack (though some mechanisms for detecting such an >> attack after the fact are suggested and a keying infrastructure could be >> added later). >> >> The encryption aspects of the protocol seem well thought out and >> appropriate. The question at hand is whether to adopt this document as a >> working group document and it easily meets that bar (at least from a >> security standpoint). I have a number of questions about operational aspects >> of the protocol (perhaps due to my limited understanding of MPLS) and I have >> some suggestions for enhancements that will probably be necessary eventually >> and might be easier to make before there is widespread deployment: >> >> There is an issue that came up in the design of IKEv2 that may be an issue >> here as well. I don't know whether MPLS connections are bi-directional or >> whether separate connections need to be established in the two directions. >> >> If they are bi-directional, then there are race conditions that can occur if >> both ends attempt to initialize a connection simultaneously and there must >> be some tie-breaking mechanism to assure that exactly one of the connection >> attempts succeeds. If they are uni-directional, and if the connection is >> always initialized by the sending end, then this is not a problem (though it >> is replaced with the problem that messages of this protocol sent in the >> reverse direction cannot be tunneled over the MPLS connection). (This >> document seems to imply that MPLS connections can be either uni-directional >> or bi-directional, but I don't understand MPLS well enough to have >> understood it). Even if the connections are bi-directional, it will make >> your life simpler if you use different symmetric keys in the two directions. >> This can be done easily by getting two independent keys from the key >> expansion process. > > Right. LSPs may be unidirectional or bidirectional. > > Section 4 and particularly 4.3 describe how the return path is selected for the > case of a unidirectional LSP. > > So we have four questions: > > 1. Is the return path secure? > 2. Who initiates the use of OS? > 3. How do we handle race conditions? > 4. Should we have different keys in different directions? > > In fact, the key exchange does not itself need to be secure, but it would be > better if it was. 4.2.1 and 4.4 say how to do this if possible, but notes it > will likely not be possible in the case of OS. So that's Q1. > > In the case of a unidirectional LSP, only the source node (i.e. upstream from > the perspective of data flow) can be the initiator for the key exchange because > the key exchange requires the use of a message flowing on the LSP itself. So, > for Q2 we only have to worry about bidirectional LSPs, and that takes us to Q3. > > But, in fact, a bidirectional LSP is in fact (from the point of view of the > forwarding plane) the association of two unidirectional LSPs. The association > may be so tight (in the control plane or the management plane, and with fate > sharing) that the LSP is referred to as *a* single bidirectional LSP, but that > doesn't change the forwarding plane behavior. And, indeed, in the bidirectional > case, there is no reason to not have encryption in one direction and not in the > other direction (except, of course, that more is better :-). So that means that > each direction of the bidirectional LSP is responsible for initiating its own > OS. > > Hence Q3 is not a problem, and Q4 takes care of itself. > > We should definitely clarify this in the draft (and thank you for making me > describe it here), but I'd like some more discussion with the WG to check I am > right about this. Yep, some more mpls-clue would help me on the directionality thing too, but I think Adrian's answers are good. In particular, regardless of all else, we will definitely not end up allowing the same symmetric key in both directions as that would permit reflection attacks. The current version doesn't have that bad properly and I'll make sure that we don't introduce it. To be complete: I think the LSP ID is different for both directions and that is an input to the KDF, as are the LSR IDs whose order will differ. So I don't think we can currently end up with the same symmetric key used in two directions with the current draft. > >> A second issue relates to algorithm negotiation. While the protocol allows >> for any of the crypto algorithms to be replaced, and the algorithms are >> indicated on the wire, it does not appear to allow for a smooth upgrade >> where the two ends are updated independently and everything must continue >> to work when only one end has been updated. To accomplish that, there >> should be an algorithm negotiation (as takes place in IKE and TLS) where one >> end presents a list of algorithms is can support and the other end chooses the >> algorithms it prefers. A simpler variation would be for a responder to be >> able to reject the algorithms assumed by the initiator and send back a list >> of algorithms it will accept. Note: it's possible that MPLS already operates >> with the restriction that the two ends of a connection must be consistent >> and operations will halt if the two ends are updated non-simultaneously. If >> that's true, then adding crypto doesn't make the situation any worse and it >> would be acceptable to continue to operate that way. > > I'm so far from being an expert in this matter that I am probably making a fool > of myself (again), but is algorithm replacement actually any different from key > change? That is, the key negotiation protocol negotiates the key and algorithm > to use and so can also negotiate changes in both key and algorithm. > > Section 4.2.3 mentions this, but is exceptionally week. I'll add some text > (assuming what I just wrote is not complete lunacy). > The key ID identifies the key and the algorithm in one field, so being able to > change the key ID was intended to also allow changing the algorithm. Right, we are here assuming that any algorithm negotiation is done via some management system that is not defined by the basic mechanism, i.e. not here. I think that's reasonable as that same management system would be the place where someone decides whether and when to try use OS, so handling those aspects of algorithm agility at that stage seems better. It's probably also worth noting that since the symmetric crypto here is very likely to have to be in h/w for performance reasons, this is not quite the same as cases where a s/w update might introduce a new algorithm nor is it that likely that a single node supports many algorithms given the fairly severe performance constraints that apply, i.e. line rates of N x 10G generally. >> A possible problem with Key Identifiers: the Key Identifier is only 4 bits >> long, which should be sufficient because at most two keys should be active >> at any given time. The Key Identifier, however, is chosen effectively >> randomly, which means that one time in 16 it will be the same as the Key >> Identifier it is replacing. While the protocol could be modified to do >> something special in that last (like adding one to the Key Identifier if it >> matches the previous value or redoing the key negotiation in that case), it >> would probably be better to get the Key-ID from the key expansion when >> there is no previous connection and add one (mod 16) when rekeying. > > Yes, I had assumed that if the key ID was reselected then some form of secondary > choice would be made. Not sure that the predictability of simply adding one is > good idea (not that I can think of specific associated risk). Yep, adding one (mod 16) until no more collision or throwing an error if all 16 are used already or similar is needed. I've added that. > >> There is mention of the possibility of reusing g^i and g^r between >> connections. Some crypto purists would object to that, but I wouldn't. If >> you want to allow implementations that option, however, you should also >> include in the exchange nonce values Ni and Nr that are not reused between >> connections rather than depending on unique values for the other parameters >> to prevent reuse of keys. > > Ah, hmm, OK. > Stephen? > Help! Sure. For now, I added a RECOMMENDATION to use fresh i & r every time and a ref to RFC4086. I think the recommendation should stay the same as we don't ever need to do loads of key agreements in a hurry afaik. But the phrasing of that may change e.g. if we adopt Curve25519 later or if CFRG or the TLS WG produce guidance on re-use of DH public values that's more detailed. (The most common case of such re-use for TLS I think so I'd expect better guidance on this to come from TLS1.3 or CFRG, and we should just point at whichever of those is best as we go along.) > >> In section 3.5 (MTU considerations), I suspect you may be underestimating >> the effect on MTU. I believe AES_GCM_128 always adds between 1 and 16 pad >> bytes to make the encrypted payload size a multiple of 16 bytes. There are >> algorithm variants that do not add any padding, but they are somewhat >> controversial and difficult to implement in hardware. Further, the total >> overhead will be dependent of the crypto algorithm chosen, and the text >> should indicate that so that readers don't assume that there is some maximum >> number of bytes that can be wired into protocols that run above this. > > That's helpful. > Stephen, I need you to help with this. For our initial MTI, I believe we need to pick the same symmetric cipher and mode that is already supported by h/w that is used for MACsec as that exists, meets the performance requirements and is at least somewhat deployed. That implies that the overhead is probably only as much as problem as it already is for MACsec, since we're just changing the layer that sees that overhead. If one runs this and MACsec there could be fun though, yes. In any case, we do note the data expansion so the WG and implementers will deal with that as we go. I do not think we'd be wise to try to be innovative here with modes of operation, at least not at first. And if new modes with better properties do turn out to be needed, that could be defined later on. > >> I would suggest that most or all of sections 5 and 7 should be moved to >> Security Considerations. Failing that, the Security Considerations section >> should reference them. > > Thanks. Since 5 is growing, I've put back pointer from 6. > 7.1 is already referenced from 6.2 and 6.3 Yep, I think we'll need to do some editorial surgery later as we accumulate new bits and pieces of text. The same is true for the introductory material in section 2 - given we've now published RFC7435, a lot of that should probably disappear before we're done. (But is worth keeping for now probably.) Thanks again for the review. Cheers, Stephen. PS: Adrian and I are nearly done on a -05 version reflecting all these reviews. > >> Typos: >> >> P4: "and if may be advisable" -> "and it may be advisable" >> P4: "an alternative key derivation functions" -> "alternative key derivation >> functions" >> P5: "key definition function" -> "key derivation function" >> P5: "attck vecotrs" -> "attack vectors" >> P5: "descirption" -> "description" >> P19: "opostie" -> "opposite" > > Good. > > vmt > Adrian > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From nobody Mon Jun 1 10:29:57 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07331B2F80; Mon, 1 Jun 2015 10:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKMtLfGnHMUX; Mon, 1 Jun 2015 10:29:43 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF78E1B2F8C; Mon, 1 Jun 2015 10:29:42 -0700 (PDT) X-AuditID: 12074423-f79496d000000d43-b6-556c96853581 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id EA.55.03395.5869C655; Mon, 1 Jun 2015 13:29:41 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t51HTeCV008714; Mon, 1 Jun 2015 13:29:40 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t51HTbIg011132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Jun 2015 13:29:38 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t51HTaqi003812; Mon, 1 Jun 2015 13:29:36 -0400 (EDT) Date: Mon, 1 Jun 2015 13:29:36 -0400 (EDT) From: Benjamin Kaduk To: "Carlos Pignataro (cpignata)" In-Reply-To: <5C38EDAD-2CAC-485B-B488-51819FAAFC81@cisco.com> Message-ID: References: <20150524211041.52cde768@latte.josefsson.org> <02FCDA94-FCC3-4875-AFBE-D07CC792B0C9@cisco.com> <2DB7995B-8AF1-4EEE-971E-40A1A6294461@cisco.com> <53F5D306-5860-4415-8AA4-390882ED94AB@cisco.com> <5C38EDAD-2CAC-485B-B488-51819FAAFC81@cisco.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-568848066-1433179776=:22210" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRmVeSWpSXmKPExsUixG6nots6LSfUYOF0VYtP73awWNz4dJvZ YsaficwWHxY+ZLG4t+USuwOrx5TfG1k9liz5yeQx88xFdo8vlz+zBbBEcdmkpOZklqUW6dsl cGVsW7GFtWCWSsWOJYuZGxgvy3QxcnJICJhIXH3xmQXCFpO4cG89WxcjF4eQwGImiY3HNrNC OBsYJaZvn8oM4Rxkkrj46D4TSIuQQL3E31UtYO0sAloSTW9XgNlsAioSM99sZAOxRQTMJBof T2ICaWYWeMIocbrvCGMXIweHsICdxPcJKiA1nAK2Ei1vpoDV8wo4Ssyb8YYdYlkHi8StSy2M IAlRAR2J1funsEAUCUqcnPkEzGYWCJD4M+UF2wRGwVlIUrOQpCBsdYnGB2ehbG2J+zfb2BYw sqxilE3JrdLNTczMKU5N1i1OTszLSy3SNdPLzSzRS00p3cQIjgcX5R2Mfw4qHWIU4GBU4uHN 6M4OFWJNLCuuzD3EKMnBpCTKazApJ1SILyk/pTIjsTgjvqg0J7X4EKMEB7OSCK9sE1CONyWx siq1KB8mJc3BoiTOu+kHX4iQQHpiSWp2ampBahFMVoaDQ0mCN3AqUKNgUWp6akVaZk4JQpqJ gxNkOA/Q8BiQGt7igsTc4sx0iPwpRkUpcV5BkIQASCKjNA+uF5auXjGKA70izJsMUsUDTHVw 3a+ABjMBDW4XABtckoiQkmpgNDnN/jtINXN31M+FUnP6GbIVxZsyvlbyzQtcrr3+y9UuGQ1J 2TPXYh34eb6Xf2u24dO4+82V4Wu3mZ9Iqf+upEWBU4t4r/xfKVQ4+8BTQbVPV6tfabb6hEzv Cbr+PvMF36UPcYyX7X4ESaclGcsFL5AMP5V58lXxcSkll0SVjavjsjk3SAQosRRnJBpqMRcV JwIAa7LzBDIDAAA= Archived-At: Cc: "secdir@ietf.org" , "draft-ietf-sfc-architecture.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 17:29:48 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-568848066-1433179776=:22210 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Carlos, Sorry for the delayed reply. On Thu, 28 May 2015, Carlos Pignataro (cpignata) wrote: > Ben, > > > On May 28, 2015, at 12:24 AM, Benjamin Kaduk wrote: > > > > On Wed, 27 May 2015, Carlos Pignataro (cpignata) wrote: > > > >> Ben, > >> > >>> On May 27, 2015, at 2:16 PM, Benjamin Kaduk wrote: > >> > >> What changes the flow of data in the network (i.e., direct user traffi= c > >> to the =E2=80=98remote machine=E2=80=99 (as you called it) is the over= lay =E2=80=94 that is why > >> in the =E2=80=9CService Overlay=E2=80=9D section of the Security Consi= derations we have: > >> > >> and can also include authenticity and integrity checking, and/o= r > >> confidentiality provisions. > >> > >> The use of the SFC Encapsulation is for SFP encapsulation and metadata= sharing. > > > > Now that you have pointed me at it, I do see how you feel that the issu= e > > is already covered. Let me see if I have any suggestions for new text > > that would not have required you to point me at it in order for me to s= ee > > it. > > > > OK. > > > One thing that comes to mind would be to add a clause at the end of the > > sentence to reiterate what data is being protected. It is late here, s= o I > > have confused myself as to whether that should be "for both the traffic > > being forwarded and its encapsulation" or just "for the traffic being > > forwarded=E2=80=9D. > > I can add =E2=80=9C, for both the network overlay transport and traffic i= t > encapsulates=E2=80=9D at the end of that sentence? Or "for both the traff= ic > being forwarded and its encapsulation=E2=80=9D as well. I thought this wa= s > understood, however. I think that either of those would improve the clarity, thank you. > > It seems like it would also be helpful to spend another clause or sente= nce > > expounding how the security requirements of the specific SFC deployment > > are determined -- perhaps, "These security requirements will depend bot= h > > on the structure of the network where SFC is being deployed and the > > details of the protocol implementing the SFC architecture; the security > > assessment should consider potential threats from both inside and outsi= de > > the network." That's probably overkill, but is perhaps illustrative. > > To me, it is closer to overkill, but I would not oppose if you very > strongly feel it adds value, even if merely illustrative. I do not feel very strongly. This was just me attempting to brainstorm for places that new text could have made the document more clear; I wanted to include some concrete text as part of the brainstorming, to help make clear my thought process. I was definitely not expecting you to include the whole thing verbatim -- maybe some pieces of it, or maybe none of it at all, if you don't think it is needed (which seems to be the case). > >>>> =E2=80=9CReevaluated=E2=80=9D is significantly better, of course. He= re=E2=80=99s another proposal: > >>>> > >>>> "The architecture described here is different from the current model= , and > >>>> moving to the new model could lead to different security arrangement= s and > >>>> modeling. In the SFC architecture, a relatively static topologically= -dependent > >>>> deployment model is replaced with the chaining of sets of service fu= nctions. > >>>> This can change the flow of data through the network, and the securi= ty and > >>>> privacy considerations of the protocol and deployment will need to b= e > >>>> reevaluated in light of the model.=E2=80=9D > >>> > >>> I might add in "new" or "chained" before the very last "model", but t= his > >>> seems to catch the sentiment I was going for. > >> > >> Either =E2=80=98chain=E2=80=99 or =E2=80=98new=E2=80=99 univocally dis= ambiguates =E2=80=98model=E2=80=99 =E2=80=94 sure. > >> > >>> The idea would be to insert > >>> this as a new paragraph after the first paragraph of section 6? > >>> > >> > >> Yes, or as the first paragraph of Section 6, as a preamble to the sect= ion. Either. > > > > Sounds good. > > Done. Thanks. Thanks for all these updates; I think they go a long way to addressing the concerns that were raised during the secdir review. -Ben ---559023410-568848066-1433179776=:22210-- From nobody Mon Jun 1 10:40:56 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D881B2FCA; Mon, 1 Jun 2015 10:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FPAtB9GHSGR; Mon, 1 Jun 2015 10:40:53 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80F51A702E; Mon, 1 Jun 2015 10:40:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6140; q=dns/txt; s=iport; t=1433180451; x=1434390051; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YWVYiQDwZCB8jwpDR6aU5zSPDt2fEZJvVMMDJhhpBos=; b=Q80iU+jzVZc9qhmR8ae/SVCUvmzWOaTYsB9VpQkNtzaN5mMrzlMhgUy/ TWhiu1EnMg/y5058fvXKXGKindx//QYb41ZquHj0a0/ZU0V0dQocLFi5U y2hmm3gIX5NhkZT6tDzqiU5jdAAHx7Sf9VyA7hXJa57umRlwuLHtgANNt 8=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BzBADbl2xV/5JdJa1cDoI3S4EyBoMYulhmCYdRAoE1OBQBAQEBAQEBgQqEIgEBAQMBI1YFCwIBCBIGKgICMhcOAgQOBQ6IFwi0V6N0AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tDhQYHgmgvgRYBBJMQghKBQ4dBlzgjgzo+b4FGgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,534,1427760000"; d="asc'?scan'208,217";a="155382437" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP; 01 Jun 2015 17:40:50 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t51HeouE001079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Jun 2015 17:40:50 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.166]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Mon, 1 Jun 2015 12:40:50 -0500 From: "Carlos Pignataro (cpignata)" To: Benjamin Kaduk Thread-Topic: [secdir] Review of draft-ietf-sfc-architecture-08 Thread-Index: AQHQllVoiI0EciI2k0ypB2MTIDGLzJ2L5tT3gAIA+oCAAJkTAIAAwU8AgAEfd4CAABfhgIAACmqAgACfqICAANu8gIAGSOAAgAADIwA= Date: Mon, 1 Jun 2015 17:40:49 +0000 Message-ID: <425B92F1-E4B7-4395-9EA2-93420A93D935@cisco.com> References: <20150524211041.52cde768@latte.josefsson.org> <02FCDA94-FCC3-4875-AFBE-D07CC792B0C9@cisco.com> <2DB7995B-8AF1-4EEE-971E-40A1A6294461@cisco.com> <53F5D306-5860-4415-8AA4-390882ED94AB@cisco.com> <5C38EDAD-2CAC-485B-B488-51819FAAFC81@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.61] Content-Type: multipart/signed; boundary="Apple-Mail=_8066F191-7E7E-4037-B1D5-BB1D3BC2D06F"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "secdir@ietf.org" , "draft-ietf-sfc-architecture.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] Review of draft-ietf-sfc-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 17:40:54 -0000 --Apple-Mail=_8066F191-7E7E-4037-B1D5-BB1D3BC2D06F Content-Type: multipart/alternative; boundary="Apple-Mail=_CD6E4C1A-D05E-401C-A370-22497E7DBC4E" --Apple-Mail=_CD6E4C1A-D05E-401C-A370-22497E7DBC4E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 1, 2015, at 1:29 PM, Benjamin Kaduk wrote: >=20 >> Done. Thanks. >=20 > Thanks for all these updates; I think they go a long way to addressing = the > concerns that were raised during the secdir review. >=20 Many thanks to you, Ben, for the thorough review and subsequent = dialogue, which most definitely improved the document. Thanks, =E2=80=94 Carlos. > -Ben --Apple-Mail=_CD6E4C1A-D05E-401C-A370-22497E7DBC4E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 1, 2015, at 1:29 PM, Benjamin Kaduk <kaduk@MIT.EDU> = wrote:

Done. Thanks.

Thanks for all these updates; I think they go a = long way to addressing the
concerns that were raised = during the secdir review.


Many thanks = to you, Ben, for the thorough review and subsequent dialogue, which most = definitely improved the document.

Thanks,

=E2=80=94= Carlos.

-Ben

= --Apple-Mail=_CD6E4C1A-D05E-401C-A370-22497E7DBC4E-- --Apple-Mail=_8066F191-7E7E-4037-B1D5-BB1D3BC2D06F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIbBAEBCAAGBQJVbJkhAAoJEIXgpQGOZny9jVIP+L+ngF50Tbq0GU6d7gurrU+P fw9us9qmO2UHpPe+Sy6NpS2FiVacMk8i00T9T4rrC5lSU2zN2k2+fILD2bQLIZXv jnB9ymNkD4I3uO/uVfcmcDaWf7fShTOq7PctVoMa3JpOQSVtTvFPCmldmGAw7+yS oVn0WiXAZPP5z4D0J2KDtBIL+6ERWK8m3RbNKuvzjARYHWMBkwdq4RgsOqItD5Sp QYtlmWySTwxwWhj+uyCl34ou6O6P/8WYFj+R2y2bgQSe+THpCeN13KeJBJkCaMGG hraC0fRQ5C3UPHjsBlnWI9zpvORayDxyvgNo/rUS2XIUbfl0aVNjsLm7nY32OKXS lwvf8vArHWukyF3PhXiXZjlqmceY/yyk+gIC0bI98+WHfyHrAhyoorn3u7Y6mWaT ldG5PLYN8brjOqEBKXgP+hCqFZpRPPaxmhxrCf4RSB847acs5twDB1FLdjXdIip4 MQDLY74n/dEr1Ytt7bCuK847ms5Tm6PlgnMYHbvNWLVvx3KD4ygOprxd5/J6LVUE gblcB6uEY7lxdwpsSfo3xCIu4fEW79xE8HbqgusKNJ057/W3BDIEn5h/ZKq4Y5B6 yjBhsw38jJU50ZdOpn2oiP5IASGjInIgACjZim9KcXemYZYFipcfBBYPwVQCX365 iguS5OYh0qStC7hA6aQ= =CIRq -----END PGP SIGNATURE----- --Apple-Mail=_8066F191-7E7E-4037-B1D5-BB1D3BC2D06F-- From nobody Mon Jun 1 12:06:06 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDEB11B31A4 for ; Mon, 1 Jun 2015 12:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuI7HqMFTmuD for ; Mon, 1 Jun 2015 12:06:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEC241B3229 for ; Mon, 1 Jun 2015 12:05:29 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:54723 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YzV1Q-0005PB-V9; Mon, 01 Jun 2015 15:05:17 -0400 Message-ID: <556CACEC.2030501@bbn.com> Date: Mon, 01 Jun 2015 15:05:16 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: secdir , ietf@justin.richer.org, derek@ihtfp.com, Hannes Tschofenig Content-Type: multipart/alternative; boundary="------------030106030509090506080205" Archived-At: Subject: [secdir] review of draft-ietf-oauth-introspection-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 19:06:04 -0000 This is a multi-part message in MIME format. --------------030106030509090506080205 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written with the intent of improving security requirements and considerations in IETF drafts.Comments not addressed in last call may be included in AD reviews during the IESG review.Document editors and WG chairs should treat these comments just like any other last call comments. This document describes an API for use with OAuth 2.0. The API enables the recipient of a token to query an authorization server to determine the set of metadata presented to the server (by the OAuth client) when the token was issued. This API is intended to overcome the lack of a standard way to convey token metadata in the OAuth 2.0 context. I didn’t find any significant security problems with the document, but there are a number of places where the exposition needs improvement. Specific comments Section 2 The text says: The introspection endpoint MUST be protected by a transport-layer security mechanism as described in Section 4. It might be clearer to say here that the token endpoint MUST communicate security with the introspection endpoint, and that TLS 1.2 is the mandatory-to-implement mechanism for such security. Also, the text should be clearer about the relationship between an authorization server and an introspection endpoint. In some places the two terms seem to be used interchangeably. Section 2.1 The texts says: The endpoint MAY allow other parameters to provide further context to the query. How about: The endpoint MAY *accept* other parameters to provide further context to the query. How does a protected resource know which other parameters an introspection endpoint requires/accepts? This section mandates (MUST) protection against “unauthorized token scanning” but mandates no standard way to do so. [Also, when would a scanning “attack” be authorized ;-)] The text says: For example, the following example shows a protected resource calling the token introspection endpoint to query about an OAuth 2.0 bearer. How about: For example, the following example shows a protected resource calling the token introspection endpoint to query about an OAuth 2.0 bearer *token*. Section 2.2 He text says: The authorization server MAY respond differently to different protected resources making the same request.For instance, an authorization server MAY limit which scopes from a given token are returned for each protected resource in order to prevent protected resources from learning more about the larger network than is necessary for their function. How about: *An*authorization server MAY respond differently to different protected resources making the same request.For instance, an authorization server MAY limit which scopes from a given token are returned *to* each protected resource in order to prevent *a *protected resources from learning more about the larger network than is necessary for *its* *operation*. Section 3.1 Experience suggests a longer review period is appropriate, e.g., to accommodate holidays, vacations, etc. The text says: IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list. How about: IANA *MUST* accept registry updates *only* from the Designated Expert(s) and *SHOULD* direct all requests for registration to the review mailing list. Section 3.1.1 If a proposed Name matches one already registered as per 7519, ought it not have an “equivalent” (vs. “comparable”) definition if it is to be accepted? Section 4 The text lists four checks to be performed by an authorization server, yet the introduction to this list says “For instance:” A more normative introduction would seem appropriate here. I realize that the text says that not all of these checks may be applicable in all OAuth 2.0 contexts, but since each check begins with “If the token …” isn’t that a sufficient caveat? The text says: If an authorization server fails to perform any applicable check, the resource server could make an errant security decision based on that response. How about: If an authorization server fails to perform any applicable check, the resource server could make an *erroneous* security decision based on that response. The text says: per RFC 6125 [RFC6125]. How about: as specified in [RFC6125]. The discussion of introspection endpoint response caching seems to omit a simple, useful heuristic. Since the expiration time for a token is an optional parameter in the response, why not say that IF this parameter is present, the response MUST NOT be cached beyond that time? Section 5 This section says: “One way to limit disclosure is to require authorization to call the introspection endpoint and to limit calls to only registered and trusted protected resource servers.” But Section 4 says: “… the authorization server MUST require authentication of protected resources that need to access the introspection endpoint and SHOULD require protected resources to be specifically authorized to call the introspection endpoint.”It seems that the requirement imposed in Section 4 already mandate what is merely suggested in Section 5. --------------030106030509090506080205 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving security requirements and considerations in IETF drafts.  Comments not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

 

This document describes an API for use with OAuth 2.0. The API enables the recipient of a token to query an authorization server to determine the set of metadata presented to the server (by the OAuth client) when the token was issued. This API is intended to overcome the lack of a standard way to convey token metadata in the OAuth 2.0 context.

 

I didn’t find any significant security problems with the document, but there are a number of places where the exposition needs improvement.

 

Specific comments

 

Section 2

 

The text says:  

 

The introspection endpoint MUST be protected by a transport-layer security mechanism as described in Section 4.

 

It might be clearer to say here that the token endpoint MUST communicate security with the introspection endpoint, and that TLS 1.2 is the mandatory-to-implement mechanism for such security. Also, the text should be clearer about the relationship between an authorization server and an introspection endpoint. In some places the two terms seem to be used interchangeably.

 

Section 2.1

 

The texts says:

 

The endpoint MAY allow other parameters to provide further context to the query. 

 

How about:

 

The endpoint MAY accept other parameters to provide further context to the query. 

 

How does a protected resource know which other parameters an introspection endpoint requires/accepts?

 

 

This section mandates (MUST) protection against “unauthorized token scanning” but mandates no standard way to do so. [Also, when would a scanning “attack” be authorized ;-)]

 

 

The text says:

 

For example, the following example shows a protected resource calling the token introspection endpoint to query about an OAuth 2.0 bearer.

 

How about:

 

For example, the following example shows a protected resource calling the token introspection endpoint to query about an OAuth 2.0 bearer token.

 

 

Section 2.2

 

He text says:

 

   The authorization server MAY respond differently to different

   protected resources making the same request.  For instance, an

   authorization server MAY limit which scopes from a given token are

   returned for each protected resource in order to prevent protected

   resources from learning more about the larger network than is

   necessary for their function.

 

How about:

 

   An authorization server MAY respond differently to different

   protected resources making the same request.  For instance, an

   authorization server MAY limit which scopes from a given token are

   returned to each protected resource in order to prevent a protected

   resources from learning more about the larger network than is

   necessary for its operation.

 

 

Section 3.1

 

Experience suggests a longer review period is appropriate, e.g., to accommodate holidays, vacations, etc.

 

The text says:

 

IANA must only accept registry updates from the Designated Expert(s)

and should direct all requests for registration to the review mailing

list.

 

How about:

 

IANA MUST accept registry updates only from the Designated Expert(s)

and SHOULD direct all requests for registration to the review mailing

list.

 

Section 3.1.1

 

If a proposed Name matches one already registered as per 7519, ought it not have an “equivalent” (vs. “comparable”) definition if it is to be accepted?

 

 

Section 4

 

The text lists four checks to be performed by an authorization server, yet the introduction to this list says “For instance:” A more normative introduction would seem appropriate here. I realize that the text says that not all of these checks may be applicable in all OAuth 2.0 contexts, but since each check begins with “If the token …” isn’t that a sufficient caveat?

 

The text says:

 

If an authorization server fails to perform any applicable check, the

resource server could make an errant security decision based on that

response. 

 

How about:

 

If an authorization server fails to perform any applicable check, the

resource server could make an erroneous security decision based on that response. 

 

 

The text says:

 

per RFC 6125 [RFC6125].

 

How about:

 

as specified in [RFC6125].

 

 

The discussion of introspection endpoint response caching seems to omit a simple, useful heuristic. Since the expiration time for a token is an optional parameter in the response, why not say that IF this parameter is present, the response MUST NOT be cached beyond that time?

 

 

Section 5

 

This section says: “One way to limit disclosure is to require

authorization to call the introspection endpoint and to limit calls

to only registered and trusted protected resource servers.” But  

Section 4 says: “… the authorization server MUST require authentication of protected resources that need to access the introspection endpoint and SHOULD require protected resources to be specifically authorized to call the introspection endpoint.”  It seems that the requirement imposed in Section 4 already mandate what is merely suggested in Section 5.

--------------030106030509090506080205-- From nobody Mon Jun 1 14:27:10 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821AE1A0047 for ; Mon, 1 Jun 2015 14:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TR2vNB42KFy for ; Mon, 1 Jun 2015 14:27:06 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97EEA1A002F for ; Mon, 1 Jun 2015 14:27:05 -0700 (PDT) X-AuditID: 12074424-f79b06d000000cfd-21-556cce27bb88 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 36.74.03325.82ECC655; Mon, 1 Jun 2015 17:27:04 -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 t51LR3dN011107; Mon, 1 Jun 2015 17:27:03 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t51LQxk7027191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Jun 2015 17:27:00 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A9461030-61D6-4135-BDB9-E731667472C4"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Justin Richer In-Reply-To: <556CACEC.2030501@bbn.com> Date: Mon, 1 Jun 2015 17:26:58 -0400 Message-Id: <8CBCFD65-237C-4683-B84B-B058DD5E166F@mit.edu> References: <556CACEC.2030501@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBKsWRmVeSWpSXmKPExsUixCmqratxLifUoGkmh8XKSTvYLZbuvMdq sXE2o8WHhQ9ZHFg8pp4P9Vi8aT+bx5IlP5k8ln99wBLAEsVlk5Kak1mWWqRvl8CVsfeuRMHd C8wVe+8cY2pg3DeBuYuRk0NCwERi5ap7ULaYxIV769lAbCGBxUwSezdGdjFyAdkbGCU2PDzG BOE8YJK4t/kXWIewgIXE430/WUBsXgE9iUdPH7ODFDELTGGUWLN0JzvEWCmJptfHGEFsNgFV ielrWphAbE4BdYnPS7eCrWMRUJH4sPI62FBmgRKJudNfMUIMtZJYdn4bK8RJahKz7l0Hi4sI yEt8O7YVaDEH0HxZia9b5SYwCs5CcsYsZGfMAhubJLH6xiEWCFtbYtnC18wQtqbE/u7lWMQ1 JDq/TWSFsOUltr+dAxW3lFg88wZUva3Erb4FTBC2ncSjaYtYFzByr2KUTcmt0s1NzMwpTk3W LU5OzMtLLdI118vNLNFLTSndxAiKVHYXlR2MzYeUDjEKcDAq8fBmdGeHCrEmlhVX5h5ilORg UhLlDTydEyrEl5SfUpmRWJwRX1Sak1p8iFEFaNejDasvMEqx5OXnpSqJ8FqeAarjTUmsrEot yocpk+ZgURLn3fSDL0RIID2xJDU7NbUgtQgmK8PBoSTBexmkUbAoNT21Ii0zpwQhzcTBeYhR goMHaPhesOHFBYm5xZnpEPlTjIpS4rxLQRICIImM0jy4XliCfcUoDvSWMO8WkCoeYHKG634F NJgJaHC7ANjgkkSElFQDo2/PS+EnNvt3VKTmTo0/6WS+wF9atZnzx4pnXY4XxT5ZlNRLH1cr jZarfVxwo37GyUkvxA7lGE86/eVG4Yay41zxm999vnXxmZuhf8oM/wt+967em1F9i6fLtk3H Om6+x/S/WUv3pRqK82a9vMsn2yi6M0Bh73m7bXvmhxzef2BdKfOxmd5tcUosxRmJhlrMRcWJ AB9ef6+LAwAA Archived-At: Cc: secdir Subject: Re: [secdir] review of draft-ietf-oauth-introspection-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 21:27:09 -0000 --Apple-Mail=_A9461030-61D6-4135-BDB9-E731667472C4 Content-Type: multipart/alternative; boundary="Apple-Mail=_8517F82A-A0BC-4E77-8D9B-6599AF02A4DF" --Apple-Mail=_8517F82A-A0BC-4E77-8D9B-6599AF02A4DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Stephen, thanks for the review. Comments inline. > On Jun 1, 2015, at 3:05 PM, Stephen Kent wrote: >=20 > I reviewed this document as part of the security directorate's ongoing = effort to review all IETF documents being processed by the IESG. These = comments were written with the intent of improving security requirements = and considerations in IETF drafts. Comments not addressed in last call = may be included in AD reviews during the IESG review. Document editors = and WG chairs should treat these comments just like any other last call = comments. >=20 > This document describes an API for use with OAuth 2.0. The API enables = the recipient of a token to query an authorization server to determine = the set of metadata presented to the server (by the OAuth client) when = the token was issued. This API is intended to overcome the lack of a = standard way to convey token metadata in the OAuth 2.0 context. >=20 > I didn=E2=80=99t find any significant security problems with the = document, but there are a number of places where the exposition needs = improvement. >=20 > Specific comments >=20 > Section 2 >=20 > The text says: >=20 > The introspection endpoint MUST be protected by a transport-layer = security mechanism as described in Section 4. >=20 > It might be clearer to say here that the token endpoint MUST = communicate security with the introspection endpoint, and that TLS 1.2 = is the mandatory-to-implement mechanism for such security. Also, the = text should be clearer about the relationship between an authorization = server and an introspection endpoint. In some places the two terms seem = to be used interchangeably. This language was imported from the soon-to-be-published OAuth Dynamic = Registration drafts, including the forward reference. We don=E2=80=99t = want to repeat the requirement text. >=20 > Section 2.1 >=20 > The texts says: >=20 > The endpoint MAY allow other parameters to provide further context to = the query. >=20 > How about: >=20 > The endpoint MAY accept other parameters to provide further context to = the query. Thanks, that=E2=80=99s a better wording. >=20 > How does a protected resource know which other parameters an = introspection endpoint requires/accepts? >=20 >=20 We=E2=80=99re assuming it would be either an extension or = deployment-specific. >=20 > This section mandates (MUST) protection against =E2=80=9Cunauthorized = token scanning=E2=80=9D but mandates no standard way to do so. [Also, = when would a scanning =E2=80=9Cattack=E2=80=9D be authorized ;-)] >=20 Is there something more specific we can recommend here? Perhaps in the = security considerations section. And the attack could actually take place where an authorized protected = resource goes fishing for other valid tokens. The attack isn=E2=80=99t = authorized, but the client is =E2=80=A6 and yes that=E2=80=99s not what = we meant but I=E2=80=99m sticking to it. ;) >=20 > The text says: >=20 > For example, the following example shows a protected resource calling = the token introspection endpoint to query about an OAuth 2.0 bearer. >=20 > How about: >=20 > For example, the following example shows a protected resource calling = the token introspection endpoint to query about an OAuth 2.0 bearer = token. >=20 Thanks, that=E2=80=99s a typo. Good catch! >=20 > Section 2.2 >=20 > He text says: >=20 > The authorization server MAY respond differently to different > protected resources making the same request. For instance, an > authorization server MAY limit which scopes from a given token are > returned for each protected resource in order to prevent protected > resources from learning more about the larger network than is > necessary for their function. >=20 > How about: >=20 > An authorization server MAY respond differently to different > protected resources making the same request. For instance, an > authorization server MAY limit which scopes from a given token are > returned to each protected resource in order to prevent a protected > resources from learning more about the larger network than is > necessary for its operation. I prefer the definite article in the text, but the later correction is = helpful. >=20 >=20 > Section 3.1 >=20 > Experience suggests a longer review period is appropriate, e.g., to = accommodate holidays, vacations, etc. >=20 > The text says: >=20 > IANA must only accept registry updates from the Designated Expert(s) > and should direct all requests for registration to the review mailing > list. >=20 > How about: >=20 > IANA MUST accept registry updates only from the Designated Expert(s) > and SHOULD direct all requests for registration to the review mailing > list. This text was imported from a template, I=E2=80=99d be glad to change it = if there=E2=80=99s a better one. >=20 > Section 3.1.1 >=20 > If a proposed Name matches one already registered as per 7519, ought = it not have an =E2=80=9Cequivalent=E2=80=9D (vs. =E2=80=9Ccomparable=E2=80= =9D) definition if it is to be accepted? >=20 >=20 It really is comparable, since the contexts are pretty different. >=20 > Section 4 >=20 > The text lists four checks to be performed by an authorization server, = yet the introduction to this list says =E2=80=9CFor instance:=E2=80=9D A = more normative introduction would seem appropriate here. I realize that = the text says that not all of these checks may be applicable in all = OAuth 2.0 contexts, but since each check begins with =E2=80=9CIf the = token =E2=80=A6=E2=80=9D isn=E2=80=99t that a sufficient caveat? >=20 >=20 This is not a normative requirement, since everything is contextual to = the nature of the tokens issued by the authorization server. > The text says: >=20 > If an authorization server fails to perform any applicable check, the > resource server could make an errant security decision based on that > response. >=20 > How about: >=20 > If an authorization server fails to perform any applicable check, the > resource server could make an erroneous security decision based on = that response. >=20 Thanks, I think that=E2=80=99s a better word. >=20 > The text says: >=20 > per RFC 6125 [RFC6125]. >=20 > How about: >=20 > as specified in [RFC6125]. >=20 >=20 >=20 That=E2=80=99s fine with me, thanks. > The discussion of introspection endpoint response caching seems to = omit a simple, useful heuristic. Since the expiration time for a token = is an optional parameter in the response, why not say that IF this = parameter is present, the response MUST NOT be cached beyond = that time? >=20 >=20 That=E2=80=99s a good example, I=E2=80=99ll add that. >=20 > Section 5 >=20 > This section says: =E2=80=9COne way to limit disclosure is to require > authorization to call the introspection endpoint and to limit calls > to only registered and trusted protected resource servers.=E2=80=9D = But > Section 4 says: =E2=80=9C=E2=80=A6 the authorization server MUST = require authentication of protected resources that need to access the = introspection endpoint and SHOULD require protected resources to be = specifically authorized to call the introspection endpoint.=E2=80=9D It = seems that the requirement imposed in Section 4 already mandate what is = merely suggested in Section 5. The requirement in section 4 came later than the suggestion in section = 5. I=E2=80=99ll reword the security consideration to provide further = justification for the requirement. Thanks for your review! =E2=80=94 Justin --Apple-Mail=_8517F82A-A0BC-4E77-8D9B-6599AF02A4DF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Stephen, thanks for the review. Comments inline.

On Jun 1, 2015, at 3:05 PM, Stephen Kent <kent@bbn.com> = wrote:

=20 =20

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  = These comments were written with the intent of improving security requirements and considerations in IETF drafts.  = Comments not addressed in last call may be included in AD reviews during the IESG review.  Document editors and = WG chairs should treat these comments just like any other last call comments.

 

This document describes an API for use with OAuth 2.0. The API enables the recipient of a token to query an authorization server to determine the set of metadata presented to the server (by the OAuth client) when the token was issued. This API is intended to overcome the lack of a standard way to convey token metadata in the OAuth 2.0 context.

 

I didn=E2=80=99t find any significant security problems with the = document, but there are a number of places where the exposition needs improvement.

 

Specific comments

 

Section= 2

 

The text says:   =

 

The introspection endpoint MUST be protected by a transport-layer security mechanism as described in Section 4.

 

It might be clearer to say here that the token endpoint MUST communicate security with the introspection endpoint, and that TLS 1.2 is the mandatory-to-implement mechanism for such security. Also, the text should be clearer about the relationship between an authorization server and an introspection endpoint. In some places the two terms seem to be used = interchangeably.


This language was imported from the = soon-to-be-published OAuth Dynamic Registration drafts, including the = forward reference. We don=E2=80=99t want to repeat the requirement = text.

 

Section= 2.1

 

The texts says:

 

The endpoint MAY allow other parameters to provide further context to the query. 

 

How = about:

 

The = endpoint MAY accept= other parameters to provide further context to the query. 


Thanks, that=E2=80=99s a better wording.

 

How = does a protected resource know which other parameters an introspection endpoint requires/accepts?

 



We=E2=80=99re assuming it would be either an = extension or deployment-specific. 

 

This section mandates (MUST) protection against =E2=80=9Cunauthorized = token scanning=E2=80=9D but mandates no standard way to do so. [Also, when would a scanning =E2=80=9Cattack=E2=80=9D be authorized ;-)]



Is there something more specific we can recommend = here? Perhaps in the security considerations section.

And the attack could actually take place where an = authorized protected resource goes fishing for other valid tokens. The = attack isn=E2=80=99t authorized, but the client is =E2=80=A6 and yes = that=E2=80=99s not what we meant but I=E2=80=99m sticking to it. =  ;)

 

The text says:

 

For example, the following example shows a protected resource calling the token introspection endpoint to query about an OAuth 2.0 bearer.

 

How = about:

 

For = example, the following example shows a protected resource calling the token introspection endpoint to query about an OAuth 2.0 bearer token.

 


Thanks, that=E2=80=99s a typo. Good = catch!

 

Section 2.2

 

He = text says:

 

   The authorization server MAY respond differently to different

   protected = resources making the same request.  = For instance, an

   authorization server MAY limit which scopes from a given token are

   returned for = each protected resource in order to prevent protected

   resources from = learning more about the larger network than is

   necessary for = their function.

 

How about:

 

   An authorization server MAY respond differently to different

   protected = resources making the same request.  = For instance, an

   authorization server MAY limit which scopes from a given token are

   returned to each protected resource in order to = prevent a protected

   resources from learning more about the larger network than is

   necessary for = its operation.



I prefer the definite = article in the text, but the later correction is helpful.

 

 

Section= 3.1

 

Experience suggests a longer review period is appropriate, e.g., to accommodate holidays, vacations, etc.

 

The text says:

 

IANA must only accept registry updates from the Designated Expert(s)

and should direct all requests for registration to the review mailing

list.

 

How = about:

 

IANA = MUST accept registry updates only from the Designated Expert(s)

and = SHOULD direct all requests for = registration to the review mailing

list.



This text was imported = from a template, I=E2=80=99d be glad to change it if there=E2=80=99s a = better one.

 

Section 3.1.1

 

If a = proposed Name matches one already registered as per 7519, ought it not have an =E2=80=9Cequivalent=E2=80=9D (vs. =E2=80=9Ccomparable=E2=80=9D) definition if it is to be = accepted?

 


It really is comparable, since the contexts are = pretty different. 

 

Section 4

 

The = text lists four checks to be performed by an authorization server, yet the introduction to this list says =E2=80=9CFor instance:=E2=80=9D A more normative = introduction would seem appropriate here. I realize that the text says that not all of these checks may be applicable in all OAuth 2.0 contexts, but since each check begins with =E2=80=9C= If the token =E2=80=A6=E2=80=9D isn=E2=80=99t that a sufficient caveat?

 



This is not a normative requirement, since = everything is contextual to the nature of the tokens issued by the = authorization server.

The text says:

 

If an authorization server fails to perform any applicable check, the

resource server could make an errant security decision based on that

response. 

 

How = about:

 

If an authorization server fails to perform any applicable check, the

resource server could make an erroneous security decision based on that response. 

 


Thanks, I think that=E2=80=99s a better = word.

 

The text says:

 

per RFC 6125 [RFC6125].

 

How about:

 

as = specified in [RFC6125].

 

 


That=E2=80=99s fine with me, thanks.

The discussion of introspection endpoint response caching seems to omit a simple, useful heuristic. Since the expiration time for a token is an optional parameter in the response, why not say that IF this parameter is present, the response MUST NOT be cached beyond that time?

 



That=E2=80=99s a good example, I=E2=80=99ll add = that.

 

Section 5

 

This = section says: =E2=80=9COne way to limit disclosure is to require

authorization to call the introspection endpoint and to limit calls

to only registered and trusted protected resource servers.=E2=80=9D But  

Section 4 says: =E2=80=9C=E2=80=A6 the authorization server MUST require authentication of protected resources that need to access the introspection endpoint and SHOULD require protected resources to be specifically authorized to call the introspection endpoint.=E2=80=9D  It seems that the requirement imposed in Section 4 already mandate what is merely suggested in Section = 5.



The requirement in section 4 came later = than the suggestion in section 5. I=E2=80=99ll reword the security = consideration to provide further justification for the = requirement.

Thanks for your review!

 =E2=80=94 = Justin
= --Apple-Mail=_8517F82A-A0BC-4E77-8D9B-6599AF02A4DF-- --Apple-Mail=_A9461030-61D6-4135-BDB9-E731667472C4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVbM4iAAoJEDPAngkbd+w9fTcH/Astbw1qHLlq/Ynm8uD1BSQh Kt3bupV6iUfFWwPLpjT7vu2DdDVocZ8KYSLc0aV7DCj4fvRXOvZ9wxYDhAOFm/Tq TShpmSPywSeXUKFIcTV6XMb6B6q+ELgakQfiHw/P5f1lK3Zp3akstFctwKOBmpfx 8fCbLtMmPBh0YCoqmXIdRUSlo9XtFPa7ap5a/zWfDiLiaOgEjBG8SFTf5Zmovs+2 qAY4Wj0Whz3h2H3HWOdVP7WnHEoN5BGJSyETk3TIxi30joCI/Qrm9xHouJTsJMx6 aid3yedgnSRRf/FEotXdKcHsBrMTWkCIBfgQrcbHDc1+x3JS3FTN0qQa4pgVyfc= =8SrC -----END PGP SIGNATURE----- --Apple-Mail=_A9461030-61D6-4135-BDB9-E731667472C4-- From nobody Wed Jun 3 16:23:49 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559A41A8908; Wed, 3 Jun 2015 16:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 MDWpcyii7pyQ; Wed, 3 Jun 2015 16:23:45 -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 B446D1A0120; Wed, 3 Jun 2015 16:23:45 -0700 (PDT) Received: by oiww2 with SMTP id w2so19446032oiw.0; Wed, 03 Jun 2015 16:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=02jIrLydkoZSil4iG+ngG52SvKSy0CfivP/olGWsCJ4=; b=wxqwJislpGBD4JdEXv7ukR7vS0oJ8lCYckgYplbEoxqV9FSOSNtBuQI5dJ+alUizZQ hgD6YuCFzfM3pdRWOEOcS7VaAMMZLvt5/2Lpm2+l50zjFbDkGMRkFcGNrDCY7R2fLjLm O6v1QoOVDZ4BWhuJqghagtmzqxGGmmapoTMBZw+xlXsonpX5nEkBAG4sWlmWzvfiqqyQ 8sY2POaPdVNy6Prd5R8tLBMY0/l+is0DvWJhIwcWLBulcAEhl1rnrHrw5YWWxnLsEklj D3pisVe6iMgvwOTKdRDkAiLp8s/CufuGaEFl7Qf1vtdI/Phkk1ZXBs3S1seNxBKOjWxd o22w== X-Received: by 10.202.239.138 with SMTP id n132mr15744924oih.99.1433373825214; Wed, 03 Jun 2015 16:23:45 -0700 (PDT) Received: from Chriss-MacBook-Air.local (c-50-171-51-221.hsd1.tx.comcast.net. [50.171.51.221]) by mx.google.com with ESMTPSA id x3sm215531obm.8.2015.06.03.16.23.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jun 2015 16:23:44 -0700 (PDT) Message-ID: <556F8C89.1020500@gmail.com> Date: Wed, 03 Jun 2015 18:23:53 -0500 From: Chris Lonvick User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-6lo-btle.all@tools.ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] secdir review of draft-ietf-6lo-btle-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 23:23:47 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Overall, the document is well written and explains the concepts well. I saw that a "test interface" is defined in Section 2.1. I would like to see some guidance in the Security Considerations section about this. Hopefully the guidance will describe how the interface is secured, or that it can be secured by an operator. Multicast is mentioned several times throughout the document mostly saying that the Bluetooth LE link layer does not support it. I would like to see this addressed in the Security Considerations section as well to alert implementers and operators that this may be a point of attack. Any guidance on how to prevent an active, malicious denial of service attack using multicast would be appreciated. Also, I found a couple of nits that you may want to address. Current in Section 3: This functionality comprises of link-local IPv6 addresses and stateless IPv6 address autoconfiguration (see Section 3.2.1), Neighbor Discovery (see Section 3.2.2) and header compression (see Section 3.2.3). Fragmentation features from 6LoWPAN standards are not used due Bluetooth LE's link layer fragmentation support (see Section 2.4). Proposed: This functionality is comprised of link-local IPv6 addresses and stateless ^^^^^^^^^^^^ IPv6 address autoconfiguration (see Section 3.2.1), Neighbor Discovery (see Section 3.2.2), and header compression (see ^ Section 3.2.3). Fragmentation features from 6LoWPAN standards are not used due to Bluetooth LE's link layer fragmentation support (see ^^ Section 2.4). Current also in Section 3: In Bluetooth LE a central node is assumed to be less constrained than Proposed: In Bluetooth LE a central node is assumed to be less resource constrained than ^^^^^^^^ Current in 3.2.1: Effectively duplicate address detection for link-local addresses is performed by the 6LBR's software responsible of discovery of IP-enabled Bluetooth LE nodes and of starting Bluetooth LE connection establishment procedures. Proposed: Detection of duplicate link-local addresses is performed by the process on the 6LBR responsible for the discovery of IP-enabled Bluetooth LE nodes and for starting Bluetooth LE connection establishment procedures. Best regards, Chris From nobody Thu Jun 4 09:18:41 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E401A9023 for ; Thu, 4 Jun 2015 09:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RCVM9rcfOqk for ; Thu, 4 Jun 2015 09:18:37 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FB681A9005 for ; Thu, 4 Jun 2015 09:18:37 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:37492 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Z0Xqg-0001Lf-Bs; Thu, 04 Jun 2015 12:18:30 -0400 Message-ID: <55707A56.5000105@bbn.com> Date: Thu, 04 Jun 2015 12:18:30 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Justin Richer References: <556CACEC.2030501@bbn.com> <8CBCFD65-237C-4683-B84B-B058DD5E166F@mit.edu> In-Reply-To: <8CBCFD65-237C-4683-B84B-B058DD5E166F@mit.edu> Content-Type: multipart/alternative; boundary="------------040606060907060309060607" Archived-At: Cc: secdir Subject: Re: [secdir] review of draft-ietf-oauth-introspection-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 16:18:39 -0000 This is a multi-part message in MIME format. --------------040606060907060309060607 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Justin, > Stephen, thanks for the review. Comments inline. > >> ... >> >> The text says: >> >> The introspection endpoint MUST be protected by a transport-layer >> security mechanism as described in Section 4. >> >> It might be clearer to say here that the token endpoint MUST >> communicate security with the introspection endpoint, and that TLS >> 1.2 is the mandatory-to-implement mechanism for such security. Also, >> the text should be clearer about the relationship between an >> authorization server and an introspection endpoint. In some places >> the two terms seem to be used interchangeably. >> > > This language was imported from the soon-to-be-published OAuth Dynamic > Registration drafts, including the forward reference. We don’t want to > repeat the requirement text. I didn't review the dynamic registration docs, or I would have made the same comment there :-). If you don't want to repeat requirements text, then I suggest you might re-word the sentence I cited so that it's clearer. Saying that an endpoint must be protected by a transport layer security mechanism seems needlessly ambiguous. > ... >> >> How does a protected resource know which other parameters an >> introspection endpoint requires/accepts? >> >> > > We’re assuming it would be either an extension or deployment-specific. an extension to what? it seems that a primary motivation for this document is to fix problems that arose because of inadequate specifications for OAuth token syntax. In that light, this description of "other parameters" seems to perpetuate this sort of problem. > > >> This section mandates (MUST) protection against “unauthorized token >> scanning” but mandates no standard way to do so. [Also, when would a >> scanning “attack” be authorized ;-)] >> >> > > Is there something more specific we can recommend here? Perhaps in the > security considerations section. yes, the SC section is where there should be suggestions on how to protect against such attacks. if you can't recommend something specific, then mandating that something be done seems possibly vacuous, a MUST that will never be realized in practice (see RFC 6919). > > And the attack could actually take place where an authorized protected > resource goes fishing for other valid tokens. The attack isn’t > authorized, but the client is … and yes that’s not what we meant but > I’m sticking to it. ;) so, as I said, the attack is not authorized, and the phrase "unauthorized attack" will make most security experts cringe. is cringing a goal? > >> ... >> >> IANA must only accept registry updates from the Designated Expert(s) >> >> and should direct all requests for registration to the review mailing >> >> list. >> >> How about: >> >> IANA *MUST* accept registry updates *only* from the Designated Expert(s) >> >> and *SHOULD* direct all requests for registration to the review mailing >> >> list. >> > > > This text was imported from a template, I’d be glad to change it if > there’s a better one. one should not assume that a doc that has made it through the RFC approval process is perfect. > >> Section 3.1.1 >> >> If a proposed Name matches one already registered as per 7519, ought >> it not have an “equivalent” (vs. “comparable”) definition if it is to >> be accepted? >> >> > > It really is comparable, since the contexts are pretty different. if the contexts are so different, and thus the semantics are not equivalent, why is the reuse of the name, and the potential confusion acceptable? > >> Section 4 >> >> The text lists four checks to be performed by an authorization >> server, yet the introduction to this list says “For instance:” A more >> normative introduction would seem appropriate here. I realize that >> the text says that not all of these checks may be applicable in all >> OAuth 2.0 contexts, but since each check begins with “If the token …” >> isn’t that a sufficient caveat? >> >> > > This is not a normative requirement, since everything is contextual to > the nature of the tokens issued by the authorization server. so you're saying that there is no set of checks that every authorization server can be expected to perform? not even token expiration? Steve --------------040606060907060309060607 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Justin,


Stephen, thanks for the review. Comments inline.

...

The text says:  

 

The introspection endpoint MUST be protected by a transport-layer security mechanism as described in Section 4.

 

It might be clearer to say here that the token endpoint MUST communicate security with the introspection endpoint, and that TLS 1.2 is the mandatory-to-implement mechanism for such security. Also, the text should be clearer about the relationship between an authorization server and an introspection endpoint. In some places the two terms seem to be used interchangeably.


This language was imported from the soon-to-be-published OAuth Dynamic Registration drafts, including the forward reference. We don’t want to repeat the requirement text.
I didn't review the dynamic registration docs, or I would have made the same comment there :-).

If you don't want to repeat requirements text, then I suggest you might re-word the sentence
I cited so that it's clearer. Saying that an endpoint must be protected by a transport layer security mechanism seems needlessly ambiguous.


...

 

How does a protected resource know which other parameters an introspection endpoint requires/accepts?

 



We’re assuming it would be either an extension or deployment-specific.
an extension to what?

it seems that a primary motivation for this document is to fix problems that arose
because of inadequate specifications for OAuth token syntax. In that light, this description
of "other parameters" seems to perpetuate this sort of problem.


 

This section mandates (MUST) protection against “unauthorized token scanning” but mandates no standard way to do so. [Also, when would a scanning “attack” be authorized ;-)]



Is there something more specific we can recommend here? Perhaps in the security considerations section.
yes, the SC section is where there should be suggestions on how to protect against such attacks. if you can't recommend something specific, then mandating that something be
done seems possibly vacuous, a MUST that will never be realized in practice (see RFC 6919).

And the attack could actually take place where an authorized protected resource goes fishing for other valid tokens. The attack isn’t authorized, but the client is … and yes that’s not what we meant but I’m sticking to it.  ;)
so, as I said, the attack is not authorized, and the phrase "unauthorized attack" will
make most security experts cringe. is cringing a goal?

...

IANA must only accept registry updates from the Designated Expert(s)

and should direct all requests for registration to the review mailing

list.

 

How about:

 

IANA MUST accept registry updates only from the Designated Expert(s)

and SHOULD direct all requests for registration to the review mailing

list.



This text was imported from a template, I’d be glad to change it if there’s a better one.
one should not assume that a doc that has made it through the RFC approval process
is perfect.

 

Section 3.1.1

 

If a proposed Name matches one already registered as per 7519, ought it not have an “equivalent” (vs. “comparable”) definition if it is to be accepted?

 



It really is comparable, since the contexts are pretty different.
if the contexts are so different, and thus the semantics are not equivalent, why is the reuse of the name, and the potential confusion acceptable?

 

Section 4

 

The text lists four checks to be performed by an authorization server, yet the introduction to this list says “For instance:” A more normative introduction would seem appropriate here. I realize that the text says that not all of these checks may be applicable in all OAuth 2.0 contexts, but since each check begins with “If the token …” isn’t that a sufficient caveat?

 



This is not a normative requirement, since everything is contextual to the nature of the tokens issued by the authorization server.
so you're saying that there is no set of checks that every authorization server
can be expected to perform? not even token expiration?


Steve

--------------040606060907060309060607-- From nobody Thu Jun 4 13:14:54 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446B61A90F7 for ; Thu, 4 Jun 2015 13:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uvQms6ECZW6 for ; Thu, 4 Jun 2015 13:14:49 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6B47A1A90F3 for ; Thu, 4 Jun 2015 13:14:49 -0700 (PDT) X-AuditID: 12074422-f79c36d000000db3-66-5570b1b87ba7 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-5.mit.edu (Symantec Messaging Gateway) with SMTP id 3B.E6.03507.8B1B0755; Thu, 4 Jun 2015 16:14:48 -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 t54KElbb013498; Thu, 4 Jun 2015 16:14:47 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t54KEhfs029671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Jun 2015 16:14:44 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_DCEAEE28-5426-4B69-B662-65298F0A5313"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Justin Richer In-Reply-To: <55707A56.5000105@bbn.com> Date: Thu, 4 Jun 2015 16:14:42 -0400 Message-Id: <9F40D42F-56E0-49A9-8BCC-6964D124E3B2@mit.edu> References: <556CACEC.2030501@bbn.com> <8CBCFD65-237C-4683-B84B-B058DD5E166F@mit.edu> <55707A56.5000105@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA2VSa0hTYRjmOzubZ7ojx+Ptc2bWwegiWkLF0hSDCP3Xj/YnoTpuX264GztT VCLNitJUStLMMi/T1BS8gLQU1EaMtMILSjrSvFDCTJBA0cjsnG1q0L/nfZ7nfd7343sJEf1L LCe0BgsyG1gdI/HFaWlwdIyty6Q8UXKfVrSW23wUTW9mxYquZ0CxWj+PJ+MpFSPKFGv3gCSl sXETS2lem8Mv4pd9z6qRTpuNzMeTrvlqfoy34KbeIZBT4XSAArBaC4qBlIDUSXivacWLQ+Do bIekGPgSNGXF4PRYA/AUnQC2Vb73FnMYbGhfw4WWQEoBF/s33ZikYuHCt0UfwSSiHgNYWNUi 8uTKYeGywz1DQh2Cta1OTMBS6jC0Od9JBIxTUfCjc9DNiygLrHniAp7QeLg9N+TmacoER6eW fAQcREXCdUcPP5jg8yPgWs/+hyCg+p81qv9do9odmw5/3m0We3A0fFm/7OWPwoEHzfj//BFY tP7I64+Er1eee/kz0Pp0yutPhM6yOsyDk+BCZYO4Dvi9AhFqfV6MntXqOKSK4VSswYDMMadi 9VpLLFJndQPhW33OMzaw+ZaxA4oAjIxUOIxKWsxmc7l6OwgjMCaYVHaYlLR/ulGdq2E5zVVz lg5xdhDFz1robBsFctxgNCAmiBy/yftINZubh8zGHVs4gTOhZPeG/yWaymAtKBMhEzLvqPsI goEk6uQbA8woA+Vc1+osezJGSO0AEjI+XCV4SM7E6jlthkcfBgfloeRtQaAEQZNl2O3dOVkX COWfFUhaBZeMP+jdbhcfjPHBn8XuYAu7J8kLgDwfk4ZoA/uM+ZPc8sj3+VsXBhlp6wBXVtlC 96ctnZ7culPsytCmTia0NG8t5YXFNemotiuJsxt+576ONdi2J3JlshtZqTXTwRMfhjscHaXh qOmLsaS6/MVA5HZpXVpCUec66q2a6Q2dSTNk2lXJ7a4+x58DjCpb/8nvty6ewTkNG3dMZObY v31I9MKNAwAA Archived-At: Cc: secdir Subject: Re: [secdir] review of draft-ietf-oauth-introspection-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 20:14:53 -0000 --Apple-Mail=_DCEAEE28-5426-4B69-B662-65298F0A5313 Content-Type: multipart/alternative; boundary="Apple-Mail=_A4193C5C-0EF9-41D9-8BD4-3727EF8AB05F" --Apple-Mail=_A4193C5C-0EF9-41D9-8BD4-3727EF8AB05F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Stephen, > On Jun 4, 2015, at 12:18 PM, Stephen Kent wrote: >=20 > Justin, >=20 >=20 >> Stephen, thanks for the review. Comments inline. >>=20 >>> ... >>> The text says: >>>=20 >>>=20 >>> The introspection endpoint MUST be protected by a transport-layer = security mechanism as described in Section 4. >>>=20 >>>=20 >>> It might be clearer to say here that the token endpoint MUST = communicate security with the introspection endpoint, and that TLS 1.2 = is the mandatory-to-implement mechanism for such security. Also, the = text should be clearer about the relationship between an authorization = server and an introspection endpoint. In some places the two terms seem = to be used interchangeably. >>>=20 >>=20 >> This language was imported from the soon-to-be-published OAuth = Dynamic Registration drafts, including the forward reference. We don=E2=80= =99t want to repeat the requirement text. > I didn't review the dynamic registration docs, or I would have made = the same comment there :-). >=20 > If you don't want to repeat requirements text, then I suggest you = might re-word the sentence > I cited so that it's clearer. Saying that an endpoint must be = protected by a transport layer security mechanism seems needlessly = ambiguous. The section pointed to in the forward reference in that sentence has the = details. If you have a better way to word this, please suggest text. >=20 >=20 >> ... >>>=20 >>> How does a protected resource know which other parameters an = introspection endpoint requires/accepts? >>>=20 >>>=20 >>>=20 >>=20 >> We=E2=80=99re assuming it would be either an extension or = deployment-specific. > an extension to what? >=20 An extension to this specification that defines other parameters and = their meanings. > it seems that a primary motivation for this document is to fix = problems that arose > because of inadequate specifications for OAuth token syntax. In that = light, this description > of "other parameters" seems to perpetuate this sort of problem. I wouldn=E2=80=99t call OAuth having =E2=80=9Cinadequate=E2=80=9D token = syntax specification, it has *no* token syntax, and that=E2=80=99s on = purpose. This specification actually doesn=E2=80=99t define a token = syntax, either, but it defines a web API for getting token information = regardless of the token syntax. The token itself can still be a signed = JWT, or a UUID, or a random hex blob; OAuth doesn=E2=80=99t care, and = that=E2=80=99s a good thing. >>=20 >>=20 >>>=20 >>> This section mandates (MUST) protection against =E2=80=9Cunauthorized = token scanning=E2=80=9D but mandates no standard way to do so. [Also, = when would a scanning =E2=80=9Cattack=E2=80=9D be authorized ;-)] >>>=20 >>>=20 >>=20 >> Is there something more specific we can recommend here? Perhaps in = the security considerations section. > yes, the SC section is where there should be suggestions on how to = protect against such attacks. if you can't recommend something specific, = then mandating that something be > done seems possibly vacuous, a MUST that will never be realized in = practice (see RFC 6919). OK, we=E2=80=99ll try to add some more examples. Cute reference. >>=20 >> And the attack could actually take place where an authorized = protected resource goes fishing for other valid tokens. The = attack isn=E2=80=99t authorized, but the client is =E2=80=A6 and yes = that=E2=80=99s not what we meant but I=E2=80=99m sticking to it. ;) > so, as I said, the attack is not authorized, and the phrase = "unauthorized attack" will > make most security experts cringe. is cringing a goal? We can change the wording to reduce the cringe level. >>=20 >>> ... >>> IANA must only accept registry updates from the Designated Expert(s) >>>=20 >>> and should direct all requests for registration to the review = mailing >>>=20 >>> list. >>>=20 >>>=20 >>> How about: >>>=20 >>>=20 >>> IANA MUST accept registry updates only from the Designated Expert(s) >>>=20 >>> and SHOULD direct all requests for registration to the review = mailing >>>=20 >>> list. >>>=20 >>=20 >>=20 >> This text was imported from a template, I=E2=80=99d be glad to change = it if there=E2=80=99s a better one. > one should not assume that a doc that has made it through the RFC = approval process > is perfect. >>=20 >>>=20 >>> Section 3.1.1 >>>=20 >>>=20 >>> If a proposed Name matches one already registered as per 7519, ought = it not have an =E2=80=9Cequivalent=E2=80=9D (vs. =E2=80=9Ccomparable=E2=80= =9D) definition if it is to be accepted? >>>=20 >>>=20 >>>=20 >>=20 >> It really is comparable, since the contexts are pretty different. > if the contexts are so different, and thus the semantics are not = equivalent, why is the reuse of the name, and the potential confusion = acceptable? Besides, if we simply prohibit reuse of the name, we=E2=80=99ll have = similar-but-confusing names, like =E2=80=9Cexpires=E2=80=9D vs. = =E2=80=9Cexp=E2=80=9D, in the two different places. The meanings are = close enough, with the details being context-specific, that the names = should be the same. Previously it was the same registry, but that was = causing even more confusion. >>=20 >>>=20 >>> Section 4 >>>=20 >>>=20 >>> The text lists four checks to be performed by an authorization = server, yet the introduction to this list says =E2=80=9CFor instance:=E2=80= =9D A more normative introduction would seem appropriate here. I realize = that the text says that not all of these checks may be applicable in all = OAuth 2.0 contexts, but since each check begins with =E2=80=9CIf the = token =E2=80=A6=E2=80=9D isn=E2=80=99t that a sufficient caveat? >>>=20 >>>=20 >>>=20 >>=20 >> This is not a normative requirement, since everything is contextual = to the nature of the tokens issued by the authorization server. > so you're saying that there is no set of checks that every = authorization server > can be expected to perform? not even token expiration? >=20 That=E2=80=99s correct. Not all tokens expire, so it doesn=E2=80=99t = make sense to mandate checking for expiration. Every recommendation here = is something that at least one known implementation of this protocol = already does in the wild, but not every implementation does every check = because it simply doesn=E2=80=99t make sense to do so. That=E2=80=99s = why the checks are phrased as =E2=80=9Cif the token=E2=80=9D and the = list is given as a =E2=80=9Cfor instance=E2=80=9D example of what to do. = We would also expect a server implementation to implement any other = checks that it might have in store, like =E2=80=9Cis my database online = and can I find the token in the these-are-valid-tokens table=E2=80=9D. =E2=80=94 Justin >=20 > Steve >=20 --Apple-Mail=_A4193C5C-0EF9-41D9-8BD4-3727EF8AB05F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Stephen,

On Jun 4, 2015, at 12:18 PM, = Stephen Kent <kent@bbn.com> wrote:

=20
Justin,


=20 Stephen, thanks for the review. Comments inline.

...

The = text says:   =

 

The introspection endpoint MUST be protected by a transport-layer security mechanism as described in Section 4.

 

It = might be clearer to say here that the token endpoint MUST communicate security with the introspection endpoint, and that TLS 1.2 is the mandatory-to-implement mechanism for such security. Also, the text should be clearer about the relationship between an authorization server and an introspection endpoint. In some places the two terms seem to be used interchangeably.


This language was imported from the = soon-to-be-published OAuth Dynamic Registration drafts, including the forward reference. We don=E2=80=99t want to repeat the requirement = text.
I didn't review the dynamic registration docs, or I would have made the same comment there :-).

If you don't want to repeat requirements text, then I suggest you might re-word the sentence
I cited so that it's clearer. Saying that an endpoint must be protected by a transport layer security mechanism seems needlessly ambiguous.

The section pointed to in the forward reference in = that sentence has the details. If you have a better way to word this, = please suggest text.



...

 

How does a protected resource know = which other parameters an introspection endpoint requires/accepts?

 


We=E2=80=99re assuming it would be either an = extension or deployment-specific.
an extension to what?


An extension to this specification that defines = other parameters and their meanings.

it seems that a primary motivation for this document is to fix problems that arose
because of inadequate specifications for OAuth token syntax. In that light, this description
of "other parameters" seems to perpetuate this sort of problem.

I = wouldn=E2=80=99t call OAuth having =E2=80=9Cinadequate=E2=80=9D token = syntax specification, it has *no* token syntax, and that=E2=80=99s on = purpose. This specification actually doesn=E2=80=99t define a token = syntax, either, but it defines a web API for getting token information = regardless of the token syntax. The token itself can still be a signed = JWT, or a UUID, or a random hex blob; OAuth doesn=E2=80=99t care, and = that=E2=80=99s a good thing.




 

This = section mandates (MUST) protection against =E2=80=9Cunauthorized token scanning=E2=80=9D = but mandates no standard way to do so. [Also, when would a scanning =E2=80=9Cattack=E2=80=9D be authorized ;-)]



Is there something more specific we can = recommend here? Perhaps in the security considerations section.
yes, the SC section is where there should be suggestions on how to protect against such attacks. if you can't recommend something specific, then mandating that something be
done seems possibly vacuous, a MUST that will never be realized in practice (see RFC 6919).

OK, = we=E2=80=99ll try to add some more examples. 

Cute reference.


And the attack could actually take place where = an authorized protected resource goes fishing for other valid tokens. The attack isn=E2=80=99t authorized, but the client = is =E2=80=A6 and yes that=E2=80=99s not what we meant but I=E2=80=99m = sticking to it.  ;)
so, as I said, the attack is not authorized, and the phrase "unauthorized attack" will
make most security experts cringe. is cringing a goal?

We = can change the wording to reduce the cringe level.


...
=

IANA must only accept registry = updates from the Designated Expert(s)

and should direct all requests for registration to the review mailing

list.

 

How about:

 

IANA MUST accept registry = updates only from the Designated Expert(s)

and SHOULD direct all requests for registration to the review mailing

list.



This text was imported from a template, I=E2=80=99= d be glad to change it if there=E2=80=99s a better one.
one should not assume that a doc that has made it through the RFC approval process
is perfect.

 

Section 3.1.1

 

If a proposed Name matches one = already registered as per 7519, ought it not have an =E2=80=9Cequivalent=E2=80=9D (vs. =E2=80=9Ccomparable=E2= =80=9D) definition if it is to be accepted?

 


It really is comparable, since the contexts = are pretty different.
if the contexts are so different, and thus the semantics are not equivalent, why is the reuse of the name, and the potential confusion acceptable?

Besides, if we simply prohibit reuse of the name, = we=E2=80=99ll have similar-but-confusing names, like =E2=80=9Cexpires=E2=80= =9D vs. =E2=80=9Cexp=E2=80=9D, in the two different places. The meanings = are close enough, with the details being context-specific, that the = names should be the same. Previously it was the same registry, but that = was causing even more confusion.


 

Section 4

 

The text lists four checks to be = performed by an authorization server, yet the introduction to this list says =E2=80=9CFor instance:=E2=80=9D A = more normative introduction would seem appropriate here. I realize that the text says that not all of these checks may be applicable in all OAuth 2.0 contexts, but since each check begins with =E2=80=9CIf the token =E2=80=A6= =E2=80=9D isn=E2=80=99t that a sufficient caveat?

 


This is not a normative requirement, since = everything is contextual to the nature of the tokens issued by the authorization server.
so you're saying that there is no set of checks that every authorization server
can be expected to perform? not even token expiration?


That=E2=80=99s correct. Not all tokens expire, so = it doesn=E2=80=99t make sense to mandate checking for expiration. Every = recommendation here is something that at least one known implementation = of this protocol already does in the wild, but not every implementation = does every check because it simply doesn=E2=80=99t make sense to do so. = That=E2=80=99s why the checks are phrased as =E2=80=9Cif the token=E2=80=9D= and the list is given as a =E2=80=9Cfor instance=E2=80=9D example of = what to do. We would also expect a server implementation to implement = any other checks that it might have in store, like =E2=80=9Cis my = database online and can I find the token in the these-are-valid-tokens = table=E2=80=9D. 

 =E2=80=94 = Justin


Steve


= --Apple-Mail=_A4193C5C-0EF9-41D9-8BD4-3727EF8AB05F-- --Apple-Mail=_DCEAEE28-5426-4B69-B662-65298F0A5313 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVcLGzAAoJEDPAngkbd+w9wpMIAJzawC33msxV5MTEaOUyhD2t oVmX+mSsnL+tOCBw3H88bOZAl7lOLyRL31Q4xSqeJaTMfkISyg+SAtayY705VH8U Rnez9RrP/cE0ElbQSDoaROTh4oaVDBYUwzcVXp1WrhPwUAYgA9f35qOf1dZhQJH4 aBp4IniNoE3GSmnqQDf2BKOAXiWWebwK8C8RNsW2729/sgujYVq+U2BpMBYrG93H skeCOLlcO5S2eo1iZHzenSo2FftlhZan3Q/2jv3dET7rTiJtQOYJgEpGgwRUL6Tf cD1aGPj5H+mo5gNaBJgyh5MizvIQZ995Z+C903siA/aYR/A1WOxPQKXYikp86O0= =G/1V -----END PGP SIGNATURE----- --Apple-Mail=_DCEAEE28-5426-4B69-B662-65298F0A5313-- From nobody Fri Jun 5 02:45:23 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0071B2AF7 for ; Fri, 5 Jun 2015 02:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=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 kGk0QmaR20Z8 for ; Fri, 5 Jun 2015 02:45:21 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 C67111B2AEE for ; Fri, 5 Jun 2015 02:45:20 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t559jHnL023226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 5 Jun 2015 12:45:17 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t559jGAv003068; Fri, 5 Jun 2015 12:45:16 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21873.28587.868175.417180@fireball.kivinen.iki.fi> Date: Fri, 5 Jun 2015 12:45:15 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 09:45:23 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Yaron Sheffer is next in the rotation. For telechat 2015-06-11 Reviewer LC end Draft Alan DeKok T 2015-05-01 draft-ietf-dprive-problem-statement-05 Steve Hanna T 2015-05-15 draft-ietf-rtcweb-stun-consent-freshness-13 Jeffrey Hutzelman T 2015-06-03 draft-ietf-rtcweb-video-05 Chris Inacio T 2015-05-28 draft-ietf-rtcweb-rtp-usage-24 Leif Johansson T 2015-05-25 draft-ietf-mip4-multiple-tunnel-support-12 Scott Kelly T 2015-06-03 draft-ietf-httpbis-tunnel-protocol-04 Ben Laurie T 2015-06-01 draft-ietf-oauth-spop-11 Matt Lepinski T 2015-06-03 draft-ietf-xmpp-6122bis-23 Eric Osterweil T 2015-04-29 draft-perrault-behave-deprecate-nat-mib-v1-01 For telechat 2015-06-25 Sandy Murphy T 2015-06-12 draft-ietf-manet-olsrv2-management-snapshot-03 Magnus Nystrom T 2015-06-18 draft-ietf-rtgwg-lfa-manageability-08 Joe Salowey T 2015-06-17 draft-ietf-tzdist-service-08 Last calls and special requests: Catherine Meadows 2015-06-09 draft-ietf-dhc-access-network-identifier-08 Alexey Melnikov 2015-06-17 draft-ietf-avtcore-rtp-topologies-update-07 Matthew Miller 2015-06-11 draft-ietf-homenet-prefix-assignment-06 Adam Montville 2015-06-11 draft-ietf-jose-jwk-thumbprint-05 Yoav Nir 2015-06-11 draft-ietf-pcp-anycast-06 Hilarie Orman 2015-06-17 draft-ietf-sipcore-6665-clarification-00 Radia Perlman 2015-06-17 draft-ietf-sipcore-refer-clarifications-04 Vincent Roca 2015-06-17 draft-ietf-sipcore-refer-explicit-subscription-02 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 -- kivinen@iki.fi From nobody Fri Jun 5 05:24:29 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF931B2D9C for ; Fri, 5 Jun 2015 05:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 2sF6v8BMLO41 for ; Fri, 5 Jun 2015 05:24:26 -0700 (PDT) Received: from smtp122.ord1c.emailsrvr.com (smtp122.ord1c.emailsrvr.com [108.166.43.122]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7867C1B2D0E for ; Fri, 5 Jun 2015 05:24:26 -0700 (PDT) Received: from smtp24.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp24.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id CEA5C80288; Fri, 5 Jun 2015 08:24:25 -0400 (EDT) Received: by smtp24.relay.ord1c.emailsrvr.com (Authenticated sender: scott-AT-hyperthought.com) with ESMTPSA id 7335680196; Fri, 5 Jun 2015 08:24:25 -0400 (EDT) X-Sender-Id: scott@hyperthought.com Received: from [10.0.0.6] (c-73-129-12-245.hsd1.md.comcast.net [73.129.12.245]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:587 (trex/5.4.2); Fri, 05 Jun 2015 12:24:25 GMT From: Scott Kelly Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 5 Jun 2015 05:24:25 -0700 To: secdir@ietf.org, iesg@ietf.org, draft-ietf-httpbis-tunnel-protocol.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [secdir] secdir review of draft-ietf-httpbis-tunnel-protocol-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 12:24:28 -0000 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. Sorry that this review is a few days late, I hope it is still useful. This document describes a method for using the HTTP ALPN header with the = HTTP CONNECT method. HTTP CONNECT is used to ask a proxy to establish a = tunnel through which other protocols (possibly HTTP, but not = necessarily) can be forwarded. Once established, the client encapsulates = the tunneled protocol in HTTP, sends this to the proxy, and the proxy = de-encapsulates and forwards the traffic, which may or may not be = encrypted.=20 The ALPN header allows the client to tell the proxy which protocol(s) it = intends to encapsulate. This ALPN header is not authenticated, and the = draft makes no reference to client authentication and/or other protocol = security mechanisms, so I assume this exchange is not secured in any = way. In the introduction, it says =20 "When the CONNECT method is used to establish a tunnel, the ALPN header field can be used to identify the protocol that the client intends to use with that tunnel. For a tunnel that is then secured using TLS [RFC5246], the header field carries the same application protocol label as will be carried within the TLS handshake. If there are multiple possible application protocols, all of those application protocols are indicated. The ALPN header field carries an indication of client intent only. An ALPN identifier is used here only to identify the application protocol or suite of protocols that the client intends to use in the tunnel. No negotiation takes place using this header field. In TLS, the final choice of application protocol is made by the server from the set of choices presented by the client. Other substrates could negotiate the application protocol differently. Proxies do not implement the tunneled protocol, though they might choose to make policy decisions based on the value of the header field. For example, a proxy could use the application protocol to select appropriate traffic prioritization.=94 The security considerations section notes that the client may falsify = the ALPN header, but it also implies that this could be used as input to = an authorization decision: The ALPN header field described in this document is an OPTIONAL header field. Clients and HTTP proxies could choose to not support the header and therefore fail to provide it, or ignore it when present. If the header is not available or ignored, a proxy cannot identify the purpose of the tunnel and use this as input to any authorization decision regarding the tunnel. This is indistinguishable from the case where either client or proxy does not support the ALPN header field. In the last of the previously quoted paragraphs, there was a similar = implication regarding policy (traffic prioritization). These both raised = red flags for me (especially the use of =93authorization decision=94). This header is unauthenticated, and therefore not trustworthy. The = client and/or a bad actor between the client/proxy can modify this. = Further, unless the proxy actively compares the ALPN content to the TLS = ClientHello message, those values may be different. For these reasons, = the ALPN header in unreliable for use in traffic policy decisions, and = for security-relevant definitions of =93authorization=94, should never = be relied upon. Things I think should change: The draft never says what the proxy should do if the client makes one = claim in the ALPN header, but then does something different (including = using different ALPNs in encapsulated TLS negotiations). Seems like it = should. Also, the draft seems to suggest that it is okay to use the ALPN for = policy/authorization decisions. This is unreliable from a security = perspective. At minimum, I think the draft should explicitly call this = out. =97Scott From nobody Fri Jun 5 05:44:44 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED6A1B2EF5 for ; Fri, 5 Jun 2015 05:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 oqHR-VkekkzX for ; Fri, 5 Jun 2015 05:44:41 -0700 (PDT) Received: from mail-vn0-x22a.google.com (mail-vn0-x22a.google.com [IPv6:2607:f8b0:400c:c0f::22a]) (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 B08D01B2EFE for ; Fri, 5 Jun 2015 05:44:40 -0700 (PDT) Received: by vnbg1 with SMTP id g1so8818534vnb.3 for ; Fri, 05 Jun 2015 05:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ykUJDztPorE4bnD4JaDFpumIIy3wP+ZXedLfrX8avdI=; b=hxyqeV2XFYehdqGyavOlA4fdhbjrV4TRSJy7f4cMjtTXqF06iyD49Kj/MKCy0vOwok ioKhZDd2/JwtLV3VAeut7iH5hf5dlttLPLdVgbXcwl5lDJ1wfhgdU2EbArz2yXj7Dkn3 t5kyylZRtlnWExn+M8T5Sv3Rk/8ht27cQDJ+zfxEmeWJ5S9oRp5r2YvPkiGrEDuQzkpj q40G/Jf5hoc19gvn1NrUo4GgqEWdvSiYi56YxvKp7/y8RTm55PeUveKo3eJOWxSCo7HB BAyxzZJkpY+4BMqfdIRzD4NDxGzfE0y3ZGdvLqoeccoiF4/6er+OSqyttl+4K4AcDIpx EMDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=ykUJDztPorE4bnD4JaDFpumIIy3wP+ZXedLfrX8avdI=; b=Cv4fcVSTjvXxSPBc6uvAPAM5LuNQKoqmSR/UWESz8WBXLXjo1+goJQtt49PYlsvMOu eiO9zsDi3moCZQ9Hw2bZFwTKB1HEr4ELhxCYcHb9hZGMs8SmcYDUkrpqn6mKahxCk/NF 7qerD1hiSsdvJ4s007e9FFmmUhHw4vQavYe6kxGvH8e7IHurn1VLpziNosY764Vq5Kx6 RvBo+rPOQgmJ1Ckrllao3XrHuXG0sYtu7/E+9fpFC/HjZPEHjJNEMbC1lnu6CYmc2A0u 7JwHmVw/mOvJQ+3wdeEklUvT/51DmBrN/PD6AyUXTQHAZEJpX8OU6xUsHpZQxjhofUVR 0PVw== X-Gm-Message-State: ALoCoQkb9djt/z4p/pxozSEXfJEsMIVaKg9vCrHMPWwp3EUbommSbrpZ13aj1czkxQeQKOGAiX5d MIME-Version: 1.0 X-Received: by 10.52.75.201 with SMTP id e9mr5767020vdw.33.1433508279791; Fri, 05 Jun 2015 05:44:39 -0700 (PDT) Received: by 10.52.76.6 with HTTP; Fri, 5 Jun 2015 05:44:39 -0700 (PDT) Date: Fri, 5 Jun 2015 13:44:39 +0100 Message-ID: From: Ben Laurie To: The IESG , "secdir@ietf.org" , draft-ietf-oauth-spop.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] Secdir review of draft-ietf-oauth-spop-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 12:44:43 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Status: ready with issues. It is disappointing that such a protocol must be introduced to work around security deficiencies in application platforms - have these security issues been reported to vendors? Anyway, issues: 1. Security consideration says: "Concatenating a publicly known value to a code_challenge (with 256 bits of entropy) and then hashing it with SHA256 would actually reduce the entropy in the resulting code_verifier making it easier for an attacker to brute force." This makes no sense. A brute force attack would still require iteration of 2^256 inputs. How is that easier? 2. The introduction says "No client secret is used (since public clients cannot keep their secrets confidential.)". However, a client secret is used. I suspect I know what is intended, but this should be clarified. From nobody Fri Jun 5 06:54:25 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C911B2FB5 for ; Fri, 5 Jun 2015 06:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 gLMDvSXIhLHX for ; Fri, 5 Jun 2015 06:54:21 -0700 (PDT) Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com [209.85.220.177]) (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 BDC861B2FB1 for ; Fri, 5 Jun 2015 06:54:20 -0700 (PDT) Received: by qkoo18 with SMTP id o18so40821087qko.1 for ; Fri, 05 Jun 2015 06:54:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=8bQtAa6tmBNZnHDclpqSD375crZwZVi6MKzg3DHMlAU=; b=awLQN8IPCGNHk1I3m7eaeuKCZk0U/Y38RI47lXFRpiPVTIScdfB/QWNHnVAjk8aXrA goxsJtlGdZ2QFNjNpyXX4cQyvEg6BZByS0RtNL01VZuDCNhhGllOkJgMcdRDdXNmZ9D+ A6Z2O3fQFHMIgITNbfen6rYacxKcUpOxziuJPFZs4/JAaroU8XknSkWsBjjuZSRd4PKs U0zh5TFUDvFsN2mfz8PxBSbC4QLfjQv2pqN+GUeLUPE5BDTEPSJMZ/o43MZ9OjDrcQ1B Igbt3WeRPWjENY5KAXc5vjTXtJ1BgtVK1ziiyV5t53Yb8WuZFosjkvh3aC0WyhD31nra 9IPw== X-Gm-Message-State: ALoCoQkvevjWDwJzZEI/LzHxZ5igMlqhIwBr3LCFb7+57w148zHyL83+rSxNuwo0iy2gMr7xuDb3 X-Received: by 10.140.216.208 with SMTP id m199mr4317672qhb.69.1433512459913; Fri, 05 Jun 2015 06:54:19 -0700 (PDT) Received: from [192.168.8.100] ([181.202.130.165]) by mx.google.com with ESMTPSA id o19sm3996371qkh.25.2015.06.05.06.54.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jun 2015 06:54:19 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_627DD0D8-8E7A-46D7-BA53-662226EC8E13"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: John Bradley In-Reply-To: Date: Fri, 5 Jun 2015 10:54:08 -0300 Message-Id: References: To: Ben Laurie X-Mailer: Apple Mail (2.2098) Archived-At: Cc: draft-ietf-oauth-spop.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-oauth-spop-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 13:54:23 -0000 --Apple-Mail=_627DD0D8-8E7A-46D7-BA53-662226EC8E13 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the review Ben. The security issue is well known to Apple and the subject of debate for = some time. OAuth states native applications SHOULD use the system browser to train = users not to expose credentials to applications. Apples approach to this point has been to recommend application = developers use web views to get around the feature/security issue of = insecure inter application communications. This is documenting the work around that Google , Ping, T-Mobile and = others have in production to work around the issue of multiple = applications being allowed to register the same custom scheme and not = prompting the user about what app to return to. Prompting the user as on Android is only a partial solution as users are = not perfect. So doing a proof for code is not a bad thing, and may = prevent new attacks on public clients. The OIDF NAPPS working group is working with MDM vendors, Google, = Microsoft (for there apps on other platforms), to develop a better = identity API approach for native apps. We are hoping that can provide a better long term solution for = platforms. I will also note that custom per IdP API solutions have not always = worked. Facebook has recently abandoned the custom solution apple = provided them with in iOS as apple was not able to keep up with changes = on the Facebook side. =46rom a protocol point of view this was the best we could come up with = to deal with the issue now. Inline. > On Jun 5, 2015, at 9:44 AM, Ben Laurie wrote: >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > Status: ready with issues. >=20 > It is disappointing that such a protocol must be introduced to work > around security deficiencies in application platforms - have these > security issues been reported to vendors? >=20 > Anyway, issues: >=20 > 1. Security consideration says: "Concatenating a publicly known value > to a code_challenge > (with 256 bits of entropy) and then hashing it with SHA256 would > actually reduce the entropy in the resulting code_verifier making it > easier for an attacker to brute force." This makes no sense. A > brute force attack would still require iteration of 2^256 inputs. How > is that easier? >=20 I can try an make it clearer that the 256 bits being referred to is the = total size of salt + secret. The point we were trying to make is that if the salt is included in the = 256 bit input then the attack space is reduced by the size of the nonce.=20= If you make the hash bigger then you are still better off making all the = entropy secret. An example would be having a 128 bit salt that is known and a 128 bit = secret. A brute force attack would require 2^128 inputs rather than = 2^256 inputs if it were all secret. This came from a request to explain why we don=E2=80=99t have a salt to = protect against rainbow table lookup, like passwords. > 2. The introduction says "No client secret is used (since public > clients cannot keep their secrets confidential.)". However, a client > secret is used. I suspect I know what is intended, but this should be > clarified. >=20 How about? 3) The attacker has access to the client id and client secret (if = provisioned). All native app client- instances use the same client id, and client secret. Secrets = provisioned in client binaries cannot be considered confidential. John B. > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --Apple-Mail=_627DD0D8-8E7A-46D7-BA53-662226EC8E13 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTA2MDUxMzU0MDlaMCMGCSqGSIb3DQEJBDEWBBSUx8gzMfJ9JzGv21jYghBq d8p6GzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCgR8M6Wz+JDjhwwbSlk6oAhE4yfxGJQmtcsk9TjTHIuWiau1unHPd8 jjIcURCUcQ17PLjxn4fzqttolSqrh2POHISSKJ9vbsKFX6xqR3BeyCy/0amZ7PCc9Mo3/FjJVsCR mqpZ+SAL/KwTXBSJ1OetvK7Ex1FiPXFy69Dd0u/rp1NCtHYx1yTmXkDrHkgd4FVavKVG197Ry/kt OmLb8vXfNor/ZQ7p1Xtn7jg25gcApCrw3TSbikf8F5u4lpcmt0YOVqLlEHriuSzR5mP2o0aXiBdC 60gSoDZMmd9aIlXp4Sozqa9CaGXbiJI4nBcH+6qMpgEf/FYCwn9BCItEciw8AAAAAAAA --Apple-Mail=_627DD0D8-8E7A-46D7-BA53-662226EC8E13-- From nobody Fri Jun 5 07:56:23 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4331B306C for ; Fri, 5 Jun 2015 07:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 lycPC6tmHqQf for ; Fri, 5 Jun 2015 07:56:21 -0700 (PDT) Received: from mail-vn0-x22f.google.com (mail-vn0-x22f.google.com [IPv6:2607:f8b0:400c:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC85D1B3067 for ; Fri, 5 Jun 2015 07:56:20 -0700 (PDT) Received: by vnbg190 with SMTP id g190so5330427vnb.8 for ; Fri, 05 Jun 2015 07:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MldGqQBUY79CyXPR7q+BMm4ipcrC5uf9HqbR+JUdnfg=; b=Xfo7BHh63BZqM+ZfPYGC/Itr8auO/LwdOrkFq9dCxPptDj/+ZXBTkv5wAS4ouYy5Nc CFJz+gLQ1r2uDHM9xiAMgfHo32YH6KR7ZWgSj3GDEeyAk6RquHiYwtnMWjzVgsAE67qv hJV6Zsqf3oDTj1pFOzBYddcVkCweJVDC9fZfLDyAjqy1NN2JoaYCGOizE3ta1xexdMo9 uD8hCTcS6GiS02tjnzITotHPR77cWVeogsRjnw8SichaiT1XPtQ/u5RPQkSjnlwExhsU gBOSoMZgFYpKvOc3CbDkisNZRzh85N8wCyC9rGtTTAHJ4GgcD8PPdEIBG8xMWQ4kRuSY 8xWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MldGqQBUY79CyXPR7q+BMm4ipcrC5uf9HqbR+JUdnfg=; b=Hcyob5GQfz3p1efAYxJfvBQRyOZ73SsEm/ebKjIck1gugsPxki7p4cFd6gewn+N+PA Os+xloV66syRYbpB9leJ19cUTZp9FH4eIQPPSTKjBpcNzRq3fusSwFIc45+RuMRZnLLK AkZ4fUxe5Dn2aEpFrA8VK/l59mAg1095eD0KSwZbDF9Tu/NKwhlakc77Zv4PIthuAp5k I0mRXGg7ZU2pebK+Dd9+s+doJRLgZK7tChtQ2gC4kMer/1/NhbdWydGywNkue5Jk6TEF zudb5WRxNCdfVkMmRaxIPOVVrxjHGrT56tP/iBs0M0OYrWeF7xSP0wwNFxFj1acIEYeN C15A== X-Gm-Message-State: ALoCoQmGL6uWURwPF5Ckh9t612rLjiCzWEdGkdZ9LozP82JWc+dQUKnQS4KGTUqXUA8b6G5YM9hv MIME-Version: 1.0 X-Received: by 10.52.139.168 with SMTP id qz8mr6815964vdb.82.1433516179822; Fri, 05 Jun 2015 07:56:19 -0700 (PDT) Received: by 10.52.76.6 with HTTP; Fri, 5 Jun 2015 07:56:19 -0700 (PDT) In-Reply-To: References: Date: Fri, 5 Jun 2015 15:56:19 +0100 Message-ID: From: Ben Laurie To: John Bradley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-oauth-spop.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-oauth-spop-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 14:56:22 -0000 On 5 June 2015 at 14:54, John Bradley wrote: > Thanks for the review Ben. > > The security issue is well known to Apple and the subject of debate for s= ome time. > > OAuth states native applications SHOULD use the system browser to train u= sers not to expose credentials to applications. > > Apples approach to this point has been to recommend application developer= s use web views to get around the feature/security issue of insecure inter = application communications. > > This is documenting the work around that Google , Ping, T-Mobile and othe= rs have in production to work around the issue of multiple applications bei= ng allowed to register the same custom scheme and not prompting the user ab= out what app to return to. > > Prompting the user as on Android is only a partial solution as users are = not perfect. So doing a proof for code is not a bad thing, and may prevent= new attacks on public clients. > > The OIDF NAPPS working group is working with MDM vendors, Google, Microso= ft (for there apps on other platforms), to develop a better identity API ap= proach for native apps. > We are hoping that can provide a better long term solution for platforms. > > I will also note that custom per IdP API solutions have not always worked= . Facebook has recently abandoned the custom solution apple provided them = with in iOS as apple was not able to keep up with changes on the Facebook s= ide. > > From a protocol point of view this was the best we could come up with to = deal with the issue now. > > Inline. >> On Jun 5, 2015, at 9:44 AM, Ben Laurie wrote: >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> Status: ready with issues. >> >> It is disappointing that such a protocol must be introduced to work >> around security deficiencies in application platforms - have these >> security issues been reported to vendors? >> >> Anyway, issues: >> >> 1. Security consideration says: "Concatenating a publicly known value >> to a code_challenge >> (with 256 bits of entropy) and then hashing it with SHA256 would >> actually reduce the entropy in the resulting code_verifier making it >> easier for an attacker to brute force." This makes no sense. A >> brute force attack would still require iteration of 2^256 inputs. How >> is that easier? >> > I can try an make it clearer that the 256 bits being referred to is the t= otal size of salt + secret. > > The point we were trying to make is that if the salt is included in the 2= 56 bit input then the attack space is reduced by the size of the nonce. > If you make the hash bigger then you are still better off making all the = entropy secret. > > An example would be having a 128 bit salt that is known and a 128 bit sec= ret. A brute force attack would require 2^128 inputs rather than 2^256 inp= uts if it were all secret. > > This came from a request to explain why we don=E2=80=99t have a salt to p= rotect against rainbow table lookup, like passwords. Ah, I see. Though you then have to explain why you are constraining to 256 bits... >> 2. The introduction says "No client secret is used (since public >> clients cannot keep their secrets confidential.)". However, a client >> secret is used. I suspect I know what is intended, but this should be >> clarified. >> > > How about? > > 3) The attacker has access to the client id and client secret (if provisi= oned). All native app client- > instances use the same client id, and client secret. Secrets provi= sioned in client binaries cannot be considered confidential. I think the issue is that "client secret" has meaning independent of OAuth, but you are using it in the sense that the OAuth standards use it - perhaps "OAuth client secret" would make this clearer? > > John B. > > >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From nobody Fri Jun 5 19:33:01 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57261A90C0 for ; Fri, 5 Jun 2015 19:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCkZaWlLd1ic for ; Fri, 5 Jun 2015 19:32:54 -0700 (PDT) Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com [209.85.220.171]) (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 63EA01A8F4E for ; Fri, 5 Jun 2015 19:32:54 -0700 (PDT) Received: by qkhg32 with SMTP id g32so49687840qkh.0 for ; Fri, 05 Jun 2015 19:32:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=IbayePrmpm4RAW27rOMIW0If1LJegngE7UQ9ObM/m5w=; b=Gal68DohvsIjqc230xYr28iu//laqFnlyvD04xdcH65eWJ50YR4742jVfNJD0tt1Dd CUgakqMWLFm1sKPFHiNl8QhrhmNIjOJm1mqrtsDFoVoZp0gis6sNsaIaRMzsDvBoL5Y5 8GcdQjcTIbIsc1YVldA18RkT6A5X0CS+yRep2wjSn3yZfM0fO8jAswnD17y3JVf/wSNX MAdBY8C/DBmY48Qa/wwSopTuUj3o7wk140luZtXM4Ai4DVgvqrPZLNFjvIbVtI2W6rAQ Jzvcem6dJDjWiIsRuVTTwj038ZdFvbM+xV3v6JoTu7eQbBPflhkZs4O76IrMw5uJv9yT ep4A== X-Gm-Message-State: ALoCoQlYeyNPv0wLnvmT/+SOlQA/oKu37tfI9iMlAfUQ4GzFftgGrdMtYi9iyCqggjvnWBvNHipB X-Received: by 10.55.26.165 with SMTP id l37mr12251889qkh.88.1433557973503; Fri, 05 Jun 2015 19:32:53 -0700 (PDT) Received: from [192.168.1.216] (186-106-183-184.baf.movistar.cl. [186.106.183.184]) by mx.google.com with ESMTPSA id 84sm4803507qha.47.2015.06.05.19.32.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jun 2015 19:32:52 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_1BCBDC07-BA85-4813-AB91-3366321DCE56"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: John Bradley In-Reply-To: Date: Fri, 5 Jun 2015 22:48:00 -0300 Message-Id: References: To: Ben Laurie X-Mailer: Apple Mail (2.2098) Archived-At: Cc: draft-ietf-oauth-spop.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-oauth-spop-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 02:32:56 -0000 --Apple-Mail=_1BCBDC07-BA85-4813-AB91-3366321DCE56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 inline > On Jun 5, 2015, at 11:56 AM, Ben Laurie wrote: >=20 > On 5 June 2015 at 14:54, John Bradley wrote: >> Thanks for the review Ben. >>=20 >> The security issue is well known to Apple and the subject of debate = for some time. >>=20 >> OAuth states native applications SHOULD use the system browser to = train users not to expose credentials to applications. >>=20 >> Apples approach to this point has been to recommend application = developers use web views to get around the feature/security issue of = insecure inter application communications. >>=20 >> This is documenting the work around that Google , Ping, T-Mobile and = others have in production to work around the issue of multiple = applications being allowed to register the same custom scheme and not = prompting the user about what app to return to. >>=20 >> Prompting the user as on Android is only a partial solution as users = are not perfect. So doing a proof for code is not a bad thing, and may = prevent new attacks on public clients. >>=20 >> The OIDF NAPPS working group is working with MDM vendors, Google, = Microsoft (for there apps on other platforms), to develop a better = identity API approach for native apps. >> We are hoping that can provide a better long term solution for = platforms. >>=20 >> I will also note that custom per IdP API solutions have not always = worked. Facebook has recently abandoned the custom solution apple = provided them with in iOS as apple was not able to keep up with changes = on the Facebook side. >>=20 >> =46rom a protocol point of view this was the best we could come up = with to deal with the issue now. >>=20 >> Inline. >>> On Jun 5, 2015, at 9:44 AM, Ben Laurie wrote: >>>=20 >>> I have reviewed this document as part of the security directorate's >>> ongoing effort to review all IETF documents being processed by the >>> IESG. These comments were written primarily for the benefit of the >>> security area directors. Document editors and WG chairs should = treat >>> these comments just like any other last call comments. >>>=20 >>> Status: ready with issues. >>>=20 >>> It is disappointing that such a protocol must be introduced to work >>> around security deficiencies in application platforms - have these >>> security issues been reported to vendors? >>>=20 >>> Anyway, issues: >>>=20 >>> 1. Security consideration says: "Concatenating a publicly known = value >>> to a code_challenge >>> (with 256 bits of entropy) and then hashing it with SHA256 would >>> actually reduce the entropy in the resulting code_verifier making = it >>> easier for an attacker to brute force." This makes no sense. A >>> brute force attack would still require iteration of 2^256 inputs. = How >>> is that easier? >>>=20 >> I can try an make it clearer that the 256 bits being referred to is = the total size of salt + secret. >>=20 >> The point we were trying to make is that if the salt is included in = the 256 bit input then the attack space is reduced by the size of the = nonce. >> If you make the hash bigger then you are still better off making all = the entropy secret. >>=20 >> An example would be having a 128 bit salt that is known and a 128 bit = secret. A brute force attack would require 2^128 inputs rather than = 2^256 inputs if it were all secret. >>=20 >> This came from a request to explain why we don=E2=80=99t have a salt = to protect against rainbow table lookup, like passwords. >=20 > Ah, I see. Though you then have to explain why you are constraining to > 256 bits=E2=80=A6 This wouldn't apply to the plain transform. For the S256 transform = having more than 256bits of entropy is just more work for no benefit. Later someone could define a SHA512 transform if they want to use more = entropy, though 256bits is probably enough unless some flaw is found in = SHA256. We did debate truncating the hash as 256bits is probably overkill for a = single use challenge at this point, but that would have introduced = possible implementation errors, and only provide a small saving of = message size. A asymmetric transform is also possible as an extension once we have = Token Binding completed and deployed, but that is future work. For the moment SHA 256 with 256bits of entropy for the input to generate = a key for a single use token, is infeasible to brute force.=20 >=20 >>> 2. The introduction says "No client secret is used (since public >>> clients cannot keep their secrets confidential.)". However, a client >>> secret is used. I suspect I know what is intended, but this should = be >>> clarified. >>>=20 >>=20 >> How about? >>=20 >> 3) The attacker has access to the client id and client secret (if = provisioned). All native app client- >> instances use the same client id, and client secret. Secrets = provisioned in client binaries cannot be considered confidential. >=20 > I think the issue is that "client secret" has meaning independent of > OAuth, but you are using it in the sense that the OAuth standards use > it - perhaps "OAuth client secret" would make this clearer? >=20 How about? 3) The attacker has access to the OAuth client id and OAuth client = secret (if provisioned). All OAuth native app client- instances use the same client id, and client secret. Secrets = provisioned in client binaries cannot be considered confidential. John B. >>=20 >> John B. >>=20 >>=20 >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --Apple-Mail=_1BCBDC07-BA85-4813-AB91-3366321DCE56 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTA2MDYwMTQ4MDFaMCMGCSqGSIb3DQEJBDEWBBRQk7JNNwtX6nweSLD71niT lzH3ITCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQClXFqHTuh2p9R4HI/hhZAv+w239huU6fNDUkiR0WPV2RrtTQuwQoMZ CUPTjjCxs0/OijkHg5qXK3YFHC2ju0lZtETyr84ka7UKG6RY1Rasqj2M9zzXe+4IZNcSaQalFVRA hTsV41OvgbyuFOZb3Y4eeAc8Yb/87ACmlZ9PyBLTbtMp/oT9yTmJa7aV7OqDbBC7j4MTG9Oqr7vU yHvPuCSeRvabJxfB0/B/ZH2A1DdDhvNzkLmQGZAlNk+n+KXLOFgW2rq6phiDzu43kDrC4uZNCmtD OMvfdjEChckz96l70F+EVgOrXwPrizWchURaBCsHTLBFxie2e1IYZPJEdNk3AAAAAAAA --Apple-Mail=_1BCBDC07-BA85-4813-AB91-3366321DCE56-- From nobody Sat Jun 6 02:03:07 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12AEF1B2AE5 for ; Sat, 6 Jun 2015 02:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 YM1p2wz9BT5A for ; Sat, 6 Jun 2015 02:03:05 -0700 (PDT) Received: from mail-vn0-x231.google.com (mail-vn0-x231.google.com [IPv6:2607:f8b0:400c:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 267E71B2AE2 for ; Sat, 6 Jun 2015 02:03:05 -0700 (PDT) Received: by vnbf129 with SMTP id f129so1659208vnb.2 for ; Sat, 06 Jun 2015 02:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=N8dgEG9dQEBCy6kx1PknrSU5OlOiOCGVhanH+pcoC4I=; b=J5Gh9TzFo6Gkd60GFnEoWJnOy7k6SrcjdFK7/5O4LUORIkonOPILfY5Dj9tbpmtvsa R6XfYRo33kqP3Znm2/wV88c+Vr01s+yKd1VFShT5ytneuG6BPeONnGE+g3MJQRDdg5LX HbD3R0UC9fEy1jMdiFhW/80QTKcSy+WnDvJowYsbrfoluLIB2J7x7PQDtYGnzPCiomMF wlg/dZuzpOUOrN/zhsEJ2lRr5JmuQpOePYLAhCVFXzH//hxPqAmIqQ3eTFgIo340m4nx 6SavVeF2Y7FCaTWSW1SeS1Hz1tY9eF3CnZObrHlQ960kVGj7GLObIxaWp2z1g5EDAicu JlMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=N8dgEG9dQEBCy6kx1PknrSU5OlOiOCGVhanH+pcoC4I=; b=TT9sBCFHXm3uz0G7C7GA04vkNXpMvqbvYqjmcBCMr/4tLHWuvNXffuIXEg55lw7k0E e9eTHank26kYD0vbZBzKif8cD1ubtU0TlxB12U8AaLgNa6V3bjeeRqA9rXw+VVulupIt Hgv/CktI6VTDqnlreC8f7DYpewOzr1KGIJJCoK3zVNrhhXUFsTL9p7h8B2sbASHlYQIa 72fGAFGIjLysRmlFjifyDCKlFZbmx51J/NgNHXfxZbWYjP35ycTZ+FntoqEGVYxqhWlf 6J/qKxWlURZkrKtvRgSM09LpDDvfqNysKCAQvAUw1MBBGvdwS+6gm1c/Oj2TpybPit3Y cB/g== X-Gm-Message-State: ALoCoQkMIyPMp1NcA1mdUfmQdEB5O4c3F8pIP/nGEutpAfpZw5Vi+RPO81JIAYS1hN+S/jMXFqvo MIME-Version: 1.0 X-Received: by 10.52.75.201 with SMTP id e9mr13171263vdw.33.1433581384185; Sat, 06 Jun 2015 02:03:04 -0700 (PDT) Received: by 10.52.76.6 with HTTP; Sat, 6 Jun 2015 02:03:04 -0700 (PDT) In-Reply-To: References: Date: Sat, 6 Jun 2015 10:03:04 +0100 Message-ID: From: Ben Laurie To: John Bradley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-oauth-spop.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-oauth-spop-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 09:03:07 -0000 On 6 June 2015 at 02:48, John Bradley wrote: > inline >> On Jun 5, 2015, at 11:56 AM, Ben Laurie wrote: >> >> On 5 June 2015 at 14:54, John Bradley wrote: >>> Thanks for the review Ben. >>> >>> The security issue is well known to Apple and the subject of debate for= some time. >>> >>> OAuth states native applications SHOULD use the system browser to train= users not to expose credentials to applications. >>> >>> Apples approach to this point has been to recommend application develop= ers use web views to get around the feature/security issue of insecure inte= r application communications. >>> >>> This is documenting the work around that Google , Ping, T-Mobile and ot= hers have in production to work around the issue of multiple applications b= eing allowed to register the same custom scheme and not prompting the user = about what app to return to. >>> >>> Prompting the user as on Android is only a partial solution as users ar= e not perfect. So doing a proof for code is not a bad thing, and may preve= nt new attacks on public clients. >>> >>> The OIDF NAPPS working group is working with MDM vendors, Google, Micro= soft (for there apps on other platforms), to develop a better identity API = approach for native apps. >>> We are hoping that can provide a better long term solution for platform= s. >>> >>> I will also note that custom per IdP API solutions have not always work= ed. Facebook has recently abandoned the custom solution apple provided the= m with in iOS as apple was not able to keep up with changes on the Facebook= side. >>> >>> From a protocol point of view this was the best we could come up with t= o deal with the issue now. >>> >>> Inline. >>>> On Jun 5, 2015, at 9:44 AM, Ben Laurie wrote: >>>> >>>> I have reviewed this document as part of the security directorate's >>>> ongoing effort to review all IETF documents being processed by the >>>> IESG. These comments were written primarily for the benefit of the >>>> security area directors. Document editors and WG chairs should treat >>>> these comments just like any other last call comments. >>>> >>>> Status: ready with issues. >>>> >>>> It is disappointing that such a protocol must be introduced to work >>>> around security deficiencies in application platforms - have these >>>> security issues been reported to vendors? >>>> >>>> Anyway, issues: >>>> >>>> 1. Security consideration says: "Concatenating a publicly known value >>>> to a code_challenge >>>> (with 256 bits of entropy) and then hashing it with SHA256 would >>>> actually reduce the entropy in the resulting code_verifier making it >>>> easier for an attacker to brute force." This makes no sense. A >>>> brute force attack would still require iteration of 2^256 inputs. How >>>> is that easier? >>>> >>> I can try an make it clearer that the 256 bits being referred to is the= total size of salt + secret. >>> >>> The point we were trying to make is that if the salt is included in the= 256 bit input then the attack space is reduced by the size of the nonce. >>> If you make the hash bigger then you are still better off making all th= e entropy secret. >>> >>> An example would be having a 128 bit salt that is known and a 128 bit s= ecret. A brute force attack would require 2^128 inputs rather than 2^256 i= nputs if it were all secret. >>> >>> This came from a request to explain why we don=E2=80=99t have a salt to= protect against rainbow table lookup, like passwords. >> >> Ah, I see. Though you then have to explain why you are constraining to >> 256 bits=E2=80=A6 > > This wouldn't apply to the plain transform. For the S256 transform havi= ng more than 256bits of entropy is just more work for no benefit. > > Later someone could define a SHA512 transform if they want to use more en= tropy, though 256bits is probably enough unless some flaw is found in SHA25= 6. > We did debate truncating the hash as 256bits is probably overkill for a s= ingle use challenge at this point, but that would have introduced possible = implementation errors, and only provide a small saving of message size. > > A asymmetric transform is also possible as an extension once we have Toke= n Binding completed and deployed, but that is future work. > > For the moment SHA 256 with 256bits of entropy for the input to generate = a key for a single use token, is infeasible to brute force. I agree. But we're not debating that, we're debating the claim that adding salt reduces attack cost. Which is only true if you add an artificial constraint on input size. > >> >>>> 2. The introduction says "No client secret is used (since public >>>> clients cannot keep their secrets confidential.)". However, a client >>>> secret is used. I suspect I know what is intended, but this should be >>>> clarified. >>>> >>> >>> How about? >>> >>> 3) The attacker has access to the client id and client secret (if provi= sioned). All native app client- >>> instances use the same client id, and client secret. Secrets prov= isioned in client binaries cannot be considered confidential. >> >> I think the issue is that "client secret" has meaning independent of >> OAuth, but you are using it in the sense that the OAuth standards use >> it - perhaps "OAuth client secret" would make this clearer? >> > > How about? > > 3) The attacker has access to the OAuth client id and OAuth client secret= (if provisioned). All OAuth native app client- > instances use the same client id, and client secret. Secrets provis= ioned in client binaries cannot be considered confidential. Fine. > > John B. >>> >>> John B. >>> >>> >>>> _______________________________________________ >>>> secdir mailing list >>>> secdir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/secdir >>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From nobody Sat Jun 6 08:52:40 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57EA1B334D for ; Sat, 6 Jun 2015 08:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzLBkQaB5POR for ; Sat, 6 Jun 2015 08:52:30 -0700 (PDT) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (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 6D69E1B334B for ; Sat, 6 Jun 2015 08:52:30 -0700 (PDT) Received: by qcnj1 with SMTP id j1so13178244qcn.0 for ; Sat, 06 Jun 2015 08:52:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=enVdY0rgRxmaI+og9u3RJX65Mv1JV7EOEgfztldCOmU=; b=jH1QFDbUFj7EpdCuSSbZokjc4ie9tq2LVYWcAI8zBhA8uEUz1v4T4N+AEvA2DsZ1f+ 62lNCX83+h4dU6DuOCW6fHIa9ihJYjuU/MqyA4odeD+P7n1peaRPrH3TADkfwZjPvjMi gDGG6rxZAHNW5hXuBAz+CG99UGlU5EmyrtM1zRfMb4TL2gU/Oo9sj5qJQKrpJfK9qJjn E571c/9tRTvmWBq/jsEUzU1GTcXAxrKZqydVGeKijLmTiyFSqk2LP7pMWy5gOjqvNBFw vOTbNLIEycYVLqvLnCSsD13+ShkMRmFuwNvXHN6LOAbq6aLST30D5+3rY1/x5rTIGDl1 TPzg== X-Gm-Message-State: ALoCoQnBT3/YQ3C/p+AbKKvXl9+YM/E42ZYCOK82aQKDnafApMuDYrtBsnrL3W2bhhdlRKZimmf4 X-Received: by 10.140.149.76 with SMTP id 73mr10873724qhv.94.1433605949686; Sat, 06 Jun 2015 08:52:29 -0700 (PDT) Received: from [192.168.1.216] (186-79-85-97.baf.movistar.cl. [186.79.85.97]) by mx.google.com with ESMTPSA id 4sm5479235qku.20.2015.06.06.08.52.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Jun 2015 08:52:28 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8DDF2E8C-FD06-42A8-9365-06E7D4E1BE8B"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: John Bradley In-Reply-To: Date: Sat, 6 Jun 2015 12:52:22 -0300 Message-Id: <0849D10A-7DD4-477E-A048-935821E4E427@ve7jtb.com> References: To: Ben Laurie X-Mailer: Apple Mail (2.2098) Archived-At: Cc: draft-ietf-oauth-spop.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-oauth-spop-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 15:52:33 -0000 --Apple-Mail=_8DDF2E8C-FD06-42A8-9365-06E7D4E1BE8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ben, I have updated the draft based on your feedback. I changed the wording in the security consideration to say that adding a = salt doesn=E2=80=99t increase the workload for an attacker given 256 = bits of entropy and a sha256 hash. Let me know if that wording works for you. John B. > On Jun 6, 2015, at 6:03 AM, Ben Laurie wrote: >=20 > On 6 June 2015 at 02:48, John Bradley wrote: >> inline >>> On Jun 5, 2015, at 11:56 AM, Ben Laurie wrote: >>>=20 >>> On 5 June 2015 at 14:54, John Bradley wrote: >>>> Thanks for the review Ben. >>>>=20 >>>> The security issue is well known to Apple and the subject of debate = for some time. >>>>=20 >>>> OAuth states native applications SHOULD use the system browser to = train users not to expose credentials to applications. >>>>=20 >>>> Apples approach to this point has been to recommend application = developers use web views to get around the feature/security issue of = insecure inter application communications. >>>>=20 >>>> This is documenting the work around that Google , Ping, T-Mobile = and others have in production to work around the issue of multiple = applications being allowed to register the same custom scheme and not = prompting the user about what app to return to. >>>>=20 >>>> Prompting the user as on Android is only a partial solution as = users are not perfect. So doing a proof for code is not a bad thing, = and may prevent new attacks on public clients. >>>>=20 >>>> The OIDF NAPPS working group is working with MDM vendors, Google, = Microsoft (for there apps on other platforms), to develop a better = identity API approach for native apps. >>>> We are hoping that can provide a better long term solution for = platforms. >>>>=20 >>>> I will also note that custom per IdP API solutions have not always = worked. Facebook has recently abandoned the custom solution apple = provided them with in iOS as apple was not able to keep up with changes = on the Facebook side. >>>>=20 >>>> =46rom a protocol point of view this was the best we could come up = with to deal with the issue now. >>>>=20 >>>> Inline. >>>>> On Jun 5, 2015, at 9:44 AM, Ben Laurie wrote: >>>>>=20 >>>>> I have reviewed this document as part of the security = directorate's >>>>> ongoing effort to review all IETF documents being processed by the >>>>> IESG. These comments were written primarily for the benefit of = the >>>>> security area directors. Document editors and WG chairs should = treat >>>>> these comments just like any other last call comments. >>>>>=20 >>>>> Status: ready with issues. >>>>>=20 >>>>> It is disappointing that such a protocol must be introduced to = work >>>>> around security deficiencies in application platforms - have these >>>>> security issues been reported to vendors? >>>>>=20 >>>>> Anyway, issues: >>>>>=20 >>>>> 1. Security consideration says: "Concatenating a publicly known = value >>>>> to a code_challenge >>>>> (with 256 bits of entropy) and then hashing it with SHA256 would >>>>> actually reduce the entropy in the resulting code_verifier making = it >>>>> easier for an attacker to brute force." This makes no sense. A >>>>> brute force attack would still require iteration of 2^256 inputs. = How >>>>> is that easier? >>>>>=20 >>>> I can try an make it clearer that the 256 bits being referred to is = the total size of salt + secret. >>>>=20 >>>> The point we were trying to make is that if the salt is included in = the 256 bit input then the attack space is reduced by the size of the = nonce. >>>> If you make the hash bigger then you are still better off making = all the entropy secret. >>>>=20 >>>> An example would be having a 128 bit salt that is known and a 128 = bit secret. A brute force attack would require 2^128 inputs rather than = 2^256 inputs if it were all secret. >>>>=20 >>>> This came from a request to explain why we don=E2=80=99t have a = salt to protect against rainbow table lookup, like passwords. >>>=20 >>> Ah, I see. Though you then have to explain why you are constraining = to >>> 256 bits=E2=80=A6 >>=20 >> This wouldn't apply to the plain transform. For the S256 transform = having more than 256bits of entropy is just more work for no benefit. >>=20 >> Later someone could define a SHA512 transform if they want to use = more entropy, though 256bits is probably enough unless some flaw is = found in SHA256. >> We did debate truncating the hash as 256bits is probably overkill for = a single use challenge at this point, but that would have introduced = possible implementation errors, and only provide a small saving of = message size. >>=20 >> A asymmetric transform is also possible as an extension once we have = Token Binding completed and deployed, but that is future work. >>=20 >> For the moment SHA 256 with 256bits of entropy for the input to = generate a key for a single use token, is infeasible to brute force. >=20 > I agree. But we're not debating that, we're debating the claim that > adding salt reduces attack cost. Which is only true if you add an > artificial constraint on input size. >=20 >>=20 >>>=20 >>>>> 2. The introduction says "No client secret is used (since public >>>>> clients cannot keep their secrets confidential.)". However, a = client >>>>> secret is used. I suspect I know what is intended, but this should = be >>>>> clarified. >>>>>=20 >>>>=20 >>>> How about? >>>>=20 >>>> 3) The attacker has access to the client id and client secret (if = provisioned). All native app client- >>>> instances use the same client id, and client secret. Secrets = provisioned in client binaries cannot be considered confidential. >>>=20 >>> I think the issue is that "client secret" has meaning independent of >>> OAuth, but you are using it in the sense that the OAuth standards = use >>> it - perhaps "OAuth client secret" would make this clearer? >>>=20 >>=20 >> How about? >>=20 >> 3) The attacker has access to the OAuth client id and OAuth client = secret (if provisioned). All OAuth native app client- >> instances use the same client id, and client secret. Secrets = provisioned in client binaries cannot be considered confidential. >=20 > Fine. >=20 >>=20 >> John B. >>>>=20 >>>> John B. >>>>=20 >>>>=20 >>>>> _______________________________________________ >>>>> secdir mailing list >>>>> secdir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/secdir >>>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --Apple-Mail=_8DDF2E8C-FD06-42A8-9365-06E7D4E1BE8B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTA2MDYxNTUyMjJaMCMGCSqGSIb3DQEJBDEWBBSmqCvPqpoinX9SZV8WbZob jYS7JzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAssE924E3b4UX7gih+L8U1aMkHW0jRjpAPUzvyHGE/BOZ1A+3rvPa0 lFTcZBW4OaWh7rBGhMjIHGoitMsmpeoxkAoAnNMQm6C1gTl2LV95TZH52tDx+gG4uqdUtM4vj9L0 Shy0CDM5sxZNDSR7f5jw7q0XQomHrUaX+Yh4uRZf6eYajRG5ZQ1ZG33mPFwvuR0bIl7lgD9JhM1G QfJT/5r41KPkPMTk58F+1ZwqFRf5lmUi2xmbpyuIN3Q110Umjn81y/sLAJ+JArUi3HuVDj3Ms4RK MQ09UlxSG/mhwJW1Cg+Emg/utRffjoqizfAq0KlHHJRkVHiaEWwUBS7+mAMeAAAAAAAA --Apple-Mail=_8DDF2E8C-FD06-42A8-9365-06E7D4E1BE8B-- From nobody Sat Jun 6 22:11:17 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D50B1A87AA; Sat, 6 Jun 2015 22:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRD6CMS7cZe5; Sat, 6 Jun 2015 22:11:15 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::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 9E3AC1A87A9; Sat, 6 Jun 2015 22:11:14 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so63794512lbb.3; Sat, 06 Jun 2015 22:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=FLd4cLYaithq9VvnVEv59hHGAN3JqWFyFJ/fvb7MR2M=; b=IloAUbKg+1v5fcuYedlsY1Aae/1IH0beSfXBdAuI1/z2FcTweJoZpN8ymeyq1+Q9WO PV4PsUdTtxZbjB3NY+UbfyrlIO5qAp8gEME9d1psvUhC0f1qPk6R9AadzFHEiFNVcf8O iK4bvPq+Sho4U6JF4vHHVbU4JZkN+MAEz9/L+NwEFwJQtjS3Z7NmiDZToeJKOBUGwp0e f6JMeuZ7yGzX0suXlg6dW1iJmfN0VdGOsLMNnzz69yf6DCt6g1lpmTjPabW0X3VgFsPC 3gY83zmkVjdQBEyD+RCW+JWShMskVgbAApvQ6bfawWYLoIXnGupgBAsn/iZPVpOXEJVz Y6+g== MIME-Version: 1.0 X-Received: by 10.152.1.40 with SMTP id 8mr5029091laj.56.1433653873113; Sat, 06 Jun 2015 22:11:13 -0700 (PDT) Received: by 10.112.133.68 with HTTP; Sat, 6 Jun 2015 22:11:13 -0700 (PDT) Date: Sat, 6 Jun 2015 22:11:13 -0700 Message-ID: From: Radia Perlman To: "secdir@ietf.org" , The IESG , draft-ietf-sipcore-refer-clarifications.all@tools.ietf.org Content-Type: multipart/alternative; boundary=089e013c6b90d67da20517e68df6 Archived-At: Subject: [secdir] Secdir review of draft-ietf-sipcore-refer-clarifications-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 05:11:16 -0000 --089e013c6b90d67da20517e68df6 Content-Type: text/plain; charset=UTF-8 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is a clarifications document describing the changes to RFC3515 that were implied by the publication of RFC6665. The document is fairly opaque to readers not familiar with those two RFCs (including me), but its claim that it does not change the security considerations for RFC3515 beyond those already stated in RFC6665 seem highly plausible. It's a little surprising that the contentof this document wasn't folded into RFC6665, but assuming that document was adequately reviewed, this one should be fine. Radia --089e013c6b90d67da20517e68df6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have review= ed this document as part of the security directorate's ongoingeffort to review all IETF documents being processed by the IESG.= =C2=A0 These
comments were written primarily for the b= enefit of the security area
directors.=C2=A0 Document ed= itors and WG chairs should treat these comments just
lik= e any other last call comments.

This is a clarifications document describing the changes= to RFC3515 that
were implied by the publication of RFC6= 665. The document is fairly opaque to
readers not famili= ar with those two RFCs (including me), but its claim that
it does not change the security considerations for RFC3515 beyond those=
already stated in RFC6665 seem highly plausible. It'= ;s a little surprising
that the contentof this document = wasn't folded into RFC6665, but assuming
that docume= nt was adequately reviewed, this one should be fine.

Radia
--089e013c6b90d67da20517e68df6-- From nobody Mon Jun 8 08:00:46 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CA81B2E82; Mon, 8 Jun 2015 08:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xznKBK0JsXD0; Mon, 8 Jun 2015 08:00:43 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 892071A88F1; Mon, 8 Jun 2015 08:00:43 -0700 (PDT) Received: by wibut5 with SMTP id ut5so89394954wib.1; Mon, 08 Jun 2015 08:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=47pTolTck1pYsje1fV2tH/85tW/Ntm6VcZOb8OTuEjk=; b=tmLfdveXMClQjcbD4zz242JzcZiP6lVeN7MtQXf8TJ13ZxJoNN6EauycQ0yIFAzvMq qpxKZcXuSSLG9sVMqzdtZLLaq1VRAr/3RSgHmqng3rU3zpOErjeEAVk26eYoeOHSQMzL dgMKWuOhEM/fY8TRQ4Npzejr5EPH6mSRBKNnb/5Zi8h8Plo3lXfjUTRt9SD50pHXcfDk Url52UAJsCTbORc1Amtg4yZHybn65SGsXPwcegAdLP2cTOsTNNQah9Yndxm+hjsKv4zy oqNbQk1QH3seBy7nLqJXa42Grown9VO8Jn49vl3SPvtM/gnppTrDbMgIbmTGA8vsa+OU E6Wg== X-Received: by 10.194.240.8 with SMTP id vw8mr31672157wjc.114.1433775642304; Mon, 08 Jun 2015 08:00:42 -0700 (PDT) Received: from [172.24.251.11] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id cd9sm4704031wjc.34.2015.06.08.08.00.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Jun 2015 08:00:41 -0700 (PDT) From: Yoav Nir Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <06A85300-7DD9-4AC4-A5F5-EE9FE77F7466@gmail.com> Date: Mon, 8 Jun 2015 18:00:38 +0300 To: secdir , The IESG , draft-ietf-pcp-anycast.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [secdir] SecDir Review of draft-ietf-pcp-anycast-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 15:00:45 -0000 Hi. I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. TL;DR: Ready (with a question) The document describes an alternative method for nodes behind a = middlebox (such as NAT device or firewall) to contact the middlebox in = order to manage port allocation. Existing methods (described in RFC 6887 = and 7291 respectively) are to either assume that the default router is = the device (suitable for small networks) or specify the middlebox = address in a DHCP option (suitable for larger networks). This document proposes a third alternative: use of a well-known anycast = address. Sending a request to that anycast address will ensure delivery = to the closest service address (which may or may not be co-located with = the middlebox) by the routing on the network, supported by either BGP or = IGP. There are two specific concerns about this method (other than the usual = anycast or pcp concerns). The first is that information about the = internal network might leak to a PCP service outside the network. = Whereas a failure of a service whose address is given in DHCP will = result in black-holed packets, failure of a service with an anycast = address will cause the packets to be forwarded to some random PCP server = on the Internet. Section 5.1 discusses this and recommends filtering in = perimeter gateways and reduced TTL. I believe this addresses that threat = adequately. The other specific concern is that a rogue machine would push routes to = advertise itself as a PCP service, hijacking PCP traffic and causing = network outages. Section 5.2 deals with this issue. The section makes = the claim that within the first network segment, the nodes do not use = dynamic routing protocols, so an attack there is equivalent to = impersonating the default router. Outside the first segment, routing = protocols are used, and there is a need for routing security anyway. In = both cases an attacker capable of conducting these attacks can do a lot = worse than impersonating a PCP service. I find this argument almost convincing. What is still bothering me is = the question of whether the more damaging attacks would be discovered = immediately, whereas simply advertising a route to the anycast address = can =E2=80=9Cfly under the radar=E2=80=9D so that the attacker can = become the PCP server undetected. I don=E2=80=99t have a firm attack in = mind, just a mild concern. Yoav From nobody Mon Jun 8 08:47:08 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8CF1B2F87; Mon, 8 Jun 2015 08:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tK1oM0UBbjnz; Mon, 8 Jun 2015 08:46:59 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F00871B2F73; Mon, 8 Jun 2015 08:46:31 -0700 (PDT) Received: by oigz2 with SMTP id z2so32745638oig.1; Mon, 08 Jun 2015 08:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=wysmFZRSRrr97qDayB6EZE12aQsG7Jqtib4dNPbzBFs=; b=PGEW7PPU1CVKwoDrf2CMPcm6hnM3G1mCuSPH2T9WpvFxra6nl7Ffbafd40+3PMfnA3 8dcIIhGAattfNLwIVfJYJesn7z3hYta9dTKNyLn3HKhLN0YBVDO8FLkQOryDT2R6yvZD ekUEEfZOKOxUwY8HcMDS1NlCOzFGRVeZdGjxa1bmOmP2BCI9ZQcmV0Bin6L4IdCBh+C4 oOotCg+r2fCIQyLuTnQ9KpCswyKXUYQJpscvoOY7wa5YI5pQzoV/yHdMaeaHiMIK1KJJ 09fxvJyffm5aTIt5xTDKjq+ZKy0qYp2QAdJXTcwzZvzJVVnk5vlXYQ5YbLvcZ0ZlzHv6 +8nQ== X-Received: by 10.202.212.147 with SMTP id l141mr11865531oig.89.1433778391344; Mon, 08 Jun 2015 08:46:31 -0700 (PDT) Received: from adams-mac-mini.attlocal.net ([2602:306:3406:4830:693d:fac2:3df1:e032]) by mx.google.com with ESMTPSA id sm8sm2003006obb.13.2015.06.08.08.46.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Jun 2015 08:46:30 -0700 (PDT) From: "Adam W. Montville" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 8 Jun 2015 10:46:29 -0500 To: The IESG , secdir@ietf.org, draft-ietf-jose-jwk-thumbprint.all@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [secdir] sector review of draft-ietf-jose-jwk-thumbprint-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 15:47:05 -0000 Hi, I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. I believe the document is ready with (potential) issues. The =E2=80=9Cwit= h issues=E2=80=9D might be due to ignorance on my part. The draft does = a very good job of explaining the canonical form of a JSON Web Key that = can be used for establishing a thumbprint under varying circumstances, = complete with what I found to be helpful examples. The primary issue I have is that it=E2=80=99s unclear how relying = parties are going to know which hash algorithm has been used. The = examples use SHA-256, but I=E2=80=99m not seeing where SHA-256 might be = specified as a MUST or even a SHOULD. Moreover, the example output = ultimately shows only the Base-64 encoding of the resulting hash, which = says nothing about the algorithm used to identify a key. Additionally, in Section 4, =E2=80=9CJSON and Unicode Considerations=E2=80= =9D some =E2=80=9Cshould=E2=80=9Ds are used, but I=E2=80=99m not reading = them as SHOULDs. Should they be SHOULDs? For example, the start of the = third paragraph in that section: =E2=80=9Cif new JWK members are defined = that use non-ASCII member names, their definitions should specify the = exact Unicode code point sequences used to represent them.=E2=80=9D = It=E2=80=99s not clear to me whether this is a strong statement or just = a recommendation - it seems that this draft could help the future by = making stronger statements to encourage future interoperability. Kind regards, Adam= From nobody Tue Jun 9 06:51:48 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE301B2C4C; Tue, 9 Jun 2015 06:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IwZ0w0yk_jJ; Tue, 9 Jun 2015 06:51:41 -0700 (PDT) Received: from smtp2.infineon.com (smtp2.infineon.com [217.10.52.18]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8045F1B2C5E; Tue, 9 Jun 2015 06:50:41 -0700 (PDT) X-SBRS: None Received: from unknown (HELO mucxv001.muc.infineon.com) ([172.23.11.16]) by smtp2.infineon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jun 2015 15:50:41 +0200 Received: from MUCSE607.infineon.com (mucltm.muc.infineon.com [172.23.8.247]) by mucxv001.muc.infineon.com (Postfix) with ESMTPS; Tue, 9 Jun 2015 15:50:39 +0200 (CEST) Received: from MUCSE613.infineon.com (172.23.7.84) by MUCSE607.infineon.com (172.23.7.108) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 9 Jun 2015 15:50:38 +0200 Received: from MUCSE609.infineon.com (172.23.7.110) by MUCSE613.infineon.com (172.23.7.84) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 9 Jun 2015 15:50:38 +0200 Received: from MUCSE609.infineon.com ([172.23.103.71]) by MUCSE609.infineon.com ([172.23.103.71]) with mapi id 15.00.0995.032; Tue, 9 Jun 2015 15:50:38 +0200 From: To: , , Thread-Topic: SecDir Review of draft-ietf-rtcweb-stun-consent-freshness-14 Thread-Index: AdCiuP9HBMF1kiH7Sn2XX8QyBIo+fw== Date: Tue, 9 Jun 2015 13:50:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.23.8.247] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0A98_01D0A299.B98CE8E0" MIME-Version: 1.0 Archived-At: Subject: [secdir] SecDir Review of draft-ietf-rtcweb-stun-consent-freshness-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 13:51:45 -0000 ------=_NextPart_000_0A98_01D0A299.B98CE8E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0A99_01D0A299.B98CE8E0" ------=_NextPart_001_0A99_01D0A299.B98CE8E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. In my view, this document is Ready with Issues. The purpose of the document is to reduce flooding attacks by defining a standard method for WebRTC endpoints to obtain "consent to send" before sending traffic to another endpoint and continuously while sending. I have a few questions: 1) Will misbehaving or malicious endpoints obey this? If not, what's the point? If only a few polite endpoints go to the trouble of obtaining consent to send, I don't see how this will solve anything. 2) Section 5.1 says "An endpoint MUST NOT send data other than the messages used to establish consent unless the receiving endpoint has consented to receive data." This seems to be a long way from the present reality. How many applications implement this requirement? Or will this feature somehow be built into the OS? 3) The document says that "Consent expires after 30 seconds." And "Implementations SHOULD set a default interval of 5 seconds" for retransmitting STUN binding requests (requests for consent). If I understand this correctly, every pair of endpoints with an active connection will now exchange STUN binding request and response pairs in each direction every five seconds. That works out to about one packet per second transit for every connection. That seems like a lot of overhead. Is the benefit adequate? Other than these issues, the document seems ready. Thanks, Steve ------=_NextPart_001_0A99_01D0A299.B98CE8E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have = reviewed this document as part of the security directorate's ongoing = effort to review all IETF documents being processed by the IESG.  = These comments were written primarily for the benefit of the security = area directors.  Document editors and WG chairs should treat these = comments just like any other last call comments.

 

In my view, = this document is Ready with Issues.

 

The purpose = of the document is to reduce flooding attacks by defining a standard = method for WebRTC endpoints to obtain “consent to send” = before sending traffic to another endpoint and continuously while = sending. I have a few questions:

 

1)      = Will misbehaving or malicious endpoints obey = this? If not, what’s the point? If only a few polite endpoints go = to the trouble of obtaining consent to send, I don’t see how this = will solve anything.

 

2)      = Section 5.1 says “An endpoint MUST NOT = send data other than the messages used to establish consent unless the = receiving endpoint has consented to receive data.” This seems to = be a long way from the present reality. How many applications implement = this requirement? Or will this feature somehow be built into the = OS?

 

3)      = The document says that “Consent expires = after 30 seconds.” And “Implementations SHOULD set a default = interval of 5 seconds” for retransmitting STUN binding requests = (requests for consent). If I understand this correctly, every pair of = endpoints with an active connection will now exchange STUN binding = request and response pairs in each direction every five seconds. That = works out to about one packet per second transit for every connection. = That seems like a lot of overhead. Is the benefit = adequate?

 

Other than these issues, the document seems = ready.

 

Thanks,

 

Steve

 

------=_NextPart_001_0A99_01D0A299.B98CE8E0-- ------=_NextPart_000_0A98_01D0A299.B98CE8E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM7jCCA+4w ggLWoAMCAQICEGsk517Bqmu0TbjoYC/BbAIwDQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCZGUx ITAfBgNVBAoTGEluZmluZW9uIFRlY2hub2xvZ2llcyBBRzErMCkGA1UEAxMiSW5maW5lb24gVGVj aG5vbG9naWVzIEFHIFJvb3QgQ0EgMjAeFw0xMTA3MjYxMzEyMjBaFw0zNjA3MjYxMzIyMjBaMF0x CzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcxKzApBgNVBAMT IkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBSb290IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDMQpw2+wMM1Zu9gvlmBJSMi0GGkpvNL+RUfdNatlMGrliwyaCEB+HZzZP9CLys cLIglTKWeANzKozlAjE4ubdO/Y1IBmnuJMDW2lI73bZOwR2Y0shwmO1esRd2EyGCtVa9RgKa7HD3 pEHJAXlu9+IejoYv94lF80E/5jsNMeczlwUV7cF3NwXQKMoRd1BHGtFnwwOqIVELmDC/coQM6UXe MlUzYpfVJyqdCiNHU0wPzFNyeDObgDOLNIH222OuRR5wsDvmDiP/6j8QPTBJ71uGWlFE6B7cVvAO QXVDCZYLpfQLkNFnG8BElOH7gSzuAiBvQtoERRC1QyZZC2MEValdAgMBAAGjgakwgaYwDgYDVR0P AQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQEwHQYDVR0OBBYEFDhv1fR35slaIStRFWrWIKsC DacVMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3Jvb3RjYTIvcm9v dGNhMi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwEQYDVR0gBAowCDAGBgRVHSAAMA0GCSqGSIb3DQEB BQUAA4IBAQCsiCetpToA0t9yFxPkiw1pekvEPPEeOqsMEGa/Xf6JyqZCC0lSAyu9Uo6l6YSCAb73 f0TjNH0JDNApW2q6556qloVM0almOTirDaM+R8bJzeRg7xHeZriif9QWfA9czBfK6MSDTDULatcH mJwNznVQWuRBefTg/txo0OuPvvmbuGVT8hhdEf1fu0rcX7fE1X7zP27opZ3DjMk+ocu9MRk3L+Cw ISxiCfo2af0hWLZBTuQPqODjx73waxOAK317QwRC4m84BwUEZ3IR3CfvK3ukk6UQ8Pgl6SmDdzNw KGVNo+tNELKtgW125xQ5znatvPJQjYJjhB0XikvWjdKJL48PMIIEIzCCAwugAwIBAgIKYR4k+gAA AAAAAjANBgkqhkiG9w0BAQUFADBdMQswCQYDVQQGEwJkZTEhMB8GA1UEChMYSW5maW5lb24gVGVj aG5vbG9naWVzIEFHMSswKQYDVQQDEyJJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcgUm9vdCBDQSAy MB4XDTExMDcyNzEyMzIwNVoXDTI2MDcyNzEyNDIwNVowXTELMAkGA1UEBhMCZGUxITAfBgNVBAoT GEluZmluZW9uIFRlY2hub2xvZ2llcyBBRzErMCkGA1UEAxMiSW5maW5lb24gVGVjaG5vbG9naWVz IEFHIFVzZXIgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKBHZyb03ScBt//g 4A4cOg5bRHXlpCBOyzJo/X4sMpuxu+47KFkVAIWhUlyhVk4f22+EDos6Ley7/10Pl7VNBuTj0i07 P5vjTbT/CgshA3mcRb4xqyXZx4Eh/rnMicAlXQ8OUhbg+uBMjBOuvQrhXg2epP6+etKdg6LlXDrD edZflpmIGvn8sgGyfbAiH0Wy/HGJngg6dncHacL6hPzGTrhR4bJwTnogxhN7NaDmuU1OxzKjsPc7 cidAmTtIlGpEfXj162C8GZ6vQjmBjH+ZqEdnz86IPGnUHb4Ifoa/GVzSlH0hPtMmybczi/BAcAQO obiKhfCbpNU8/nXhuiQ3kbcCAwEAAaOB5DCB4TALBgNVHQ8EBAMCAYYwHQYDVR0OBBYEFBoYmNi4 E/3bHsoMirMTA3B3wxeWMB8GA1UdIwQYMBaAFDhv1fR35slaIStRFWrWIKsCDacVMDwGA1UdHwQ1 MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3Jvb3RjYTIvcm9vdGNhMi5jcmwwEgYD VR0TAQH/BAgwBgEB/wIBADBABgNVHSAEOTA3MDUGCyqCFABEChQBAQEBMCYwJAYIKwYBBQUHAgEW GGh0dHBzOi8vY3BzLmluZmluZW9uLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAbOjg2haQMCPP0ZcS 1+hd0teYaBpi2LpwADGVyFAUO2UuPKGxAfYxWf3/v0FNW2IOhNKj8w3f076sKkeSlb6WiZZIe+ao kG2H6AimMIlhvv4GGAFHzQLVclXIz9jM7H4fH/wA/gHE4wDE1dvsGVjeM2fEjwTOtNrPzGF9SF1s NyJy8a2AZ83b6J6WIN72Jg2KXXQuVsa61/q2C5AAMfXLL4shuWN1JnYO03PBUjYWxqNdcETppKhc swaIZJ0MjKDttzuT9IntFeoOYMJx27KGowOqMDbmRoXRGWZahO4m4UkjIo9uzMX7U5EQymoMiVJc Ndp3qT5b48QXhmDe7Cmd4DCCBNEwggO5oAMCAQICAn7aMA0GCSqGSIb3DQEBBQUAMF0xCzAJBgNV BAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dpZXMgQUcxKzApBgNVBAMTIkluZmlu ZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDIwHhcNMTQwNTA4MDYzMDI0WhcNMTkwNTA4MDYz MDI0WjCBgjELMAkGA1UEBhMCVVMxMjAwBgNVBAoTKUluZmluZW9uIFRlY2hub2xvZ2llcyBOb3J0 aCBBbWVyaWNhIENvcnAuMRYwFAYDVQQDEw1TdGVwaGVuIEhhbm5hMScwJQYJKoZIhvcNAQkBFhhT dGV2ZS5IYW5uYUBpbmZpbmVvbi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCA FtObO7F+pUxS4qh2dVM0xI9zDZquunmkxtfb7TG3IXsd7NaqDYBXI67jA3WfxI/DHp3ub0ZuQ3qv JLzsdCr5FQgDDh7MBvesFRoYa6RHT/dUWE9SGjexFquQRHP75ZYxNBw3zOYpr87XFE1rsjXIQp7s 2ehfZLiIEr3NkyzjeAqBw6EfT65Dy598EWFon2Ky/QfJsDmBAfTc4+Ews2suhvS8x2pqSwHtOLNF PK2zD+zFsBdZJyv+ZawWaLO/B8aAwavVBDYBd3S5/4FJKEG8ednZpetkNQ2aMMg3Lnay8/t9UvcY jS810qTNVOEfiyZBzlJi53I4Nhw35UC6o1P5AgMBAAGjggFzMIIBbzA/BgNVHREEODA2gRhTdGV2 ZS5IYW5uYUBpbmZpbmVvbi5jb22BGlN0ZXBoZW4uSGFubmFAaW5maW5lb24uY29tMEAGA1UdIAQ5 MDcwNQYLKoIUAEQKFAEBAQEwJjAkBggrBgEFBQcCARYYaHR0cHM6Ly9jcHMuaW5maW5lb24uY29t MDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaW5maW5lb24uY29tL3VzZXJjYTIvdXNlcmNh Mi5jcmwwDgYDVR0PAQH/BAQDAgTwMBMGA1UdJQQMMAoGCCsGAQUFBwMEMEcGCCsGAQUFBwEBBDsw OTA3BggrBgEFBQcwAoYraHR0cDovL2NybC5pbmZpbmVvbi5jb20vdXNlcmNhMi91c2VyY2EyLmNy dDAfBgNVHSMEGDAWgBQaGJjYuBP92x7KDIqzEwNwd8MXljAdBgNVHQ4EFgQUhs576DHwRkp1mWLi fTZ7b4yVe+UwDQYJKoZIhvcNAQEFBQADggEBADKEDQXoKMcxN3zhhg3gfoVJII4Y8BWdjTzs5q2D bivs+8Ic8v/7KT3a61Gmz+BJx/8kWTe8LbJtk3GM0ui1MLUo8110r7qnvNtTtM8hYAuQGXYDGhkh H2PmZG7VSgB6G6DFNLA/017Uqvz6UiRLTUJcge7VJvk40cxJ1Mzs240+JVW9nLb/Fn+zI5KJj573 tXv7LTNVK2whVD7fJ3s07JGh75QYw5NusaHT9/4Zh/7idDdE/ailMY9pPvEtbVWcBnQxcXSoFEiM LKZFJ3o8nN7XFscSUqGRNNVYrAxpcktrnbz+assus7SbIYDpkOAOToBIWkdcxTXOWkv0Me9tVGcx ggODMIIDfwIBATBjMF0xCzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dp ZXMgQUcxKzApBgNVBAMTIkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDICAn7aMAkG BSsOAwIaBQCgggH1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDYwOTEzNTAzMlowIwYJKoZIhvcNAQkEMRYEFDYrYKEZhz2Ns1pvCuq22DIeMtl+MHIGCSsGAQQB gjcQBDFlMGMwXTELMAkGA1UEBhMCZGUxITAfBgNVBAoTGEluZmluZW9uIFRlY2hub2xvZ2llcyBB RzErMCkGA1UEAxMiSW5maW5lb24gVGVjaG5vbG9naWVzIEFHIFVzZXIgQ0EgMgICftowdAYLKoZI hvcNAQkQAgsxZaBjMF0xCzAJBgNVBAYTAmRlMSEwHwYDVQQKExhJbmZpbmVvbiBUZWNobm9sb2dp ZXMgQUcxKzApBgNVBAMTIkluZmluZW9uIFRlY2hub2xvZ2llcyBBRyBVc2VyIENBIDICAn7aMIGr BgkqhkiG9w0BCQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzAL BglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqG SIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAEib1raCFNX6saSHwyTtdsWpqzyywn3n7x4esaNLEqmvg3zDAa+a rSWZt2c04RncV/vnejT/MYbNrGOswCXUeAlTVAzqF2KjORHCrVSR/b8SqSrf9BSy8TOMkPqwpVfw 5aBDafeLe2mmOFpCZFhMIoWo53OIoTKMylu+Ci5aCduDbn4LixXB0bM3RXicIfZo3aZNBG6KDBqy H+3GtH998yhSWRx+NYU7Yppa6vinsB0NjmLberosAtrR7p45cqa2Dbf30H0nQZCW8N/oEVxId5Ck tMNcnFqqsRUKVeHwJ8q+MVD5uoSau7PrfKXNAcLIIghYX4XVOCQ+aMHGus/Fg+YAAAAAAAA= ------=_NextPart_000_0A98_01D0A299.B98CE8E0-- From nobody Tue Jun 9 08:13:41 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B09D1A8863; Tue, 9 Jun 2015 08:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vv6t9jYCeydU; Tue, 9 Jun 2015 08:13:38 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78F51A884D; Tue, 9 Jun 2015 08:13:37 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t59FDaGk015671; Tue, 9 Jun 2015 11:13:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1433862816; bh=F0VElwMGjfY2yNutL+ttkiuK2ewOJs6JkZpO4TpjWdg=; h=From:To:Subject:Date:Message-ID:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=JlDiLUpYOSxrwcdkPvUmyq9tBet2WraIjKTNwq62gqb23W/0QHV7lJWtwdwKWOKDZ zBEkmslENJcguLot1t1PE4WRVASZWVorhpa+g1JGj1ZN1Rv8Dzkx+/vbWkOuXnEpTm xrMqMhS6PPS6mxlMAk461ND+XQ2QKRGOkXQH4BTY= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t59FDYl1031631; Tue, 9 Jun 2015 11:13:34 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0210.002; Tue, 9 Jun 2015 11:13:34 -0400 From: Chris Inacio To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-rtcweb-rtp-usage-23@tools.ietf.org" Thread-Topic: sector review of draft-ietf-rtcweb-rtp-usage-23 Thread-Index: AQHQosba90/jwM6QXkWTs/Q+kZ42aQ== Date: Tue, 9 Jun 2015 15:13:33 +0000 Message-ID: <24C0D45F-DBF0-43A4-A2D6-B086F7EC368F@cert.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.97.138] Content-Type: text/plain; charset="utf-8" Content-ID: <92D96E38118CD1488DF5B81262CF98E0@sei.cmu.edu> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [secdir] sector review of draft-ietf-rtcweb-rtp-usage-23 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 15:13:40 -0000 DQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5 IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50 cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0 ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3Rv cnMuICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNv bW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQoNCkJMVUY6 ICBUaGlzIGRyYWZ0IGlzIHJlYWR5IHRvIGdvIHdpdGggc29tZSBOSVRTLg0KDQoNClRoaXMgZHJh ZnQgaXMgYW4gb3ZlcmFyY2hpbmcgc2V0IG9mIGd1aWRlbGluZXMgb2YgdGhlIHVzZSBhbmQgYXBw bGljYXRpb24gb2YgUlRQIGFuZCBSVENQIGFzIGl0IGFwcGxpZXMgdG8gV2ViUlRDIGFuZCB0aGUg cmVsYXRlZCBXM0MgQVBJLiAgVGhlIFczQyBBUEkgaXMgbm90IGRlc2NyaWJlZCBpbiB0aGlzIGRv Y3VtZW50LCBidXQgcmVmZXJlbmNlcyB0byBmdW5jdGlvbmFsaXR5IHJlcXVpcmVtZW50cyBmb3Ig dGhlIEFQSSBhcmUgbWFkZS4NCg0KVGhpcyBkcmFmdCBpcyBleHRyZW1lbHkgd2VsbCB3cml0dGVu LiAgQXQgdGhlIHNhbWUgdGltZSwgaG93ZXZlciwgaXQgcmVhZHMgbGlrZSBhbiBlbmN5Y2xvcGVk aWEgb2YgcmVmZXJlbmNlcyBhbmQgcmVxdWlyZW1lbnRzIGFjcm9zcyAzNSBkaWZmZXJlbnQgbm9y bWF0aXZlIG90aGVyIHJlZmVyZW5jZWQgZHJhZnRzLiAgQ29ycmVzcG9uZGluZ2x5LCBJIGRpZCBO T1QgcmVhZCB0aHJvdWdoIGFsbCBvZiB0aGUgcmVmZXJlbmNlZCBkcmFmdHMsIG5vciBkaWQgSSBi ZWxpZXZlIHRoYXQgaXQgd2FzIG5lY2Vzc2FyeSBpbiB0aGlzIGNhc2UgdG8gZG8gc28uDQoNClRo ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHdhcyBjb21wcmVoZW5zaXZlIGFuZCBz ZWN1cml0eSBpbXBhY3RzIHdlcmUgdGFrZW4gaW50byBhY2NvdW50IHRocm91Z2hvdXQgdGhpcyBk cmFmdC4gIEkgaGF2ZSB0d28gc21hbGwgTklU4oCZcyBhYm91dCB0aGUgc2VjdXJpdHkgc2VjdGlv biB0aGF0IEkgd291bGQgbGlrZSBpbXByb3ZlZCwgYW5kIEkgZmVlbCB0aGVzZSBhcmUgcmF0aGVy IHNtYWxsOiAgRmlyc3QsIGluIHRoZSBwYXJhZ3JhcGggaW4gdGhlIHNlY3VyaXR5IHNlY3Rpb24g dGhhdCBzdGFydHMg4oCcUlRDUCBwYWNrZXRzIGNvbnZleSBhIENhbm9uaWNhbCBOYW1l4oCm4oCd ICB0aGUgYXV0aG9ycyBzdGF0ZSB0aGF0IHRoZSBDTkFNRSBnZW5lcmF0aW9uIGFsZ29yaXRobSBp biBkZXNjcmliZWQgaW4gc2VjdGlvbiA0Ljkg4oCTIGl0IGlzbuKAmXQsIHNlY3Rpb24gNC45IHJl ZmVyZW5jZXMgUkZDNzAyMiBmb3IgdGhlIGdlbmVyYXRpb24gYWxnb3JpdGhtLiAgU2Vjb25kLCB0 aGUgbGFzdCBwYXJhZ3JhcGggb24gcGFnZSAzOSwgc3RhcnRpbmcgd2l0aCDigJxQcm92aWRpbmcg c291cmNlIGF1dGhlbnRpY2F0aW9uIGluIG11bHRpLXBhcnR54oCm4oCdIGVuZHMgdGhlIHBhZ2Ug d2l0aCBhIGxhcmdlIHNlY3VyaXR5IHdhcm5pbmcuICAgUGxlYXNlIGluY2x1ZGUgYSByZWZlcmVu Y2UgaW4gdGhhdCBwYXJhZ3JhcGggaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFuZCBw b3NzaWJseSB0byB0aGUgYXBwcm9wcmlhdGUgZHJhZnQvUkZDIHdoaWNoIGRpc2N1c3NlcyB0aGF0 IGlzc3VlIGluIHNvbWUgbW9yZSBkZXB0aC4NCg0KDQpnZW5lcmFsIE5JVFM6DQoNCkkgYmVsaWV2 ZSB0aGVyZSBhcmUgbXVsdGlwbGUgdmVyc2lvbnMgb2Yg4oCcZW5kIHBvaW504oCdIHVzZWQgaW4g dGhlIGRvY3VtZW50IEVuZCBQb2ludCwgZW5kLXBvaW50LCBldGMuICBUaG9zZSBzaG91bGQgYmUg aGFybW9uaXplZC4NCg0KDQpwYWdlIDQ6DQoNClNlY3Rpb24gMiBSYXRpb25hbGUNCg0K4oCcVGhp cyBidWlsZHMgb24gdGhlIHBhc3QgMjAgeWVhcnMgZGV2ZWxvcG1lbnQgb2YgUlRQIHRvIG1hbmRh dGUgdGhlIHVzZSBvZiBleHRlbnNpb25zIHRoYXQgaGF2ZSBzaG93biB3aWRlc3ByZWFkIHV0aWxp dHnigJ0gDQoNCmNhbiB0aGlzIGJlIHJld29yZGVkIHRvIOKAnFRoaXMgYnVpbGRzIG9uIHRoZSBw YXN0IDIwIHllYXJzIG9mIFJUUCBkZXZlbG9wbWVudCB0byBtYW5kYXRlIHRoZSB1c2Ugb2YgZXh0 ZW5zaW9ucyB0aGF0IGhhdmUgc2hvd24gd2lkZXNwcmVhZCB1dGlsaXR5LuKAnQ0KDQoNCnBhZ2Ug NjoNCg0K4oCcVGhpcyBzcGVjaWZpY2F0aW9uIHJlcXVpcmVzIHRoZSB1c2FnZSBvZiBhIHNpbmds ZSBDTkFNRSB3aGVuIHNlbmRpbmcgUlRQIFBhY2tldCBTdHJlYW1z4oCm4oCdICAgc2hvdWxkIHRo ZSDigJxyZXF1aXJl4oCdIGJlIOKAnFJFUVVJUkXigJ0/DQoNCnBhZ2UgNzoNCg0KIlRoaXMgdG8g ZW5zdXJlIHJvYnVzdCBoYW5kbGluZyBvZiBmdXR1cmUgZXh0ZW5zaW9uc+KApuKAnSB0byDigJxU aGlzIGlzIHRvIGVuc3VyZeKApuKAnQ0KDQpwYWdlIDE0Og0KDQpJbiByZWZlcmVuY2UgdG8gdGhl IHBhcmFncmFwaCB0aGF0IHN0YXJ0cyB3aXRoIOKAnFdoaWxlIHRoZSB1c2Ugb2YgSVAgbXVsdGlj YXN0Li4u4oCdLiAgVGhlcmUgaXMgbm8gTUFZL1NIT1VMRC9TSEFMTC9SRVFVSVJFIGV0Yy4gaW4g dGhlIHBhcmFncmFwaCwgYnV0IHRoZSBsYXN0IHNlbnRlbmNlIGRvZXMgc2VlbSB0byBpbXBseSBh biBpbXBsZW1lbnRhdGlvbiByZXF1aXJlbWVudC4gIFdhcyB0aGF0IGludGVudGlvbmFsPw0KDQpw YWdlIDE2Og0KDQrigJxUaGlzIGNhbiBiZSB2YXJpb3VzIHJlYXNvbnMgZm9yIHRoaXM64oCm4oCd ICB0byDigJxUaGVyZSBjYW4gYmUgdmFyaW91cyByZWFzb25zIGZvciB0aGlzOuKApuKAnQ0KDQpw YWdlIDIwOg0KDQrigJxoZXRlcm9nZW5lb3VzIG5ldHdvcmsgZW52aXJvbm1lbnRzIHVzaW5nIGEg dmFyaWV0eSBzZXQgb2YgbGluayB0ZWNobm9sb2dpZXPigKbigJ0gZ2V0IHJpZCBvZiDigJxzZXTi gJ0uDQoNCnBhZ2UgMjM6DQoNCuKAnOKApnN1cHBvcnRlZCBieSB0aGUgUlRDUCBFeHRlbmRlZCBS ZXBvcnRzIChYUikgZnJhbWV3b3JrIFtSRkMzNjExXVtSRkM2NzkyXS7igJ0gICBSRkMzNjExIHNl ZW1zIHRvIGJlIGEgZnVsbCBmbGVkZ2VkIHJlZmVyZW5jZSB3aGlsZSBSRkM2NzkyIHNlZW1zIHRv IGp1c3QgYmUgdGV4dCBvZiDigJxbUkZDNjc5Ml3igJ0uDQoNCnBhZ2UgMjU6DQoNCkZpcnN0IHBh cmFncmFwaCBvZiBzZWN0aW9uIDExIGRlZmluZXMgYSBudW1iZXIgb2YgV2ViUlRDIEFQSSB0ZXJt cywgUExFQVNFIG1vdmUgdGhvc2UgKGZhcikgZm9yd2FyZCBpbiB0aGUgZG9jdW1lbnQuDQrigJxU aGUgTWVkaWFTdHJlYW1UcmFja3Mgd2l0aGluIGEgTWVkaWFTdHJlYW0gbmVlZCB0byBiZSBwb3Nz aWJsZSB0byBwbGF5IG91dCBzeW5jaHJvbml6ZWQu4oCdICByZXdyaXRlIHRvIOKAnFRoZSBNZWRp YVN0cmVhbVRyYWNrcyB3aXRoaW4gYSBNZWRpYVN0cmVhbSBtYXkgbmVlZCB0byBiZSBzeW5jaHJv bml6ZWQgZHVyaW5nIHBsYXkgYmFjay7igJ0gIG9yIHNvbWV0aGluZyBzaW1pbGFyLg0KDQpwYWdl IDI2Og0KDQrigJxmb3JjZSBhbiBlbmQtcG9pbnQgdG8gdG8gZGlzcnVwdOKAnSAgb25seSBvbmUg 4oCcdG/igJ0uDQoNCuKAnFRoaXMgaXMgbW90aXZhdGluZyB0aGUgZGlzY3Vzc2lvbiBpbiBTZWN0 aW9uIDQuOeKAnSwgKHllcywgbm93IEnigJltIHJlYWxseSBnZXR0aW5nIHBpY2t5LCkgYnV0IHRo ZSBkaXNjdXNzaW9uIHdhcyBhbHJlYWR5IG1vdGl2YXRlZC4gIDopDQoNCnBhZ2UgMjc6DQoNCuKA nE9wdGltaXphdGlvbnMgb2YgdGhpcyBtZXRob2QgaXMgY2xlYXJseSBwb3NzaWJsZSBhbmQg4oCm 4oCdICDigJxpc+KAnSAtPiDigJxhcmXigJ0NCg0K4oCccmVjZWl2aW5nIG11bHRpcGxlIE1lZGlh U3RyZWFtVHJhY2tzLCB3aGVyZSBlYWNoIG9mIGRpZmZlcmVudCBNZWRpYVN0cmVhbVRyYWNrcyAo YW5kIOKApuKAnSB0byDigJwg4oCmIHdoZXJlIGVhY2ggb2YgKnRoZSogZGlmZmVyZW50IE1lZGlh U3RyZWFtVHJhY2tzIOKApiDigJwNCg0K4oCcVGhpcyBsYXRlciBpcyByZWxldmFudCB0byBoYW5k bGUgc29tZSBjYXNlcyBvZiBsZWdhY3kgaW50ZXJvcC7igJ0gdG8g4oCcVGhlIGxhdGVyIGlzIHJl bGV2YW50IOKApiBsZWdhY3kgaW50ZXJvcGVyYWJpbGl0eS7igJ0NCg0KcGFnZSAyODoNCg0K4oCc LiAuIC4gRW5kcG9pbnRzIGNhbiBjb25maWd1cmUgYW5kIHVzZSBSVFAgc2Vzc2lvbnMgaXMgb3V0 bGluZWQu4oCdICBjaGFuZ2Ug4oCcaXPigJ0gdG8g4oCcYXJl4oCdDQoNCuKAnCAuIC4gLiBpdCBp cyBjb21tb24gdG8gdXNlIG9uZSBSVFAgc2Vzc2lvbiBmb3IgZWFjaCB0eXBlIG9mIG1lZGlhIHNv dXJjZXMgKGUuZy4gLiAuIC7igJ0gIGNoYW5nZSDigJxzb3VyY2Vz4oCdIHRvIOKAnHNvdXJjZeKA nQ0KDQpwYWdlIDMxOg0KDQrigJxUbyBtYWludGFpbiBhIGNvaGVyZW50IG1hcHBpbmcgYmV0d2Vl biB0aGUgcmVsYXRpb24gYmV0d2VlbiBSVFAgc2Vzc2lvbnMgYW5kIFJUQ1BlZXJDb25uZWN0aW9u IG9iamVjdHMgaXQgaXMg4oCm4oCdICByZXdyaXRlIHRvIG1heWJlDQoNCuKAnFRvIG1haW50YWlu IGEgY29oZXJlbnQgbWFwcGluZyBiZXR3ZWVuIHRoZSByZWxhdGlvbnNoaXAgb2YgUlRQIHNlc3Np b25zIGFuZCBSVENQZWVyQ29ubmVjdGlvbiBvYmplY3RzIGl0IGlzIOKApi7igJ0NCg0KcGFnZSAz MjoNCg0K4oCcVGhpcyBzY2VuYXJpbyBhbHNvIHJlc3VsdHMgaW4gdGhhdCBhbiBlbmQtcG9pbnTi gJlzIGZlZWRiYWNrIG9yIHJlcXVlc3RzIGdvZXMgdG8gdGhlIG1peGVy4oCm4oCdICBjaGFuZ2Ug 4oCcZ29lc+KAnSB0byDigJxnb+KAnS4NCg0K4oCcbmVjZXNzYXJpbHkgYmUgZXhwbGljaXRseSB2 aXNpYmxlIGFueSBSVFAgYW5kIFJUQ1AgdHJhZmZpYyDigKbigJ0gdG8g4oCcbmVjZXNzYXJpbHkg YmUgZXhwbGljaXRseSB2aXNpYmxlIHRvIGFueSBSVFAgYW5kIFJUQ1AgdHJhZmZpY+KAnS4NCg0K cGFnZSAzODoNCg0K4oCcY29tYmluZ+KAnSB0byDigJxjb21iaW5pbmfigJ0NCg0KDQoNCi0tDQpD aHJpcyBJbmFjaW8NCmluYWNpb0BjZXJ0Lm9yZw0KDQoNCg0K From nobody Tue Jun 9 10:37:58 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8892F1B2DA4; Tue, 9 Jun 2015 10:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxXfRidX9_IC; Tue, 9 Jun 2015 10:37:51 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A29E1B2DB6; Tue, 9 Jun 2015 10:37:51 -0700 (PDT) Received: by yked142 with SMTP id d142so11545521yke.3; Tue, 09 Jun 2015 10:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RjkriLBUV9/2RhwjFvaTSNz2mu/C6+a7H7LGUiiX9J4=; b=ei89l81/MVGqld5YxOyyx8TAA7BPcMwATGuEFcRjsXbCOaAAYqzEWL/BwRmherl5Ui 0HQWalGEsPeUAAnrXqfq8j4Ky2UIb+y57IChEG0Zdpqw8Bss1uqKkm+OiHpTtx4HgDaO 2SAOWfLgcbSkYmNeAKN+EaQtjvRW2ya1bx/7ZBueMxN1VnfC3DPGwTfYfyVZDIdYvV6q ZX5R7JybgZ9zfqchZlHyiqVHa2EvbzNKhszGRJzPM+AFvaqyhR5/1bW5ZQQvdBG3KjwL A7Qx4vYjf4aRh4tG90KqQDCR7i2K9O/2XzFksULiXAN9pNEx/7RrHV22Hwh8GWxqpr7m /E5A== MIME-Version: 1.0 X-Received: by 10.170.139.132 with SMTP id g126mr26657953ykc.98.1433871469892; Tue, 09 Jun 2015 10:37:49 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Tue, 9 Jun 2015 10:37:49 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Jun 2015 10:37:49 -0700 Message-ID: From: Martin Thomson To: Steve.Hanna@infineon.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] SecDir Review of draft-ietf-rtcweb-stun-consent-freshness-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 17:37:57 -0000 On 9 June 2015 at 06:50, wrote: > 1) Will misbehaving or malicious endpoints obey this? If not, what= =E2=80=99s > the point? If only a few polite endpoints go to the trouble of obtaining > consent to send, I don=E2=80=99t see how this will solve anything. Good actors will respect this, and that has proven sufficient to stop congestion collapse in TCP. ICE is already the foundation of real-time communications. This just patches a hole. This will be implemented in web browsers, which means that they cannot be used as a (sustained) DoS platform. > 2) Section 5.1 says =E2=80=9CAn endpoint MUST NOT send data other th= an the > messages used to establish consent unless the receiving endpoint has > consented to receive data.=E2=80=9D This seems to be a long way from the = present > reality. How many applications implement this requirement? Or will this > feature somehow be built into the OS? This is already the case for all real-time implementations today. And it will - in effect - be part of the platform of the web when it is made part of a browser. > 3) The document says that =E2=80=9CConsent expires after 30 seconds.= =E2=80=9D And > =E2=80=9CImplementations SHOULD set a default interval of 5 seconds=E2=80= =9D for > retransmitting STUN binding requests (requests for consent). If I underst= and > this correctly, every pair of endpoints with an active connection will no= w > exchange STUN binding request and response pairs in each direction every > five seconds. That works out to about one packet per second transit for > every connection. That seems like a lot of overhead. Is the benefit > adequate? We're talking real-time communications, where 50 packets per second each way is the baseline. This is a negligible increase. From nobody Tue Jun 9 14:33:38 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5491A1B4B; Tue, 9 Jun 2015 14:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leY42f4Ulb12; Tue, 9 Jun 2015 14:33:33 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::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 2413C1A1B5B; Tue, 9 Jun 2015 14:33:33 -0700 (PDT) Received: by yhid80 with SMTP id d80so12621107yhi.1; Tue, 09 Jun 2015 14:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5VBsK/3uXe4YyD17jS7MnJ8WcdXjhibSPHHMyYh/IQw=; b=A7Acutq3M/dzdMyvwGGAMMN8gI3YBWMB0T50717QZ3MutpIa4JohT/k8hbamOsg2eL 0Dss+nMC4QcL3aI8HvSaDVIM47KhI18WgQ9UJN54Ab0BFoVGk0UMK39+Rhr0Lo/cYHR6 RP/cmXgQOCzrR8YFuYQi3OFpN9Yv9B/uB31/QFpl98v5NXULCZvcwTs8PEYnLtpCZrRW b7JX27jrD7DIVhLSYnpF5dIGO7P8KQKxDC/ecyOy0FBBVMxj2F7fN77vItrTq5VZQ24i nbcQLF84pX70sI2G7tmLZb2DVt+smtj0HJpH2hWS1NU/6E62TuN4gw3QEisrgQOC2d3J 03Cw== MIME-Version: 1.0 X-Received: by 10.170.112.18 with SMTP id e18mr27815527ykb.101.1433885612354; Tue, 09 Jun 2015 14:33:32 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Tue, 9 Jun 2015 14:33:32 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Jun 2015 14:33:32 -0700 Message-ID: From: Martin Thomson To: Scott Kelly Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-httpbis-tunnel-protocol.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-httpbis-tunnel-protocol-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 21:33:37 -0000 On 5 June 2015 at 05:24, Scott Kelly wrote: > Sorry that this review is a few days late, I hope it is still useful. Of course it is :) > The ALPN header allows the client to tell the proxy which protocol(s) it = intends to encapsulate. This ALPN header is not authenticated, and the draf= t makes no reference to client authentication and/or other protocol securit= y mechanisms, so I assume this exchange is not secured in any way. Correct. It's a "forward-looking statement" that couldn't be validated any= way. > Things I think should change: > > The draft never says what the proxy should do if the client makes one cla= im in the ALPN header, but then does something different (including using d= ifferent ALPNs in encapsulated TLS negotiations). Seems like it should. > > Also, the draft seems to suggest that it is okay to use the ALPN for poli= cy/authorization decisions. This is unreliable from a security perspective.= At minimum, I think the draft should explicitly call this out. Stephen made similar comments in his review. Those lead to the addition of text: https://github.com/httpwg/http-extensions/compare/6c7b987e2b25e...master Does that help at all? The intent is not to let this be used for authorization decisions, but to allow a quick, clean "deny" decision to be issued. The current state of play is pretty messy in that regard. Other changes (based on other reviews) resulted in more emphasis on this being a hint, or an indication of intent. From nobody Tue Jun 9 14:33:45 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD09B1A1B5B for ; Tue, 9 Jun 2015 14:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 K_GjeYO2M6Ws for ; Tue, 9 Jun 2015 14:33:36 -0700 (PDT) Received: from xsmtp04.mail2web.com (xsmtp04.mail2web.com [168.144.250.231]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DA041A1BA3 for ; Tue, 9 Jun 2015 14:33:35 -0700 (PDT) Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Z2R9J-0002u5-8f for secdir@ietf.org; Tue, 09 Jun 2015 17:33:34 -0400 Received: (qmail 16111 invoked from network); 9 Jun 2015 21:33:32 -0000 Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[131.107.147.223]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 9 Jun 2015 21:33:32 -0000 From: "Christian Huitema" To: "'Yoav Nir'" , "'secdir'" , "'The IESG'" , References: <06A85300-7DD9-4AC4-A5F5-EE9FE77F7466@gmail.com> In-Reply-To: <06A85300-7DD9-4AC4-A5F5-EE9FE77F7466@gmail.com> Date: Tue, 9 Jun 2015 14:33:30 -0700 Message-ID: <001801d0a2fb$ef31e560$cd95b020$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQM76S7OfzTHZVpZ8EJ9iD3mk4Q05prOIsqw Content-Language: en-us Archived-At: Subject: Re: [secdir] SecDir Review of draft-ietf-pcp-anycast-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 21:33:38 -0000 > There are two specific concerns about this method (other than the = usual > anycast or pcp concerns). The first is that information about the = internal > network might leak to a PCP service outside the network.=20 In fact, it is almost guaranteed to leak outside of the network. In the = initial deployments, first hop routers will not be aware of the anycast = address... > ... Whereas a failure of > a service whose address is given in DHCP will result in black-holed = packets, > failure of a service with an anycast address will cause the packets to = be > forwarded to some random PCP server on the Internet. Section 5.1 = discusses > this and recommends filtering in perimeter gateways and reduced TTL. I > believe this addresses that threat adequately. I would find the TTL mitigation would be more convincing if the draft = actually specified a recommended TTL value. -- Christian Huitema From nobody Tue Jun 9 14:47:35 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBC41A6ED9; Tue, 9 Jun 2015 14:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 2T9CMa8vhFjP; Tue, 9 Jun 2015 14:47:29 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c: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 1F4471A1F00; Tue, 9 Jun 2015 14:47:29 -0700 (PDT) Received: by wgme6 with SMTP id e6so22048012wgm.2; Tue, 09 Jun 2015 14:47:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XqipQ0+D/cRmbRsMzoq+HNvV1PjBSZPGMUdP6UQFI8M=; b=OH6RvIbG74Mgbz05GotprAa53VC6YD5i1DQM/TvcHAuTZ3hxne1xcr5vt6NprggnRC RLYeQreEhhKkbZHxXSrfBMi6s9ftNLZ/F0+uS6xkB4ZaW3YqCbFqnJ2UoHY08jqRovat llaldpiVHIimvYbZ7tZ3obiNFcXFmAhOb0Fgwx0XYtyfdlCl8yv7pK3z9RkSh1bnb/Y/ 2eZU5vE7dFdbnzY14XGpMreAd7K3fjvFOmNW2aL7UFUS6/oQaOn4SuUA2t/Ta9RRl4XP 3sU02T4ZtnXLxBW8WnaLp7qRigxnpYdXHYzfwOFykb6PaRe2qBtCWXSU+Lb1ESwbRqe6 Ptpg== X-Received: by 10.194.60.50 with SMTP id e18mr44739022wjr.109.1433886447909; Tue, 09 Jun 2015 14:47:27 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id l6sm4769573wib.18.2015.06.09.14.47.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jun 2015 14:47:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Yoav Nir In-Reply-To: <001801d0a2fb$ef31e560$cd95b020$@huitema.net> Date: Wed, 10 Jun 2015 00:47:23 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <06A85300-7DD9-4AC4-A5F5-EE9FE77F7466@gmail.com> <001801d0a2fb$ef31e560$cd95b020$@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.2098) Archived-At: Cc: draft-ietf-pcp-anycast.all@tools.ietf.org, The IESG , secdir Subject: Re: [secdir] SecDir Review of draft-ietf-pcp-anycast-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 21:47:30 -0000 > On Jun 10, 2015, at 12:33 AM, Christian Huitema = wrote: >=20 >> There are two specific concerns about this method (other than the = usual >> anycast or pcp concerns). The first is that information about the = internal >> network might leak to a PCP service outside the network.=20 >=20 > In fact, it is almost guaranteed to leak outside of the network. In = the initial deployments, first hop routers will not be aware of the = anycast address... >=20 >> ... Whereas a failure of >> a service whose address is given in DHCP will result in black-holed = packets, >> failure of a service with an anycast address will cause the packets = to be >> forwarded to some random PCP server on the Internet. Section 5.1 = discusses >> this and recommends filtering in perimeter gateways and reduced TTL. = I >> believe this addresses that threat adequately. >=20 > I would find the TTL mitigation would be more convincing if the draft = actually specified a recommended TTL value. Doesn=E2=80=99t that depend on the depth (diameter?) of the network? = The TTL should be high enough to reach the legitimate service but no = higher. It does seem like a very fiddly thing. You=E2=80=99d need to = re-adjust the TTL sent by all clients if you rearranged your servers a = bit. I can see operators not taking the risk and just using the OS = default TTL that=E2=80=99s high enough to take a packet to any network = on the Internet. Expecting the NAT device / firewall to filter sounds more plausible to = me. From nobody Tue Jun 9 15:33:26 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDD81A6F2E for ; Tue, 9 Jun 2015 15:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sD3x31rY49sd for ; Tue, 9 Jun 2015 15:33:24 -0700 (PDT) Received: from xsmtp04.mail2web.com (xsmtp04.mail2web.com [168.144.250.231]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7C51A6F29 for ; Tue, 9 Jun 2015 15:33:24 -0700 (PDT) Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Z2S5C-0003f5-7H for secdir@ietf.org; Tue, 09 Jun 2015 18:33:23 -0400 Received: (qmail 10037 invoked from network); 9 Jun 2015 22:33:21 -0000 Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[131.107.147.223]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 9 Jun 2015 22:33:21 -0000 From: "Christian Huitema" To: "'Yoav Nir'" References: <06A85300-7DD9-4AC4-A5F5-EE9FE77F7466@gmail.com> <001801d0a2fb$ef31e560$cd95b020$@huitema.net> In-Reply-To: Date: Tue, 9 Jun 2015 15:33:19 -0700 Message-ID: <009001d0a304$4a518ec0$def4ac40$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQM76S7OfzTHZVpZ8EJ9iD3mk4Q05gBUUmk8AhLhUUqauvprsA== Content-Language: en-us Archived-At: Cc: draft-ietf-pcp-anycast.all@tools.ietf.org, 'The IESG' , 'secdir' Subject: Re: [secdir] SecDir Review of draft-ietf-pcp-anycast-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 22:33:25 -0000 > > I would find the TTL mitigation would be more convincing if the = draft > actually specified a recommended TTL value. >=20 > Doesn=E2=80=99t that depend on the depth (diameter?) of the network? = The TTL > should be high enough to reach the legitimate service but no higher. = It does > seem like a very fiddly thing. You=E2=80=99d need to re-adjust the TTL = sent by all clients > if you rearranged your servers a bit. I can see operators not taking = the risk and > just using the OS default TTL that=E2=80=99s high enough to take a = packet to any > network on the Internet. But then, what is the point of mentioning TTL as a plausible mitigation = if there is no practical way to use it?=20 > Expecting the NAT device / firewall to filter sounds more plausible to = me. Except that currently deployed routers will not be updated for a long = time. If they do support PCP, the router selection rule will discover = them. But many don't. They will thus pass the unicast packets through, = unmolested. There are probably a bunch of heuristics that can be applied to reduce = the leakage. But I don't see them in the draft. -- Christian Huitema From nobody Wed Jun 10 08:50:09 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B4A1B2F36; Wed, 10 Jun 2015 08:50:06 -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 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 yW6jVFde9fQL; Wed, 10 Jun 2015 08:50:03 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7701B2F24; Wed, 10 Jun 2015 08:50:02 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-fc-55785ca81856 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CB.3B.17665.8AC58755; Wed, 10 Jun 2015 17:50:00 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.210.2; Wed, 10 Jun 2015 17:50:00 +0200 Message-ID: <55785CA7.4090005@ericsson.com> Date: Wed, 10 Jun 2015 17:49:59 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Chris Inacio , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-rtcweb-rtp-usage-23@tools.ietf.org" , "rtcweb@ietf.org" References: <24C0D45F-DBF0-43A4-A2D6-B086F7EC368F@cert.org> In-Reply-To: <24C0D45F-DBF0-43A4-A2D6-B086F7EC368F@cert.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUyM+Jvre6KmIpQgw/vtCzmtMZbzPgzkdli 4dqTjBZr/7WzW3xY+JDFgdVjxgYfjyVLfjJ5fLn8mS2AOYrLJiU1J7MstUjfLoEr4+PTRSwF Cx0rpvflNDCeN+5i5OSQEDCROLrqPjOELSZx4d56ti5GLg4hgaOMEq8v72SBcJYzSnSv28oG UsUroC3x78sTFhCbRUBVYtW8g+wgNpuAhcTNH41gNaICURJTH69jgagXlDg58wnYIBGBb0BT t05nBEkIC9hILJrxD6xBSMBaYufCR0CDODg4geK/upVAwsxAM2fOP88IYctLNG+dzQxRri3R 0NTBOoFRYBaSFbOQtMxC0rKAkXkVo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmDoHtzyW3cH 4+rXjocYBTgYlXh4FWaVhwqxJpYVV+YeYpTmYFES552xOS9USCA9sSQ1OzW1ILUovqg0J7X4 ECMTB6dUA2PT8uoKs4y4WSdyOWzP3u6qiti1Mq9zupO9wUIzlzVJ/m5at1+4yTEvu6t19Psl GU0G70Obg3kK5k6az55q5sexI/H8hkeSE1uOPfmyauo5v8qP2xgzE9t5XX1erT+lO2vzWu3W gE1HMmfuzLnbM31B4qIguYmuTP9/JcqGLO5g8I2aM+9RgpISS3FGoqEWc1FxIgDDl9LSPgIA AA== Archived-At: Subject: Re: [secdir] sector review of draft-ietf-rtcweb-rtp-usage-23 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 15:50:06 -0000 Hi, (Adding RTCWEB WG list as this discusses changes to the draft) Thanks for the very detailed review. We will include all relevant changes in an update that will be submitted after the IESG call tomorrow. WG, this is your chance to scream if there are bad changes here. Chris Inacio skrev den 2015-06-09 17:13: > > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > > BLUF: This draft is ready to go with some NITS. > > > This draft is an overarching set of guidelines of the use and > application of RTP and RTCP as it applies to WebRTC and the related > W3C API. The W3C API is not described in this document, but > references to functionality requirements for the API are made. > > This draft is extremely well written. At the same time, however, it > reads like an encyclopedia of references and requirements across 35 > different normative other referenced drafts. Correspondingly, I did > NOT read through all of the referenced drafts, nor did I believe that > it was necessary in this case to do so. > > The security considerations section was comprehensive and security > impacts were taken into account throughout this draft. I have two > small NIT’s about the security section that I would like improved, > and I feel these are rather small: First, in the paragraph in the > security section that starts “RTCP packets convey a Canonical Name…” > the authors state that the CNAME generation algorithm in described in > section 4.9 – it isn’t, section 4.9 references RFC7022 for the > generation algorithm. Yes, but it actually specifies which particular generation algorithm to use. RFC7022 does contain more than one. I propose that we change this text to say: Section 4.9 of this memo mandates generation of short-term persistent RTCP CNAMES, as specified in RFC7022, resulting in untraceable CNAME values that alleviate this risk. Second, the last paragraph on page 39, > starting with “Providing source authentication in multi-party…” ends > the page with a large security warning. Please include a reference > in that paragraph in the security considerations and possibly to the > appropriate draft/RFC which discusses that issue in some more depth. If I understand this correctly, you want something like the below added to the security consideration section. I suggest to add this last in the section. In multi-party communication scenarios using RTP Middleboxes, a lot of trust is placed on these middleboxes to preserve the sessions security. The middlebox needs to maintain the confidentiality, integrity and perform source authentication. As discussed in Section 12.1.1 the middlebox can perform checks that prevents any endpoint participating in a conference to impersonate another. Some additional security considerations regarding multi-party topologies can be found in [I-D.ietf-avtcore-rtp-topologies-update]. > > > general NITS: > > I believe there are multiple versions of “end point” used in the > document End Point, end-point, etc. Those should be harmonized. > Yes, we will use endpoint > > page 4: > > Section 2 Rationale > > “This builds on the past 20 years development of RTP to mandate the > use of extensions that have shown widespread utility” > > can this be reworded to “This builds on the past 20 years of RTP > development to mandate the use of extensions that have shown > widespread utility.” > Yes. > > page 6: > > “This specification requires the usage of a single CNAME when sending > RTP Packet Streams…” should the “require” be “REQUIRE”? This is intended as an informational reference, thus I propose to change this to "mandates" thus avoiding the RFC2119 terms. > > page 7: > > "This to ensure robust handling of future extensions…” to “This is to > ensure…” Sure. > > page 14: > > In reference to the paragraph that starts with “While the use of IP > multicast...”. There is no MAY/SHOULD/SHALL/REQUIRE etc. in the > paragraph, but the last sentence does seem to imply an implementation > requirement. Was that intentional? Yes, it is intentional. > > page 16: > > “This can be various reasons for this:…” to “There can be various > reasons for this:…” Addressed in -24 version. > > page 20: > > “heterogeneous network environments using a variety set of link > technologies…” get rid of “set”. > Yes. > page 23: > > “…supported by the RTCP Extended Reports (XR) framework > [RFC3611][RFC6792].” RFC3611 seems to be a full fledged reference > while RFC6792 seems to just be text of “[RFC6792]”. > They are both relevant references when understanding what RTCP XR are and what metrics one should consider. I propose to add a "see" so that the results become "... framework, see [RFC3611][RFC6792]. > page 25: > > First paragraph of section 11 defines a number of WebRTC API terms, > PLEASE move those (far) forward in the document. “The > MediaStreamTracks within a MediaStream need to be possible to play > out synchronized.” rewrite to “The MediaStreamTracks within a > MediaStream may need to be synchronized during play back.” or > something similar. I have added also MediaStreamTrack to the Terminology section (3). And populated both MediaStream and MediaStreamTrack with text from this paragraph. I have however not removed any text from this paragraph in Section 11. > > page 26: > > “force an end-point to to disrupt” only one “to”. Ok > > “This is motivating the discussion in Section 4.9”, (yes, now I’m > really getting picky,) but the discussion was already motivated. :) Changed this to: This is motivating the use of a single CNAME in Section 4.9. > > page 27: > > “Optimizations of this method is clearly possible and …” “is” -> > “are” ok > > “receiving multiple MediaStreamTracks, where each of different > MediaStreamTracks (and …” to “ … where each of *the* different > MediaStreamTracks … “ Fixed > > “This later is relevant to handle some cases of legacy interop.” to > “The later is relevant … legacy interoperability.” > Ok > page 28: > > “. . . Endpoints can configure and use RTP sessions is outlined.” > change “is” to “are” > > “ . . . it is common to use one RTP session for each type of media > sources (e.g. . . .” change “sources” to “source” > > page 31: > > “To maintain a coherent mapping between the relation between RTP > sessions and RTCPeerConnection objects it is …” rewrite to maybe > > “To maintain a coherent mapping between the relationship of RTP > sessions and RTCPeerConnection objects it is ….” I propose: To maintain a coherent mapping of the relationship between RTP sessions and RTCPeerConnection objects it is recommend that this is implemented as several individual RTP sessions. > > page 32: > > “This scenario also results in that an end-point’s feedback or > requests goes to the mixer…” change “goes” to “go”. ok > > “necessarily be explicitly visible any RTP and RTCP traffic …” to > “necessarily be explicitly visible to any RTP and RTCP traffic”. Yes > > page 38: > > “combing” to “combining” > ok > > > -- Chris Inacio inacio@cert.org > > > Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Jun 10 11:25:39 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16EE31B33ED; Wed, 10 Jun 2015 11:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vyt_mly73Ut7; Wed, 10 Jun 2015 11:25:35 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90A971B2E90; Wed, 10 Jun 2015 11:25:35 -0700 (PDT) Received: from [81.187.2.149] (port=48437 helo=[192.168.0.24]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Z2kgq-0002ER-DW; Wed, 10 Jun 2015 19:25:30 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <55786629.6060705@nostrum.com> Date: Wed, 10 Jun 2015 19:25:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1F558D60-16EB-40B5-B7F8-C51FC2CE604B@csperkins.org> References: <24C0D45F-DBF0-43A4-A2D6-B086F7EC368F@cert.org> <55785CA7.4090005@ericsson.com> <55786629.6060705@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: Magnus Westerlund , "secdir@ietf.org" , "rtcweb@ietf.org" , "iesg@ietf.org" , "draft-ietf-rtcweb-rtp-usage-23@tools.ietf.org" Subject: Re: [secdir] [rtcweb] sector review of draft-ietf-rtcweb-rtp-usage-23 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 18:25:37 -0000 On 10 Jun 2015, at 17:30, Adam Roach wrote: > On 6/10/15 10:49, Magnus Westerlund wrote: >>> page 6: >>>=20 >>> =93This specification requires the usage of a single CNAME when = sending >>> RTP Packet Streams=85=94 should the =93require=94 be =93REQUIRE=94? >>=20 >> This is intended as an informational reference, thus I propose to = change this to "mandates" thus avoiding the RFC2119 terms. >=20 > RFC 2119 doesn't remove the words "require", "must", "should", "may" = and "recommend" from the English language. If all you mean is the = ordinary word "require," (rather than the 2119 term "REQUIRE"), then = "require" is just fine. The RFC 2119 term is "REQUIRED", not "REQUIRES" or "REQUIRE" anyway, but = we have explicitly avoided lower-case versions of RFC 2119 terms in the = draft, precisely to avoid any possible confusion. --=20 Colin Perkins https://csperkins.org/ From nobody Wed Jun 10 11:34:35 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7843C1A00F3; Wed, 10 Jun 2015 11:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WzXR7BsIPn4; Wed, 10 Jun 2015 11:34:30 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 112AA1A0091; Wed, 10 Jun 2015 11:34:29 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t5AIYPKX017219; Wed, 10 Jun 2015 14:34:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1433961266; bh=bhnNdMnS9M/mCUISEP8TcP2nw3GptvSuIxvDDHOFa8I=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To; b=YgMaHQoSuzl3WMASp2GrjfSrTIaaZw6EDsnqYJgmNsN0RGNl052ZBNRRP7h63Kx55 +j+37tGW3b0jH8i8RyhQGQzJESXAB9pSxa8GHgsSCTlGbAFk1lfUyLF9RPMdeEgwkW e8YOWdrCguVz13WUJxuEfJCiFh7AMEJ0DFZTZHMo= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t5AIYKHC003932; Wed, 10 Jun 2015 14:34:20 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0210.002; Wed, 10 Jun 2015 14:34:20 -0400 From: Chris Inacio To: Adam Roach Thread-Topic: [rtcweb] sector review of draft-ietf-rtcweb-rtp-usage-23 Thread-Index: AQHQosbhcvT38Apty0Os5Xa8WMhXhJ2mJ7aAgAALVYD//9+Hag== Date: Wed, 10 Jun 2015 18:34:20 +0000 Message-ID: <2D926D03-6D62-4C9E-AA5B-330E168DD969@cert.org> References: <24C0D45F-DBF0-43A4-A2D6-B086F7EC368F@cert.org> <55785CA7.4090005@ericsson.com>,<55786629.6060705@nostrum.com> In-Reply-To: <55786629.6060705@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Magnus Westerlund , "rtcweb@ietf.org" , "iesg@ietf.org" , "draft-ietf-rtcweb-rtp-usage-23@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] [rtcweb] sector review of draft-ietf-rtcweb-rtp-usage-23 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 18:34:31 -0000 > On Jun 10, 2015, at 9:30 AM, Adam Roach wrote: >=20 > On 6/10/15 10:49, Magnus Westerlund wrote: >>> page 6: >>>=20 >>> =93This specification requires the usage of a single CNAME when sending >>> RTP Packet Streams=85=94 should the =93require=94 be =93REQUIRE=94? >>=20 >> This is intended as an informational reference, thus I propose to change= this to "mandates" thus avoiding the RFC2119 terms. >=20 > RFC 2119 doesn't remove the words "require", "must", "should", "may" and = "recommend" from the English language. If all you mean is the ordinary word= "require," (rather than the 2119 term "REQUIRE"), then "require" is just f= ine. >=20 > /a That was exactly my comment and you have made a thoughtful decision -- I'm = good.=20 -- Chris Inacio From nobody Wed Jun 10 12:09:27 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11FA11A86FA for ; Wed, 10 Jun 2015 12:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 eeDExXHV0Saz for ; Wed, 10 Jun 2015 12:09:21 -0700 (PDT) Received: from smtp122.iad3a.emailsrvr.com (smtp122.iad3a.emailsrvr.com [173.203.187.122]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F3C51A8029 for ; Wed, 10 Jun 2015 12:09:21 -0700 (PDT) Received: from smtp32.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp32.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id A430C380533; Wed, 10 Jun 2015 15:09:20 -0400 (EDT) Received: by smtp32.relay.iad3a.emailsrvr.com (Authenticated sender: scott-AT-hyperthought.com) with ESMTPSA id BF0DC380469; Wed, 10 Jun 2015 15:09:19 -0400 (EDT) X-Sender-Id: scott@hyperthought.com Received: from [192.168.128.56] (c-76-21-94-29.hsd1.ca.comcast.net [76.21.94.29]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:587 (trex/5.4.2); Wed, 10 Jun 2015 19:09:20 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Scott Kelly In-Reply-To: Date: Wed, 10 Jun 2015 12:09:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <93D1B0AD-7CA0-4143-9687-A9CE05170120@hyperthought.com> References: To: Martin Thomson X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: draft-ietf-httpbis-tunnel-protocol.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-httpbis-tunnel-protocol-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 19:09:23 -0000 Hi Martin, Comments below. On Jun 9, 2015, at 2:33 PM, Martin Thomson = wrote: > On 5 June 2015 at 05:24, Scott Kelly wrote: >> Sorry that this review is a few days late, I hope it is still useful. >=20 > Of course it is :) >=20 >> The ALPN header allows the client to tell the proxy which protocol(s) = it intends to encapsulate. This ALPN header is not authenticated, and = the draft makes no reference to client authentication and/or other = protocol security mechanisms, so I assume this exchange is not secured = in any way. >=20 > Correct. It's a "forward-looking statement" that couldn't be = validated anyway. >=20 >> Things I think should change: >>=20 >> The draft never says what the proxy should do if the client makes one = claim in the ALPN header, but then does something different (including = using different ALPNs in encapsulated TLS negotiations). Seems like it = should. >>=20 >> Also, the draft seems to suggest that it is okay to use the ALPN for = policy/authorization decisions. This is unreliable from a security = perspective. At minimum, I think the draft should explicitly call this = out. >=20 > Stephen made similar comments in his review. Those lead to the > addition of text: >=20 > = https://github.com/httpwg/http-extensions/compare/6c7b987e2b25e...master >=20 > Does that help at all? The intent is not to let this be used for > authorization decisions, but to allow a quick, clean "deny" decision > to be issued. The current state of play is pretty messy in that > regard. >=20 > Other changes (based on other reviews) resulted in more emphasis on > this being a hint, or an indication of intent. I looked at the modification at the github link above, but I still have = the same impression when I read the text. RFC3552 gives guidelines for writing security considerations text, and = one of the stated aims is to inform the reader of relevant security = issues. I don=92t think the current language does this. It states that = the proxy may make policy/authorization decisions based on the ALPN = header value (implying that this is generally okay). This has security = implications that a non-security-savvy person may not understand. The new language says (in part), + A proxy can use the value of the ALPN header field as input = to + authorization decisions. The header field exposes protocol + information at the HTTP layer, allowing authorization = decisions to be + made earlier, with better error reporting (such as a 403 = status code). The term =93authorization=94 evokes notions of security, at least for = me. This text gives me the impression that the ALPN header is suitable = for use in security decisions. I can think of a couple of ways to address this. One easy way is to = replace =93authorization=94 with something more security-neutral = (=93filtering=94? =93allow/deny=94?). Another is to simply add a = statement saying this header may be falsified by either the client or a = MitM, and therefore should not be relied upon for security-relevant = decisions unless additional security measures are applied. =97Scott From nobody Wed Jun 10 13:02:41 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A8A1A8AB3; Wed, 10 Jun 2015 13:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 GX74P-4lpMOF; Wed, 10 Jun 2015 13:02:27 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53E941A8AAC; Wed, 10 Jun 2015 13:02:27 -0700 (PDT) Received: by ykaz81 with SMTP id z81so1212200yka.3; Wed, 10 Jun 2015 13:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ES8HFFcox31RxvNJDxItqooBajunakrztMOIlFT3Nd4=; b=ZoRw/5AjAauye6KR4nZGu1SMLbfbfX+qtifl7b6j4OWI3OGZXxsyWs/98xKL49/wMc z+nGQpJLeGF8LTocaoClEeIAK6TkzHAzKgERIcEYFtxBqS7pslQGxdEixNhQVJT/7pDV iJbUz7pL1jixo2xT2IKksCIWmWolT2KGSojArbC/za5Hi542Umt+hS512dvj0euv+oAK q8i3jjSGA80+6YV7794D5Ml1EBk4966ZakVBRV0jP32zo6aI18DnBMnH8LA4oOsIqLnP HaTyf4MDxJBvuA5yja3uUNOLe7wm1HKUU2mRUC1s4aJkLU60atvWumyI1DhBEVtFNURA /sqg== MIME-Version: 1.0 X-Received: by 10.129.93.136 with SMTP id r130mr1901303ywb.52.1433966545309; Wed, 10 Jun 2015 13:02:25 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 10 Jun 2015 13:02:25 -0700 (PDT) In-Reply-To: <93D1B0AD-7CA0-4143-9687-A9CE05170120@hyperthought.com> References: <93D1B0AD-7CA0-4143-9687-A9CE05170120@hyperthought.com> Date: Wed, 10 Jun 2015 13:02:25 -0700 Message-ID: From: Martin Thomson To: Scott Kelly Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-httpbis-tunnel-protocol.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-httpbis-tunnel-protocol-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 20:02:31 -0000 On 10 June 2015 at 12:09, Scott Kelly wrote: > > + A proxy can use the value of the ALPN header field as input to > + authorization decisions. The header field exposes protocol > + information at the HTTP layer, allowing authorization decision= s to be > + made earlier, with better error reporting (such as a 403 statu= s code). > > The term =E2=80=9Cauthorization=E2=80=9D evokes notions of security, at l= east for me. This text gives me the impression that the ALPN header is suit= able for use in security decisions. > > I can think of a couple of ways to address this. One easy way is to repla= ce =E2=80=9Cauthorization=E2=80=9D with something more security-neutral (= =E2=80=9Cfiltering=E2=80=9D? =E2=80=9Callow/deny=E2=80=9D?). Another is to = simply add a statement saying this header may be falsified by either the cl= ient or a MitM, and therefore should not be relied upon for security-releva= nt decisions unless additional security measures are applied. Would it make more sense like this? A proxy can use the value of the ALPN header field to more cleanl= y and efficiently reject requests for a CONNECT tunnel. Exposing proto= col information at the HTTP layer allows a proxy to deny requests ear= lier, with better error reporting (such as a 403 status code). The ALP= N header field can be falsified and is therefore not sufficient bas= is for authorizing a request. From nobody Wed Jun 10 13:10:45 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3EC1A9112 for ; Wed, 10 Jun 2015 13:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPajBQqZU48S for ; Wed, 10 Jun 2015 13:10:36 -0700 (PDT) Received: from smtp66.iad3a.emailsrvr.com (smtp66.iad3a.emailsrvr.com [173.203.187.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 904C71A90CD for ; Wed, 10 Jun 2015 13:10:36 -0700 (PDT) Received: from smtp9.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id AA83E3804F4; Wed, 10 Jun 2015 16:10:35 -0400 (EDT) Received: by smtp9.relay.iad3a.emailsrvr.com (Authenticated sender: scott-AT-hyperthought.com) with ESMTPSA id 893293804EE; Wed, 10 Jun 2015 16:10:34 -0400 (EDT) X-Sender-Id: scott@hyperthought.com Received: from [192.168.128.56] (c-76-21-94-29.hsd1.ca.comcast.net [76.21.94.29]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:587 (trex/5.4.2); Wed, 10 Jun 2015 20:10:35 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Scott Kelly In-Reply-To: Date: Wed, 10 Jun 2015 13:10:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5604BEA6-52ED-455C-A8EF-0418CB874BA7@hyperthought.com> References: <93D1B0AD-7CA0-4143-9687-A9CE05170120@hyperthought.com> To: Martin Thomson X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: draft-ietf-httpbis-tunnel-protocol.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-httpbis-tunnel-protocol-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 20:10:43 -0000 On Jun 10, 2015, at 1:02 PM, Martin Thomson = wrote: > On 10 June 2015 at 12:09, Scott Kelly wrote: >>=20 >> + A proxy can use the value of the ALPN header field as = input to >> + authorization decisions. The header field exposes = protocol >> + information at the HTTP layer, allowing authorization = decisions to be >> + made earlier, with better error reporting (such as a 403 = status code). >>=20 >> The term =93authorization=94 evokes notions of security, at least for = me. This text gives me the impression that the ALPN header is suitable = for use in security decisions. >>=20 >> I can think of a couple of ways to address this. One easy way is to = replace =93authorization=94 with something more security-neutral = (=93filtering=94? =93allow/deny=94?). Another is to simply add a = statement saying this header may be falsified by either the client or a = MitM, and therefore should not be relied upon for security-relevant = decisions unless additional security measures are applied. >=20 >=20 > Would it make more sense like this? >=20 > A proxy can use the value of the ALPN header field to more = cleanly and > efficiently reject requests for a CONNECT tunnel. Exposing = protocol > information at the HTTP layer allows a proxy to deny requests = earlier, > with better error reporting (such as a 403 status code). The = ALPN > header field can be falsified and is therefore not sufficient = basis > for authorizing a request. Yes. Thanks, Scott From nobody Wed Jun 10 13:31:41 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610C71AC3F7; Wed, 10 Jun 2015 13:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKUTK0gjLpW1; Wed, 10 Jun 2015 13:31:29 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5F31A8AF3; Wed, 10 Jun 2015 13:31:29 -0700 (PDT) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t5AKVPPD019698; Wed, 10 Jun 2015 16:31:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1433968285; bh=mzppUFy1xpGixGdkun8nL7U+O23+P0JsH+cuwZpHJB8=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-ID:Content-Transfer-Encoding:MIME-Version: Sender:Reply-To; b=cD9Yu9MKDGXM3hrybFdqbkYHCVhzOhr5tCUxlgIBiX9z/nNGOSg9QI5Pg8BkMPJ+f VGheqWQ0UxGIkov+7U2Xdj2FRlMPEzoW6sYzZUuijRJGy83q4+1hl/OJTmlb8mTT4H s/YdUK7NaLdhX2qsd4njkCbBf/jyLI2oosv5pwho= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t5AKVTCe005093; Wed, 10 Jun 2015 16:31:29 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0210.002; Wed, 10 Jun 2015 16:31:22 -0400 From: Chris Inacio To: Magnus Westerlund Thread-Topic: sector review of draft-ietf-rtcweb-rtp-usage-23 Thread-Index: AQHQosbhcvT38Apty0Os5Xa8WMhXhJ2mJ7aAgABOk4A= Date: Wed, 10 Jun 2015 20:31:22 +0000 Message-ID: References: <24C0D45F-DBF0-43A4-A2D6-B086F7EC368F@cert.org> <55785CA7.4090005@ericsson.com> In-Reply-To: <55785CA7.4090005@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.96.46] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-rtcweb-rtp-usage-23@tools.ietf.org" , "rtcweb@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] sector review of draft-ietf-rtcweb-rtp-usage-23 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 20:31:32 -0000 DQoNCj4gT24gSnVuIDEwLCAyMDE1LCBhdCA4OjQ5IEFNLCBNYWdudXMgV2VzdGVybHVuZCA8bWFn bnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gDQo+IEhpLA0KPiANCj4gKEFk ZGluZyBSVENXRUIgV0cgbGlzdCBhcyB0aGlzIGRpc2N1c3NlcyBjaGFuZ2VzIHRvIHRoZSBkcmFm dCkNCj4gDQo+IFRoYW5rcyBmb3IgdGhlIHZlcnkgZGV0YWlsZWQgcmV2aWV3LiBXZSB3aWxsIGlu Y2x1ZGUgYWxsIHJlbGV2YW50IGNoYW5nZXMgaW4gYW4gdXBkYXRlIHRoYXQgd2lsbCBiZSBzdWJt aXR0ZWQgYWZ0ZXIgdGhlIElFU0cgY2FsbCB0b21vcnJvdy4NCj4gDQo+IFdHLCB0aGlzIGlzIHlv dXIgY2hhbmNlIHRvIHNjcmVhbSBpZiB0aGVyZSBhcmUgYmFkIGNoYW5nZXMgaGVyZS4NCj4gDQo+ IA0KPiBDaHJpcyBJbmFjaW8gc2tyZXYgZGVuIDIwMTUtMDYtMDkgMTc6MTM6DQo+PiANCj4+IA0K Pj4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkg ZGlyZWN0b3JhdGUncw0KPj4gb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3Vt ZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlDQo+PiBJRVNHLiAgVGhlc2UgY29tbWVudHMgd2Vy ZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlDQo+PiBzZWN1cml0eSBh cmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJl YXQNCj4+IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1l bnRzLg0KPj4gDQo+PiANCj4+IEJMVUY6ICBUaGlzIGRyYWZ0IGlzIHJlYWR5IHRvIGdvIHdpdGgg c29tZSBOSVRTLg0KPj4gDQo+PiANCj4+IFRoaXMgZHJhZnQgaXMgYW4gb3ZlcmFyY2hpbmcgc2V0 IG9mIGd1aWRlbGluZXMgb2YgdGhlIHVzZSBhbmQNCj4+IGFwcGxpY2F0aW9uIG9mIFJUUCBhbmQg UlRDUCBhcyBpdCBhcHBsaWVzIHRvIFdlYlJUQyBhbmQgdGhlIHJlbGF0ZWQNCj4+IFczQyBBUEku ICBUaGUgVzNDIEFQSSBpcyBub3QgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQsIGJ1dA0KPj4g cmVmZXJlbmNlcyB0byBmdW5jdGlvbmFsaXR5IHJlcXVpcmVtZW50cyBmb3IgdGhlIEFQSSBhcmUg bWFkZS4NCj4+IA0KPj4gVGhpcyBkcmFmdCBpcyBleHRyZW1lbHkgd2VsbCB3cml0dGVuLiAgQXQg dGhlIHNhbWUgdGltZSwgaG93ZXZlciwgaXQNCj4+IHJlYWRzIGxpa2UgYW4gZW5jeWNsb3BlZGlh IG9mIHJlZmVyZW5jZXMgYW5kIHJlcXVpcmVtZW50cyBhY3Jvc3MgMzUNCj4+IGRpZmZlcmVudCBu b3JtYXRpdmUgb3RoZXIgcmVmZXJlbmNlZCBkcmFmdHMuICBDb3JyZXNwb25kaW5nbHksIEkgZGlk DQo+PiBOT1QgcmVhZCB0aHJvdWdoIGFsbCBvZiB0aGUgcmVmZXJlbmNlZCBkcmFmdHMsIG5vciBk aWQgSSBiZWxpZXZlIHRoYXQNCj4+IGl0IHdhcyBuZWNlc3NhcnkgaW4gdGhpcyBjYXNlIHRvIGRv IHNvLg0KPj4gDQo+PiBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiB3YXMgY29t cHJlaGVuc2l2ZSBhbmQgc2VjdXJpdHkNCj4+IGltcGFjdHMgd2VyZSB0YWtlbiBpbnRvIGFjY291 bnQgdGhyb3VnaG91dCB0aGlzIGRyYWZ0LiAgSSBoYXZlIHR3bw0KPj4gc21hbGwgTklU4oCZcyBh Ym91dCB0aGUgc2VjdXJpdHkgc2VjdGlvbiB0aGF0IEkgd291bGQgbGlrZSBpbXByb3ZlZCwNCj4+ IGFuZCBJIGZlZWwgdGhlc2UgYXJlIHJhdGhlciBzbWFsbDoNCj4gDQo+IEZpcnN0LCBpbiB0aGUg cGFyYWdyYXBoIGluIHRoZQ0KPj4gc2VjdXJpdHkgc2VjdGlvbiB0aGF0IHN0YXJ0cyDigJxSVENQ IHBhY2tldHMgY29udmV5IGEgQ2Fub25pY2FsIE5hbWXigKbigJ0NCj4+IHRoZSBhdXRob3JzIHN0 YXRlIHRoYXQgdGhlIENOQU1FIGdlbmVyYXRpb24gYWxnb3JpdGhtIGluIGRlc2NyaWJlZCBpbg0K Pj4gc2VjdGlvbiA0Ljkg4oCTIGl0IGlzbuKAmXQsIHNlY3Rpb24gNC45IHJlZmVyZW5jZXMgUkZD NzAyMiBmb3IgdGhlDQo+PiBnZW5lcmF0aW9uIGFsZ29yaXRobS4NCj4gDQo+IFllcywgYnV0IGl0 IGFjdHVhbGx5IHNwZWNpZmllcyB3aGljaCBwYXJ0aWN1bGFyIGdlbmVyYXRpb24gYWxnb3JpdGht IHRvIHVzZS4gUkZDNzAyMiBkb2VzIGNvbnRhaW4gbW9yZSB0aGFuIG9uZS4NCj4gDQo+IEkgcHJv cG9zZSB0aGF0IHdlIGNoYW5nZSB0aGlzIHRleHQgdG8gc2F5Og0KPiANCj4gU2VjdGlvbiA0Ljkg b2YgdGhpcyBtZW1vIG1hbmRhdGVzIGdlbmVyYXRpb24gb2Ygc2hvcnQtdGVybSBwZXJzaXN0ZW50 IFJUQ1AgQ05BTUVTLCBhcyBzcGVjaWZpZWQgaW4gUkZDNzAyMiwgcmVzdWx0aW5nIGluIHVudHJh Y2VhYmxlIENOQU1FIHZhbHVlcyB0aGF0IGFsbGV2aWF0ZSB0aGlzIHJpc2suDQo+IA0KDQpsb29r cyBnb29kLg0KDQo+IFNlY29uZCwgdGhlIGxhc3QgcGFyYWdyYXBoIG9uIHBhZ2UgMzksDQo+PiBz dGFydGluZyB3aXRoIOKAnFByb3ZpZGluZyBzb3VyY2UgYXV0aGVudGljYXRpb24gaW4gbXVsdGkt cGFydHnigKbigJ0gZW5kcw0KPj4gdGhlIHBhZ2Ugd2l0aCBhIGxhcmdlIHNlY3VyaXR5IHdhcm5p bmcuICAgUGxlYXNlIGluY2x1ZGUgYSByZWZlcmVuY2UNCj4+IGluIHRoYXQgcGFyYWdyYXBoIGlu IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhbmQgcG9zc2libHkgdG8gdGhlDQo+PiBhcHBy b3ByaWF0ZSBkcmFmdC9SRkMgd2hpY2ggZGlzY3Vzc2VzIHRoYXQgaXNzdWUgaW4gc29tZSBtb3Jl IGRlcHRoLg0KPiANCj4gDQo+IElmIEkgdW5kZXJzdGFuZCB0aGlzIGNvcnJlY3RseSwgeW91IHdh bnQgc29tZXRoaW5nIGxpa2UgdGhlIGJlbG93IGFkZGVkIHRvIHRoZSBzZWN1cml0eSBjb25zaWRl cmF0aW9uIHNlY3Rpb24uIEkgc3VnZ2VzdCB0byBhZGQgdGhpcyBsYXN0IGluIHRoZSBzZWN0aW9u Lg0KPiANCj4gICBJbiBtdWx0aS1wYXJ0eSBjb21tdW5pY2F0aW9uIHNjZW5hcmlvcyB1c2luZyBS VFAgTWlkZGxlYm94ZXMsIGEgbG90DQo+ICAgb2YgdHJ1c3QgaXMgcGxhY2VkIG9uIHRoZXNlIG1p ZGRsZWJveGVzIHRvIHByZXNlcnZlIHRoZSBzZXNzaW9ucw0KPiAgIHNlY3VyaXR5LiAgVGhlIG1p ZGRsZWJveCBuZWVkcyB0byBtYWludGFpbiB0aGUgY29uZmlkZW50aWFsaXR5LA0KPiAgIGludGVn cml0eSBhbmQgcGVyZm9ybSBzb3VyY2UgYXV0aGVudGljYXRpb24uICBBcyBkaXNjdXNzZWQgaW4N Cj4gICBTZWN0aW9uIDEyLjEuMSB0aGUgbWlkZGxlYm94IGNhbiBwZXJmb3JtIGNoZWNrcyB0aGF0 IHByZXZlbnRzIGFueQ0KPiAgIGVuZHBvaW50IHBhcnRpY2lwYXRpbmcgaW4gYSBjb25mZXJlbmNl IHRvIGltcGVyc29uYXRlIGFub3RoZXIuICBTb21lDQo+ICAgYWRkaXRpb25hbCBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyByZWdhcmRpbmcgbXVsdGktcGFydHkgdG9wb2xvZ2llcw0KPiAgIGNhbiBi ZSBmb3VuZCBpbiBbSS1ELmlldGYtYXZ0Y29yZS1ydHAtdG9wb2xvZ2llcy11cGRhdGVdLg0KPiAN Cg0KVGhhdCB3b3VsZCBiZSBleGNlbGxlbnQuDQoNCj4+IA0KPj4gDQo+PiBnZW5lcmFsIE5JVFM6 DQo+PiANCj4+IEkgYmVsaWV2ZSB0aGVyZSBhcmUgbXVsdGlwbGUgdmVyc2lvbnMgb2Yg4oCcZW5k IHBvaW504oCdIHVzZWQgaW4gdGhlDQo+PiBkb2N1bWVudCBFbmQgUG9pbnQsIGVuZC1wb2ludCwg ZXRjLiAgVGhvc2Ugc2hvdWxkIGJlIGhhcm1vbml6ZWQuDQo+PiANCj4gDQo+IFllcywgd2Ugd2ls bCB1c2UgZW5kcG9pbnQNCj4gDQo+PiANCj4+IHBhZ2UgNDoNCj4+IA0KPj4gU2VjdGlvbiAyIFJh dGlvbmFsZQ0KPj4gDQo+PiDigJxUaGlzIGJ1aWxkcyBvbiB0aGUgcGFzdCAyMCB5ZWFycyBkZXZl bG9wbWVudCBvZiBSVFAgdG8gbWFuZGF0ZSB0aGUNCj4+IHVzZSBvZiBleHRlbnNpb25zIHRoYXQg aGF2ZSBzaG93biB3aWRlc3ByZWFkIHV0aWxpdHnigJ0NCj4+IA0KPj4gY2FuIHRoaXMgYmUgcmV3 b3JkZWQgdG8g4oCcVGhpcyBidWlsZHMgb24gdGhlIHBhc3QgMjAgeWVhcnMgb2YgUlRQDQo+PiBk ZXZlbG9wbWVudCB0byBtYW5kYXRlIHRoZSB1c2Ugb2YgZXh0ZW5zaW9ucyB0aGF0IGhhdmUgc2hv d24NCj4+IHdpZGVzcHJlYWQgdXRpbGl0eS7igJ0NCj4+IA0KPiANCj4gWWVzLg0KPiANCj4+IA0K Pj4gcGFnZSA2Og0KPj4gDQo+PiDigJxUaGlzIHNwZWNpZmljYXRpb24gcmVxdWlyZXMgdGhlIHVz YWdlIG9mIGEgc2luZ2xlIENOQU1FIHdoZW4gc2VuZGluZw0KPj4gUlRQIFBhY2tldCBTdHJlYW1z 4oCm4oCdICAgc2hvdWxkIHRoZSDigJxyZXF1aXJl4oCdIGJlIOKAnFJFUVVJUkXigJ0/DQo+IA0K PiBUaGlzIGlzIGludGVuZGVkIGFzIGFuIGluZm9ybWF0aW9uYWwgcmVmZXJlbmNlLCB0aHVzIEkg cHJvcG9zZSB0byBjaGFuZ2UgdGhpcyB0byAibWFuZGF0ZXMiIHRodXMgYXZvaWRpbmcgdGhlIFJG QzIxMTkgdGVybXMuDQo+IA0KPiANCknigJltIGdvb2Qgd2l0aCB0aGF0Lg0KDQo+PiANCj4+IHBh Z2UgNzoNCj4+IA0KPj4gIlRoaXMgdG8gZW5zdXJlIHJvYnVzdCBoYW5kbGluZyBvZiBmdXR1cmUg ZXh0ZW5zaW9uc+KApuKAnSB0byDigJxUaGlzIGlzIHRvDQo+PiBlbnN1cmXigKbigJ0NCj4gDQo+ IFN1cmUuDQo+IA0KPj4gDQo+PiBwYWdlIDE0Og0KPj4gDQo+PiBJbiByZWZlcmVuY2UgdG8gdGhl IHBhcmFncmFwaCB0aGF0IHN0YXJ0cyB3aXRoIOKAnFdoaWxlIHRoZSB1c2Ugb2YgSVANCj4+IG11 bHRpY2FzdC4uLuKAnS4gIFRoZXJlIGlzIG5vIE1BWS9TSE9VTEQvU0hBTEwvUkVRVUlSRSBldGMu IGluIHRoZQ0KPj4gcGFyYWdyYXBoLCBidXQgdGhlIGxhc3Qgc2VudGVuY2UgZG9lcyBzZWVtIHRv IGltcGx5IGFuIGltcGxlbWVudGF0aW9uDQo+PiByZXF1aXJlbWVudC4gIFdhcyB0aGF0IGludGVu dGlvbmFsPw0KPiANCj4gWWVzLCBpdCBpcyBpbnRlbnRpb25hbC4NCj4gDQo+PiANCj4+IHBhZ2Ug MTY6DQo+PiANCj4+IOKAnFRoaXMgY2FuIGJlIHZhcmlvdXMgcmVhc29ucyBmb3IgdGhpczrigKbi gJ0gIHRvIOKAnFRoZXJlIGNhbiBiZSB2YXJpb3VzDQo+PiByZWFzb25zIGZvciB0aGlzOuKApuKA nQ0KPiANCj4gQWRkcmVzc2VkIGluIC0yNCB2ZXJzaW9uLg0KPiANCj4+IA0KPj4gcGFnZSAyMDoN Cj4+IA0KPj4g4oCcaGV0ZXJvZ2VuZW91cyBuZXR3b3JrIGVudmlyb25tZW50cyB1c2luZyBhIHZh cmlldHkgc2V0IG9mIGxpbmsNCj4+IHRlY2hub2xvZ2llc+KApuKAnSBnZXQgcmlkIG9mIOKAnHNl dOKAnS4NCj4+IA0KPiBZZXMuDQo+IA0KPj4gcGFnZSAyMzoNCj4+IA0KPj4g4oCc4oCmc3VwcG9y dGVkIGJ5IHRoZSBSVENQIEV4dGVuZGVkIFJlcG9ydHMgKFhSKSBmcmFtZXdvcmsNCj4+IFtSRkMz NjExXVtSRkM2NzkyXS7igJ0gICBSRkMzNjExIHNlZW1zIHRvIGJlIGEgZnVsbCBmbGVkZ2VkIHJl ZmVyZW5jZQ0KPj4gd2hpbGUgUkZDNjc5MiBzZWVtcyB0byBqdXN0IGJlIHRleHQgb2Yg4oCcW1JG QzY3OTJd4oCdLg0KPj4gDQo+IA0KPiBUaGV5IGFyZSBib3RoIHJlbGV2YW50IHJlZmVyZW5jZXMg d2hlbiB1bmRlcnN0YW5kaW5nIHdoYXQgUlRDUCBYUiBhcmUgYW5kIHdoYXQgbWV0cmljcyBvbmUg c2hvdWxkIGNvbnNpZGVyLg0KPiANCj4gSSBwcm9wb3NlIHRvIGFkZCBhICJzZWUiIHNvIHRoYXQg dGhlIHJlc3VsdHMgYmVjb21lICIuLi4gZnJhbWV3b3JrLCBzZWUgW1JGQzM2MTFdW1JGQzY3OTJd Lg0KPiANCg0KSSB0aGluayBJIHdhcyBtaXN1bmRlcnN0b29kLCBsaWtlbHkgbXkgZmF1bHQuICBJ biB0aGUgUERGLCB0aGUgUkZDMzYxMSBzZWVtZWQgdG8gYmUgYSB0cnVlIHJlZmVyZW5jZSBpbiB0 aGUgZG9jdW1lbnQ7IGJ1dCBSRkM2NzkyIGRpZCBOT1Qgc2VlbSB0byBiZSBhIHJlZmVyZW5jZS4g IE1heWJlIGFuIGlzc3VlIGluIHRoZSBhY3R1YWwgWE1MLCBub3QgdGhlIHJlc3VsdGluZyBQREYv VFhULiAgSXQgbWF5IGJlIG5vdGhpbmcuDQoNCj4gDQo+PiBwYWdlIDI1Og0KPj4gDQo+PiBGaXJz dCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiAxMSBkZWZpbmVzIGEgbnVtYmVyIG9mIFdlYlJUQyBBUEkg dGVybXMsDQo+PiBQTEVBU0UgbW92ZSB0aG9zZSAoZmFyKSBmb3J3YXJkIGluIHRoZSBkb2N1bWVu dC4g4oCcVGhlDQo+PiBNZWRpYVN0cmVhbVRyYWNrcyB3aXRoaW4gYSBNZWRpYVN0cmVhbSBuZWVk IHRvIGJlIHBvc3NpYmxlIHRvIHBsYXkNCj4+IG91dCBzeW5jaHJvbml6ZWQu4oCdICByZXdyaXRl IHRvIOKAnFRoZSBNZWRpYVN0cmVhbVRyYWNrcyB3aXRoaW4gYQ0KPj4gTWVkaWFTdHJlYW0gbWF5 IG5lZWQgdG8gYmUgc3luY2hyb25pemVkIGR1cmluZyBwbGF5IGJhY2su4oCdICBvcg0KPj4gc29t ZXRoaW5nIHNpbWlsYXIuDQo+IA0KPiBJIGhhdmUgYWRkZWQgYWxzbyBNZWRpYVN0cmVhbVRyYWNr IHRvIHRoZSBUZXJtaW5vbG9neSBzZWN0aW9uICgzKS4gQW5kIHBvcHVsYXRlZCBib3RoIE1lZGlh U3RyZWFtIGFuZCBNZWRpYVN0cmVhbVRyYWNrIHdpdGggdGV4dCBmcm9tIHRoaXMgcGFyYWdyYXBo LiBJIGhhdmUgaG93ZXZlciBub3QgcmVtb3ZlZCBhbnkgdGV4dCBmcm9tIHRoaXMgcGFyYWdyYXBo IGluIFNlY3Rpb24gMTEuDQo+IA0KPiANCnNvdW5kcyBnb29kLg0KDQo+PiANCj4+IHBhZ2UgMjY6 DQo+PiANCj4+IOKAnGZvcmNlIGFuIGVuZC1wb2ludCB0byB0byBkaXNydXB04oCdICBvbmx5IG9u ZSDigJx0b+KAnS4NCj4gDQo+IE9rDQo+IA0KPj4gDQo+PiDigJxUaGlzIGlzIG1vdGl2YXRpbmcg dGhlIGRpc2N1c3Npb24gaW4gU2VjdGlvbiA0LjnigJ0sICh5ZXMsIG5vdyBJ4oCZbQ0KPj4gcmVh bGx5IGdldHRpbmcgcGlja3ksKSBidXQgdGhlIGRpc2N1c3Npb24gd2FzIGFscmVhZHkgbW90aXZh dGVkLiAgOikNCj4gDQo+IENoYW5nZWQgdGhpcyB0bzoNCj4gDQo+IFRoaXMgaXMgbW90aXZhdGlu ZyB0aGUgdXNlIG9mIGEgc2luZ2xlIENOQU1FIGluIFNlY3Rpb24gNC45Lg0KPiANCjopDQoNCg0K Pj4gDQo+PiBwYWdlIDI3Og0KPj4gDQo+PiDigJxPcHRpbWl6YXRpb25zIG9mIHRoaXMgbWV0aG9k IGlzIGNsZWFybHkgcG9zc2libGUgYW5kIOKApuKAnSAg4oCcaXPigJ0gLT4NCj4+IOKAnGFyZeKA nQ0KPiANCj4gb2sNCj4gDQo+PiANCj4+IOKAnHJlY2VpdmluZyBtdWx0aXBsZSBNZWRpYVN0cmVh bVRyYWNrcywgd2hlcmUgZWFjaCBvZiBkaWZmZXJlbnQNCj4+IE1lZGlhU3RyZWFtVHJhY2tzIChh bmQg4oCm4oCdIHRvIOKAnCDigKYgd2hlcmUgZWFjaCBvZiAqdGhlKiBkaWZmZXJlbnQNCj4+IE1l ZGlhU3RyZWFtVHJhY2tzIOKApiDigJwNCj4gDQo+IEZpeGVkDQo+IA0KPj4gDQo+PiDigJxUaGlz IGxhdGVyIGlzIHJlbGV2YW50IHRvIGhhbmRsZSBzb21lIGNhc2VzIG9mIGxlZ2FjeSBpbnRlcm9w LuKAnSB0bw0KPj4g4oCcVGhlIGxhdGVyIGlzIHJlbGV2YW50IOKApiBsZWdhY3kgaW50ZXJvcGVy YWJpbGl0eS7igJ0NCj4+IA0KPiANCj4gT2sNCj4gDQo+IA0KPj4gcGFnZSAyODoNCj4+IA0KPj4g 4oCcLiAuIC4gRW5kcG9pbnRzIGNhbiBjb25maWd1cmUgYW5kIHVzZSBSVFAgc2Vzc2lvbnMgaXMg b3V0bGluZWQu4oCdDQo+PiBjaGFuZ2Ug4oCcaXPigJ0gdG8g4oCcYXJl4oCdDQo+IA0KPiANCj4+ IA0KPj4g4oCcIC4gLiAuIGl0IGlzIGNvbW1vbiB0byB1c2Ugb25lIFJUUCBzZXNzaW9uIGZvciBl YWNoIHR5cGUgb2YgbWVkaWENCj4+IHNvdXJjZXMgKGUuZy4gLiAuIC7igJ0gIGNoYW5nZSDigJxz b3VyY2Vz4oCdIHRvIOKAnHNvdXJjZeKAnQ0KPj4gDQo+PiBwYWdlIDMxOg0KPj4gDQo+PiDigJxU byBtYWludGFpbiBhIGNvaGVyZW50IG1hcHBpbmcgYmV0d2VlbiB0aGUgcmVsYXRpb24gYmV0d2Vl biBSVFANCj4+IHNlc3Npb25zIGFuZCBSVENQZWVyQ29ubmVjdGlvbiBvYmplY3RzIGl0IGlzIOKA puKAnSAgcmV3cml0ZSB0byBtYXliZQ0KPj4gDQo+PiDigJxUbyBtYWludGFpbiBhIGNvaGVyZW50 IG1hcHBpbmcgYmV0d2VlbiB0aGUgcmVsYXRpb25zaGlwIG9mIFJUUA0KPj4gc2Vzc2lvbnMgYW5k IFJUQ1BlZXJDb25uZWN0aW9uIG9iamVjdHMgaXQgaXMg4oCmLuKAnQ0KPiANCj4gSSBwcm9wb3Nl Og0KPiANCj4gVG8gbWFpbnRhaW4gYSBjb2hlcmVudCBtYXBwaW5nIG9mIHRoZSByZWxhdGlvbnNo aXAgYmV0d2VlbiBSVFAgc2Vzc2lvbnMgYW5kIFJUQ1BlZXJDb25uZWN0aW9uIG9iamVjdHMgaXQg aXMgcmVjb21tZW5kIHRoYXQgdGhpcyBpcyBpbXBsZW1lbnRlZCBhcyBzZXZlcmFsIGluZGl2aWR1 YWwgUlRQIHNlc3Npb25zLg0KPiANCg0KbG9va3MgZ29vZC4NCg0KDQo+PiANCj4+IHBhZ2UgMzI6 DQo+PiANCj4+IOKAnFRoaXMgc2NlbmFyaW8gYWxzbyByZXN1bHRzIGluIHRoYXQgYW4gZW5kLXBv aW504oCZcyBmZWVkYmFjayBvcg0KPj4gcmVxdWVzdHMgZ29lcyB0byB0aGUgbWl4ZXLigKbigJ0g IGNoYW5nZSDigJxnb2Vz4oCdIHRvIOKAnGdv4oCdLg0KPiANCj4gb2sNCj4gDQo+PiANCj4+IOKA nG5lY2Vzc2FyaWx5IGJlIGV4cGxpY2l0bHkgdmlzaWJsZSBhbnkgUlRQIGFuZCBSVENQIHRyYWZm aWMg4oCm4oCdIHRvDQo+PiDigJxuZWNlc3NhcmlseSBiZSBleHBsaWNpdGx5IHZpc2libGUgdG8g YW55IFJUUCBhbmQgUlRDUCB0cmFmZmlj4oCdLg0KPiANCj4gWWVzDQo+IA0KPj4gDQo+PiBwYWdl IDM4Og0KPj4gDQo+PiDigJxjb21iaW5n4oCdIHRvIOKAnGNvbWJpbmluZ+KAnQ0KPj4gDQo+IA0K PiBvaw0KPiANCj4+IA0KPj4gDQo+PiAtLSBDaHJpcyBJbmFjaW8gaW5hY2lvQGNlcnQub3JnDQo+ PiANCj4+IA0KPj4gDQo+IA0KPiBDaGVlcnMNCj4gDQo+IE1hZ251cyBXZXN0ZXJsdW5kDQo+IA0K DQpncmVhdC4gIEl0IGlzIGEgdmVyeSB3ZWxsIHdyaXR0ZW4gZHJhZnQuDQoNCg0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IFNlcnZpY2VzLCBNZWRpYSBhbmQgTmV0d29yayBmZWF0dXJlcywgRXJpY3Nzb24g UmVzZWFyY2ggRUFCL1RYTQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IEVyaWNzc29uIEFCICAgICAgICAg ICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0KPiBGw6Ryw7ZnYXRhbiA2ICAgICAgICAg ICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KPiBTRS0xNjQgODAgU3RvY2tob2xtLCBT d2VkZW4gfCBtYWlsdG86IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IA0KDQoNCg0KLS0NCkNocmlzIEluYWNpbw0KaW5hY2lvQGNlcnQub3JnDQoNCg0K From nobody Wed Jun 10 14:28:45 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC58C1B2BFA; Wed, 10 Jun 2015 14:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 2CJuVSwSFPas; Wed, 10 Jun 2015 14:28:40 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F301B2BDE; Wed, 10 Jun 2015 14:28:40 -0700 (PDT) Received: by yhpn97 with SMTP id n97so26067277yhp.0; Wed, 10 Jun 2015 14:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XqoZ00EoZw0sBIOIoaP5pW9HXAstq6pkgV83LfDftZc=; b=JQMlw6pB8pMQSnDVOKuRNmzqZzxoDIaTyVN1D/w8vNoDN7iJ5dNGy9tD6cjq3JmlG/ dGtB7yNSzU86xYY6ilg5k0YVJot6odzbvbigrazf9yfYusUiKGahCWtpkxoPsjvFMBjU yf9PhqnDfoZAuaE0hsWGdwYQoMfbJkWn9lFWhBnuyHhQbc34M2XbpYUHz0Ydgrto1vuz uoG6T6aYEjWW+fdA7Iaixu3HDrxz+2ArinqfgqlpxiDqFXa/nAryfkE8Y1g0e7eS7pNN i5UTmU0vRqDgxE6RIgYdInvn4QTKbdVwrQFyezXyanmp0gC+NQzVoUKpMEXiLEWZXLEj 03lg== MIME-Version: 1.0 X-Received: by 10.129.36.14 with SMTP id k14mr7218044ywk.64.1433971719449; Wed, 10 Jun 2015 14:28:39 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 10 Jun 2015 14:28:39 -0700 (PDT) In-Reply-To: <5604BEA6-52ED-455C-A8EF-0418CB874BA7@hyperthought.com> References: <93D1B0AD-7CA0-4143-9687-A9CE05170120@hyperthought.com> <5604BEA6-52ED-455C-A8EF-0418CB874BA7@hyperthought.com> Date: Wed, 10 Jun 2015 14:28:39 -0700 Message-ID: From: Martin Thomson To: Scott Kelly Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-httpbis-tunnel-protocol.all@tools.ietf.org, The IESG , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-httpbis-tunnel-protocol-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 21:28:41 -0000 On 10 June 2015 at 13:10, Scott Kelly wrote: > On Jun 10, 2015, at 1:02 PM, Martin Thomson wrote: >> Would it make more sense like this? >> >> A proxy can use the value of the ALPN header field to more cleanly and >> efficiently reject requests for a CONNECT tunnel. Exposing protocol >> information at the HTTP layer allows a proxy to deny requests earlier, >> with better error reporting (such as a 403 status code). The ALPN >> header field can be falsified and is therefore not sufficient basis >> for authorizing a request. > > Yes. Thanks Scott. https://github.com/httpwg/http-extensions/commit/3fb72e95 From nobody Wed Jun 10 15:21:55 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4474D1A88A7 for ; Wed, 10 Jun 2015 15:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.768 X-Spam-Level: X-Spam-Status: No, score=0.768 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=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 iwCTkT2T7FCt for ; Wed, 10 Jun 2015 15:21:52 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 0B04F1A8899 for ; Wed, 10 Jun 2015 15:21:51 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t5AMLm2I018803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 11 Jun 2015 01:21:48 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t5AMLmnV003346; Thu, 11 Jun 2015 01:21:48 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21880.47228.391502.941735@fireball.kivinen.iki.fi> Date: Thu, 11 Jun 2015 01:21:48 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 22:21:54 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Tina TSOU is next in the rotation. For telechat 2015-06-11 Reviewer LC end Draft Alan DeKok T 2015-05-01 draft-ietf-dprive-problem-statement-05 Jeffrey Hutzelman T 2015-06-03 draft-ietf-rtcweb-video-05 Leif Johansson T 2015-05-25 draft-ietf-mip4-multiple-tunnel-support-12 Matt Lepinski T 2015-06-03 draft-ietf-xmpp-6122bis-23 Eric Osterweil T 2015-04-29 draft-perrault-behave-deprecate-nat-mib-v1-02 For telechat 2015-06-25 Sandy Murphy T 2015-06-12 draft-ietf-manet-olsrv2-management-snapshot-03 Magnus Nystrom T 2015-06-18 draft-ietf-rtgwg-lfa-manageability-08 Joe Salowey T 2015-06-17 draft-ietf-tzdist-service-08 For telechat 2015-07-09 Robert Sparks T 2015-06-24 draft-ietf-hybi-permessage-compression-21 Takeshi Takahashi T 2015-07-03 draft-ietf-karp-isis-analysis-04 Last calls and special requests: Catherine Meadows 2015-06-09 draft-ietf-dhc-access-network-identifier-08 Alexey Melnikov 2015-06-17 draft-ietf-avtcore-rtp-topologies-update-07 Matthew Miller 2015-06-11 draft-ietf-homenet-prefix-assignment-06 Hilarie Orman 2015-06-17 draft-ietf-sipcore-6665-clarification-00 Vincent Roca 2015-06-17 draft-ietf-sipcore-refer-explicit-subscription-02 Yaron Sheffer 2015-06-23 draft-ietf-dnsop-negative-trust-anchors-10 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Hannes Tschofenig 2015-07-07 draft-wkumari-dhc-capport-12 -- kivinen@iki.fi From nobody Thu Jun 11 01:08:38 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957861ACD0D; Thu, 11 Jun 2015 01:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BBGQSgoEjOY; Thu, 11 Jun 2015 01:08:29 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 ABB9D1AC3B6; Thu, 11 Jun 2015 01:08:29 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id C61CFEC0798C; Thu, 11 Jun 2015 08:08:25 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t5B88O61016691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Jun 2015 10:08:25 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 11 Jun 2015 10:08:08 +0200 From: "DRAGE, Keith (Keith)" To: Colin Perkins , Adam Roach Thread-Topic: [rtcweb] sector review of draft-ietf-rtcweb-rtp-usage-23 Thread-Index: AQHQo5UyIGbw77cZCECqEegNh+rEXZ2lzNmAgAAgDICAAQbP0A== Date: Thu, 11 Jun 2015 08:08:08 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B69728E95@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <24C0D45F-DBF0-43A4-A2D6-B086F7EC368F@cert.org> <55785CA7.4090005@ericsson.com> <55786629.6060705@nostrum.com> <1F558D60-16EB-40B5-B7F8-C51FC2CE604B@csperkins.org> In-Reply-To: <1F558D60-16EB-40B5-B7F8-C51FC2CE604B@csperkins.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-rtcweb-rtp-usage-23@tools.ietf.org" , "rtcweb@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] [rtcweb] sector review of draft-ietf-rtcweb-rtp-usage-23 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 08:08:31 -0000 I support Colin on this. Using lower case versions of RFC 2119 terms causes its own confusions. It is usually easy to maintain clarity while avoiding this. Keith > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of=20 > Colin Perkins > Sent: 10 June 2015 19:25 > To: Adam Roach > Cc: secdir@ietf.org; rtcweb@ietf.org; iesg@ietf.org;=20 > draft-ietf-rtcweb-rtp-usage-23@tools.ietf.org; Chris Inacio > Subject: Re: [rtcweb] sector review of draft-ietf-rtcweb-rtp-usage-23 >=20 > On 10 Jun 2015, at 17:30, Adam Roach wrote: > > On 6/10/15 10:49, Magnus Westerlund wrote: > >>> page 6: > >>>=20 > >>> "This specification requires the usage of a single CNAME=20 > when sending > >>> RTP Packet Streams..." should the "require" be "REQUIRE"? > >>=20 > >> This is intended as an informational reference, thus I=20 > propose to change this to "mandates" thus avoiding the RFC2119 terms. > >=20 > > RFC 2119 doesn't remove the words "require", "must",=20 > "should", "may" and "recommend" from the English language. If=20 > all you mean is the ordinary word "require," (rather than the=20 > 2119 term "REQUIRE"), then "require" is just fine. >=20 > The RFC 2119 term is "REQUIRED", not "REQUIRES" or "REQUIRE"=20 > anyway, but we have explicitly avoided lower-case versions of=20 > RFC 2119 terms in the draft, precisely to avoid any possible=20 > confusion. >=20 > -- > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From nobody Thu Jun 11 01:21:03 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82201ACC87; Thu, 11 Jun 2015 01:20:57 -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 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 OsFkgVy0F5kv; Thu, 11 Jun 2015 01:20:56 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76501ACAD5; Thu, 11 Jun 2015 01:20:55 -0700 (PDT) X-AuditID: c1b4fb30-f799f6d000000faf-99-557944e587f5 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D4.56.04015.5E449755; Thu, 11 Jun 2015 10:20:54 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.210.2; Thu, 11 Jun 2015 10:20:53 +0200 Message-ID: <557944E3.7030809@ericsson.com> Date: Thu, 11 Jun 2015 10:20:51 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Chris Inacio References: <24C0D45F-DBF0-43A4-A2D6-B086F7EC368F@cert.org> <55785CA7.4090005@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM+Jvre4zl8pQg6m/mCzmtMZbzPgzkdli 4dqTjBZr/7WzW3xY+JDFgdVjxgYfjyVLfjJ5fLn8mS2AOYrLJiU1J7MstUjfLoEr43n3XbaC abwVR5Z3MjcwnuDqYuTkkBAwkXh7fiY7hC0mceHeerYuRi4OIYGjjBIL1+9ignCWM0psfNfH BlLFK6At0XdjPhOIzSKgKvH9zQtWEJtNwELi5o9GsBpRgSiJqY/XsUDUC0qcnPkEzBYRUJJY fuA2M8hQZoErjBLdi6aAJYQFbCQWzfgHtbqbUaJj6jawDZxAidMztjGC2MxAG2bOPw9ly0s0 b53NDGILAV3U0NTBOoFRcBaShbOQtMxC0rKAkXkVo2hxanFSbrqRkV5qUWZycXF+nl5easkm RmBgH9zy22AH48vnjocYBTgYlXh4F7yuCBViTSwrrsw9xCjNwaIkzjtjc16okEB6Yklqdmpq QWpRfFFpTmrxIUYmDk6pBsZs+Slb32VIfv0Z8WBfxI+O/aYClw48Zv5zadpPnuMH28yOJSpc /v+jpe5Recnjt5IFTr3XuEPWJ1+oMZd4afH3yMHLMkxrpD/UZfU3hm2KXc19pq3m9iqOnKW9 fAVWPye4yhwpni8b8axg8l9NUZPV3R48y3fJp9aW/9pvuskvYrXL9HcfG1SUWIozEg21mIuK EwGY56AITQIAAA== Archived-At: Cc: "draft-ietf-rtcweb-rtp-usage-23@tools.ietf.org" , "rtcweb@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] sector review of draft-ietf-rtcweb-rtp-usage-23 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 08:20:58 -0000 Hi Snipping it down to a single thing I want to comment on. Chris Inacio skrev den 2015-06-10 22:31: > > >> On Jun 10, 2015, at 8:49 AM, Magnus Westerlund wrote: >> >>> page 23: >>> >>> “…supported by the RTCP Extended Reports (XR) framework >>> [RFC3611][RFC6792].” RFC3611 seems to be a full fledged reference >>> while RFC6792 seems to just be text of “[RFC6792]”. >>> >> >> They are both relevant references when understanding what RTCP XR are and what metrics one should consider. >> >> I propose to add a "see" so that the results become "... framework, see [RFC3611][RFC6792]. >> > > I think I was misunderstood, likely my fault. In the PDF, the > RFC3611 seemed to be a true reference in the document; but RFC6792 did NOT seem to be a reference. Maybe an issue in the actual XML, not the resulting PDF/TXT. It may be nothing. I haven't looked at the PDF generated at all before. It appear as a bug in the generation. Both these are xref items in the XML source. So it must be something when putting two xref after each other and no display text. I have reported this as a bug in the XML2RFC tracker. cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Jun 11 01:26:14 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC9B1ACCE1; Thu, 11 Jun 2015 01:26:08 -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 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 ouh4r_ayixIA; Thu, 11 Jun 2015 01:26:07 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A151ACC92; Thu, 11 Jun 2015 01:26:06 -0700 (PDT) X-AuditID: c1b4fb30-f799f6d000000faf-67-557945f89e35 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 9B.27.04015.8F549755; Thu, 11 Jun 2015 10:25:29 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.210.2; Thu, 11 Jun 2015 10:25:28 +0200 Message-ID: <557945F8.9080504@ericsson.com> Date: Thu, 11 Jun 2015 10:25:28 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , Colin Perkins , Adam Roach References: <24C0D45F-DBF0-43A4-A2D6-B086F7EC368F@cert.org> <55785CA7.4090005@ericsson.com> <55786629.6060705@nostrum.com> <1F558D60-16EB-40B5-B7F8-C51FC2CE604B@csperkins.org> <949EF20990823C4C85C18D59AA11AD8B69728E95@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69728E95@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvra6MW2WowYSvShZ7/i5it1j+8gSj xZzWeIsZfyYyWyxce5LR4mnjWUaLtf/a2S0+LHzI4sDh0fpsL6vHjA0+HtPu32fzWLLkJ5PH rJ1PWDy+XP7MFsAWxWWTkpqTWZZapG+XwJVxqecBW8E5zoppM1cxNjBeY+9i5OSQEDCRuL1l DSuELSZx4d56ti5GLg4hgaOMEpMmzIdyljNKbHu0E6yDV0BbovfbCzCbRUBVYu/yvywgNpuA hcTNH41sILaoQJTE1MfrWCDqBSVOznwCZosI1Es0tR5lArGZBb4wStz4xQ1iCwu4Suz92cgI sayBSWLmvmNgDZwCsRLPG1uBlnEANdhLPNhaBtErL9G8dTYziC0EdE9DUwfrBEbBWUjWzULo mIWkYwEj8ypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwHg4uOW3wQ7Gl88dDzEKcDAq8fAu eF0RKsSaWFZcmXuIUZqDRUmcd8bmvFAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjJ0B0y+U P+Nw4rpVbp7OuJDX5fvy2vsC5v2iJ6eW2t08IJN0/4POj6Qkg3pmtRbGj29vN4nPceBdt3ct d95n1VLJWGPpp93taeqs6pJvVez1FrzZ98n1EYvvC7H4svqNprWnPadvv8MkFiPb7pJlf+HZ zxdLbX7vqJFvW7j26vzrnc379yg+UmIpzkg01GIuKk4EAFTBN7BoAgAA Archived-At: Cc: "draft-ietf-rtcweb-rtp-usage-23@tools.ietf.org" , "rtcweb@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] [rtcweb] sector review of draft-ietf-rtcweb-rtp-usage-23 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 08:26:08 -0000 DRAGE, Keith (Keith) skrev den 2015-06-11 10:08: > I support Colin on this. > > Using lower case versions of RFC 2119 terms causes its own confusions. I have heard some people argue that also the lower case usage have the RFC 2119 meaning. The RFC 2119 to some degree support such an interpretation, but is not more explicit than this. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. > > It is usually easy to maintain clarity while avoiding this. > Yes, and the rewrite here was trivial and conveys the same meaning. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Jun 11 14:25:28 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406E61ABB1A; Thu, 11 Jun 2015 14:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeXQqY84zBRX; Thu, 11 Jun 2015 14:25:24 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0130.outbound.protection.outlook.com [207.46.100.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C2F21A8869; Thu, 11 Jun 2015 14:25:24 -0700 (PDT) Received: from BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) by BY2PR03MB508.namprd03.prod.outlook.com (10.141.143.27) with Microsoft SMTP Server (TLS) id 15.1.184.17; Thu, 11 Jun 2015 21:25:24 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.195.6; Thu, 11 Jun 2015 21:25:22 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0195.005; Thu, 11 Jun 2015 21:25:22 +0000 From: Mike Jones To: "Adam W. Montville" , The IESG , "secdir@ietf.org" , "draft-ietf-jose-jwk-thumbprint.all@ietf.org" Thread-Topic: sector review of draft-ietf-jose-jwk-thumbprint-05 Thread-Index: AQHQogJgaphBjlti2Uu758g0GQEF3p2nztYw Date: Thu, 11 Jun 2015 21:25:22 +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: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e0:ee43::6] x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:d9Ho590BsYK5Qe32G3meUj+fWL+1noc4EBJZBPT858zyApvFD7nDFmeF6NZTxvxXqKswewpdaedCo04mhB3UHu2qd+V/tu0Sbsfnv7kkWdUXZikTtv+w5Nw/wrdzWcAFo+tY2Z+halFvL+DK5E95ow==; 24:D1/cJGrZQrW8SuDG5bW+hAZy+X3+gjHGJ2bJeggWRKa/Xqfv+uyIazK+Vis4+so2M5YK1lVDJ54CFzYsM7D8X77S3YmBJVrZ183f/qL95xU=; 20:8ddfMdLv9wvj4/89snG7e+9GKR8vUDXJHV41D6B8MKNTlaWjjtukdhNyxCmfrOtBKr6z4PfkH7b27ScQHZ8Gwg== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB508; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 0604AFA86B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(43784003)(71364002)(51704005)(5003600100002)(2900100001)(92566002)(2950100001)(77096005)(62966003)(77156002)(5001960100002)(2201001)(46102003)(230783001)(86612001)(99286002)(86362001)(2501003)(40100003)(15975445007)(2656002)(19580405001)(19580395003)(54356999)(5002640100001)(122556002)(76176999)(76576001)(33656002)(50986999)(106116001)(5001770100001)(102836002)(74316001)(87936001)(189998001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2015 21:25:22.6629 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB508; 2:V6cT3Atht8izR7pLuSuqcxNM1z/6TPHtf2fiQOMxrPHAKRFBkroX5z7500llu9st; 2:xKZVWc/13nrMdOS41H8VaZ64tRqQgWjuX3GEdKban1eOpx6+1TIL3ktLlhr015zPSfAKiUBwKeQSVDh5K3nj3eXxQpzn8IW5PxGxj7mjcp88mjK89kWF5IeS9oD35J5fV5a/KMF7ngMnHGPb2D5doQ==; 9:/lniCRXPfCAMtc/uTi/zhwoD0hCAOsW4vFG2XObCligKru5n//UoEp3Hz7vtV/QmkWfE34mS4DogD3EB7aT/aU44KgisG8jU2UEHXYcQUqSsozoNtbp26MJA46NAHfFUkzL9hEQAr+yOo2drqVz9mg== X-OriginatorOrg: microsoft.com Archived-At: Cc: "jose@ietf.org" Subject: Re: [secdir] sector review of draft-ietf-jose-jwk-thumbprint-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 21:25:26 -0000 SGkgQWRhbSwNCg0KVGhhbmtzIGZvciB0aGUgc2VjZGlyIHJldmlldy4NCg0KPiBGcm9tOiBBZGFt IFcuIE1vbnR2aWxsZSBbbWFpbHRvOmFkYW0udy5tb250dmlsbGVAZ21haWwuY29tXQ0KPiBTZW50 OiBNb25kYXksIEp1bmUgMDgsIDIwMTUgODo0NiBBTQ0KPiBUbzogVGhlIElFU0c7IHNlY2RpckBp ZXRmLm9yZzsgZHJhZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnByaW50LmFsbEBpZXRmLm9yZw0KPiBT dWJqZWN0OiBzZWN0b3IgcmV2aWV3IG9mIGRyYWZ0LWlldGYtam9zZS1qd2stdGh1bWJwcmludC0w NQ0KDQo+IEhpLA0KDQo+IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2Yg dGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJ RVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuIFRoZXNlIGNvbW1lbnRz IHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBh cmVhIGRpcmVjdG9ycy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVh dCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4N Cj4NCj4gSSBiZWxpZXZlIHRoZSBkb2N1bWVudCBpcyByZWFkeSB3aXRoIChwb3RlbnRpYWwpIGlz c3Vlcy4gIFRoZSDigJx3aXRoIGlzc3Vlc+KAnSBtaWdodCBiZSBkdWUgdG8gaWdub3JhbmNlIG9u IG15IHBhcnQuICBUaGUgZHJhZnQgZG9lcyBhIHZlcnkgZ29vZCBqb2Igb2YgZXhwbGFpbmluZyB0 aGUgY2Fub25pY2FsIGZvcm0gb2YgYSBKU09OIFdlYiBLZXkgdGhhdCBjYW4gYmUgdXNlZCBmb3Ig ZXN0YWJsaXNoaW5nIGEgdGh1bWJwcmludCB1bmRlciB2YXJ5aW5nIGNpcmN1bXN0YW5jZXMsIGNv bXBsZXRlIHdpdGggd2hhdCBJIGZvdW5kIHRvIGJlIGhlbHBmdWwgZXhhbXBsZXMuDQo+DQo+IFRo ZSBwcmltYXJ5IGlzc3VlIEkgaGF2ZSBpcyB0aGF0IGl04oCZcyB1bmNsZWFyIGhvdyByZWx5aW5n IHBhcnRpZXMgYXJlIGdvaW5nIHRvIGtub3cgd2hpY2ggaGFzaCBhbGdvcml0aG0gaGFzIGJlZW4g dXNlZC4gIFRoZSBleGFtcGxlcyB1c2UgU0hBLTI1NiwgYnV0IEnigJltIG5vdCBzZWVpbmcgd2hl cmUgU0hBLTI1NiBtaWdodCBiZSBzcGVjaWZpZWQgYXMgYSBNVVNUIG9yIGV2ZW4gYSBTSE9VTEQu ICBNb3Jlb3ZlciwgdGhlIGV4YW1wbGUgb3V0cHV0IHVsdGltYXRlbHkgc2hvd3Mgb25seSB0aGUg QmFzZS02NCBlbmNvZGluZyBvZiB0aGUgcmVzdWx0aW5nIGhhc2gsIHdoaWNoIHNheXMgbm90aGlu ZyBhYm91dCB0aGUgYWxnb3JpdGhtIHVzZWQgdG8gaWRlbnRpZnkgYSBrZXkuDQoNCkVhcmxpZXIg ZHJhZnRzIGhhZCBpbmNsdWRlZCBmaWVsZHMgd2hvc2UgbmFtZXMgd2VyZSBpbnRlbmRlZCB0byBj b21tdW5pY2F0ZSB0aGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGhhc2ggZnVuY3Rpb24gdXNlZCAt IHNlZSB0aGUgImprdCIgZmllbGQgZGVmaW5pdGlvbnMgaW4gaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnByaW50LTAxI3NlY3Rpb24tNCAtIGJ1dCBz ZXZlcmFsIHdvcmtpbmcgZ3JvdXAgcmV2aWV3ZXJzIHN1Z2dlc3RlZCB0aGF0IHRoZXNlIGZpZWxk cyB3ZXJlIHVubmVjZXNzYXJ5IGFuZCB0aGF0IHRoZSB0eXBpY2FsIHVzYWdlIHdvdWxkIGJlIGFz ICJraWQiIChrZXkgSUQpIGZpZWxkIHZhbHVlcy4gIFdpdGggdGhhdCByZW1vdmFsLCBpdCBmYWxs cyBvbnRvIHRoZSBhcHBsaWNhdGlvbiB0byBzcGVjaWZ5IHRoZSBoYXNoIGFsZ29yaXRobSBmb3Ig aXRzIHBhcnRpY3VsYXIgdXNhZ2UuDQoNClRoaXMgaXNuJ3QgYXMgYmFkIGFzIHlvdSBtaWdodCB0 aGluaywgaG93ZXZlciwgYmVjYXVzZSB0eXBpY2FsbHkgdGhlIGNvbnN1bWVyIG9mIHRoZSAia2lk IiBkb2Vzbid0IG5lZWQgdG8ga25vdyB0aGUgYWxnb3JpdGhtIGJlY2F1c2UgaXQgd29uJ3QgYmUg cmVwcm9kdWNpbmcgdGhlIGNvbXB1dGF0aW9uLiAgSXQganVzdCByZWxpZXMgb24gdGhlIGZhY3Qg dGhhdCBhIHVuaXF1ZSBrZXkgSUQgdmFsdWUgd2FzIGdlbmVyYXRlZCBmb3IgdGhlIGtleSBhbmQg Y29tcGFyZXMgImtpZCIgdmFsdWVzIGFzIG9wYXF1ZSBzdHJpbmdzIHRvIGZpbmQgdGhlIGFwcHJv cHJpYXRlIGtleS4gIEluIHRoaXMgdXNhZ2UsIHRoZSBwcm9kdWNlciBvZiB0aGUga2V5IGlzIHRo ZSBvbmx5IHBhcnR5IHRoYXQgbmVlZHMgdG8ga25vdyB0aGUgaGFzaCBhbGdvcml0aG0gdGhhdCBp dCBpcyB1c2luZy4gIEkgaG9wZSB0aGlzIGhlbHBzLg0KDQo+IEFkZGl0aW9uYWxseSwgaW4gU2Vj dGlvbiA0LCDigJxKU09OIGFuZCBVbmljb2RlIENvbnNpZGVyYXRpb25z4oCdIHNvbWUg4oCcc2hv dWxk4oCdcyBhcmUgdXNlZCwgYnV0IEnigJltIG5vdCByZWFkaW5nIHRoZW0gYXMgU0hPVUxEcy4g IFNob3VsZCB0aGV5IGJlIFNIT1VMRHM/ICBGb3IgZXhhbXBsZSwgdGhlIHN0YXJ0IG9mIHRoZSB0 aGlyZCBwYXJhZ3JhcGggaW4gdGhhdCBzZWN0aW9uOiDigJxpZiBuZXcgSldLIG1lbWJlcnMgYXJl IGRlZmluZWQgdGhhdCB1c2Ugbm9uLUFTQ0lJIG1lbWJlciBuYW1lcywgdGhlaXIgZGVmaW5pdGlv bnMgc2hvdWxkIHNwZWNpZnkgdGhlIGV4YWN0IFVuaWNvZGUgY29kZSBwb2ludCBzZXF1ZW5jZXMg dXNlZCB0byByZXByZXNlbnQgdGhlbS7igJ0gIEl04oCZcyBub3QgY2xlYXIgdG8gbWUgd2hldGhl ciB0aGlzIGlzIGEgc3Ryb25nIHN0YXRlbWVudCBvciBqdXN0IGEgcmVjb21tZW5kYXRpb24gLSBp dCBzZWVtcyB0aGF0IHRoaXMgZHJhZnQgY291bGQgaGVscCB0aGUgZnV0dXJlIGJ5IG1ha2luZyBz dHJvbmdlciBzdGF0ZW1lbnRzIHRvIGVuY291cmFnZSBmdXR1cmUgaW50ZXJvcGVyYWJpbGl0eS4N Cg0KRm9yIHRoZSBvdGhlciBKT1NFIHNwZWNpZmljYXRpb25zLCBvdXIgY2hhaXIgSmltIFNjaGFh ZCB0b29rIHRoZSBwb3NpdGlvbiB0aGF0IFJGQyAyMTE5IGtleXdvcmRzIHNob3VsZCBiZSByZXNl cnZlZCBmb3IgdGVzdGFibGUgcHJvdG9jb2wgYmVoYXZpb3JzIGFuZCB0aGF0IG90aGVyIHVzZXMg b2YgdGhlIEVuZ2xpc2ggd29yZCAic2hvdWxkIiBzaG91bGQgbm90IHVzZSAiU0hPVUxEIi4gIFRo ZSBhdXRob3JzIGZvbGxvd2VkIHRoYXQgY29udmVudGlvbiBpbiB0aGlzIGRvY3VtZW50LiAgSSBk byB1bmRlcnN0YW5kIHRoYXQgb3RoZXIgYXV0aG9ycyBhbmQgd29ya2luZyBncm91cHMgaGF2ZSB0 YWtlbiBkaWZmZXJlbnQgcG9zaXRpb25zIGluIHRoaXMgcmVnYXJkLiAgSWYgdGhlcmUgYXJlIHBh cnRpY3VsYXIgdXNlcyB0aGF0IHlvdSBzdGlsbCBmZWVsIHNob3VsZCBiZSBjaGFuZ2VkIHRvIHVz ZSBSRkMgMjExOSBrZXl3b3JkcywgcGxlYXNlIGNhbGwgdGhlbSBvdXQuDQoNCj4gS2luZCByZWdh cmRzLA0KPiBBZGFtDQoNCgkJCQlUaGFua3MgYWdhaW4hDQoJCQkJLS0gTWlrZQ0KDQo= From nobody Thu Jun 11 15:35:40 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFE11B33BE; Thu, 11 Jun 2015 15:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LUzyl0Oo34S; Thu, 11 Jun 2015 15:35:34 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40D31B33A7; Thu, 11 Jun 2015 15:35:34 -0700 (PDT) Received: from hebrews (unknown [50.109.226.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 8B8F938FC8; Thu, 11 Jun 2015 15:35:33 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , "'Adam W. Montville'" , "'The IESG'" , , References: In-Reply-To: Date: Thu, 11 Jun 2015 15:35:40 -0700 Message-ID: <003d01d0a496$f2ee7d70$d8cb7850$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQH/CRWIcZSXbJbM2kM+qRSrEj4cCAIc57yonTo0IvA= Content-Language: en-us Archived-At: Cc: jose@ietf.org Subject: Re: [secdir] sector review of draft-ietf-jose-jwk-thumbprint-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 22:35:36 -0000 > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Thursday, June 11, 2015 2:25 PM > To: Adam W. Montville; The IESG; secdir@ietf.org; draft-ietf-jose-jwk- > thumbprint.all@ietf.org > Cc: jose@ietf.org > Subject: RE: sector review of draft-ietf-jose-jwk-thumbprint-05 >=20 > Hi Adam, >=20 > Thanks for the secdir review. >=20 > > From: Adam W. Montville [mailto:adam.w.montville@gmail.com] > > Sent: Monday, June 08, 2015 8:46 AM > > To: The IESG; secdir@ietf.org; = draft-ietf-jose-jwk-thumbprint.all@ietf.org > > Subject: sector review of draft-ietf-jose-jwk-thumbprint-05 >=20 > > Hi, >=20 > > I have reviewed this document as part of the security directorate's = ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area = directors. > Document editors and WG chairs should treat these comments just like = any > other last call comments. > > > > I believe the document is ready with (potential) issues. The = =E2=80=9Cwith issues=E2=80=9D might > be due to ignorance on my part. The draft does a very good job of = explaining > the canonical form of a JSON Web Key that can be used for establishing = a > thumbprint under varying circumstances, complete with what I found to = be > helpful examples. > > > > The primary issue I have is that it=E2=80=99s unclear how relying = parties are going to > know which hash algorithm has been used. The examples use SHA-256, = but I=E2=80=99m > not seeing where SHA-256 might be specified as a MUST or even a = SHOULD. > Moreover, the example output ultimately shows only the Base-64 = encoding of > the resulting hash, which says nothing about the algorithm used to = identify a > key. >=20 > Earlier drafts had included fields whose names were intended to = communicate > the information about the hash function used - see the "jkt" field = definitions in > http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-01#section-4 = - but > several working group reviewers suggested that these fields were = unnecessary > and that the typical usage would be as "kid" (key ID) field values. = With that > removal, it falls onto the application to specify the hash algorithm = for its > particular usage. >=20 > This isn't as bad as you might think, however, because typically the = consumer of > the "kid" doesn't need to know the algorithm because it won't be = reproducing > the computation. It just relies on the fact that a unique key ID = value was > generated for the key and compares "kid" values as opaque strings to = find the > appropriate key. In this usage, the producer of the key is the only = party that > needs to know the hash algorithm that it is using. I hope this helps. >=20 > > Additionally, in Section 4, =E2=80=9CJSON and Unicode = Considerations=E2=80=9D some =E2=80=9Cshould=E2=80=9Ds > are used, but I=E2=80=99m not reading them as SHOULDs. Should they be = SHOULDs? For > example, the start of the third paragraph in that section: =E2=80=9Cif = new JWK members > are defined that use non-ASCII member names, their definitions should = specify > the exact Unicode code point sequences used to represent = them.=E2=80=9D It=E2=80=99s not clear > to me whether this is a strong statement or just a recommendation - it = seems > that this draft could help the future by making stronger statements to = encourage > future interoperability. >=20 > For the other JOSE specifications, our chair Jim Schaad took the = position that > RFC 2119 keywords should be reserved for testable protocol behaviors = and that > other uses of the English word "should" should not use "SHOULD". The = authors > followed that convention in this document. I do understand that other = authors > and working groups have taken different positions in this regard. If = there are > particular uses that you still feel should be changed to use RFC 2119 = keywords, > please call them out. If we really wanted to make sure that the recommendation was followed, = then it would make sense to adjust the IANA reviewers instructions for = the registry. Putting a SHOULD or a MUST in this document would not = have any effect since it does not define a protocol and might not be = seen by anybody defining a new header field. Jim >=20 > > Kind regards, > > Adam >=20 > Thanks again! > -- Mike From nobody Thu Jun 11 15:49:07 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B111B33FC; Thu, 11 Jun 2015 15:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40xYul3oEOo8; Thu, 11 Jun 2015 15:48:59 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0138.outbound.protection.outlook.com [65.55.169.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 561A81B2CDE; Thu, 11 Jun 2015 15:48:59 -0700 (PDT) Received: from BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) by BY2PR03MB191.namprd03.prod.outlook.com (10.242.36.143) with Microsoft SMTP Server (TLS) id 15.1.195.6; Thu, 11 Jun 2015 22:48:57 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.195.6; Thu, 11 Jun 2015 22:48:56 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0195.005; Thu, 11 Jun 2015 22:48:56 +0000 From: Mike Jones To: Jim Schaad , "'Adam W. Montville'" , 'The IESG' , "secdir@ietf.org" , "draft-ietf-jose-jwk-thumbprint.all@ietf.org" Thread-Topic: sector review of draft-ietf-jose-jwk-thumbprint-05 Thread-Index: AQHQogJgaphBjlti2Uu758g0GQEF3p2nztYwgAAbCACAAAIooA== Date: Thu, 11 Jun 2015 22:48:56 +0000 Message-ID: References: <003d01d0a496$f2ee7d70$d8cb7850$@augustcellars.com> In-Reply-To: <003d01d0a496$f2ee7d70$d8cb7850$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e0:ee43::6] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:AYEqWEKMsIR735iijZguQIO/3fBy0wOAK1Wvno6YzDay4Xff2MRu8ip1s+Zd/ab5bZMZRWiBG652pwE2oKtVNfZZA56WlAjyvGOBmJEzzLnlADZtVzGB3h8b55Fx+oWutHYDYTYkp9kIrezQc1A9UA==; 24:nY8eTOe6E5sFYdz1y7KsOwHjf6waqGLTF3nw9C1Xh0AfD8QshthpyWd0B+eSLP165W3u5GcPXzkFGX+U3FY9Zc1znuT6BDNXPCdJ4Z71HBs=; 20:ofKEWT6Z78h1GPdCFV8N1zisBgkcLud2rCrvTqMmfwH02skL6hmiZ5XIKAMLxuCFNjDwxhdQnqsZ50rpBC/kNQ== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB191; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0604AFA86B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(71364002)(43784003)(51704005)(13464003)(377454003)(2900100001)(76576001)(40100003)(189998001)(87936001)(2950100001)(5001960100002)(74316001)(76176999)(50986999)(54356999)(86612001)(15975445007)(77096005)(102836002)(86362001)(19580405001)(19580395003)(99286002)(2201001)(5002640100001)(122556002)(92566002)(106116001)(230783001)(2501003)(33656002)(2656002)(77156002)(5001770100001)(5003600100002)(62966003)(46102003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2015 22:48:56.7117 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB191; 2:a7aVzZ3VDfZyoHyi7SYhdyrVDRO+BE1TCLexbpPHDN1Zc6nXnYO1wgd6vWp0sip0; 3:KPLb0++UwaXKzdZYhQmsmhbwT/+BQB1ZRwGfJs1tOxVyJjnUR2sxAj3H4TpAoCSIVf7updHjauakkuTMUPlmbdhvPxeS7mAtCy4WEC5l3VJ6Xn7GOllSs74N5L58gqEReI7PHoKrmqLNR8oMzrN2rw==; 23:zowL651Lhm2Z0rnh87EkAD9dzCOOkrPz51N2i9rwLom8JMYaR07rJBkptxOKU9ixt9Il0ZVHj7ccY/LTmxdcmUq2OZRsyY3dB4qZfk1/YAw+jJwUp09yrs0n2Ermp462cTgGi8xEwYohIdYG+E0Vhb0GP3oFKL+yaWQ6ToK8Qdc3UGEsBbmtdy5pvCTeXwnX8r4S0kI8cyNbvlkC2veiVygIqE6I+6gzCnLGhwFdHfHfNGDJsRIwdqJbf802BIb8 X-OriginatorOrg: microsoft.com Archived-At: Cc: "jose@ietf.org" Subject: Re: [secdir] sector review of draft-ietf-jose-jwk-thumbprint-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 22:49:02 -0000 VGhlIHJlZ2lzdHJhdGlvbiBpbnN0cnVjdGlvbnMgZG9uJ3QgYXBwZWFyIHRvIGJlIHN0b3JlZCB3 aXRoIHRoZSByZWdpc3RyeSBhdCBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2pvc2Uv am9zZS54aHRtbC4gIFRoZSBjbG9zZXN0IHRoZXJlIGlzIHRoZXJlIGlzIHRoZSBSZWZlcmVuY2Ug ZmllbGQsIHdoaWNoIHNwZWNpZmllcyBbUkZDNzUxNV0sIHdoaWNoIEkgYXNzdW1lIGlzIGhvdyB0 aGUgZGVzaWduYXRlZCBleHBlcnRzIGFyZSBleHBlY3RlZCB0byByZXRyaWV2ZSB0aGUgaW5zdHJ1 Y3Rpb25zLg0KDQpEb2VzIGFueW9uZSBvbiB0aGUgdGhyZWFkIGtub3cgaWYgaXQncyBwb3NzaWJs ZSB0byBhZGQgYSBjb3B5IG9mIHRoZSByZWdpc3RyYXRpb24gaW5zdHJ1Y3Rpb25zIGluIHRoZSBy ZWdpc3RyeSBpdHNlbGY/ICBJZiBzbywgdGhlbiB3ZSdkIGhhdmUgYSBtZWNoYW5pc20gYnkgd2hp Y2ggd2UgY291bGQgdXBkYXRlIHRoZW0sIGFzIEppbSBzdWdnZXN0ZWQuDQoNCgkJCQktLSBNaWtl DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKaW0gU2NoYWFkIFttYWlsdG86 aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbV0gDQpTZW50OiBUaHVyc2RheSwgSnVuZSAxMSwgMjAxNSAz OjM2IFBNDQpUbzogTWlrZSBKb25lczsgJ0FkYW0gVy4gTW9udHZpbGxlJzsgJ1RoZSBJRVNHJzsg c2VjZGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLWpvc2UtandrLXRodW1icHJpbnQuYWxsQGlldGYu b3JnDQpDYzogam9zZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IHNlY3RvciByZXZpZXcgb2YgZHJh ZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnByaW50LTA1DQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IE1pa2UgSm9uZXMgW21haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDExLCAyMDE1IDI6MjUgUE0NCj4gVG86 IEFkYW0gVy4gTW9udHZpbGxlOyBUaGUgSUVTRzsgc2VjZGlyQGlldGYub3JnOyBkcmFmdC1pZXRm LWpvc2UtandrLSANCj4gdGh1bWJwcmludC5hbGxAaWV0Zi5vcmcNCj4gQ2M6IGpvc2VAaWV0Zi5v cmcNCj4gU3ViamVjdDogUkU6IHNlY3RvciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1qb3NlLWp3ay10 aHVtYnByaW50LTA1DQo+IA0KPiBIaSBBZGFtLA0KPiANCj4gVGhhbmtzIGZvciB0aGUgc2VjZGly IHJldmlldy4NCj4gDQo+ID4gRnJvbTogQWRhbSBXLiBNb250dmlsbGUgW21haWx0bzphZGFtLncu bW9udHZpbGxlQGdtYWlsLmNvbV0NCj4gPiBTZW50OiBNb25kYXksIEp1bmUgMDgsIDIwMTUgODo0 NiBBTQ0KPiA+IFRvOiBUaGUgSUVTRzsgc2VjZGlyQGlldGYub3JnOyANCj4gPiBkcmFmdC1pZXRm LWpvc2UtandrLXRodW1icHJpbnQuYWxsQGlldGYub3JnDQo+ID4gU3ViamVjdDogc2VjdG9yIHJl dmlldyBvZiBkcmFmdC1pZXRmLWpvc2UtandrLXRodW1icHJpbnQtMDUNCj4gDQo+ID4gSGksDQo+ IA0KPiA+IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3Vy aXR5IGRpcmVjdG9yYXRlJ3MgDQo+ID4gb25nb2luZw0KPiBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJ RVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuIFRoZXNlIA0KPiBjb21t ZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJp dHkgYXJlYSBkaXJlY3RvcnMuDQo+IERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91 bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIA0KPiBhbnkgb3RoZXIgbGFzdCBjYWxs IGNvbW1lbnRzLg0KPiA+DQo+ID4gSSBiZWxpZXZlIHRoZSBkb2N1bWVudCBpcyByZWFkeSB3aXRo IChwb3RlbnRpYWwpIGlzc3Vlcy4gIFRoZSDigJx3aXRoIA0KPiA+IGlzc3Vlc+KAnSBtaWdodA0K PiBiZSBkdWUgdG8gaWdub3JhbmNlIG9uIG15IHBhcnQuICBUaGUgZHJhZnQgZG9lcyBhIHZlcnkg Z29vZCBqb2Igb2YgDQo+IGV4cGxhaW5pbmcgdGhlIGNhbm9uaWNhbCBmb3JtIG9mIGEgSlNPTiBX ZWIgS2V5IHRoYXQgY2FuIGJlIHVzZWQgZm9yIA0KPiBlc3RhYmxpc2hpbmcgYSB0aHVtYnByaW50 IHVuZGVyIHZhcnlpbmcgY2lyY3Vtc3RhbmNlcywgY29tcGxldGUgd2l0aCANCj4gd2hhdCBJIGZv dW5kIHRvIGJlIGhlbHBmdWwgZXhhbXBsZXMuDQo+ID4NCj4gPiBUaGUgcHJpbWFyeSBpc3N1ZSBJ IGhhdmUgaXMgdGhhdCBpdOKAmXMgdW5jbGVhciBob3cgcmVseWluZyBwYXJ0aWVzIA0KPiA+IGFy ZSBnb2luZyB0bw0KPiBrbm93IHdoaWNoIGhhc2ggYWxnb3JpdGhtIGhhcyBiZWVuIHVzZWQuICBU aGUgZXhhbXBsZXMgdXNlIFNIQS0yNTYsIA0KPiBidXQgSeKAmW0gbm90IHNlZWluZyB3aGVyZSBT SEEtMjU2IG1pZ2h0IGJlIHNwZWNpZmllZCBhcyBhIE1VU1Qgb3IgZXZlbiBhIFNIT1VMRC4NCj4g TW9yZW92ZXIsIHRoZSBleGFtcGxlIG91dHB1dCB1bHRpbWF0ZWx5IHNob3dzIG9ubHkgdGhlIEJh c2UtNjQgDQo+IGVuY29kaW5nIG9mIHRoZSByZXN1bHRpbmcgaGFzaCwgd2hpY2ggc2F5cyBub3Ro aW5nIGFib3V0IHRoZSBhbGdvcml0aG0gDQo+IHVzZWQgdG8gaWRlbnRpZnkgYSBrZXkuDQo+IA0K PiBFYXJsaWVyIGRyYWZ0cyBoYWQgaW5jbHVkZWQgZmllbGRzIHdob3NlIG5hbWVzIHdlcmUgaW50 ZW5kZWQgdG8gDQo+IGNvbW11bmljYXRlIHRoZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgaGFzaCBm dW5jdGlvbiB1c2VkIC0gc2VlIHRoZSANCj4gImprdCIgZmllbGQgZGVmaW5pdGlvbnMgaW4NCj4g aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnByaW50 LTAxI3NlY3Rpb24tNCANCj4gLSBidXQgc2V2ZXJhbCB3b3JraW5nIGdyb3VwIHJldmlld2VycyBz dWdnZXN0ZWQgdGhhdCB0aGVzZSBmaWVsZHMgd2VyZSANCj4gdW5uZWNlc3NhcnkgYW5kIHRoYXQg dGhlIHR5cGljYWwgdXNhZ2Ugd291bGQgYmUgYXMgImtpZCIgKGtleSBJRCkgDQo+IGZpZWxkIHZh bHVlcy4gIFdpdGggdGhhdCByZW1vdmFsLCBpdCBmYWxscyBvbnRvIHRoZSBhcHBsaWNhdGlvbiB0 byANCj4gc3BlY2lmeSB0aGUgaGFzaCBhbGdvcml0aG0gZm9yIGl0cyBwYXJ0aWN1bGFyIHVzYWdl Lg0KPiANCj4gVGhpcyBpc24ndCBhcyBiYWQgYXMgeW91IG1pZ2h0IHRoaW5rLCBob3dldmVyLCBi ZWNhdXNlIHR5cGljYWxseSB0aGUgDQo+IGNvbnN1bWVyIG9mIHRoZSAia2lkIiBkb2Vzbid0IG5l ZWQgdG8ga25vdyB0aGUgYWxnb3JpdGhtIGJlY2F1c2UgaXQgDQo+IHdvbid0IGJlIHJlcHJvZHVj aW5nIHRoZSBjb21wdXRhdGlvbi4gIEl0IGp1c3QgcmVsaWVzIG9uIHRoZSBmYWN0IHRoYXQgDQo+ IGEgdW5pcXVlIGtleSBJRCB2YWx1ZSB3YXMgZ2VuZXJhdGVkIGZvciB0aGUga2V5IGFuZCBjb21w YXJlcyAia2lkIiANCj4gdmFsdWVzIGFzIG9wYXF1ZSBzdHJpbmdzIHRvIGZpbmQgdGhlIGFwcHJv cHJpYXRlIGtleS4gIEluIHRoaXMgdXNhZ2UsIA0KPiB0aGUgcHJvZHVjZXIgb2YgdGhlIGtleSBp cyB0aGUgb25seSBwYXJ0eSB0aGF0IG5lZWRzIHRvIGtub3cgdGhlIGhhc2ggYWxnb3JpdGhtIHRo YXQgaXQgaXMgdXNpbmcuICBJIGhvcGUgdGhpcyBoZWxwcy4NCj4gDQo+ID4gQWRkaXRpb25hbGx5 LCBpbiBTZWN0aW9uIDQsIOKAnEpTT04gYW5kIFVuaWNvZGUgQ29uc2lkZXJhdGlvbnPigJ0gc29t ZSANCj4gPiDigJxzaG91bGTigJ1zDQo+IGFyZSB1c2VkLCBidXQgSeKAmW0gbm90IHJlYWRpbmcg dGhlbSBhcyBTSE9VTERzLiAgU2hvdWxkIHRoZXkgYmUgDQo+IFNIT1VMRHM/ICBGb3IgZXhhbXBs ZSwgdGhlIHN0YXJ0IG9mIHRoZSB0aGlyZCBwYXJhZ3JhcGggaW4gdGhhdCANCj4gc2VjdGlvbjog 4oCcaWYgbmV3IEpXSyBtZW1iZXJzIGFyZSBkZWZpbmVkIHRoYXQgdXNlIG5vbi1BU0NJSSBtZW1i ZXIgDQo+IG5hbWVzLCB0aGVpciBkZWZpbml0aW9ucyBzaG91bGQgc3BlY2lmeSB0aGUgZXhhY3Qg VW5pY29kZSBjb2RlIHBvaW50IA0KPiBzZXF1ZW5jZXMgdXNlZCB0byByZXByZXNlbnQgdGhlbS7i gJ0gIEl04oCZcyBub3QgY2xlYXIgdG8gbWUgd2hldGhlciB0aGlzIA0KPiBpcyBhIHN0cm9uZyBz dGF0ZW1lbnQgb3IganVzdCBhIHJlY29tbWVuZGF0aW9uIC0gaXQgc2VlbXMgdGhhdCB0aGlzIA0K PiBkcmFmdCBjb3VsZCBoZWxwIHRoZSBmdXR1cmUgYnkgbWFraW5nIHN0cm9uZ2VyIHN0YXRlbWVu dHMgdG8gZW5jb3VyYWdlIGZ1dHVyZSBpbnRlcm9wZXJhYmlsaXR5Lg0KPiANCj4gRm9yIHRoZSBv dGhlciBKT1NFIHNwZWNpZmljYXRpb25zLCBvdXIgY2hhaXIgSmltIFNjaGFhZCB0b29rIHRoZSAN Cj4gcG9zaXRpb24gdGhhdCBSRkMgMjExOSBrZXl3b3JkcyBzaG91bGQgYmUgcmVzZXJ2ZWQgZm9y IHRlc3RhYmxlIA0KPiBwcm90b2NvbCBiZWhhdmlvcnMgYW5kIHRoYXQgb3RoZXIgdXNlcyBvZiB0 aGUgRW5nbGlzaCB3b3JkICJzaG91bGQiIA0KPiBzaG91bGQgbm90IHVzZSAiU0hPVUxEIi4gIFRo ZSBhdXRob3JzIGZvbGxvd2VkIHRoYXQgY29udmVudGlvbiBpbiB0aGlzIA0KPiBkb2N1bWVudC4g IEkgZG8gdW5kZXJzdGFuZCB0aGF0IG90aGVyIGF1dGhvcnMgYW5kIHdvcmtpbmcgZ3JvdXBzIGhh dmUgDQo+IHRha2VuIGRpZmZlcmVudCBwb3NpdGlvbnMgaW4gdGhpcyByZWdhcmQuICBJZiB0aGVy ZSBhcmUgcGFydGljdWxhciANCj4gdXNlcyB0aGF0IHlvdSBzdGlsbCBmZWVsIHNob3VsZCBiZSBj aGFuZ2VkIHRvIHVzZSBSRkMgMjExOSBrZXl3b3JkcywgcGxlYXNlIGNhbGwgdGhlbSBvdXQuDQoN CklmIHdlIHJlYWxseSB3YW50ZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIHJlY29tbWVuZGF0aW9u IHdhcyBmb2xsb3dlZCwgdGhlbiBpdCB3b3VsZCBtYWtlIHNlbnNlIHRvIGFkanVzdCB0aGUgSUFO QSByZXZpZXdlcnMgaW5zdHJ1Y3Rpb25zIGZvciB0aGUgcmVnaXN0cnkuICBQdXR0aW5nIGEgU0hP VUxEIG9yIGEgTVVTVCBpbiB0aGlzIGRvY3VtZW50IHdvdWxkIG5vdCBoYXZlIGFueSBlZmZlY3Qg c2luY2UgaXQgZG9lcyBub3QgZGVmaW5lIGEgcHJvdG9jb2wgYW5kIG1pZ2h0IG5vdCBiZSBzZWVu IGJ5IGFueWJvZHkgZGVmaW5pbmcgYSBuZXcgaGVhZGVyIGZpZWxkLg0KDQpKaW0NCg0KPiANCj4g PiBLaW5kIHJlZ2FyZHMsDQo+ID4gQWRhbQ0KPiANCj4gCQkJCVRoYW5rcyBhZ2FpbiENCj4gCQkJ CS0tIE1pa2UNCg0KDQo= From nobody Thu Jun 11 17:00:06 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064B11B34B8; Thu, 11 Jun 2015 17:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JspVYVCzYINV; Thu, 11 Jun 2015 17:00:01 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E271B34BB; Thu, 11 Jun 2015 17:00:00 -0700 (PDT) Received: from hebrews (unknown [50.109.226.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 4AE7438EF3; Thu, 11 Jun 2015 16:59:59 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , "'Adam W. Montville'" , "'The IESG'" , , References: <003d01d0a496$f2ee7d70$d8cb7850$@augustcellars.com> In-Reply-To: Date: Thu, 11 Jun 2015 17:00:06 -0700 Message-ID: <004801d0a4a2$be5e1b40$3b1a51c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQH/CRWIcZSXbJbM2kM+qRSrEj4cCAIc57yoAlPx0JQCobgd4Z0Snnug Content-Language: en-us Archived-At: Cc: jose@ietf.org Subject: Re: [secdir] sector review of draft-ietf-jose-jwk-thumbprint-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 00:00:04 -0000 I would do this by including an IANA considerations section that states = you are updating the expert review instructions for a registry. They = will then include that in the list of references for the registry = itself. Jim > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Thursday, June 11, 2015 3:49 PM > To: Jim Schaad; 'Adam W. Montville'; 'The IESG'; secdir@ietf.org; = draft-ietf-jose- > jwk-thumbprint.all@ietf.org > Cc: jose@ietf.org > Subject: RE: sector review of draft-ietf-jose-jwk-thumbprint-05 >=20 > The registration instructions don't appear to be stored with the = registry at > http://www.iana.org/assignments/jose/jose.xhtml. The closest there is = there is > the Reference field, which specifies [RFC7515], which I assume is how = the > designated experts are expected to retrieve the instructions. >=20 > Does anyone on the thread know if it's possible to add a copy of the = registration > instructions in the registry itself? If so, then we'd have a = mechanism by which > we could update them, as Jim suggested. >=20 > -- Mike >=20 > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: Thursday, June 11, 2015 3:36 PM > To: Mike Jones; 'Adam W. Montville'; 'The IESG'; secdir@ietf.org; = draft-ietf-jose- > jwk-thumbprint.all@ietf.org > Cc: jose@ietf.org > Subject: RE: sector review of draft-ietf-jose-jwk-thumbprint-05 >=20 >=20 >=20 > > -----Original Message----- > > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > > Sent: Thursday, June 11, 2015 2:25 PM > > To: Adam W. Montville; The IESG; secdir@ietf.org; = draft-ietf-jose-jwk- > > thumbprint.all@ietf.org > > Cc: jose@ietf.org > > Subject: RE: sector review of draft-ietf-jose-jwk-thumbprint-05 > > > > Hi Adam, > > > > Thanks for the secdir review. > > > > > From: Adam W. Montville [mailto:adam.w.montville@gmail.com] > > > Sent: Monday, June 08, 2015 8:46 AM > > > To: The IESG; secdir@ietf.org; > > > draft-ietf-jose-jwk-thumbprint.all@ietf.org > > > Subject: sector review of draft-ietf-jose-jwk-thumbprint-05 > > > > > Hi, > > > > > I have reviewed this document as part of the security = directorate's > > > ongoing > > effort to review all IETF documents being processed by the IESG. = These > > comments were written primarily for the benefit of the security area = directors. > > Document editors and WG chairs should treat these comments just like > > any other last call comments. > > > > > > I believe the document is ready with (potential) issues. The = =E2=80=9Cwith > > > issues=E2=80=9D might > > be due to ignorance on my part. The draft does a very good job of > > explaining the canonical form of a JSON Web Key that can be used for > > establishing a thumbprint under varying circumstances, complete with > > what I found to be helpful examples. > > > > > > The primary issue I have is that it=E2=80=99s unclear how relying = parties > > > are going to > > know which hash algorithm has been used. The examples use SHA-256, > > but I=E2=80=99m not seeing where SHA-256 might be specified as a = MUST or even a > SHOULD. > > Moreover, the example output ultimately shows only the Base-64 > > encoding of the resulting hash, which says nothing about the = algorithm > > used to identify a key. > > > > Earlier drafts had included fields whose names were intended to > > communicate the information about the hash function used - see the > > "jkt" field definitions in > > = http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-01#section-4 > > - but several working group reviewers suggested that these fields = were > > unnecessary and that the typical usage would be as "kid" (key ID) > > field values. With that removal, it falls onto the application to > > specify the hash algorithm for its particular usage. > > > > This isn't as bad as you might think, however, because typically the > > consumer of the "kid" doesn't need to know the algorithm because it > > won't be reproducing the computation. It just relies on the fact = that > > a unique key ID value was generated for the key and compares "kid" > > values as opaque strings to find the appropriate key. In this = usage, > > the producer of the key is the only party that needs to know the = hash > algorithm that it is using. I hope this helps. > > > > > Additionally, in Section 4, =E2=80=9CJSON and Unicode = Considerations=E2=80=9D some > > > =E2=80=9Cshould=E2=80=9Ds > > are used, but I=E2=80=99m not reading them as SHOULDs. Should they = be > > SHOULDs? For example, the start of the third paragraph in that > > section: =E2=80=9Cif new JWK members are defined that use non-ASCII = member > > names, their definitions should specify the exact Unicode code point > > sequences used to represent them.=E2=80=9D It=E2=80=99s not clear = to me whether this > > is a strong statement or just a recommendation - it seems that this > > draft could help the future by making stronger statements to = encourage future > interoperability. > > > > For the other JOSE specifications, our chair Jim Schaad took the > > position that RFC 2119 keywords should be reserved for testable > > protocol behaviors and that other uses of the English word "should" > > should not use "SHOULD". The authors followed that convention in = this > > document. I do understand that other authors and working groups = have > > taken different positions in this regard. If there are particular > > uses that you still feel should be changed to use RFC 2119 keywords, = please > call them out. >=20 > If we really wanted to make sure that the recommendation was followed, = then > it would make sense to adjust the IANA reviewers instructions for the = registry. > Putting a SHOULD or a MUST in this document would not have any effect = since it > does not define a protocol and might not be seen by anybody defining a = new > header field. >=20 > Jim >=20 > > > > > Kind regards, > > > Adam > > > > Thanks again! > > -- Mike >=20 From nobody Fri Jun 12 05:06:42 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E131A86E2; Fri, 12 Jun 2015 05:06:36 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m_fG45C26UL9; Fri, 12 Jun 2015 05:06:34 -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 1366C1A1EF6; Fri, 12 Jun 2015 05:06:34 -0700 (PDT) Received: by oigz2 with SMTP id z2so20519067oig.1; Fri, 12 Jun 2015 05:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=EjYunyZx2un6QeuN4WSDIxKvpsJepURMRS69uHppZW0=; b=uztRoMoTyI/iZ17RwibKqNGuOHD3e9sBdIgGwLagXfDPkIKOIO8RUTQSqBGHjGEGrM Ed5LdqddcWIZ1MCzb2PZFPQFD8zt6hhLA+taculsNoZHxdqEm6FfNG4Ukxqfusiw1Way 9NaX7w0gLNYfutoqtnFp9JSWb/X7VulPnIqgag4vlCyDymXGVDvMsnsU8zwPdwg8DGcn ZEw7Y5uNtnDLp5DS2xtttCSG/Iwa8le7HiqdakfkDyE4VtsvDvtheU1eZDHklaCWqwwT oKRatYvIIh6FdSMGQIRFTjrb/5fBt5e2CiQvDWjfAATonloNitRqnA5U35YDV/CNw7Aj c2ug== X-Received: by 10.60.175.72 with SMTP id by8mr12147137oec.35.1434110793388; Fri, 12 Jun 2015 05:06:33 -0700 (PDT) Received: from adams-mac-mini.attlocal.net ([2602:306:3406:4830:7109:e5a9:442:72ed]) by mx.google.com with ESMTPSA id h195sm2484458oig.1.2015.06.12.05.06.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jun 2015 05:06:32 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_DFB11325-054C-4A8B-97FC-DD6F100E5B08" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: "Adam W. Montville" In-Reply-To: Date: Fri, 12 Jun 2015 07:06:30 -0500 Message-Id: <4CA0A65D-E5FD-408C-A6B9-6ECB12A81B7C@gmail.com> References: To: Mike Jones X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "draft-ietf-jose-jwk-thumbprint.all@ietf.org" , The IESG , "jose@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] sector review of draft-ietf-jose-jwk-thumbprint-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 12:06:36 -0000 --Apple-Mail=_DFB11325-054C-4A8B-97FC-DD6F100E5B08 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 11, 2015, at 4:25 PM, Mike Jones = wrote: >=20 > Hi Adam, >=20 > Thanks for the secdir review. >=20 >> From: Adam W. Montville [mailto:adam.w.montville@gmail.com] >> Sent: Monday, June 08, 2015 8:46 AM >> To: The IESG; secdir@ietf.org; = draft-ietf-jose-jwk-thumbprint.all@ietf.org >> Subject: sector review of draft-ietf-jose-jwk-thumbprint-05 >=20 >> Hi, >=20 >> I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >>=20 >> I believe the document is ready with (potential) issues. The =E2=80=9C= with issues=E2=80=9D might be due to ignorance on my part. The draft = does a very good job of explaining the canonical form of a JSON Web Key = that can be used for establishing a thumbprint under varying = circumstances, complete with what I found to be helpful examples. >>=20 >> The primary issue I have is that it=E2=80=99s unclear how relying = parties are going to know which hash algorithm has been used. The = examples use SHA-256, but I=E2=80=99m not seeing where SHA-256 might be = specified as a MUST or even a SHOULD. Moreover, the example output = ultimately shows only the Base-64 encoding of the resulting hash, which = says nothing about the algorithm used to identify a key. >=20 > Earlier drafts had included fields whose names were intended to = communicate the information about the hash function used - see the "jkt" = field definitions in = http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-01#section-4 = = - but several working group reviewers suggested that these fields were = unnecessary and that the typical usage would be as "kid" (key ID) field = values. With that removal, it falls onto the application to specify the = hash algorithm for its particular usage. >=20 > This isn't as bad as you might think, however, because typically the = consumer of the "kid" doesn't need to know the algorithm because it = won't be reproducing the computation. It just relies on the fact that a = unique key ID value was generated for the key and compares "kid" values = as opaque strings to find the appropriate key. In this usage, the = producer of the key is the only party that needs to know the hash = algorithm that it is using. I hope this helps. Yes, this does help, thank you. It seems like something that could be = easily added to the draft to explain why the generating algorithm = needn=E2=80=99t be disclosed so that slow folk like myself get the = picture straight away. >=20 >> Additionally, in Section 4, =E2=80=9CJSON and Unicode = Considerations=E2=80=9D some =E2=80=9Cshould=E2=80=9Ds are used, but = I=E2=80=99m not reading them as SHOULDs. Should they be SHOULDs? For = example, the start of the third paragraph in that section: =E2=80=9Cif = new JWK members are defined that use non-ASCII member names, their = definitions should specify the exact Unicode code point sequences used = to represent them.=E2=80=9D It=E2=80=99s not clear to me whether this = is a strong statement or just a recommendation - it seems that this = draft could help the future by making stronger statements to encourage = future interoperability. >=20 > For the other JOSE specifications, our chair Jim Schaad took the = position that RFC 2119 keywords should be reserved for testable protocol = behaviors and that other uses of the English word "should" should not = use "SHOULD". The authors followed that convention in this document. I = do understand that other authors and working groups have taken different = positions in this regard. If there are particular uses that you still = feel should be changed to use RFC 2119 keywords, please call them out. This is all good, too. I was simply pointing out that there are = =E2=80=9Cshould=E2=80=9Ds around that may need to be considered as = =E2=80=9CSHOULD=E2=80=9Ds. I also see Jim=E2=80=99s (and others=E2=80=99) = subsequent notes on the subject, so this is good from my perspective. >=20 >> Kind regards, >> Adam >=20 > Thanks again! > -- Mike --Apple-Mail=_DFB11325-054C-4A8B-97FC-DD6F100E5B08 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 11, 2015, at 4:25 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Hi Adam,

Thanks for the secdir review.

From: Adam W. Montville = [mailto:adam.w.montville@gmail.com]
Sent: = Monday, June 08, 2015 8:46 AM
To: The IESG; secdir@ietf.org; draft-ietf-jose-jwk-thumbprint.all@ietf.org
Subject: sector review of = draft-ietf-jose-jwk-thumbprint-05

Hi,

I have reviewed this document as part of the security = directorate's ongoing effort to review all IETF documents being = processed by the IESG. These comments were written primarily for the = benefit of the security area directors. Document editors and WG chairs = should treat these comments just like any other last call comments.

I believe the document is ready with = (potential) issues.  The =E2=80=9Cwith issues=E2=80=9D might be due = to ignorance on my part.  The draft does a very good job of = explaining the canonical form of a JSON Web Key that can be used for = establishing a thumbprint under varying circumstances, complete with = what I found to be helpful examples.

The = primary issue I have is that it=E2=80=99s unclear how relying parties = are going to know which hash algorithm has been used.  The examples = use SHA-256, but I=E2=80=99m not seeing where SHA-256 might be specified = as a MUST or even a SHOULD.  Moreover, the example output = ultimately shows only the Base-64 encoding of the resulting hash, which = says nothing about the algorithm used to identify a key.

Earlier drafts had = included fields whose names were intended to communicate the information = about the hash function used - see the "jkt" field definitions in http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-01#se= ction-4 - but several working group = reviewers suggested that these fields were unnecessary and that the = typical usage would be as "kid" (key ID) field values.  With that = removal, it falls onto the application to specify the hash algorithm for = its particular usage.

This isn't as bad as you = might think, however, because typically the consumer of the "kid" = doesn't need to know the algorithm because it won't be reproducing the = computation.  It just relies on the fact that a unique key ID value = was generated for the key and compares "kid" values as opaque strings to = find the appropriate key.  In this usage, the producer of the key = is the only party that needs to know the hash algorithm that it is = using.  I hope this helps.

Yes, this does help, thank you.  It seems = like something that could be easily added to the draft to explain why = the generating algorithm needn=E2=80=99t be disclosed so that slow folk = like myself get the picture straight away.



Additionally, in Section 4, =E2=80=9CJSON and Unicode = Considerations=E2=80=9D some =E2=80=9Cshould=E2=80=9Ds are used, but = I=E2=80=99m not reading them as SHOULDs. Should they be SHOULDs? =  For example, the start of the third paragraph in that section: = =E2=80=9Cif new JWK members are defined that use non-ASCII member names, = their definitions should specify the exact Unicode code point sequences = used to represent them.=E2=80=9D  It=E2=80=99s not clear to me = whether this is a strong statement or just a recommendation - it seems = that this draft could help the future by making stronger statements to = encourage future interoperability.

For the other JOSE specifications, our chair Jim = Schaad took the position that RFC 2119 keywords should be reserved for = testable protocol behaviors and that other uses of the English word = "should" should not use "SHOULD".  The authors followed that = convention in this document.  I do understand that other authors = and working groups have taken different positions in this regard. =  If there are particular uses that you still feel should be changed = to use RFC 2119 keywords, please call them out.

This is all = good, too.  I was simply pointing out that there are =E2=80=9Cshould=E2= =80=9Ds around that may need to be considered as =E2=80=9CSHOULD=E2=80=9Ds= . I also see Jim=E2=80=99s (and others=E2=80=99) subsequent notes on the = subject, so this is good from my perspective.


Kind regards,
Adam

= = = Thanks again!
= = = = -- = Mike

= --Apple-Mail=_DFB11325-054C-4A8B-97FC-DD6F100E5B08-- From nobody Fri Jun 12 09:11:51 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EDB1A8971; Wed, 10 Jun 2015 09:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCSF4mca8rAc; Wed, 10 Jun 2015 09:30:42 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 533DA1A8968; Wed, 10 Jun 2015 09:30:42 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5AGUX4M074752 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 Jun 2015 11:30:34 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <55786629.6060705@nostrum.com> Date: Wed, 10 Jun 2015 11:30:33 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Magnus Westerlund , Chris Inacio , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-rtcweb-rtp-usage-23@tools.ietf.org" , "rtcweb@ietf.org" References: <24C0D45F-DBF0-43A4-A2D6-B086F7EC368F@cert.org> <55785CA7.4090005@ericsson.com> In-Reply-To: <55785CA7.4090005@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Fri, 12 Jun 2015 09:11:48 -0700 Subject: Re: [secdir] [rtcweb] sector review of draft-ietf-rtcweb-rtp-usage-23 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 16:30:43 -0000 On 6/10/15 10:49, Magnus Westerlund wrote: >> page 6: >> >> “This specification requires the usage of a single CNAME when sending >> RTP Packet Streams…” should the “require” be “REQUIRE”? > > This is intended as an informational reference, thus I propose to > change this to "mandates" thus avoiding the RFC2119 terms. RFC 2119 doesn't remove the words "require", "must", "should", "may" and "recommend" from the English language. If all you mean is the ordinary word "require," (rather than the 2119 term "REQUIRE"), then "require" is just fine. /a From nobody Fri Jun 12 09:11:52 2015 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E941A1A7E; Fri, 12 Jun 2015 08:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1434123952; bh=zvbx8Zc4k0FMalqaZD/RDDvP4xUSV3UTT0X2nMYErtU=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=liu1sj+H/qsc9/IDZZCXlmUncmFxuj4bGpuZoepDEQIw/lNGda5n1UjQs8WyOL6Uv EAcw/ntj+sFy5iGT0sfPwIxV5/chD8RnFioizlajJ1p98ecaDPM91VqzE0G3Kr+dVG 0rQnl3IptALBd9AkZKttgg69ibPZJaWzcW+w1sHU= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775011A1A82; Fri, 12 Jun 2015 08:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVbcMiGqmlOz; Fri, 12 Jun 2015 08:45:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7691B1A1AA9; Fri, 12 Jun 2015 08:45:30 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150612154530.7904.69080.idtracker@ietfa.amsl.com> Date: Fri, 12 Jun 2015 08:45:30 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 12 Jun 2015 09:11:48 -0700 Subject: [secdir] [new-work] WG Review: Javascript Object Notation Update (jsonbis) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 15:45:52 -0000 A new IETF working group has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22. Javascript Object Notation Update (jsonbis) ------------------------------------------------ Current Status: Proposed WG Chairs: Matthew Miller Assigned Area Director: Barry Leiba Mailing list Address: json@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/json Archive: https://www.ietf.org/mail-archive/web/json/ Charter: Javascript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard, and is published in both ECMA-404 and RFC 7159. First published over 10 years ago, JSON has come into nearly ubiquitous use, often the first choice for data interchange over other forms -- especially for applications that work over the World Wide Web. Given this ubiquity it makes sense to move JSON to Internet Standard. JSON is defined in two separate documents from two different bodies. ECMA-404, published by Ecma International, focuses on the abstract syntax. RFC 7159, published by the IETF, focuses on the interoperability concerns when exchanging JSON over a network. The two documents agree on the structure of what JSON is. The JSON working group will have as its only task the minor revision of RFC 7159 to bring it to Internet Standard, and fully acknowledge the syntax definition in ECMA-404. The work is essentially a reclassification in place, with absolute minimal changes, though those changes will require publication of a new RFC. The working group will review errata and update the document as needed to incorporate those. The resulting RFC will be aligned with a corresponding publication by ECMA. The Working Group will work with the liaison managers to coordinate with Ecma International TC39 on the editing of both documents. The responsible AD will work with the liaison managers to coordinate the approval process with Ecma International so that the versions of the document that are approved by each body are properly aligned with regard to syntax and shared semantics. Milestones: Oct 2015 - Request publication of JSON standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Jun 12 09:11:53 2015 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A96B1A1BA4; Fri, 12 Jun 2015 09:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1434124883; bh=5JawuC1RlGurlGYbtKqK0HrOKDnyKldV+SNUAjWzw1Q=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=fWM68neSWBrLbezc/lw891MUIUm3LL7sU4GNCqLd4lFWDpSLXsNue6zbqLCvhu4YI PkI5eEjSQQL4rqt/VCrGuYCLeUvhYFBLZPtKK+J4ruu4owdUo7Lz0/NBW020RlWsps t3fU6Tpl3ZbquvKJCbGa7Z1PrEum1i5V8rKNfi40= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B6E1A1B8A; Fri, 12 Jun 2015 09:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6] autolearn=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 YCS_1Tz1kmbl; Fri, 12 Jun 2015 09:01:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BD11A1B8D; Fri, 12 Jun 2015 09:01:15 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150612160115.14053.47696.idtracker@ietfa.amsl.com> Date: Fri, 12 Jun 2015 09:01:15 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 12 Jun 2015 09:11:49 -0700 Subject: [secdir] [new-work] WG Review: DDoS Open Threat Signaling (dots) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 16:01:23 -0000 A new IETF working group has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22. DDoS Open Threat Signaling (dots) ------------------------------------------------ Current Status: Proposed WG Chairs: Roman Danyliw Assigned Area Director: Kathleen Moriarty Mailing list Address: dots@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dots Archive: https://mailarchive.ietf.org/arch/search/?email_list=dots Charter: The aim of DDoS Open Threat Signaling (DOTS) is to develop a standards based approach for the realtime signaling of DDoS related telemetry and threat handling requests and data between elements concerned with DDoS attack detection, classification, traceback, and mitigation. The elements may be described as: * On-premise DDoS mitigation platforms * Service provider DDoS mitigation platforms * Other network elements and services with the ability to analyze and/or influence network traffic Elements may participate in DDoS detection, classification, traceback and mitigation individually or within the context of a larger collaborative system. These elements may be communicating inter-domain or intra-domain over links that may be congested by attack traffic resulting in potentially hostile conditions for any type of upstream signaling, in particular transport protocols that yield to congestion, and more generalized signaling and telemetry solutions. Robustness under these conditions is paramount while ensuring appropriate regard for authentication, authorization, privacy and data integrity. Elements may be deployed as part of a wider strategy incorporating multiple points of DDoS detection, classification, traceback and mitigation, both on premise or service provider based. Should changing conditions necessitate altering the specifics of mitigation actions and/or the topological scope of mitigation coverage, timely and effective signaling of telemetry and current threat status to all elements involved in the mitigation is essential. Feedback between participating elements is required for increased awareness supporting effective decision making. The WG will, where appropriate, reuse or extend existing standard protocols and mechanisms (for example, IPFIX and its associated templating and extension mechanisms). Any modification of or extension to existing protocols must be in close coordination with the working groups responsible for the protocol being modified, and may be done in this working group after agreement with all the relevant WGs and responsible Area Directors. The WG may coordinate on a situationally appropriate basis with other working groups and initiatives which compliment the DOTS effort e.g. M3AAWG, SACM, MILE, SUPA, I2NSF et. al. The WG will document requirements for the transport protocol to be used for the signaling of DOTS and consult with the Transport Area about the requirements and, if applicable, any new development of a encapsulation scheme for DOTS. The charter of the working group is to produce one or more standards track specifications to provide for this open signaling in the DDoS problem space. While the resulting standards should be designed so they apply to network security applications beyond the DDoS problem space, this working group will focus on signaling and coordination mechanisms directly related to DDoS attack detection, classification, traceback and mitigation, incorporating the general principles articulated in RFC5218 . Focusing the WG efforts on DDoS is intended to meet the community's desire for a deployable solution in the near term. The specification(s) produced by the WG will include a standard mechanism for authentication and authorization, data integrity, and providing for privacy in operation, with privacy-friendly choices being the default in all cases. The WG will produce the following deliverables and milestones: * Document or Documents describing the problem space, use cases, protocol requirements and other qualifying information as the WG sees fit. * Document or Documents specifying protocols and associated data models to address the stated goals of the WG. Milestones: Feb 2016 - Requirements/use case information document to IESG May 2016 - Transport document as proposed standard to IESG Jun 2016 - Data model document as proposed standard to IESG _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Jun 12 09:11:55 2015 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 720051A1F73; Fri, 12 Jun 2015 09:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1434125201; bh=2QyvKyu0stSPxsh62ErkrVgPZrwNMsdDwPm+SxEyMhE=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=k+DWGnqU/BaceNfTmou1gImOb1YrqA54GWRjVSgPnYwAx0sG2yLBT+PnXrS57kg4T p9gYB+YENoKvtzP0voensCD3Ely8KcGnNgnnIXLqKa3yX0zJdzbcX2TwyXL82BMnMP 07+inl1JyVKa9ab2+Ig/PEfK+3tIWTU3yVyfofIs= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9118C1A1F73; Fri, 12 Jun 2015 09:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtwDQFk09zRf; Fri, 12 Jun 2015 09:06:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 351D91A1BAC; Fri, 12 Jun 2015 09:06:28 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150612160628.14548.94621.idtracker@ietfa.amsl.com> Date: Fri, 12 Jun 2015 09:06:28 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 12 Jun 2015 09:11:49 -0700 Subject: [secdir] [new-work] WG Review: Automated Certificate Management Environment (acme) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 16:06:41 -0000 A new IETF working group has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22. Automated Certificate Management Environment (acme) ------------------------------------------------ Current Status: Proposed WG Chairs: Rich Salz Ted Hardie Assigned Area Director: Kathleen Moriarty Mailing list Address: acme@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/acme Archive: http://www.ietf.org/mail-archive/web/acme/ Charter: Historically, issuance of certificates for Internet applications (e.g., web servers) has involved many manual identity validation steps by the certification authority (CA). The ACME WG will specify conventions for automated X.509 certificate management, including validation of control over an identifier, certificate issuance, certificate renewal, and certificate revocation. The initial focus of the ACME WG will be on domain name certificates (as used by web servers), but other uses of certificates can be considered as work progresses. ACME certificate management must allow the CA to verify, in an automated manner, that the party requesting a certificate has authority over the requested identifiers, including the subject and subject alternative names. The processing must also confirm that the requesting party has access to the private key that corresponds to the public key that will appear in the certificate. All of the processing must be done in a manner that is compatible with common service deployment environments, such as hosting environments. ACME certificate management must, in an automated manner, allow an authorized party to request revocation of a certificate. The ACME working group is specifying ways to automate certificate issuance, validation, revocation and renewal. The ACME working group is not reviewing or producing certificate policies or practices. The starting point for ACME WG discussions shall be draft-barnes-acme. Milestones: Aug 2015 - Initial working group draft Mar 2016 - Submit working group draft to IESG as Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Jun 12 09:11:56 2015 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 527441A7007; Fri, 12 Jun 2015 09:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1434125226; bh=S6l/yl4MZ9nuAj6fuDboLfX/9N/S/A3JFE52Rw/+xG0=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=H1jmOH0fhZpXoy83WphsjGY4v1aKQZfst2JyZcRMrPsgW/p1zwXbj25Gi7EUHqhp7 4ADMUE6fLaIqjV4cs+QUHiZIT8CSnlklvlnhLXl+J3F3k5t6A67m63mHzrqPhMM/OR Eo9bAHxCq0qwnUWRwlNvUHlME4za5FEN59FTLu9E= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C23D1A6F30; Fri, 12 Jun 2015 09:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIxWUj3l3JoZ; Fri, 12 Jun 2015 09:07:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E45031A1BFA; Fri, 12 Jun 2015 09:06:49 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150612160649.18953.62329.idtracker@ietfa.amsl.com> Date: Fri, 12 Jun 2015 09:06:49 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 12 Jun 2015 09:11:49 -0700 Subject: [secdir] [new-work] WG Review: IMAP APPEND Extensions (imapapnd) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 16:07:06 -0000 A new IETF working group has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22. IMAP APPEND Extensions (imapapnd) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Barry Leiba Mailing list Address: imapext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/imapext Archive: https://www.ietf.org/mail-archive/web/imapext/ Charter: The Internet Message Access Protocol (IMAP), defined in RFC 3501, specifies a protocol for transferring email messages between a server that implements a message store, and a client. It also includes commands for manipulating the message store -- creating, deleting, and renaming mailboxes, adding a message to a mailbox, and copying messages from one mailbox to another. IMAP (RFC 3501) contains the "literal" syntactic construct for transferring blocks of data. Sending an IMAP literal string entails first sending the length of the string, waiting for a response that accepts a string of that length, then sending the string itself. This complicates client implementations and resulted in definition of the "LITERAL+" IMAP extension (RFC 2088), which specifies an alternative type of literal string that does not require an extra network round trip (the length and data are sent together). While this extension is quite commonly supported by servers, some implementations have it disabled because there is no good way for clients to know whether a server can accept big messages. The IMAP APPEND Extensions (imapapnd) working group will produce two related Standards Track specifications, which are targeted at improving the current situation: * The first is based on draft-jayantheesh-imap-appendlimit-extension, and defines a way for servers to announce an APPEND limit for a particular server or a particular mailbox. * The second is based on draft-melnikov-rfc2088bis, and describes implementation choices for servers supporting the LITERAL+ extension, as well as defining a new "LITERAL-" extension that has similar properties but provides a mechanism allowing servers to avoid denials of service by malicious or naive IMAP clients. As part of the protocol development, implementation experience on both the client and server side is highly desirable, so that the actual operational value of this extension can be assessed. The working group will document the results of this experience on the working group wiki. No other IMAP extension work is in scope for this working group. Milestones: _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Jun 12 19:39:45 2015 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F151ACED6; Fri, 12 Jun 2015 11:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1434134811; bh=zaXeDoAwTQjDVUaNC9p+JeGXCSt5Jixflss0yPgtgHE=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=stKa21XREeWoX4p0aVrUw7LDNh4mRFzQkGG8NdY+FE4Mu6oXwKEY1j+ctkX7xDJeD dW1iClgkK9+YRuAT/2oS/PVkqsfkKsa7dCcHGcYurKbM3btJD0Ns4hdD4+QX+O3Aai cXvXgYpIDbL6nK4dClZt9wPesd7IBWTWKYAyaKZE= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5031ACEC8; Fri, 12 Jun 2015 11:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1F-CMfRjLoj; Fri, 12 Jun 2015 11:46:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E98B1ACEB7; Fri, 12 Jun 2015 11:46:38 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150612184638.26579.51447.idtracker@ietfa.amsl.com> Date: Fri, 12 Jun 2015 11:46:38 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 12 Jun 2015 19:39:44 -0700 Subject: [secdir] [new-work] WG Review: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 18:46:51 -0000 A new IETF working group has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-22. Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (modern) ------------------------------------------------ Current Status: Proposed WG Chairs: Tom McGarry Steve Donovan Assigned Area Director: Alissa Cooper Mailing list Address: modern@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/modern Archive: http://www.ietf.org/mail-archive/web/modern/ Charter: The MODERN working group will define a set of Internet-based mechanisms for the purposes of managing and resolving telephone numbers (TNs) in an IP environment. Devices, applications, and network tools increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities. The output of the working group should make distribution, acquisition, and management of TNs simpler for all entities involved. The working group will define an information management framework for the roles and functions involved in associating information with one or more TNs in an IP environment. The working group will also identify protocol mechanisms to support the interactions between the functions defined by the framework. This includes either recommending or defining protocol mechanisms for acquiring, associating and resolving TNs, with a preference for use of existing protocol mechanisms. TNs may either be managed in a hierarchical tree, or in a distributed registry. The protocol mechanism for acquiring TNs will provide an enrollment process for the entities that use and manage TNs. The protocol mechanism for resolving TNs will allow entities such as service providers, devices, and applications to access data related to TNs. Maintaining reliability, real-time application performance, and security and privacy for both the data and the protocol interactions are primary considerations. The working group will take into consideration existing IETF work including STIR, ENUM, SPEERMINT, DRINKS and SCIM. The work of this group will focus on TNs, as defined in RFC3966, and blocks of TNs, that are used to initiate communication with another user of a service. There is an expectation that aspects of the architecture and protocols defined by the working group will be reusable for other user-focused identifiers. Any such extensions or reuse of MODERN mechanisms are out of scope for the MODERN working group. Solutions and mechanisms created by the working group will be flexible enough to accommodate different policies for TN assignment and management, for example those established by different regulatory agencies. The working group will deliver the following: - An architecture overview, including high level requirements and security/privacy considerations - A description of the enrollment processes for existing and new TNs including any modifications to metadata related to those TNs - A description of protocol mechanisms for accessing contact information associated with enrollments - A description of mechanisms for resolving information related to TNs Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Jun 12 19:39:46 2015 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 562651B2AC6; Fri, 12 Jun 2015 14:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1434143133; bh=t/kpcInGsROmKlCmVbF22TdHOxOndOCjLqnIbgvjbfg=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=dfyDYm/ALAi0c0apNy/UHGlcQSrCwpG/CRJDWE28MHcO5KAEKLuuno7LH2A/fiXRx wGZEjk6jQqgrfYgoMYXprVmVlD7vSPBn89etQE4ib8Sbvk5EAGBnkYbKafks/K/0q2 i3p7bOa6F3QVWWZs0PuYZSIVke6S1jHoUfmoBJLU= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3FB1B2AC6; Fri, 12 Jun 2015 14:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ng8GsTS2hZWA; Fri, 12 Jun 2015 14:05:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5FA1AC412; Fri, 12 Jun 2015 14:05:30 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150612210530.32575.28203.idtracker@ietfa.amsl.com> Date: Fri, 12 Jun 2015 14:05:30 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 12 Jun 2015 19:39:44 -0700 Subject: [secdir] [new-work] WG Review: Privacy Enhanced RTP Conferencing (perc) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 21:05:33 -0000 QSBuZXcgSUVURiB3b3JraW5nIGdyb3VwIGhhcyBiZWVuIHByb3Bvc2VkIGluIHRoZSBBcHBsaWNh dGlvbnMgYW5kClJlYWwtVGltZSBBcmVhLiBUaGUgSUVTRyBoYXMgbm90IG1hZGUgYW55IGRldGVy bWluYXRpb24geWV0LiBUaGUKZm9sbG93aW5nIGRyYWZ0IGNoYXJ0ZXIgd2FzIHN1Ym1pdHRlZCwg YW5kIGlzIHByb3ZpZGVkIGZvciBpbmZvcm1hdGlvbmFsCnB1cnBvc2VzIG9ubHkuIFBsZWFzZSBz ZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIElFU0cgbWFpbGluZyBsaXN0IChpZXNnCmF0IGlldGYu b3JnKSBieSAyMDE1LTA2LTIyLgoKUHJpdmFjeSBFbmhhbmNlZCBSVFAgQ29uZmVyZW5jaW5nICAo cGVyYykKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCkN1 cnJlbnQgU3RhdHVzOiBQcm9wb3NlZCBXRwoKQ2hhaXJzOgogIFJpY2hhcmQgQmFybmVzIDxybGJA aXB2LnN4PgogIFN1aGFzIE5hbmRha3VtYXIgPHN1aGFzaWV0ZkBnbWFpbC5jb20+CgpBc3NpZ25l ZCBBcmVhIERpcmVjdG9yOgogIEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPgoKTWFpbGlu ZyBsaXN0CiAgQWRkcmVzczogZGlzcGF0Y2hAaWV0Zi5vcmcKICBUbyBTdWJzY3JpYmU6IAogIEFy Y2hpdmU6IAoKQ2hhcnRlcjoKClJUUC1iYXNlZCByZWFsLXRpbWUgbXVsdGktcGFydHkgaW50ZXJh Y3RpdmUgbWVkaWEgY29uZmVyZW5jaW5nIGlzIGluCndpZGVzcHJlYWQgdXNlIHRvZGF5LiBNYW55 IG9mIHRoZSBkZXBsb3ltZW50cyB1c2Ugb25lIG9yIG1vcmUgY2VudHJhbGx5CmxvY2F0ZWQgbWVk aWEgZGlzdHJpYnV0aW9uIGRldmljZXMgdGhhdCBwZXJmb3JtIHNlbGVjdGl2ZSBmb3J3YXJkaW5n IG9mCm1peGVkLW1lZGlhIHN0cmVhbXMgcmVjZWl2ZWQgZnJvbSB0aGUgcGFydGljaXBhdGluZyBl bmRwb2ludHMuIFRoZSBtZWRpYQp0cmFuc3BvcnQgcHJvdG9jb2wgY29tbW9ubHkgdXNlZCBpcyBS VFAgKFJGQzM1NTApLiBUaGVyZSBhcmUgdmFyaW91cwpzaWduYWxpbmcgc3lzdGVtcyB1c2VkIHRv IGVzdGFibGlzaCB0aGVzZSBtdWx0aS1wYXJ0eSBjb25mZXJlbmNlcy4KIApUaGVzZSBjb25mZXJl bmNlcyByZXF1aXJlIHNlY3VyaXR5IHRvIGVuc3VyZSB0aGF0IHRoZSBSVFAgbWVkaWEgYW5kCnJl bGF0ZWQgbWV0YWRhdGEgb2YgdGhlIGNvbmZlcmVuY2UgaXMga2VwdCBwcml2YXRlIGFuZCBvbmx5 IGF2YWlsYWJsZSB0bwp0aGUgc2V0IG9mIGludml0ZWQgcGFydGljaXBhbnRzIGFuZCBvdGhlciBk ZXZpY2VzIHRydXN0ZWQgYnkgdGhvc2UKcGFydGljaXBhbnRzIHdpdGggdGhlaXIgbWVkaWEuICBB dCB0aGUgc2FtZSB0aW1lLCBtdWx0aS1wYXJ0eSBtZWRpYQpjb25mZXJlbmNlcyBuZWVkIHNvdXJj ZSBhdXRoZW50aWNhdGlvbiBhbmQgaW50ZWdyaXR5IGNoZWNrcyB0byBwcm90ZWN0CmFnYWluc3Qg bW9kaWZpY2F0aW9ucywgaW5zZXJ0aW9ucywgYW5kIHJlcGxheSBhdHRhY2tzLiAgTWVkaWEKZGlz dHJpYnV0aW9uIGRldmljZXMgc3VwcG9ydGluZyB0aGVzZSBjb25mZXJlbmNlcyBtYXkgYWxzbyBw ZXJmb3JtIFJUUApoZWFkZXIgY2hhbmdlcywgYW5kIHRoZXkgb2Z0ZW4gY29uc3VtZSBhbmQgY3Jl YXRlIFJUQ1AgbWVzc2FnZXMgZm9yCmVmZmljaWVudCBtZWRpYSBoYW5kbGluZy4KIApUbyBkYXRl LCBkZXBsb3ltZW50IG1vZGVscyBmb3IgdGhlc2UgbXVsdGktcGFydHkgbWVkaWEgZGlzdHJpYnV0 aW9uCmRldmljZXMgZG8gbm90IGVuYWJsZSB0aGUgZGV2aWNlcyB0byBwZXJmb3JtIHRoZWlyIGZ1 bmN0aW9ucyB3aXRob3V0CmhhdmluZyBrZXlzIHRvIGRlY3J5cHQgdGhlIHBhcnRpY2lwYW50c+KA mSBtZWRpYSwgcHJpbWFyaWx5IHVzaW5nIFNlY3VyZQpSVFAgKFJGQzM3MTEpIHRvIHByb3ZpZGUg c2Vzc2lvbiBzZWN1cml0eS4gCiAKVGhpcyB0cnVzdCBtb2RlbCBoYXMgbGltaXRhdGlvbnMgYW5k IHByZXZlbnRzIG9yIGhhbXBlcnMgZGVwbG95bWVudCBvZgpzZWN1cmUgUlRQIGNvbmZlcmVuY2lu ZyBpbiBhIG11bHRpdHVkZSBvZiBjYXNlcywgaW5jbHVkaW5nIG91dHNvdXJjaW5nLApsZWdhbCBy ZXF1aXJlbWVudHMgb24gY29uZmlkZW50aWFsaXR5LCBhbmQgdXRpbGl6YXRpb24gb2YgdmlydHVh bGl6ZWQKc2VydmVycy4gVGh1cywgYSBuZXcgYXJjaGl0ZWN0dXJhbCBtb2RlbCBhbmQgcmVsYXRl ZCBzcGVjaWZpY2F0aW9ucyBhcmUKbmVlZGVkLCB3aXRoIGEgZm9jdXNlZCBlZmZvcnQgZnJvbSB0 aGUgUlRQIGFuZCBTZWN1cml0eSBjb21tdW5pdGllcy4KIApXRyBPYmplY3RpdmVzCiAKVGhpcyBX RyB3aWxsIHdvcmsgb24gYSBzb2x1dGlvbiB0aGF0IGVuYWJsZXMgY2VudHJhbGl6ZWQgU1JUUC1i YXNlZApjb25mZXJlbmNpbmcsIHdoZXJlIHRoZSBjZW50cmFsIGRldmljZSBkaXN0cmlidXRpbmcg dGhlIG1lZGlhIGlzIG5vdApyZXF1aXJlZCB0byBiZSB0cnVzdGVkIHdpdGggdGhlIGtleXMgdG8g ZGVjcnlwdCB0aGUgcGFydGljaXBhbnRzJyBtZWRpYS4KVGhlIG1lZGlhIG11c3QgYmUga2VwdCBj b25maWRlbnRpYWwgYW5kIGF1dGhlbnRpY2F0ZWQgYmV0d2VlbiBhbgpvcmlnaW5hdGluZyBlbmRw b2ludCBhbmQgdGhlIGV4cGxpY2l0bHkgYWxsb3dlZCByZWNlaXZpbmcgZW5kcG9pbnRzIG9yCm90 aGVyIGRldmljZXMuIFRoZSBtZXRhIGluZm9ybWF0aW9uIHByb3ZpZGVkIHRvIHRoZSBjZW50cmFs IGRldmljZSBpcyB0bwpiZSBsaW1pdGVkIHRvIHRoZSBtaW5pbWFsIHJlcXVpcmVkIGZvciBpdCB0 byBwZXJmb3JtIGl0cyBmdW5jdGlvbiB0bwpwcmVzZXJ2ZSB0aGUgY29uZmVyZW5jZSBwYXJ0aWNp cGFudHMgcHJpdmFjeS4gRnVydGhlciwgaXQgaXMgZGVzaXJlZCB0aGF0CmEgc29sdXRpb24gc3Rp bGwgcHJvdmlkZXMgcmVwbGF5IHByb3RlY3Rpb24sIHNvIHRoYXQgdGhlIG1lZGlhCmRpc3RyaWJ1 dGlvbiBkZXZpY2VzIGNhbuKAmXQgcmVwbGF5IHByZXZpb3VzIHBhcnRzIG9mIHRoZSBtZWRpYS4K IApUaGUgc29sdXRpb24gbXVzdCBhbHNvIHByb3ZpZGUgc2VjdXJpdHkgZm9yIGVhY2ggaG9wIGJl dHdlZW4gZW5kcG9pbnRzCmFuZCBtdWx0aS1wYXJ0eSBtZWRpYSBkaXN0cmlidXRpb24gZGV2aWNl cyBhbmQgYmV0d2VlbiBtdWx0aS1wYXJ0eSBtZWRpYQpkaXN0cmlidXRpb24gZGV2aWNlcy4gVGhl IFJUQ1AgbWVzc2FnZXMgYW5kIFJUUCBoZWFkZXIgZXh0ZW5zaW9ucwpyZXF1aXJlZCBmb3IgdGhl IG1lZGlhIGRpc3RyaWJ1dGlvbiBkZXZpY2UgdG8gcGVyZm9ybSB0aGUgc2VsZWN0aXZlIG1lZGlh CmZvcndhcmRpbmcgbWF5IHJlcXVpcmUgYm90aCBzb3VyY2UgYXV0aGVudGljYXRpb24gYW5kIGlu dGVncml0eSBhcyB3ZWxsCmFzIGNvbmZpZGVudGlhbGl0eS4gVGhlIHNvbHV0aW9uIG1heSBhbHNv IGNvbnNpZGVyIHByb3ZpZGluZyBlbmQtdG8tZW5kCnNlY3VyaXR5IGZvciBhIHN1YnNldCBvZiB0 aGUgUlRDUCBtZXNzYWdlcyBvciBSVFAgaGVhZGVyIGV4dGVuc2lvbnMuCgpUaGUgc29sdXRpb24g c2hvdWxkIGJlIGltcGxlbWVudGFibGUgYnkgYm90aCBTSVAgKFJGQzMyNjEpIGFuZCBXZWJSVEMK ZW5kcG9pbnRzIChkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldykuIEhvdyB0ZWxlcHJlc2VuY2Ug ZW5kcG9pbnRzIHVzaW5nCnRoZSBwcm90b2NvbHMgZGVmaW5lZCBpbiB0aGUgQ0xVRSB3b3JraW5n IGdyb3VwIGNvdWxkIHV0aWxpemUgdGhlIGRlZmluZWQKc2VjdXJpdHkgc29sdXRpb24gbmVlZHMg dG8gYmUgY29uc2lkZXJlZC4gSG93ZXZlciwgaXQgaXMgYWNrbm93bGVkZ2VkCnRoYXQgbGltaXRh dGlvbnMgbWF5IGV4aXN0LCByZXN1bHRpbmcgaW4gcmVzdHJpY3RlZCBmdW5jdGlvbmFsaXR5IG9y IG5lZWQKZm9yIGFkZGl0aW9uYWwgYWRhcHRhdGlvbnMgb2YgdGhlIENMVUUgcHJvdG9jb2xzLiAK ClRoaXMgd29ya2luZyBncm91cCB3aWxsIHBlcmZvcm0gdGhlIGZvbGxvd2luZyB3b3JrOgogCjEu ICAgIERlZmluZSBhIGdlbmVyYWwgYXJjaGl0ZWN0dXJlIGFuZCBSVFAgdG9wb2xvZ3kocykgdGhh dCBlbmFibGVzCmVuZC10by1lbmQgbWVkaWEgc2VjdXJpdHkgZm9yIG11bHRpLXBhcnR5IFJUUCBj b25mZXJlbmNpbmcuCjIuICAgIERlZmluZSB0aGUgdHJ1c3QgbW9kZWwgYW5kIGRlc2NyaWJlIHRo ZSByZXN1bHRpbmcgc2VjdXJpdHkKcHJvcGVydGllcy4KMy4gICAgRG9jdW1lbnQgbW9kZWxzIGNv bnNpZGVyZWQgZm9yIGludGVncmF0aW5nIHRoZSBzb2x1dGlvbiB3aXRoCldlYlJUQywgU0lQIGFu ZCBDTFVFIGVzdGFibGlzaG1lbnQgb2YgY29uZmVyZW5jaW5nIHNlc3Npb25zLgo0LiAgICBTcGVj aWZ5IGFueSBuZWNlc3NhcnkgZXh0ZW5zaW9ucyB0byBTUlRQLgo1LiAgIERlZmluZSBuZWVkZWQg S2V5IE1hbmFnZW1lbnQgRnVuY3Rpb25zIHRoYXQgZGlzdHJpYnV0ZSB0aGUga2V5cy4gVGhlCnN5 c3RlbSBuZWVkcyB0byBiZSBhYmxlIHRvIGJpbmQgdGhlIG1lZGlhIHRvIHRoZSBpZGVudGl0eSBv ZiB0aGUgc2VuZGVyCm9mIHRoZSBtZWRpYSBhbmQvb3IgdGhlIGlkZW50aXR5IG9mIHRoZSBjb25m ZXJlbmNlLgogCkNvbGxhYm9yYXRpb24KIApJZiB0aGVyZSBpcyBpZGVudGlmaWNhdGlvbiBvZiBt aXNzaW5nIHByb3RvY29scyBvciBmdW5jdGlvbmFsaXRpZXMsIHN1Y2gKd29yayBjYW4gYmUgcmVx dWVzdGVkIHRvIGJlIGRvbmUgaW4gYW5vdGhlciB3b3JraW5nIGdyb3VwIHdpdGggYSBzdWl0YWJs ZQpjaGFydGVyIG9yIGJ5IHJlcXVlc3RzIGZvciBjaGFydGVyaW5nIGl0IGluIHRoaXMgV0cgb3Ig YW5vdGhlciBXRy4KUG90ZW50aWFsIGl0ZW1zIHRoYXQgbWlnaHQgcmVxdWlyZSB3b3JrIGluIG90 aGVyIFdHcyBhcmUgRFRMUyBleHRlbnNpb25zCihUTFMgV0cpIGFuZCBSVFAgaGVhZGVyIGV4dGVu c2lvbnMgKEFWVEVYVCBXRykuIFRoaXMgd29yayByZXF1aXJlcyBzdHJvbmcKY29sbGFib3JhdGlv biB3aXRoIHRoZSBzZWN1cml0eSBhcmVhLiBXZSB3aWxsIG5vdGlmeSwgYW5kIHdoZW4gbmVlZGVk CmNvb3JkaW5hdGUgd2l0aCwgQVZUQ29yZSwgQ0xVRSwgTU1VU0lDLCBSVENXRUIsIFNJUFJFQywg VzNDIFdlYlJUQywgYW5kCm90aGVyIHJlbGF0ZWQgZ3JvdXBzIGFib3V0IHRoaXMgd29yay4gCiAK Tm9uLUdvYWxzCiAKVGhlIFBFUkMgd29ya2luZyBncm91cCBpcyBub3QgY2hhcnRlcmVkIHRvIGV4 dGVuZCBhbnkgc2lnbmFsaW5nIHN5c3RlbQp1c2VkIHRvIGVzdGFibGlzaCB0aGUgUlRQLWJhc2Vk IGNvbmZlcmVuY2VzLiBJdCB3aWxsLCBob3dldmVyLCBuZWVkIHRvCmNvbnNpZGVyIGluIGl0cyBh cmNoaXRlY3R1cmUgaG93IHRoZSBzb2x1dGlvbiBtYXkgaW50ZWdyYXRlIHdpdGggdGhlc2UKc3lz dGVtcywgYW5kIGRvY3VtZW50IHN1Y2ggY29uc2lkZXJhdGlvbiBmb3IgV2ViUlRDLCBTSVAsIGFu ZCBDTFVFLiBUaGUKc3BlY2lmaWNhdGlvbiBvZiBob3cgYSBwYXJ0aWN1bGFyIHN5c3RlbSBpbnRl Z3JhdGVzIHRoZSBzZWN1cml0eSBzb2x1dGlvbgp3aWxsIGhhcHBlbiBvdXRzaWRlIG9mIHRoaXMg d29ya2luZyBncm91cCwgaW4gc3VpdGFibGUgdmVudWVzLiAKClRoZSBXRyB3aWxsIG5vdCBjb25z aWRlciBub24tcmVhbC10aW1lIHVzYWdlLCBtdWx0aWNhc3QtYmFzZWQgbWVkaWEKZGlzdHJpYnV0 aW9uLCBvciBTZWN1cml0eSBkZXNjcmlwdGlvbnMtYmFzZWQga2V5aW5nIChSRkM0NTY4KS4KCklu cHV0IHRvIHRoZSBXRwoKUHJvcG9zYWxzIGFscmVhZHkgZXhpc3RpbmcgcmVsYXRpbmcgdG8gdGhp cyBjaGFydGVyIHByb3Bvc2FsOgoKaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtam9uZXMtYXZ0Y29yZS1wcml2YXRlLW1lZGlhLXJlcXRzLwpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1qb25lcy1hdnRjb3JlLXByaXZhdGUtbWVkaWEtZnJhbWV3b3Jr LwpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jaGVuZy1hdnRjb3JlLXNy dHAtY2xvdWQvCgoKCgpNaWxlc3RvbmVzOgogIFNlcCAyMDE2IC0gU3VibWl0IGFyY2hpdGVjdHVy ZSBvciBmcmFtZXdvcmsgc3BlY2lmaWNhdGlvbiB0byBJRVNHCihTdGFuZGFyZHMgVHJhY2spCiAg SmFuIDIwMTcgLSBTdWJtaXQgZG9jdW1lbnRhdGlvbiBvZiBob3cgdG8gaW50ZWdyYXRlIHNvbHV0 aW9uIGluIFNJUCwKV2ViUlRDIGFuZCBDTFVFIHRvIElFU0cgKEluZm9ybWF0aW9uYWwpCiAgSnVu IDIwMTcgLSBTdWJtaXQgU1JUUCBwcm90b2NvbCBleHRlbnNpb24gc3BlY2lmaWNhdGlvbiB0byBJ RVNHCihTdGFuZGFyZHMgVHJhY2spCiAgSnVuIDIwMTcgLSBTdWJtaXQgS2V5LW1hbmFnZW1lbnQg cHJvdG9jb2wgc3BlY2lmaWNhdGlvbiB0byBJRVNHCihTdGFuZGFyZHMgVHJhY2spCgoKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV3LXdvcmsgbWFpbGlu ZyBsaXN0Cm5ldy13b3JrQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV3LXdvcmsK From nobody Mon Jun 15 11:48:58 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38ACC1A1B98; Mon, 15 Jun 2015 11:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.11 X-Spam-Level: X-Spam-Status: No, score=0.11 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_FROM_12LTRDOM=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJi-FyCcQCvo; Mon, 15 Jun 2015 11:48:53 -0700 (PDT) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA9B41A1B7B; Mon, 15 Jun 2015 11:48:53 -0700 (PDT) Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Z4ZRD-0006fO-RM; Mon, 15 Jun 2015 12:48:51 -0600 Received: from [72.250.219.84] (helo=sylvester.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1Z4ZRD-0003sT-3F; Mon, 15 Jun 2015 12:48:51 -0600 Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.4/Debian-2ubuntu1) with ESMTP id t5FImZM7006067; Mon, 15 Jun 2015 12:48:35 -0600 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id t5FImZ8e006065; Mon, 15 Jun 2015 12:48:35 -0600 Date: Mon, 15 Jun 2015 12:48:35 -0600 Message-Id: <201506151848.t5FImZ8e006065@sylvester.rhmr.com> From: "Hilarie Orman" To: secdir@ietf.org X-XM-AID: U2FsdGVkX1+TFHRi/KofjOS6rM1N1dDl X-SA-Exim-Connect-IP: 72.250.219.84 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ******;secdir@ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 428 ms - load_scoreonly_sql: 0.22 (0.1%), signal_user_changed: 6 (1.4%), b_tie_ro: 4.0 (0.9%), parse: 1.15 (0.3%), extract_message_metadata: 10 (2.4%), get_uri_detail_list: 1.94 (0.5%), tests_pri_-1000: 3.6 (0.8%), tests_pri_-950: 1.56 (0.4%), tests_pri_-900: 1.38 (0.3%), tests_pri_-400: 23 (5.4%), check_bayes: 21 (5.0%), b_tokenize: 6 (1.3%), b_tok_get_all: 6 (1.5%), b_comp_prob: 3.5 (0.8%), b_tok_touch_all: 3.1 (0.7%), b_finish: 1.07 (0.3%), tests_pri_0: 370 (86.7%), tests_pri_500: 6 (1.4%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Archived-At: Cc: iesg@ietf.org, draft-ietf-sipcore-6665-clarification@tools.ietf.org Subject: [secdir] Security review of draft-ietf-sipcore-6665-clarification-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 18:48:55 -0000 Security review of draft-ietf-sipcore-6665-clarification-00 A clarification on the use of Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP) Event Notification Framework Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. SIP is big, very big, and I've not even come close to reading all the defining documents. Thus, I'm on shaky ground here. I believe that a GRUU stands for a collection of contact handles for an individual, and it is thus an identifier for a protocol entity. The clarification addresses when to use GRUUs, and the answer is something like "for all dialogs, unless the dialog is forbidden." The clarification emphasizes that it applies to INVITE dialogs. According to the text, implementers have not always used a GRUU as a local target. Is this deliberate or accidental? Is there some perceived advantage to avoiding GRUUs for INVITE? If so, can the clarification explain why it is a misconception? I don't really understand why GRUUs are to be avoided for forbidden dialogs. Perhaps it is an optimization that would be obvious to a skilled SIP implementor. Beyond that, I am not at all sure about the effect of GRUUs on the overall security of the protocol. If they are used for all dialogs, might that open the door to some sort of amplication attack? Does it allow some sort of probing that could widen the attack surface? I would like to see a sentence or two in the security considerations explaining why not. An editorial comment about the text "... to allow you to send ...". "You" is a confusing informality in a protocol description. The formal name of the role ("notifier"?) should be used. Hilarie From nobody Mon Jun 15 20:59:39 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9883A1B2850 for ; Mon, 15 Jun 2015 20:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 qTXfo5Ihj-nA for ; Mon, 15 Jun 2015 20:59:36 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918AD1AD4A1 for ; Mon, 15 Jun 2015 20:59:36 -0700 (PDT) Received: by wiwd19 with SMTP id d19so92059420wiw.0 for ; Mon, 15 Jun 2015 20:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DyXyXhKgS8mg3iGtRk1jCjdWIspK8HDocNVswP2wgPA=; b=IfA6hdY+FCed2+2iMjBe1fYoBCqQZrUEbFlkeNdiXqJqDyjI4uQfFrXwSFJjoA3ygV C5XjGw4f4uzesq8KASd/HVPJ5ngjS5JCGhTiNJ0ORdUb3tLdM7GUQJKaD3TXZ8I5kZPE pj1nOyNCsDi52TbwMv03cf5/v4fjfnhkdwa6hwjQsQWRA18DwKkVYN59A9LDPSpzJ/4N 1vhXagl9C2m6ugzwfNt9xg5YAFt8c3/qse4KbygWMUDaw13I8wOkcR59yi2LCH6rxyJS nY77HOe2UJAUJdakuxgJunFP1g5Wh7vfn/GDmEGZz58lAFoJxiVWjD4tTnbMqRVWloAa Zcig== MIME-Version: 1.0 X-Received: by 10.180.37.230 with SMTP id b6mr2077079wik.14.1434427175298; Mon, 15 Jun 2015 20:59:35 -0700 (PDT) Received: by 10.180.187.243 with HTTP; Mon, 15 Jun 2015 20:59:35 -0700 (PDT) Date: Mon, 15 Jun 2015 20:59:35 -0700 Message-ID: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= To: "secdir@ietf.org" , draft-ietf-rtgwg-lfa-manageability@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] Secdir review of draft-ietf-rtgwg-lfa-manageability X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 03:59:37 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This memo provides operational feedback on LFA, highlights some limitations, and proposes some refinements based on the found limitations. As such, the Security Considerations seems adequate to me - it refers to the foundational RFC 5286. -- Magnus From nobody Tue Jun 16 09:02:09 2015 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 524F51ACE36; Mon, 15 Jun 2015 07:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1434379091; bh=bSQW8p15Mh6e+y2Nfp6Yo1eXSX8Os5Atjl7089g3OMU=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=V/+yXgIFQUEycf5Vy5+YiF3Jrj29nqyzkAcnj4JNFXbaeogTmD2VMROEKKcGGfJH0 0y8E9zTo+5h0o3vwysvKBKQeMowdqq78THXyKXRaiffwCrZ2XypIFWl5+IqOJyMwFz +Uro1UhjvrRAhI+c3dorJZDszdBqzHLGLfo4EHYk= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C906F1ACE36; Mon, 15 Jun 2015 07:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-9Kg5dC9ymK; Mon, 15 Jun 2015 07:38:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE101A86F5; Mon, 15 Jun 2015 07:38:05 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150615143805.17937.95388.idtracker@ietfa.amsl.com> Date: Mon, 15 Jun 2015 07:38:05 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 16 Jun 2015 09:02:07 -0700 Subject: [secdir] [new-work] WG Review: Open Specification for Pretty Good Privacy (openpgp) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 14:38:11 -0000 A new IETF working group has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-25. Open Specification for Pretty Good Privacy (openpgp) ------------------------------------------------ Current Status: Proposed WG Chairs: Daniel Gillmor Christopher Liljenstolpe Assigned Area Director: Stephen Farrell Mailing list Address: openpgp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/openpgp Archive: https://www.ietf.org/mail-archive/web/openpgp/current/maillist.html Charter: OpenPGP is an Internet standard that covers object encryption, object signing, and identity certification. These were defined by the first incarnation of the OpenPGP working group. The following is an excerpt from the charter of the original incarnation of the openpgp working group > The goal of the OpenPGP working group is to provide IETF standards for > the algorithms and formats of PGP processed objects as well as providing the MIME > framework for exchanging them via e-mail or other transport protocols. The working group concluded this work and was closed in March of 2008. In the intervening period, there has been a rough consensus reached that the RFC that defined the IETF openpgp standard, RFC4880, is in need of revision. This incarnation of the working group is chartered to primarily produce a revision of RFC4880 to address issues that have been identified by the community since the working group was originally closed. These revisions will include, but are not limited to: - Potential inclusion of elliptic curves recommended by the CFRG (see note below) - A symmetric encryption mechanism that offers modern message integrity protection (e.g. AEAD) - Revision of mandatory-to-implement algorithm selection and deprecation of weak algorithms - An updated public-key fingerprint mechanism The Working Group will perform the following work: - Revise RFC4880 - Other work related to OpenPGP may be entertained by the working group as long as it does not interfere with the completion of the RFC4880 revision. As the revision of RFC4880 is the primary goal of the working group, other work may be undertaken, so long as: 1. The work will not unduly delay the closure of the working group after the revision is finished (unless the working group is rechartered). 2. The work has widespread support in the working group. These additional work items may only be added with approval from the responsible Area Director or by re-chartering. Inclusion of CFRG Curves ----------------------------- The Working Group will consider CFRG curves as possible Mandatory to Implement (MTI) based on the output of the CFRG and/or Working Group consensus in the matter. Working Group Process -------------------------- The working group will endeavor to complete most if not all of its work online on the working group's mailing list. We expect that the requirement for face-to-face sessions at IETF meetings to be minimal. Furthermore, the working group will accept no ID's as working group items unless there is a review by at least two un-interested parties of the ID as part of the acceptance process. Milestones: Sep 2015 - Working Group (rough) consensus on the necessary updates to RFC4880. Feb 2016 - First wg-id for RFC4880bis Jul 2016 - RFC4880bis wg-id final call _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Wed Jun 17 09:01:44 2015 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C57CF1AD09D; Wed, 17 Jun 2015 08:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1434554732; bh=7dnhihq7aEEk6QCZz0YDi6jWSffC4jkoNCGXFpT0ZYg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=KzlWBvL51PDgpjLHn4LJU1NOVFEmzjypvfpTk7ohoZGIt9CK9j2Ytr5cPnMqK2StF fCuo72ChENqSBmYhcz8KHU0nAjBQtTfq+JJ32tCMs/hkV3Sf/AZSv1m1sIz4Vk8LS4 I7Rq9UQVm5uY6GNVhWwGyv6Hk4SLITA4IiVbYoFE= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE7A1B366B; Tue, 16 Jun 2015 09:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 jmimHPop720W; Tue, 16 Jun 2015 09:36:05 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92071B3684; Tue, 16 Jun 2015 09:36:04 -0700 (PDT) Received: by laka10 with SMTP id a10so15299419lak.0; Tue, 16 Jun 2015 09:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LU8/HrV42Xw4QOcFwC6iITU7f6cpubqrieFKiuGdooI=; b=ylVIkRbDao3cHxe4Mrgl3tcRFywqyF6efpvuK0j2Xmcf/rNdfby4b9XK8Hqhox3Pkn lUgdtSS5eJevdkQ/nqcCvS6zsJJIBg+TD8Hgy5vvyV2SYftnjv55IYTBlWMYZ0zGO4Ev AllTo0WCF4aQxzGbQ0GirfOoVPHd6ssogUx+DDHFI5XXHPivTyyvyULJfkyuARXVAV// qa+itouT/xuZc5zpAghRDyc0Iaw4+fCPora6xTV0RojZsChc8WW9CE6ARc8FDiBoIYRd dFhgWRk97A3JnekYScn1D/m+m9bYoaB0N/bYRXWsYas0mWacMcmXXHF29WrkErSEdZjE hdGQ== MIME-Version: 1.0 X-Received: by 10.112.166.5 with SMTP id zc5mr2181575lbb.91.1434472563413; Tue, 16 Jun 2015 09:36:03 -0700 (PDT) Received: by 10.112.203.163 with HTTP; Tue, 16 Jun 2015 09:36:03 -0700 (PDT) In-Reply-To: <20150615143805.17937.95388.idtracker@ietfa.amsl.com> References: <20150615143805.17937.95388.idtracker@ietfa.amsl.com> Date: Tue, 16 Jun 2015 12:36:03 -0400 X-Google-Sender-Auth: rnlBkT0XGhJS0mwsV2TsKbd7fpg Message-ID: From: Phillip Hallam-Baker To: "iesg@ietf.org" Archived-At: X-Mailman-Approved-At: Wed, 17 Jun 2015 08:25:31 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Type: multipart/mixed; boundary="===============8386657065933354256==" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Wed, 17 Jun 2015 09:01:42 -0700 Cc: new-work@ietf.org Subject: Re: [secdir] [new-work] WG Review: Open Specification for Pretty Good Privacy (openpgp) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 15:25:33 -0000 --===============8386657065933354256== Content-Type: multipart/alternative; boundary=001a11c269069519480518a52bdc --001a11c269069519480518a52bdc Content-Type: text/plain; charset=UTF-8 It might sound like a real nit, but " An updated public-key fingerprint mechanism" OpenPGP fingerprints are created using message digests. And distributions of the code inevitably involve fingerprints of code, not just keys. Would prefer it just say "An updated fingerprint mechanism" One of the things I have been working on recently involves fingerprints of symmetric keys which I describe on the right key list. The approach is powerful and I believe it is likely to be useful for a range of personal pki apps. The thing that has been a killer in the past is management of personal private keys. The problem is getting worse as we have five platforms instead of just one. In 1992 I only had a desktop. Now I have desktops, laptops, tablets, phones and a watch. And only the last one of those is singular. This is a problem that is clearly linked to OpenPGP and should be served by any solution. But any solution has to support any application requiring credential management. On Mon, Jun 15, 2015 at 10:38 AM, The IESG wrote: > A new IETF working group has been proposed in the Security Area. The IESG > has not made any determination yet. The following draft charter was > submitted, and is provided for informational purposes only. Please send > your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-25. > > Open Specification for Pretty Good Privacy (openpgp) > ------------------------------------------------ > Current Status: Proposed WG > > Chairs: > Daniel Gillmor > Christopher Liljenstolpe > > Assigned Area Director: > Stephen Farrell > > Mailing list > Address: openpgp@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/openpgp > Archive: > https://www.ietf.org/mail-archive/web/openpgp/current/maillist.html > > Charter: > > OpenPGP is an Internet standard that covers object encryption, object > signing, and identity certification. These were defined by the first > incarnation of the OpenPGP working group. > > The following is an excerpt from the charter of the original incarnation > of the openpgp working group > > > The goal of the OpenPGP working group is to provide IETF standards for > > the algorithms and formats of PGP processed objects as well as providing > the MIME > > framework for exchanging them via e-mail or other transport protocols. > > The working group concluded this work and was closed in March of 2008. In > the intervening period, there has been a rough consensus reached that the > RFC that defined the IETF openpgp standard, RFC4880, is in need of > revision. > > This incarnation of the working group is chartered to primarily produce a > revision of RFC4880 to address issues that have been identified by the > community since the working group was originally closed. > > These revisions will include, but are not limited to: > > - Potential inclusion of elliptic curves recommended by the CFRG (see > note below) > > - A symmetric encryption mechanism that offers modern message integrity > protection (e.g. AEAD) > > - Revision of mandatory-to-implement algorithm selection and deprecation > of weak algorithms > > - An updated public-key fingerprint mechanism > > The Working Group will perform the following work: > > - Revise RFC4880 > > - Other work related to OpenPGP may be entertained by the working group > as long as it does not interfere with the completion of the RFC4880 > revision. As the revision of RFC4880 is the primary goal of the working > group, other work may be undertaken, so long as: > > 1. The work will not unduly delay the closure of the working group after > the revision is finished (unless the working group is rechartered). > > 2. The work has widespread support in the working group. > > These additional work items may only be added with approval from the > responsible Area Director or by re-chartering. > > Inclusion of CFRG Curves > ----------------------------- > > The Working Group will consider CFRG curves as possible Mandatory to > Implement (MTI) based on the output of the CFRG and/or Working Group > consensus in the matter. > > Working Group Process > -------------------------- > > The working group will endeavor to complete most if not all of its work > online on the working group's mailing list. We expect that the > requirement for face-to-face sessions at IETF meetings to be minimal. > > Furthermore, the working group will accept no ID's as working group items > unless there is a review by at least two un-interested parties of the ID > as part of the acceptance process. > > > Milestones: > Sep 2015 - Working Group (rough) consensus on the necessary updates to > RFC4880. > Feb 2016 - First wg-id for RFC4880bis > Jul 2016 - RFC4880bis wg-id final call > > > _______________________________________________ > new-work mailing list > new-work@ietf.org > https://www.ietf.org/mailman/listinfo/new-work > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > --001a11c269069519480518a52bdc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It might sound like a real nit, but "=C2=A0An updated public-key fingerprint mechan= ism"

OpenPGP fingerpri= nts are created using message digests. And distributions of the code inevit= ably involve fingerprints of code, not just keys.

Would prefer it just say "An updated fingerprint mechanism"=

<= /div>

One of the things I have bee= n working on recently involves fingerprints of symmetric keys which I descr= ibe on the right key list. The approach is powerful and I believe it is lik= ely to be useful for a range of personal pki apps.

The thing that has been a killer in the past = is management of personal private keys. The problem is getting worse as we = have five platforms instead of just one. In 1992 I only had a desktop. Now = I have desktops, laptops, tablets, phones and a watch. And only the last on= e of those is singular. This is a problem that is clearly linked to OpenPGP= and should be served by any solution. But any solution has to support any = application requiring credential management.





On Mon, Jun 15, 2015 at 10:38 AM, The IESG <iesg@ietf.org= > wrote:
A new IETF working gro= up has been proposed in the Security Area. The IESG
has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg at ietf.org) by 2015-06-25.

Open Specification for Pretty Good Privacy (openpgp)
------------------------------------------------
Current Status: Proposed WG

Chairs:
=C2=A0 Daniel Gillmor <dkg@fift= hhorseman.net>
=C2=A0 Christopher Liljenstolpe <ietf@cdl.asgaard.org>

Assigned Area Director:
=C2=A0 Stephen Farrell <ste= phen.farrell@cs.tcd.ie>

Mailing list
=C2=A0 Address: openpgp@ietf.org =C2=A0 To Subscribe: https://www.ietf.org/mailman/listi= nfo/openpgp
=C2=A0 Archive:
https://www.ietf.org/mail-archive= /web/openpgp/current/maillist.html

Charter:

OpenPGP is an Internet standard that covers object encryption, object
signing, and identity certification. These were defined by the first
incarnation of the OpenPGP working group.

The following is an excerpt from the charter of the original incarnation of the openpgp working group

> The goal of the OpenPGP working group is to provide IETF standards for=
> the algorithms and formats of PGP processed objects as well as providi= ng the MIME
> framework for exchanging them via e-mail or other transport protocols.=

The working group concluded this work and was closed in March of 2008. In the intervening period, there has been a rough consensus reached that the RFC that defined the IETF openpgp standard, RFC4880, is in need of
revision.

This incarnation of the working group is chartered to primarily produce a revision of RFC4880 to address issues that have been identified by the
community since the working group was originally closed.

These revisions will include, but are not limited to:

- Potential inclusion of elliptic curves recommended by the CFRG (see
note below)

- A symmetric encryption mechanism that offers modern message integrity
protection (e.g. AEAD)

- Revision of mandatory-to-implement algorithm selection and deprecation of weak algorithms

- An updated public-key fingerprint mechanism

The Working Group will perform the following work:

- Revise RFC4880

- Other work related to OpenPGP may be entertained by the working group
as long as it does not interfere with the completion of the RFC4880
revision. As the revision of RFC4880 is the primary goal of the working
group, other work may be undertaken, so long as:

1. The work will not unduly delay the closure of the working group after the revision is finished (unless the working group is rechartered).

2. The work has widespread support in the working group.

These additional work items may only be added with approval from the
responsible Area Director or by re-chartering.

Inclusion of CFRG Curves
-----------------------------

The Working Group will consider CFRG curves as possible Mandatory to
Implement (MTI) based on the output of the CFRG and/or Working Group
consensus in the matter.

Working Group Process
--------------------------

The working group will endeavor to complete most if not all of its work
online on the working group's mailing list. We expect that the
requirement for face-to-face sessions at IETF meetings to be minimal.

Furthermore, the working group will accept no ID's as working group ite= ms
unless there is a review by at least two un-interested parties of the ID as part of the acceptance process.


Milestones:
=C2=A0 Sep 2015 - Working Group (rough) consensus on the necessary updates = to
RFC4880.
=C2=A0 Feb 2016 - First wg-id for RFC4880bis
=C2=A0 Jul 2016 - RFC4880bis wg-id final call


_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/= SecDirReview

--001a11c269069519480518a52bdc-- --===============8386657065933354256== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============8386657065933354256==-- From nobody Thu Jun 18 02:47:07 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3031B30E5 for ; Thu, 18 Jun 2015 02:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.768 X-Spam-Level: X-Spam-Status: No, score=0.768 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=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 qYge9BNobq4F for ; Thu, 18 Jun 2015 02:47:04 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 A44A41B30DF for ; Thu, 18 Jun 2015 02:47:03 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t5I9l0fm005689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 18 Jun 2015 12:47:00 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t5I9kxZs017088; Thu, 18 Jun 2015 12:46:59 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21890.37779.532802.433594@fireball.kivinen.iki.fi> Date: Thu, 18 Jun 2015 12:46:59 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 09:47:06 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Klaas Wierenga is next in the rotation. For telechat 2015-06-25 Reviewer LC end Draft Alexey Melnikov T 2015-06-17 draft-ietf-avtcore-rtp-topologies-update-08 Sandy Murphy T 2015-06-12 draft-ietf-manet-olsrv2-management-snapshot-03 Vincent Roca T 2015-06-17 draft-ietf-sipcore-refer-explicit-subscription-02 For telechat 2015-07-09 Matthew Miller T 2015-06-11 draft-ietf-homenet-prefix-assignment-07 Joe Salowey T 2015-06-17 draft-ietf-tzdist-service-08 Robert Sparks T 2015-06-24 draft-ietf-hybi-permessage-compression-22 Takeshi Takahashi T 2015-07-03 draft-ietf-karp-isis-analysis-04 Brian Weis T 2015-06-30 draft-ietf-roll-mpl-parameter-configuration-04 Last calls and special requests: Catherine Meadows 2015-06-09 draft-ietf-dhc-access-network-identifier-08 Yaron Sheffer 2015-06-23 draft-ietf-dnsop-negative-trust-anchors-10 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Hannes Tschofenig 2015-07-07 draft-wkumari-dhc-capport-12 Tina TSOU 2015-06-24 draft-ietf-dane-ops-12 Sean Turner 2015-06-29 draft-ietf-dhc-dhcpv6-active-leasequery-03 Carl Wallace 2015-06-29 draft-ietf-ipsecme-chacha20-poly1305-10 David Waltermire 2015-06-29 draft-ietf-pcp-authentication-11 Sam Weiler 2015-06-29 draft-ietf-pcp-proxy-08 -- kivinen@iki.fi From nobody Thu Jun 18 03:34:03 2015 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEC11B3109; Thu, 18 Jun 2015 03:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1434621779; bh=bogKIAvyy3b/LKd/uWub89LePG3FZpF61KDjMZF05ZQ=; h=To:Date:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=VNKs+RWN4HqkRjEL4qlJfZ8czaJABBN9dcqEJ8N0sh3jHCV6zI6QPQNz8b5VrOVYT SGdh4PN5MviaOEgZeknRmQZW0FzmFNjCcM2qmTssj8F3y87M8YjZNWoCUCilLPkWRD P/hV0enUyPWvB4TlD1YffzyYeObDxxtO1ND9abH4= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24321B3108 for ; Thu, 18 Jun 2015 03:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uI9WYR_Tdl-a for ; Thu, 18 Jun 2015 03:02:54 -0700 (PDT) Received: from jay.w3.org (jay.w3.org [128.30.52.169]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C16E51B3106 for ; Thu, 18 Jun 2015 03:02:54 -0700 (PDT) Received: from eb.bleuazur.com ([88.173.33.195] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Z5Weq-0006JF-Ot; Thu, 18 Jun 2015 06:02:52 -0400 To: new-work@ietf.org Date: Thu, 18 Jun 2015 12:02:51 +0200 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed"; DelSp="yes" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 18 Jun 2015 03:34:02 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: WebRTC Working Group (until 2015-07-19) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 10:02:59 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpc2UgdGhlIFViaXF1aXRvdXMgV2ViIEFwcGxpY2F0aW9u cyBBY3Rpdml0eSBbMF0gKHNlZSB0aGUgVzNDIFByb2Nlc3MKRG9jdW1lbnQgZGVzY3JpcHRpb24g b2YgQWN0aXZpdHkgUHJvcG9zYWxzIFsxXSkuIFRoaXMgcHJvcG9zYWwKaW5jbHVkZXMgYSBkcmFm dCBjaGFydGVyIGZvciB0aGUgV2ViUlRDIFdvcmtpbmcgR3JvdXA6CiAgIGh0dHA6Ly93d3cudzMu b3JnLzIwMTUvMDYvd2VicnRjLWNoYXJ0ZXIuaHRtbAoKQXMgcGFydCBvZiBlbnN1cmluZyB0aGF0 IHRoZSBjb21tdW5pdHkgaXMgYXdhcmUgb2YgcHJvcG9zZWQgd29yawphdCBXM0MsIHRoaXMgZHJh ZnQgY2hhcnRlciBpcyBwdWJsaWMgZHVyaW5nIHRoZSBBZHZpc29yeQpDb21taXR0ZWUgcmV2aWV3 IHBlcmlvZC4KClczQyBpbnZpdGVzIHB1YmxpYyBjb21tZW50cyB0aHJvdWdoIDIwMTUtMDctMTkg b24gdGhlCnByb3Bvc2VkIGNoYXJ0ZXIuIFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvCnB1YmxpYy1u ZXctd29ya0B3My5vcmcsIHdoaWNoIGhhcyBhIHB1YmxpYyBhcmNoaXZlOgogICBodHRwOi8vbGlz dHMudzMub3JnL0FyY2hpdmVzL1B1YmxpYy9wdWJsaWMtbmV3LXdvcmsvCgpPdGhlciB0aGFuIGNv bW1lbnRzIHNlbnQgaW4gZm9ybWFsIHJlc3BvbnNlcyBieSBXM0MgQWR2aXNvcnkKQ29tbWl0dGVl IFJlcHJlc2VudGF0aXZlcywgVzNDIGNhbm5vdCBndWFyYW50ZWUgYSByZXNwb25zZSB0bwpjb21t ZW50cy4gSWYgeW91IHdvcmsgZm9yIGEgVzNDIE1lbWJlciBbMl0sIHBsZWFzZSBjb29yZGluYXRl CnlvdXIgY29tbWVudHMgd2l0aCB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2 ZS4gRm9yCmV4YW1wbGUsIHlvdSBtYXkgd2lzaCB0byBtYWtlIHB1YmxpYyBjb21tZW50cyB2aWEg dGhpcyBsaXN0IGFuZApoYXZlIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZl IHJlZmVyIHRvIGl0IGZyb20gaGlzCm9yIGhlciBmb3JtYWwgcmV2aWV3IGNvbW1lbnRzLgoKSWYg eW91IHNob3VsZCBoYXZlIGFueSBxdWVzdGlvbnMgb3IgbmVlZCBmdXJ0aGVyIGluZm9ybWF0aW9u LCBwbGVhc2UKY29udGFjdCBEb21pbmlxdWUgSGF6YcOrbC1NYXNzaWV1eCAoPGRvbUB3My5vcmc+ KSBvciBWaXZpZW4gTGFjb3VyYmEKKDx2aXZpZW5AdzMub3JnPiksIFRlYW0gQ29udGFjdHMuCgpU aGFuayB5b3UsCgpDb3JhbGllIE1lcmNpZXIsIEFjdGluZyBIZWFkIG9mIFczQyBNYXJrZXRpbmcg JiBDb21tdW5pY2F0aW9ucwoKWzBdIGh0dHA6Ly93d3cudzMub3JnLzIwMDcvdXdhL0FjdGl2aXR5 Lmh0bWwKWzFdIGh0dHA6Ly93d3cudzMub3JnLzIwMTQvUHJvY2Vzcy0yMDE0MDgwMS8jQWN0aXZp dHlDcmVhdGlvbgpbMl0gaHR0cDovL3d3dy53My5vcmcvQ29uc29ydGl1bS9NZW1iZXIvTGlzdAoK LS0gCiAgQ29yYWxpZSBNZXJjaWVyICAtICBXM0MgQ29tbXVuaWNhdGlvbnMgVGVhbSAgLSAgaHR0 cDovL3d3dy53My5vcmcKbWFpbHRvOmNvcmFsaWVAdzMub3JnICszMzYgNDMyMiAwMDAxIGh0dHA6 Ly93d3cudzMub3JnL1Blb3BsZS9DTWVyY2llci8KCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCm5ldy13b3JrIG1haWxpbmcgbGlzdApuZXctd29ya0BpZXRm Lm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldy13b3JrCg== From nobody Fri Jun 19 13:24:39 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0DE1B2A19; Fri, 19 Jun 2015 13:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOQ4CeK3IOlo; Fri, 19 Jun 2015 13:24:34 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c: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 4ABC81B2A16; Fri, 19 Jun 2015 13:24:34 -0700 (PDT) Received: by wgbhy7 with SMTP id hy7so98116412wgb.2; Fri, 19 Jun 2015 13:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=LMoRhoPSAFeI7oGOtxCwpzvnzpjQBo/H/2hfrp7YC4Q=; b=sSXIKFYf5plI7m476NIURmTGd3wbL/WxWTmUr3ggkWnpyO3OUvs+YLlwuZqhF7Ipy4 0HWFldcHs4Jowed8yMGfcD8tVIyfOzoKwEuaP+1LcmMXjHa4AcvZMQJqVXMS0cLvSrQQ EXtIT5pfiqfcg/yItIBsocF8f/U4VLqCczn6udtOhCX5tLUfhzchH7TUZmwk81fdawYH VFLiYdyj36PXk86FWfw06svkzBsoPuvHkkKfTTDxDZB/TfmrpUpZguTjDk9cJK0JVxxl cCRgovdzKg/vn11h2wHUeyY+VIONglh+oAoyItsJ3ktuGUEI14+uSXKnG9OwCVkD94Lt DyRA== X-Received: by 10.180.218.195 with SMTP id pi3mr9876972wic.71.1434745473067; Fri, 19 Jun 2015 13:24:33 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-180-17-102.red.bezeqint.net. [79.180.17.102]) by mx.google.com with ESMTPSA id a19sm5218363wiv.2.2015.06.19.13.24.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jun 2015 13:24:31 -0700 (PDT) Message-ID: <55847A7D.9030504@gmail.com> Date: Fri, 19 Jun 2015 23:24:29 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: IETF Security Directorate , The IESG , draft-ietf-dnsop-negative-trust-anchors.all@tools.ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] SecDir review of draft-ietf-dnsop-negative-trust-anchors-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 20:24:36 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a process where an ISP can declare that certain domain names (whose DNSSEC records are deemed misconfigured) are not covered by DNSSEC. The server then provides DNS resolution in response to client queries, where otherwise the server would have failed those queries. Summary This is more of a rant than a review, however it presents a security perspective that seems to be at odds with the operational-first perspective of the document. Details I am hearing that this is a controversial draft, and I can see why. The draft explains very well what motivates the proposed mechanism, and the motivation makes sense, especially if you are an ISP. But I think the draft gives excellent instructions on improving the security of an inherently problematic usage model. As an individual or even as a company, the local ISP is not my friend. State-controlled ISPs in less developed countries have been known to steal traffic and fake certificates in order to attack their own subscribers. Commercial ISPs in more developed countries throttle or block certain types of traffic for various reasons. Moreover, the local ISP is best positioned to identify the owner of individual IP endpoints and perform point attacks on local subscribers. DNS is an obvious attack vector. Even assuming that 99.9% of us will continue to trust ISPs for DNS resolution, IMHO the proposed solution would be better off with more automation and less celebration of "trained technical personnel". For example, the document has a SHOULD level requirement to test the NTA "periodically" in order to eventually remove it. How about an alternative that shifts the responsibility to DevOps or to the actual vendors, and also empowers the .1% who maintain their own resolvers: "NTA implementors MUST attempt to validate the domain in question once every MINUTE for the period of time that the Negative Trust Anchor is in place, until such validation is again successful, and MUST remove the NTA as soon as that happens." Similarly, I would guess the process of establishing an NTA could be automated, e.g. by querying multiple major DNS operators over a period of time (maybe operators that are known to run the same brand of resolver). In general, automating the process is more likely to encourage deployment of DNSSEC by smaller ISPs than adding complex manual "best practices". Thanks, Yaron From nobody Mon Jun 22 06:37:47 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47581A8BC5; Mon, 22 Jun 2015 06:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5cLPrazJG81; Mon, 22 Jun 2015 06:37:39 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C8691A8BC0; Mon, 22 Jun 2015 06:37:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,659,1427752800"; d="asc'?scan'208,217";a="166651881" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jun 2015 15:37:37 +0200 From: Vincent Roca X-Pgp-Agent: GPGMail 2.5 Content-Type: multipart/signed; boundary="Apple-Mail=_61DF978C-2F24-4292-BF02-C2E9976DA43D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Mon, 22 Jun 2015 15:37:36 +0200 Message-Id: <2E90B73E-0309-4C49-B208-C2E30A0B6B22@inria.fr> To: IESG , secdir@ietf.org, draft-ietf-sipcore-refer-explicit-subscription@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [secdir] Secdir review of draft-ietf-sipcore-refer-explicit-subscription-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 13:37:44 -0000 --Apple-Mail=_61DF978C-2F24-4292-BF02-C2E9976DA43D Content-Type: multipart/alternative; boundary="Apple-Mail=_BFC8F87D-B4D8-4500-B9E3-F1507F73DF70" --Apple-Mail=_BFC8F87D-B4D8-4500-B9E3-F1507F73DF70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, I have reviewed this document as part of the security directorate=E2=80=99= s ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments = just like any other last call comments. Summary: almost ready I have several questions and suggestions WRT the Security Section. It is said that: =C2=AB With this update, there may multiple subscribers = to any given refer event state." So what? What are the implications from a security point of view? IMHO, the third paragraph does not make an appropriate use of the = normative vocabulary. For instance, it is said: "the URI should be constructed so that it is not easy to guess, = and should be protected against eavesdroppers" Shouldn=E2=80=99t the author use =C2=AB SHOULD =C2=BB on both occasions? The following sentence is ambiguous. It says: "For instance, SIP messages containing this URI SHOULD be sent = using TLS or DTLS..." "SHOULD" and "For instance" are contradictory. I suggest removing "For = instance". Similarly, next sentence says: "can redirect". I think "SHOULD" redirect = is more appropriate. Finally the same remark (i.e. use =C2=AB SHOULD") can be done for the = next two sentences about additional authorization mechanisms. In the 4th paragraph, it is not clear to me why it is said that there is = =C2=AB a factor of 11 amplification due to retransmissions of the request =C2=BB. What are the foundations for this =C2=AB 11 =C2=BB = factor? And what happens if the victim is SIP aware? Additionally, I have concerns about backward compatibility. The mechanisms introduced by this extension may not be backward = compatible with RFC 3515 (see section 7). However I don=E2=80=99t see any discussion in the current document. There are some guidelines in RFC 6656 (8.3.1) concerning the 202 = response code, but what is described in the first paragraph is new to this document. Typo, section 8: =C2=AB be =C2=BB is missing in the following sentence: =C2=AB With this update, there may multiple subscribers to any = given refer event state." Cheers, Vincent --Apple-Mail=_BFC8F87D-B4D8-4500-B9E3-F1507F73DF70 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

I have reviewed this document as part of the = security directorate=E2=80=99s ongoing
effort to review = all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the = security area
directors.  Document editors and WG = chairs should treat these comments just
like any other = last call comments.


Summary: almost = ready

I have several questions = and suggestions WRT the Security Section.

It is = said that: =C2=AB With this update, there may multiple subscribers to = any given refer event state."
So what? What are the = implications from a security point of view?


IMHO, the third paragraph does not make an appropriate use of = the normative vocabulary.
For instance, it is = said: 
"the URI should be constructed so = that it is not easy to guess, and should be protected against = eavesdroppers"
Shouldn=E2=80=99t the author use = =C2=AB SHOULD =C2=BB on both occasions?
The= following sentence is ambiguous. It says:
"For = instance, SIP messages containing this URI SHOULD be sent using TLS or = DTLS..."
"SHOULD" and "For instance" are = contradictory. I suggest removing "For instance".
Similarly, next sentence says: "can redirect". I think = "SHOULD" redirect is more appropriate.
Finally the = same remark (i.e. use =C2=AB SHOULD") can be done for the next two = sentences about additional authorization
mechanisms.


In the 4th paragraph, it = is not clear to me why it is said that there is =C2=AB a factor of = 11 amplification due to retransmissions
of the = request =C2=BB. What are the foundations for this = =C2=AB 11 =C2=BB factor? And what happens if the victim is SIP = aware?



Additionally, I have concerns about backward = compatibility.
The mechanisms introduced by = this extension may not be backward compatible with RFC 3515 (see section = 7).
However I don=E2=80=99t see any discussion in = the current document.
There are some guidelines in = RFC 6656 (8.3.1) concerning the 202 response code, but what is described = in the first
paragraph is new to this = document.


Typo, section 8: =C2=AB be =C2=BB= is missing in the following sentence:
= =C2=AB With this update, there may multiple subscribers to = any given refer event state."


Cheers,

   Vincent
= --Apple-Mail=_BFC8F87D-B4D8-4500-B9E3-F1507F73DF70-- --Apple-Mail=_61DF978C-2F24-4292-BF02-C2E9976DA43D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJViA+gAAoJEHBYw8t72N4rKhMQALSfazGnFBiRCeLviaomLLKp J2C5hSA1hD6rTYIWHdcVxYZ36KelG+c2mtOabb9Ep4BnupFA7PyqA2HalOjXTGUi DwMh8ca2XQ5KCm2gbfa+IPa8RmIF4ZqolJ/riCb+TLENYxnvQ1joa07NOOEoheJr xAkqyDBxcksXB1WKjVl4TVAXjHPr5ehlXANaLnzFS9s5V0R7pHuLA+IADcgEz/pV 7p1v7BXSDlUT3ShwN7u+G98WmR6nOBe6ZSaiv6SGRwrepKKHH3FdQ4GBMtN4ZYs4 94id23gHmqQqSISL+Rltn2YQ8MYCiMj/6VBJfTC/8jDewuJx+w4GgoD+ejfALxjY 0dFkAOWyv6sR6gJq1yuFX5Z5YAacgYT/H6ChOCkNKpDB9taTPRXG3S2T/LZVEvXn 8fEcFitBca7wB6NOTG7LXSIgEd6mf40Q/lS3iZbpfC83IFdp1Do04C2gl7jbp2J4 U8JMzN+GqDuGcHiJgYwYgJR5/BNazZmf1cGqgNEqB0JRuIjFzIRCb27NBWXpBj/s JdatpoE9hb3/BxO17u04UvaytHIeAbwd/v5gUSLecoCxxi5q86JhUe4SVB4yRjps 5uZek2WXJ5TznVvi/CLzeE3Izzdg2B0TCOVryS4Om5xQKNh9nhYlFdHn/AMzr0KE 2yOi7di5I8SjDQLQSAIZ =MdvI -----END PGP SIGNATURE----- --Apple-Mail=_61DF978C-2F24-4292-BF02-C2E9976DA43D-- From nobody Mon Jun 22 08:35:00 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1EB1A87A6; Mon, 22 Jun 2015 08:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Zs-6ZH3LITg; Mon, 22 Jun 2015 08:34:54 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B181A802A; Mon, 22 Jun 2015 08:34:53 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5MFYq9l034472 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Mon, 22 Jun 2015 10:34:53 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <55882B17.5010207@nostrum.com> Date: Mon, 22 Jun 2015 10:34:47 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Vincent Roca , IESG , secdir@ietf.org, draft-ietf-sipcore-refer-explicit-subscription@tools.ietf.org References: <2E90B73E-0309-4C49-B208-C2E30A0B6B22@inria.fr> In-Reply-To: <2E90B73E-0309-4C49-B208-C2E30A0B6B22@inria.fr> Content-Type: multipart/alternative; boundary="------------030002040501090805070208" Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-sipcore-refer-explicit-subscription-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 15:34:57 -0000 This is a multi-part message in MIME format. --------------030002040501090805070208 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks Vincent - Responses inline: On 6/22/15 8:37 AM, Vincent Roca wrote: > Hello, > > I have reviewed this document as part of the security directorate’s > ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments > just > like any other last call comments. > > > *Summary: almost ready* > > I have several questions and suggestions WRT the *Security Section*. > > It is said that: « With this update, there may multiple subscribers to > any given refer event state." > So what? What are the implications from a security point of view? Hmm. I wonder if sentence order made this less clear than it should have been? The paragraph that sentence appears in discusses exactly what the implications are - specifically that there is a new authorization consideration. The paragraph that follow talks about how we deal with having that new consideration. > > > IMHO, the third paragraph does not make an appropriate use of the > normative vocabulary. > For instance, it is said: > "the URI should be constructed so that it is not easy to guess, and > should be protected against eavesdroppers" > Shouldn’t the author use « SHOULD » on both occasions? > The following sentence is ambiguous. It says: > "For instance, SIP messages containing this URI SHOULD be sent using > TLS or DTLS..." > "SHOULD" and "For instance" are contradictory. I suggest removing "For > instance". > Similarly, next sentence says: "can redirect". I think "SHOULD" > redirect is more appropriate. > Finally the same remark (i.e. use « SHOULD") can be done for the next > two sentences about additional authorization > mechanisms. Ben made a similar comment. The first 2119 requirement you point to needs to move up into the protocol definition part of the document. The second is restating text that's in RFC3261, and we don't need to repeat the 2119 here - I'll clarify the language to say "use the mechanisms the base specification provides". > > > In the 4th paragraph, it is not clear to me why it is said that there > is « a factor of 11 amplification due to retransmissions > of the request ». What are the foundations for this « 11 » factor? This is base SIP behavior. The non-INVITE transaction state machine retransmits 11 times before giving up if something on the other end doesn't talk back (which is what will happen if the other endpoint is not SIP aware). > And what happens if the victim is SIP aware? It will send an appropriate response, so there won't be the retransmissions of the request. In other words, sending this as raw traffic towards a sip aware element is no different than sending any other sip request towards a sip aware element. > > > > Additionally, I have concerns about *backward compatibility*. > The mechanisms introduced by this extension may not be backward > compatible with RFC 3515 (see section 7). > However I don’t see any discussion in the current document. > There are some guidelines in RFC 6656 (8.3.1) concerning the 202 > response code, but what is described in the first > paragraph is new to this document. > > > Typo, section 8: « be » is missing in the following sentence: > « With this update, there may multiple subscribers to any given refer > event state." > > > Cheers, > > Vincent --------------030002040501090805070208 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Thanks Vincent -

Responses inline:

On 6/22/15 8:37 AM, Vincent Roca wrote:
Hello,

I have reviewed this document as part of the security directorate’s ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.


Summary: almost ready

I have several questions and suggestions WRT the Security Section.

It is said that: « With this update, there may multiple subscribers to any given refer event state."
So what? What are the implications from a security point of view?
Hmm. I wonder if sentence order made this less clear than it should have been?

The paragraph that sentence appears in discusses exactly what the implications are - specifically that there is a new authorization consideration.
The paragraph that follow talks about how we deal with having that new consideration.



IMHO, the third paragraph does not make an appropriate use of the normative vocabulary.
For instance, it is said: 
"the URI should be constructed so that it is not easy to guess, and should be protected against eavesdroppers"
Shouldn’t the author use « SHOULD » on both occasions?
The following sentence is ambiguous. It says:
"For instance, SIP messages containing this URI SHOULD be sent using TLS or DTLS..."
"SHOULD" and "For instance" are contradictory. I suggest removing "For instance".
Similarly, next sentence says: "can redirect". I think "SHOULD" redirect is more appropriate.
Finally the same remark (i.e. use « SHOULD") can be done for the next two sentences about additional authorization
mechanisms.
Ben made a similar comment. The first 2119 requirement you point to needs to move up into the protocol definition part of the document.
The second is restating text that's in RFC3261, and we don't need to repeat the 2119 here - I'll clarify the language to say "use the mechanisms the base specification provides".



In the 4th paragraph, it is not clear to me why it is said that there is « a factor of 11 amplification due to retransmissions
of the request ». What are the foundations for this « 11 » factor?
This is base SIP behavior. The non-INVITE transaction state machine retransmits 11 times before giving up if something on the other end doesn't talk back
(which is what will happen if the other endpoint is not SIP aware).
And what happens if the victim is SIP aware?
It will send an appropriate response, so there won't be the retransmissions of the request. In other words, sending this as raw traffic towards a sip aware element is no different than sending any other sip request towards a sip aware element.



Additionally, I have concerns about backward compatibility.
The mechanisms introduced by this extension may not be backward compatible with RFC 3515 (see section 7).
However I don’t see any discussion in the current document.
There are some guidelines in RFC 6656 (8.3.1) concerning the 202 response code, but what is described in the first
paragraph is new to this document.


Typo, section 8: « be » is missing in the following sentence:
« With this update, there may multiple subscribers to any given refer event state."


Cheers,

   Vincent

--------------030002040501090805070208-- From nobody Mon Jun 22 08:43:46 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE151B2B20; Mon, 22 Jun 2015 08:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhKStRgukr2f; Mon, 22 Jun 2015 08:43:42 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC2451B2F78; Mon, 22 Jun 2015 08:43:42 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5MFhfrN035331 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Mon, 22 Jun 2015 10:43:41 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <55882D28.3020701@nostrum.com> Date: Mon, 22 Jun 2015 10:43:36 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Vincent Roca , IESG , secdir@ietf.org, draft-ietf-sipcore-refer-explicit-subscription@tools.ietf.org References: <2E90B73E-0309-4C49-B208-C2E30A0B6B22@inria.fr> In-Reply-To: <2E90B73E-0309-4C49-B208-C2E30A0B6B22@inria.fr> Content-Type: multipart/alternative; boundary="------------090300070304050105040508" Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-sipcore-refer-explicit-subscription-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 15:43:45 -0000 This is a multi-part message in MIME format. --------------090300070304050105040508 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit (I hit send too soon - the rest of the responses are inline) On 6/22/15 8:37 AM, Vincent Roca wrote: > Hello, > > I have reviewed this document as part of the security directorates > ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments > just > like any other last call comments. > > > *Summary: almost ready* > > I have several questions and suggestions WRT the *Security Section*. > > It is said that: With this update, there may multiple subscribers to > any given refer event state." > So what? What are the implications from a security point of view? > > > IMHO, the third paragraph does not make an appropriate use of the > normative vocabulary. > For instance, it is said: > "the URI should be constructed so that it is not easy to guess, and > should be protected against eavesdroppers" > Shouldnt the author use SHOULD on both occasions? > The following sentence is ambiguous. It says: > "For instance, SIP messages containing this URI SHOULD be sent using > TLS or DTLS..." > "SHOULD" and "For instance" are contradictory. I suggest removing "For > instance". > Similarly, next sentence says: "can redirect". I think "SHOULD" > redirect is more appropriate. > Finally the same remark (i.e. use SHOULD") can be done for the next > two sentences about additional authorization > mechanisms. > > > In the 4th paragraph, it is not clear to me why it is said that there > is a factor of 11 amplification due to retransmissions > of the request . What are the foundations for this 11 factor? And > what happens if the victim is SIP aware? > > starting here - see the previous response for everything above. > > Additionally, I have concerns about *backward compatibility*. > The mechanisms introduced by this extension may not be backward > compatible with RFC 3515 (see section 7). > However I dont see any discussion in the current document. > There are some guidelines in RFC 6656 (8.3.1) concerning the 202 > response code, but what is described in the first > paragraph is new to this document. Our AD already noted that the second paragraph should actually be removed from this document - it is covered in refer-clarifications. For the first paragraph - backwards compatibility is ensured by the base SIP extension mechanism. An implementation of 3515 that is not aware of this extension (and the update to 3515 established by this document) would reject any requests that tried to invoke the extension (if either of the tokens defined here appeared in a Require: header field, that implementation would reject them with a 420 response. > > > Typo, section 8: be is missing in the following sentence: > With this update, there may multiple subscribers to any given refer > event state." ack. > > > Cheers, > > Vincent > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --------------090300070304050105040508 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit (I hit send too soon - the rest of the responses are inline)

On 6/22/15 8:37 AM, Vincent Roca wrote:
Hello,

I have reviewed this document as part of the security directorates ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors. Document editors and WG chairs should treat these comments just
like any other last call comments.


Summary: almost ready

I have several questions and suggestions WRT the Security Section.

It is said that: With this update, there may multiple subscribers to any given refer event state."
So what? What are the implications from a security point of view?


IMHO, the third paragraph does not make an appropriate use of the normative vocabulary.
For instance, it is said:
"the URI should be constructed so that it is not easy to guess, and should be protected against eavesdroppers"
Shouldnt the author use SHOULD on both occasions?
The following sentence is ambiguous. It says:
"For instance, SIP messages containing this URI SHOULD be sent using TLS or DTLS..."
"SHOULD" and "For instance" are contradictory. I suggest removing "For instance".
Similarly, next sentence says: "can redirect". I think "SHOULD" redirect is more appropriate.
Finally the same remark (i.e. use SHOULD") can be done for the next two sentences about additional authorization
mechanisms.


In the 4th paragraph, it is not clear to me why it is said that there is a factor of 11 amplification due to retransmissions
of the request. What are the foundations for this 11 factor? And what happens if the victim is SIP aware?


starting here - see the previous response for everything above.

Additionally, I have concerns about backward compatibility.
The mechanisms introduced by this extension may not be backward compatible with RFC 3515 (see section 7).
However I dont see any discussion in the current document.
There are some guidelines in RFC 6656 (8.3.1) concerning the 202 response code, but what is described in the first
paragraph is new to this document.
Our AD already noted that the second paragraph should actually be removed from this document - it is covered in refer-clarifications.

For the first paragraph - backwards compatibility is ensured by the base SIP extension mechanism.
An implementation of 3515 that is not aware of this extension (and the update to 3515 established by this document) would reject any requests that tried to invoke the extension (if either of the tokens defined here appeared in a Require: header field, that implementation would reject them with a 420 response.


Typo, section 8: be is missing in the following sentence:
With this update, there may multiple subscribers to any given refer event state."
ack.


Cheers,

Vincent


_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

--------------090300070304050105040508-- From nobody Mon Jun 22 12:19:18 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0341A88B1; Mon, 22 Jun 2015 12:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPKv48T2JRXB; Mon, 22 Jun 2015 12:19:09 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0729.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:729]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36BF91A88AD; Mon, 22 Jun 2015 12:19:09 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.195.6; Mon, 22 Jun 2015 19:18:52 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0195.005; Mon, 22 Jun 2015 19:18:52 +0000 From: Mike Jones To: "Adam W. Montville" Thread-Topic: sector review of draft-ietf-jose-jwk-thumbprint-05 Thread-Index: AQHQogJgaphBjlti2Uu758g0GQEF3p2nztYwgAD9kwCAEC+K8A== Date: Mon, 22 Jun 2015 19:18:52 +0000 Message-ID: References: <4CA0A65D-E5FD-408C-A6B9-6ECB12A81B7C@gmail.com> In-Reply-To: <4CA0A65D-E5FD-408C-A6B9-6ECB12A81B7C@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e0:ed43::2] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:uqxBae95mxvGx8VjiX4EFWQ7GVby6dPUttkNyOC8OGL0HyrZbLJ7xSVtllZfc/tLzDcpnMrWCJWvxeCw3QmYxgwZ2Q1vDXYJA7ktm9zP98qeL+iWu9gOYn8eelSXxEB0dVDE7hvUOWluQN4YwjsayA==; 24:I4gf/cmEv6AHTk/3XeYYCdQbNa45BM5LoL9FSBeGZtjfN8CypDNt6gDr96CxIEhAHgQpyA5p6GFbDg7Vw2APgLfux+smEVYrvpFVdVOxsjc=; 20:v2dlgEVHotgtpgiUiNq3zZqtG+t0Ha8hRObAHvSKd4dk4VX3StXYuNxaggg+5MVNraB0CUcWL/49gtBMV4f+CA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 06157D541C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(71364002)(51914003)(99286002)(5001960100002)(33656002)(19625215002)(110136002)(86362001)(5002640100001)(62966003)(106116001)(77156002)(92566002)(189998001)(230783001)(19617315012)(19580395003)(5003600100002)(46102003)(74316001)(76576001)(122556002)(50986999)(54356999)(40100003)(87936001)(15975445007)(77096005)(102836002)(19580405001)(2656002)(19300405004)(2900100001)(76176999)(2950100001)(86612001)(16236675004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB44292335834F3354309E062F5A10BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2015 19:18:52.5573 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Cc: "draft-ietf-jose-jwk-thumbprint.all@ietf.org" , The IESG , "jose@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] sector review of draft-ietf-jose-jwk-thumbprint-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 19:19:12 -0000 --_000_BY2PR03MB44292335834F3354309E062F5A10BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmWQgYmUgZ2xhZCB0byBhZGQgdGhlIGV4cGxhbmF0aW9uIGJlbG93IHRvIHRoZSBkcmFmdCBh bmQgdG8gYWxzbyBpbmNsdWRlIGFuIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiB0aGF0IHN0 YXRlcyB3ZSBhcmUgdXBkYXRpbmcgdGhlIGV4cGVydCByZXZpZXcgaW5zdHJ1Y3Rpb25zIGZvciBh IHJlZ2lzdHJ5LCBhcyBKaW0gU2NoYWFkIGhhZCBzdWdnZXN0ZWQuICBDaGFpcnMgYW5kIEthdGhs ZWVuLCBkbyB5b3Ugd2FudCBOYXQgYW5kIEkgdG8gcHJvY2VlZCB0byBwdWJsaXNoIGFuIHVwZGF0 ZWQgZHJhZnQ/DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IEFkYW0gVy4gTW9udHZpbGxlIFtt YWlsdG86YWRhbS53Lm1vbnR2aWxsZUBnbWFpbC5jb21dDQpTZW50OiBGcmlkYXksIEp1bmUgMTIs IDIwMTUgNTowNyBBTQ0KVG86IE1pa2UgSm9uZXMNCkNjOiBUaGUgSUVTRzsgc2VjZGlyQGlldGYu b3JnOyBkcmFmdC1pZXRmLWpvc2UtandrLXRodW1icHJpbnQuYWxsQGlldGYub3JnOyBqb3NlQGll dGYub3JnDQpTdWJqZWN0OiBSZTogc2VjdG9yIHJldmlldyBvZiBkcmFmdC1pZXRmLWpvc2Utandr LXRodW1icHJpbnQtMDUNCg0KDQpPbiBKdW4gMTEsIDIwMTUsIGF0IDQ6MjUgUE0sIE1pa2UgSm9u ZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tPj4gd3JvdGU6DQoNCkhpIEFkYW0sDQoNClRoYW5rcyBmb3IgdGhlIHNlY2RpciBy ZXZpZXcuDQoNCg0KRnJvbTogQWRhbSBXLiBNb250dmlsbGUgW21haWx0bzphZGFtLncubW9udHZp bGxlQGdtYWlsLmNvbV0NClNlbnQ6IE1vbmRheSwgSnVuZSAwOCwgMjAxNSA4OjQ2IEFNDQpUbzog VGhlIElFU0c7IHNlY2RpckBpZXRmLm9yZzxtYWlsdG86c2VjZGlyQGlldGYub3JnPjsgZHJhZnQt aWV0Zi1qb3NlLWp3ay10aHVtYnByaW50LmFsbEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1q b3NlLWp3ay10aHVtYnByaW50LmFsbEBpZXRmLm9yZz4NClN1YmplY3Q6IHNlY3RvciByZXZpZXcg b2YgZHJhZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnByaW50LTA1DQoNCg0KSGksDQoNCg0KSSBoYXZl IHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3Jh dGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHBy b2Nlc3NlZCBieSB0aGUgSUVTRy4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmls eSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiBEb2N1bWVu dCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3Qg bGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpJIGJlbGlldmUgdGhlIGRvY3Vt ZW50IGlzIHJlYWR5IHdpdGggKHBvdGVudGlhbCkgaXNzdWVzLiAgVGhlIOKAnHdpdGggaXNzdWVz 4oCdIG1pZ2h0IGJlIGR1ZSB0byBpZ25vcmFuY2Ugb24gbXkgcGFydC4gIFRoZSBkcmFmdCBkb2Vz IGEgdmVyeSBnb29kIGpvYiBvZiBleHBsYWluaW5nIHRoZSBjYW5vbmljYWwgZm9ybSBvZiBhIEpT T04gV2ViIEtleSB0aGF0IGNhbiBiZSB1c2VkIGZvciBlc3RhYmxpc2hpbmcgYSB0aHVtYnByaW50 IHVuZGVyIHZhcnlpbmcgY2lyY3Vtc3RhbmNlcywgY29tcGxldGUgd2l0aCB3aGF0IEkgZm91bmQg dG8gYmUgaGVscGZ1bCBleGFtcGxlcy4NCg0KVGhlIHByaW1hcnkgaXNzdWUgSSBoYXZlIGlzIHRo YXQgaXTigJlzIHVuY2xlYXIgaG93IHJlbHlpbmcgcGFydGllcyBhcmUgZ29pbmcgdG8ga25vdyB3 aGljaCBoYXNoIGFsZ29yaXRobSBoYXMgYmVlbiB1c2VkLiAgVGhlIGV4YW1wbGVzIHVzZSBTSEEt MjU2LCBidXQgSeKAmW0gbm90IHNlZWluZyB3aGVyZSBTSEEtMjU2IG1pZ2h0IGJlIHNwZWNpZmll ZCBhcyBhIE1VU1Qgb3IgZXZlbiBhIFNIT1VMRC4gIE1vcmVvdmVyLCB0aGUgZXhhbXBsZSBvdXRw dXQgdWx0aW1hdGVseSBzaG93cyBvbmx5IHRoZSBCYXNlLTY0IGVuY29kaW5nIG9mIHRoZSByZXN1 bHRpbmcgaGFzaCwgd2hpY2ggc2F5cyBub3RoaW5nIGFib3V0IHRoZSBhbGdvcml0aG0gdXNlZCB0 byBpZGVudGlmeSBhIGtleS4NCg0KRWFybGllciBkcmFmdHMgaGFkIGluY2x1ZGVkIGZpZWxkcyB3 aG9zZSBuYW1lcyB3ZXJlIGludGVuZGVkIHRvIGNvbW11bmljYXRlIHRoZSBpbmZvcm1hdGlvbiBh Ym91dCB0aGUgaGFzaCBmdW5jdGlvbiB1c2VkIC0gc2VlIHRoZSAiamt0IiBmaWVsZCBkZWZpbml0 aW9ucyBpbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtandrLXRo dW1icHJpbnQtMDEjc2VjdGlvbi00IC0gYnV0IHNldmVyYWwgd29ya2luZyBncm91cCByZXZpZXdl cnMgc3VnZ2VzdGVkIHRoYXQgdGhlc2UgZmllbGRzIHdlcmUgdW5uZWNlc3NhcnkgYW5kIHRoYXQg dGhlIHR5cGljYWwgdXNhZ2Ugd291bGQgYmUgYXMgImtpZCIgKGtleSBJRCkgZmllbGQgdmFsdWVz LiAgV2l0aCB0aGF0IHJlbW92YWwsIGl0IGZhbGxzIG9udG8gdGhlIGFwcGxpY2F0aW9uIHRvIHNw ZWNpZnkgdGhlIGhhc2ggYWxnb3JpdGhtIGZvciBpdHMgcGFydGljdWxhciB1c2FnZS4NCg0KVGhp cyBpc24ndCBhcyBiYWQgYXMgeW91IG1pZ2h0IHRoaW5rLCBob3dldmVyLCBiZWNhdXNlIHR5cGlj YWxseSB0aGUgY29uc3VtZXIgb2YgdGhlICJraWQiIGRvZXNuJ3QgbmVlZCB0byBrbm93IHRoZSBh bGdvcml0aG0gYmVjYXVzZSBpdCB3b24ndCBiZSByZXByb2R1Y2luZyB0aGUgY29tcHV0YXRpb24u ICBJdCBqdXN0IHJlbGllcyBvbiB0aGUgZmFjdCB0aGF0IGEgdW5pcXVlIGtleSBJRCB2YWx1ZSB3 YXMgZ2VuZXJhdGVkIGZvciB0aGUga2V5IGFuZCBjb21wYXJlcyAia2lkIiB2YWx1ZXMgYXMgb3Bh cXVlIHN0cmluZ3MgdG8gZmluZCB0aGUgYXBwcm9wcmlhdGUga2V5LiAgSW4gdGhpcyB1c2FnZSwg dGhlIHByb2R1Y2VyIG9mIHRoZSBrZXkgaXMgdGhlIG9ubHkgcGFydHkgdGhhdCBuZWVkcyB0byBr bm93IHRoZSBoYXNoIGFsZ29yaXRobSB0aGF0IGl0IGlzIHVzaW5nLiAgSSBob3BlIHRoaXMgaGVs cHMuDQoNClllcywgdGhpcyBkb2VzIGhlbHAsIHRoYW5rIHlvdS4gIEl0IHNlZW1zIGxpa2Ugc29t ZXRoaW5nIHRoYXQgY291bGQgYmUgZWFzaWx5IGFkZGVkIHRvIHRoZSBkcmFmdCB0byBleHBsYWlu IHdoeSB0aGUgZ2VuZXJhdGluZyBhbGdvcml0aG0gbmVlZG7igJl0IGJlIGRpc2Nsb3NlZCBzbyB0 aGF0IHNsb3cgZm9sayBsaWtlIG15c2VsZiBnZXQgdGhlIHBpY3R1cmUgc3RyYWlnaHQgYXdheS4N Cg0KDQoNCg0KDQpBZGRpdGlvbmFsbHksIGluIFNlY3Rpb24gNCwg4oCcSlNPTiBhbmQgVW5pY29k ZSBDb25zaWRlcmF0aW9uc+KAnSBzb21lIOKAnHNob3VsZOKAnXMgYXJlIHVzZWQsIGJ1dCBJ4oCZ bSBub3QgcmVhZGluZyB0aGVtIGFzIFNIT1VMRHMuIFNob3VsZCB0aGV5IGJlIFNIT1VMRHM/ICBG b3IgZXhhbXBsZSwgdGhlIHN0YXJ0IG9mIHRoZSB0aGlyZCBwYXJhZ3JhcGggaW4gdGhhdCBzZWN0 aW9uOiDigJxpZiBuZXcgSldLIG1lbWJlcnMgYXJlIGRlZmluZWQgdGhhdCB1c2Ugbm9uLUFTQ0lJ IG1lbWJlciBuYW1lcywgdGhlaXIgZGVmaW5pdGlvbnMgc2hvdWxkIHNwZWNpZnkgdGhlIGV4YWN0 IFVuaWNvZGUgY29kZSBwb2ludCBzZXF1ZW5jZXMgdXNlZCB0byByZXByZXNlbnQgdGhlbS7igJ0g IEl04oCZcyBub3QgY2xlYXIgdG8gbWUgd2hldGhlciB0aGlzIGlzIGEgc3Ryb25nIHN0YXRlbWVu dCBvciBqdXN0IGEgcmVjb21tZW5kYXRpb24gLSBpdCBzZWVtcyB0aGF0IHRoaXMgZHJhZnQgY291 bGQgaGVscCB0aGUgZnV0dXJlIGJ5IG1ha2luZyBzdHJvbmdlciBzdGF0ZW1lbnRzIHRvIGVuY291 cmFnZSBmdXR1cmUgaW50ZXJvcGVyYWJpbGl0eS4NCg0KRm9yIHRoZSBvdGhlciBKT1NFIHNwZWNp ZmljYXRpb25zLCBvdXIgY2hhaXIgSmltIFNjaGFhZCB0b29rIHRoZSBwb3NpdGlvbiB0aGF0IFJG QyAyMTE5IGtleXdvcmRzIHNob3VsZCBiZSByZXNlcnZlZCBmb3IgdGVzdGFibGUgcHJvdG9jb2wg YmVoYXZpb3JzIGFuZCB0aGF0IG90aGVyIHVzZXMgb2YgdGhlIEVuZ2xpc2ggd29yZCAic2hvdWxk IiBzaG91bGQgbm90IHVzZSAiU0hPVUxEIi4gIFRoZSBhdXRob3JzIGZvbGxvd2VkIHRoYXQgY29u dmVudGlvbiBpbiB0aGlzIGRvY3VtZW50LiAgSSBkbyB1bmRlcnN0YW5kIHRoYXQgb3RoZXIgYXV0 aG9ycyBhbmQgd29ya2luZyBncm91cHMgaGF2ZSB0YWtlbiBkaWZmZXJlbnQgcG9zaXRpb25zIGlu IHRoaXMgcmVnYXJkLiAgSWYgdGhlcmUgYXJlIHBhcnRpY3VsYXIgdXNlcyB0aGF0IHlvdSBzdGls bCBmZWVsIHNob3VsZCBiZSBjaGFuZ2VkIHRvIHVzZSBSRkMgMjExOSBrZXl3b3JkcywgcGxlYXNl IGNhbGwgdGhlbSBvdXQuDQoNClRoaXMgaXMgYWxsIGdvb2QsIHRvby4gIEkgd2FzIHNpbXBseSBw b2ludGluZyBvdXQgdGhhdCB0aGVyZSBhcmUg4oCcc2hvdWxk4oCdcyBhcm91bmQgdGhhdCBtYXkg bmVlZCB0byBiZSBjb25zaWRlcmVkIGFzIOKAnFNIT1VMROKAnXMuIEkgYWxzbyBzZWUgSmlt4oCZ cyAoYW5kIG90aGVyc+KAmSkgc3Vic2VxdWVudCBub3RlcyBvbiB0aGUgc3ViamVjdCwgc28gdGhp cyBpcyBnb29kIGZyb20gbXkgcGVyc3BlY3RpdmUuDQoNCg0KDQoNCktpbmQgcmVnYXJkcywNCkFk YW0NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFRoYW5rcyBhZ2FpbiENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCg== --_000_BY2PR03MB44292335834F3354309E062F5A10BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uYXBwbGUtY29udmVy dGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFu LmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4u RW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxv b25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J4oCZZCBiZSBnbGFkIHRvIGFkZCB0aGUgZXhw bGFuYXRpb24gYmVsb3cgdG8gdGhlIGRyYWZ0IGFuZCB0byBhbHNvIGluY2x1ZGUgYW4gSUFOQSBj b25zaWRlcmF0aW9ucyBzZWN0aW9uIHRoYXQgc3RhdGVzIHdlIGFyZSB1cGRhdGluZyB0aGUgZXhw ZXJ0IHJldmlldyBpbnN0cnVjdGlvbnMNCiBmb3IgYSByZWdpc3RyeSwgYXMgSmltIFNjaGFhZCBo YWQgc3VnZ2VzdGVkLiZuYnNwOyBDaGFpcnMgYW5kIEthdGhsZWVuLCBkbyB5b3Ugd2FudCBOYXQg YW5kIEkgdG8gcHJvY2VlZCB0byBwdWJsaXNoIGFuIHVwZGF0ZWQgZHJhZnQ/PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IEFkYW0gVy4gTW9udHZpbGxlIFttYWlsdG86YWRhbS53Lm1vbnR2aWxsZUBnbWFpbC5j b21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdW5lIDEyLCAyMDE1IDU6MDcgQU08YnI+ DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM8YnI+DQo8Yj5DYzo8L2I+IFRoZSBJRVNHOyBzZWNkaXJA aWV0Zi5vcmc7IGRyYWZ0LWlldGYtam9zZS1qd2stdGh1bWJwcmludC5hbGxAaWV0Zi5vcmc7IGpv c2VAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IHNlY3RvciByZXZpZXcgb2YgZHJh ZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnByaW50LTA1PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSnVuIDExLCAyMDE1LCBhdCA0OjI1IFBNLCBNaWtl IEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5N aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGkg QWRhbSw8YnI+DQo8YnI+DQpUaGFua3MgZm9yIHRoZSBzZWNkaXIgcmV2aWV3Ljxicj4NCjxiciBz dHlsZT0ib3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOiBBZGFtIFcuIE1vbnR2aWxsZSBbPGEgaHJlZj0ibWFpbHRvOmFkYW0u dy5tb250dmlsbGVAZ21haWwuY29tIj5tYWlsdG86YWRhbS53Lm1vbnR2aWxsZUBnbWFpbC5jb208 L2E+XTxicj4NClNlbnQ6IE1vbmRheSwgSnVuZSAwOCwgMjAxNSA4OjQ2IEFNPGJyPg0KVG86IFRo ZSBJRVNHOyA8YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIj5zZWNkaXJAaWV0Zi5vcmc8 L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnByaW50LmFsbEBp ZXRmLm9yZyI+DQpkcmFmdC1pZXRmLWpvc2UtandrLXRodW1icHJpbnQuYWxsQGlldGYub3JnPC9h Pjxicj4NClN1YmplY3Q6IHNlY3RvciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1qb3NlLWp3ay10aHVt YnByaW50LTA1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyIHN0eWxlPSJvcnBoYW5zOiBhdXRvO3RleHQt YWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3 b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhpLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxiciBzdHlsZT0ib3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czog YXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8 YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBw YXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmll dyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiBUaGVzZSBj b21tZW50cyB3ZXJlIHdyaXR0ZW4NCiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBz ZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNo b3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBj b21tZW50cy48YnI+DQo8YnI+DQpJIGJlbGlldmUgdGhlIGRvY3VtZW50IGlzIHJlYWR5IHdpdGgg KHBvdGVudGlhbCkgaXNzdWVzLiAmbmJzcDtUaGUg4oCcd2l0aCBpc3N1ZXPigJ0gbWlnaHQgYmUg ZHVlIHRvIGlnbm9yYW5jZSBvbiBteSBwYXJ0LiAmbmJzcDtUaGUgZHJhZnQgZG9lcyBhIHZlcnkg Z29vZCBqb2Igb2YgZXhwbGFpbmluZyB0aGUgY2Fub25pY2FsIGZvcm0gb2YgYSBKU09OIFdlYiBL ZXkgdGhhdCBjYW4gYmUgdXNlZCBmb3IgZXN0YWJsaXNoaW5nIGEgdGh1bWJwcmludCB1bmRlciB2 YXJ5aW5nDQogY2lyY3Vtc3RhbmNlcywgY29tcGxldGUgd2l0aCB3aGF0IEkgZm91bmQgdG8gYmUg aGVscGZ1bCBleGFtcGxlcy48YnI+DQo8YnI+DQpUaGUgcHJpbWFyeSBpc3N1ZSBJIGhhdmUgaXMg dGhhdCBpdOKAmXMgdW5jbGVhciBob3cgcmVseWluZyBwYXJ0aWVzIGFyZSBnb2luZyB0byBrbm93 IHdoaWNoIGhhc2ggYWxnb3JpdGhtIGhhcyBiZWVuIHVzZWQuICZuYnNwO1RoZSBleGFtcGxlcyB1 c2UgU0hBLTI1NiwgYnV0IEnigJltIG5vdCBzZWVpbmcgd2hlcmUgU0hBLTI1NiBtaWdodCBiZSBz cGVjaWZpZWQgYXMgYSBNVVNUIG9yIGV2ZW4gYSBTSE9VTEQuICZuYnNwO01vcmVvdmVyLCB0aGUg ZXhhbXBsZSBvdXRwdXQNCiB1bHRpbWF0ZWx5IHNob3dzIG9ubHkgdGhlIEJhc2UtNjQgZW5jb2Rp bmcgb2YgdGhlIHJlc3VsdGluZyBoYXNoLCB3aGljaCBzYXlzIG5vdGhpbmcgYWJvdXQgdGhlIGFs Z29yaXRobSB1c2VkIHRvIGlkZW50aWZ5IGEga2V5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCkVh cmxpZXIgZHJhZnRzIGhhZCBpbmNsdWRlZCBmaWVsZHMgd2hvc2UgbmFtZXMgd2VyZSBpbnRlbmRl ZCB0byBjb21tdW5pY2F0ZSB0aGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGhhc2ggZnVuY3Rpb24g dXNlZCAtIHNlZSB0aGUgJnF1b3Q7amt0JnF1b3Q7IGZpZWxkIGRlZmluaXRpb25zIGluPHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtandrLXRodW1icHJp bnQtMDEjc2VjdGlvbi00Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtandrLXRodW1icHJpbnQtMDEjc2VjdGlv bi00PC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPi0NCiBidXQgc2V2ZXJhbCB3b3JraW5nIGdyb3VwIHJldmlld2VycyBz dWdnZXN0ZWQgdGhhdCB0aGVzZSBmaWVsZHMgd2VyZSB1bm5lY2Vzc2FyeSBhbmQgdGhhdCB0aGUg dHlwaWNhbCB1c2FnZSB3b3VsZCBiZSBhcyAmcXVvdDtraWQmcXVvdDsgKGtleSBJRCkgZmllbGQg dmFsdWVzLiAmbmJzcDtXaXRoIHRoYXQgcmVtb3ZhbCwgaXQgZmFsbHMgb250byB0aGUgYXBwbGlj YXRpb24gdG8gc3BlY2lmeSB0aGUgaGFzaCBhbGdvcml0aG0gZm9yIGl0cyBwYXJ0aWN1bGFyIHVz YWdlLjxicj4NCjxicj4NClRoaXMgaXNuJ3QgYXMgYmFkIGFzIHlvdSBtaWdodCB0aGluaywgaG93 ZXZlciwgYmVjYXVzZSB0eXBpY2FsbHkgdGhlIGNvbnN1bWVyIG9mIHRoZSAmcXVvdDtraWQmcXVv dDsgZG9lc24ndCBuZWVkIHRvIGtub3cgdGhlIGFsZ29yaXRobSBiZWNhdXNlIGl0IHdvbid0IGJl IHJlcHJvZHVjaW5nIHRoZSBjb21wdXRhdGlvbi4gJm5ic3A7SXQganVzdCByZWxpZXMgb24gdGhl IGZhY3QgdGhhdCBhIHVuaXF1ZSBrZXkgSUQgdmFsdWUgd2FzIGdlbmVyYXRlZCBmb3IgdGhlIGtl eSBhbmQNCiBjb21wYXJlcyAmcXVvdDtraWQmcXVvdDsgdmFsdWVzIGFzIG9wYXF1ZSBzdHJpbmdz IHRvIGZpbmQgdGhlIGFwcHJvcHJpYXRlIGtleS4gJm5ic3A7SW4gdGhpcyB1c2FnZSwgdGhlIHBy b2R1Y2VyIG9mIHRoZSBrZXkgaXMgdGhlIG9ubHkgcGFydHkgdGhhdCBuZWVkcyB0byBrbm93IHRo ZSBoYXNoIGFsZ29yaXRobSB0aGF0IGl0IGlzIHVzaW5nLiAmbmJzcDtJIGhvcGUgdGhpcyBoZWxw cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgdGhpcyBkb2VzIGhlbHAsIHRoYW5rIHlvdS4gJm5i c3A7SXQgc2VlbXMgbGlrZSBzb21ldGhpbmcgdGhhdCBjb3VsZCBiZSBlYXNpbHkgYWRkZWQgdG8g dGhlIGRyYWZ0IHRvIGV4cGxhaW4gd2h5IHRoZSBnZW5lcmF0aW5nIGFsZ29yaXRobSBuZWVkbuKA mXQgYmUgZGlzY2xvc2VkIHNvIHRoYXQgc2xvdyBmb2xrIGxpa2UgbXlzZWxmIGdldCB0aGUgcGlj dHVyZSBzdHJhaWdodCBhd2F5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxiciBzdHlsZT0ib3JwaGFu czogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5B ZGRpdGlvbmFsbHksIGluIFNlY3Rpb24gNCwg4oCcSlNPTiBhbmQgVW5pY29kZSBDb25zaWRlcmF0 aW9uc+KAnSBzb21lIOKAnHNob3VsZOKAnXMgYXJlIHVzZWQsIGJ1dCBJ4oCZbSBub3QgcmVhZGlu ZyB0aGVtIGFzIFNIT1VMRHMuIFNob3VsZCB0aGV5IGJlIFNIT1VMRHM/ICZuYnNwO0ZvciBleGFt cGxlLCB0aGUgc3RhcnQNCiBvZiB0aGUgdGhpcmQgcGFyYWdyYXBoIGluIHRoYXQgc2VjdGlvbjog 4oCcaWYgbmV3IEpXSyBtZW1iZXJzIGFyZSBkZWZpbmVkIHRoYXQgdXNlIG5vbi1BU0NJSSBtZW1i ZXIgbmFtZXMsIHRoZWlyIGRlZmluaXRpb25zIHNob3VsZCBzcGVjaWZ5IHRoZSBleGFjdCBVbmlj b2RlIGNvZGUgcG9pbnQgc2VxdWVuY2VzIHVzZWQgdG8gcmVwcmVzZW50IHRoZW0u4oCdICZuYnNw O0l04oCZcyBub3QgY2xlYXIgdG8gbWUgd2hldGhlciB0aGlzIGlzIGEgc3Ryb25nIHN0YXRlbWVu dA0KIG9yIGp1c3QgYSByZWNvbW1lbmRhdGlvbiAtIGl0IHNlZW1zIHRoYXQgdGhpcyBkcmFmdCBj b3VsZCBoZWxwIHRoZSBmdXR1cmUgYnkgbWFraW5nIHN0cm9uZ2VyIHN0YXRlbWVudHMgdG8gZW5j b3VyYWdlIGZ1dHVyZSBpbnRlcm9wZXJhYmlsaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCkZv ciB0aGUgb3RoZXIgSk9TRSBzcGVjaWZpY2F0aW9ucywgb3VyIGNoYWlyIEppbSBTY2hhYWQgdG9v ayB0aGUgcG9zaXRpb24gdGhhdCBSRkMgMjExOSBrZXl3b3JkcyBzaG91bGQgYmUgcmVzZXJ2ZWQg Zm9yIHRlc3RhYmxlIHByb3RvY29sIGJlaGF2aW9ycyBhbmQgdGhhdCBvdGhlciB1c2VzIG9mIHRo ZSBFbmdsaXNoIHdvcmQgJnF1b3Q7c2hvdWxkJnF1b3Q7IHNob3VsZCBub3QgdXNlICZxdW90O1NI T1VMRCZxdW90Oy4gJm5ic3A7VGhlIGF1dGhvcnMgZm9sbG93ZWQgdGhhdCBjb252ZW50aW9uDQog aW4gdGhpcyBkb2N1bWVudC4gJm5ic3A7SSBkbyB1bmRlcnN0YW5kIHRoYXQgb3RoZXIgYXV0aG9y cyBhbmQgd29ya2luZyBncm91cHMgaGF2ZSB0YWtlbiBkaWZmZXJlbnQgcG9zaXRpb25zIGluIHRo aXMgcmVnYXJkLiAmbmJzcDtJZiB0aGVyZSBhcmUgcGFydGljdWxhciB1c2VzIHRoYXQgeW91IHN0 aWxsIGZlZWwgc2hvdWxkIGJlIGNoYW5nZWQgdG8gdXNlIFJGQyAyMTE5IGtleXdvcmRzLCBwbGVh c2UgY2FsbCB0aGVtIG91dC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgYWxsIGdvb2QsIHRvby4gJm5ic3A7SSB3YXMg c2ltcGx5IHBvaW50aW5nIG91dCB0aGF0IHRoZXJlIGFyZSDigJxzaG91bGTigJ1zIGFyb3VuZCB0 aGF0IG1heSBuZWVkIHRvIGJlIGNvbnNpZGVyZWQgYXMg4oCcU0hPVUxE4oCdcy4gSSBhbHNvIHNl ZSBKaW3igJlzIChhbmQgb3RoZXJz4oCZKSBzdWJzZXF1ZW50IG5vdGVzIG9uIHRoZSBzdWJqZWN0 LCBzbyB0aGlzIGlzIGdvb2QgZnJvbSBteSBwZXJzcGVjdGl2ZS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PGJyIHN0eWxlPSJvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPktpbmQgcmVnYXJkcyw8YnI+DQpBZGFtPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj5UaGFua3MgYWdhaW4hPGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj4tLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY2PR03MB44292335834F3354309E062F5A10BY2PR03MB442namprd_-- From nobody Mon Jun 22 12:51:28 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D4C1A882F; Mon, 22 Jun 2015 12:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=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 5rcoKPTROsF8; Mon, 22 Jun 2015 12:51:19 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::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 37B7E1A8822; Mon, 22 Jun 2015 12:51:19 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so86652575wic.1; Mon, 22 Jun 2015 12:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2bqtuw7KuCSxeyEXNZjQPWZCfoa0Ux2XONGfZCwzmNk=; b=RkkM5rWwv028KYHPf2k+QehMVmxEKNbLKzXt1gxDDCba1EjmTovu2whsGH5tFzqucI ZB+f8mjLvybqDukxHzG80MzBxGXGtDBfq3uwLDUC6jAQROBcz/dtY/320wrtSeuWIbft niFkBDy2tN/kbLpV5q84gsxMbZsIPkwuec13u3Y0vgqbdlJWH1v8xwlQLvCZMndEuJE5 Y53YEArlo+4O5grnycYMHpgh+vTyIDN0k2mPwlvy4yM0vudNOoWPCRhyk00+HzUyhn+o ktGb+zdQdlBNpOdpHZTqi/JyQ0PH8F+3lJTV6vyN6JiDm77bPWk6TLhJd/oypc0PKVLQ pA5Q== X-Received: by 10.194.209.130 with SMTP id mm2mr52677321wjc.64.1435002677866; Mon, 22 Jun 2015 12:51:17 -0700 (PDT) Received: from [10.200.6.61] ([46.218.164.216]) by mx.google.com with ESMTPSA id ex5sm18734302wib.2.2015.06.22.12.51.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jun 2015 12:51:17 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-0184946C-494C-4A67-B9E1-24EB2DEAF287 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Mon, 22 Jun 2015 21:51:20 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <4CA0A65D-E5FD-408C-A6B9-6ECB12A81B7C@gmail.com> To: Mike Jones Archived-At: Cc: "draft-ietf-jose-jwk-thumbprint.all@ietf.org" , "secdir@ietf.org" , "jose@ietf.org" , The IESG Subject: Re: [secdir] sector review of draft-ietf-jose-jwk-thumbprint-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 19:51:22 -0000 --Apple-Mail-0184946C-494C-4A67-B9E1-24EB2DEAF287 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes, thank you. Kathleen=20 Sent from my iPhone > On Jun 22, 2015, at 9:18 PM, Mike Jones wrot= e: >=20 > I=E2=80=99d be glad to add the explanation below to the draft and to also i= nclude an IANA considerations section that states we are updating the expert= review instructions for a registry, as Jim Schaad had suggested. Chairs an= d Kathleen, do you want Nat and I to proceed to publish an updated draft? > =20 > -- Mike > =20 > From: Adam W. Montville [mailto:adam.w.montville@gmail.com]=20 > Sent: Friday, June 12, 2015 5:07 AM > To: Mike Jones > Cc: The IESG; secdir@ietf.org; draft-ietf-jose-jwk-thumbprint.all@ietf.org= ; jose@ietf.org > Subject: Re: sector review of draft-ietf-jose-jwk-thumbprint-05 > =20 > =20 > On Jun 11, 2015, at 4:25 PM, Mike Jones wrot= e: > =20 > Hi Adam, >=20 > Thanks for the secdir review. >=20 >=20 > From: Adam W. Montville [mailto:adam.w.montville@gmail.com] > Sent: Monday, June 08, 2015 8:46 AM > To: The IESG; secdir@ietf.org; draft-ietf-jose-jwk-thumbprint.all@ietf.org= > Subject: sector review of draft-ietf-jose-jwk-thumbprint-05 >=20 >=20 > Hi, >=20 >=20 > I have reviewed this document as part of the security directorate's ongoin= g effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors.= Document editors and WG chairs should treat these comments just like any ot= her last call comments. >=20 > I believe the document is ready with (potential) issues. The =E2=80=9Cwit= h issues=E2=80=9D might be due to ignorance on my part. The draft does a ve= ry good job of explaining the canonical form of a JSON Web Key that can be u= sed for establishing a thumbprint under varying circumstances, complete with= what I found to be helpful examples. >=20 > The primary issue I have is that it=E2=80=99s unclear how relying parties a= re going to know which hash algorithm has been used. The examples use SHA-2= 56, but I=E2=80=99m not seeing where SHA-256 might be specified as a MUST or= even a SHOULD. Moreover, the example output ultimately shows only the Base= -64 encoding of the resulting hash, which says nothing about the algorithm u= sed to identify a key. >=20 > Earlier drafts had included fields whose names were intended to communicat= e the information about the hash function used - see the "jkt" field definit= ions in http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-01#section= -4 - but several working group reviewers suggested that these fields were un= necessary and that the typical usage would be as "kid" (key ID) field values= . With that removal, it falls onto the application to specify the hash algo= rithm for its particular usage. >=20 > This isn't as bad as you might think, however, because typically the consu= mer of the "kid" doesn't need to know the algorithm because it won't be repr= oducing the computation. It just relies on the fact that a unique key ID va= lue was generated for the key and compares "kid" values as opaque strings to= find the appropriate key. In this usage, the producer of the key is the on= ly party that needs to know the hash algorithm that it is using. I hope thi= s helps. > =20 > Yes, this does help, thank you. It seems like something that could be eas= ily added to the draft to explain why the generating algorithm needn=E2=80=99= t be disclosed so that slow folk like myself get the picture straight away. > =20 >=20 >=20 >=20 >=20 > Additionally, in Section 4, =E2=80=9CJSON and Unicode Considerations=E2=80= =9D some =E2=80=9Cshould=E2=80=9Ds are used, but I=E2=80=99m not reading the= m as SHOULDs. Should they be SHOULDs? For example, the start of the third p= aragraph in that section: =E2=80=9Cif new JWK members are defined that use n= on-ASCII member names, their definitions should specify the exact Unicode co= de point sequences used to represent them.=E2=80=9D It=E2=80=99s not clear t= o me whether this is a strong statement or just a recommendation - it seems t= hat this draft could help the future by making stronger statements to encour= age future interoperability. >=20 > For the other JOSE specifications, our chair Jim Schaad took the position t= hat RFC 2119 keywords should be reserved for testable protocol behaviors and= that other uses of the English word "should" should not use "SHOULD". The a= uthors followed that convention in this document. I do understand that othe= r authors and working groups have taken different positions in this regard. = If there are particular uses that you still feel should be changed to use R= FC 2119 keywords, please call them out. > =20 > This is all good, too. I was simply pointing out that there are =E2=80=9C= should=E2=80=9Ds around that may need to be considered as =E2=80=9CSHOULD=E2= =80=9Ds. I also see Jim=E2=80=99s (and others=E2=80=99) subsequent notes on t= he subject, so this is good from my perspective. >=20 >=20 >=20 >=20 > Kind regards, > Adam >=20 > Thanks aga= in! > -- Mike > =20 --Apple-Mail-0184946C-494C-4A67-B9E1-24EB2DEAF287 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes, thank you.
Kathleen&nbs= p;

Sent from my iPhone

On Jun 22, 2015, at 9:18 PM, Mik= e Jones <Michael.Jones@mic= rosoft.com> wrote:

I=E2=80=99d be glad to add t= he explanation below to the draft and to also include an IANA considerations= section that states we are updating the expert review instructions for a registry, as Jim Schaad had suggested.  Chairs and Kathleen, do y= ou want Nat and I to proceed to publish an updated draft?<= /p>

 

    &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;        -- Mike

 

From: Adam W. Mon= tville [mailto:adam.w.montvill= e@gmail.com]
Sent: Friday, June 12, 2015 5:07 AM
To: Mike Jones
Cc: The IESG; secdir@ietf.org;= draft-ietf-j= ose-jwk-thumbprint.all@ietf.org; jose@i= etf.org
Subject: Re: sector review of draft-ietf-jose-jwk-thumbprint-05<= /o:p>

 

 

On Jun 11, 2015, at 4:25 PM, Mike Jones <Michael.Jones@microsoft.com> wro= te:

 

Hi Adam,

Thanks for the secdir review.


From: Adam W. Montville [mailto:adam.w.montville@gmail.com]
Sent: Monday, June 08, 2015 8:46 AM
To: The IESG; secdir@ietf.org; draft-ietf-jose-jwk-thumbprint.all@ietf.org
Subject: sector review of draft-ietf-jose-jwk-thumbprint-05



Hi,



I have reviewed this document as part of= the security directorate's ongoing effort to review all IETF documents bein= g processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors a= nd WG chairs should treat these comments just like any other last call comme= nts.

I believe the document is ready with (potential) issues.  The =E2=80=9C= with issues=E2=80=9D might be due to ignorance on my part.  The draft d= oes a very good job of explaining the canonical form of a JSON Web Key that c= an be used for establishing a thumbprint under varying circumstances, complete with what I found to be helpful examples.

The primary issue I have is that it=E2=80=99s unclear how relying parties ar= e going to know which hash algorithm has been used.  The examples use S= HA-256, but I=E2=80=99m not seeing where SHA-256 might be specified as a MUS= T or even a SHOULD.  Moreover, the example output ultimately shows only the Base-64 encoding of the resulting hash, which say= s nothing about the algorithm used to identify a key.


Earlier drafts had included fields whose names were intended to communicate t= he information about the hash function used - see the "jkt" field definition= s in http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-01#section-4=  <= /span>- but several working group reviewers suggested that these fields were unnece= ssary and that the typical usage would be as "kid" (key ID) field values. &n= bsp;With that removal, it falls onto the application to specify the hash alg= orithm for its particular usage.

This isn't as bad as you might think, however, because typically the consume= r of the "kid" doesn't need to know the algorithm because it won't be reprod= ucing the computation.  It just relies on the fact that a unique key ID= value was generated for the key and compares "kid" values as opaque strings to find the appropriate key.  = In this usage, the producer of the key is the only party that needs to know t= he hash algorithm that it is using.  I hope this helps.

 

Yes, this does help, thank you.  It seems like s= omething that could be easily added to the draft to explain why the generati= ng algorithm needn=E2=80=99t be disclosed so that slow folk like myself get t= he picture straight away.

 





Additionally, in Section 4, =E2=80=9CJSO= N and Unicode Considerations=E2=80=9D some =E2=80=9Cshould=E2=80=9Ds are use= d, but I=E2=80=99m not reading them as SHOULDs. Should they be SHOULDs? &nbs= p;For example, the start of the third paragraph in that section: =E2=80=9Cif new JWK members are def= ined that use non-ASCII member names, their definitions should specify the e= xact Unicode code point sequences used to represent them.=E2=80=9D  It=E2= =80=99s not clear to me whether this is a strong statement or just a recommendation - it seems that this draft could help the future b= y making stronger statements to encourage future interoperability.


For the other JOSE specifications, our chair Jim Schaad took the position th= at RFC 2119 keywords should be reserved for testable protocol behaviors and t= hat other uses of the English word "should" should not use "SHOULD".  T= he authors followed that convention in this document.  I do understand that other authors and working grou= ps have taken different positions in this regard.  If there are particu= lar uses that you still feel should be changed to use RFC 2119 keywords, ple= ase call them out.

 

This is all good, too.  I was simply pointing ou= t that there are =E2=80=9Cshould=E2=80=9Ds around that may need to be consid= ered as =E2=80=9CSHOULD=E2=80=9Ds. I also see Jim=E2=80=99s (and others=E2=80= =99) subsequent notes on the subject, so this is good from my perspective.





Kind regards,
Adam


       &nb= sp;             =              &nb= sp;             &= nbsp;            = ;   Thanks again!
       &nb= sp;             =              &nb= sp;             &= nbsp;            = ;   -- Mike

 

= --Apple-Mail-0184946C-494C-4A67-B9E1-24EB2DEAF287-- From nobody Mon Jun 22 17:51:27 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525411B3132 for ; Mon, 22 Jun 2015 17:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFOIris6-8wd for ; Mon, 22 Jun 2015 17:51:21 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8701B3121 for ; Mon, 22 Jun 2015 17:51:20 -0700 (PDT) X-AuditID: 12074422-f79d26d0000026d6-0c-5588ad8868ad 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-5.mit.edu (Symantec Messaging Gateway) with SMTP id 97.1C.09942.88DA8855; Mon, 22 Jun 2015 20:51:20 -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 t5N0pJGu028825; Mon, 22 Jun 2015 20:51:19 -0400 Received: from macbook-pro.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5N0pFID003545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jun 2015 20:51:16 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_077D0EE3-C433-4520-9551-870F21D5FFB1"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5 From: Justin Richer In-Reply-To: <9F40D42F-56E0-49A9-8BCC-6964D124E3B2@mit.edu> Date: Mon, 22 Jun 2015 20:51:14 -0400 Message-Id: <5C315402-F952-43C6-A72C-DFADBF1E779B@mit.edu> References: <556CACEC.2030501@bbn.com> <8CBCFD65-237C-4683-B84B-B058DD5E166F@mit.edu> <55707A56.5000105@bbn.com> <9F40D42F-56E0-49A9-8BCC-6964D124E3B2@mit.edu> To: Stephen Kent X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNKsWRmVeSWpSXmKPExsUixCmqrduxtiPU4OI5IYuVk3awWyzdeY/V YuNsRosPCx+yOLB4TD0f6rF40342jyVLfjJ5LP/6gCWAJYrLJiU1J7MstUjfLoErY+bPVraC L7cZKzbuOcfYwHh+A2MXIyeHhICJxJcj75ggbDGJC/fWs3UxcnEICSxmklh67Qc7hLORUaL9 8TKozGMmiY3LVrGDtAgLWEg83veTBcTmFdCTePT0MVgHs8AURol/RxvZIOZKSFyd/RusiE1A VWL+yltg+zgFrCWuvnkEdgcLULxr3xKwocwCJRJzp79ihBhqJbFy6j5GiM3zGSXWnIDYJiIg L/Ht2FYgmwNogazE161yExgFZyG5YxayO2aBzU2S2DHzNBOErS2xbOFrZghbU2J/93IWTHEN ic5vE1khbHmJ7W/nQMUtJRbPvAFVbytxq28B1Ew7iUfTFrEuYORexSibklulm5uYmVOcmqxb nJyYl5dapGuql5tZopeaUrqJERSv7C5KOxh/HlQ6xCjAwajEw1swuSNUiDWxrLgy9xCjJAeT kijvqjVAIb6k/JTKjMTijPii0pzU4kOMKkC7Hm1YfYFRiiUvPy9VSYR36hygOt6UxMqq1KJ8 mDJpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxKErxtIAsEi1LTUyvSMnNKENJMHJyHGCU4 eICGnwSp4S0uSMwtzkyHyJ9iVJQS5y0FSQiAJDJK8+B6YWn2FaM40FvCvO9WA1XxAFM0XPcr oMFMQIO/5LaBDC5JREhJNTBa+T2uPP1scVOI+gmNl2KBv7ku7ldsdL+TICYy04rxJ6tDH/th /hmWshe/2/z+17AxvPaE4OLAn0+F/p87UZq5IWamQUo98+KbwQEa92flOpoHWOxPXcvwgCvL a5KfZLLTi6nstcYxr2IuHs+cxxsnf3rWZLMfsxwbdSTZmUJfNV7XbHX8wq/EUpyRaKjFXFSc CACHPPR/jgMAAA== Archived-At: Cc: secdir Subject: Re: [secdir] review of draft-ietf-oauth-introspection-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 00:51:25 -0000 --Apple-Mail=_077D0EE3-C433-4520-9551-870F21D5FFB1 Content-Type: multipart/alternative; boundary="Apple-Mail=_784A6454-76C9-4BC2-8AF8-5D3B0F064F9B" --Apple-Mail=_784A6454-76C9-4BC2-8AF8-5D3B0F064F9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Stephen, I=E2=80=99ve uploaded a new draft that should address your comments = below: Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-10 = Diff: = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspection-10.tx= t = Please let me know if you have any further questions, =E2=80=94 Justin > On Jun 4, 2015, at 4:14 PM, Justin Richer wrote: >=20 > Stephen, >=20 >> On Jun 4, 2015, at 12:18 PM, Stephen Kent > wrote: >>=20 >> Justin, >>=20 >>=20 >>> Stephen, thanks for the review. Comments inline. >>>=20 >>>> ... >>>> The text says: >>>>=20 >>>>=20 >>>> The introspection endpoint MUST be protected by a transport-layer = security mechanism as described in Section 4. >>>>=20 >>>>=20 >>>> It might be clearer to say here that the token endpoint MUST = communicate security with the introspection endpoint, and that TLS 1.2 = is the mandatory-to-implement mechanism for such security. Also, the = text should be clearer about the relationship between an authorization = server and an introspection endpoint. In some places the two terms seem = to be used interchangeably. >>>>=20 >>>=20 >>> This language was imported from the soon-to-be-published OAuth = Dynamic Registration drafts, including the forward reference. We don=E2=80= =99t want to repeat the requirement text. >> I didn't review the dynamic registration docs, or I would have made = the same comment there :-). >>=20 >> If you don't want to repeat requirements text, then I suggest you = might re-word the sentence >> I cited so that it's clearer. Saying that an endpoint must be = protected by a transport layer security mechanism seems needlessly = ambiguous. >=20 > The section pointed to in the forward reference in that sentence has = the details. If you have a better way to word this, please suggest text. >=20 >>=20 >>=20 >>> ... >>>>=20 >>>> How does a protected resource know which other parameters an = introspection endpoint requires/accepts? >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> We=E2=80=99re assuming it would be either an extension or = deployment-specific. >> an extension to what? >>=20 >=20 > An extension to this specification that defines other parameters and = their meanings. >=20 >> it seems that a primary motivation for this document is to fix = problems that arose >> because of inadequate specifications for OAuth token syntax. In that = light, this description >> of "other parameters" seems to perpetuate this sort of problem. >=20 > I wouldn=E2=80=99t call OAuth having =E2=80=9Cinadequate=E2=80=9D = token syntax specification, it has *no* token syntax, and that=E2=80=99s = on purpose. This specification actually doesn=E2=80=99t define a token = syntax, either, but it defines a web API for getting token information = regardless of the token syntax. The token itself can still be a signed = JWT, or a UUID, or a random hex blob; OAuth doesn=E2=80=99t care, and = that=E2=80=99s a good thing. >=20 >=20 >>>=20 >>>=20 >>>>=20 >>>> This section mandates (MUST) protection against =E2=80=9Cunauthorized= token scanning=E2=80=9D but mandates no standard way to do so. [Also, = when would a scanning =E2=80=9Cattack=E2=80=9D be authorized ;-)] >>>>=20 >>>>=20 >>>=20 >>> Is there something more specific we can recommend here? Perhaps in = the security considerations section. >> yes, the SC section is where there should be suggestions on how to = protect against such attacks. if you can't recommend something specific, = then mandating that something be >> done seems possibly vacuous, a MUST that will never be realized in = practice (see RFC 6919). >=20 > OK, we=E2=80=99ll try to add some more examples. >=20 > Cute reference. >=20 >>>=20 >>> And the attack could actually take place where an authorized = protected resource goes fishing for other valid tokens. The attack = isn=E2=80=99t authorized, but the client is =E2=80=A6 and yes that=E2=80=99= s not what we meant but I=E2=80=99m sticking to it. ;) >> so, as I said, the attack is not authorized, and the phrase = "unauthorized attack" will >> make most security experts cringe. is cringing a goal? >=20 > We can change the wording to reduce the cringe level. >=20 >>>=20 >>>> ... >>>> IANA must only accept registry updates from the Designated = Expert(s) >>>>=20 >>>> and should direct all requests for registration to the review = mailing >>>>=20 >>>> list. >>>>=20 >>>>=20 >>>> How about: >>>>=20 >>>>=20 >>>> IANA MUST accept registry updates only from the Designated = Expert(s) >>>>=20 >>>> and SHOULD direct all requests for registration to the review = mailing >>>>=20 >>>> list. >>>>=20 >>>=20 >>>=20 >>> This text was imported from a template, I=E2=80=99d be glad to = change it if there=E2=80=99s a better one. >> one should not assume that a doc that has made it through the RFC = approval process >> is perfect. >>>=20 >>>>=20 >>>> Section 3.1.1 >>>>=20 >>>>=20 >>>> If a proposed Name matches one already registered as per 7519, = ought it not have an =E2=80=9Cequivalent=E2=80=9D (vs. =E2=80=9Ccomparable= =E2=80=9D) definition if it is to be accepted? >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> It really is comparable, since the contexts are pretty different. >> if the contexts are so different, and thus the semantics are not = equivalent, why is the reuse of the name, and the potential confusion = acceptable? >=20 > Besides, if we simply prohibit reuse of the name, we=E2=80=99ll have = similar-but-confusing names, like =E2=80=9Cexpires=E2=80=9D vs. = =E2=80=9Cexp=E2=80=9D, in the two different places. The meanings are = close enough, with the details being context-specific, that the names = should be the same. Previously it was the same registry, but that was = causing even more confusion. >=20 >>>=20 >>>>=20 >>>> Section 4 >>>>=20 >>>>=20 >>>> The text lists four checks to be performed by an authorization = server, yet the introduction to this list says =E2=80=9CFor instance:=E2=80= =9D A more normative introduction would seem appropriate here. I realize = that the text says that not all of these checks may be applicable in all = OAuth 2.0 contexts, but since each check begins with =E2=80=9CIf the = token =E2=80=A6=E2=80=9D isn=E2=80=99t that a sufficient caveat? >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> This is not a normative requirement, since everything is contextual = to the nature of the tokens issued by the authorization server. >> so you're saying that there is no set of checks that every = authorization server >> can be expected to perform? not even token expiration? >>=20 >=20 > That=E2=80=99s correct. Not all tokens expire, so it doesn=E2=80=99t = make sense to mandate checking for expiration. Every recommendation here = is something that at least one known implementation of this protocol = already does in the wild, but not every implementation does every check = because it simply doesn=E2=80=99t make sense to do so. That=E2=80=99s = why the checks are phrased as =E2=80=9Cif the token=E2=80=9D and the = list is given as a =E2=80=9Cfor instance=E2=80=9D example of what to do. = We would also expect a server implementation to implement any other = checks that it might have in store, like =E2=80=9Cis my database online = and can I find the token in the these-are-valid-tokens table=E2=80=9D. >=20 > =E2=80=94 Justin >=20 >>=20 >> Steve >>=20 >=20 --Apple-Mail=_784A6454-76C9-4BC2-8AF8-5D3B0F064F9B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Stephen,

I=E2=80=99ve uploaded a new draft that should address your = comments below:

Draft: https://tools.ietf.org/html/draft-ietf-oauth-introspection-10

Diff: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-introspe= ction-10.txt

Please let me know if you have any further = questions,
 =E2=80=94 Justin

On Jun 4, 2015, at 4:14 PM, Justin Richer <jricher@MIT.EDU> = wrote:

Stephen,

On Jun 4, 2015, at 12:18 PM, Stephen Kent = <kent@bbn.com> = wrote:

=20
Justin,


=20 Stephen, thanks for the review. Comments inline.

...

The = text says:   =

 

The introspection endpoint MUST be protected by a transport-layer security mechanism as described in Section 4.

 

It = might be clearer to say here that the token endpoint MUST communicate security with the introspection endpoint, and that TLS 1.2 is the mandatory-to-implement mechanism for such security. Also, the text should be clearer about the relationship between an authorization server and an introspection endpoint. In some places the two terms seem to be used interchangeably.


This language was imported from the = soon-to-be-published OAuth Dynamic Registration drafts, including the forward reference. We don=E2=80=99t want to repeat the requirement = text.
I didn't review the dynamic registration docs, or I would have made the same comment there :-).

If you don't want to repeat requirements text, then I suggest you might re-word the sentence
I cited so that it's clearer. Saying that an endpoint must be protected by a transport layer security mechanism seems needlessly ambiguous.

The section pointed to in the forward = reference in that sentence has the details. If you have a better way to = word this, please suggest text.



...

 

How does a protected resource know = which other parameters an introspection endpoint requires/accepts?

 


We=E2=80=99re assuming it would be either an = extension or deployment-specific.
an extension to what?


An extension to this specification that = defines other parameters and their meanings.

it seems that a primary motivation for this document is to fix problems that arose
because of inadequate specifications for OAuth token syntax. In that light, this description
of "other parameters" seems to perpetuate this sort of problem.

I wouldn=E2=80=99t call OAuth having = =E2=80=9Cinadequate=E2=80=9D token syntax specification, it has *no* = token syntax, and that=E2=80=99s on purpose. This specification actually = doesn=E2=80=99t define a token syntax, either, but it defines a web API = for getting token information regardless of the token syntax. The token = itself can still be a signed JWT, or a UUID, or a random hex blob; OAuth = doesn=E2=80=99t care, and that=E2=80=99s a good thing.




 

This = section mandates (MUST) protection against =E2=80=9Cunauthorized token scanning=E2=80=9D = but mandates no standard way to do so. [Also, when would a scanning =E2=80=9Cattack=E2=80=9D be authorized ;-)]



Is there something more specific we can = recommend here? Perhaps in the security considerations section.
yes, the SC section is where there should be suggestions on how to protect against such attacks. if you can't recommend something specific, then mandating that something be
done seems possibly vacuous, a MUST that will never be realized in practice (see RFC 6919).

OK, we=E2=80=99ll try to = add some more examples. 

Cute reference.


And the attack could actually take place where = an authorized protected resource goes fishing for other valid tokens. The attack isn=E2=80=99t authorized, but the client = is =E2=80=A6 and yes that=E2=80=99s not what we meant but I=E2=80=99m = sticking to it.  ;)
so, as I said, the attack is not authorized, and the phrase "unauthorized attack" will
make most security experts cringe. is cringing a goal?

We can change the wording to reduce the = cringe level.


...
=

IANA must only accept registry = updates from the Designated Expert(s)

and should direct all requests for registration to the review mailing

list.

 

How about:

 

IANA MUST accept registry = updates only from the Designated Expert(s)

and SHOULD direct all requests for registration to the review mailing

list.



This text was imported from a template, I=E2=80=99= d be glad to change it if there=E2=80=99s a better one.
one should not assume that a doc that has made it through the RFC approval process
is perfect.

 

Section 3.1.1

 

If a proposed Name matches one = already registered as per 7519, ought it not have an =E2=80=9Cequivalent=E2=80=9D (vs. =E2=80=9Ccomparable=E2= =80=9D) definition if it is to be accepted?

 


It really is comparable, since the contexts = are pretty different.
if the contexts are so different, and thus the semantics are not equivalent, why is the reuse of the name, and the potential confusion acceptable?

Besides, if we simply = prohibit reuse of the name, we=E2=80=99ll have similar-but-confusing = names, like =E2=80=9Cexpires=E2=80=9D vs. =E2=80=9Cexp=E2=80=9D, in the = two different places. The meanings are close enough, with the details = being context-specific, that the names should be the same. Previously it = was the same registry, but that was causing even more = confusion.


 

Section 4

 

The text lists four checks to be = performed by an authorization server, yet the introduction to this list says =E2=80=9CFor instance:=E2=80=9D A = more normative introduction would seem appropriate here. I realize that the text says that not all of these checks may be applicable in all OAuth 2.0 contexts, but since each check begins with =E2=80=9CIf the token =E2=80=A6= =E2=80=9D isn=E2=80=99t that a sufficient caveat?

 


This is not a normative requirement, since = everything is contextual to the nature of the tokens issued by the authorization server.
so you're saying that there is no set of checks that every authorization server
can be expected to perform? not even token expiration?


That=E2=80=99s correct. Not all tokens = expire, so it doesn=E2=80=99t make sense to mandate checking for = expiration. Every recommendation here is something that at least one = known implementation of this protocol already does in the wild, but not = every implementation does every check because it simply doesn=E2=80=99t = make sense to do so. That=E2=80=99s why the checks are phrased as =E2=80=9C= if the token=E2=80=9D and the list is given as a =E2=80=9Cfor = instance=E2=80=9D example of what to do. We would also expect a server = implementation to implement any other checks that it might have in = store, like =E2=80=9Cis my database online and can I find the token in = the these-are-valid-tokens table=E2=80=9D. 

 =E2=80=94 Justin


Steve



= --Apple-Mail=_784A6454-76C9-4BC2-8AF8-5D3B0F064F9B-- --Apple-Mail=_077D0EE3-C433-4520-9551-870F21D5FFB1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJViK2DAAoJEDPAngkbd+w9aIwH/j4nMeA3ooGx2xaxcmGSat11 HE9dHxwwc3u/q0Mh7g2BSeaKSlIDOjyoiR0vvzeO3v7Mz1FgGwbgtOnLoD5hBvg8 jZHJo08Z55JM4+jSL9KpiBHVj55arvCqTOpmxBDGrwxkcGWTK+KZLa/Nrzv9k2Tn eqJKymO33jmjLSmQiRbGSsklGnvyHlElf73EBAI2OqSt1M7Uq92ItT5r9niZQAoM yN77WS8dRHA4DKK1y5LAKxkFXsg9yY6bH7i+qBNVOIt7n3gdA5+8UuanJh4iYoRX nYJv2LmD5ig1qZJTpe1UeqTurpi+8QqVlNJCAExst07DMrQ5v22bArDnIT+/M94= =sgWi -----END PGP SIGNATURE----- --Apple-Mail=_077D0EE3-C433-4520-9551-870F21D5FFB1-- From nobody Tue Jun 23 01:03:03 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C6F1A9069; Tue, 23 Jun 2015 01:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVe7AI-jG8oo; Tue, 23 Jun 2015 01:02:59 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63B351A9055; Tue, 23 Jun 2015 01:02:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,664,1427752800"; d="asc'?scan'208,217";a="137447316" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Jun 2015 10:02:43 +0200 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_27313A55-C36F-4A3F-BAC1-93724AEEE8F0"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Vincent Roca In-Reply-To: <55882D28.3020701@nostrum.com> Date: Tue, 23 Jun 2015 10:02:42 +0200 Message-Id: References: <2E90B73E-0309-4C49-B208-C2E30A0B6B22@inria.fr> <55882D28.3020701@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.2098) Archived-At: Cc: draft-ietf-sipcore-refer-explicit-subscription@tools.ietf.org, IESG , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sipcore-refer-explicit-subscription-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 08:03:02 -0000 --Apple-Mail=_27313A55-C36F-4A3F-BAC1-93724AEEE8F0 Content-Type: multipart/alternative; boundary="Apple-Mail=_58300043-8E95-43FE-AF3E-4B9667E184CD" --Apple-Mail=_58300043-8E95-43FE-AF3E-4B9667E184CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Robert, I have merged the two emails. >>> I have several questions and suggestions WRT the Security Section. >>>=20 >>> It is said that: =AB With this update, there may multiple = subscribers to any given refer event state." >>> So what? What are the implications from a security point of view? >> Hmm. I wonder if sentence order made this less clear than it should = have been? >>=20 >> The paragraph that sentence appears in discusses exactly what the = implications are - specifically that there is a new authorization = consideration. >> The paragraph that follow talks about how we deal with having that = new consideration. VR: Previous sentences of this paragraph explain that the authorization = for a SUBSCRIBE is now decoupled from the REFER mechanism. And then, the last sentence mentions the = possibility of having **multiple** subscribers which is not discussed previously, hence my remark. I don=92t think it=92s= a matter of sentence order. And the paragraph that follows does not mention nor discuss explicitly this idea of = **multiple** subscribers. I don=92t know if this notion of **multiple** subscribers is difficult to handle or not, if it creates = risks or not. Can you clarify the text? >>> IMHO, the third paragraph does not make an appropriate use of the = normative vocabulary. >>> For instance, it is said: >>> "the URI should be constructed so that it is not easy to guess, and = should be protected against eavesdroppers" >>> Shouldn=92t the author use =AB SHOULD =BB on both occasions? >>> The following sentence is ambiguous. It says: >>> "For instance, SIP messages containing this URI SHOULD be sent = using TLS or DTLS..." >>> "SHOULD" and "For instance" are contradictory. I suggest removing = "For instance". >>> Similarly, next sentence says: "can redirect". I think "SHOULD" = redirect is more appropriate. >>> Finally the same remark (i.e. use =AB SHOULD") can be done for the = next two sentences about additional authorization >>> mechanisms. >> Ben made a similar comment. The first 2119 requirement you point to = needs to move up into the protocol definition part of the document. >> The second is restating text that=92s in RFC3261, and we don't need = to repeat the 2119 here - I'll clarify the language to say "use the = mechanisms the base specification provides". VR: IMHO repeating normative vocabulary is not an issue as long as it is = used homogeneously in the whole document, whereas the opposite would be an issue. >>> In the 4th paragraph, it is not clear to me why it is said that = there is =AB a factor of 11 amplification due to retransmissions >>> of the request =BB. What are the foundations for this =AB 11 =BB = factor? >> This is base SIP behavior. The non-INVITE transaction state machine = retransmits 11 times before giving up if something on the other end = doesn't talk back >> (which is what will happen if the other endpoint is not SIP aware). VR: okay, I see. I=92ll let you judge whether it=92s appropriate or not = to justify this figure in the document. >>> And what happens if the victim is SIP aware? >> It will send an appropriate response, so there won't be the = retransmissions of the request. In other words, sending this as raw = traffic towards a sip aware element is no different than sending any = other sip request towards a sip aware element. VR: okay. Same remark as above. >> Additionally, I have concerns about backward compatibility. >> The mechanisms introduced by this extension may not be backward = compatible with RFC 3515 (see section 7). >> However I don=92t see any discussion in the current document. >> There are some guidelines in RFC 6656 (8.3.1) concerning the 202 = response code, but what is described in the first >> paragraph is new to this document. > Our AD already noted that the second paragraph should actually be = removed from this document - it is covered in refer-clarifications. VR: ok > For the first paragraph - backwards compatibility is ensured by the = base SIP extension mechanism. > An implementation of 3515 that is not aware of this extension (and the = update to 3515 established by this document) would reject any requests = that tried to invoke the extension (if either of the tokens defined here = appeared in a Require: header field, that implementation would reject = them with a 420 response. VR: ok, I understand. But is =AB MAY accept =BB the appropriate? I don=92t= think so. What about: NEW: The requirement in section 2.4.4 of [RFC3515] to reject out-of-dialog SUBSCRIBE requests to event 'refer' is removed. An element MUST process a SUBSCRIBE request to event =91refer', following the requirements and guidance in this document, since REFER is no longer = the only mechanism that can create a subscription to event =91refer=92. Cheers, Vincent --Apple-Mail=_58300043-8E95-43FE-AF3E-4B9667E184CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello Robert,

I have merged the two emails.

I have several questions and suggestions WRT = the Security Section.

It is said that: =AB = With this update, there may multiple subscribers to any given refer = event state."
So what? What are the implications = from a security point of view?
Hmm. I wonder if = sentence order made this less clear than it should have been?

The paragraph that sentence appears in = discusses exactly what the implications are - specifically that there is = a new authorization consideration.
The paragraph that = follow talks about how we deal with having that new = consideration. 

VR: Previous sentences of this paragraph explain = that the authorization for a SUBSCRIBE is now decoupled = from
the REFER mechanism. And then, the last sentence mentions = the possibility of having **multiple** subscribers
which is = not discussed previously, hence my remark. I don=92t think it=92s a = matter of sentence order. And the paragraph
that follows does = not mention nor discuss explicitly this idea of **multiple** = subscribers. I don=92t know if this notion
of **multiple** = subscribers is difficult to handle or not, if it creates risks or not. = Can you clarify the text?
 

IMHO, the third paragraph = does not make an appropriate use of the normative vocabulary.
For instance, it is said: 
"the URI = should be constructed so that it is not easy to guess, and should be = protected against eavesdroppers"
Shouldn=92t the = author use =AB SHOULD =BB on both occasions?
The following sentence is ambiguous. It says:
= "For instance, SIP messages containing this URI SHOULD be sent = using TLS or DTLS..."
"SHOULD" and "For instance" = are contradictory. I suggest removing "For instance".
Similarly, next sentence says: "can redirect". I think = "SHOULD" redirect is more appropriate.
Finally the = same remark (i.e. use =AB SHOULD") can be done for the next two = sentences about additional authorization
mechanisms.
Ben made a similar = comment. The first 2119 requirement you point to needs to move up into = the protocol definition part of the document.
The second = is restating text that=92s in RFC3261, and we don't need to repeat the = 2119 here - I'll clarify the language to say "use the mechanisms the = base specification provides".

VR: IMHO repeating normative vocabulary is not an = issue as long as it is used homogeneously in the whole = document,
whereas the opposite would be an = issue.

In the 4th paragraph, it is = not clear to me why it is said that there is =AB a factor of 11 = amplification due to retransmissions
of the = request =BB. What are the foundations for this =AB 11 =BB = factor?
This is base SIP behavior. The = non-INVITE transaction state machine retransmits 11 times before giving = up if something on the other end doesn't talk back
(which = is what will happen if the other endpoint is not SIP aware).

VR: okay, I see. I=92ll let you judge whether it=92s= appropriate or not to justify this figure in the document.

And what happens if the = victim is SIP aware?
It will send an appropriate = response, so there won't be the retransmissions of the request. In other = words, sending this as raw traffic towards a sip aware element is no = different than sending any other sip request towards a sip aware = element.

VR: okay. Same remark as above.


Additionally, I have concerns about backward compatibility.
The mechanisms introduced by this extension may not be backward compatible with RFC 3515 (see section = 7).
However I don=92t see any discussion in the = current document.
There are some guidelines in RFC 6656 (8.3.1) concerning the 202 response code, but what is described in the first
paragraph is new to this document.
Our AD already noted that the second paragraph should actually be removed from this document - it is covered in refer-clarifications.

VR: ok

=20 For the first paragraph - backwards compatibility is ensured by the base SIP extension mechanism.
An implementation of 3515 that is not aware of this extension (and the update to 3515 established by this document) would reject any requests that tried to invoke the extension (if either of the tokens defined here appeared in a Require: header field, that implementation would reject them with a 420 response.

VR: = ok, I understand. But is =AB MAY accept =BB the appropriate? I = don=92t think so. What about:

NEW:
   The requirement = in section 2.4.4 of [RFC3515] to reject out-of-dialog
   SUBSCRIBE requests to event 'refer' is removed. =  An element MUST
   process = a SUBSCRIBE request to event =91refer', following the
   requirements and guidance in this document, since REFER is no longer = the
   only mechanism that can create a = subscription to event =91refer=92.

Cheers,

   Vincent

= --Apple-Mail=_58300043-8E95-43FE-AF3E-4B9667E184CD-- --Apple-Mail=_27313A55-C36F-4A3F-BAC1-93724AEEE8F0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJViRKiAAoJEHBYw8t72N4rkhQP/19v0ku9pV9G80TKhWxy+5h5 1hAbRpenMhrpTGwg/4/QpcMMjVgQlXBY5g4hvKhd4t/YxXeaXq/qWeWr5gNPGi4+ 4V+YksyFtl9Y4La1Vc577gS1mbJ/eeOLnvRV8ML3Rz8GSALEGSkFbjkrfaKwaRTA NLZ2mmNn/QP52QW0mbaUhGAXg2f4ODWqK1vKdTiciAgTNuxYow9KnjFz3OIf6wAu aUe8KXMqxyFadmQFEmvmw322D0YWhYjlaJFz7hRKDWm+yR+9c544tJYEAw84FiXD ycchETJrgfOcQm78jtDXiaI9hEZIjmUC338mpgnTGPUWtysk1mLu9WyjKcx2AK/b BhvDzZeBr4IJZs4Zpoge5wTxcgMLeYhvxQDFIwOdLM1FnNIg9zp8nFs56bNKbzOA dWHV9msByJE72GrDsaFb4+O9WezRXXEscHN0wkRW9p1DtS4VtSfXISRlQzRhpB18 0OijOX8cEOoNxseEurlBDo7xRow2BzGA87Ni4jL7f7ymr0F46d8iwUbY88CXzIJi JskJBM+Va0wCBwaePIWPMHK5jd8lSsFjPEvmhfTc/5Hf7jTvEs4vliuiPXEumyQt AAacDrNwCG6qDYGlA6cFKDgvm7jP+8y2MlICieVcuOfByfnO2eWf9PqvxkelXhLx A4GyQoG08JLufWBuT9ZJ =po1x -----END PGP SIGNATURE----- --Apple-Mail=_27313A55-C36F-4A3F-BAC1-93724AEEE8F0-- From nobody Tue Jun 23 07:33:23 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4B01B2C78; Tue, 23 Jun 2015 07:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPPI03Npv2dy; Tue, 23 Jun 2015 07:33:18 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBD6E1A0211; Tue, 23 Jun 2015 07:33:18 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5NEX7FT009225 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 23 Jun 2015 09:33:18 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Vincent Roca" Date: Tue, 23 Jun 2015 09:33:07 -0500 Message-ID: <87B34D50-F69C-4436-A470-A5F56FF4EE42@nostrum.com> In-Reply-To: References: <2E90B73E-0309-4C49-B208-C2E30A0B6B22@inria.fr> <55882D28.3020701@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: draft-ietf-sipcore-refer-explicit-subscription@tools.ietf.org, secdir@ietf.org, IESG Subject: Re: [secdir] Secdir review of draft-ietf-sipcore-refer-explicit-subscription-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 14:33:20 -0000 On 23 Jun 2015, at 3:02, Vincent Roca wrote: > Ben made a similar comment. The first 2119 requirement you point to > needs to move up into the protocol definition part of the document. >>> The second is restating text that’s in RFC3261, and we don't need >>> to repeat the 2119 here - I'll clarify the language to say "use the >>> mechanisms the base specification provides". > > > > VR: IMHO repeating normative vocabulary is not an issue as long as it > is used homogeneously in the whole document, > whereas the opposite would be an issue. While this is small enough to not matter either way, in general I prefer not to have multiple occurrences of the same normative statement, unless one clearly refers to the other. Even if they are in sync, it can cause confusion for people trying to reference authoritative text, and an opportunity for error in future updates. From nobody Tue Jun 23 23:08:28 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C481B2A1A; Tue, 23 Jun 2015 23:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uF3Hkn8WHjyu; Tue, 23 Jun 2015 23:08:21 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B811B2A17; Tue, 23 Jun 2015 23:08:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,670,1427752800"; d="asc'?scan'208";a="166979934" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Jun 2015 08:08:18 +0200 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_77D7F85B-8D30-4C04-A573-B5CE50AA5B2C"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Vincent Roca In-Reply-To: <87B34D50-F69C-4436-A470-A5F56FF4EE42@nostrum.com> Date: Wed, 24 Jun 2015 08:08:19 +0200 Message-Id: References: <2E90B73E-0309-4C49-B208-C2E30A0B6B22@inria.fr> <55882D28.3020701@nostrum.com> <87B34D50-F69C-4436-A470-A5F56FF4EE42@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.2098) Archived-At: Cc: draft-ietf-sipcore-refer-explicit-subscription@tools.ietf.org, secdir@ietf.org, IESG Subject: Re: [secdir] Secdir review of draft-ietf-sipcore-refer-explicit-subscription-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 06:08:22 -0000 --Apple-Mail=_77D7F85B-8D30-4C04-A573-B5CE50AA5B2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Ben, I do understand that such a practice across different documents is = dangerous. But this is not what I=E2=80=99ve been doing so far within a single = document. I=E2=80=99ll think about it in the future. Thanks, Vincent > Le 23 juin 2015 =C3=A0 16:33, Ben Campbell a =C3=A9cri= t : >=20 > On 23 Jun 2015, at 3:02, Vincent Roca wrote: >=20 >> Ben made a similar comment. The first 2119 requirement you point to = needs to move up into the protocol definition part of the document. >>>> The second is restating text that=E2=80=99s in RFC3261, and we = don't need to repeat the 2119 here - I'll clarify the language to say = "use the mechanisms the base specification provides". >>=20 >>=20 >>=20 >> VR: IMHO repeating normative vocabulary is not an issue as long as it = is used homogeneously in the whole document, >> whereas the opposite would be an issue. >=20 > While this is small enough to not matter either way, in general I = prefer not to have multiple occurrences of the same normative statement, = unless one clearly refers to the other. Even if they are in sync, it can = cause confusion for people trying to reference authoritative text, and = an opportunity for error in future updates. --Apple-Mail=_77D7F85B-8D30-4C04-A573-B5CE50AA5B2C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJViklTAAoJEHBYw8t72N4rtxsP/ik6W2H1ifpSe9pefjrdDD6l 7+S6iv9AhJDqC+oSkYXA51bPmoE6JFZSOuVY/EKLbEz9A/eZjpbebLGvutT5JLFX ygq8r+gwpmSag5Z/hpEo0g4tQ35bvnII/jo9buvd8Yn+Xpd3Q2+S1ZCRNPi90CrN C6tDOW599yKTrvWaCSHZq94ArKS2rYxHFabnuzDk5LnD9fx2TTEeKrMMflElyv6y H4EzrTGNR/6xojR975Qgz9/4Ma4SdDI27mn8v5vcwQtAJMgb2O49qGvWyWL6Z8zn AEaS3p0NRLuC8o7dXcQ4auvHBK3i2ljAIxeusOc0JdvjY1tJ1l+jV02wubpLGRUj kZYD/1suRk0lXqsZ0FSgnJ+vllf7/OPVPWT5gc263RhvxyoN/Z/vgYfJO3fa4U/t VYoOE2koO495X33+U2JMAHvTG43E8MIe3A9ZcJns//BILYHlI1XLdRnzKrJpjCFY GLKiYufzdxjXY4EG6/a6jrldQOXt3mV+knO2nJ1ZjnHMYsyvhzZHs4yxauhc9kQL eIRdlB5iNgqiNr9lwICf9lnjJCnkLuV+cnI4CIlOaAG0iDVyw7KM0aZt3nc5vBQW ZcXf8VBeKMuczTwoDtNYofYbMW2BEcSQrkWM5NY5KaMXz4/y3KtNLHGvqT09aIA4 wciC5spDEDZ9k2FMOlQM =b6/l -----END PGP SIGNATURE----- --Apple-Mail=_77D7F85B-8D30-4C04-A573-B5CE50AA5B2C-- From nobody Wed Jun 24 01:40:28 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4A51B3082; Wed, 24 Jun 2015 01:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4gjK4LTU2Aw; Wed, 24 Jun 2015 01:40:22 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0144.outbound.protection.outlook.com [207.46.100.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25D2B1A90CE; Wed, 24 Jun 2015 01:40:22 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.201.16; Wed, 24 Jun 2015 08:40:19 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0201.000; Wed, 24 Jun 2015 08:40:19 +0000 From: Mike Jones To: "Adam W. Montville" Thread-Topic: sector review of draft-ietf-jose-jwk-thumbprint-05 Thread-Index: AQHQogJgaphBjlti2Uu758g0GQEF3p2nztYwgAD9kwCAEC+K8IAACaYAgAJomRA= Date: Wed, 24 Jun 2015 08:40:19 +0000 Message-ID: References: <4CA0A65D-E5FD-408C-A6B9-6ECB12A81B7C@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:l2wEPiAEK3yPxB5Qjpyn+6FoYJtbr/zV8Vd68iV61KyxBXmyxKZ+SJyxdNk0ddWRqu8+1/ZzD9pT02b0H01m0w3b4+MsyL9Qo8c+NtcojR2vWJDTCK60l8A0B4ypY4OKuThh8L37TaH6CzQdMwNz8A==; 24:LZhei9JFn1wpa7HsGOEp4CIoMHxPnPiM+fLUz7W23DrhOwWqPgQkUD+GyL3qX56/GnfP1SLxvT58h22koYVdjP8m9y15sXrAtzvTgTKOwGA=; 20:ock39G+rV/Yb5RX2ru7c9m44Vb1FTIFv3wzOy6vSIrN25ed63s4QxKYHSZwU9g/FmnaEYsTz2fucliRFwr1JOg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 061725F016 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(43784003)(377454003)(19580395003)(19580405001)(2656002)(87936001)(93886004)(230783001)(46102003)(19609705001)(122556002)(62966003)(77156002)(40100003)(5003630100001)(19617315012)(92566002)(86612001)(5003600100002)(74316001)(16236675004)(19625215002)(86362001)(33656002)(99286002)(106116001)(54356999)(50986999)(76176999)(19300405004)(5001960100002)(5002640100001)(110136002)(2950100001)(2900100001)(66066001)(189998001)(76576001)(77096005)(15975445007)(102836002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB44275C31276DFF36611D67DF5AF0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2015 08:40:19.2700 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Cc: "draft-ietf-jose-jwk-thumbprint.all@ietf.org" , The IESG , "jose@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] sector review of draft-ietf-jose-jwk-thumbprint-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 08:40:25 -0000 --_000_BY2PR03MB44275C31276DFF36611D67DF5AF0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWRhbSwNCg0KVGhhbmtzIGFnYWluIGZvciB5b3VyIHJldmlldyBjb21tZW50cy4gIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtandrLXRodW1icHJpbnQtMDYg aGFzIGJlZW4gcG9zdGVkIHRvIGFkZHJlc3MgdGhlbS4gIFNlZSBzZWN0aW9ucyAzLjQgKFNlbGVj dGlvbiBvZiBIYXNoIEZ1bmN0aW9uKSBhbmQgNiAoSUFOQSBDb25zaWRlcmF0aW9ucykuDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFRoYW5rcyBhZ2FpbiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC0tIE5hdCBhbmQgTWlrZQ0KDQpGcm9tOiBLYXRobGVlbiBNb3Jp YXJ0eSBbbWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tXQ0KU2VudDogTW9u ZGF5LCBKdW5lIDIyLCAyMDE1IDEyOjUxIFBNDQpUbzogTWlrZSBKb25lcw0KQ2M6IEFkYW0gVy4g TW9udHZpbGxlOyBUaGUgSUVTRzsgc2VjZGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLWpvc2Utandr LXRodW1icHJpbnQuYWxsQGlldGYub3JnOyBqb3NlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogc2Vj dG9yIHJldmlldyBvZiBkcmFmdC1pZXRmLWpvc2UtandrLXRodW1icHJpbnQtMDUNCg0KWWVzLCB0 aGFuayB5b3UuDQpLYXRobGVlbg0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIEp1biAyMiwg MjAxNSwgYXQgOToxOCBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t PG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCknigJlkIGJlIGds YWQgdG8gYWRkIHRoZSBleHBsYW5hdGlvbiBiZWxvdyB0byB0aGUgZHJhZnQgYW5kIHRvIGFsc28g aW5jbHVkZSBhbiBJQU5BIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gdGhhdCBzdGF0ZXMgd2UgYXJl IHVwZGF0aW5nIHRoZSBleHBlcnQgcmV2aWV3IGluc3RydWN0aW9ucyBmb3IgYSByZWdpc3RyeSwg YXMgSmltIFNjaGFhZCBoYWQgc3VnZ2VzdGVkLiAgQ2hhaXJzIGFuZCBLYXRobGVlbiwgZG8geW91 IHdhbnQgTmF0IGFuZCBJIHRvIHByb2NlZWQgdG8gcHVibGlzaCBhbiB1cGRhdGVkIGRyYWZ0Pw0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBBZGFtIFcuIE1vbnR2aWxsZSBbbWFpbHRvOmFkYW0u dy5tb250dmlsbGVAZ21haWwuY29tXQ0KU2VudDogRnJpZGF5LCBKdW5lIDEyLCAyMDE1IDU6MDcg QU0NClRvOiBNaWtlIEpvbmVzDQpDYzogVGhlIElFU0c7IHNlY2RpckBpZXRmLm9yZzxtYWlsdG86 c2VjZGlyQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnByaW50LmFsbEBpZXRm Lm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnByaW50LmFsbEBpZXRmLm9yZz47 IGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogc2VjdG9y IHJldmlldyBvZiBkcmFmdC1pZXRmLWpvc2UtandrLXRodW1icHJpbnQtMDUNCg0KDQpPbiBKdW4g MTEsIDIwMTUsIGF0IDQ6MjUgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQoNCkhpIEFk YW0sDQoNClRoYW5rcyBmb3IgdGhlIHNlY2RpciByZXZpZXcuDQoNCg0KDQpGcm9tOiBBZGFtIFcu IE1vbnR2aWxsZSBbbWFpbHRvOmFkYW0udy5tb250dmlsbGVAZ21haWwuY29tXQ0KU2VudDogTW9u ZGF5LCBKdW5lIDA4LCAyMDE1IDg6NDYgQU0NClRvOiBUaGUgSUVTRzsgc2VjZGlyQGlldGYub3Jn PG1haWx0bzpzZWNkaXJAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWpvc2UtandrLXRodW1icHJpbnQu YWxsQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWpvc2UtandrLXRodW1icHJpbnQuYWxsQGll dGYub3JnPg0KU3ViamVjdDogc2VjdG9yIHJldmlldyBvZiBkcmFmdC1pZXRmLWpvc2UtandrLXRo dW1icHJpbnQtMDUNCg0KDQoNCkhpLA0KDQoNCg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1l bnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0 byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4g VGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2Yg dGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFp cnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBj YWxsIGNvbW1lbnRzLg0KDQpJIGJlbGlldmUgdGhlIGRvY3VtZW50IGlzIHJlYWR5IHdpdGggKHBv dGVudGlhbCkgaXNzdWVzLiAgVGhlIOKAnHdpdGggaXNzdWVz4oCdIG1pZ2h0IGJlIGR1ZSB0byBp Z25vcmFuY2Ugb24gbXkgcGFydC4gIFRoZSBkcmFmdCBkb2VzIGEgdmVyeSBnb29kIGpvYiBvZiBl eHBsYWluaW5nIHRoZSBjYW5vbmljYWwgZm9ybSBvZiBhIEpTT04gV2ViIEtleSB0aGF0IGNhbiBi ZSB1c2VkIGZvciBlc3RhYmxpc2hpbmcgYSB0aHVtYnByaW50IHVuZGVyIHZhcnlpbmcgY2lyY3Vt c3RhbmNlcywgY29tcGxldGUgd2l0aCB3aGF0IEkgZm91bmQgdG8gYmUgaGVscGZ1bCBleGFtcGxl cy4NCg0KVGhlIHByaW1hcnkgaXNzdWUgSSBoYXZlIGlzIHRoYXQgaXTigJlzIHVuY2xlYXIgaG93 IHJlbHlpbmcgcGFydGllcyBhcmUgZ29pbmcgdG8ga25vdyB3aGljaCBoYXNoIGFsZ29yaXRobSBo YXMgYmVlbiB1c2VkLiAgVGhlIGV4YW1wbGVzIHVzZSBTSEEtMjU2LCBidXQgSeKAmW0gbm90IHNl ZWluZyB3aGVyZSBTSEEtMjU2IG1pZ2h0IGJlIHNwZWNpZmllZCBhcyBhIE1VU1Qgb3IgZXZlbiBh IFNIT1VMRC4gIE1vcmVvdmVyLCB0aGUgZXhhbXBsZSBvdXRwdXQgdWx0aW1hdGVseSBzaG93cyBv bmx5IHRoZSBCYXNlLTY0IGVuY29kaW5nIG9mIHRoZSByZXN1bHRpbmcgaGFzaCwgd2hpY2ggc2F5 cyBub3RoaW5nIGFib3V0IHRoZSBhbGdvcml0aG0gdXNlZCB0byBpZGVudGlmeSBhIGtleS4NCg0K RWFybGllciBkcmFmdHMgaGFkIGluY2x1ZGVkIGZpZWxkcyB3aG9zZSBuYW1lcyB3ZXJlIGludGVu ZGVkIHRvIGNvbW11bmljYXRlIHRoZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgaGFzaCBmdW5jdGlv biB1c2VkIC0gc2VlIHRoZSAiamt0IiBmaWVsZCBkZWZpbml0aW9ucyBpbiBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtandrLXRodW1icHJpbnQtMDEjc2VjdGlvbi00 IC0gYnV0IHNldmVyYWwgd29ya2luZyBncm91cCByZXZpZXdlcnMgc3VnZ2VzdGVkIHRoYXQgdGhl c2UgZmllbGRzIHdlcmUgdW5uZWNlc3NhcnkgYW5kIHRoYXQgdGhlIHR5cGljYWwgdXNhZ2Ugd291 bGQgYmUgYXMgImtpZCIgKGtleSBJRCkgZmllbGQgdmFsdWVzLiAgV2l0aCB0aGF0IHJlbW92YWws IGl0IGZhbGxzIG9udG8gdGhlIGFwcGxpY2F0aW9uIHRvIHNwZWNpZnkgdGhlIGhhc2ggYWxnb3Jp dGhtIGZvciBpdHMgcGFydGljdWxhciB1c2FnZS4NCg0KVGhpcyBpc24ndCBhcyBiYWQgYXMgeW91 IG1pZ2h0IHRoaW5rLCBob3dldmVyLCBiZWNhdXNlIHR5cGljYWxseSB0aGUgY29uc3VtZXIgb2Yg dGhlICJraWQiIGRvZXNuJ3QgbmVlZCB0byBrbm93IHRoZSBhbGdvcml0aG0gYmVjYXVzZSBpdCB3 b24ndCBiZSByZXByb2R1Y2luZyB0aGUgY29tcHV0YXRpb24uICBJdCBqdXN0IHJlbGllcyBvbiB0 aGUgZmFjdCB0aGF0IGEgdW5pcXVlIGtleSBJRCB2YWx1ZSB3YXMgZ2VuZXJhdGVkIGZvciB0aGUg a2V5IGFuZCBjb21wYXJlcyAia2lkIiB2YWx1ZXMgYXMgb3BhcXVlIHN0cmluZ3MgdG8gZmluZCB0 aGUgYXBwcm9wcmlhdGUga2V5LiAgSW4gdGhpcyB1c2FnZSwgdGhlIHByb2R1Y2VyIG9mIHRoZSBr ZXkgaXMgdGhlIG9ubHkgcGFydHkgdGhhdCBuZWVkcyB0byBrbm93IHRoZSBoYXNoIGFsZ29yaXRo bSB0aGF0IGl0IGlzIHVzaW5nLiAgSSBob3BlIHRoaXMgaGVscHMuDQoNClllcywgdGhpcyBkb2Vz IGhlbHAsIHRoYW5rIHlvdS4gIEl0IHNlZW1zIGxpa2Ugc29tZXRoaW5nIHRoYXQgY291bGQgYmUg ZWFzaWx5IGFkZGVkIHRvIHRoZSBkcmFmdCB0byBleHBsYWluIHdoeSB0aGUgZ2VuZXJhdGluZyBh bGdvcml0aG0gbmVlZG7igJl0IGJlIGRpc2Nsb3NlZCBzbyB0aGF0IHNsb3cgZm9sayBsaWtlIG15 c2VsZiBnZXQgdGhlIHBpY3R1cmUgc3RyYWlnaHQgYXdheS4NCg0KDQoNCg0KDQoNCg0KQWRkaXRp b25hbGx5LCBpbiBTZWN0aW9uIDQsIOKAnEpTT04gYW5kIFVuaWNvZGUgQ29uc2lkZXJhdGlvbnPi gJ0gc29tZSDigJxzaG91bGTigJ1zIGFyZSB1c2VkLCBidXQgSeKAmW0gbm90IHJlYWRpbmcgdGhl bSBhcyBTSE9VTERzLiBTaG91bGQgdGhleSBiZSBTSE9VTERzPyAgRm9yIGV4YW1wbGUsIHRoZSBz dGFydCBvZiB0aGUgdGhpcmQgcGFyYWdyYXBoIGluIHRoYXQgc2VjdGlvbjog4oCcaWYgbmV3IEpX SyBtZW1iZXJzIGFyZSBkZWZpbmVkIHRoYXQgdXNlIG5vbi1BU0NJSSBtZW1iZXIgbmFtZXMsIHRo ZWlyIGRlZmluaXRpb25zIHNob3VsZCBzcGVjaWZ5IHRoZSBleGFjdCBVbmljb2RlIGNvZGUgcG9p bnQgc2VxdWVuY2VzIHVzZWQgdG8gcmVwcmVzZW50IHRoZW0u4oCdICBJdOKAmXMgbm90IGNsZWFy IHRvIG1lIHdoZXRoZXIgdGhpcyBpcyBhIHN0cm9uZyBzdGF0ZW1lbnQgb3IganVzdCBhIHJlY29t bWVuZGF0aW9uIC0gaXQgc2VlbXMgdGhhdCB0aGlzIGRyYWZ0IGNvdWxkIGhlbHAgdGhlIGZ1dHVy ZSBieSBtYWtpbmcgc3Ryb25nZXIgc3RhdGVtZW50cyB0byBlbmNvdXJhZ2UgZnV0dXJlIGludGVy b3BlcmFiaWxpdHkuDQoNCkZvciB0aGUgb3RoZXIgSk9TRSBzcGVjaWZpY2F0aW9ucywgb3VyIGNo YWlyIEppbSBTY2hhYWQgdG9vayB0aGUgcG9zaXRpb24gdGhhdCBSRkMgMjExOSBrZXl3b3JkcyBz aG91bGQgYmUgcmVzZXJ2ZWQgZm9yIHRlc3RhYmxlIHByb3RvY29sIGJlaGF2aW9ycyBhbmQgdGhh dCBvdGhlciB1c2VzIG9mIHRoZSBFbmdsaXNoIHdvcmQgInNob3VsZCIgc2hvdWxkIG5vdCB1c2Ug IlNIT1VMRCIuICBUaGUgYXV0aG9ycyBmb2xsb3dlZCB0aGF0IGNvbnZlbnRpb24gaW4gdGhpcyBk b2N1bWVudC4gIEkgZG8gdW5kZXJzdGFuZCB0aGF0IG90aGVyIGF1dGhvcnMgYW5kIHdvcmtpbmcg Z3JvdXBzIGhhdmUgdGFrZW4gZGlmZmVyZW50IHBvc2l0aW9ucyBpbiB0aGlzIHJlZ2FyZC4gIElm IHRoZXJlIGFyZSBwYXJ0aWN1bGFyIHVzZXMgdGhhdCB5b3Ugc3RpbGwgZmVlbCBzaG91bGQgYmUg Y2hhbmdlZCB0byB1c2UgUkZDIDIxMTkga2V5d29yZHMsIHBsZWFzZSBjYWxsIHRoZW0gb3V0Lg0K DQpUaGlzIGlzIGFsbCBnb29kLCB0b28uICBJIHdhcyBzaW1wbHkgcG9pbnRpbmcgb3V0IHRoYXQg dGhlcmUgYXJlIOKAnHNob3VsZOKAnXMgYXJvdW5kIHRoYXQgbWF5IG5lZWQgdG8gYmUgY29uc2lk ZXJlZCBhcyDigJxTSE9VTETigJ1zLiBJIGFsc28gc2VlIEppbeKAmXMgKGFuZCBvdGhlcnPigJkp IHN1YnNlcXVlbnQgbm90ZXMgb24gdGhlIHN1YmplY3QsIHNvIHRoaXMgaXMgZ29vZCBmcm9tIG15 IHBlcnNwZWN0aXZlLg0KDQoNCg0KDQoNCg0KS2luZCByZWdhcmRzLA0KQWRhbQ0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg VGhhbmtzIGFnYWluIQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0K --_000_BY2PR03MB44275C31276DFF36611D67DF5AF0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXtt c28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5hcHBsZS10YWItc3Bh bg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SGkgQWRhbSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBhZ2FpbiBmb3IgeW91 ciByZXZpZXcgY29tbWVudHMuJm5ic3A7DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnByaW50LTA2Ij5odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnByaW50LTA2PC9hPiBoYXMgYmVl biBwb3N0ZWQgdG8gYWRkcmVzcyB0aGVtLiZuYnNwOyBTZWUgc2VjdGlvbnMgMy40IChTZWxlY3Rp b24gb2YgSGFzaCBGdW5jdGlvbikgYW5kIDYgKElBTkEgQ29uc2lkZXJhdGlvbnMpLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyBhZ2Fpbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC0tIE5hdCBhbmQgTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEthdGhs ZWVuIE1vcmlhcnR5IFttYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb21dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKdW5lIDIyLCAyMDE1IDEyOjUxIFBNPGJyPg0KPGI+ VG86PC9iPiBNaWtlIEpvbmVzPGJyPg0KPGI+Q2M6PC9iPiBBZGFtIFcuIE1vbnR2aWxsZTsgVGhl IElFU0c7IHNlY2RpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnByaW50LmFs bEBpZXRmLm9yZzsgam9zZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogc2VjdG9y IHJldmlldyBvZiBkcmFmdC1pZXRmLWpvc2UtandrLXRodW1icHJpbnQtMDU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCB0aGFuayB5b3Uu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LYXRo bGVlbiZuYnNwOzxicj4NCjxicj4NClNlbnQgZnJvbSBteSBpUGhvbmU8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PGJyPg0KT24gSnVuIDIyLCAyMDE1LCBhdCA5OjE4IFBNLCBNaWtlIEpvbmVzICZs dDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPknigJlkIGJlIGdsYWQgdG8gYWRkIHRoZSBleHBsYW5hdGlvbiBiZWxv dyB0byB0aGUgZHJhZnQgYW5kIHRvIGFsc28gaW5jbHVkZSBhbiBJQU5BIGNvbnNpZGVyYXRpb25z IHNlY3Rpb24gdGhhdCBzdGF0ZXMgd2UgYXJlIHVwZGF0aW5nIHRoZSBleHBlcnQgcmV2aWV3IGlu c3RydWN0aW9ucw0KIGZvciBhIHJlZ2lzdHJ5LCBhcyBKaW0gU2NoYWFkIGhhZCBzdWdnZXN0ZWQu Jm5ic3A7IENoYWlycyBhbmQgS2F0aGxlZW4sIGRvIHlvdSB3YW50IE5hdCBhbmQgSSB0byBwcm9j ZWVkIHRvIHB1Ymxpc2ggYW4gdXBkYXRlZCBkcmFmdD88L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQWRhbSBX LiBNb250dmlsbGUgWzxhIGhyZWY9Im1haWx0bzphZGFtLncubW9udHZpbGxlQGdtYWlsLmNvbSI+ bWFpbHRvOmFkYW0udy5tb250dmlsbGVAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9i PiBGcmlkYXksIEp1bmUgMTIsIDIwMTUgNTowNyBBTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25l czxicj4NCjxiPkNjOjwvYj4gVGhlIElFU0c7IDxhIGhyZWY9Im1haWx0bzpzZWNkaXJAaWV0Zi5v cmciPnNlY2RpckBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWpvc2Ut andrLXRodW1icHJpbnQuYWxsQGlldGYub3JnIj4NCmRyYWZ0LWlldGYtam9zZS1qd2stdGh1bWJw cmludC5hbGxAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9z ZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IHNlY3RvciByZXZpZXcgb2Yg ZHJhZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnByaW50LTA1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSnVuIDExLCAyMDE1LCBhdCA0OjI1IFBNLCBN aWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t Ij5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ SGkgQWRhbSw8YnI+DQo8YnI+DQpUaGFua3MgZm9yIHRoZSBzZWNkaXIgcmV2aWV3Ljxicj4NCjxi cj4NCjxicj4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206IEFkYW0gVy4gTW9udHZpbGxl IFs8YSBocmVmPSJtYWlsdG86YWRhbS53Lm1vbnR2aWxsZUBnbWFpbC5jb20iPm1haWx0bzphZGFt LncubW9udHZpbGxlQGdtYWlsLmNvbTwvYT5dPGJyPg0KU2VudDogTW9uZGF5LCBKdW5lIDA4LCAy MDE1IDg6NDYgQU08YnI+DQpUbzogVGhlIElFU0c7IDxhIGhyZWY9Im1haWx0bzpzZWNkaXJAaWV0 Zi5vcmciPnNlY2RpckBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWpv c2UtandrLXRodW1icHJpbnQuYWxsQGlldGYub3JnIj4NCmRyYWZ0LWlldGYtam9zZS1qd2stdGh1 bWJwcmludC5hbGxAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogc2VjdG9yIHJldmlldyBvZiBk cmFmdC1pZXRmLWpvc2UtandrLXRodW1icHJpbnQtMDU8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8 YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8 YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVu dCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRv IHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiBU aGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4NCiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9m IHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hh aXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3Qg Y2FsbCBjb21tZW50cy48YnI+DQo8YnI+DQpJIGJlbGlldmUgdGhlIGRvY3VtZW50IGlzIHJlYWR5 IHdpdGggKHBvdGVudGlhbCkgaXNzdWVzLiAmbmJzcDtUaGUg4oCcd2l0aCBpc3N1ZXPigJ0gbWln aHQgYmUgZHVlIHRvIGlnbm9yYW5jZSBvbiBteSBwYXJ0LiAmbmJzcDtUaGUgZHJhZnQgZG9lcyBh IHZlcnkgZ29vZCBqb2Igb2YgZXhwbGFpbmluZyB0aGUgY2Fub25pY2FsIGZvcm0gb2YgYSBKU09O IFdlYiBLZXkgdGhhdCBjYW4gYmUgdXNlZCBmb3IgZXN0YWJsaXNoaW5nIGEgdGh1bWJwcmludCB1 bmRlciB2YXJ5aW5nDQogY2lyY3Vtc3RhbmNlcywgY29tcGxldGUgd2l0aCB3aGF0IEkgZm91bmQg dG8gYmUgaGVscGZ1bCBleGFtcGxlcy48YnI+DQo8YnI+DQpUaGUgcHJpbWFyeSBpc3N1ZSBJIGhh dmUgaXMgdGhhdCBpdOKAmXMgdW5jbGVhciBob3cgcmVseWluZyBwYXJ0aWVzIGFyZSBnb2luZyB0 byBrbm93IHdoaWNoIGhhc2ggYWxnb3JpdGhtIGhhcyBiZWVuIHVzZWQuICZuYnNwO1RoZSBleGFt cGxlcyB1c2UgU0hBLTI1NiwgYnV0IEnigJltIG5vdCBzZWVpbmcgd2hlcmUgU0hBLTI1NiBtaWdo dCBiZSBzcGVjaWZpZWQgYXMgYSBNVVNUIG9yIGV2ZW4gYSBTSE9VTEQuICZuYnNwO01vcmVvdmVy LCB0aGUgZXhhbXBsZSBvdXRwdXQNCiB1bHRpbWF0ZWx5IHNob3dzIG9ubHkgdGhlIEJhc2UtNjQg ZW5jb2Rpbmcgb2YgdGhlIHJlc3VsdGluZyBoYXNoLCB3aGljaCBzYXlzIG5vdGhpbmcgYWJvdXQg dGhlIGFsZ29yaXRobSB1c2VkIHRvIGlkZW50aWZ5IGEga2V5Ljwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxi cj4NCkVhcmxpZXIgZHJhZnRzIGhhZCBpbmNsdWRlZCBmaWVsZHMgd2hvc2UgbmFtZXMgd2VyZSBp bnRlbmRlZCB0byBjb21tdW5pY2F0ZSB0aGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGhhc2ggZnVu Y3Rpb24gdXNlZCAtIHNlZSB0aGUgJnF1b3Q7amt0JnF1b3Q7IGZpZWxkIGRlZmluaXRpb25zIGlu PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48 YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtandrLXRo dW1icHJpbnQtMDEjc2VjdGlvbi00Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtandrLXRodW1icHJpbnQtMDEj c2VjdGlvbi00PC9zcGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPi0NCiBidXQgc2V2ZXJhbCB3b3JraW5nIGdyb3VwIHJldmll d2VycyBzdWdnZXN0ZWQgdGhhdCB0aGVzZSBmaWVsZHMgd2VyZSB1bm5lY2Vzc2FyeSBhbmQgdGhh dCB0aGUgdHlwaWNhbCB1c2FnZSB3b3VsZCBiZSBhcyAmcXVvdDtraWQmcXVvdDsgKGtleSBJRCkg ZmllbGQgdmFsdWVzLiAmbmJzcDtXaXRoIHRoYXQgcmVtb3ZhbCwgaXQgZmFsbHMgb250byB0aGUg YXBwbGljYXRpb24gdG8gc3BlY2lmeSB0aGUgaGFzaCBhbGdvcml0aG0gZm9yIGl0cyBwYXJ0aWN1 bGFyIHVzYWdlLjxicj4NCjxicj4NClRoaXMgaXNuJ3QgYXMgYmFkIGFzIHlvdSBtaWdodCB0aGlu aywgaG93ZXZlciwgYmVjYXVzZSB0eXBpY2FsbHkgdGhlIGNvbnN1bWVyIG9mIHRoZSAmcXVvdDtr aWQmcXVvdDsgZG9lc24ndCBuZWVkIHRvIGtub3cgdGhlIGFsZ29yaXRobSBiZWNhdXNlIGl0IHdv bid0IGJlIHJlcHJvZHVjaW5nIHRoZSBjb21wdXRhdGlvbi4gJm5ic3A7SXQganVzdCByZWxpZXMg b24gdGhlIGZhY3QgdGhhdCBhIHVuaXF1ZSBrZXkgSUQgdmFsdWUgd2FzIGdlbmVyYXRlZCBmb3Ig dGhlIGtleSBhbmQNCiBjb21wYXJlcyAmcXVvdDtraWQmcXVvdDsgdmFsdWVzIGFzIG9wYXF1ZSBz dHJpbmdzIHRvIGZpbmQgdGhlIGFwcHJvcHJpYXRlIGtleS4gJm5ic3A7SW4gdGhpcyB1c2FnZSwg dGhlIHByb2R1Y2VyIG9mIHRoZSBrZXkgaXMgdGhlIG9ubHkgcGFydHkgdGhhdCBuZWVkcyB0byBr bm93IHRoZSBoYXNoIGFsZ29yaXRobSB0aGF0IGl0IGlzIHVzaW5nLiAmbmJzcDtJIGhvcGUgdGhp cyBoZWxwcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgdGhpcyBkb2VzIGhlbHAsIHRoYW5rIHlv dS4gJm5ic3A7SXQgc2VlbXMgbGlrZSBzb21ldGhpbmcgdGhhdCBjb3VsZCBiZSBlYXNpbHkgYWRk ZWQgdG8gdGhlIGRyYWZ0IHRvIGV4cGxhaW4gd2h5IHRoZSBnZW5lcmF0aW5nIGFsZ29yaXRobSBu ZWVkbuKAmXQgYmUgZGlzY2xvc2VkIHNvIHRoYXQgc2xvdyBmb2xrIGxpa2UgbXlzZWxmIGdldCB0 aGUgcGljdHVyZSBzdHJhaWdodCBhd2F5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4N Cjxicj4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFkZGl0aW9uYWxseSwgaW4gU2VjdGlvbiA0 LCDigJxKU09OIGFuZCBVbmljb2RlIENvbnNpZGVyYXRpb25z4oCdIHNvbWUg4oCcc2hvdWxk4oCd cyBhcmUgdXNlZCwgYnV0IEnigJltIG5vdCByZWFkaW5nIHRoZW0gYXMgU0hPVUxEcy4gU2hvdWxk IHRoZXkgYmUgU0hPVUxEcz8gJm5ic3A7Rm9yIGV4YW1wbGUsIHRoZSBzdGFydA0KIG9mIHRoZSB0 aGlyZCBwYXJhZ3JhcGggaW4gdGhhdCBzZWN0aW9uOiDigJxpZiBuZXcgSldLIG1lbWJlcnMgYXJl IGRlZmluZWQgdGhhdCB1c2Ugbm9uLUFTQ0lJIG1lbWJlciBuYW1lcywgdGhlaXIgZGVmaW5pdGlv bnMgc2hvdWxkIHNwZWNpZnkgdGhlIGV4YWN0IFVuaWNvZGUgY29kZSBwb2ludCBzZXF1ZW5jZXMg dXNlZCB0byByZXByZXNlbnQgdGhlbS7igJ0gJm5ic3A7SXTigJlzIG5vdCBjbGVhciB0byBtZSB3 aGV0aGVyIHRoaXMgaXMgYSBzdHJvbmcgc3RhdGVtZW50DQogb3IganVzdCBhIHJlY29tbWVuZGF0 aW9uIC0gaXQgc2VlbXMgdGhhdCB0aGlzIGRyYWZ0IGNvdWxkIGhlbHAgdGhlIGZ1dHVyZSBieSBt YWtpbmcgc3Ryb25nZXIgc3RhdGVtZW50cyB0byBlbmNvdXJhZ2UgZnV0dXJlIGludGVyb3BlcmFi aWxpdHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KRm9yIHRoZSBvdGhlciBKT1NFIHNwZWNpZmlj YXRpb25zLCBvdXIgY2hhaXIgSmltIFNjaGFhZCB0b29rIHRoZSBwb3NpdGlvbiB0aGF0IFJGQyAy MTE5IGtleXdvcmRzIHNob3VsZCBiZSByZXNlcnZlZCBmb3IgdGVzdGFibGUgcHJvdG9jb2wgYmVo YXZpb3JzIGFuZCB0aGF0IG90aGVyIHVzZXMgb2YgdGhlIEVuZ2xpc2ggd29yZCAmcXVvdDtzaG91 bGQmcXVvdDsgc2hvdWxkIG5vdCB1c2UgJnF1b3Q7U0hPVUxEJnF1b3Q7LiAmbmJzcDtUaGUgYXV0 aG9ycyBmb2xsb3dlZCB0aGF0IGNvbnZlbnRpb24NCiBpbiB0aGlzIGRvY3VtZW50LiAmbmJzcDtJ IGRvIHVuZGVyc3RhbmQgdGhhdCBvdGhlciBhdXRob3JzIGFuZCB3b3JraW5nIGdyb3VwcyBoYXZl IHRha2VuIGRpZmZlcmVudCBwb3NpdGlvbnMgaW4gdGhpcyByZWdhcmQuICZuYnNwO0lmIHRoZXJl IGFyZSBwYXJ0aWN1bGFyIHVzZXMgdGhhdCB5b3Ugc3RpbGwgZmVlbCBzaG91bGQgYmUgY2hhbmdl ZCB0byB1c2UgUkZDIDIxMTkga2V5d29yZHMsIHBsZWFzZSBjYWxsIHRoZW0gb3V0Ljwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhp cyBpcyBhbGwgZ29vZCwgdG9vLiAmbmJzcDtJIHdhcyBzaW1wbHkgcG9pbnRpbmcgb3V0IHRoYXQg dGhlcmUgYXJlIOKAnHNob3VsZOKAnXMgYXJvdW5kIHRoYXQgbWF5IG5lZWQgdG8gYmUgY29uc2lk ZXJlZCBhcyDigJxTSE9VTETigJ1zLiBJIGFsc28gc2VlIEppbeKAmXMgKGFuZCBvdGhlcnPigJkp IHN1YnNlcXVlbnQgbm90ZXMgb24gdGhlIHN1YmplY3QsIHNvIHRoaXMgaXMgZ29vZCBmcm9tIG15 IHBlcnNwZWN0aXZlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQo8YnI+DQo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5LaW5kIHJlZ2FyZHMsPGJyPg0KQWRhbTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pjxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+VGhhbmtzIGFnYWluITxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+LS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY2PR03MB44275C31276DFF36611D67DF5AF0BY2PR03MB442namprd_-- From nobody Wed Jun 24 05:12:12 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501031A8A0E; Wed, 24 Jun 2015 05:12:06 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNvex3SgnfBR; Wed, 24 Jun 2015 05:12:03 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBFE71A89FB; Wed, 24 Jun 2015 05:12:02 -0700 (PDT) Received: by oiax193 with SMTP id x193so28247723oia.2; Wed, 24 Jun 2015 05:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=lo6xcEmpXTUKrVG8yN5UGZWH+K8fTeZGFlClQwBh+kY=; b=CZZJX+DB1JPiskbev95o6Ceojj6W9pPEFYV97Op/W8kAgwTEGFxHrRR/IHJ22/zyKC 7KF8lqVfE3SGHSIPnokXCZ9W885JOCvWTUIB/dlJC0/VuNW+D5YeE1dVMU1au1zuqx0Q njaCHCaxw4kqtvgaElILT2AKulMNUs6APngjDeyZSQb9IBbceJBcB5Z7rr3hWwlSpWLU d8/Yp0c09HVQoRGFWe2G2zkMV/SfmSegE9wlsYdfGD409dSTAHbsX/KUrT/J97GPd93N Mu3N1P/bV5Dt36lWxfEAPiICQjF8UmgtHaVv1rB3hqeBiclZ1ty2zvMJiMiUF36DiCQ0 F0bQ== X-Received: by 10.202.87.134 with SMTP id l128mr8591043oib.83.1435147922407; Wed, 24 Jun 2015 05:12:02 -0700 (PDT) Received: from adams-mac-mini.attlocal.net ([2602:306:3406:4830:b059:3770:4dda:970e]) by mx.google.com with ESMTPSA id k129sm14032408oia.14.2015.06.24.05.11.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jun 2015 05:12:01 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_AFF50B74-E35C-4317-9037-F9F5CA66C996" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: "Adam W. Montville" In-Reply-To: Date: Wed, 24 Jun 2015 07:11:58 -0500 Message-Id: References: <4CA0A65D-E5FD-408C-A6B9-6ECB12A81B7C@gmail.com> To: Mike Jones X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "draft-ietf-jose-jwk-thumbprint.all@ietf.org" , The IESG , "jose@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] sector review of draft-ietf-jose-jwk-thumbprint-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 12:12:06 -0000 --Apple-Mail=_AFF50B74-E35C-4317-9037-F9F5CA66C996 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Nat and Mike, Thanks for your attention on this issue. I see the following text in = section 3.4: Note that in many cases, only the party that creates a key will need to know the hash function used. A typical usage is for the producer of the key to use the base64url-encoded JWK Thumbprint value as a "kid" (key ID) value. The consumer of the "kid" treats it as an opaque value that it uses to select the key. Only if multiple parties will be reproducing the JWK Thumbprint calculation for some reason, will parties other than the original producer of the JWK Thumbprint need to know which hash function was used. Would it make the draft clearer if that last sentence were omitted? The = way this paragraph reads is such that draft considers and would allow = for multiple parties generating key IDs, but then we=E2=80=99re back at = not knowing which algorithm was chosen. If that last sentence were = omitted, this would be less of an issue. =20 > On Jun 24, 2015, at 3:40 AM, Mike Jones = wrote: >=20 > Hi Adam, > =20 > Thanks again for your review comments. = https://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-06 = has been = posted to address them. See sections 3.4 (Selection of Hash Function) = and 6 (IANA Considerations). > =20 > Thanks = again, > -- Nat and = Mike > =20 > From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]=20 > Sent: Monday, June 22, 2015 12:51 PM > To: Mike Jones > Cc: Adam W. Montville; The IESG; secdir@ietf.org; = draft-ietf-jose-jwk-thumbprint.all@ietf.org; jose@ietf.org > Subject: Re: sector review of draft-ietf-jose-jwk-thumbprint-05 > =20 > Yes, thank you. > Kathleen=20 >=20 > Sent from my iPhone >=20 > On Jun 22, 2015, at 9:18 PM, Mike Jones > wrote: >=20 > I=E2=80=99d be glad to add the explanation below to the draft and to = also include an IANA considerations section that states we are updating = the expert review instructions for a registry, as Jim Schaad had = suggested. Chairs and Kathleen, do you want Nat and I to proceed to = publish an updated draft? > =20 > -- = Mike > =20 > From: Adam W. Montville [mailto:adam.w.montville@gmail.com = ]=20 > Sent: Friday, June 12, 2015 5:07 AM > To: Mike Jones > Cc: The IESG; secdir@ietf.org ; = draft-ietf-jose-jwk-thumbprint.all@ietf.org = ; jose@ietf.org = > Subject: Re: sector review of draft-ietf-jose-jwk-thumbprint-05 > =20 > =20 > On Jun 11, 2015, at 4:25 PM, Mike Jones > wrote: > =20 > Hi Adam, >=20 > Thanks for the secdir review. >=20 >=20 >=20 > From: Adam W. Montville [mailto:adam.w.montville@gmail.com = ] > Sent: Monday, June 08, 2015 8:46 AM > To: The IESG; secdir@ietf.org ; = draft-ietf-jose-jwk-thumbprint.all@ietf.org = > Subject: sector review of draft-ietf-jose-jwk-thumbprint-05 >=20 >=20 >=20 > Hi, >=20 >=20 >=20 > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >=20 > I believe the document is ready with (potential) issues. The =E2=80=9Cw= ith issues=E2=80=9D might be due to ignorance on my part. The draft = does a very good job of explaining the canonical form of a JSON Web Key = that can be used for establishing a thumbprint under varying = circumstances, complete with what I found to be helpful examples. >=20 > The primary issue I have is that it=E2=80=99s unclear how relying = parties are going to know which hash algorithm has been used. The = examples use SHA-256, but I=E2=80=99m not seeing where SHA-256 might be = specified as a MUST or even a SHOULD. Moreover, the example output = ultimately shows only the Base-64 encoding of the resulting hash, which = says nothing about the algorithm used to identify a key. >=20 > Earlier drafts had included fields whose names were intended to = communicate the information about the hash function used - see the "jkt" = field definitions in = http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-01#section-4 = = - but several working group reviewers suggested that these fields were = unnecessary and that the typical usage would be as "kid" (key ID) field = values. With that removal, it falls onto the application to specify the = hash algorithm for its particular usage. >=20 > This isn't as bad as you might think, however, because typically the = consumer of the "kid" doesn't need to know the algorithm because it = won't be reproducing the computation. It just relies on the fact that a = unique key ID value was generated for the key and compares "kid" values = as opaque strings to find the appropriate key. In this usage, the = producer of the key is the only party that needs to know the hash = algorithm that it is using. I hope this helps. > =20 > Yes, this does help, thank you. It seems like something that could be = easily added to the draft to explain why the generating algorithm = needn=E2=80=99t be disclosed so that slow folk like myself get the = picture straight away. > =20 >=20 >=20 >=20 >=20 >=20 >=20 > Additionally, in Section 4, =E2=80=9CJSON and Unicode = Considerations=E2=80=9D some =E2=80=9Cshould=E2=80=9Ds are used, but = I=E2=80=99m not reading them as SHOULDs. Should they be SHOULDs? For = example, the start of the third paragraph in that section: =E2=80=9Cif = new JWK members are defined that use non-ASCII member names, their = definitions should specify the exact Unicode code point sequences used = to represent them.=E2=80=9D It=E2=80=99s not clear to me whether this = is a strong statement or just a recommendation - it seems that this = draft could help the future by making stronger statements to encourage = future interoperability. >=20 > For the other JOSE specifications, our chair Jim Schaad took the = position that RFC 2119 keywords should be reserved for testable protocol = behaviors and that other uses of the English word "should" should not = use "SHOULD". The authors followed that convention in this document. I = do understand that other authors and working groups have taken different = positions in this regard. If there are particular uses that you still = feel should be changed to use RFC 2119 keywords, please call them out. > =20 > This is all good, too. I was simply pointing out that there are = =E2=80=9Cshould=E2=80=9Ds around that may need to be considered as = =E2=80=9CSHOULD=E2=80=9Ds. I also see Jim=E2=80=99s (and others=E2=80=99) = subsequent notes on the subject, so this is good from my perspective. >=20 >=20 >=20 >=20 >=20 >=20 > Kind regards, > Adam >=20 > Thanks = again! > -- = Mike --Apple-Mail=_AFF50B74-E35C-4317-9037-F9F5CA66C996 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Nat and Mike,

Thanks for your attention on this issue.  I see the = following text in section 3.4:

Note that in many = cases, only the party that creates a key will need
   to know the hash function used.  A typical = usage is for the producer
   of the key = to use the base64url-encoded JWK Thumbprint value as a
   "kid" (key ID) value.  The consumer of the = "kid" treats it as an
   opaque value = that it uses to select the key.  Only if multiple
   parties will be reproducing the JWK Thumbprint = calculation for some
   reason, will = parties other than the original producer of the JWK
   Thumbprint need to know which hash function was = used.


Would it make the draft clearer if that = last sentence were omitted?  The way this paragraph reads is such = that draft considers and would allow for multiple parties generating key = IDs, but then we=E2=80=99re back at not knowing which algorithm was = chosen.  If that last sentence were omitted, this would be less of = an issue.  


On Jun 24, 2015, at 3:40 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Hi Adam,
 
Thanks again for your = review comments.  https://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-06 has been posted to = address them.  See sections 3.4 (Selection of Hash Function) and 6 = (IANA Considerations).
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = Thanks again,
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            -- = Nat and Mike
From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] 
Sent: Monday, June 22, 2015 12:51 = PM
To: Mike Jones
Cc: Adam = W. Montville; The IESG; secdir@ietf.org; draft-ietf-jose-jwk-thumbprint.all@ietf.org; jose@ietf.org
Subject: Re: sector review of = draft-ietf-jose-jwk-thumbprint-05
 
Yes, thank you.
Kathleen 

Sent from my = iPhone


On Jun 22, 2015, = at 9:18 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I=E2=80=99d be glad to = add the explanation below to the draft and to also include an IANA = considerations section that states we are updating the expert review = instructions for a registry, as Jim Schaad had suggested.  Chairs = and Kathleen, do you want Nat and I to proceed to publish an updated = draft?
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
From: Adam W. = Montville [mailto:adam.w.montville@gmail.com] 
Sent: Friday, June 12, 2015 5:07 = AM
To: Mike Jones
Cc: The = IESG; secdir@ietf.org; draft-ietf-jose-jwk-thumbprint.all@ietf.org; jose@ietf.org
Subject: Re: sector review of = draft-ietf-jose-jwk-thumbprint-05
 
 
On Jun 11, 2015, at = 4:25 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
 
Hi Adam,
Thanks for the secdir review.


From: Adam W. Montville = [mailto:adam.w.montville@gmail.com]
Sent: = Monday, June 08, 2015 8:46 AM
To: The IESG; secdir@ietf.org; draft-ietf-jose-jwk-thumbprint.all@ietf.org
Subject: sector review of = draft-ietf-jose-jwk-thumbprint-05



Hi,



I= have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments.

I believe the document is ready with (potential) issues. =  The =E2=80=9Cwith issues=E2=80=9D might be due to ignorance on my = part.  The draft does a very good job of explaining the canonical = form of a JSON Web Key that can be used for establishing a thumbprint = under varying circumstances, complete with what I found to be helpful = examples.

The primary issue I have is that = it=E2=80=99s unclear how relying parties are going to know which hash = algorithm has been used.  The examples use SHA-256, but I=E2=80=99m = not seeing where SHA-256 might be specified as a MUST or even a SHOULD. =  Moreover, the example output ultimately shows only the Base-64 = encoding of the resulting hash, which says nothing about the algorithm = used to identify a key.

Earlier = drafts had included fields whose names were intended to communicate the = information about the hash function used - see the "jkt" field = definitions in http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-01#se= ction-4 - but several working = group reviewers suggested that these fields were unnecessary and that = the typical usage would be as "kid" (key ID) field values.  With = that removal, it falls onto the application to specify the hash = algorithm for its particular usage.

This = isn't as bad as you might think, however, because typically the consumer = of the "kid" doesn't need to know the algorithm because it won't be = reproducing the computation.  It just relies on the fact that a = unique key ID value was generated for the key and compares "kid" values = as opaque strings to find the appropriate key.  In this usage, the = producer of the key is the only party that needs to know the hash = algorithm that it is using.  I hope this helps.
 
Yes, this does help, thank you.  It seems like something = that could be easily added to the draft to explain why the generating = algorithm needn=E2=80=99t be disclosed so that slow folk like myself get = the picture straight away.
 






Additionally, in Section 4, =E2=80=9CJSON and Unicode = Considerations=E2=80=9D some =E2=80=9Cshould=E2=80=9Ds are used, but = I=E2=80=99m not reading them as SHOULDs. Should they be SHOULDs? =  For example, the start of the third paragraph in that section: = =E2=80=9Cif new JWK members are defined that use non-ASCII member names, = their definitions should specify the exact Unicode code point sequences = used to represent them.=E2=80=9D  It=E2=80=99s not clear to me = whether this is a strong statement or just a recommendation - it seems = that this draft could help the future by making stronger statements to = encourage future interoperability.

For the = other JOSE specifications, our chair Jim Schaad took the position that = RFC 2119 keywords should be reserved for testable protocol behaviors and = that other uses of the English word "should" should not use "SHOULD". =  The authors followed that convention in this document.  I do = understand that other authors and working groups have taken different = positions in this regard.  If there are particular uses that you = still feel should be changed to use RFC 2119 keywords, please call them = out.
 
This is all good, too.  I was simply pointing out that = there are =E2=80=9Cshould=E2=80=9Ds around that may need to be = considered as =E2=80=9CSHOULD=E2=80=9Ds. I also see Jim=E2=80=99s (and = others=E2=80=99) subsequent notes on the subject, so this is good from = my perspective.






Kind regards,
Adam

        &= nbsp;       =             &n= bsp;   =             &n= bsp;   =             &n= bsp;   Thanks again!
        &= nbsp;       =             &n= bsp;   =             &n= bsp;   =             &n= bsp;   -- = Mike
<= /div>
= --Apple-Mail=_AFF50B74-E35C-4317-9037-F9F5CA66C996-- From nobody Wed Jun 24 08:42:38 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C191ACCDF for ; Wed, 24 Jun 2015 08:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSw8F_aPPoSu for ; Wed, 24 Jun 2015 08:42:35 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [217.34.220.150]) by ietfa.amsl.com (Postfix) with ESMTP id B00131ACD00 for ; Wed, 24 Jun 2015 08:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1435160555; d=isode.com; s=selector; i=@isode.com; bh=6/+7TZn+OYhyJd07ehdIAtnSoGyY9B5PkGat1/7fEqg=; 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=q3okRoZrT2Sz2P9CA7Ufu0AUq/StAsIrbfP6I37NBaX+Uv+Jk5jY3+B3rRd50OeiUPRVZi FfOI2hO8WxtXeG/7BkkJU362WUv0gHh91FAcwItZ9tT5ahOLbDOFlSQRzvHCNGA2CYK433 /c2+r34mugC7n4aKDJFtpR0xYBTqQcc=; 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, 24 Jun 2015 16:42:34 +0100 Message-ID: <558ACFDE.5000109@isode.com> Date: Wed, 24 Jun 2015 16:42:22 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 To: IETF Security Directorate , draft-ietf-avtcore-rtp-topologies-update.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] SecDir review of draft-ietf-avtcore-rtp-topologies-update-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 15:42:37 -0000 (My apologies for doing the review late.) I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document discusses point to point and multi-endpoint topologies used in Real-time Transport Protocol (RTP)-based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. This document is updated with additional topologies and replaces RFC 5117. Summary The document is well written and has lots of useful security related details. I have very passing familiarity with RTP/RTCP, but the Security Considerations looks reasonable to me. From nobody Wed Jun 24 10:49:24 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847AF1A90F4; Wed, 24 Jun 2015 10:49:18 -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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqXqf7r_M7kk; Wed, 24 Jun 2015 10:49:14 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0741.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F8F1A90C8; Wed, 24 Jun 2015 10:49:14 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.201.16; Wed, 24 Jun 2015 17:49:09 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0201.000; Wed, 24 Jun 2015 17:49:09 +0000 From: Mike Jones To: "Adam W. Montville" Thread-Topic: sector review of draft-ietf-jose-jwk-thumbprint-05 Thread-Index: AQHQogJgaphBjlti2Uu758g0GQEF3p2nztYwgAD9kwCAEC+K8IAACaYAgAJomRCAADu4AIAAWqTQ Date: Wed, 24 Jun 2015 17:49:09 +0000 Message-ID: References: <4CA0A65D-E5FD-408C-A6B9-6ECB12A81B7C@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:T5XR2Z6cg1XHw5E9RoOhGEuEiYhj0B9jxOZjEKEQOXkRcdiOCVdguv9VmPPAsTgqSLmWPE1KweYYtS3laVjehJldiWR1rHmyGDCpBFk8grZJIXIJKdrlo8S9DRfEyPeKbJcZzeT9CJs11ca9IaC8Jg==; 24:6ZnGb7rtnUxftR+wJXtG9MzSJjw0lhDfQHcwNHEi8gskS7ZxZ0sdXCCoWjeIE3ZJ7t/QEQ28UDuslthlcGwm7ELOumeQKF9cPKu9rJBg2UE=; 20:AjAVzixk2GG1LZOI0gBx8Qjp1/KD2M9IUqv/8SyGQvPA56Ow+X/OIQv8mpLnSlaJFMPOuMT7NaAkHfLiUGySkw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 061725F016 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(51914003)(43784003)(71364002)(46102003)(19625215002)(2656002)(54356999)(87936001)(76576001)(33656002)(40100003)(230783001)(86362001)(16236675004)(74316001)(5003630100001)(5003600100002)(92566002)(106116001)(19580405001)(19300405004)(19580395003)(99286002)(62966003)(77156002)(76176999)(5002640100001)(93886004)(19617315012)(77096005)(66066001)(15975445007)(102836002)(50986999)(86612001)(5001920100001)(110136002)(5001960100002)(189998001)(2900100001)(122556002)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4421B3C0A9973108C1F7B6AF5AF0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2015 17:49:09.1173 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: "draft-ietf-jose-jwk-thumbprint.all@ietf.org" , The IESG , "jose@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] sector review of draft-ietf-jose-jwk-thumbprint-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 17:49:18 -0000 --_000_BY2PR03MB4421B3C0A9973108C1F7B6AF5AF0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWRhbSwNCg0KSSB0YWtlIHlvdXIgcG9pbnQgdGhhdCB0aGUgcGFyYWdyYXBoIHdvdWxkIHNl ZW0gc2ltcGxlciB3aXRob3V0IHRoZSBsYXN0IHNlbnRlbmNlLCBidXQgSeKAmWQgcmF0aGVyIGVy ciBvbiB0aGUgc2lkZSBvZiBnaXZpbmcgcmVhZGVycyBtb3JlIGluZm9ybWF0aW9uIHRoYW4gbGVz cy4gIFdoaWxlIGluIG1hbnkgY2FzZXMga25vd2xlZGdlIG9mIHRoZSBoYXNoIGZ1bmN0aW9uIHVz ZWQgbmVlZCBub3QgYmUgcHJvcGFnYXRlZCAocGVyIHRoZSBleGFtcGxlIGluIHRoZSBiZWdpbm5p bmcgb2YgdGhlIHBhcmFncmFwaCksIHNvbWV0aW1lcyBpdCBkb2VzLiAgU28gTmF0IGFuZCBJIGRl Y2lkZWQgdG8gYWxzbyBpbmNsdWRlIGEgc2VudGVuY2UgYWJvdXQgd2hlbiBpdCBkb2VzLiAgUGVy IHRoZSBwcmV2aW91cyBwYXJhZ3JhcGgsIHdoaWNoIGhhc2ggZnVuY3Rpb24gdG8gdXNlIGlzIGFu IGFwcGxpY2F0aW9uIGNob2ljZS4NCg0KRnJvbSB0aGF0IHZpZXdwb2ludCwgZG9lcyB0aGUgY3Vy cmVudCBwYXJhZ3JhcGggd29yayBmb3IgeW91LCBvciBpcyB0aGVyZSBhIHNwZWNpZmljIHdvcmRp bmcgY2hhbmdlIHRoYXQgeW914oCZZCBzdGlsbCBsaWtlIHRvIHNlZT8NCg0KVGhhbmtzIGFnYWlu IGZvciB5b3VyIHJldmlldyENCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBBZGFtIFcuIE1vbnR2aWxs ZSBbbWFpbHRvOmFkYW0udy5tb250dmlsbGVAZ21haWwuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBK dW5lIDI0LCAyMDE1IDU6MTIgQU0NClRvOiBNaWtlIEpvbmVzDQpDYzogVGhlIElFU0c7IHNlY2Rp ckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnByaW50LmFsbEBpZXRmLm9yZzsg am9zZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IHNlY3RvciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1q b3NlLWp3ay10aHVtYnByaW50LTA1DQoNCkhpIE5hdCBhbmQgTWlrZSwNCg0KVGhhbmtzIGZvciB5 b3VyIGF0dGVudGlvbiBvbiB0aGlzIGlzc3VlLiAgSSBzZWUgdGhlIGZvbGxvd2luZyB0ZXh0IGlu IHNlY3Rpb24gMy40Og0KDQpOb3RlIHRoYXQgaW4gbWFueSBjYXNlcywgb25seSB0aGUgcGFydHkg dGhhdCBjcmVhdGVzIGEga2V5IHdpbGwgbmVlZA0KICAgdG8ga25vdyB0aGUgaGFzaCBmdW5jdGlv biB1c2VkLiAgQSB0eXBpY2FsIHVzYWdlIGlzIGZvciB0aGUgcHJvZHVjZXINCiAgIG9mIHRoZSBr ZXkgdG8gdXNlIHRoZSBiYXNlNjR1cmwtZW5jb2RlZCBKV0sgVGh1bWJwcmludCB2YWx1ZSBhcyBh DQogICAia2lkIiAoa2V5IElEKSB2YWx1ZS4gIFRoZSBjb25zdW1lciBvZiB0aGUgImtpZCIgdHJl YXRzIGl0IGFzIGFuDQogICBvcGFxdWUgdmFsdWUgdGhhdCBpdCB1c2VzIHRvIHNlbGVjdCB0aGUg a2V5LiAgT25seSBpZiBtdWx0aXBsZQ0KICAgcGFydGllcyB3aWxsIGJlIHJlcHJvZHVjaW5nIHRo ZSBKV0sgVGh1bWJwcmludCBjYWxjdWxhdGlvbiBmb3Igc29tZQ0KICAgcmVhc29uLCB3aWxsIHBh cnRpZXMgb3RoZXIgdGhhbiB0aGUgb3JpZ2luYWwgcHJvZHVjZXIgb2YgdGhlIEpXSw0KICAgVGh1 bWJwcmludCBuZWVkIHRvIGtub3cgd2hpY2ggaGFzaCBmdW5jdGlvbiB3YXMgdXNlZC4NCg0KDQpX b3VsZCBpdCBtYWtlIHRoZSBkcmFmdCBjbGVhcmVyIGlmIHRoYXQgbGFzdCBzZW50ZW5jZSB3ZXJl IG9taXR0ZWQ/ICBUaGUgd2F5IHRoaXMgcGFyYWdyYXBoIHJlYWRzIGlzIHN1Y2ggdGhhdCBkcmFm dCBjb25zaWRlcnMgYW5kIHdvdWxkIGFsbG93IGZvciBtdWx0aXBsZSBwYXJ0aWVzIGdlbmVyYXRp bmcga2V5IElEcywgYnV0IHRoZW4gd2XigJlyZSBiYWNrIGF0IG5vdCBrbm93aW5nIHdoaWNoIGFs Z29yaXRobSB3YXMgY2hvc2VuLiAgSWYgdGhhdCBsYXN0IHNlbnRlbmNlIHdlcmUgb21pdHRlZCwg dGhpcyB3b3VsZCBiZSBsZXNzIG9mIGFuIGlzc3VlLg0KDQoNCk9uIEp1biAyNCwgMjAxNSwgYXQg Mzo0MCBBTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCg0KSGkgQWRhbSwNCg0KVGhhbmtz IGFnYWluIGZvciB5b3VyIHJldmlldyBjb21tZW50cy4gIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWpvc2UtandrLXRodW1icHJpbnQtMDYgaGFzIGJlZW4gcG9zdGVkIHRv IGFkZHJlc3MgdGhlbS4gIFNlZSBzZWN0aW9ucyAzLjQgKFNlbGVjdGlvbiBvZiBIYXNoIEZ1bmN0 aW9uKSBhbmQgNiAoSUFOQSBDb25zaWRlcmF0aW9ucykuDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcyBhZ2FpbiwNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC0tIE5hdCBhbmQgTWlrZQ0KDQpGcm9tOiBLYXRobGVlbiBNb3JpYXJ0eSBbbWFpbHRvOmthdGhs ZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tXQ0KU2VudDogTW9uZGF5LCBKdW5lIDIyLCAyMDE1 IDEyOjUxIFBNDQpUbzogTWlrZSBKb25lcw0KQ2M6IEFkYW0gVy4gTW9udHZpbGxlOyBUaGUgSUVT Rzsgc2VjZGlyQGlldGYub3JnPG1haWx0bzpzZWNkaXJAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWpv c2UtandrLXRodW1icHJpbnQuYWxsQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWpvc2Utandr LXRodW1icHJpbnQuYWxsQGlldGYub3JnPjsgam9zZUBpZXRmLm9yZzxtYWlsdG86am9zZUBpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBzZWN0b3IgcmV2aWV3IG9mIGRyYWZ0LWlldGYtam9zZS1qd2st dGh1bWJwcmludC0wNQ0KDQpZZXMsIHRoYW5rIHlvdS4NCkthdGhsZWVuDQoNClNlbnQgZnJvbSBt eSBpUGhvbmUNCg0KT24gSnVuIDIyLCAyMDE1LCBhdCA5OjE4IFBNLCBNaWtlIEpvbmVzIDxNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bT4+IHdyb3RlOg0KSeKAmWQgYmUgZ2xhZCB0byBhZGQgdGhlIGV4cGxhbmF0aW9uIGJlbG93IHRv IHRoZSBkcmFmdCBhbmQgdG8gYWxzbyBpbmNsdWRlIGFuIElBTkEgY29uc2lkZXJhdGlvbnMgc2Vj dGlvbiB0aGF0IHN0YXRlcyB3ZSBhcmUgdXBkYXRpbmcgdGhlIGV4cGVydCByZXZpZXcgaW5zdHJ1 Y3Rpb25zIGZvciBhIHJlZ2lzdHJ5LCBhcyBKaW0gU2NoYWFkIGhhZCBzdWdnZXN0ZWQuICBDaGFp cnMgYW5kIEthdGhsZWVuLCBkbyB5b3Ugd2FudCBOYXQgYW5kIEkgdG8gcHJvY2VlZCB0byBwdWJs aXNoIGFuIHVwZGF0ZWQgZHJhZnQ/DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IEFkYW0gVy4g TW9udHZpbGxlIFttYWlsdG86YWRhbS53Lm1vbnR2aWxsZUBnbWFpbC5jb21dDQpTZW50OiBGcmlk YXksIEp1bmUgMTIsIDIwMTUgNTowNyBBTQ0KVG86IE1pa2UgSm9uZXMNCkNjOiBUaGUgSUVTRzsg c2VjZGlyQGlldGYub3JnPG1haWx0bzpzZWNkaXJAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWpvc2Ut andrLXRodW1icHJpbnQuYWxsQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWpvc2UtandrLXRo dW1icHJpbnQuYWxsQGlldGYub3JnPjsgam9zZUBpZXRmLm9yZzxtYWlsdG86am9zZUBpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBzZWN0b3IgcmV2aWV3IG9mIGRyYWZ0LWlldGYtam9zZS1qd2stdGh1 bWJwcmludC0wNQ0KDQoNCk9uIEp1biAxMSwgMjAxNSwgYXQgNDoyNSBQTSwgTWlrZSBKb25lcyA8 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb20+PiB3cm90ZToNCg0KSGkgQWRhbSwNCg0KVGhhbmtzIGZvciB0aGUgc2VjZGlyIHJldmll dy4NCg0KDQoNCg0KRnJvbTogQWRhbSBXLiBNb250dmlsbGUgW21haWx0bzphZGFtLncubW9udHZp bGxlQGdtYWlsLmNvbV0NClNlbnQ6IE1vbmRheSwgSnVuZSAwOCwgMjAxNSA4OjQ2IEFNDQpUbzog VGhlIElFU0c7IHNlY2RpckBpZXRmLm9yZzxtYWlsdG86c2VjZGlyQGlldGYub3JnPjsgZHJhZnQt aWV0Zi1qb3NlLWp3ay10aHVtYnByaW50LmFsbEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1q b3NlLWp3ay10aHVtYnByaW50LmFsbEBpZXRmLm9yZz4NClN1YmplY3Q6IHNlY3RvciByZXZpZXcg b2YgZHJhZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnByaW50LTA1DQoNCg0KDQoNCkhpLA0KDQoNCg0K DQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBk aXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMg YmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4g cHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMu IERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVu dHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNCkkgYmVsaWV2ZSB0 aGUgZG9jdW1lbnQgaXMgcmVhZHkgd2l0aCAocG90ZW50aWFsKSBpc3N1ZXMuICBUaGUg4oCcd2l0 aCBpc3N1ZXPigJ0gbWlnaHQgYmUgZHVlIHRvIGlnbm9yYW5jZSBvbiBteSBwYXJ0LiAgVGhlIGRy YWZ0IGRvZXMgYSB2ZXJ5IGdvb2Qgam9iIG9mIGV4cGxhaW5pbmcgdGhlIGNhbm9uaWNhbCBmb3Jt IG9mIGEgSlNPTiBXZWIgS2V5IHRoYXQgY2FuIGJlIHVzZWQgZm9yIGVzdGFibGlzaGluZyBhIHRo dW1icHJpbnQgdW5kZXIgdmFyeWluZyBjaXJjdW1zdGFuY2VzLCBjb21wbGV0ZSB3aXRoIHdoYXQg SSBmb3VuZCB0byBiZSBoZWxwZnVsIGV4YW1wbGVzLg0KDQpUaGUgcHJpbWFyeSBpc3N1ZSBJIGhh dmUgaXMgdGhhdCBpdOKAmXMgdW5jbGVhciBob3cgcmVseWluZyBwYXJ0aWVzIGFyZSBnb2luZyB0 byBrbm93IHdoaWNoIGhhc2ggYWxnb3JpdGhtIGhhcyBiZWVuIHVzZWQuICBUaGUgZXhhbXBsZXMg dXNlIFNIQS0yNTYsIGJ1dCBJ4oCZbSBub3Qgc2VlaW5nIHdoZXJlIFNIQS0yNTYgbWlnaHQgYmUg c3BlY2lmaWVkIGFzIGEgTVVTVCBvciBldmVuIGEgU0hPVUxELiAgTW9yZW92ZXIsIHRoZSBleGFt cGxlIG91dHB1dCB1bHRpbWF0ZWx5IHNob3dzIG9ubHkgdGhlIEJhc2UtNjQgZW5jb2Rpbmcgb2Yg dGhlIHJlc3VsdGluZyBoYXNoLCB3aGljaCBzYXlzIG5vdGhpbmcgYWJvdXQgdGhlIGFsZ29yaXRo bSB1c2VkIHRvIGlkZW50aWZ5IGEga2V5Lg0KDQpFYXJsaWVyIGRyYWZ0cyBoYWQgaW5jbHVkZWQg ZmllbGRzIHdob3NlIG5hbWVzIHdlcmUgaW50ZW5kZWQgdG8gY29tbXVuaWNhdGUgdGhlIGluZm9y bWF0aW9uIGFib3V0IHRoZSBoYXNoIGZ1bmN0aW9uIHVzZWQgLSBzZWUgdGhlICJqa3QiIGZpZWxk IGRlZmluaXRpb25zIGluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9z ZS1qd2stdGh1bWJwcmludC0wMSNzZWN0aW9uLTQgLSBidXQgc2V2ZXJhbCB3b3JraW5nIGdyb3Vw IHJldmlld2VycyBzdWdnZXN0ZWQgdGhhdCB0aGVzZSBmaWVsZHMgd2VyZSB1bm5lY2Vzc2FyeSBh bmQgdGhhdCB0aGUgdHlwaWNhbCB1c2FnZSB3b3VsZCBiZSBhcyAia2lkIiAoa2V5IElEKSBmaWVs ZCB2YWx1ZXMuICBXaXRoIHRoYXQgcmVtb3ZhbCwgaXQgZmFsbHMgb250byB0aGUgYXBwbGljYXRp b24gdG8gc3BlY2lmeSB0aGUgaGFzaCBhbGdvcml0aG0gZm9yIGl0cyBwYXJ0aWN1bGFyIHVzYWdl Lg0KDQpUaGlzIGlzbid0IGFzIGJhZCBhcyB5b3UgbWlnaHQgdGhpbmssIGhvd2V2ZXIsIGJlY2F1 c2UgdHlwaWNhbGx5IHRoZSBjb25zdW1lciBvZiB0aGUgImtpZCIgZG9lc24ndCBuZWVkIHRvIGtu b3cgdGhlIGFsZ29yaXRobSBiZWNhdXNlIGl0IHdvbid0IGJlIHJlcHJvZHVjaW5nIHRoZSBjb21w dXRhdGlvbi4gIEl0IGp1c3QgcmVsaWVzIG9uIHRoZSBmYWN0IHRoYXQgYSB1bmlxdWUga2V5IElE IHZhbHVlIHdhcyBnZW5lcmF0ZWQgZm9yIHRoZSBrZXkgYW5kIGNvbXBhcmVzICJraWQiIHZhbHVl cyBhcyBvcGFxdWUgc3RyaW5ncyB0byBmaW5kIHRoZSBhcHByb3ByaWF0ZSBrZXkuICBJbiB0aGlz IHVzYWdlLCB0aGUgcHJvZHVjZXIgb2YgdGhlIGtleSBpcyB0aGUgb25seSBwYXJ0eSB0aGF0IG5l ZWRzIHRvIGtub3cgdGhlIGhhc2ggYWxnb3JpdGhtIHRoYXQgaXQgaXMgdXNpbmcuICBJIGhvcGUg dGhpcyBoZWxwcy4NCg0KWWVzLCB0aGlzIGRvZXMgaGVscCwgdGhhbmsgeW91LiAgSXQgc2VlbXMg bGlrZSBzb21ldGhpbmcgdGhhdCBjb3VsZCBiZSBlYXNpbHkgYWRkZWQgdG8gdGhlIGRyYWZ0IHRv IGV4cGxhaW4gd2h5IHRoZSBnZW5lcmF0aW5nIGFsZ29yaXRobSBuZWVkbuKAmXQgYmUgZGlzY2xv c2VkIHNvIHRoYXQgc2xvdyBmb2xrIGxpa2UgbXlzZWxmIGdldCB0aGUgcGljdHVyZSBzdHJhaWdo dCBhd2F5Lg0KDQoNCg0KDQoNCg0KDQoNCg0KQWRkaXRpb25hbGx5LCBpbiBTZWN0aW9uIDQsIOKA nEpTT04gYW5kIFVuaWNvZGUgQ29uc2lkZXJhdGlvbnPigJ0gc29tZSDigJxzaG91bGTigJ1zIGFy ZSB1c2VkLCBidXQgSeKAmW0gbm90IHJlYWRpbmcgdGhlbSBhcyBTSE9VTERzLiBTaG91bGQgdGhl eSBiZSBTSE9VTERzPyAgRm9yIGV4YW1wbGUsIHRoZSBzdGFydCBvZiB0aGUgdGhpcmQgcGFyYWdy YXBoIGluIHRoYXQgc2VjdGlvbjog4oCcaWYgbmV3IEpXSyBtZW1iZXJzIGFyZSBkZWZpbmVkIHRo YXQgdXNlIG5vbi1BU0NJSSBtZW1iZXIgbmFtZXMsIHRoZWlyIGRlZmluaXRpb25zIHNob3VsZCBz cGVjaWZ5IHRoZSBleGFjdCBVbmljb2RlIGNvZGUgcG9pbnQgc2VxdWVuY2VzIHVzZWQgdG8gcmVw cmVzZW50IHRoZW0u4oCdICBJdOKAmXMgbm90IGNsZWFyIHRvIG1lIHdoZXRoZXIgdGhpcyBpcyBh IHN0cm9uZyBzdGF0ZW1lbnQgb3IganVzdCBhIHJlY29tbWVuZGF0aW9uIC0gaXQgc2VlbXMgdGhh dCB0aGlzIGRyYWZ0IGNvdWxkIGhlbHAgdGhlIGZ1dHVyZSBieSBtYWtpbmcgc3Ryb25nZXIgc3Rh dGVtZW50cyB0byBlbmNvdXJhZ2UgZnV0dXJlIGludGVyb3BlcmFiaWxpdHkuDQoNCkZvciB0aGUg b3RoZXIgSk9TRSBzcGVjaWZpY2F0aW9ucywgb3VyIGNoYWlyIEppbSBTY2hhYWQgdG9vayB0aGUg cG9zaXRpb24gdGhhdCBSRkMgMjExOSBrZXl3b3JkcyBzaG91bGQgYmUgcmVzZXJ2ZWQgZm9yIHRl c3RhYmxlIHByb3RvY29sIGJlaGF2aW9ycyBhbmQgdGhhdCBvdGhlciB1c2VzIG9mIHRoZSBFbmds aXNoIHdvcmQgInNob3VsZCIgc2hvdWxkIG5vdCB1c2UgIlNIT1VMRCIuICBUaGUgYXV0aG9ycyBm b2xsb3dlZCB0aGF0IGNvbnZlbnRpb24gaW4gdGhpcyBkb2N1bWVudC4gIEkgZG8gdW5kZXJzdGFu ZCB0aGF0IG90aGVyIGF1dGhvcnMgYW5kIHdvcmtpbmcgZ3JvdXBzIGhhdmUgdGFrZW4gZGlmZmVy ZW50IHBvc2l0aW9ucyBpbiB0aGlzIHJlZ2FyZC4gIElmIHRoZXJlIGFyZSBwYXJ0aWN1bGFyIHVz ZXMgdGhhdCB5b3Ugc3RpbGwgZmVlbCBzaG91bGQgYmUgY2hhbmdlZCB0byB1c2UgUkZDIDIxMTkg a2V5d29yZHMsIHBsZWFzZSBjYWxsIHRoZW0gb3V0Lg0KDQpUaGlzIGlzIGFsbCBnb29kLCB0b28u ICBJIHdhcyBzaW1wbHkgcG9pbnRpbmcgb3V0IHRoYXQgdGhlcmUgYXJlIOKAnHNob3VsZOKAnXMg YXJvdW5kIHRoYXQgbWF5IG5lZWQgdG8gYmUgY29uc2lkZXJlZCBhcyDigJxTSE9VTETigJ1zLiBJ IGFsc28gc2VlIEppbeKAmXMgKGFuZCBvdGhlcnPigJkpIHN1YnNlcXVlbnQgbm90ZXMgb24gdGhl IHN1YmplY3QsIHNvIHRoaXMgaXMgZ29vZCBmcm9tIG15IHBlcnNwZWN0aXZlLg0KDQoNCg0KDQoN Cg0KDQoNCktpbmQgcmVnYXJkcywNCkFkYW0NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcyBhZ2FpbiENCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAtLSBNaWtlDQoNCg== --_000_BY2PR03MB4421B3C0A9973108C1F7B6AF5AF0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uYXBwbGUtY29udmVy dGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFu LmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4u RW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxv b25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBBZGFtLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0YWtlIHlv dXIgcG9pbnQgdGhhdCB0aGUgcGFyYWdyYXBoIHdvdWxkIHNlZW0gc2ltcGxlciB3aXRob3V0IHRo ZSBsYXN0IHNlbnRlbmNlLCBidXQgSeKAmWQgcmF0aGVyIGVyciBvbiB0aGUgc2lkZSBvZiBnaXZp bmcgcmVhZGVycyBtb3JlIGluZm9ybWF0aW9uIHRoYW4gbGVzcy4mbmJzcDsNCiBXaGlsZSBpbiBt YW55IGNhc2VzIGtub3dsZWRnZSBvZiB0aGUgaGFzaCBmdW5jdGlvbiB1c2VkIG5lZWQgbm90IGJl IHByb3BhZ2F0ZWQgKHBlciB0aGUgZXhhbXBsZSBpbiB0aGUgYmVnaW5uaW5nIG9mIHRoZSBwYXJh Z3JhcGgpLCBzb21ldGltZXMgaXQgZG9lcy4mbmJzcDsgU28gTmF0IGFuZCBJIGRlY2lkZWQgdG8g YWxzbyBpbmNsdWRlIGEgc2VudGVuY2UgYWJvdXQgd2hlbiBpdCBkb2VzLiZuYnNwOyBQZXIgdGhl IHByZXZpb3VzIHBhcmFncmFwaCwgd2hpY2ggaGFzaA0KIGZ1bmN0aW9uIHRvIHVzZSBpcyBhbiBh cHBsaWNhdGlvbiBjaG9pY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gcm9tIHRoYXQgdmlld3BvaW50LCBkb2VzIHRo ZSBjdXJyZW50IHBhcmFncmFwaCB3b3JrIGZvciB5b3UsIG9yIGlzIHRoZXJlIGEgc3BlY2lmaWMg d29yZGluZyBjaGFuZ2UgdGhhdCB5b3XigJlkIHN0aWxsIGxpa2UgdG8gc2VlPzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGhhbmtzIGFnYWluIGZvciB5b3VyIHJldmlldyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBN aWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQWRhbSBXLiBNb250dmlsbGUgW21haWx0bzphZGFtLncu bW9udHZpbGxlQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1bmUg MjQsIDIwMTUgNToxMiBBTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lczxicj4NCjxiPkNjOjwv Yj4gVGhlIElFU0c7IHNlY2RpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnBy aW50LmFsbEBpZXRmLm9yZzsgam9zZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog c2VjdG9yIHJldmlldyBvZiBkcmFmdC1pZXRmLWpvc2UtandrLXRodW1icHJpbnQtMDU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBOYXQgYW5kIE1pa2Us PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9y IHlvdXIgYXR0ZW50aW9uIG9uIHRoaXMgaXNzdWUuICZuYnNwO0kgc2VlIHRoZSBmb2xsb3dpbmcg dGV4dCBpbiBzZWN0aW9uIDMuNDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdGUgdGhhdCBpbiBtYW55IGNhc2VzLCBvbmx5IHRo ZSBwYXJ0eSB0aGF0IGNyZWF0ZXMgYSBrZXkgd2lsbCBuZWVkPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7dG8ga25vdyB0aGUg aGFzaCBmdW5jdGlvbiB1c2VkLiAmbmJzcDtBIHR5cGljYWwgdXNhZ2UgaXMgZm9yIHRoZSBwcm9k dWNlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7ICZuYnNwO29mIHRoZSBrZXkgdG8gdXNlIHRoZSBiYXNlNjR1cmwtZW5jb2RlZCBKV0sg VGh1bWJwcmludCB2YWx1ZSBhcyBhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7JnF1b3Q7a2lkJnF1b3Q7IChrZXkgSUQpIHZh bHVlLiAmbmJzcDtUaGUgY29uc3VtZXIgb2YgdGhlICZxdW90O2tpZCZxdW90OyB0cmVhdHMgaXQg YXMgYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDtvcGFxdWUgdmFsdWUgdGhhdCBpdCB1c2VzIHRvIHNlbGVjdCB0aGUga2V5 LiAmbmJzcDtPbmx5IGlmIG11bHRpcGxlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7cGFydGllcyB3aWxsIGJlIHJlcHJvZHVj aW5nIHRoZSBKV0sgVGh1bWJwcmludCBjYWxjdWxhdGlvbiBmb3Igc29tZTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3JlYXNv biwgd2lsbCBwYXJ0aWVzIG90aGVyIHRoYW4gdGhlIG9yaWdpbmFsIHByb2R1Y2VyIG9mIHRoZSBK V0s8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyAmbmJzcDtUaHVtYnByaW50IG5lZWQgdG8ga25vdyB3aGljaCBoYXNoIGZ1bmN0aW9uIHdh cyB1c2VkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+V291bGQgaXQgbWFrZSB0aGUgZHJhZnQgY2xlYXJlciBpZiB0aGF0IGxh c3Qgc2VudGVuY2Ugd2VyZSBvbWl0dGVkPyAmbmJzcDtUaGUgd2F5IHRoaXMgcGFyYWdyYXBoIHJl YWRzIGlzIHN1Y2ggdGhhdCBkcmFmdCBjb25zaWRlcnMgYW5kIHdvdWxkIGFsbG93IGZvciBtdWx0 aXBsZSBwYXJ0aWVzIGdlbmVyYXRpbmcga2V5IElEcywgYnV0IHRoZW4gd2XigJlyZSBiYWNrIGF0 IG5vdCBrbm93aW5nIHdoaWNoIGFsZ29yaXRobSB3YXMNCiBjaG9zZW4uICZuYnNwO0lmIHRoYXQg bGFzdCBzZW50ZW5jZSB3ZXJlIG9taXR0ZWQsIHRoaXMgd291bGQgYmUgbGVzcyBvZiBhbiBpc3N1 ZS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIEp1biAyNCwgMjAxNSwgYXQgMzo0MCBBTSwgTWlrZSBKb25lcyAmbHQ7PGEg aHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SGkgQWRhbSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5r cyBhZ2FpbiBmb3IgeW91ciByZXZpZXcgY29tbWVudHMuJm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtandrLXRodW1icHJpbnQtMDYiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpv c2UtandrLXRodW1icHJpbnQtMDY8L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5oYXMNCiBiZWVuIHBvc3RlZCB0byBhZGRyZXNzIHRoZW0u Jm5ic3A7IFNlZSBzZWN0aW9ucyAzLjQgKFNlbGVjdGlvbiBvZiBIYXNoIEZ1bmN0aW9uKSBhbmQg NiAoSUFOQSBDb25zaWRlcmF0aW9ucykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzIGFnYWluLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTmF0IGFuZCBNaWtlPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5LYXRobGVlbg0KIE1vcmlhcnR5IFs8YSBocmVmPSJtYWlsdG86a2F0aGxl ZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20iPm1haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRm QGdtYWlsLmNvbTwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5Nb25kYXksIEp1bmUgMjIsIDIwMTUgMTI6NTEgUE08YnI+DQo8Yj5U bzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1p a2UgSm9uZXM8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPkFkYW0gVy4gTW9udHZpbGxlOyBUaGUgSUVTRzsNCjxhIGhyZWY9Im1h aWx0bzpzZWNkaXJAaWV0Zi5vcmciPnNlY2RpckBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0 bzpkcmFmdC1pZXRmLWpvc2UtandrLXRodW1icHJpbnQuYWxsQGlldGYub3JnIj4NCmRyYWZ0LWll dGYtam9zZS1qd2stdGh1bWJwcmludC5hbGxAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86 am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IHNlY3RvciBy ZXZpZXcgb2YgZHJhZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnByaW50LTA1PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlllcywgdGhhbmsgeW91LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2F0aGxlZW4mbmJzcDs8YnI+ DQo8YnI+DQpTZW50IGZyb20gbXkgaVBob25lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PGJyPg0KT24gSnVuIDIyLCAyMDE1LCBhdCA5OjE4IFBNLCBNaWtlIEpvbmVzICZsdDs8YSBo cmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L3NwYW4+PC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmWQg YmUgZ2xhZCB0byBhZGQgdGhlIGV4cGxhbmF0aW9uIGJlbG93IHRvIHRoZSBkcmFmdCBhbmQgdG8g YWxzbyBpbmNsdWRlIGFuIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiB0aGF0IHN0YXRlcyB3 ZSBhcmUgdXBkYXRpbmcgdGhlIGV4cGVydCByZXZpZXcgaW5zdHJ1Y3Rpb25zDQogZm9yIGEgcmVn aXN0cnksIGFzIEppbSBTY2hhYWQgaGFkIHN1Z2dlc3RlZC4mbmJzcDsgQ2hhaXJzIGFuZCBLYXRo bGVlbiwgZG8geW91IHdhbnQgTmF0IGFuZCBJIHRvIHByb2NlZWQgdG8gcHVibGlzaCBhbiB1cGRh dGVkIGRyYWZ0Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkFkYW0NCiBXLiBNb250dmlsbGUgWzxhIGhyZWY9Im1haWx0bzphZGFtLncubW9udHZpbGxlQGdt YWlsLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRvOmFkYW0udy5tb250dmls bGVAZ21haWwuY29tPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5GcmlkYXksIEp1bmUgMTIsIDIwMTUgNTowNyBBTTxi cj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+TWlrZSBKb25lczxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VGhlIElFU0c7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzZWNkaXJAaWV0Zi5vcmci PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnNlY2RpckBpZXRmLm9yZzwvc3Bhbj48L2E+Ozxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJt YWlsdG86ZHJhZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnByaW50LmFsbEBpZXRmLm9yZyI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+ZHJhZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnByaW50LmFsbEBp ZXRmLm9yZzwvc3Bhbj48L2E+OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+am9zZUBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBzZWN0 b3IgcmV2aWV3IG9mIGRyYWZ0LWlldGYtam9zZS1qd2stdGh1bWJwcmludC0wNTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1biAxMSwgMjAxNSwgYXQgNDoyNSBQTSwg TWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t PC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5IaSBBZGFtLDxicj4NCjxicj4NClRoYW5rcyBmb3IgdGhlIHNlY2RpciByZXZpZXcu PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTogQWRhbSBXLiBNb250dmlsbGUgWzxhIGhyZWY9Im1haWx0bzphZGFtLncubW9u dHZpbGxlQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRvOmFkYW0u dy5tb250dmlsbGVAZ21haWwuY29tPC9zcGFuPjwvYT5dPGJyPg0KU2VudDogTW9uZGF5LCBKdW5l IDA4LCAyMDE1IDg6NDYgQU08YnI+DQpUbzogVGhlIElFU0c7PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzZWNkaXJAaWV0Zi5v cmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnNlY2RpckBpZXRmLm9yZzwvc3Bhbj48L2E+ OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVm PSJtYWlsdG86ZHJhZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnByaW50LmFsbEBpZXRmLm9yZyI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ZHJhZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnByaW50LmFs bEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KU3ViamVjdDogc2VjdG9yIHJldmlldyBvZiBkcmFm dC1pZXRmLWpvc2UtandrLXRodW1icHJpbnQtMDU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5IaSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIGhhdmUgcmV2aWV3ZWQg dGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29p bmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5 IHRoZSBJRVNHLiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4NCiBwcmltYXJpbHkgZm9yIHRo ZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gRG9jdW1lbnQgZWRpdG9y cyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55 IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy48YnI+DQo8YnI+DQpJIGJlbGlldmUgdGhlIGRvY3Vt ZW50IGlzIHJlYWR5IHdpdGggKHBvdGVudGlhbCkgaXNzdWVzLiAmbmJzcDtUaGUg4oCcd2l0aCBp c3N1ZXPigJ0gbWlnaHQgYmUgZHVlIHRvIGlnbm9yYW5jZSBvbiBteSBwYXJ0LiAmbmJzcDtUaGUg ZHJhZnQgZG9lcyBhIHZlcnkgZ29vZCBqb2Igb2YgZXhwbGFpbmluZyB0aGUgY2Fub25pY2FsIGZv cm0gb2YgYSBKU09OIFdlYiBLZXkgdGhhdCBjYW4gYmUgdXNlZCBmb3IgZXN0YWJsaXNoaW5nIGEg dGh1bWJwcmludCB1bmRlciB2YXJ5aW5nDQogY2lyY3Vtc3RhbmNlcywgY29tcGxldGUgd2l0aCB3 aGF0IEkgZm91bmQgdG8gYmUgaGVscGZ1bCBleGFtcGxlcy48YnI+DQo8YnI+DQpUaGUgcHJpbWFy eSBpc3N1ZSBJIGhhdmUgaXMgdGhhdCBpdOKAmXMgdW5jbGVhciBob3cgcmVseWluZyBwYXJ0aWVz IGFyZSBnb2luZyB0byBrbm93IHdoaWNoIGhhc2ggYWxnb3JpdGhtIGhhcyBiZWVuIHVzZWQuICZu YnNwO1RoZSBleGFtcGxlcyB1c2UgU0hBLTI1NiwgYnV0IEnigJltIG5vdCBzZWVpbmcgd2hlcmUg U0hBLTI1NiBtaWdodCBiZSBzcGVjaWZpZWQgYXMgYSBNVVNUIG9yIGV2ZW4gYSBTSE9VTEQuICZu YnNwO01vcmVvdmVyLCB0aGUgZXhhbXBsZSBvdXRwdXQNCiB1bHRpbWF0ZWx5IHNob3dzIG9ubHkg dGhlIEJhc2UtNjQgZW5jb2Rpbmcgb2YgdGhlIHJlc3VsdGluZyBoYXNoLCB3aGljaCBzYXlzIG5v dGhpbmcgYWJvdXQgdGhlIGFsZ29yaXRobSB1c2VkIHRvIGlkZW50aWZ5IGEga2V5Ljwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCkVhcmxpZXIgZHJhZnRzIGhhZCBpbmNsdWRl ZCBmaWVsZHMgd2hvc2UgbmFtZXMgd2VyZSBpbnRlbmRlZCB0byBjb21tdW5pY2F0ZSB0aGUgaW5m b3JtYXRpb24gYWJvdXQgdGhlIGhhc2ggZnVuY3Rpb24gdXNlZCAtIHNlZSB0aGUgJnF1b3Q7amt0 JnF1b3Q7IGZpZWxkIGRlZmluaXRpb25zIGluPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWpvc2UtandrLXRodW1icHJpbnQtMDEjc2VjdGlvbi00Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnB1cnBsZSI+aHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWp3ay10aHVtYnByaW50LTAxI3NlY3Rpb24tNDwvc3Bhbj48 L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4tDQogYnV0IHNldmVyYWwgd29ya2luZyBncm91cCByZXZpZXdlcnMgc3VnZ2VzdGVkIHRo YXQgdGhlc2UgZmllbGRzIHdlcmUgdW5uZWNlc3NhcnkgYW5kIHRoYXQgdGhlIHR5cGljYWwgdXNh Z2Ugd291bGQgYmUgYXMgJnF1b3Q7a2lkJnF1b3Q7IChrZXkgSUQpIGZpZWxkIHZhbHVlcy4gJm5i c3A7V2l0aCB0aGF0IHJlbW92YWwsIGl0IGZhbGxzIG9udG8gdGhlIGFwcGxpY2F0aW9uIHRvIHNw ZWNpZnkgdGhlIGhhc2ggYWxnb3JpdGhtIGZvciBpdHMgcGFydGljdWxhciB1c2FnZS48YnI+DQo8 YnI+DQpUaGlzIGlzbid0IGFzIGJhZCBhcyB5b3UgbWlnaHQgdGhpbmssIGhvd2V2ZXIsIGJlY2F1 c2UgdHlwaWNhbGx5IHRoZSBjb25zdW1lciBvZiB0aGUgJnF1b3Q7a2lkJnF1b3Q7IGRvZXNuJ3Qg bmVlZCB0byBrbm93IHRoZSBhbGdvcml0aG0gYmVjYXVzZSBpdCB3b24ndCBiZSByZXByb2R1Y2lu ZyB0aGUgY29tcHV0YXRpb24uICZuYnNwO0l0IGp1c3QgcmVsaWVzIG9uIHRoZSBmYWN0IHRoYXQg YSB1bmlxdWUga2V5IElEIHZhbHVlIHdhcyBnZW5lcmF0ZWQgZm9yIHRoZSBrZXkgYW5kDQogY29t cGFyZXMgJnF1b3Q7a2lkJnF1b3Q7IHZhbHVlcyBhcyBvcGFxdWUgc3RyaW5ncyB0byBmaW5kIHRo ZSBhcHByb3ByaWF0ZSBrZXkuICZuYnNwO0luIHRoaXMgdXNhZ2UsIHRoZSBwcm9kdWNlciBvZiB0 aGUga2V5IGlzIHRoZSBvbmx5IHBhcnR5IHRoYXQgbmVlZHMgdG8ga25vdyB0aGUgaGFzaCBhbGdv cml0aG0gdGhhdCBpdCBpcyB1c2luZy4gJm5ic3A7SSBob3BlIHRoaXMgaGVscHMuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIHRoaXMgZG9lcyBo ZWxwLCB0aGFuayB5b3UuICZuYnNwO0l0IHNlZW1zIGxpa2Ugc29tZXRoaW5nIHRoYXQgY291bGQg YmUgZWFzaWx5IGFkZGVkIHRvIHRoZSBkcmFmdCB0byBleHBsYWluIHdoeSB0aGUgZ2VuZXJhdGlu ZyBhbGdvcml0aG0gbmVlZG7igJl0IGJlIGRpc2Nsb3NlZCBzbyB0aGF0IHNsb3cgZm9sayBsaWtl IG15c2VsZiBnZXQgdGhlIHBpY3R1cmUgc3RyYWlnaHQgYXdheS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5BZGRpdGlvbmFsbHksIGluIFNlY3Rpb24gNCwg4oCcSlNPTiBhbmQgVW5pY29kZSBDb25zaWRl cmF0aW9uc+KAnSBzb21lIOKAnHNob3VsZOKAnXMgYXJlIHVzZWQsIGJ1dCBJ4oCZbSBub3QgcmVh ZGluZyB0aGVtIGFzIFNIT1VMRHMuIFNob3VsZCB0aGV5IGJlIFNIT1VMRHM/ICZuYnNwO0ZvciBl eGFtcGxlLCB0aGUgc3RhcnQNCiBvZiB0aGUgdGhpcmQgcGFyYWdyYXBoIGluIHRoYXQgc2VjdGlv bjog4oCcaWYgbmV3IEpXSyBtZW1iZXJzIGFyZSBkZWZpbmVkIHRoYXQgdXNlIG5vbi1BU0NJSSBt ZW1iZXIgbmFtZXMsIHRoZWlyIGRlZmluaXRpb25zIHNob3VsZCBzcGVjaWZ5IHRoZSBleGFjdCBV bmljb2RlIGNvZGUgcG9pbnQgc2VxdWVuY2VzIHVzZWQgdG8gcmVwcmVzZW50IHRoZW0u4oCdICZu YnNwO0l04oCZcyBub3QgY2xlYXIgdG8gbWUgd2hldGhlciB0aGlzIGlzIGEgc3Ryb25nIHN0YXRl bWVudA0KIG9yIGp1c3QgYSByZWNvbW1lbmRhdGlvbiAtIGl0IHNlZW1zIHRoYXQgdGhpcyBkcmFm dCBjb3VsZCBoZWxwIHRoZSBmdXR1cmUgYnkgbWFraW5nIHN0cm9uZ2VyIHN0YXRlbWVudHMgdG8g ZW5jb3VyYWdlIGZ1dHVyZSBpbnRlcm9wZXJhYmlsaXR5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxicj4NCkZvciB0aGUgb3RoZXIgSk9TRSBzcGVjaWZpY2F0aW9ucywgb3VyIGNo YWlyIEppbSBTY2hhYWQgdG9vayB0aGUgcG9zaXRpb24gdGhhdCBSRkMgMjExOSBrZXl3b3JkcyBz aG91bGQgYmUgcmVzZXJ2ZWQgZm9yIHRlc3RhYmxlIHByb3RvY29sIGJlaGF2aW9ycyBhbmQgdGhh dCBvdGhlciB1c2VzIG9mIHRoZSBFbmdsaXNoIHdvcmQgJnF1b3Q7c2hvdWxkJnF1b3Q7IHNob3Vs ZCBub3QgdXNlICZxdW90O1NIT1VMRCZxdW90Oy4gJm5ic3A7VGhlIGF1dGhvcnMgZm9sbG93ZWQg dGhhdCBjb252ZW50aW9uDQogaW4gdGhpcyBkb2N1bWVudC4gJm5ic3A7SSBkbyB1bmRlcnN0YW5k IHRoYXQgb3RoZXIgYXV0aG9ycyBhbmQgd29ya2luZyBncm91cHMgaGF2ZSB0YWtlbiBkaWZmZXJl bnQgcG9zaXRpb25zIGluIHRoaXMgcmVnYXJkLiAmbmJzcDtJZiB0aGVyZSBhcmUgcGFydGljdWxh ciB1c2VzIHRoYXQgeW91IHN0aWxsIGZlZWwgc2hvdWxkIGJlIGNoYW5nZWQgdG8gdXNlIFJGQyAy MTE5IGtleXdvcmRzLCBwbGVhc2UgY2FsbCB0aGVtIG91dC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoaXMgaXMgYWxsIGdvb2QsIHRvby4gJm5ic3A7SSB3YXMgc2ltcGx5IHBv aW50aW5nIG91dCB0aGF0IHRoZXJlIGFyZSDigJxzaG91bGTigJ1zIGFyb3VuZCB0aGF0IG1heSBu ZWVkIHRvIGJlIGNvbnNpZGVyZWQgYXMg4oCcU0hPVUxE4oCdcy4gSSBhbHNvIHNlZSBKaW3igJlz IChhbmQgb3RoZXJz4oCZKSBzdWJzZXF1ZW50IG5vdGVzIG9uIHRoZSBzdWJqZWN0LCBzbyB0aGlz IGlzIGdvb2QgZnJvbSBteSBwZXJzcGVjdGl2ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+S2luZCByZWdhcmRzLDxicj4NCkFkYW08 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUt dGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VGhhbmtzIGFnYWluITxicj4NCjxzcGFuIGNs YXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4tLSBNaWtlPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY2PR03MB4421B3C0A9973108C1F7B6AF5AF0BY2PR03MB442namprd_-- From nobody Wed Jun 24 14:18:32 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2591B2E41; Wed, 24 Jun 2015 14:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3czA62rSkgJ; Wed, 24 Jun 2015 14:18:26 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3020A1B2E40; Wed, 24 Jun 2015 14:18:26 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5OLIPfg000957 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Wed, 24 Jun 2015 16:18:25 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <558B1E9C.8080505@nostrum.com> Date: Wed, 24 Jun 2015 16:18:20 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "secdir@ietf.org" , "ietf@ietf.org" , "iesg@ietf.org" , draft-ietf-hybi-permessage-compression.all@ietf.org Content-Type: multipart/alternative; boundary="------------050005090203080403030500" Archived-At: Subject: [secdir] Secdir review of draft-ietf-hybi-permessage-compression-22 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 21:18:27 -0000 This is a multi-part message in MIME format. --------------050005090203080403030500 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Ready with issues (fwiw, I also reviewed up through version -24). Section 7 (Intermediaries) should be more explicit that it's talking about an intermediary doing compression on one side and not (or doing different compression) on the other. (If that's not what it's trying to set up, please clarify). It's not clear from reading RFC6455 that the idea of intermediaries changing the contents of the websocket extension negotiation mechanism was considered - have I missed the text in that RFC that discusses that? Are there other extensions that suggest similar behavior? It's not immediately clear that the protocol mechanics do the right thing when the different negotiations on each side of the proxy fail differently. This also seems to put an endpoint in a position where it has no say on what an intermediary does with the traffic on the other side of it. Is that worth discussing in the document? It would be good to point to, or provide, a discussion of how the extension negotiation mechanism in WebSockets is meant to be protected. RjS --------------050005090203080403030500 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit 
I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

Summary: Ready with issues

(fwiw, I also reviewed up through version -24).

Section 7 (Intermediaries) should be more explicit that it's talking about an intermediary doing compression on one side and not (or doing different compression) on the other.
(If that's not what it's trying to set up, please clarify).

It's not clear from reading RFC6455 that the idea of intermediaries changing the contents of the websocket extension negotiation mechanism was considered - have I missed the text in that RFC that discusses that?
Are there other extensions that suggest similar behavior? It's not immediately clear that the protocol mechanics do the right thing when the different negotiations on each side of the proxy fail differently.

This also seems to put an endpoint in a position where it has no say on what an intermediary does with the traffic on the other side of it. Is that worth discussing in the document?

It would be good to point to, or provide, a discussion of how the extension negotiation mechanism in WebSockets is meant to be protected.

RjS
--------------050005090203080403030500-- From nobody Thu Jun 25 04:51:38 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2A61B354F for ; Thu, 25 Jun 2015 04:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=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 N4paEXfwRajh for ; Thu, 25 Jun 2015 04:51:35 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 62CD81B354E for ; Thu, 25 Jun 2015 04:51:35 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t5PBpWTL006809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 25 Jun 2015 14:51:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t5PBpWKV028088; Thu, 25 Jun 2015 14:51:32 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21899.60228.520719.584402@fireball.kivinen.iki.fi> Date: Thu, 25 Jun 2015 14:51:32 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 11:51:38 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Shaun Cooley is next in the rotation. For telechat 2015-06-25 Reviewer LC end Draft Sandy Murphy T 2015-06-12 draft-ietf-manet-olsrv2-management-snapshot-03 For telechat 2015-07-09 Matthew Miller T 2015-06-11 draft-ietf-homenet-prefix-assignment-07 Joe Salowey T 2015-06-17 draft-ietf-tzdist-service-08 Takeshi Takahashi T 2015-07-03 draft-ietf-karp-isis-analysis-04 Brian Weis T 2015-06-30 draft-ietf-roll-mpl-parameter-configuration-04 Klaas Wierenga T 2015-07-02 draft-ietf-appsawg-text-markdown-08 Paul Wouters T 2015-07-03 draft-ietf-appsawg-text-markdown-use-cases-02 Last calls and special requests: Derek Atkins 2015-07-08 draft-ietf-xmpp-dna-10 John Bradley 2015-07-08 draft-ietf-xmpp-posh-04 Catherine Meadows 2015-06-09 draft-ietf-dhc-access-network-identifier-08 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Hannes Tschofenig 2015-07-07 draft-wkumari-dhc-capport-13 Tina TSOU 2015-06-24 draft-ietf-dane-ops-12 Sean Turner 2015-06-29 draft-ietf-dhc-dhcpv6-active-leasequery-03 Carl Wallace 2015-06-29 draft-ietf-ipsecme-chacha20-poly1305-10 David Waltermire 2015-06-29 draft-ietf-pcp-authentication-11 Sam Weiler 2015-06-29 draft-ietf-pcp-proxy-08 Frank Xialiang 2015-07-02 draft-ietf-bmwg-issu-meth-01 Tom Yu 2015-07-02 draft-ietf-grow-filtering-threats-06 Dacheng Zhang 2015-07-08 draft-ietf-opsec-ipv6-host-scanning-07 -- kivinen@iki.fi From nobody Thu Jun 25 07:56:30 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6DDD1A89FC; Thu, 25 Jun 2015 07:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmzecNwCDbea; Thu, 25 Jun 2015 07:56:17 -0700 (PDT) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (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 99F2C1A8A11; Thu, 25 Jun 2015 07:56:17 -0700 (PDT) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id t5PEuFoU029399 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 25 Jun 2015 10:56:16 -0400 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_7124DE79-BC50-4B4F-86CD-478563904C33" Date: Thu, 25 Jun 2015 10:56:11 -0400 Message-Id: To: draft-ietf-dhc-access-network-identifier.all@tools.ietf.org, secdir@ietf.org, iesg@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: Subject: [secdir] secdir review of draft-ietf-dhc-access-network-identifier-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 14:56:19 -0000 --Apple-Mail=_7124DE79-BC50-4B4F-86CD-478563904C33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This draft specifies the format and mechanisms used for encoding network = identifiers in DHCPv4 and DHCPv6 by defining new access identifier = options and sub-options. The Security Considerations section gives a discussion of the security = risks in using DHCP and their mitigation. However, what needs to be go = in the Security Considerations Section is a discussion of the security risks raised by *this* document = and possible mitigation. The information about DHCP security risks is = useful, but not of primary importance. My impression is that this document gives formats for presenting fields = whose use is already discussed in previous RFC=92s, e.g. RFC3315, in = which case there are no new security considerations. If that is so, then the Security = Considerations Section should include (preferably begin with) a statement to the effect that, since = this document only gives instructions for formatting and encoding fields = whose use has already been specified in these previous RFC=92s, it presents no additional security = considerations beyond what is covered in those RFCs. If that is not the = case, you should say what new security risks are introduced by *this* draft, e.g. does it enable a use of DHCP that was not possible = before and could cause a new type of security risk if DHCP was used = without authentication? Recommendation: Ready With Issues Cathy Meadows Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail=_7124DE79-BC50-4B4F-86CD-478563904C33 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I have = reviewed this document as part of the security = directorate's 
ongoing effort to review all IETF documents being = processed by the 
IESG.  These comments were written = primarily for the benefit of the 
security area directors. =  Document editors and WG chairs should treat 
these = comments just like any other last call comments.


This draft = specifies the format and mechanisms used for encoding network = identifiers in DHCPv4 and DHCPv6 by defining new access identifier = options and sub-options.
The Security Considerations section gives a = discussion of the security risks in using DHCP and their mitigation. =  However, what needs to be go in the Security = Considerations
Section is a discussion of the security risks raised = by *this* document and possible mitigation.  The information about = DHCP security risks is useful, but not of primary importance.

My = impression is that this document gives formats for presenting fields = whose use is already discussed in previous RFC=92s, e.g. RFC3315, in = which case there are no new
security considerations.  If that is = so, then the Security Considerations Section should
include = (preferably begin with) a statement to the effect that, since this = document only gives instructions for formatting and encoding fields = whose use has already been specified
in these previous RFC=92s, it = presents no additional security considerations beyond what is covered in = those RFCs.  If that is not the case, you should say what new = security risks are introduced
by *this* draft, e.g. does it enable a = use of DHCP that was not possible before and could cause a new type of = security risk if DHCP was used without = authentication?

Recommendation:  Ready With = Issues

Cathy = Meadows


Catherine Meadows
Naval = Research Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: 202-767-3490
fax: = 202-404-7942
email: catherine.meadows@nrl.navy.= mil

= --Apple-Mail=_7124DE79-BC50-4B4F-86CD-478563904C33-- From nobody Thu Jun 25 12:17:53 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D20C1ACCD9; Thu, 25 Jun 2015 12:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jq-Px5W2YVEx; Thu, 25 Jun 2015 12:17:46 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B67A11AC82C; Thu, 25 Jun 2015 12:17:46 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5PJHjie079810 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Thu, 25 Jun 2015 14:17:45 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <558C53D4.1020207@nostrum.com> Date: Thu, 25 Jun 2015 14:17:40 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Vincent Roca References: <2E90B73E-0309-4C49-B208-C2E30A0B6B22@inria.fr> <55882D28.3020701@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070409060808060207050207" Archived-At: Cc: draft-ietf-sipcore-refer-explicit-subscription@tools.ietf.org, IESG , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sipcore-refer-explicit-subscription-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 19:17:49 -0000 This is a multi-part message in MIME format. --------------070409060808060207050207 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit One more response to make sure we've wrapped the loose ends. On 6/23/15 3:02 AM, Vincent Roca wrote: > Hello Robert, > > I have merged the two emails. > >>>> I have several questions and suggestions WRT the *Security Section*. >>>> >>>> It is said that: With this update, there may multiple subscribers >>>> to any given refer event state." >>>> So what? What are the implications from a security point of view? >>> Hmm. I wonder if sentence order made this less clear than it should >>> have been? >>> >>> The paragraph that sentence appears in discusses exactly what the >>> implications are - specifically that there is a new authorization >>> consideration. >>> The paragraph that follow talks about how we deal with having that >>> new consideration. > > VR: Previous sentences of this paragraph explain that the > authorization for a SUBSCRIBE is now decoupled from > the REFER mechanism. And then, the last sentence mentions the > possibility of having **multiple** subscribers > which is not discussed previously, hence my remark. I dont think its > a matter of sentence order. And the paragraph > that follows does not mention nor discuss explicitly this idea of > **multiple** subscribers. I dont know if this notion > of **multiple** subscribers is difficult to handle or not, if it > creates risks or not. Can you clarify the text? Ah - multiple subscriptions in SIP events is _normal_. This sentence is here because an unextended REFER request could only create one subscription. It's a reminder to the implementer that all the normal SIP events behavior comes into play when you use this extension. There are no extra considerations to discuss beyond the authorization one already called out. > >>>> IMHO, the third paragraph does not make an appropriate use of the >>>> normative vocabulary. >>>> For instance, it is said: >>>> "the URI should be constructed so that it is not easy to guess, and >>>> should be protected against eavesdroppers" >>>> Shouldnt the author use SHOULD on both occasions? >>>> The following sentence is ambiguous. It says: >>>> "For instance, SIP messages containing this URI SHOULD be sent >>>> using TLS or DTLS..." >>>> "SHOULD" and "For instance" are contradictory. I suggest removing >>>> "For instance". >>>> Similarly, next sentence says: "can redirect". I think "SHOULD" >>>> redirect is more appropriate. >>>> Finally the same remark (i.e. use SHOULD") can be done for the >>>> next two sentences about additional authorization >>>> mechanisms. >>> Ben made a similar comment. The first 2119 requirement you point to >>> needs to move up into the protocol definition part of the document. >>> The second is restating text thats in RFC3261, and we don't need to >>> repeat the 2119 here - I'll clarify the language to say "use the >>> mechanisms the base specification provides". > > VR: IMHO repeating normative vocabulary is not an issue as long as it > is used homogeneously in the whole document, > whereas the opposite would be an issue. > >>>> In the 4th paragraph, it is not clear to me why it is said that >>>> there is a factor of 11 amplification due to retransmissions >>>> of the request . What are the foundations for this 11 factor? >>> This is base SIP behavior. The non-INVITE transaction state machine >>> retransmits 11 times before giving up if something on the other end >>> doesn't talk back >>> (which is what will happen if the other endpoint is not SIP aware). > > VR: okay, I see. Ill let you judge whether its appropriate or not to > justify this figure in the document. > >>>> And what happens if the victim is SIP aware? >>> It will send an appropriate response, so there won't be the >>> retransmissions of the request. In other words, sending this as raw >>> traffic towards a sip aware element is no different than sending any >>> other sip request towards a sip aware element. > > VR: okay. Same remark as above. > > >>> Additionally, I have concerns about *backward compatibility*. >>> The mechanisms introduced by this extension may not be backward >>> compatible with RFC 3515 (see section 7). >>> However I dont see any discussion in the current document. >>> There are some guidelines in RFC 6656 (8.3.1) concerning the 202 >>> response code, but what is described in the first >>> paragraph is new to this document. >> Our AD already noted that the second paragraph should actually be >> removed from this document - it is covered in refer-clarifications. > > VR: ok > >> For the first paragraph - backwards compatibility is ensured by the >> base SIP extension mechanism. >> An implementation of 3515 that is not aware of this extension (and >> the update to 3515 established by this document) would reject any >> requests that tried to invoke the extension (if either of the tokens >> defined here appeared in a Require: header field, that implementation >> would reject them with a 420 response. > > VR: ok, I understand. But is MAY accept the appropriate? I dont > think so. What about: > > NEW: > The requirement in section 2.4.4 of [RFC3515] to reject out-of-dialog > SUBSCRIBE requests to event 'refer' is removed. An element MUST > process a SUBSCRIBE request to event refer', following the > requirements and guidance in this document,since REFER is no longer the > only mechanism that can create a subscription to event refer. No, MAY is the appropriate word here. An element could have many reasons to not accept the request, and accepting is what we need to talk about at this point. The rest of the draft details what is required once that choice to accept has been made. Thanks for your review work on this! RjS > Cheers, > > Vincent > --------------070409060808060207050207 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit One more response to make sure we've wrapped the loose ends.

On 6/23/15 3:02 AM, Vincent Roca wrote:
Hello Robert,

I have merged the two emails.

I have several questions and suggestions WRT theSecurity Section.

It is said that: With this update, there may multiple subscribers to any given refer event state."
So what? What are the implications from a security point of view?
Hmm. I wonder if sentence order made this less clear than it should have been?

The paragraph that sentence appears in discusses exactly what the implications are - specifically that there is a new authorization consideration.
The paragraph that follow talks about how we deal with having that new consideration.

VR: Previous sentences of this paragraph explain that the authorization for a SUBSCRIBE is now decoupled from
the REFER mechanism. And then, the last sentence mentions the possibility of having **multiple** subscribers
which is not discussed previously, hence my remark. I dont think its a matter of sentence order. And the paragraph
that follows does not mention nor discuss explicitly this idea of **multiple** subscribers. I dont know if this notion
of **multiple** subscribers is difficult to handle or not, if it creates risks or not. Can you clarify the text?
Ah - multiple subscriptions in SIP events is _normal_. This sentence is here because an unextended REFER request could
only create one subscription. It's a reminder to the implementer that all the normal SIP events behavior comes into play
when you use this extension. There are no extra considerations to discuss beyond the authorization one already called out.

IMHO, the third paragraph does not make an appropriate use of the normative vocabulary.
For instance, it is said:
"the URI should be constructed so that it is not easy to guess, and should be protected against eavesdroppers"
Shouldnt the author use SHOULD on both occasions?
The following sentence is ambiguous. It says:
"For instance, SIP messages containing this URI SHOULD be sent using TLS or DTLS..."
"SHOULD" and "For instance" are contradictory. I suggest removing "For instance".
Similarly, next sentence says: "can redirect". I think "SHOULD" redirect is more appropriate.
Finally the same remark (i.e. use SHOULD") can be done for the next two sentences about additional authorization
mechanisms.
Ben made a similar comment. The first 2119 requirement you point to needs to move up into the protocol definition part of the document.
The second is restating text thats in RFC3261, and we don't need to repeat the 2119 here - I'll clarify the language to say "use the mechanisms the base specification provides".

VR: IMHO repeating normative vocabulary is not an issue as long as it is used homogeneously in the whole document,
whereas the opposite would be an issue.

In the 4th paragraph, it is not clear to me why it is said that there is a factor of 11 amplification due to retransmissions
of the request. What are the foundations for this 11 factor?
This is base SIP behavior. The non-INVITE transaction state machine retransmits 11 times before giving up if something on the other end doesn't talk back
(which is what will happen if the other endpoint is not SIP aware).

VR: okay, I see. Ill let you judge whether its appropriate or not to justify this figure in the document.

And what happens if the victim is SIP aware?
It will send an appropriate response, so there won't be the retransmissions of the request. In other words, sending this as raw traffic towards a sip aware element is no different than sending any other sip request towards a sip aware element.

VR: okay. Same remark as above.


Additionally, I have concerns about backward compatibility.
The mechanisms introduced by this extension may not be backward compatible with RFC 3515 (see section 7).
However I dont see any discussion in the current document.
There are some guidelines in RFC 6656 (8.3.1) concerning the 202 response code, but what is described in the first
paragraph is new to this document.
Our AD already noted that the second paragraph should actually be removed from this document - it is covered in refer-clarifications.

VR: ok

For the first paragraph - backwards compatibility is ensured by the base SIP extension mechanism.
An implementation of 3515 that is not aware of this extension (and the update to 3515 established by this document) would reject any requests that tried to invoke the extension (if either of the tokens defined here appeared in a Require: header field, that implementation would reject them with a 420 response.

VR: ok, I understand. But is MAY accept the appropriate? I dont think so. What about:

NEW:
The requirement insection 2.4.4 of [RFC3515] to reject out-of-dialog
SUBSCRIBE requests to event 'refer' is removed. An element MUST
process a SUBSCRIBE request to event refer', following the
requirements and guidance in this document, since REFER is no longer the
only mechanism that can create a subscription to event refer.
No, MAY is the appropriate word here. An element could have many reasons to not accept the request, and accepting is what we need to talk about at this point.
The rest of the draft details what is required once that choice to accept has been made.

Thanks for your review work on this!

RjS
Cheers,

Vincent


--------------070409060808060207050207-- From nobody Thu Jun 25 13:18:11 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADE01ACEB4; Thu, 25 Jun 2015 13:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgu4UHvhzGxv; Thu, 25 Jun 2015 13:18:06 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 146831ACEAB; Thu, 25 Jun 2015 13:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1617; q=dns/txt; s=iport; t=1435263486; x=1436473086; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=EM/NiGa/xG10Ws5MNWZ5BB1wdpMVQ4YFSJa79rbKDFs=; b=F/KSa40X/xcKtw3Q09HxD+v/P7kjhewRV7nHs0L3qwW3RceUHPUec9HE OCmc4F9jhJkVi6M0e8mNmp9U4puhJ8oQCxxXLeBZLrD1L33RAg+TbuK4D q6GEVTG+VWUlckxv1BklfGZSIZMJ8RY+BshT6UX20AHdx1tZVhvtdcfcr 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BOBQBTYYxV/40NJK1cgxGBOb0Wh16BQjoSAQEBAQEBAYEKhCUEeRIBgQAnBAENiDTMIAEBAQEBAQEBAQEBAQEBAQEBAQEZkAEES4MegRQFlAYBhy+EIpg5JoN6gjWBAgEBAQ X-IronPort-AV: E=Sophos;i="5.13,679,1427760000"; d="scan'208";a="162983272" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP; 25 Jun 2015 20:18:05 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t5PKI4uT008493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jun 2015 20:18:05 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.136]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Thu, 25 Jun 2015 15:18:05 -0500 From: "Brian Weis (bew)" To: The IESG , "secdir@ietf.org" Thread-Topic: Secdir review of draft-ietf-roll-mpl-parameter-configuration-04 Thread-Index: AQHQr4QKL7yMzuQ4YkCLPi20wdm6Hg== Date: Thu, 25 Jun 2015 20:18:04 +0000 Message-ID: <5BE572AB-D17A-4890-8385-B0F9A16C2A3F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.49.63] Content-Type: text/plain; charset="Windows-1252" Content-ID: <55559D70BC1BA741BF320287835EF8D6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-roll-mpl-parameter-configuration.all@tools.ietf.org" Subject: [secdir] Secdir review of draft-ietf-roll-mpl-parameter-configuration-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 20:18:07 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any = other last call comments. This draft defines a new DHCPv6 option, whereby a DHCP server can configure= a client with Multicast Protocol for Low power and Lossy Networks (MPL) p= olicy. The option definition seems straightforward. Security Considerations= outlines three items which seem useful: 1. Describing a resource consumption threat ("excessive layer-2 broadcastin= g=93) resulting from a man-in-the-middle modifying policy sent within an op= tion. If there is a suggested mitigation (e.g., a means of integrity protec= ting the DHCPv6 traffic between the client and server) this would be worth = noting. But I=92m not sure if there any available mitigation in a ROLL envi= ronment. 2. Making a requirement that a server implementation choose reasonable poli= cy values. This might be more useful if it were phrased as a threat, someth= ing like =93Server implementations need to take care in setting reasonable = bounds for each parameter in order to avoid overloading the network." 3. Making a requirement that the "DHCP server or the network itself shall b= e trusted by some means including network access control or DHCP authentica= tion=94. Is this this =93shall=94 intended to be an RFC 2119 =93MUST=94? I consider this draft to be Ready with nits. Brian From nobody Thu Jun 25 13:35:36 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC2C1AD066; Thu, 25 Jun 2015 13:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUO6U0vrC9D8; Thu, 25 Jun 2015 13:35:30 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7571AD062; Thu, 25 Jun 2015 13:35:30 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5PKZFD3086541 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 25 Jun 2015 15:35:25 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Hilarie Orman" Date: Thu, 25 Jun 2015 15:35:14 -0500 Message-ID: <46F73FD7-A802-4D31-9407-5BB0BA410182@nostrum.com> In-Reply-To: <201506151848.t5FImZ8e006065@sylvester.rhmr.com> References: <201506151848.t5FImZ8e006065@sylvester.rhmr.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: Kathleen Moriarty , iesg@ietf.org, draft-ietf-sipcore-6665-clarification@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Security review of draft-ietf-sipcore-6665-clarification-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 20:35:31 -0000 Hi, I believe Adam is on vacation, or otherwise offline. Thus I will attempt a response, inline: Thanks! Ben. On 15 Jun 2015, at 13:48, Hilarie Orman wrote: [...] > > SIP is big, very big, ... Yes. Yes, it is. :-) > ... and I've not even come close to reading all the > defining documents. Thus, I'm on shaky ground here. I believe that a > GRUU stands for a collection of contact handles for an individual, > and it is thus an identifier for a protocol entity. > > The clarification addresses when to use GRUUs, and the answer is > something like "for all dialogs, unless the dialog is forbidden." > The clarification emphasizes that it applies to INVITE dialogs. > > According to the text, implementers have not always used a GRUU > as a local target. Is this deliberate or accidental? Is there > some perceived advantage to avoiding GRUUs for INVITE? If so, > can the clarification explain why it is a misconception? I think it falls more to accidental in this particular case. That is, the original text in RFC 6665 was interpreted by some to only apply to SUBSCRIBE-created dialogs. That was not the intent. > > I don't really understand why GRUUs are to be avoided for forbidden > dialogs. Perhaps it is an optimization that would be obvious to > a skilled SIP implementor. It's the other way around. It's not that GRUUs are to be avoided--it's that if the local contact for a dialog is _not_ a GRUU, then any request that might create a subscription to the dialog's state is forbidden. > > Beyond that, I am not at all sure about the effect of GRUUs on the > overall security of the protocol. If they are used for all dialogs, > might that open the door to some sort of amplication attack? Does > it allow some sort of probing that could widen the attack surface? > I would like to see a sentence or two in the security considerations > explaining why not. This draft does not change the intended use of GRUUs described in RFC 6665. It's only purpose is to clarify that intent. Thus the security considerations already in RFC6665 should be sufficient. (If for some reason they are not sufficient, that's a different problem, and should be addressed separately from this draft.) > > An editorial comment about the text "... to allow you to send ...". > "You" is a confusing informality in a protocol description. The > formal name of the role ("notifier"?) should be used. The "you" here doesn't refer to the notifier. It refers to any UA in the abstract. While a more formal construct might be "allow one to send" or even "allow SIP UAs to send", I'm inclined to leave it as is. From nobody Thu Jun 25 14:32:49 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BBC1B2AD6; Thu, 25 Jun 2015 14:32: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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQPuClLLesCO; Thu, 25 Jun 2015 14:32:42 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0A001B2AD5; Thu, 25 Jun 2015 14:32:40 -0700 (PDT) Received: by oiyy130 with SMTP id y130so62359993oiy.0; Thu, 25 Jun 2015 14:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=BdMAo/4bHPA5hv4im1Whn46alznssKmPZh+sWYUMV2I=; b=ieYAtTXwgQIStnfSu6DVp1XYMczgPYLGC7QS9qZAuwAmufajlS0PylIWWSpCMKMVm+ lmhNtVu+3QxXYy4LUJPwa5oXDZqBA3cLDvozoi+YXAskZGSlfi4KnJgAhLjgfDPlFdX1 Uya7uZ2dW33WdK2bVOM8+cLmUh2tjkEPRfMkWuWVSraf4UjpmibC+BJC8WeqIzv3uRy6 QDREm3PMzi7eYJSg7oLDCsIpje/HL3ti5mk/Yz3swWpw3tHso866IaCoXm66IWcNdKx5 8oMntZt1pIDgIPsTiXYVUVILiF+Dd/ciVilF05NJdCDvAeWIK3hRP3eSdmVSQuIYSgn5 hwxQ== X-Received: by 10.202.187.138 with SMTP id l132mr39046779oif.31.1435267960384; Thu, 25 Jun 2015 14:32:40 -0700 (PDT) Received: from adams-mac-mini.attlocal.net (99-64-100-131.lightspeed.austtx.sbcglobal.net. [99.64.100.131]) by mx.google.com with ESMTPSA id ej6sm4679724obb.2.2015.06.25.14.32.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jun 2015 14:32:39 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_2732D2AA-8F6B-49ED-8829-8599B3C5D6F1" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: "Adam W. Montville" In-Reply-To: Date: Thu, 25 Jun 2015 16:32:38 -0500 Message-Id: <13E52A73-7D81-458E-880F-890809BBBC03@gmail.com> References: <4CA0A65D-E5FD-408C-A6B9-6ECB12A81B7C@gmail.com> To: Mike Jones X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "draft-ietf-jose-jwk-thumbprint.all@ietf.org" , The IESG , "jose@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] sector review of draft-ietf-jose-jwk-thumbprint-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 21:32:45 -0000 --Apple-Mail=_2732D2AA-8F6B-49ED-8829-8599B3C5D6F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I haven=E2=80=99t an objection to the paragraph as worded, so it works = for me. Should have made that clear before - sorry. > On Jun 24, 2015, at 12:49 PM, Mike Jones = wrote: >=20 > Hi Adam, > =20 > I take your point that the paragraph would seem simpler without the = last sentence, but I=E2=80=99d rather err on the side of giving readers = more information than less. While in many cases knowledge of the hash = function used need not be propagated (per the example in the beginning = of the paragraph), sometimes it does. So Nat and I decided to also = include a sentence about when it does. Per the previous paragraph, = which hash function to use is an application choice. > =20 > =46rom that viewpoint, does the current paragraph work for you, or is = there a specific wording change that you=E2=80=99d still like to see? > =20 > Thanks again for your review! > =20 > -- Mike > =20 > From: Adam W. Montville [mailto:adam.w.montville@gmail.com]=20 > Sent: Wednesday, June 24, 2015 5:12 AM > To: Mike Jones > Cc: The IESG; secdir@ietf.org; = draft-ietf-jose-jwk-thumbprint.all@ietf.org; jose@ietf.org > Subject: Re: sector review of draft-ietf-jose-jwk-thumbprint-05 > =20 > Hi Nat and Mike, > =20 > Thanks for your attention on this issue. I see the following text in = section 3.4: > =20 > Note that in many cases, only the party that creates a key will need > to know the hash function used. A typical usage is for the = producer > of the key to use the base64url-encoded JWK Thumbprint value as a > "kid" (key ID) value. The consumer of the "kid" treats it as an > opaque value that it uses to select the key. Only if multiple > parties will be reproducing the JWK Thumbprint calculation for some > reason, will parties other than the original producer of the JWK > Thumbprint need to know which hash function was used. > =20 > =20 > Would it make the draft clearer if that last sentence were omitted? = The way this paragraph reads is such that draft considers and would = allow for multiple parties generating key IDs, but then we=E2=80=99re = back at not knowing which algorithm was chosen. If that last sentence = were omitted, this would be less of an issue. =20 > =20 > =20 > On Jun 24, 2015, at 3:40 AM, Mike Jones > wrote: > =20 > Hi Adam, > =20 > Thanks again for your review comments. = https://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-06 = has been = posted to address them. See sections 3.4 (Selection of Hash Function) = and 6 (IANA Considerations). > =20 > Thanks = again, > -- Nat and = Mike > =20 > From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com = ]=20 > Sent: Monday, June 22, 2015 12:51 PM > To: Mike Jones > Cc: Adam W. Montville; The IESG; secdir@ietf.org = ; draft-ietf-jose-jwk-thumbprint.all@ietf.org = ; jose@ietf.org = > Subject: Re: sector review of draft-ietf-jose-jwk-thumbprint-05 > =20 > Yes, thank you. > Kathleen=20 >=20 > Sent from my iPhone >=20 > On Jun 22, 2015, at 9:18 PM, Mike Jones > wrote: >=20 > I=E2=80=99d be glad to add the explanation below to the draft and to = also include an IANA considerations section that states we are updating = the expert review instructions for a registry, as Jim Schaad had = suggested. Chairs and Kathleen, do you want Nat and I to proceed to = publish an updated draft? > =20 > -- = Mike > =20 > From: Adam W. Montville [mailto:adam.w.montville@gmail.com = ]=20 > Sent: Friday, June 12, 2015 5:07 AM > To: Mike Jones > Cc: The IESG; secdir@ietf.org ; = draft-ietf-jose-jwk-thumbprint.all@ietf.org = ; jose@ietf.org = > Subject: Re: sector review of draft-ietf-jose-jwk-thumbprint-05 > =20 > =20 > On Jun 11, 2015, at 4:25 PM, Mike Jones > wrote: > =20 > Hi Adam, >=20 > Thanks for the secdir review. >=20 >=20 >=20 >=20 > From: Adam W. Montville [mailto:adam.w.montville@gmail.com = ] > Sent: Monday, June 08, 2015 8:46 AM > To: The IESG; secdir@ietf.org ; = draft-ietf-jose-jwk-thumbprint.all@ietf.org = > Subject: sector review of draft-ietf-jose-jwk-thumbprint-05 >=20 >=20 >=20 >=20 > Hi, >=20 >=20 >=20 >=20 > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >=20 > I believe the document is ready with (potential) issues. The =E2=80=9Cw= ith issues=E2=80=9D might be due to ignorance on my part. The draft = does a very good job of explaining the canonical form of a JSON Web Key = that can be used for establishing a thumbprint under varying = circumstances, complete with what I found to be helpful examples. >=20 > The primary issue I have is that it=E2=80=99s unclear how relying = parties are going to know which hash algorithm has been used. The = examples use SHA-256, but I=E2=80=99m not seeing where SHA-256 might be = specified as a MUST or even a SHOULD. Moreover, the example output = ultimately shows only the Base-64 encoding of the resulting hash, which = says nothing about the algorithm used to identify a key. >=20 > Earlier drafts had included fields whose names were intended to = communicate the information about the hash function used - see the "jkt" = field definitions in = http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-01#section-4 = = - but several working group reviewers suggested that these fields were = unnecessary and that the typical usage would be as "kid" (key ID) field = values. With that removal, it falls onto the application to specify the = hash algorithm for its particular usage. >=20 > This isn't as bad as you might think, however, because typically the = consumer of the "kid" doesn't need to know the algorithm because it = won't be reproducing the computation. It just relies on the fact that a = unique key ID value was generated for the key and compares "kid" values = as opaque strings to find the appropriate key. In this usage, the = producer of the key is the only party that needs to know the hash = algorithm that it is using. I hope this helps. > =20 > Yes, this does help, thank you. It seems like something that could be = easily added to the draft to explain why the generating algorithm = needn=E2=80=99t be disclosed so that slow folk like myself get the = picture straight away. > =20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Additionally, in Section 4, =E2=80=9CJSON and Unicode = Considerations=E2=80=9D some =E2=80=9Cshould=E2=80=9Ds are used, but = I=E2=80=99m not reading them as SHOULDs. Should they be SHOULDs? For = example, the start of the third paragraph in that section: =E2=80=9Cif = new JWK members are defined that use non-ASCII member names, their = definitions should specify the exact Unicode code point sequences used = to represent them.=E2=80=9D It=E2=80=99s not clear to me whether this = is a strong statement or just a recommendation - it seems that this = draft could help the future by making stronger statements to encourage = future interoperability. >=20 > For the other JOSE specifications, our chair Jim Schaad took the = position that RFC 2119 keywords should be reserved for testable protocol = behaviors and that other uses of the English word "should" should not = use "SHOULD". The authors followed that convention in this document. I = do understand that other authors and working groups have taken different = positions in this regard. If there are particular uses that you still = feel should be changed to use RFC 2119 keywords, please call them out. > =20 > This is all good, too. I was simply pointing out that there are = =E2=80=9Cshould=E2=80=9Ds around that may need to be considered as = =E2=80=9CSHOULD=E2=80=9Ds. I also see Jim=E2=80=99s (and others=E2=80=99) = subsequent notes on the subject, so this is good from my perspective. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kind regards, > Adam >=20 > Thanks = again! > -- = Mike --Apple-Mail=_2732D2AA-8F6B-49ED-8829-8599B3C5D6F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I haven=E2=80=99t an objection to the = paragraph as worded, so it works for me.  Should have made that = clear before - sorry.


On = Jun 24, 2015, at 12:49 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Hi Adam,
 
I take your point that = the paragraph would seem simpler without the last sentence, but I=E2=80=99= d rather err on the side of giving readers more information than = less.  While in many cases knowledge of the hash function used need = not be propagated (per the example in the beginning of the paragraph), = sometimes it does.  So Nat and I decided to also include a sentence = about when it does.  Per the previous paragraph, which hash = function to use is an application choice.
 
=46rom that viewpoint, = does the current paragraph work for you, or is there a specific wording = change that you=E2=80=99d still like to see?
 
Thanks again for your = review!
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            -- = Mike
 
From: Adam W. Montville [mailto:adam.w.montville@gmail.com] 
Sent: Wednesday, June 24, 2015 = 5:12 AM
To: Mike Jones
Cc: The = IESG; secdir@ietf.org; = draft-ietf-jose-jwk-thumbprint.all@ietf.org; jose@ietf.org
Subject: Re: sector review of = draft-ietf-jose-jwk-thumbprint-05
 
Hi Nat and Mike,
 
Thanks for your attention on this issue.  I see = the following text in section 3.4:
 
Note that in many cases, only the party = that creates a key will need
   to know = the hash function used.  A typical usage is for the producer
   of the key to use the base64url-encoded JWK = Thumbprint value as a
   "kid" = (key ID) value.  The consumer of the "kid" treats it as an
   opaque value that it uses to select the key. =  Only if multiple
   parties = will be reproducing the JWK Thumbprint calculation for some
   reason, will parties other than the original = producer of the JWK
   Thumbprint need to know = which hash function was used.
 
 
Would it make the = draft clearer if that last sentence were omitted?  The way this = paragraph reads is such that draft considers and would allow for = multiple parties generating key IDs, but then we=E2=80=99re back at not = knowing which algorithm was chosen.  If that last sentence were = omitted, this would be less of an issue.  
 
 
On = Jun 24, 2015, at 3:40 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
 
Hi = Adam,
 
Thanks again for your review = comments.  https://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-06 has been = posted to address them.  See sections 3.4 (Selection of Hash = Function) and 6 (IANA Considerations).
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = Thanks again,
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            -- = Nat and Mike
 
From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] 
Sent: Monday, June 22, 2015 12:51 = PM
To: Mike Jones
Cc: Adam = W. Montville; The IESG; secdir@ietf.org; draft-ietf-jose-jwk-thumbprint.all@ietf.org; jose@ietf.org
Subject: Re: sector review of = draft-ietf-jose-jwk-thumbprint-05
 
Yes, thank you.
Kathleen 

Sent from my iPhone


On= Jun 22, 2015, at 9:18 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I=E2=80=99d be glad to add the explanation below to the draft = and to also include an IANA considerations section that states we are = updating the expert review instructions for a registry, as Jim Schaad = had suggested.  Chairs and Kathleen, do you want Nat and I to = proceed to publish an updated draft?
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
From: Adam W. Montville [mailto:adam.w.montville@gmail.com] 
Sent: Friday, June 12, 2015 5:07 = AM
To: Mike Jones
Cc: The = IESG; secdir@ietf.org; draft-ietf-jose-jwk-thumbprint.all@ietf.org; jose@ietf.org
Subject: Re: sector review of = draft-ietf-jose-jwk-thumbprint-05
 
 
On Jun 11, 2015, at 4:25 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
 
Hi Adam,

Thanks for the secdir = review.




From: Adam W. Montville = [mailto:adam.w.montville@gmail.com]
Sent: Monday, June 08, 2015 8:46 AM
To: The = IESG; secdir@ietf.org; draft-ietf-jose-jwk-thumbprint.all@ietf.org
Subject: sector review of = draft-ietf-jose-jwk-thumbprint-05




Hi,




I have reviewed this = document as part of the security directorate's ongoing effort to review = all IETF documents being processed by the IESG. These comments were = written primarily for the benefit of the security area directors. = Document editors and WG chairs should treat these comments just like any = other last call comments.

I believe the = document is ready with (potential) issues.  The =E2=80=9Cwith = issues=E2=80=9D might be due to ignorance on my part.  The draft = does a very good job of explaining the canonical form of a JSON Web Key = that can be used for establishing a thumbprint under varying = circumstances, complete with what I found to be helpful examples.

The primary issue I have is that it=E2=80=99s = unclear how relying parties are going to know which hash algorithm has = been used.  The examples use SHA-256, but I=E2=80=99m not seeing = where SHA-256 might be specified as a MUST or even a SHOULD. =  Moreover, the example output ultimately shows only the Base-64 = encoding of the resulting hash, which says nothing about the algorithm = used to identify a key.

Earlier drafts had included fields whose names = were intended to communicate the information about the hash function = used - see the "jkt" field definitions in http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-01#se= ction-4 - but several working = group reviewers suggested that these fields were unnecessary and that = the typical usage would be as "kid" (key ID) field values.  With = that removal, it falls onto the application to specify the hash = algorithm for its particular usage.

This = isn't as bad as you might think, however, because typically the consumer = of the "kid" doesn't need to know the algorithm because it won't be = reproducing the computation.  It just relies on the fact that a = unique key ID value was generated for the key and compares "kid" values = as opaque strings to find the appropriate key.  In this usage, the = producer of the key is the only party that needs to know the hash = algorithm that it is using.  I hope this helps.
 
Yes, this does help, thank you.  It = seems like something that could be easily added to the draft to explain = why the generating algorithm needn=E2=80=99t be disclosed so that slow = folk like myself get the picture straight away.
 








Additionally, in Section = 4, =E2=80=9CJSON and Unicode Considerations=E2=80=9D some =E2=80=9Cshould=E2= =80=9Ds are used, but I=E2=80=99m not reading them as SHOULDs. Should = they be SHOULDs?  For example, the start of the third paragraph in = that section: =E2=80=9Cif new JWK members are defined that use non-ASCII = member names, their definitions should specify the exact Unicode code = point sequences used to represent them.=E2=80=9D  It=E2=80=99s not = clear to me whether this is a strong statement or just a recommendation = - it seems that this draft could help the future by making stronger = statements to encourage future interoperability.

For the other JOSE = specifications, our chair Jim Schaad took the position that RFC 2119 = keywords should be reserved for testable protocol behaviors and that = other uses of the English word "should" should not use "SHOULD". =  The authors followed that convention in this document.  I do = understand that other authors and working groups have taken different = positions in this regard.  If there are particular uses that you = still feel should be changed to use RFC 2119 keywords, please call them = out.
 
This is all good, too.  I was simply = pointing out that there are =E2=80=9Cshould=E2=80=9Ds around that may = need to be considered as =E2=80=9CSHOULD=E2=80=9Ds. I also see Jim=E2=80=99= s (and others=E2=80=99) subsequent notes on the subject, so this is good = from my perspective.








Kind regards,
Adam

        &= nbsp;       =             &n= bsp;   =             &n= bsp;   =             &n= bsp;   Thanks again!
        &= nbsp;       =             &n= bsp;   =             &n= bsp;   =             &n= bsp;   -- = Mike
<= /div>

= --Apple-Mail=_2732D2AA-8F6B-49ED-8829-8599B3C5D6F1-- From nobody Fri Jun 26 09:18:00 2015 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F64C1A8791; Fri, 26 Jun 2015 08:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1435332969; bh=ukYrK34ZJdFYjZMwiFNeD8KumlxWG4NoaYDX6Q1+xg4=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=fdw0J82nfhRHOXcrqF/BLNUmr9c2aGf/2BTxloW+j8eVWPW8J/SDQNyPsb2uaJG/5 6TEEATCAr262z3DSaSNrPoFMvWhTeQCccmq06ATtgo6PUcbxPcjGRX6IxlwJiJnMDu LaWJ3nP7IRqpBtMmOOCVcJp1c10EiF/06TurA8Bc= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A5E1A8791; Fri, 26 Jun 2015 08:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtQFsIgSeytl; Fri, 26 Jun 2015 08:36:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BD61A8784; Fri, 26 Jun 2015 08:36:05 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150626153605.18943.13946.idtracker@ietfa.amsl.com> Date: Fri, 26 Jun 2015 08:36:05 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 26 Jun 2015 09:17:54 -0700 Subject: [secdir] [new-work] WG Review: Selection of Language for Internet Media (slim) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 15:36:09 -0000 A new IETF working group has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-07-06. Selection of Language for Internet Media (slim) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Barry Leiba Mailing list Address: slim@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/slim Archive: https://mailarchive.ietf.org/arch/browse/slim/ Charter: Description of Working Group: A mutually comprehensible language is helpful for human communication. This is true across a range of circumstances and environments. In general, the problem is most acute in situations where there is not a clear choice for a single language, such as environments lacking contextual or out-of-band information regarding the identity of the parties and the language to be used. The group will address two specific cases that most urgently need a technical solution: One problem space is non-real-time communication, specifically email for one-to-many or where the set of recipients is dynamic or different recipients require different languages; the other is real-time communication, specifically emergency calling, preferably also useful for other cases where the parties may not know each other personally or where one party wishes to accommodate people with varying language and media needs. In the real-time communication case, language and media are intrinsically linked, for example, signed languages require a video media. While the two use cases are in different contexts (real time and non-real-time), the fundamental goal is the same: to enable selection of the best-fit language(s) for a specific situation. Some of the details will also be in common across the cases, e.g., the language tags. Having a single WG address both cases makes it clear that these are two aspects of the same basic problem. A single WG also makes it easier to maximize similarities and avoid unnecessary fragmentation of the solutions, and facilitates broader review. The group will produce two documents, one for email, and one for real-time communications. In the email case, the group will determine a MIME based solution that enables a single email message to contain multiple language versions of the content, with provisions to help clients select a best fit version. In the real-time communication case, the group will produce a specification based on draft-gellens-slim-negotiating-human-language, enabling negotiation of a human language per media stream. The specification must be suitable for use in emergency communications as specified in RFC 6443 and RFC 6881 (which use SIP and SDP to negotiate media); it is desirable to also be suitable for use in non-emergency real-time communications that share the same call set-up and media negotiation protocols. The mechanism will permit the caller's media and language needs and preferences to be matched against what the called party is able to provide. The mechanism will permit resources (e.g., translation, relay, media) to be allocated or engaged as early as possible in the call set-up or for the call to be routed or handled specially (e.g., routed to a resource able to provide a needed language and/or media). Alternatives such as doing the negotiation in SIP have been thoroughly explored in the past and are out of scope (although the scope might be extended after the SDP mechanism has been advanced). By adding language to the existing media negotiation mechanism as used in RFC 6443 and RFC 6881, the group can meet the basic use cases with minimal added complexity and be able to enhance later for additional use cases as needed. Milestones: Oct 2015 - Submit "Multiple Language Content Type" to the IESG (based on draft-tomkinson-slim-multilangcontent) Feb 2016 - Submit "Negotiating Human Language in Real-Time Communications" to the IESG (based on draft-gellens-slim-negotiating-human-language) _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Jun 26 12:01:50 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2665E1AC3F1; Fri, 26 Jun 2015 12:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_ORG=0.611] autolearn=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 AsZOG-U4y3Oa; Fri, 26 Jun 2015 12:01:44 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624871AC3DF; Fri, 26 Jun 2015 12:01:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id B79ECE203A; Fri, 26 Jun 2015 15:01:23 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 17829-05; Fri, 26 Jun 2015 15:01:20 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id A7583E2038; Fri, 26 Jun 2015 15:01:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1435345280; bh=KNYymWh3p0/XzAmQfsuR+XBKSfASe8joiPhp7Tsr0pg=; h=From:To:Cc:Subject:Date; b=UB4xhbvNkKYxvvLT4vlPdRsNDG5U45468znbCf8idbVnIugG42oOX6XysMFrvo0Wk 7JYaV8uArZ91EuAWZoBELx0OneOSlaWSUR1yLoxioBSShVbZv0nGBDa/Nutmlqmfzk Gf3ncwp04z05wR1+wawZBA9iiJxrXU73Z97wJpKo= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t5QJ1JMK027861; Fri, 26 Jun 2015 15:01:19 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Fri, 26 Jun 2015 15:01:19 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: peter@andyet.com, xmpp-chairs@tools.ietf.org, fippo@andyet.com Subject: [secdir] sec-dir review of draft-ietf-xmpp-dna-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 19:01:46 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Ready to publish Details: I have no issues with this document as written. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Sat Jun 27 09:23:54 2015 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EB71B3360; Thu, 25 Jun 2015 01:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1435222631; bh=E0Y0bLmfQ+UXLllolMb0NOHDEp4IltTtwNjEIEFKhTQ=; h=From:To:Date:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=WDrW4Ut7NY7rs+hcPZJ3t8/JHRmxlrtrulnC3MO/Y7kdYRD6A3ARLlnCDxL6ly3Ye A/lgwYwZlold9woWTW6UeiTWQ9olRn5/ySmKUsfNX9tK+Y8p3LwmKlIjMlBfEW/ddl 07+aML1f3k6Pw/f/r3ZD6KIgKc0aPc9AAteYl5Gw= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E26B1B3360 for ; Thu, 25 Jun 2015 01:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1lJUjD7vb2F for ; Thu, 25 Jun 2015 01:57:07 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (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 12BF91B335D for ; Thu, 25 Jun 2015 01:57:06 -0700 (PDT) Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [84.16.68.91]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5P8v4a2014421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 25 Jun 2015 10:57:04 +0200 Received: from RHillNew (adsl-178-38-12-166.adslplus.ch [178.38.12.166]) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id t5P8v3Yg011718 for ; Thu, 25 Jun 2015 10:57:04 +0200 From: "Richard Hill" To: Date: Thu, 25 Jun 2015 10:57:04 +0200 Message-ID: <004001d0af24$e89d70e0$b9d852a0$@ch> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdCvJOg5Dlbkvi9rSgCEkL6kWmG8Uw== Content-Language: en-us X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Sat, 27 Jun 2015 09:23:53 -0700 Subject: [secdir] [new-work] Comment on WG modern X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 08:57:11 -0000 I refer to: https://www.ietf.org/mailman/private/new-work/2015-June/000533.html As I understand it, this is a proposal to create new working group that will consider managing, ordering, distributing, and registering telephone numbers. In my view, the proposed work clearly falls within the remit of ITU-T Study Group 2 and I don't think that it would be a good idea for the IETF to create a group whose mandate squarely overlaps with the mandate of ITU-T. A more detailed explanation follows. I presume that "telephone numbers" refers to E.164 numbers, that is, numbers that are standardized and administered in accordance with ITU-T Recommendations E.164, E.164.1, E.190, and related ITU-T Recommendations. In accordance with those recommendations, and related ITU Plenipotentiary Resolutions, the management and administration of those numbers is done at the international level by the Telecommunications Standardization Bureau (TSB) which assigned country codes (such as 41 for Switzerland) and by national authorities at the country level. Countries can have more than one country code, or less than one country code: that is, several countries can share one country code. The best-known example of this situation is country code 1, which is shared by the USA, Canada, and a number of other countries. The administration of the numbers under country code 1 is performed by the North American Numbering Plan Administration, which is a private entity to which the US Federal Communication Commission delegates the administration. At present that entity is Neustar. The policies that the Administration implements are developed by the North American Numbering Plan which, if I understand correctly, is comprised of operators that use numbers under country code 1. The US arrangements for the management of telephone numbers are, I believe, unusual. In other countries the management is performed directly by the national regulatory authority, which sets the policies and assigns blocks of numbers to operators. Thus, in general, decisions about managing, ordering, distributing and registering telephone numbers are made by national regulatory authorities. I now refer to one of the presentations that was made during early discussions regarding this working group: http://www.ietf.org/proceedings/92/slides/slides-92-modern-2.pdf Slide 2 states that phone numbers are "opaque". I don't know what is meant by that, but it is true that it is not obvious whether a particular phone number is fixed or mobile, or, if fixed, what geography it corresponds to. But that is because phone numbers do not have significance: you have to look up the code in a database to find out what meaning, if any, is attached to it (e.g. that 41 corresponds to Switzerland and that 4179 corresponds to mobile phones in Switzerland). (By the way, many countries now have full number portability within the fixed and mobile numbering plans, so it is no longer possible to tell which mobile operator is service a particular mobile number, or what geographical area corresponds to a particular fixed number. For example, 4122 was the geographic code for Geneva, Switzerland, but now, with number portability, it could correspond to a fixed telephone in Zurich, Switzerland.) Slide 2 states that phone numbers are "still anchored in the PSTN". Of course: they were designed for the PSTN and have been adapted and upgraded to meet the needs of the current telephony system, including mobile telephony. Slide 3 says: "What if you could get numbers the way you get domain names? Or what if you could get numbers like you get IP addresses?" Those are rhetorical questions, because it would require changes in the ITU-T Recommendations, and national regulations, to be able to do that. Slide 5 says that the proposed working group will not set telephone number policies. Obviously, since those policies are set by the ITU-T and by national regulatory authorities. So I don't understand what the proposed working group would do that would help to achieve the objectives set forth in slide 3, other than to develop standards that would facilitate the exchange of information related to the administration of numbers (that's my understanding of what slides 9 to 17 are presenting). For sure standards to facilitate exchange of information are very useful, and there are some ITU-T Recommendations relating to that (in particular for providing information on national numbering plans). But it seems to me that development of such standards falls squarely within the remit of ITU-T Study Group 2, so it does not appear appropriate to me to create an IETF working group whose mandate would clearly overlap with the ITU-T's mandate. I was heavily involved in the ENUM discussions that arose when the IETF made some decisions without first liaising with ITU-T Study Group 2. That created a difficult atmosphere and it took a lot of effort to find a solution that satisfied both the IETF folks that designed ENUM and national regulators. I would urge the IETF not to repeat that mistake. If somebody thinks that some additional standards are needed regarding telephone numbers, then I would recommend that the requirements be submitted to ITU-T Study Group 2, and that the folks who are interested in the issue participate in the discussions in ITU-T Study Group 2. Otherwise you will likely wind up with the same contentious situation that arose back in 2001 regarding ENUM. Slide 5 says "Numbering inventory is a scarce asset, not like the DNS". There may be some scarcity under code 1, because the North American Numbering Plan has not expanded the number of digits in a very long time. In most other countries, the number of digits has been increased and there is no scarcity. Slide 10 refers to Skype. Skype actually applied to ITU-T to obtain an international code (country codes need not be geographic, there are non-geographic country codes; sub-codes of those non-geographic codes are assigned to operators that provide services in more than one country). Skype was refused the code because they refused to certify that they operate physical infrastructure in at least two countries (that's one of the conditions for obtaining a non-geographic code). As I understood the discussion at the time, Skype did not wish to certify that because they did not wish to be subject to telephony regulations. So any assignments to Skype would presumably have to comply with applicable regulations. Since the people who know and understand the applicable regulations participate in the work of ITU-T Study Group 2, it seems to me that discussions of these topics should take place there, and not in the IETF. Best, Richard Hill _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Sat Jun 27 09:45:28 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC8A1A1B84 for ; Sat, 27 Jun 2015 09:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 epWjFUaT3TyP for ; Sat, 27 Jun 2015 09:45:25 -0700 (PDT) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (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 4D6131A1B4C for ; Sat, 27 Jun 2015 09:45:25 -0700 (PDT) Received: by igcsj18 with SMTP id sj18so52286719igc.1 for ; Sat, 27 Jun 2015 09:45:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0dGyLv7Q3XJadZqrtlZF+AXh4HvY/X3H6vSBzQegtWg=; b=UCO7ZggCy4rzmJNE2/WykrzZq8fPm7A4aivIvgIr9/aClBCyp9qUxodZs6I5EGpMxa jp9uHFnNfXRGwu7lBRvkG2g2jI0i7U7AYO24KUWmMI1zZcfH7Vn/ZIUEHhiuR81GKL2w 99CMiBIclAEVBkj1YM9NHtoRmS9RQ9r/Cn7ie5+YrS4nNHomKWFcXU3niJbXAheLEtvj UpUkFx8yrk/v/Hod8bJkP2IBHMVbfWuZN4o9gt5JmBZmOOPTp4wNPQtyT6CJDgKmfgHr Q9BtgPrfzQw0ADLVfD/TZU7VTQcUe4V+ot39EjRWKhVzqeNMMmrcw6Mey8aNVYrAeyNf /VGw== X-Gm-Message-State: ALoCoQmoEEEu7eV4uSN/sJFJGUvcN9DGS4c6uoLdj/Rgo7oJX05yQMR63ZqdIjyto1obfaw6220A X-Received: by 10.50.87.74 with SMTP id v10mr4836913igz.37.1435423524741; Sat, 27 Jun 2015 09:45:24 -0700 (PDT) Received: from aither.local ([2601:282:4201:ef5b:e0dd:a498:af68:ea6f]) by mx.google.com with ESMTPSA id ij4sm1511985igb.7.2015.06.27.09.45.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Jun 2015 09:45:23 -0700 (PDT) Message-ID: <558ED320.2010700@andyet.net> Date: Sat, 27 Jun 2015 10:45:20 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Derek Atkins , iesg@ietf.org, secdir@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: peter@andyet.com, xmpp-chairs@tools.ietf.org, fippo@andyet.com Subject: Re: [secdir] sec-dir review of draft-ietf-xmpp-dna-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 16:45:26 -0000 Hi Derek, thanks for the review! Peter On 6/26/15 1:01 PM, Derek Atkins wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written with the intent of improving > security requirements and considerations in IETF drafts. Comments > not addressed in last call may be included in AD reviews during the > IESG review. Document editors and WG chairs should treat these > comments just like any other last call comments. > > Summary: > > Ready to publish > > Details: > > I have no issues with this document as written. > > -derek > From nobody Mon Jun 29 05:57:44 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF5B1A90EC; Mon, 29 Jun 2015 05:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.926 X-Spam-Level: ** X-Spam-Status: No, score=2.926 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 tO73bPmohRgp; Mon, 29 Jun 2015 05:57:38 -0700 (PDT) Received: from pacdcmhout01.cable.comcast.com (PACDCMHOUT01.cable.comcast.com [68.87.31.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990361A9068; Mon, 29 Jun 2015 05:57:37 -0700 (PDT) X-AuditID: 44571fa7-f796a6d000005411-d1-559140bfb87c Received: from pacdcexhub05.cable.comcast.com (dlpemail-wc-4p.sys.comcast.net [24.40.12.138]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by pacdcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id EA.48.21521.FB041955; Mon, 29 Jun 2015 08:57:36 -0400 (EDT) Received: from VAADCEX36.cable.comcast.com (147.191.103.213) by pacdcexhub05.cable.comcast.com (24.40.56.122) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 29 Jun 2015 08:57:31 -0400 Received: from VAADCEX39.cable.comcast.com (147.191.103.216) by VAADCEX36.cable.comcast.com (147.191.103.213) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 29 Jun 2015 08:57:30 -0400 Received: from VAADCEX39.cable.comcast.com ([fe80::3aea:a7ff:fe12:37f4]) by VAADCEX39.cable.comcast.com ([fe80::3aea:a7ff:fe12:37f4%19]) with mapi id 15.00.1044.021; Mon, 29 Jun 2015 08:57:30 -0400 From: "Livingood, Jason" To: Yaron Sheffer , IETF Security Directorate , The IESG , "draft-ietf-dnsop-negative-trust-anchors.all@tools.ietf.org" Thread-Topic: SecDir review of draft-ietf-dnsop-negative-trust-anchors-10 Thread-Index: AQHQqs3939n5Q1LeNESf2OzLcK//sJ3DgLCA Date: Mon, 29 Jun 2015 12:57:30 +0000 Message-ID: References: <55847A7D.9030504@gmail.com> In-Reply-To: <55847A7D.9030504@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [96.114.156.8] Content-Type: multipart/alternative; boundary="_000_D1B6B587108CBDjasonlivingoodcablecomcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42KR0ODp0j3gMDHU4P4XIYvjtz4zW8z4M5HZ 4sPChywWq+7PYHdg8dg56y67x5IlP5k8vlz+zBbAHMVlk5Kak1mWWqRvl8CV8Wf+S7aCvSYV WzbOZ2tgfK7dxcjJISFgIrF43UQWCFtM4sK99WxdjFwcQgLbmCT+N7xhhHAOMkq8a9nBCuEc ZpToO/CUCcI5yShx6sI6NpB+NgEbienbjjKDJEQEPjJK/Fz5gRUkISzgIbFj5SomEFtEwFNi 2YVbbBC2kcT653vBbBYBVYljr36xg9i8AvYSh/r/MYLYQgIaEl+v/AWLcwpoSqxcsxpsJiPQ sd9PrQGbySwgLnHryXwmiCcEJJbsOc8MYYtKvHz8D6xeVEBP4tCsj1CPGkhsXboPylaQ2L5/ GwvEnGSJc5s/MUHcIChxcuYTFogb9CQu7brMDlEvLnH4yA7WCYxSs5CsnoWkfRaSdoi4jsSC 3Z/YIGxtiWULXzPD2GcOPIbqdZDobjyJomYBI8cqRrmCxOSU5NyM/NISA0O95MSknFS95Pzc 5MTiEhC9iRGYNlzC5ZfvYLz3wukQowAHoxIP7wvLiaFCrIllxZW5hxglOJiVRHgvb54QKsSb klhZlVqUH19UmpNafIhRmoNFSZz31fTeUCGB9MSS1OzU1ILUIpgsEwenVANjR2rWnzV/462i bJZ7WYjnX31dqr/46B11ZQ+fM/25qXNz4vkfbE1h5Fpsvd63kkWPTWFVW0nA3gPdzoLK56/Y JZm8U+FrLez8HSfs9vTqua8vgsp7D522uPK14u2R9XdN55Znsf1oOeoa1/na8Zpay4c/567t 4uKS+++csFupsftzHv/tZiMlluKMREMt5qLiRAA/FodiFwMAAA== Archived-At: Subject: Re: [secdir] SecDir review of draft-ietf-dnsop-negative-trust-anchors-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 12:57:39 -0000 --_000_D1B6B587108CBDjasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 6/19/15, 4:24 PM, "Yaron Sheffer" > wrote: This is more of a rant than a review, however it presents a security perspe= ctive that seems to be at odds with the operational-first perspective of th= e document. Keeping in mind your feedback is as you say a rant, I will happily respond = below and try to shed some more light on this. ;-) As an aside, DNSSEC validation penetration would not be where it is today w= ithout NTAs. They have become critical; without them it is unlikely DNSSEC = would be particularly viable. This is the unfortunate reality, and implemen= ters are doing their best to make the network & namespace more secure withi= n the boundaries of operational reality. Even assuming that 99.9% of us will continue to trust ISPs for DNS resolution, IMHO the proposed solution would be better off with more automation and less celebration of "trained technical personnel". For example, the document has a SHOULD level requirement to test the NTA "periodically" in order to eventually remove it. Automated vs. manual was extensively discussed in the WG and the issue conc= luded with the text in the document now. Among the concerns with making thi= s more automated were whether an automated, centralized DNSSEC-disablement = function would itself be a juicy target of attack to enable downgrade attac= ks. Aside from that, DNS recursion has always been operated locally, on a d= istributed basis, and there is local policy such as NTAs that has tradition= ally a part of this. In the end, the WG felt that not automating this was b= etter than automating it. How about an alternative that shifts the responsibility to DevOps or to the actual vendors, and also empowers the .1% who maintain their own resolvers: "NTA implementors MUST attempt to validate the domain in question once ever= y MINUTE for the period of time that the Negative Trust Anchor is in place,= until such validation is again successful, and MUST remove the NTA as soon= as that happens." FWIW, the document does not have an RFC 2119 reference and so that sort of = requirement text would not carry much weight. In practice, however, impleme= nters use NTAs sparingly and are usually in very close contact with the dom= ain owner and are often advised by them of an estimated MTTR. Regards, Jason --_000_D1B6B587108CBDjasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On 6/19/15, 4:24 PM, "Yaron Sheffer" <yaronf.ietf@gmail.com> wrote:

This is more of a rant than a review, however it presents a sec= urity perspective that seems to be at odds with the operational-first persp= ective of the document.

Keeping in mind your feedback is as you say a rant, I will happily res= pond below and try to shed some more light on this. ;-)

As an aside, DNSSEC validation penetration would not be where it is to= day without NTAs. They have become critical; without them it is unlikely DN= SSEC would be particularly viable. This is the unfortunate reality, and imp= lementers are doing their best to make the network & namespace more secure within the boundaries of oper= ational reality.

Even assuming that 99.9% of us will continue to trust ISPs for DNS
resolution, IMHO the proposed solution would be better off with more <= /div>
automation and less celebration of "trained technical personnel&q= uot;. For
example, the document has a SHOULD level requirement to test the NTA <= /div>
"periodically" in order to eventually remove it.

Automated vs. manual was extensively discussed in the WG and th= e issue concluded with the text in the document now. Among the concerns wit= h making this more automated were whether an automated, centralized DNSSEC-= disablement function would itself be a juicy target of attack to enable downgrade attacks. Aside from that, = DNS recursion has always been operated locally, on a distributed basis, and= there is local policy such as NTAs that has traditionally a part of this. = In the end, the WG felt that not automating this was better than automating it. 

How about an
alternative that shifts the responsibility to DevOps or to the actual =
vendors, and also empowers the .1% who maintain their own resolvers:

"NTA implementors MUST attempt to validate the domain in question= once every MINUTE for the period of time that the Negative Trust Anchor is= in place, until such validation is again successful, and MUST remove the N= TA as soon as that happens."

FWIW, the document does not have an RFC 2119 reference and so that sor= t of requirement text would not carry much weight. In practice, however, im= plementers use NTAs sparingly and are usually in very close contact with th= e domain owner and are often advised by them of an estimated MTTR. 

Regards,
Jason
--_000_D1B6B587108CBDjasonlivingoodcablecomcastcom_-- From nobody Mon Jun 29 07:57:33 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C321ACDDF for ; Mon, 29 Jun 2015 07:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGTQ6cMYWGUp for ; Mon, 29 Jun 2015 07:57:30 -0700 (PDT) Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) (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 0A9A41ACDEE for ; Mon, 29 Jun 2015 07:57:25 -0700 (PDT) Received: by oiax193 with SMTP id x193so119761696oia.2 for ; Mon, 29 Jun 2015 07:57:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=paCySm2d/rwFqQuAFSKFJSMaYHixPxU73iRq8NVPgpE=; b=BmkLpjSem8vE7Hjzvzr7dch+e3igWSCY0/LRnSRTIEN0xqd2ZdIxiBqUk1nxXq9X5u PfH8oUH7+KLL7wW6oaoB9j4GgmzWoQYc/Q5KmnnrCFXxQpbqMuutOqkVMYooyrBbTpww lONPEvu5NRck3nlo8AeBtg89joEH2o6W194w69kY5R3dcOzgPq1AvxeFg7LWxrrZ8QYw jnlEF1c6vAwoREUcpqF5OeRFLppRtvihWnt6mBnhnCwlvt9GBQbDvj74AQXQnD623cIT WMqywqTYtgaq4PeXnN/jr5rMqX4xwuV5ZsNwzAdFsS+TyiSptvSqZiACE5LCPSbHq6jA w/hw== X-Gm-Message-State: ALoCoQnHHoxInhWNpEe5D9AX0Ej/PLxLKsQ9L9EDjswK+Ju04z1XHpnoE9OViNdatBKh3hTc6ZpY MIME-Version: 1.0 X-Received: by 10.202.1.209 with SMTP id 200mr13796930oib.86.1435589845243; Mon, 29 Jun 2015 07:57:25 -0700 (PDT) Received: by 10.202.203.134 with HTTP; Mon, 29 Jun 2015 07:57:25 -0700 (PDT) In-Reply-To: References: <55847A7D.9030504@gmail.com> Date: Mon, 29 Jun 2015 10:57:25 -0400 Message-ID: From: Warren Kumari To: "Livingood, Jason" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "draft-ietf-dnsop-negative-trust-anchors.all@tools.ietf.org" , The IESG , IETF Security Directorate Subject: Re: [secdir] SecDir review of draft-ietf-dnsop-negative-trust-anchors-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 14:57:32 -0000 On Mon, Jun 29, 2015 at 8:57 AM, Livingood, Jason wrote: > On 6/19/15, 4:24 PM, "Yaron Sheffer" wrote: > > This is more of a rant than a review, however it presents a security > perspective that seems to be at odds with the operational-first perspective > of the document. > > > Keeping in mind your feedback is as you say a rant, I will happily respond > below and try to shed some more light on this. ;-) > > As an aside, DNSSEC validation penetration would not be where it is today > without NTAs. They have become critical; without them it is unlikely DNSSEC > would be particularly viable. This is the unfortunate reality, and > implementers are doing their best to make the network & namespace more > secure within the boundaries of operational reality. > > Even assuming that 99.9% of us will continue to trust ISPs for DNS > resolution, IMHO the proposed solution would be better off with more > automation and less celebration of "trained technical personnel". For > example, the document has a SHOULD level requirement to test the NTA > "periodically" in order to eventually remove it. > > > Automated vs. manual was extensively discussed in the WG and the issue > concluded with the text in the document now. Among the concerns with making > this more automated were whether an automated, centralized > DNSSEC-disablement function would itself be a juicy target of attack to > enable downgrade attacks. Aside from that, DNS recursion has always been > operated locally, on a distributed basis, and there is local policy such as > NTAs that has traditionally a part of this. In the end, the WG felt that not > automating this was better than automating it. > > How about an > alternative that shifts the responsibility to DevOps or to the actual > vendors, and also empowers the .1% who maintain their own resolvers: > > "NTA implementors MUST attempt to validate the domain in question once every > MINUTE for the period of time that the Negative Trust Anchor is in place, > until such validation is again successful, and MUST remove the NTA as soon > as that happens." > > > FWIW, the document does not have an RFC 2119 reference and so that sort of > requirement text would not carry much weight. In practice, however, > implementers use NTAs sparingly and are usually in very close contact with > the domain owner and are often advised by them of an estimated MTTR. In addition, unless I'm very confused (entirely possible, no coffee yet!) the .1% of people (and hopefully increasing) who run their own resolvers are not affected by the NTA. If you don't trust your ISP (and many people don't), you really shouldn't be trusting them to do DNSSEC validation for you (they can easily set the AD bit on all queries, clear it on some, etc), you should do your own validation. If you do your own validation the NTA is a no-op for you. [ Apologies for delay, I was traveling (ICANN meeting...)] W > > Regards, > Jason > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Jun 30 02:01:22 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4D81A1B92 for ; Tue, 30 Jun 2015 01:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 3LtoV-lLPRxr for ; Tue, 30 Jun 2015 01:43:14 -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 1A1031A1BA4 for ; Tue, 30 Jun 2015 01:43:06 -0700 (PDT) Received: by oigx81 with SMTP id x81so2271861oig.1 for ; Tue, 30 Jun 2015 01:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rcAjctmZeQ6vYsz3epaMSfVDADd3Wcgo6zFNaB1p0ko=; b=DgPmGDyXMCo+9FYIpLlnVDDwlILVqs9KvGhCNGP0vCWcq7u2dhRDFkMkSmhO4t6/dw c9+9ff9gy5TYI8RWfiRdPRjnlXoRQqSThvpqenAZzK245Fk5lQ4/nXIglMOWnbnnwLO5 Pf21npY2hWqiDMrXbneag8+jDKPmkVEsLwwpPBVPtneF0OyiDIgvS2GfSaRF/YTvoVEL Iu73csDQzkfhvNxRxc1B2QCr9thWC5+N6B08Kd7+5DA/viwGmNFUG4VdYUhBJPlR8BcQ mY+rQEwiBjz709DWAtQ8pdvL8eN9uKaKxEBeuu0+q9wK3dkzRSrkt3vLETtIx+2NmVvl uzag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rcAjctmZeQ6vYsz3epaMSfVDADd3Wcgo6zFNaB1p0ko=; b=BCB4biWHJZJQiv2as8wvPQpt6QiMkDss/1BunCqf9BJYv2jv1vehnGyzmsCEhPkizH +jgOInlpOKN7Swn995d+oQ2WzKpHnqTrQ++xI1ObgztgmPwoxWDpKGzBoFazyshP0+Aw 3G164nSPkfQFSpxgkdEuXjSWxXqso/a+g7qU0OgjmYsaZKOg2OjZrJy/HiObiPT1RTa1 LrnT7elotxIuutaOtAnLviXUcxenOkqz1ZTaOwg8M/CeRBtCfmrv4DSsbRs+vvY4JbX6 4VNdoDjDQv9zV8u9kQV+uZniSomCvPlKZCft+/9eJxW5gC1vHkYROnCt2wKIeE7TioB7 vXuQ== X-Gm-Message-State: ALoCoQmzOU2NAx6IUXLlYFyITXX0g8hmGAGGjfnx7wvSkW3mbXdBQa/HraT6tBDP3ASJIP6tWnbR X-Received: by 10.202.57.137 with SMTP id g131mr16283728oia.122.1435653785557; Tue, 30 Jun 2015 01:43:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.66.130 with HTTP; Tue, 30 Jun 2015 01:42:45 -0700 (PDT) In-Reply-To: <558B1E9C.8080505@nostrum.com> References: <558B1E9C.8080505@nostrum.com> From: Takeshi Yoshino Date: Tue, 30 Jun 2015 17:42:45 +0900 Message-ID: To: Robert Sparks Content-Type: multipart/alternative; boundary=001a113cee2ae8c9670519b831b7 Archived-At: X-Mailman-Approved-At: Tue, 30 Jun 2015 02:01:21 -0700 Cc: "iesg@ietf.org" , draft-ietf-hybi-permessage-compression.all@ietf.org, "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-hybi-permessage-compression-22 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 08:43:16 -0000 --001a113cee2ae8c9670519b831b7 Content-Type: text/plain; charset=UTF-8 Thank you for review, Robert. On Thu, Jun 25, 2015 at 6:18 AM, Robert Sparks wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Summary: Ready with issues > > (fwiw, I also reviewed up through version -24). > > Section 7 (Intermediaries) should be more explicit that it's talking about an intermediary doing compression on one side and not (or doing different compression) on the other. > (If that's not what it's trying to set up, please clarify). > > OK. So, I'd like to change the text as follows: When an intermediary proxies ... Per-message Compression of messages received from one peer, and then forward the messages to the other peer, if the intermediary ... > It's not clear from reading RFC6455 that the idea of intermediaries changing the contents of the websocket extension negotiation mechanism was considered - have I missed the text in that RFC that discusses that? > Are there other extensions that suggest similar behavior? It's not immediately clear that the protocol mechanics do the right thing when the different negotiations on each side of the proxy fail differently. > > It's not well discussed in RFC6455. Right. AFAIK, there's no such extension defined, yet. I understand that this text (intermediary section in the I-D) works just not to disallow change of compression but there's nothing in RFC6455 that guarantees that such transformation doesn't cause any issue with other infrastructure of the WebSocket protocol. I believe that unless any extension that interferes with the other negotiated extensions (e.g. counting the number of negotiated extensions, relying on PMCE, etc.), the core WebSocket protocol (things defined in RFC6455) should work. If such an extension is introduced, it would be just considered to be incompatible with PMCEs, or that extension should describe how to coordinate with change on PMCE in the intermediaries section of its RFC. I think this is more reasonable than prohibiting change on Per-message Compression by intermediaries. > This also seems to put an endpoint in a position where it has no say on what an intermediary does with the traffic on the other side of it. Is that worth discussing in the document? > > Ah, right. Maybe some text like: "It's not guaranteed that the PMCE which an endpoint has negotiated in the opening handshake is preserved in the whole path to the peer endpoint." > > It would be good to point to, or provide, a discussion of how the extension negotiation mechanism in WebSockets is meant to be protected. > > As a general discussion to cover other extensions (if they want. by referring to this to-be-RFC) like the section defining terms to complement RFC6455 [1]? [1] https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-24#section-3 --001a113cee2ae8c9670519b831b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Than= k you for review, Robert.

On Thu, Jun 25, 2015 at 6:18 AM, Robert Sparks <rjs= parks@nostrum.com> wrote:
=20 =20 =20
=20 
I have reviewed this document as part of the security directorate&=
#39;s=20
ongoing effort to review all IETF documents being processed by the=20
IESG.  These comments were written primarily for the benefit of the=20
security area directors.  Document editors and WG chairs should treat=20
these comments just like any other last call comments.

Summary: Ready with issues

(fwiw, I also reviewed up through version -24).

Section 7 (Intermediaries) should be more explicit that it's talking ab=
out an intermediary doing compression on one side and not (or doing differe=
nt compression) on the other.
(If that's not what it's trying to set up, please clarify).
OK. So, I'd like to change the text as fo= llows:

When an intermediary proxies ... Per-m= essage Compression of messages received from one peer, and then forward the= messages to the other peer, if the intermediary ...
=C2=A0= 
I=
t's not clear from reading RFC6455 that the idea of intermediaries chan=
ging the contents of the websocket extension negotiation mechanism was cons=
idered - have I missed the text in that RFC that discusses that?
Are there other extensions that suggest similar behavior? It's not imme=
diately clear that the protocol mechanics do the right thing when the diffe=
rent negotiations on each side of the proxy fail differently.
It's not well discussed in RFC6455. Right= . AFAIK, there's no such extension defined, yet.

I understand that this text (intermediary section in the I-D) works just= not to disallow change of compression but there's nothing in RFC6455 t= hat guarantees that such transformation doesn't cause any issue with ot= her infrastructure of the WebSocket protocol.

I be= lieve that unless any extension that interferes with the other negotiated e= xtensions (e.g. counting the number of negotiated extensions, relying on PM= CE, etc.), the core WebSocket protocol (things defined in RFC6455) should w= ork. If such an extension is introduced, it would be just considered to be = incompatible with PMCEs, or that extension should describe how to coordinat= e with change on PMCE in the intermediaries section of its RFC.
<= br>
I think this is more reasonable than prohibiting change on Pe= r-message Compression by intermediaries.
This also seems to put an endpoint in a =
position where it has no say on what an intermediary does with the traffic =
on the other side of it. Is that worth discussing in the document?
Ah, right. Maybe some text like:

<= div>"It's not guaranteed that the PMCE which an endpoint has negot= iated in the opening handshake is preserved in the whole path to the peer e= ndpoint."
=C2=A0
It would be good to point to, or provide, a discussion of how the extension=
 negotiation mechanism in WebSockets is meant to be protected.
<= /blockquote>

As a general discussion to cover other exte= nsions (if they want. by referring to this to-be-RFC) like the section defi= ning terms to complement RFC6455 [1]?

=C2=A0
--001a113cee2ae8c9670519b831b7-- From nobody Tue Jun 30 06:44:10 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C02D1B29FC for ; Tue, 30 Jun 2015 06:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 a0eleZZyV0f5 for ; Tue, 30 Jun 2015 06:44:07 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (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 F13011B29EB for ; Tue, 30 Jun 2015 06:44:06 -0700 (PDT) Received: by widjy10 with SMTP id jy10so30842294wid.1 for ; Tue, 30 Jun 2015 06:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Ek6uqZ67IGTRLH/6UsfC6peMD1syvrDMVycEhtoEWYY=; b=kCYOCS/SNG2BYi4Rn75F5MMBJmrtFbTARJGWQ0MIKpOP2GehIJ0FRPsVtib4Pg66Ea zT1h0RCtXHHKDsW4weABed6FW87uqCrBKf5SRXrKC1vSjOKzUS9EYWaX3z4YxXgxb+oK CgQMlo5UhWdrJTqTMmC9gCwhirkEALAQqraLb/2fIHKE51cMkXBEHWDZpHScU9OX9T4u Jsv+J2xeichThmu0nlJw29VYNej6ZM0SFqO+xOveKRljUyE69sfBZPEAYqKhl2cBEgov CgXaSGm4c5ZZB37L5lDBI2xyrteHeaSvb5B2PCtSejqVYk2uiyQ7jy4A1gCGZb3rdIHk JNSQ== MIME-Version: 1.0 X-Received: by 10.180.86.73 with SMTP id n9mr32896741wiz.78.1435671800726; Tue, 30 Jun 2015 06:43:20 -0700 (PDT) Received: by 10.28.31.194 with HTTP; Tue, 30 Jun 2015 06:43:20 -0700 (PDT) Date: Tue, 30 Jun 2015 09:43:20 -0400 Message-ID: From: Kathleen Moriarty To: "secdir@ietf.org" Content-Type: multipart/alternative; boundary=f46d0442806eb24f060519bc6381 Archived-At: Subject: [secdir] SecDir Lunch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 13:44:09 -0000 --f46d0442806eb24f060519bc6381 Content-Type: text/plain; charset=UTF-8 Hello, The SecDir lunch scheduled in the Tyrolka room on Tuesday, July 21 from 1130 - 1300. Please grab lunch and join us in the room. We usually start by 12. Thanks for all your assistance reviewing drafts! -- Best regards, Kathleen & Stephen --f46d0442806eb24f060519bc6381 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

The SecDir=C2=A0lunch scheduled in the Tyrolka room on=C2=A0Tuesday, July 21=C2=A0from
1130 - 1300.=C2=A0 Please grab lunch an= d join us in the room.=C2=A0 We usually start by 12.

Thanks for all your assistance reviewing = drafts!

--

Best regards,
Kathleen & = Stephen
--f46d0442806eb24f060519bc6381-- From nobody Tue Jun 30 18:29:30 2015 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EAE1A0275; Tue, 30 Jun 2015 18:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqxcXhctxHYS; Tue, 30 Jun 2015 18:29:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22E111A026F; Tue, 30 Jun 2015 18:29:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUO34773; Wed, 01 Jul 2015 01:29:23 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 1 Jul 2015 02:29:22 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.143]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Wed, 1 Jul 2015 09:29:19 +0800 From: "Xialiang (Frank)" To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-bmwg-issu-meth.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-bmwg-issu-meth-01 Thread-Index: AdCznVhNjRYm7y6ZS9SgpDHakbeZ2Q== Date: Wed, 1 Jul 2015 01:29:18 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.43.91] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12ADE7046SZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [secdir] Secdir review of draft-ietf-bmwg-issu-meth-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 01:29:27 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12ADE7046SZXEMA502MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comment. This draft specifies a set of common methodologies and procedures designed = to characterize the overall behavior of a Device Under Test (DUT), subject = to an ISSU event. I have the following comments: 1. Should the ISSU test methodology include the verification and test= when the DUT is under network DDoS attacks? 2. In the software download stage, in addition to compatibility check= s and verification of checksums, we should also explicitly mention that the= device should verify the authenticity and integrity of its download. I.e. = verify signatures on signed code and OCSP/CRL for the used signature. And t= hat a system must not load unverified code; 3. even in a test environment all deployed software components must b= e verified (e.g. using signatures); 4. Nits: this draft has expired on May-30, 2015 Recommendation: Ready With Issues B.R. Frank --_000_C02846B1344F344EB4FAA6FA7AF481F12ADE7046SZXEMA502MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have reviewed this document a= s part of the security directorate's ongoing effort to review all IETF= documents being processed by the IESG.  These comments were writ= ten primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these co= mments just like any other last call comment.

 

This draft specifies a set of c= ommon methodologies and procedures designed to characterize the overall beh= avior of a Device Under Test (DUT), subject to an ISSU event.

 

I have the following comments:<= o:p>

1= .   &= nbsp;   Should the ISSU test me= thodology include the verification and test when the DUT is under network D= DoS attacks?

2= .   &= nbsp;   In the software downloa= d stage, in addition to compatibility checks and verification of checksums,= we should also explicitly mention that the device should verify the authen= ticity and integrity of its download. I.e. verify signatures on signed code and OCSP/CRL for the used signature.= And that a system must not load unverified code;

3= .   &= nbsp;   even in a test environm= ent all deployed software components must be verified (e.g. using signature= s);

4= .   &= nbsp;   Nits: this draft has ex= pired on May-30, 2015

 

Recommendation:  Ready Wit= h Issues

 

B.R.

Frank

--_000_C02846B1344F344EB4FAA6FA7AF481F12ADE7046SZXEMA502MBSchi_--