From nobody Sun Nov 3 14:20:11 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6199A120024 for ; Sun, 3 Nov 2019 14:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PKHid7LxD6w for ; Sun, 3 Nov 2019 14:20:07 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 C15F91200F7 for ; Sun, 3 Nov 2019 14:20:06 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id j5so10772714lfh.10 for ; Sun, 03 Nov 2019 14:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=b1nnSiX3hvcWN27Y4h7oHoMR73kJmhsoIxIUubEOJBo=; b=lD6qaQALuCly/zJSfzhwum61glBzdD/xHZJBh3SHQLZHEy437EyW0mc0qkFMwUfDP5 nr++GlADS1zr8F2SALGxceXe56+a3nb0NwasnFI7mi9aOCdZr1w/NAX7UxCPypMH+vej rq5WZo5C/HL5v/N3KxF7FzUAzlfJytfagNfVA8Nqp1ez6LAcrB5Aqh6WLbHw8vs85Xxd Z992U04fgXb4D2MMjG6pdtEu4HQ+7sx/Bp4+c92oThgc+8I51Co0MPdJpOMfTxpwAaoF E7NiODpEgF393MteZpU+Nz23CjgYu26jTNeBsapLHrq02zmkpBTsa9dxfLugRsEK/x9w Tmag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=b1nnSiX3hvcWN27Y4h7oHoMR73kJmhsoIxIUubEOJBo=; b=qswm7SGOBfXQPcrkQNUeqU6SxwJYncXUWlmfKQoVdCKNXLprxqNa8mGdru/CN/J7H8 dDMMzuOfvOh/1hINsDsC1MxAvZW+CRCw9lHJIN9iVLXJCrm7+tmmvQFQMs6TZDmr012H VJF2u9I0t/8H39AsiW1RPcaanGeQ3nv9wEJ5XIkXShuvxLSWpPdmmgIkiV2XTIDJ3pGX SuETQFwQSS155pO/BEZ+ta8ZuwAp32EdnYGvny60IWKIIcXCdJtaa/7XZz5I9wDJU7PM OYpHTNLc7cRxt87tJY3ALH1XtpWEubR6xm7iaSyzA0Rt4nh305BvIMEvltwGJv9RmJlh ZxZw== X-Gm-Message-State: APjAAAV1++Qx8oTsjPP97er4ORs/MhP7XDhmqDfTODNmUtV4Su2CV3A4 DbT2qO2lJFS6YtGsuoVPiEE1pX3jQqydGV5o9u0/gw== X-Google-Smtp-Source: APXvYqyqoJIWFa3ppbHpjsgtQgcYeomm2/iJ2YqmC3ZHgnLOpuabnnsav1Xjtkg7PWJLdczCFO3U09GrPTXVpjC7fc8= X-Received: by 2002:a19:c6d6:: with SMTP id w205mr13311657lff.17.1572819604911; Sun, 03 Nov 2019 14:20:04 -0800 (PST) MIME-Version: 1.0 From: Eric Rescorla Date: Sun, 3 Nov 2019 14:19:28 -0800 Message-ID: To: tsvwg IETF list , saag@ietf.org Content-Type: multipart/alternative; boundary="000000000000d8c9ae0596789900" Archived-At: Subject: [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2019 22:20:10 -0000 --000000000000d8c9ae0596789900 Content-Type: text/plain; charset="UTF-8" After reviewing this document, I share Christian Huitema's concern about the tone and perspective of this document, which, while saying that encryption is good, then proceeds to mostly lament how difficult it makes life for various entities other than the endpoints. It seems to me rather problematic to publish this document as an RFC for several reasons: - Yes, it's true that the trend towards encrypting everything has and continues to make a number of entities sad, but that's a point which is already made in RFC 8404. How does all of the additional detail here help? - The community of people designing new transport protocols has already weighed all the considerations here and come down pretty decisively on the side of "encrypt all the things". Given that both SCTP-over-DTLS and QUIC do this, it seems pretty unlikely we're going to design a new transport protocol that doesn't. - Having an IETF Consensus RFC that is so heavily weighted on the side of "this is how encryption inconveniences us" and so light on "these are the attacks we are preventing" gives a misleading picture of the IETF community's view of the relative priority of these concerns. ISTM that RFC 8558 -- though perhaps imperfect -- far more closely reflects that consensus. In short, I do not think this draft should be published as an RFC. I have appended a number of detailed comments which IMO need to be addressed in any case, but even if they were resolved, that would not address my primary concern. COMMENTS S 2.1. > 2.1. Use of Transport Header Information in the Network > > In-network measurement of transport flow characteristics can be used > to enhance performance, and control cost and service reliability. > Some operators have deployed functionality in middleboxes to both > support network operations and enhance performance. This reliance on This seems like a contested point. My understanding is that while these middleboxes are *intended* to enhance performance that there is doubt that they actually do. S 2.1. > to enhance performance, and control cost and service reliability. > Some operators have deployed functionality in middleboxes to both > support network operations and enhance performance. This reliance on > the presence and semantics of specific header information leads to > ossification, where an endpoint could be required to supply a > specific header to receive the network service that it desires. In Well, not just the network service it desires but *any* service. S 2.1. > specific header to receive the network service that it desires. In > some cases, this could be benign or advantageous to the protocol > (e.g., recognising the start of a connection, or explicitly exposing > protocol information can be expected to provide more consistent > decisions by on-path devices than the use of diverse methods to infer > semantics from other flow properties). In other cases, the Is there evidence of this? S 2.1. > > As an example of ossification, consider the experience of developing > Transport Layer Security (TLS) 1.3 [RFC8446]. This required a design > that recognised that deployed middleboxes relied on the presence of > certain header filed exposed in TLS 1.2, and failed if those headers > were changed. Other examples of the impact of ossification can be I think you mean "fields" and it wasn't headers so much as handshake data. S 2.2. > This supports use of this information by on-path devices, but at the > same time can be expected to lead to ossification of the transport > header, because network forwarding could evolve to depend on the > presence and/or value of these fields. To avoid unwanted inspection, > a protocol could intentionally vary the format or value of exposed > header fields [I-D.ietf-tls-grease]. It's not just a matter of unwanted inspection. There's a real question about whether we want these on-path devices to have this information at all, as it is potentially used for surveillance, traffic analysis, etc. S 2.2. > > While encryption can hide transport header information, it does not > prevent ossification of the network service. People seeking to > understand network traffic could come to rely on pattern inferences > and other heuristics as the basis for network decision and to derive > measurement data. This can create new dependencies on the transport This also seems quite contested. Do you have any evidence of such a thing happening? S 2.3. > anomalies, and failure pathologies at any point along the Internet > path. In many cases, it is important to relate observations to > specific equipment/configurations or network segments. > > Concealing transport header information makes performance/ > behaviour unavailable to passive observers along the path, While also making traffic analysis more difficult. S 2.3. > applications it is important to relate observations to specific > equipment/configurations or particular network segments. > > Concealing transport header information can make analysis harder > or impossible. This could impact the ability for an operator to > anticipate the need for network upgrades and roll-out. It can Or to reduce the opportunities for traffic discrimination. S 2.3. > > Different parties will view the relative importance of these issues > differently. For some, the benefits of encrypting some, or all, of > the transport headers may outweigh the impact of doing so; others > might make a different trade-off. The purpose of highlighting the > trade-offs is to make such analysis possible. This whole section seems to really just ignore the fact that many of these practices are unwanted. S 3.1. > Firewalls). Common issues concerning IP address sharing are > described in [RFC6269]. > > 3.1. Observing Transport Information in the Network > > If in-network observation of transport protocol headers is needed, Why is this needed? I know some people might want it. S 3.1.1. > 3.1.1. Flow Identification Using Transport Layer Headers > > Flow identification is a common function. For example, performed by > measurement activities, QoS classification, firewalls, Denial of > Service, DOS, prevention. This becomes more complex and less easily > achieved when multiplexing is used at or above the transport layer. Also traffic discrimination and blocking. S 3.1.1. > use heuristics to infer that short UDP packets with regular spacing > carry audio traffic. Operational practices aimed at inferring > transport parameters are out of scope for this document, and are only > mentioned here to recognize that encryption does not prevent > operators from attempting to apply practices that were used with > unencrypted transport headers. This has a really threatening tone. If you don't give us what we want, look what could happen. S 3.1.2. > > This information can support network operations, inform capacity > planning, and assist in determining the need for equipment and/or > configuration changes by network operators. It can also inform > Internet engineering activities by informing the development of new > protocols, methodologies, and procedures. What is the point of this exhaustive list? S 3.1.3. > > AQM and ECN offer a range of algorithms and configuration options. > Tools therefore need to be available to network operators and > researchers to understand the implication of configuration choices > and transport behaviour as the use of ECN increases and new > methods emerge [RFC7567]. QUIC sort of hides ECN feedback but not ECN marking. S 3.2.4. > > A network operator needs tools to understand if datagram flows > (e.g., using UDP) comply with congestion control expectations and > therefore whether there is a need to deploy methods such as rate- > limiters, transport circuit breakers, or other methods to enforce > acceptable usage for the offered service. Does it *need* it or does it just want it. Note that we have had DTLS- SCTP with WebRTC without this property for some time now. Can you provide some evidence that operators have been inconvenienced by not having it. S 3.3. > operators bring together heterogeneous types of network equipment and > seek to deploy opportunistic methods to access radio spectrum. > > A flow that conceals its transport header information could imply > "don't touch" to some operators. This could limit a trouble-shooting > response to "can't help, no trouble found". We have quite a bit of QUIC traffic now. I'd be interested in hearing from the gQUIC team whether they have seen anything like this. S 4. > > There are several motivations for encryption: > > o One motive to use encryption is a response to perceptions that the > network has become ossified by over-reliance on middleboxes that > prevent new protocols and mechanisms from being deployed. This This isn't just a perception, it's a demonstrable reality. S 4. > > o One motive to use encryption is a response to perceptions that the > network has become ossified by over-reliance on middleboxes that > prevent new protocols and mechanisms from being deployed. This > has lead to a perception that there is too much "manipulation" of > protocol headers within the network, and that designing to deploy Not just manipulation, also inspection. S 4. > > One example of encryption at the network layer is the use of IPsec > Encapsulating Security Payload (ESP) [RFC4303] in tunnel mode. > This encrypts and authenticates all transport headers, preventing > visibility of the transport headers by in-network devices. Some > VPN methods also encrypt these headers. This seems like a bad example as part of the point of a VPN is to conceal the headers form the network. S 6.1. > > 6.1. Independent Measurement > > Independent observation by multiple actors is important if the > transport community is to maintain an accurate understanding of the > network. Encrypting transport header encryption changes the ability This is ironic because QUIC is much better for endpoint measurement than TCP because the details are accessible at the application layer. S 8. > example, an attacker could construct a DOS attack by sending packets > with a sequence number that falls within the currently accepted range > of sequence numbers at the receiving endpoint, this would then > introduce additional work at the receiving endpoint, even though the > data in the attacking packet may not finally be delivered by the > transport layer. This is sometimes known as a "shadowing attack". This doesn't seem to be an issue with protocols that authenticate the SN. S 8. > > An attack can, for example, disrupt receiver processing, trigger loss > and retransmission, or make a receiving endpoint perform unproductive > decryption of packets that cannot be successfully decrypted (forcing > a receiver to commit decryption resources, or to update and then > restore protocol state). This is not a real issue for QUIC or similar protocols --000000000000d8c9ae0596789900 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
After reviewing this document, I share Christian Huitema&#= 39;s concern
about the tone and perspective of this document, which, whi= le saying
that encryption is good, then proceeds to mostly lament how di= fficult
it makes life for various entities other than the endpoints. It = seems
to me rather problematic to publish this document as an RFC forseveral reasons:

- Yes, it's true that the trend towards encryp= ting everything has
=C2=A0 and continues to make a number of entities sa= d, but that's a point
=C2=A0 which is already made in RFC 8404. How = does all of the additional
=C2=A0 detail here help?

- The communi= ty of people designing new transport protocols has
=C2=A0 already weighe= d all the considerations here and come down pretty
=C2=A0 decisively on = the side of "encrypt all the things". Given that
=C2=A0 both S= CTP-over-DTLS and QUIC do this, it seems pretty unlikely
=C2=A0 we'r= e going to design a new transport protocol that doesn't.

- Havin= g an IETF Consensus RFC that is so heavily weighted on the side
=C2=A0 o= f "this is how encryption inconveniences us" and so light on &quo= t;these
=C2=A0 are the attacks we are preventing" gives a misleadin= g picture of the
=C2=A0 IETF community's view of the relative priori= ty of these
=C2=A0 concerns. ISTM that RFC 8558 -- though perhaps imperf= ect -- far more
=C2=A0 closely reflects that consensus.

In short,= I do not think this draft should be published as an RFC.

I have app= ended a number of detailed comments which IMO need to be
addressed in an= y case, but even if they were resolved, that would not
address my primar= y concern.


COMMENTS
S 2.1.
> =C2=A0 2.1.=C2=A0 Use of T= ransport Header Information in the Network
> =C2=A0
> =C2=A0 = =C2=A0 =C2=A0In-network measurement of transport flow characteristics can b= e used
> =C2=A0 =C2=A0 =C2=A0to enhance performance, and control cost= and service reliability.
> =C2=A0 =C2=A0 =C2=A0Some operators have d= eployed functionality in middleboxes to both
> =C2=A0 =C2=A0 =C2=A0su= pport network operations and enhance performance.=C2=A0 This reliance on
This seems like a contested point. My understanding is that while
t= hese middleboxes are *intended* to enhance performance that there is
dou= bt that they actually do.


S 2.1.
> =C2=A0 =C2=A0 =C2=A0to = enhance performance, and control cost and service reliability.
> =C2= =A0 =C2=A0 =C2=A0Some operators have deployed functionality in middleboxes = to both
> =C2=A0 =C2=A0 =C2=A0support network operations and enhance = performance.=C2=A0 This reliance on
> =C2=A0 =C2=A0 =C2=A0the presenc= e and semantics of specific header information leads to
> =C2=A0 =C2= =A0 =C2=A0ossification, where an endpoint could be required to supply a
= > =C2=A0 =C2=A0 =C2=A0specific header to receive the network service tha= t it desires.=C2=A0 In

Well, not just the network service it desires= but *any* service.


S 2.1.
> =C2=A0 =C2=A0 =C2=A0specific = header to receive the network service that it desires.=C2=A0 In
> =C2= =A0 =C2=A0 =C2=A0some cases, this could be benign or advantageous to the pr= otocol
> =C2=A0 =C2=A0 =C2=A0(e.g., recognising the start of a connec= tion, or explicitly exposing
> =C2=A0 =C2=A0 =C2=A0protocol informati= on can be expected to provide more consistent
> =C2=A0 =C2=A0 =C2=A0d= ecisions by on-path devices than the use of diverse methods to infer
>= ; =C2=A0 =C2=A0 =C2=A0semantics from other flow properties).=C2=A0 In other= cases, the

Is there evidence of this?


S 2.1.
> =C2= =A0
> =C2=A0 =C2=A0 =C2=A0As an example of ossification, consider th= e experience of developing
> =C2=A0 =C2=A0 =C2=A0Transport Layer Secu= rity (TLS) 1.3 [RFC8446].=C2=A0 This required a design
> =C2=A0 =C2= =A0 =C2=A0that recognised that deployed middleboxes relied on the presence = of
> =C2=A0 =C2=A0 =C2=A0certain header filed exposed in TLS 1.2, and= failed if those headers
> =C2=A0 =C2=A0 =C2=A0were changed.=C2=A0 Ot= her examples of the impact of ossification can be

I think you mean &= quot;fields" and it wasn't headers so much as handshake
data.

S 2.2.
> =C2=A0 =C2=A0 =C2=A0This supports use of this info= rmation by on-path devices, but at the
> =C2=A0 =C2=A0 =C2=A0same tim= e can be expected to lead to ossification of the transport
> =C2=A0 = =C2=A0 =C2=A0header, because network forwarding could evolve to depend on t= he
> =C2=A0 =C2=A0 =C2=A0presence and/or value of these fields.=C2=A0= To avoid unwanted inspection,
> =C2=A0 =C2=A0 =C2=A0a protocol could= intentionally vary the format or value of exposed
> =C2=A0 =C2=A0 = =C2=A0header fields [I-D.ietf-tls-grease].

It's not just a matte= r of unwanted inspection. There's a real question
about whether we w= ant these on-path devices to have this information
at all, as it is pote= ntially used for surveillance, traffic
analysis, etc.



S 2= .2.
> =C2=A0
> =C2=A0 =C2=A0 =C2=A0While encryption can hide t= ransport header information, it does not
> =C2=A0 =C2=A0 =C2=A0preven= t ossification of the network service.=C2=A0 People seeking to
> =C2= =A0 =C2=A0 =C2=A0understand network traffic could come to rely on pattern i= nferences
> =C2=A0 =C2=A0 =C2=A0and other heuristics as the basis for= network decision and to derive
> =C2=A0 =C2=A0 =C2=A0measurement dat= a.=C2=A0 This can create new dependencies on the transport

This also= seems quite contested. Do you have any evidence of such a
thing happeni= ng?


S 2.3.
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 anomalies, and f= ailure pathologies at any point along the Internet
> =C2=A0 =C2=A0 = =C2=A0 =C2=A0 path.=C2=A0 In many cases, it is important to relate observat= ions to
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 specific equipment/configuratio= ns or network segments.
> =C2=A0
> =C2=A0 =C2=A0 =C2=A0 =C2=A0= Concealing transport header information makes performance/
> =C2=A0 = =C2=A0 =C2=A0 =C2=A0 behaviour unavailable to passive observers along the p= ath,

While also making traffic analysis more difficult.


S= 2.3.
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 applications it is important to r= elate observations to specific
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 equipmen= t/configurations or particular network segments.
> =C2=A0
> = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Concealing transport header information can mak= e analysis harder
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 or impossible.=C2=A0 = This could impact the ability for an operator to
> =C2=A0 =C2=A0 =C2= =A0 =C2=A0 anticipate the need for network upgrades and roll-out.=C2=A0 It = can

Or to reduce the opportunities for traffic discrimination.

S 2.3.
> =C2=A0
> =C2=A0 =C2=A0 =C2=A0Different parties = will view the relative importance of these issues
> =C2=A0 =C2=A0 =C2= =A0differently.=C2=A0 For some, the benefits of encrypting some, or all, of=
> =C2=A0 =C2=A0 =C2=A0the transport headers may outweigh the impact = of doing so; others
> =C2=A0 =C2=A0 =C2=A0might make a different trad= e-off.=C2=A0 The purpose of highlighting the
> =C2=A0 =C2=A0 =C2=A0tr= ade-offs is to make such analysis possible.

This whole section seems= to really just ignore the fact that many of
these practices are unwante= d.


S 3.1.
> =C2=A0 =C2=A0 =C2=A0Firewalls).=C2=A0 Common i= ssues concerning IP address sharing are
> =C2=A0 =C2=A0 =C2=A0describ= ed in [RFC6269].
> =C2=A0
> =C2=A0 3.1.=C2=A0 Observing Transp= ort Information in the Network
> =C2=A0
> =C2=A0 =C2=A0 =C2=A0= If in-network observation of transport protocol headers is needed,

W= hy is this needed? I know some people might want it.


S 3.1.1.> =C2=A0 3.1.1.=C2=A0 Flow Identification Using Transport Layer Headers=
> =C2=A0
> =C2=A0 =C2=A0 =C2=A0Flow identification is a commo= n function.=C2=A0 For example, performed by
> =C2=A0 =C2=A0 =C2=A0mea= surement activities, QoS classification, firewalls, Denial of
> =C2= =A0 =C2=A0 =C2=A0Service, DOS, prevention.=C2=A0 This becomes more complex = and less easily
> =C2=A0 =C2=A0 =C2=A0achieved when multiplexing is u= sed at or above the transport layer.

Also traffic discrimination and= blocking.


S 3.1.1.
> =C2=A0 =C2=A0 =C2=A0use heuristics t= o infer that short UDP packets with regular spacing
> =C2=A0 =C2=A0 = =C2=A0carry audio traffic.=C2=A0 Operational practices aimed at inferring> =C2=A0 =C2=A0 =C2=A0transport parameters are out of scope for this d= ocument, and are only
> =C2=A0 =C2=A0 =C2=A0mentioned here to recogni= ze that encryption does not prevent
> =C2=A0 =C2=A0 =C2=A0operators f= rom attempting to apply practices that were used with
> =C2=A0 =C2=A0= =C2=A0unencrypted transport headers.

This has a really threatening = tone. If you don't give us what we want,
look what could happen.
=

S 3.1.2.
> =C2=A0
> =C2=A0 =C2=A0 =C2=A0This informati= on can support network operations, inform capacity
> =C2=A0 =C2=A0 = =C2=A0planning, and assist in determining the need for equipment and/or
= > =C2=A0 =C2=A0 =C2=A0configuration changes by network operators.=C2=A0 = It can also inform
> =C2=A0 =C2=A0 =C2=A0Internet engineering activit= ies by informing the development of new
> =C2=A0 =C2=A0 =C2=A0protoco= ls, methodologies, and procedures.

What is the point of this exhaust= ive list?


S 3.1.3.
> =C2=A0
> =C2=A0 =C2=A0 =C2=A0 = =C2=A0 AQM and ECN offer a range of algorithms and configuration options.> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Tools therefore need to be available to = network operators and
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 researchers to un= derstand the implication of configuration choices
> =C2=A0 =C2=A0 =C2= =A0 =C2=A0 and transport behaviour as the use of ECN increases and new
&= gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 methods emerge [RFC7567].

QUIC sort = of hides ECN feedback but not ECN marking.


S 3.2.4.
> =C2= =A0
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 A network operator needs tools to = understand if datagram flows
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (e.g., usi= ng UDP) comply with congestion control expectations and
> =C2=A0 =C2= =A0 =C2=A0 =C2=A0 therefore whether there is a need to deploy methods such = as rate-
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 limiters, transport circuit br= eakers, or other methods to enforce
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 acc= eptable usage for the offered service.

Does it *need* it or does it = just want it. Note that we have had DTLS-
SCTP with WebRTC without this = property for some time now. Can you provide
some evidence that operators= have been inconvenienced by not having it.


S 3.3.
> =C2= =A0 =C2=A0 =C2=A0operators bring together heterogeneous types of network eq= uipment and
> =C2=A0 =C2=A0 =C2=A0seek to deploy opportunistic method= s to access radio spectrum.
> =C2=A0
> =C2=A0 =C2=A0 =C2=A0A f= low that conceals its transport header information could imply
> =C2= =A0 =C2=A0 =C2=A0"don't touch" to some operators.=C2=A0 This = could limit a trouble-shooting
> =C2=A0 =C2=A0 =C2=A0response to &quo= t;can't help, no trouble found".

We have quite a bit of QUI= C traffic now. I'd be interested in hearing
from the gQUIC team whet= her they have seen anything like this.


S 4.
> =C2=A0
&= gt; =C2=A0 =C2=A0 =C2=A0There are several motivations for encryption:
&g= t; =C2=A0
> =C2=A0 =C2=A0 =C2=A0o =C2=A0One motive to use encryption= is a response to perceptions that the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 = network has become ossified by over-reliance on middleboxes that
> = =C2=A0 =C2=A0 =C2=A0 =C2=A0 prevent new protocols and mechanisms from being= deployed.=C2=A0 This

This isn't just a perception, it's a d= emonstrable reality.


S 4.
> =C2=A0
> =C2=A0 =C2=A0 = =C2=A0o =C2=A0One motive to use encryption is a response to perceptions tha= t the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 network has become ossified by ov= er-reliance on middleboxes that
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 prevent= new protocols and mechanisms from being deployed.=C2=A0 This
> =C2= =A0 =C2=A0 =C2=A0 =C2=A0 has lead to a perception that there is too much &q= uot;manipulation" of
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 protocol head= ers within the network, and that designing to deploy

Not just manipu= lation, also inspection.


S 4.
> =C2=A0
> =C2=A0 =C2= =A0 =C2=A0 =C2=A0 One example of encryption at the network layer is the use= of IPsec
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Encapsulating Security Payloa= d (ESP) [RFC4303] in tunnel mode.
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 This = encrypts and authenticates all transport headers, preventing
> =C2=A0= =C2=A0 =C2=A0 =C2=A0 visibility of the transport headers by in-network dev= ices.=C2=A0 Some
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 VPN methods also encry= pt these headers.

This seems like a bad example as part of the point= of a VPN is to
conceal the headers form the network.


S 6.1.<= br>> =C2=A0
> =C2=A0 6.1.=C2=A0 Independent Measurement
> = =C2=A0
> =C2=A0 =C2=A0 =C2=A0Independent observation by multiple act= ors is important if the
> =C2=A0 =C2=A0 =C2=A0transport community is = to maintain an accurate understanding of the
> =C2=A0 =C2=A0 =C2=A0ne= twork.=C2=A0 Encrypting transport header encryption changes the ability
=
This is ironic because QUIC is much better for endpoint measurement
= than TCP because the details are accessible at the application layer.

S 8.
> =C2=A0 =C2=A0 =C2=A0example, an attacker could construct= a DOS attack by sending packets
> =C2=A0 =C2=A0 =C2=A0with a sequenc= e number that falls within the currently accepted range
> =C2=A0 =C2= =A0 =C2=A0of sequence numbers at the receiving endpoint, this would then> =C2=A0 =C2=A0 =C2=A0introduce additional work at the receiving endpoi= nt, even though the
> =C2=A0 =C2=A0 =C2=A0data in the attacking packe= t may not finally be delivered by the
> =C2=A0 =C2=A0 =C2=A0transport= layer.=C2=A0 This is sometimes known as a "shadowing attack".
This doesn't seem to be an issue with protocols that authenticate = the SN.


S 8.
> =C2=A0
> =C2=A0 =C2=A0 =C2=A0An atta= ck can, for example, disrupt receiver processing, trigger loss
> =C2= =A0 =C2=A0 =C2=A0and retransmission, or make a receiving endpoint perform u= nproductive
> =C2=A0 =C2=A0 =C2=A0decryption of packets that cannot b= e successfully decrypted (forcing
> =C2=A0 =C2=A0 =C2=A0a receiver to= commit decryption resources, or to update and then
> =C2=A0 =C2=A0 = =C2=A0restore protocol state).

This is not a real issue for QUIC or = similar protocols















--000000000000d8c9ae0596789900-- From nobody Sun Nov 3 16:11:16 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6B212006E; Sun, 3 Nov 2019 16:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duwC6Q2tfkFT; Sun, 3 Nov 2019 16:11:10 -0800 (PST) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 8514812003E; Sun, 3 Nov 2019 16:11:10 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id j12so4886955plt.9; Sun, 03 Nov 2019 16:11:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=DAJrgJj97UAuRy0BrXrbkUCMHEv2vEM2ESMy+thaoHM=; b=ZYVb2GY9EpvJN4qMOacG7pTTNTSKC0qdlpOt39UHu1GjJMIpgzPbrYnh0nX3QBgerg HOBcZ7VskyLMEIbD4qMEpZmINwPvuGAVbliTxofxPUhjpfC0bxzgpwJPLtn2WMONZiDv nvZESXY1RU7ssWcwNXn43Yl1zjrJSePLS/MxkRCbYOR5Dp//pyWpoRxcRNbhf35v9QyD z/wJ2/DdHJ/LlPRrflSd3AU0PHrW6285oz4hr3ixqpm/zEO6Ym9xaDv5dYIQ0lyoG6Rr v7wX+ulrMyhiSWL0zMrVMZe0hAXfriti56zp2qUkfY5b6XXqKcKROWW7fo+a3PKWLY0w +REg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=DAJrgJj97UAuRy0BrXrbkUCMHEv2vEM2ESMy+thaoHM=; b=Kq2ysv/n5GXU3egpv52uCBfb4YBwCDN73C0Fz36Rf4vBnvg0w7U8GKSl1ZrU502lAZ YECbso0DFAdeFswTOOgNuDtxtApJS5VTPdR1jam6RyqLa+WO2BuNVAUQ0W095mVmDETB wxg7rEMsW75n18mAJoekLcoglLBovksSFGBhw5PoJn+DRqbfE89Gis1WP5sSadF70Qed u8dkcni9udeF583CaU6cqWtvEeoA5k6+TPNNd5GhIqrbTldI04Iz+Lwy/26QFjOmAMFX FALhs1WhvaX0evt11Q2uD3ijZRHGZ0q5HxGUfCnwPaN+PqciTqsgvYVTMf3apjdT3vVw FqcQ== X-Gm-Message-State: APjAAAVZJtlc7/mJddokZ5GppgysfOLjysCxmFZb9aJR4bAZ7J/FRuLC Uda+vObZEqyfli0JaD8OOut3Cbsx X-Google-Smtp-Source: APXvYqwJ4a2jemytZ+7js0zvwlypOqGqECkMYUE7Y/vvQ42yWt2bPWRDnCs39fDPkqBH28JybZQFvw== X-Received: by 2002:a17:902:8208:: with SMTP id x8mr14405016pln.6.1572826268406; Sun, 03 Nov 2019 16:11:08 -0800 (PST) Received: from [192.168.1.107] (c-98-225-39-241.hsd1.wa.comcast.net. [98.225.39.241]) by smtp.gmail.com with ESMTPSA id g7sm14046037pgr.52.2019.11.03.16.11.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 03 Nov 2019 16:11:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Mime-Version: 1.0 (1.0) Date: Sun, 3 Nov 2019 16:11:06 -0800 Message-Id: <6E8A313A-2A3B-45D1-813C-029F90BA624B@gmail.com> References: Cc: tsvwg IETF list , saag@ietf.org In-Reply-To: To: Eric Rescorla X-Mailer: iPhone Mail (17B84) Archived-At: Subject: Re: [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 00:11:14 -0000 This document appears to have a *lot* of overlap with RFC 8404. So given tha= t the basic point has already been made, it seems to me that this document n= eeds to focus on new points and/or practical recommendations to make its pub= lication worthwhile. The issues raised here are by no means new - they first arose with the intro= duction of IPsec. Endpoint monitoring makes it possible for endpoint owners t= o collect information on performance that they can choose to share with oper= ators.=20 Thus the issue here is not really the loss of transport performance informat= ion since that remains available if consent can be obtained, but rather the c= ollection of that information by unauthorized third parties. > On Nov 3, 2019, at 2:20 PM, Eric Rescorla wrote: >=20 > =EF=BB=BF > After reviewing this document, I share Christian Huitema's concern > about the tone and perspective of this document, which, while saying > that encryption is good, then proceeds to mostly lament how difficult > it makes life for various entities other than the endpoints. It seems > to me rather problematic to publish this document as an RFC for > several reasons: >=20 > - Yes, it's true that the trend towards encrypting everything has > and continues to make a number of entities sad, but that's a point > which is already made in RFC 8404. How does all of the additional > detail here help? >=20 > - The community of people designing new transport protocols has > already weighed all the considerations here and come down pretty > decisively on the side of "encrypt all the things". Given that > both SCTP-over-DTLS and QUIC do this, it seems pretty unlikely > we're going to design a new transport protocol that doesn't. >=20 > - Having an IETF Consensus RFC that is so heavily weighted on the side > of "this is how encryption inconveniences us" and so light on "these > are the attacks we are preventing" gives a misleading picture of the > IETF community's view of the relative priority of these > concerns. ISTM that RFC 8558 -- though perhaps imperfect -- far more > closely reflects that consensus. >=20 > In short, I do not think this draft should be published as an RFC. >=20 > I have appended a number of detailed comments which IMO need to be > addressed in any case, but even if they were resolved, that would not > address my primary concern. >=20 >=20 > COMMENTS > S 2.1. > > 2.1. Use of Transport Header Information in the Network > > =20 > > In-network measurement of transport flow characteristics can be use= d > > to enhance performance, and control cost and service reliability. > > Some operators have deployed functionality in middleboxes to both > > support network operations and enhance performance. This reliance o= n >=20 > This seems like a contested point. My understanding is that while > these middleboxes are *intended* to enhance performance that there is > doubt that they actually do. >=20 >=20 > S 2.1. > > to enhance performance, and control cost and service reliability. > > Some operators have deployed functionality in middleboxes to both > > support network operations and enhance performance. This reliance o= n > > the presence and semantics of specific header information leads to > > ossification, where an endpoint could be required to supply a > > specific header to receive the network service that it desires. In= >=20 > Well, not just the network service it desires but *any* service. >=20 >=20 > S 2.1. > > specific header to receive the network service that it desires. In= > > some cases, this could be benign or advantageous to the protocol > > (e.g., recognising the start of a connection, or explicitly exposin= g > > protocol information can be expected to provide more consistent > > decisions by on-path devices than the use of diverse methods to inf= er > > semantics from other flow properties). In other cases, the >=20 > Is there evidence of this? >=20 >=20 > S 2.1. > > =20 > > As an example of ossification, consider the experience of developin= g > > Transport Layer Security (TLS) 1.3 [RFC8446]. This required a desi= gn > > that recognised that deployed middleboxes relied on the presence of= > > certain header filed exposed in TLS 1.2, and failed if those header= s > > were changed. Other examples of the impact of ossification can be >=20 > I think you mean "fields" and it wasn't headers so much as handshake > data. >=20 >=20 > S 2.2. > > This supports use of this information by on-path devices, but at th= e > > same time can be expected to lead to ossification of the transport > > header, because network forwarding could evolve to depend on the > > presence and/or value of these fields. To avoid unwanted inspectio= n, > > a protocol could intentionally vary the format or value of exposed > > header fields [I-D.ietf-tls-grease]. >=20 > It's not just a matter of unwanted inspection. There's a real question > about whether we want these on-path devices to have this information > at all, as it is potentially used for surveillance, traffic > analysis, etc. >=20 >=20 >=20 > S 2..2. > > =20 > > While encryption can hide transport header information, it does not= > > prevent ossification of the network service. People seeking to > > understand network traffic could come to rely on pattern inferences= > > and other heuristics as the basis for network decision and to deriv= e > > measurement data. This can create new dependencies on the transpor= t >=20 > This also seems quite contested. Do you have any evidence of such a > thing happening?=20 >=20 >=20 > S 2.3. > > anomalies, and failure pathologies at any point along the Intern= et > > path. In many cases, it is important to relate observations to > > specific equipment/configurations or network segments. > > =20 > > Concealing transport header information makes performance/ > > behaviour unavailable to passive observers along the path, >=20 > While also making traffic analysis more difficult. >=20 >=20 > S 2.3. > > applications it is important to relate observations to specific > > equipment/configurations or particular network segments. > > =20 > > Concealing transport header information can make analysis harder= > > or impossible. This could impact the ability for an operator to= > > anticipate the need for network upgrades and roll-out. It can >=20 > Or to reduce the opportunities for traffic discrimination. >=20 >=20 > S 2.3. > > =20 > > Different parties will view the relative importance of these issues= > > differently. For some, the benefits of encrypting some, or all, of= > > the transport headers may outweigh the impact of doing so; others > > might make a different trade-off. The purpose of highlighting the > > trade-offs is to make such analysis possible. >=20 > This whole section seems to really just ignore the fact that many of > these practices are unwanted. >=20 >=20 > S 3.1. > > Firewalls). Common issues concerning IP address sharing are > > described in [RFC6269]. > > =20 > > 3.1. Observing Transport Information in the Network > > =20 > > If in-network observation of transport protocol headers is needed, >=20 > Why is this needed? I know some people might want it. >=20 >=20 > S 3.1.1. > > 3.1.1. Flow Identification Using Transport Layer Headers > > =20 > > Flow identification is a common function. For example, performed b= y > > measurement activities, QoS classification, firewalls, Denial of > > Service, DOS, prevention. This becomes more complex and less easil= y > > achieved when multiplexing is used at or above the transport layer.= >=20 > Also traffic discrimination and blocking. >=20 >=20 > S 3.1.1. > > use heuristics to infer that short UDP packets with regular spacing= > > carry audio traffic. Operational practices aimed at inferring > > transport parameters are out of scope for this document, and are on= ly > > mentioned here to recognize that encryption does not prevent > > operators from attempting to apply practices that were used with > > unencrypted transport headers. >=20 > This has a really threatening tone. If you don't give us what we want, > look what could happen. >=20 >=20 > S 3.1.2. > > =20 > > This information can support network operations, inform capacity > > planning, and assist in determining the need for equipment and/or > > configuration changes by network operators. It can also inform > > Internet engineering activities by informing the development of new= > > protocols, methodologies, and procedures. >=20 > What is the point of this exhaustive list? >=20 >=20 > S 3.1.3. > > =20 > > AQM and ECN offer a range of algorithms and configuration option= s. > > Tools therefore need to be available to network operators and > > researchers to understand the implication of configuration choic= es > > and transport behaviour as the use of ECN increases and new > > methods emerge [RFC7567]. >=20 > QUIC sort of hides ECN feedback but not ECN marking. >=20 >=20 > S 3.2.4. > > =20 > > A network operator needs tools to understand if datagram flows > > (e.g., using UDP) comply with congestion control expectations an= d > > therefore whether there is a need to deploy methods such as rate= - > > limiters, transport circuit breakers, or other methods to enforc= e > > acceptable usage for the offered service. >=20 > Does it *need* it or does it just want it. Note that we have had DTLS- > SCTP with WebRTC without this property for some time now. Can you provide > some evidence that operators have been inconvenienced by not having it. >=20 >=20 > S 3.3. > > operators bring together heterogeneous types of network equipment a= nd > > seek to deploy opportunistic methods to access radio spectrum. > > =20 > > A flow that conceals its transport header information could imply > > "don't touch" to some operators. This could limit a trouble-shooti= ng > > response to "can't help, no trouble found". >=20 > We have quite a bit of QUIC traffic now. I'd be interested in hearing > from the gQUIC team whether they have seen anything like this. >=20 >=20 > S 4. > > =20 > > There are several motivations for encryption: > > =20 > > o One motive to use encryption is a response to perceptions that t= he > > network has become ossified by over-reliance on middleboxes that= > > prevent new protocols and mechanisms from being deployed. This >=20 > This isn't just a perception, it's a demonstrable reality. >=20 >=20 > S 4. > > =20 > > o One motive to use encryption is a response to perceptions that t= he > > network has become ossified by over-reliance on middleboxes that= > > prevent new protocols and mechanisms from being deployed. This > > has lead to a perception that there is too much "manipulation" o= f > > protocol headers within the network, and that designing to deplo= y >=20 > Not just manipulation, also inspection. >=20 >=20 > S 4. > > =20 > > One example of encryption at the network layer is the use of IPs= ec > > Encapsulating Security Payload (ESP) [RFC4303] in tunnel mode. > > This encrypts and authenticates all transport headers, preventin= g > > visibility of the transport headers by in-network devices. Some= > > VPN methods also encrypt these headers. >=20 > This seems like a bad example as part of the point of a VPN is to > conceal the headers form the network. >=20 >=20 > S 6.1. > > =20 > > 6.1. Independent Measurement > > =20 > > Independent observation by multiple actors is important if the > > transport community is to maintain an accurate understanding of the= > > network. Encrypting transport header encryption changes the abilit= y >=20 > This is ironic because QUIC is much better for endpoint measurement > than TCP because the details are accessible at the application layer. >=20 >=20 > S 8. > > example, an attacker could construct a DOS attack by sending packet= s > > with a sequence number that falls within the currently accepted ran= ge > > of sequence numbers at the receiving endpoint, this would then > > introduce additional work at the receiving endpoint, even though th= e > > data in the attacking packet may not finally be delivered by the > > transport layer. This is sometimes known as a "shadowing attack". >=20 > This doesn't seem to be an issue with protocols that authenticate the SN. >=20 >=20 > S 8. > > =20 > > An attack can, for example, disrupt receiver processing, trigger lo= ss > > and retransmission, or make a receiving endpoint perform unproducti= ve > > decryption of packets that cannot be successfully decrypted (forcin= g > > a receiver to commit decryption resources, or to update and then > > restore protocol state). >=20 > This is not a real issue for QUIC or similar protocols >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Sun Nov 3 18:15:32 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6F8120020 for ; Sun, 3 Nov 2019 18:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_URDNm-c-ky for ; Sun, 3 Nov 2019 18:15:18 -0800 (PST) Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) (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 604831200B2 for ; Sun, 3 Nov 2019 18:15:18 -0800 (PST) Received: by mail-ed1-x541.google.com with SMTP id x11so1827849eds.13 for ; Sun, 03 Nov 2019 18:15:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mqGVvXc0zEkIwX3pdBxfHTOiTww2ftaOtdFPDo8WQ0U=; b=1TqUr9XCbHDXSXmJjLyzrDj9WX+Lo+5FYJzXGhtfQyZkJp4gS9ifNvG8Wuz7EVYLDj P7jPZaHEC5oJW72W2+SJIFEhKtaJCP+r/wImsHbDv4xeEp1Kzuv1x9+HQPwVa4Et0paZ W/ffyJPTyKQ/YWyRKFAdEU+dnJU6V+GtWf8RaFQwFntL4GTZX+EN1NJLLDtJeaXFzzQf xRvBxh541/oF35pA61/xDaAoLm8aJPLKzgs8DBHKujLnQIiNsLDjRTiX0utragy4ZCbV y8Mi0jEo/HYtDaP7fSOjSn9xmSPQZ6Evi5lxDo7+BdYHFsT1kRvLNoOlTpDEHia0uRQ9 YqVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mqGVvXc0zEkIwX3pdBxfHTOiTww2ftaOtdFPDo8WQ0U=; b=Xib1zPlR3aY/AIebksFXcIuOvWYSnPoliG+fDIAW1t4GxIEQPbMvx9bTSu/08CNkcf h+AyROoU2PXcIPWQ1QqCJqdajy0PNX1Hjh00jnsyy+Nb4DvsEA4PXQvKaB/nkdK24obz jr7HM5nUowrcRX+Oy7pNyCjS6uW0P0+9BnDdGPQMKbH68NLMgjRqzwVavWRX8uvfwswO MC5geEKL/PqnPdNLSYe+EGJJPIiptLyJJINl/W2OtDL22yeMYgh4p0+n8EkJcfFYHQqS pVJRm7G9kQla11eQlfRNxiskCcByb6eYi2e4MgaWk2Fdz/DF1MBXnxA6ljmqYR5/9pQc 61WQ== X-Gm-Message-State: APjAAAVBIUwDWSiLCfbYbo+211BCrECGRzKL9tdQFYsIeXrEUtC5BqGB D4bprqPv3zLDQiCZf9AA3Ze8NLziaB0X2TRSRQAIyw== X-Google-Smtp-Source: APXvYqwtkJNLapC2elJt+sVy4IqccbqMLAFuSjsvVtLqUzDbp/AoEiZfstlBXwqjTakvRM8P9GsTRC5kpgE9nFtrfow= X-Received: by 2002:a17:907:1114:: with SMTP id qu20mr1482780ejb.42.1572833716580; Sun, 03 Nov 2019 18:15:16 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tom Herbert Date: Sun, 3 Nov 2019 18:15:05 -0800 Message-ID: To: Eric Rescorla Cc: tsvwg IETF list , saag@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 02:15:23 -0000 On Sun, Nov 3, 2019 at 2:20 PM Eric Rescorla wrote: > > After reviewing this document, I share Christian Huitema's concern > about the tone and perspective of this document, which, while saying > that encryption is good, then proceeds to mostly lament how difficult > it makes life for various entities other than the endpoints. It seems > to me rather problematic to publish this document as an RFC for > several reasons: > > - Yes, it's true that the trend towards encrypting everything has > and continues to make a number of entities sad, but that's a point > which is already made in RFC 8404. How does all of the additional > detail here help? > > - The community of people designing new transport protocols has > already weighed all the considerations here and come down pretty > decisively on the side of "encrypt all the things". Given that > both SCTP-over-DTLS and QUIC do this, it seems pretty unlikely > we're going to design a new transport protocol that doesn't. > > - Having an IETF Consensus RFC that is so heavily weighted on the side > of "this is how encryption inconveniences us" and so light on "these > are the attacks we are preventing" gives a misleading picture of the > IETF community's view of the relative priority of these > concerns. ISTM that RFC 8558 -- though perhaps imperfect -- far more > closely reflects that consensus. > > In short, I do not think this draft should be published as an RFC. > I believe the problem with this draft is that it identifies a perceived problem, but does little to offer a solution other than saying don't encrypt the transport layer header. As I've mentioned several times, putting transport layer information of interest into HBH extension headers is the architecturally correct solution for hosts to signal the network. This works with any transport layer protocol and exposure of transport layer information to the network is under explicit control of the end host. IMO, the draft does not adequately explore this alternative solution and too easily just brushes it off as being "undesirable" based on one set of snapshot measurements that is now almost four years old. > I have appended a number of detailed comments which IMO need to be > addressed in any case, but even if they were resolved, that would not > address my primary concern. > > > COMMENTS > S 2.1. > > 2.1. Use of Transport Header Information in the Network > > > > In-network measurement of transport flow characteristics can be used > > to enhance performance, and control cost and service reliability. > > Some operators have deployed functionality in middleboxes to both > > support network operations and enhance performance. This reliance on > > This seems like a contested point. My understanding is that while > these middleboxes are *intended* to enhance performance that there is > doubt that they actually do. > > > S 2.1. > > to enhance performance, and control cost and service reliability. > > Some operators have deployed functionality in middleboxes to both > > support network operations and enhance performance. This reliance on > > the presence and semantics of specific header information leads to > > ossification, where an endpoint could be required to supply a > > specific header to receive the network service that it desires. In > > Well, not just the network service it desires but *any* service. > > > S 2.1. > > specific header to receive the network service that it desires. In > > some cases, this could be benign or advantageous to the protocol > > (e.g., recognising the start of a connection, or explicitly exposing > > protocol information can be expected to provide more consistent > > decisions by on-path devices than the use of diverse methods to infer > > semantics from other flow properties). In other cases, the > > Is there evidence of this? > > > S 2.1. > > > > As an example of ossification, consider the experience of developing > > Transport Layer Security (TLS) 1.3 [RFC8446]. This required a design > > that recognised that deployed middleboxes relied on the presence of > > certain header filed exposed in TLS 1.2, and failed if those headers > > were changed. Other examples of the impact of ossification can be > > I think you mean "fields" and it wasn't headers so much as handshake > data. > > > S 2.2. > > This supports use of this information by on-path devices, but at the > > same time can be expected to lead to ossification of the transport > > header, because network forwarding could evolve to depend on the > > presence and/or value of these fields. To avoid unwanted inspection, > > a protocol could intentionally vary the format or value of exposed > > header fields [I-D.ietf-tls-grease]. > > It's not just a matter of unwanted inspection. There's a real question > about whether we want these on-path devices to have this information > at all, as it is potentially used for surveillance, traffic > analysis, etc. > > > > S 2..2. > > > > While encryption can hide transport header information, it does not > > prevent ossification of the network service. People seeking to > > understand network traffic could come to rely on pattern inferences > > and other heuristics as the basis for network decision and to derive > > measurement data. This can create new dependencies on the transport > > This also seems quite contested. Do you have any evidence of such a > thing happening? > > > S 2.3. > > anomalies, and failure pathologies at any point along the Internet > > path. In many cases, it is important to relate observations to > > specific equipment/configurations or network segments. > > > > Concealing transport header information makes performance/ > > behaviour unavailable to passive observers along the path, > > While also making traffic analysis more difficult. > > > S 2.3. > > applications it is important to relate observations to specific > > equipment/configurations or particular network segments. > > > > Concealing transport header information can make analysis harder > > or impossible. This could impact the ability for an operator to > > anticipate the need for network upgrades and roll-out. It can > > Or to reduce the opportunities for traffic discrimination. > > > S 2.3. > > > > Different parties will view the relative importance of these issues > > differently. For some, the benefits of encrypting some, or all, of > > the transport headers may outweigh the impact of doing so; others > > might make a different trade-off. The purpose of highlighting the > > trade-offs is to make such analysis possible. > > This whole section seems to really just ignore the fact that many of > these practices are unwanted. > > > S 3.1. > > Firewalls). Common issues concerning IP address sharing are > > described in [RFC6269]. > > > > 3.1. Observing Transport Information in the Network > > > > If in-network observation of transport protocol headers is needed, > > Why is this needed? I know some people might want it. > > > S 3.1.1. > > 3.1.1. Flow Identification Using Transport Layer Headers > > > > Flow identification is a common function. For example, performed by > > measurement activities, QoS classification, firewalls, Denial of > > Service, DOS, prevention. This becomes more complex and less easily > > achieved when multiplexing is used at or above the transport layer. > > Also traffic discrimination and blocking. > > > S 3.1.1. > > use heuristics to infer that short UDP packets with regular spacing > > carry audio traffic. Operational practices aimed at inferring > > transport parameters are out of scope for this document, and are only > > mentioned here to recognize that encryption does not prevent > > operators from attempting to apply practices that were used with > > unencrypted transport headers. > > This has a really threatening tone. If you don't give us what we want, > look what could happen. > > > S 3.1.2. > > > > This information can support network operations, inform capacity > > planning, and assist in determining the need for equipment and/or > > configuration changes by network operators. It can also inform > > Internet engineering activities by informing the development of new > > protocols, methodologies, and procedures. > > What is the point of this exhaustive list? > > > S 3.1.3. > > > > AQM and ECN offer a range of algorithms and configuration options. > > Tools therefore need to be available to network operators and > > researchers to understand the implication of configuration choices > > and transport behaviour as the use of ECN increases and new > > methods emerge [RFC7567]. > > QUIC sort of hides ECN feedback but not ECN marking. > > > S 3.2.4. > > > > A network operator needs tools to understand if datagram flows > > (e.g., using UDP) comply with congestion control expectations and > > therefore whether there is a need to deploy methods such as rate- > > limiters, transport circuit breakers, or other methods to enforce > > acceptable usage for the offered service. > > Does it *need* it or does it just want it. Note that we have had DTLS- > SCTP with WebRTC without this property for some time now. Can you provide > some evidence that operators have been inconvenienced by not having it. > > > S 3.3. > > operators bring together heterogeneous types of network equipment and > > seek to deploy opportunistic methods to access radio spectrum. > > > > A flow that conceals its transport header information could imply > > "don't touch" to some operators. This could limit a trouble-shooting > > response to "can't help, no trouble found". > > We have quite a bit of QUIC traffic now. I'd be interested in hearing > from the gQUIC team whether they have seen anything like this. QUIC presents a problem in itself since the QUIC harders are inside the UDP payload so intermediate devices end up needing to parse the UDP transport payload. I believe the only way to identify a QUIC packet is by matching port numbers, but per RFC7605 interpretation of port numbers in the middle of the network is prone to misinterpretation. Eventually, something that looks like a QUIC packet based on port number will be misinterpreted. Looking at draft-ietf-quic-transport-23, I don't see any discussion about this or reference to RFC7605. Note this is true for any use case of UDP including transport layer or network layer encapsulation. Even if the argument is that the information is only being read and misinterpretation is innocuous, it still wouldn't be robust protocol. This can be contrasted to putting the information in HBH options which can be correctly and unambiguously identified anywhere in the network. Tom > > > S 4. > > > > There are several motivations for encryption: > > > > o One motive to use encryption is a response to perceptions that the > > network has become ossified by over-reliance on middleboxes that > > prevent new protocols and mechanisms from being deployed. This > > This isn't just a perception, it's a demonstrable reality. > > > S 4. > > > > o One motive to use encryption is a response to perceptions that the > > network has become ossified by over-reliance on middleboxes that > > prevent new protocols and mechanisms from being deployed. This > > has lead to a perception that there is too much "manipulation" of > > protocol headers within the network, and that designing to deploy > > Not just manipulation, also inspection. > > > S 4. > > > > One example of encryption at the network layer is the use of IPsec > > Encapsulating Security Payload (ESP) [RFC4303] in tunnel mode. > > This encrypts and authenticates all transport headers, preventing > > visibility of the transport headers by in-network devices. Some > > VPN methods also encrypt these headers. > > This seems like a bad example as part of the point of a VPN is to > conceal the headers form the network. > > > S 6.1. > > > > 6.1. Independent Measurement > > > > Independent observation by multiple actors is important if the > > transport community is to maintain an accurate understanding of the > > network. Encrypting transport header encryption changes the ability > > This is ironic because QUIC is much better for endpoint measurement > than TCP because the details are accessible at the application layer. > > > S 8. > > example, an attacker could construct a DOS attack by sending packets > > with a sequence number that falls within the currently accepted range > > of sequence numbers at the receiving endpoint, this would then > > introduce additional work at the receiving endpoint, even though the > > data in the attacking packet may not finally be delivered by the > > transport layer. This is sometimes known as a "shadowing attack". > > This doesn't seem to be an issue with protocols that authenticate the SN. > > > S 8. > > > > An attack can, for example, disrupt receiver processing, trigger loss > > and retransmission, or make a receiving endpoint perform unproductive > > decryption of packets that cannot be successfully decrypted (forcing > > a receiver to commit decryption resources, or to update and then > > restore protocol state). > > This is not a real issue for QUIC or similar protocols > > > > > > > > > > > > > > > > From nobody Sun Nov 3 19:18:03 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23A2120888; Sun, 3 Nov 2019 19:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=JZ/c+PlF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YZFb9gXd 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 pXAITiYrTFjj; Sun, 3 Nov 2019 19:17:48 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E7E120058; Sun, 3 Nov 2019 19:17:48 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 59DBD21B7C; Sun, 3 Nov 2019 22:17:47 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sun, 03 Nov 2019 22:17:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=qXfZNKNjV8al7Q0EhqhEdt8QVs+5kwh m1evR3GmSmG4=; b=JZ/c+PlFzs1RzyfVQwAJ4YQXKXASxEQiFGsofTRf6a0MLXO wEh4h2EO9REaiGn93BAMTjYUi2YYC8zDhRYsnLQeAcMv7ga2VPZj2HuxtPAXtKFj jX9obxkrAkPOhyb6xbDGoqR7JIsDSh4FtQgoUXQXh0r8Cc9YuX53sIf0JwmuAy/k H0hBiGlfbciAPsIDlsNn/ZpezpZEzioGud0Oc8bgnMfCd74Z4nUuhiLflvXKN6Qb R95PYkNNDzlKEZf/5O3ZBaV3dHOJSMbsO/UydTlAg6A3J1u5KDnYrBJgLReVN2xO ccokQEKs2oCHG9MEnBHXfQZX0sZo3jKAD+/dHbQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=qXfZNK NjV8al7Q0EhqhEdt8QVs+5kwhm1evR3GmSmG4=; b=YZFb9gXdaZ7Bue3VaEE55G ZmgHWL9A/TJCS/995tZ8FHkGXdkF7+XFxxljpAtsLVhRV7+pAkjitAXhPDdNPLRo xWdnpxyEYT+E1luRUHKyV/AYIYe8gcy0RauWVcpZe8TVvIyxyS+JAV+GkRz6MYG9 OV58roiqZqWnCdtAySzvDBZrTHo54knVGT2mRK3bTlAgiEguhgxXxQYx5w9UnWPg Cd4FJXBatkVmOAnee8mZewIgx9rCaSCvs8l/P7HjlmgyK+BxGNbig+4MAuKAhHJX fUn/u7bYrx8vkwSceKR2XEwQ1WSZHmQHoDul08goakghdPGBB07AXS0G6F2KXRWw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduvddgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhs thgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 06002E00A3; Sun, 3 Nov 2019 22:17:46 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 04 Nov 2019 14:17:19 +1100 From: "Martin Thomson" To: saag@ietf.org, tsvwg@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [saag] =?utf-8?q?=5Btsvwg=5D_Comments_on_draft-ietf-tsvwg-transp?= =?utf-8?q?ort-encrypt-08=2Etxt?= X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 03:17:53 -0000 On Mon, Nov 4, 2019, at 13:15, Tom Herbert wrote: > QUIC presents a problem in itself since the QUIC harders are inside > the UDP payload so intermediate devices end up needing to parse the > UDP transport payload. I believe the only way to identify a QUIC > packet is by matching port numbers, but per RFC7605 interpretation of > port numbers in the middle of the network is prone to > misinterpretation. Eventually, something that looks like a QUIC packet > based on port number will be misinterpreted. Looking at > draft-ietf-quic-transport-23, I don't see any discussion about this or > reference to RFC7605. Please refer to draft-ietf-quic-manageability for that discussion. Note that while there has been extensive discussion on what QUIC should expose in terms of loss and latency, I recall relatively little discussion about distinguishing QUIC from other protocols outside of the narrow context of ensuring that QUIC can be effectively multiplexed with certain other protocols. My sense is that some people are assuming that they can use port numbers, which are fraught for the reasons you identify. Others might choose to infer the use of QUIC using the "QUIC bit": the 0x40 bit in QUIC version 1 is fixed. Personally, I think that endpoints are not obligated to signal which protocol they are using to the network. Maybe the QUIC bit is that signal and I'm just in denial. I guess we'll see whether I can send packets with a 0 value for that bit... > This can be contrasted to putting the information in HBH options which > can be correctly and unambiguously identified anywhere in the network. I happen to agree, though I don't think that this is as simple as you might be implying. https://tools.ietf.org/html/rfc8558 makes a similar assertion, but identifies some of the underlying complexities. From nobody Mon Nov 4 01:14:52 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEE1120D89; Mon, 4 Nov 2019 01:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hnPLYCXngQL; Mon, 4 Nov 2019 01:14:47 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150049.outbound.protection.outlook.com [40.107.15.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A794120D87; Mon, 4 Nov 2019 01:14:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G98l2wVfFXmoxSWTCVCbA3xqq8pWkPFvULNuU5l94HdmIDp/6Hwunr4xQBBPo3KeYikZaKeA3h8DABmKf6D99/Dhm8sw1aCqWiQLZuFlBIF9T/2uS5bNPVBvNDJ4LcgVeBcjRkWiGtzdl5pYpqSkaQ2sNe1lQWx5QpB6PhWo+CIbivXU7JhpXExQCnugeXMzP/oBHzLAZHhzPYS8V1/v+r8KdjpUAZvTNZB+UCQ7ZlBxzAbRKqIEeK4yzb+DOfhpd6BuDEBPyCiaJHNGT94MdbwaXuTSjbD7REa1seO9cxAdNHVn4GCkhJvV6ZCjrYQFxWM06CEJvrr/D67QjS8/Uw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vkj/bkkAVFPdF0ox0p76v3jYRsWSv2fEe7+8/xJvdKs=; b=LmP8UyHfuZE5yQ7gncNZlW3z3PTGcvRbJfPou1QLzNhehrPzio4ag5XgQBG3SqapdDDKxUxEjFr1Z9yvlHrXLOlAU9t4k4tV6PeUBknHDHsnB3Auu2yQ98//KYGZFqXfp7/6ZO1ljFJSd5+eHBW+F7oLPcWXD6yVGk2/baiRTpGIOdKkeXPTjzjLHGHtZmkz9HUdMKy/ibIBW0qlanBKKYbiMIufKeOOS7+VYRhqx5PeiL6scEpkixWjKGNQ/wmKP2meHrDWlUjxmDOvWVge+LQnOB3k9MxOVi3Qws0PpWuB1RvbO97oxfF7V5nP95BS53WexFEFK5QqceSlukU3+w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vkj/bkkAVFPdF0ox0p76v3jYRsWSv2fEe7+8/xJvdKs=; b=Yrsbcnsipjtsa1lrlgU1xhcI5Hm9gzi1ajAdpnUYXFFCUv33gj86TD5iynxA5Pm5Eeg+VXgGtORLyjYGwsEUbfNxIzappqRbF9uNkMewuvCpA8Inscpdi64O9V47mQrcityQd+3d/fqaViiAomH6JkizlE9N1F4ifUmyR9cQqoA= Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB5331.eurprd07.prod.outlook.com (20.178.19.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Mon, 4 Nov 2019 09:14:43 +0000 Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4189:4ef8:bfc1:ec58]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4189:4ef8:bfc1:ec58%7]) with mapi id 15.20.2430.013; Mon, 4 Nov 2019 09:14:43 +0000 From: Mirja Kuehlewind To: Tom Herbert , Eric Rescorla CC: tsvwg IETF list , "saag@ietf.org" Thread-Topic: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt Thread-Index: AQHVkpTuK59Ux5RWm0aKwFV5BLM7VKd6Ri6AgACF/4A= Date: Mon, 4 Nov 2019 09:14:43 +0000 Message-ID: <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mirja.kuehlewind@ericsson.com; x-originating-ip: [2003:eb:4700:cf00:3d57:7e7e:af67:8db2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: faf6f149-8a7b-4ddc-422f-08d761076e25 x-ms-traffictypediagnostic: AM0PR07MB5331: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(346002)(376002)(39860400002)(396003)(199004)(189003)(53754006)(76176011)(6512007)(44832011)(71200400001)(2616005)(476003)(6436002)(66476007)(46003)(316002)(102836004)(6246003)(229853002)(53546011)(6506007)(110136005)(54906003)(99286004)(6486002)(76116006)(5660300002)(36756003)(8936002)(30864003)(66946007)(8676002)(81166006)(81156014)(186003)(6116002)(478600001)(305945005)(486006)(66556008)(64756008)(66446008)(2906002)(256004)(14454004)(7736002)(86362001)(446003)(66574012)(11346002)(25786009)(14444005)(4326008)(33656002)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB5331; H:AM0PR07MB4691.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bKIOLENGnOXsoxZtcPmF0cGmFHz8vxkbhtD8ywNzMMcGZK3xL2yTKuTz+79Zc7P3sEaWU35D/6tDC7kdFie+oMyW65c5NPkACDGPtX+GbVlLG0CPdRvMbElbLOwgRqgrrwpp0nyomie2pGt8VwsnEFltmH9tJ6RTyDYS9HZ6UI8Gh3bCn5nQ9v4Y0PiJ+O63SIw6QSRKd6qfn2yPGzAYFsO25c7sPPc5XerevJw512ggE50/I9x/YaMGClhlC3cjb6uelnpf7/8KnsvTxk5pNiswxH2JWasJhyHCm1AZsPtOsvrcYQbXKEOeL0kNRtd/mtXOt0bQx8UTpyJ3dMmKnp6qpzVZ0ETGsORCGs1144hBj8rsHmOHwiNGcGheniTZq0oSiZXVamDTvO6/PrWLubTiezC0gy1A3fg8PE/x5QafK7T4u89W+Z8J26Rzu6vi x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <0CA0290355108A4E9A2419E087E0745D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: faf6f149-8a7b-4ddc-422f-08d761076e25 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2019 09:14:43.5596 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Etaa0mGs5qZ+p8FBUoyixq0gvaZSaB6bPNaMAPDSHLqipAeY70YesQ0qz/K4hmUoDSKi4FM2lC6LPHqSkT5PEmtnmJzzFXAvDO1mXDvbaHs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5331 Archived-At: Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 09:14:50 -0000 SGkgRWtyLCBoaSBhbGwsDQoNCkp1c3Qgb24gdGhpcyBwYXJ0Og0KICAgID4gLSBUaGUgY29tbXVu aXR5IG9mIHBlb3BsZSBkZXNpZ25pbmcgbmV3IHRyYW5zcG9ydCBwcm90b2NvbHMgaGFzDQogICAg PiAgIGFscmVhZHkgd2VpZ2hlZCBhbGwgdGhlIGNvbnNpZGVyYXRpb25zIGhlcmUgYW5kIGNvbWUg ZG93biBwcmV0dHkNCiAgICA+ICAgZGVjaXNpdmVseSBvbiB0aGUgc2lkZSBvZiAiZW5jcnlwdCBh bGwgdGhlIHRoaW5ncyIuIEdpdmVuIHRoYXQNCiAgICA+ICAgYm90aCBTQ1RQLW92ZXItRFRMUyBh bmQgUVVJQyBkbyB0aGlzLCBpdCBzZWVtcyBwcmV0dHkgdW5saWtlbHkNCiAgICA+ICAgd2UncmUg Z29pbmcgdG8gZGVzaWduIGEgbmV3IHRyYW5zcG9ydCBwcm90b2NvbCB0aGF0IGRvZXNuJ3QuDQpJ IGRpc2FncmVlIHRoYXQgdGhpcyBpcyB0aGUgY29uY2x1c2lvbiB0aGUgY29tbXVuaXR5IGNhbWUg dG8sIG90aGVyd2lzZSB3ZSB3b3VsZCBub3QgaGF2ZSBwdXQgYSBzaWduYWwgZm9yIHRoZSBuZXR3 b3JrIGluIHRoZSBRVUlDIGhlYWRlci4gQWxzbyBlbmNyeXB0aW9uIGhhcyBhIGNvc3QgYW5kIHRo YXQncyB0aGUgZGlzY3Vzc2lvbiB3ZSBjb250aW51b3VzbHkgc3RpbGwgaGF2aW5nIGluIFFVSUMg YW5kIHdlbGwgYXMgb3RoZXIgd29ya2luZyBncm91cHMuIFNvICJlbmNyeXB0IGFsbCB0aGUgdGhp bmdzIiBpcyB3YXkgdG9vIHNpbXBsaWZpZWQgYW5kIGZvciBzdXJlIG5vdCBhIGNvbnNlbnN1cyBz dGF0ZW1lbnQgd2hpY2ggdGhpcyBkcmFmdCAoZHJhZnQtaWV0Zi10c3Z3Zy10cmFuc3BvcnQtZW5j cnlwdCkgY2xlYXJseSBzaG93cy4NCg0KTWlyamENCg0KDQoNCu+7v09uIDA0LjExLjE5LCAwMzox NSwgInRzdndnIG9uIGJlaGFsZiBvZiBUb20gSGVyYmVydCIgPHRzdndnLWJvdW5jZXNAaWV0Zi5v cmcgb24gYmVoYWxmIG9mIHRvbUBoZXJiZXJ0bGFuZC5jb20+IHdyb3RlOg0KDQogICAgT24gU3Vu LCBOb3YgMywgMjAxOSBhdCAyOjIwIFBNIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4gd3Jv dGU6DQogICAgPg0KICAgID4gQWZ0ZXIgcmV2aWV3aW5nIHRoaXMgZG9jdW1lbnQsIEkgc2hhcmUg Q2hyaXN0aWFuIEh1aXRlbWEncyBjb25jZXJuDQogICAgPiBhYm91dCB0aGUgdG9uZSBhbmQgcGVy c3BlY3RpdmUgb2YgdGhpcyBkb2N1bWVudCwgd2hpY2gsIHdoaWxlIHNheWluZw0KICAgID4gdGhh dCBlbmNyeXB0aW9uIGlzIGdvb2QsIHRoZW4gcHJvY2VlZHMgdG8gbW9zdGx5IGxhbWVudCBob3cg ZGlmZmljdWx0DQogICAgPiBpdCBtYWtlcyBsaWZlIGZvciB2YXJpb3VzIGVudGl0aWVzIG90aGVy IHRoYW4gdGhlIGVuZHBvaW50cy4gSXQgc2VlbXMNCiAgICA+IHRvIG1lIHJhdGhlciBwcm9ibGVt YXRpYyB0byBwdWJsaXNoIHRoaXMgZG9jdW1lbnQgYXMgYW4gUkZDIGZvcg0KICAgID4gc2V2ZXJh bCByZWFzb25zOg0KICAgID4NCiAgICA+IC0gWWVzLCBpdCdzIHRydWUgdGhhdCB0aGUgdHJlbmQg dG93YXJkcyBlbmNyeXB0aW5nIGV2ZXJ5dGhpbmcgaGFzDQogICAgPiAgIGFuZCBjb250aW51ZXMg dG8gbWFrZSBhIG51bWJlciBvZiBlbnRpdGllcyBzYWQsIGJ1dCB0aGF0J3MgYSBwb2ludA0KICAg ID4gICB3aGljaCBpcyBhbHJlYWR5IG1hZGUgaW4gUkZDIDg0MDQuIEhvdyBkb2VzIGFsbCBvZiB0 aGUgYWRkaXRpb25hbA0KICAgID4gICBkZXRhaWwgaGVyZSBoZWxwPw0KICAgID4NCiAgICA+IC0g VGhlIGNvbW11bml0eSBvZiBwZW9wbGUgZGVzaWduaW5nIG5ldyB0cmFuc3BvcnQgcHJvdG9jb2xz IGhhcw0KICAgID4gICBhbHJlYWR5IHdlaWdoZWQgYWxsIHRoZSBjb25zaWRlcmF0aW9ucyBoZXJl IGFuZCBjb21lIGRvd24gcHJldHR5DQogICAgPiAgIGRlY2lzaXZlbHkgb24gdGhlIHNpZGUgb2Yg ImVuY3J5cHQgYWxsIHRoZSB0aGluZ3MiLiBHaXZlbiB0aGF0DQogICAgPiAgIGJvdGggU0NUUC1v dmVyLURUTFMgYW5kIFFVSUMgZG8gdGhpcywgaXQgc2VlbXMgcHJldHR5IHVubGlrZWx5DQogICAg PiAgIHdlJ3JlIGdvaW5nIHRvIGRlc2lnbiBhIG5ldyB0cmFuc3BvcnQgcHJvdG9jb2wgdGhhdCBk b2Vzbid0Lg0KICAgID4NCiAgICA+IC0gSGF2aW5nIGFuIElFVEYgQ29uc2Vuc3VzIFJGQyB0aGF0 IGlzIHNvIGhlYXZpbHkgd2VpZ2h0ZWQgb24gdGhlIHNpZGUNCiAgICA+ICAgb2YgInRoaXMgaXMg aG93IGVuY3J5cHRpb24gaW5jb252ZW5pZW5jZXMgdXMiIGFuZCBzbyBsaWdodCBvbiAidGhlc2UN CiAgICA+ICAgYXJlIHRoZSBhdHRhY2tzIHdlIGFyZSBwcmV2ZW50aW5nIiBnaXZlcyBhIG1pc2xl YWRpbmcgcGljdHVyZSBvZiB0aGUNCiAgICA+ICAgSUVURiBjb21tdW5pdHkncyB2aWV3IG9mIHRo ZSByZWxhdGl2ZSBwcmlvcml0eSBvZiB0aGVzZQ0KICAgID4gICBjb25jZXJucy4gSVNUTSB0aGF0 IFJGQyA4NTU4IC0tIHRob3VnaCBwZXJoYXBzIGltcGVyZmVjdCAtLSBmYXIgbW9yZQ0KICAgID4g ICBjbG9zZWx5IHJlZmxlY3RzIHRoYXQgY29uc2Vuc3VzLg0KICAgID4NCiAgICA+IEluIHNob3J0 LCBJIGRvIG5vdCB0aGluayB0aGlzIGRyYWZ0IHNob3VsZCBiZSBwdWJsaXNoZWQgYXMgYW4gUkZD Lg0KICAgID4NCiAgICBJIGJlbGlldmUgdGhlIHByb2JsZW0gd2l0aCB0aGlzIGRyYWZ0IGlzIHRo YXQgaXQgaWRlbnRpZmllcyBhDQogICAgcGVyY2VpdmVkIHByb2JsZW0sIGJ1dCBkb2VzIGxpdHRs ZSB0byBvZmZlciBhIHNvbHV0aW9uIG90aGVyIHRoYW4NCiAgICBzYXlpbmcgZG9uJ3QgZW5jcnlw dCB0aGUgdHJhbnNwb3J0IGxheWVyIGhlYWRlci4gQXMgSSd2ZSBtZW50aW9uZWQNCiAgICBzZXZl cmFsIHRpbWVzLCBwdXR0aW5nIHRyYW5zcG9ydCBsYXllciBpbmZvcm1hdGlvbiBvZiBpbnRlcmVz dCBpbnRvDQogICAgSEJIIGV4dGVuc2lvbiBoZWFkZXJzIGlzIHRoZSBhcmNoaXRlY3R1cmFsbHkg Y29ycmVjdCBzb2x1dGlvbiBmb3INCiAgICBob3N0cyB0byBzaWduYWwgdGhlIG5ldHdvcmsuIFRo aXMgd29ya3Mgd2l0aCBhbnkgdHJhbnNwb3J0IGxheWVyDQogICAgcHJvdG9jb2wgYW5kIGV4cG9z dXJlIG9mIHRyYW5zcG9ydCBsYXllciBpbmZvcm1hdGlvbiB0byB0aGUgbmV0d29yayBpcw0KICAg IHVuZGVyIGV4cGxpY2l0IGNvbnRyb2wgb2YgdGhlIGVuZCBob3N0LiBJTU8sIHRoZSBkcmFmdCBk b2VzIG5vdA0KICAgIGFkZXF1YXRlbHkgZXhwbG9yZSB0aGlzIGFsdGVybmF0aXZlIHNvbHV0aW9u IGFuZCB0b28gZWFzaWx5IGp1c3QNCiAgICBicnVzaGVzIGl0IG9mZiBhcyBiZWluZyAidW5kZXNp cmFibGUiIGJhc2VkIG9uIG9uZSBzZXQgb2Ygc25hcHNob3QNCiAgICBtZWFzdXJlbWVudHMgdGhh dCBpcyBub3cgYWxtb3N0IGZvdXIgeWVhcnMgb2xkLg0KICAgIA0KICAgID4gSSBoYXZlIGFwcGVu ZGVkIGEgbnVtYmVyIG9mIGRldGFpbGVkIGNvbW1lbnRzIHdoaWNoIElNTyBuZWVkIHRvIGJlDQog ICAgPiBhZGRyZXNzZWQgaW4gYW55IGNhc2UsIGJ1dCBldmVuIGlmIHRoZXkgd2VyZSByZXNvbHZl ZCwgdGhhdCB3b3VsZCBub3QNCiAgICA+IGFkZHJlc3MgbXkgcHJpbWFyeSBjb25jZXJuLg0KICAg ID4NCiAgICA+DQogICAgPiBDT01NRU5UUw0KICAgID4gUyAyLjEuDQogICAgPiA+ICAgMi4xLiAg VXNlIG9mIFRyYW5zcG9ydCBIZWFkZXIgSW5mb3JtYXRpb24gaW4gdGhlIE5ldHdvcmsNCiAgICA+ ID4NCiAgICA+ID4gICAgICBJbi1uZXR3b3JrIG1lYXN1cmVtZW50IG9mIHRyYW5zcG9ydCBmbG93 IGNoYXJhY3RlcmlzdGljcyBjYW4gYmUgdXNlZA0KICAgID4gPiAgICAgIHRvIGVuaGFuY2UgcGVy Zm9ybWFuY2UsIGFuZCBjb250cm9sIGNvc3QgYW5kIHNlcnZpY2UgcmVsaWFiaWxpdHkuDQogICAg PiA+ICAgICAgU29tZSBvcGVyYXRvcnMgaGF2ZSBkZXBsb3llZCBmdW5jdGlvbmFsaXR5IGluIG1p ZGRsZWJveGVzIHRvIGJvdGgNCiAgICA+ID4gICAgICBzdXBwb3J0IG5ldHdvcmsgb3BlcmF0aW9u cyBhbmQgZW5oYW5jZSBwZXJmb3JtYW5jZS4gIFRoaXMgcmVsaWFuY2Ugb24NCiAgICA+DQogICAg PiBUaGlzIHNlZW1zIGxpa2UgYSBjb250ZXN0ZWQgcG9pbnQuIE15IHVuZGVyc3RhbmRpbmcgaXMg dGhhdCB3aGlsZQ0KICAgID4gdGhlc2UgbWlkZGxlYm94ZXMgYXJlICppbnRlbmRlZCogdG8gZW5o YW5jZSBwZXJmb3JtYW5jZSB0aGF0IHRoZXJlIGlzDQogICAgPiBkb3VidCB0aGF0IHRoZXkgYWN0 dWFsbHkgZG8uDQogICAgPg0KICAgID4NCiAgICA+IFMgMi4xLg0KICAgID4gPiAgICAgIHRvIGVu aGFuY2UgcGVyZm9ybWFuY2UsIGFuZCBjb250cm9sIGNvc3QgYW5kIHNlcnZpY2UgcmVsaWFiaWxp dHkuDQogICAgPiA+ICAgICAgU29tZSBvcGVyYXRvcnMgaGF2ZSBkZXBsb3llZCBmdW5jdGlvbmFs aXR5IGluIG1pZGRsZWJveGVzIHRvIGJvdGgNCiAgICA+ID4gICAgICBzdXBwb3J0IG5ldHdvcmsg b3BlcmF0aW9ucyBhbmQgZW5oYW5jZSBwZXJmb3JtYW5jZS4gIFRoaXMgcmVsaWFuY2Ugb24NCiAg ICA+ID4gICAgICB0aGUgcHJlc2VuY2UgYW5kIHNlbWFudGljcyBvZiBzcGVjaWZpYyBoZWFkZXIg aW5mb3JtYXRpb24gbGVhZHMgdG8NCiAgICA+ID4gICAgICBvc3NpZmljYXRpb24sIHdoZXJlIGFu IGVuZHBvaW50IGNvdWxkIGJlIHJlcXVpcmVkIHRvIHN1cHBseSBhDQogICAgPiA+ICAgICAgc3Bl Y2lmaWMgaGVhZGVyIHRvIHJlY2VpdmUgdGhlIG5ldHdvcmsgc2VydmljZSB0aGF0IGl0IGRlc2ly ZXMuICBJbg0KICAgID4NCiAgICA+IFdlbGwsIG5vdCBqdXN0IHRoZSBuZXR3b3JrIHNlcnZpY2Ug aXQgZGVzaXJlcyBidXQgKmFueSogc2VydmljZS4NCiAgICA+DQogICAgPg0KICAgID4gUyAyLjEu DQogICAgPiA+ICAgICAgc3BlY2lmaWMgaGVhZGVyIHRvIHJlY2VpdmUgdGhlIG5ldHdvcmsgc2Vy dmljZSB0aGF0IGl0IGRlc2lyZXMuICBJbg0KICAgID4gPiAgICAgIHNvbWUgY2FzZXMsIHRoaXMg Y291bGQgYmUgYmVuaWduIG9yIGFkdmFudGFnZW91cyB0byB0aGUgcHJvdG9jb2wNCiAgICA+ID4g ICAgICAoZS5nLiwgcmVjb2duaXNpbmcgdGhlIHN0YXJ0IG9mIGEgY29ubmVjdGlvbiwgb3IgZXhw bGljaXRseSBleHBvc2luZw0KICAgID4gPiAgICAgIHByb3RvY29sIGluZm9ybWF0aW9uIGNhbiBi ZSBleHBlY3RlZCB0byBwcm92aWRlIG1vcmUgY29uc2lzdGVudA0KICAgID4gPiAgICAgIGRlY2lz aW9ucyBieSBvbi1wYXRoIGRldmljZXMgdGhhbiB0aGUgdXNlIG9mIGRpdmVyc2UgbWV0aG9kcyB0 byBpbmZlcg0KICAgID4gPiAgICAgIHNlbWFudGljcyBmcm9tIG90aGVyIGZsb3cgcHJvcGVydGll cykuICBJbiBvdGhlciBjYXNlcywgdGhlDQogICAgPg0KICAgID4gSXMgdGhlcmUgZXZpZGVuY2Ug b2YgdGhpcz8NCiAgICA+DQogICAgPg0KICAgID4gUyAyLjEuDQogICAgPiA+DQogICAgPiA+ICAg ICAgQXMgYW4gZXhhbXBsZSBvZiBvc3NpZmljYXRpb24sIGNvbnNpZGVyIHRoZSBleHBlcmllbmNl IG9mIGRldmVsb3BpbmcNCiAgICA+ID4gICAgICBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKFRM UykgMS4zIFtSRkM4NDQ2XS4gIFRoaXMgcmVxdWlyZWQgYSBkZXNpZ24NCiAgICA+ID4gICAgICB0 aGF0IHJlY29nbmlzZWQgdGhhdCBkZXBsb3llZCBtaWRkbGVib3hlcyByZWxpZWQgb24gdGhlIHBy ZXNlbmNlIG9mDQogICAgPiA+ICAgICAgY2VydGFpbiBoZWFkZXIgZmlsZWQgZXhwb3NlZCBpbiBU TFMgMS4yLCBhbmQgZmFpbGVkIGlmIHRob3NlIGhlYWRlcnMNCiAgICA+ID4gICAgICB3ZXJlIGNo YW5nZWQuICBPdGhlciBleGFtcGxlcyBvZiB0aGUgaW1wYWN0IG9mIG9zc2lmaWNhdGlvbiBjYW4g YmUNCiAgICA+DQogICAgPiBJIHRoaW5rIHlvdSBtZWFuICJmaWVsZHMiIGFuZCBpdCB3YXNuJ3Qg aGVhZGVycyBzbyBtdWNoIGFzIGhhbmRzaGFrZQ0KICAgID4gZGF0YS4NCiAgICA+DQogICAgPg0K ICAgID4gUyAyLjIuDQogICAgPiA+ICAgICAgVGhpcyBzdXBwb3J0cyB1c2Ugb2YgdGhpcyBpbmZv cm1hdGlvbiBieSBvbi1wYXRoIGRldmljZXMsIGJ1dCBhdCB0aGUNCiAgICA+ID4gICAgICBzYW1l IHRpbWUgY2FuIGJlIGV4cGVjdGVkIHRvIGxlYWQgdG8gb3NzaWZpY2F0aW9uIG9mIHRoZSB0cmFu c3BvcnQNCiAgICA+ID4gICAgICBoZWFkZXIsIGJlY2F1c2UgbmV0d29yayBmb3J3YXJkaW5nIGNv dWxkIGV2b2x2ZSB0byBkZXBlbmQgb24gdGhlDQogICAgPiA+ICAgICAgcHJlc2VuY2UgYW5kL29y IHZhbHVlIG9mIHRoZXNlIGZpZWxkcy4gIFRvIGF2b2lkIHVud2FudGVkIGluc3BlY3Rpb24sDQog ICAgPiA+ICAgICAgYSBwcm90b2NvbCBjb3VsZCBpbnRlbnRpb25hbGx5IHZhcnkgdGhlIGZvcm1h dCBvciB2YWx1ZSBvZiBleHBvc2VkDQogICAgPiA+ICAgICAgaGVhZGVyIGZpZWxkcyBbSS1ELmll dGYtdGxzLWdyZWFzZV0uDQogICAgPg0KICAgID4gSXQncyBub3QganVzdCBhIG1hdHRlciBvZiB1 bndhbnRlZCBpbnNwZWN0aW9uLiBUaGVyZSdzIGEgcmVhbCBxdWVzdGlvbg0KICAgID4gYWJvdXQg d2hldGhlciB3ZSB3YW50IHRoZXNlIG9uLXBhdGggZGV2aWNlcyB0byBoYXZlIHRoaXMgaW5mb3Jt YXRpb24NCiAgICA+IGF0IGFsbCwgYXMgaXQgaXMgcG90ZW50aWFsbHkgdXNlZCBmb3Igc3VydmVp bGxhbmNlLCB0cmFmZmljDQogICAgPiBhbmFseXNpcywgZXRjLg0KICAgID4NCiAgICA+DQogICAg Pg0KICAgID4gUyAyLi4yLg0KICAgID4gPg0KICAgID4gPiAgICAgIFdoaWxlIGVuY3J5cHRpb24g Y2FuIGhpZGUgdHJhbnNwb3J0IGhlYWRlciBpbmZvcm1hdGlvbiwgaXQgZG9lcyBub3QNCiAgICA+ ID4gICAgICBwcmV2ZW50IG9zc2lmaWNhdGlvbiBvZiB0aGUgbmV0d29yayBzZXJ2aWNlLiAgUGVv cGxlIHNlZWtpbmcgdG8NCiAgICA+ID4gICAgICB1bmRlcnN0YW5kIG5ldHdvcmsgdHJhZmZpYyBj b3VsZCBjb21lIHRvIHJlbHkgb24gcGF0dGVybiBpbmZlcmVuY2VzDQogICAgPiA+ICAgICAgYW5k IG90aGVyIGhldXJpc3RpY3MgYXMgdGhlIGJhc2lzIGZvciBuZXR3b3JrIGRlY2lzaW9uIGFuZCB0 byBkZXJpdmUNCiAgICA+ID4gICAgICBtZWFzdXJlbWVudCBkYXRhLiAgVGhpcyBjYW4gY3JlYXRl IG5ldyBkZXBlbmRlbmNpZXMgb24gdGhlIHRyYW5zcG9ydA0KICAgID4NCiAgICA+IFRoaXMgYWxz byBzZWVtcyBxdWl0ZSBjb250ZXN0ZWQuIERvIHlvdSBoYXZlIGFueSBldmlkZW5jZSBvZiBzdWNo IGENCiAgICA+IHRoaW5nIGhhcHBlbmluZz8NCiAgICA+DQogICAgPg0KICAgID4gUyAyLjMuDQog ICAgPiA+ICAgICAgICAgYW5vbWFsaWVzLCBhbmQgZmFpbHVyZSBwYXRob2xvZ2llcyBhdCBhbnkg cG9pbnQgYWxvbmcgdGhlIEludGVybmV0DQogICAgPiA+ICAgICAgICAgcGF0aC4gIEluIG1hbnkg Y2FzZXMsIGl0IGlzIGltcG9ydGFudCB0byByZWxhdGUgb2JzZXJ2YXRpb25zIHRvDQogICAgPiA+ ICAgICAgICAgc3BlY2lmaWMgZXF1aXBtZW50L2NvbmZpZ3VyYXRpb25zIG9yIG5ldHdvcmsgc2Vn bWVudHMuDQogICAgPiA+DQogICAgPiA+ICAgICAgICAgQ29uY2VhbGluZyB0cmFuc3BvcnQgaGVh ZGVyIGluZm9ybWF0aW9uIG1ha2VzIHBlcmZvcm1hbmNlLw0KICAgID4gPiAgICAgICAgIGJlaGF2 aW91ciB1bmF2YWlsYWJsZSB0byBwYXNzaXZlIG9ic2VydmVycyBhbG9uZyB0aGUgcGF0aCwNCiAg ICA+DQogICAgPiBXaGlsZSBhbHNvIG1ha2luZyB0cmFmZmljIGFuYWx5c2lzIG1vcmUgZGlmZmlj dWx0Lg0KICAgID4NCiAgICA+DQogICAgPiBTIDIuMy4NCiAgICA+ID4gICAgICAgICBhcHBsaWNh dGlvbnMgaXQgaXMgaW1wb3J0YW50IHRvIHJlbGF0ZSBvYnNlcnZhdGlvbnMgdG8gc3BlY2lmaWMN CiAgICA+ID4gICAgICAgICBlcXVpcG1lbnQvY29uZmlndXJhdGlvbnMgb3IgcGFydGljdWxhciBu ZXR3b3JrIHNlZ21lbnRzLg0KICAgID4gPg0KICAgID4gPiAgICAgICAgIENvbmNlYWxpbmcgdHJh bnNwb3J0IGhlYWRlciBpbmZvcm1hdGlvbiBjYW4gbWFrZSBhbmFseXNpcyBoYXJkZXINCiAgICA+ ID4gICAgICAgICBvciBpbXBvc3NpYmxlLiAgVGhpcyBjb3VsZCBpbXBhY3QgdGhlIGFiaWxpdHkg Zm9yIGFuIG9wZXJhdG9yIHRvDQogICAgPiA+ICAgICAgICAgYW50aWNpcGF0ZSB0aGUgbmVlZCBm b3IgbmV0d29yayB1cGdyYWRlcyBhbmQgcm9sbC1vdXQuICBJdCBjYW4NCiAgICA+DQogICAgPiBP ciB0byByZWR1Y2UgdGhlIG9wcG9ydHVuaXRpZXMgZm9yIHRyYWZmaWMgZGlzY3JpbWluYXRpb24u DQogICAgPg0KICAgID4NCiAgICA+IFMgMi4zLg0KICAgID4gPg0KICAgID4gPiAgICAgIERpZmZl cmVudCBwYXJ0aWVzIHdpbGwgdmlldyB0aGUgcmVsYXRpdmUgaW1wb3J0YW5jZSBvZiB0aGVzZSBp c3N1ZXMNCiAgICA+ID4gICAgICBkaWZmZXJlbnRseS4gIEZvciBzb21lLCB0aGUgYmVuZWZpdHMg b2YgZW5jcnlwdGluZyBzb21lLCBvciBhbGwsIG9mDQogICAgPiA+ICAgICAgdGhlIHRyYW5zcG9y dCBoZWFkZXJzIG1heSBvdXR3ZWlnaCB0aGUgaW1wYWN0IG9mIGRvaW5nIHNvOyBvdGhlcnMNCiAg ICA+ID4gICAgICBtaWdodCBtYWtlIGEgZGlmZmVyZW50IHRyYWRlLW9mZi4gIFRoZSBwdXJwb3Nl IG9mIGhpZ2hsaWdodGluZyB0aGUNCiAgICA+ID4gICAgICB0cmFkZS1vZmZzIGlzIHRvIG1ha2Ug c3VjaCBhbmFseXNpcyBwb3NzaWJsZS4NCiAgICA+DQogICAgPiBUaGlzIHdob2xlIHNlY3Rpb24g c2VlbXMgdG8gcmVhbGx5IGp1c3QgaWdub3JlIHRoZSBmYWN0IHRoYXQgbWFueSBvZg0KICAgID4g dGhlc2UgcHJhY3RpY2VzIGFyZSB1bndhbnRlZC4NCiAgICA+DQogICAgPg0KICAgID4gUyAzLjEu DQogICAgPiA+ICAgICAgRmlyZXdhbGxzKS4gIENvbW1vbiBpc3N1ZXMgY29uY2VybmluZyBJUCBh ZGRyZXNzIHNoYXJpbmcgYXJlDQogICAgPiA+ICAgICAgZGVzY3JpYmVkIGluIFtSRkM2MjY5XS4N CiAgICA+ID4NCiAgICA+ID4gICAzLjEuICBPYnNlcnZpbmcgVHJhbnNwb3J0IEluZm9ybWF0aW9u IGluIHRoZSBOZXR3b3JrDQogICAgPiA+DQogICAgPiA+ICAgICAgSWYgaW4tbmV0d29yayBvYnNl cnZhdGlvbiBvZiB0cmFuc3BvcnQgcHJvdG9jb2wgaGVhZGVycyBpcyBuZWVkZWQsDQogICAgPg0K ICAgID4gV2h5IGlzIHRoaXMgbmVlZGVkPyBJIGtub3cgc29tZSBwZW9wbGUgbWlnaHQgd2FudCBp dC4NCiAgICA+DQogICAgPg0KICAgID4gUyAzLjEuMS4NCiAgICA+ID4gICAzLjEuMS4gIEZsb3cg SWRlbnRpZmljYXRpb24gVXNpbmcgVHJhbnNwb3J0IExheWVyIEhlYWRlcnMNCiAgICA+ID4NCiAg ICA+ID4gICAgICBGbG93IGlkZW50aWZpY2F0aW9uIGlzIGEgY29tbW9uIGZ1bmN0aW9uLiAgRm9y IGV4YW1wbGUsIHBlcmZvcm1lZCBieQ0KICAgID4gPiAgICAgIG1lYXN1cmVtZW50IGFjdGl2aXRp ZXMsIFFvUyBjbGFzc2lmaWNhdGlvbiwgZmlyZXdhbGxzLCBEZW5pYWwgb2YNCiAgICA+ID4gICAg ICBTZXJ2aWNlLCBET1MsIHByZXZlbnRpb24uICBUaGlzIGJlY29tZXMgbW9yZSBjb21wbGV4IGFu ZCBsZXNzIGVhc2lseQ0KICAgID4gPiAgICAgIGFjaGlldmVkIHdoZW4gbXVsdGlwbGV4aW5nIGlz IHVzZWQgYXQgb3IgYWJvdmUgdGhlIHRyYW5zcG9ydCBsYXllci4NCiAgICA+DQogICAgPiBBbHNv IHRyYWZmaWMgZGlzY3JpbWluYXRpb24gYW5kIGJsb2NraW5nLg0KICAgID4NCiAgICA+DQogICAg PiBTIDMuMS4xLg0KICAgID4gPiAgICAgIHVzZSBoZXVyaXN0aWNzIHRvIGluZmVyIHRoYXQgc2hv cnQgVURQIHBhY2tldHMgd2l0aCByZWd1bGFyIHNwYWNpbmcNCiAgICA+ID4gICAgICBjYXJyeSBh dWRpbyB0cmFmZmljLiAgT3BlcmF0aW9uYWwgcHJhY3RpY2VzIGFpbWVkIGF0IGluZmVycmluZw0K ICAgID4gPiAgICAgIHRyYW5zcG9ydCBwYXJhbWV0ZXJzIGFyZSBvdXQgb2Ygc2NvcGUgZm9yIHRo aXMgZG9jdW1lbnQsIGFuZCBhcmUgb25seQ0KICAgID4gPiAgICAgIG1lbnRpb25lZCBoZXJlIHRv IHJlY29nbml6ZSB0aGF0IGVuY3J5cHRpb24gZG9lcyBub3QgcHJldmVudA0KICAgID4gPiAgICAg IG9wZXJhdG9ycyBmcm9tIGF0dGVtcHRpbmcgdG8gYXBwbHkgcHJhY3RpY2VzIHRoYXQgd2VyZSB1 c2VkIHdpdGgNCiAgICA+ID4gICAgICB1bmVuY3J5cHRlZCB0cmFuc3BvcnQgaGVhZGVycy4NCiAg ICA+DQogICAgPiBUaGlzIGhhcyBhIHJlYWxseSB0aHJlYXRlbmluZyB0b25lLiBJZiB5b3UgZG9u J3QgZ2l2ZSB1cyB3aGF0IHdlIHdhbnQsDQogICAgPiBsb29rIHdoYXQgY291bGQgaGFwcGVuLg0K ICAgID4NCiAgICA+DQogICAgPiBTIDMuMS4yLg0KICAgID4gPg0KICAgID4gPiAgICAgIFRoaXMg aW5mb3JtYXRpb24gY2FuIHN1cHBvcnQgbmV0d29yayBvcGVyYXRpb25zLCBpbmZvcm0gY2FwYWNp dHkNCiAgICA+ID4gICAgICBwbGFubmluZywgYW5kIGFzc2lzdCBpbiBkZXRlcm1pbmluZyB0aGUg bmVlZCBmb3IgZXF1aXBtZW50IGFuZC9vcg0KICAgID4gPiAgICAgIGNvbmZpZ3VyYXRpb24gY2hh bmdlcyBieSBuZXR3b3JrIG9wZXJhdG9ycy4gIEl0IGNhbiBhbHNvIGluZm9ybQ0KICAgID4gPiAg ICAgIEludGVybmV0IGVuZ2luZWVyaW5nIGFjdGl2aXRpZXMgYnkgaW5mb3JtaW5nIHRoZSBkZXZl bG9wbWVudCBvZiBuZXcNCiAgICA+ID4gICAgICBwcm90b2NvbHMsIG1ldGhvZG9sb2dpZXMsIGFu ZCBwcm9jZWR1cmVzLg0KICAgID4NCiAgICA+IFdoYXQgaXMgdGhlIHBvaW50IG9mIHRoaXMgZXho YXVzdGl2ZSBsaXN0Pw0KICAgID4NCiAgICA+DQogICAgPiBTIDMuMS4zLg0KICAgID4gPg0KICAg ID4gPiAgICAgICAgIEFRTSBhbmQgRUNOIG9mZmVyIGEgcmFuZ2Ugb2YgYWxnb3JpdGhtcyBhbmQg Y29uZmlndXJhdGlvbiBvcHRpb25zLg0KICAgID4gPiAgICAgICAgIFRvb2xzIHRoZXJlZm9yZSBu ZWVkIHRvIGJlIGF2YWlsYWJsZSB0byBuZXR3b3JrIG9wZXJhdG9ycyBhbmQNCiAgICA+ID4gICAg ICAgICByZXNlYXJjaGVycyB0byB1bmRlcnN0YW5kIHRoZSBpbXBsaWNhdGlvbiBvZiBjb25maWd1 cmF0aW9uIGNob2ljZXMNCiAgICA+ID4gICAgICAgICBhbmQgdHJhbnNwb3J0IGJlaGF2aW91ciBh cyB0aGUgdXNlIG9mIEVDTiBpbmNyZWFzZXMgYW5kIG5ldw0KICAgID4gPiAgICAgICAgIG1ldGhv ZHMgZW1lcmdlIFtSRkM3NTY3XS4NCiAgICA+DQogICAgPiBRVUlDIHNvcnQgb2YgaGlkZXMgRUNO IGZlZWRiYWNrIGJ1dCBub3QgRUNOIG1hcmtpbmcuDQogICAgPg0KICAgID4NCiAgICA+IFMgMy4y LjQuDQogICAgPiA+DQogICAgPiA+ICAgICAgICAgQSBuZXR3b3JrIG9wZXJhdG9yIG5lZWRzIHRv b2xzIHRvIHVuZGVyc3RhbmQgaWYgZGF0YWdyYW0gZmxvd3MNCiAgICA+ID4gICAgICAgICAoZS5n LiwgdXNpbmcgVURQKSBjb21wbHkgd2l0aCBjb25nZXN0aW9uIGNvbnRyb2wgZXhwZWN0YXRpb25z IGFuZA0KICAgID4gPiAgICAgICAgIHRoZXJlZm9yZSB3aGV0aGVyIHRoZXJlIGlzIGEgbmVlZCB0 byBkZXBsb3kgbWV0aG9kcyBzdWNoIGFzIHJhdGUtDQogICAgPiA+ICAgICAgICAgbGltaXRlcnMs IHRyYW5zcG9ydCBjaXJjdWl0IGJyZWFrZXJzLCBvciBvdGhlciBtZXRob2RzIHRvIGVuZm9yY2UN CiAgICA+ID4gICAgICAgICBhY2NlcHRhYmxlIHVzYWdlIGZvciB0aGUgb2ZmZXJlZCBzZXJ2aWNl Lg0KICAgID4NCiAgICA+IERvZXMgaXQgKm5lZWQqIGl0IG9yIGRvZXMgaXQganVzdCB3YW50IGl0 LiBOb3RlIHRoYXQgd2UgaGF2ZSBoYWQgRFRMUy0NCiAgICA+IFNDVFAgd2l0aCBXZWJSVEMgd2l0 aG91dCB0aGlzIHByb3BlcnR5IGZvciBzb21lIHRpbWUgbm93LiBDYW4geW91IHByb3ZpZGUNCiAg ICA+IHNvbWUgZXZpZGVuY2UgdGhhdCBvcGVyYXRvcnMgaGF2ZSBiZWVuIGluY29udmVuaWVuY2Vk IGJ5IG5vdCBoYXZpbmcgaXQuDQogICAgPg0KICAgID4NCiAgICA+IFMgMy4zLg0KICAgID4gPiAg ICAgIG9wZXJhdG9ycyBicmluZyB0b2dldGhlciBoZXRlcm9nZW5lb3VzIHR5cGVzIG9mIG5ldHdv cmsgZXF1aXBtZW50IGFuZA0KICAgID4gPiAgICAgIHNlZWsgdG8gZGVwbG95IG9wcG9ydHVuaXN0 aWMgbWV0aG9kcyB0byBhY2Nlc3MgcmFkaW8gc3BlY3RydW0uDQogICAgPiA+DQogICAgPiA+ICAg ICAgQSBmbG93IHRoYXQgY29uY2VhbHMgaXRzIHRyYW5zcG9ydCBoZWFkZXIgaW5mb3JtYXRpb24g Y291bGQgaW1wbHkNCiAgICA+ID4gICAgICAiZG9uJ3QgdG91Y2giIHRvIHNvbWUgb3BlcmF0b3Jz LiAgVGhpcyBjb3VsZCBsaW1pdCBhIHRyb3VibGUtc2hvb3RpbmcNCiAgICA+ID4gICAgICByZXNw b25zZSB0byAiY2FuJ3QgaGVscCwgbm8gdHJvdWJsZSBmb3VuZCIuDQogICAgPg0KICAgID4gV2Ug aGF2ZSBxdWl0ZSBhIGJpdCBvZiBRVUlDIHRyYWZmaWMgbm93LiBJJ2QgYmUgaW50ZXJlc3RlZCBp biBoZWFyaW5nDQogICAgPiBmcm9tIHRoZSBnUVVJQyB0ZWFtIHdoZXRoZXIgdGhleSBoYXZlIHNl ZW4gYW55dGhpbmcgbGlrZSB0aGlzLg0KICAgIA0KICAgIFFVSUMgcHJlc2VudHMgYSBwcm9ibGVt IGluIGl0c2VsZiBzaW5jZSB0aGUgUVVJQyBoYXJkZXJzIGFyZSBpbnNpZGUNCiAgICB0aGUgVURQ IHBheWxvYWQgc28gaW50ZXJtZWRpYXRlIGRldmljZXMgZW5kIHVwIG5lZWRpbmcgdG8gcGFyc2Ug dGhlDQogICAgVURQIHRyYW5zcG9ydCBwYXlsb2FkLiBJIGJlbGlldmUgdGhlIG9ubHkgd2F5IHRv IGlkZW50aWZ5IGEgUVVJQw0KICAgIHBhY2tldCBpcyBieSBtYXRjaGluZyBwb3J0IG51bWJlcnMs IGJ1dCBwZXIgUkZDNzYwNSBpbnRlcnByZXRhdGlvbiBvZg0KICAgIHBvcnQgbnVtYmVycyBpbiB0 aGUgbWlkZGxlIG9mIHRoZSBuZXR3b3JrIGlzIHByb25lIHRvDQogICAgbWlzaW50ZXJwcmV0YXRp b24uIEV2ZW50dWFsbHksIHNvbWV0aGluZyB0aGF0IGxvb2tzIGxpa2UgYSBRVUlDIHBhY2tldA0K ICAgIGJhc2VkIG9uIHBvcnQgbnVtYmVyIHdpbGwgYmUgbWlzaW50ZXJwcmV0ZWQuIExvb2tpbmcg YXQNCiAgICBkcmFmdC1pZXRmLXF1aWMtdHJhbnNwb3J0LTIzLCBJIGRvbid0IHNlZSBhbnkgZGlz Y3Vzc2lvbiBhYm91dCB0aGlzIG9yDQogICAgcmVmZXJlbmNlIHRvIFJGQzc2MDUuIE5vdGUgdGhp cyBpcyB0cnVlIGZvciBhbnkgdXNlIGNhc2Ugb2YgVURQDQogICAgaW5jbHVkaW5nIHRyYW5zcG9y dCBsYXllciBvciBuZXR3b3JrIGxheWVyIGVuY2Fwc3VsYXRpb24uIEV2ZW4gaWYgdGhlDQogICAg YXJndW1lbnQgaXMgdGhhdCB0aGUgaW5mb3JtYXRpb24gaXMgb25seSBiZWluZyByZWFkIGFuZA0K ICAgIG1pc2ludGVycHJldGF0aW9uIGlzIGlubm9jdW91cywgaXQgc3RpbGwgd291bGRuJ3QgYmUg cm9idXN0IHByb3RvY29sLg0KICAgIFRoaXMgY2FuIGJlIGNvbnRyYXN0ZWQgdG8gcHV0dGluZyB0 aGUgaW5mb3JtYXRpb24gaW4gSEJIIG9wdGlvbnMgd2hpY2gNCiAgICBjYW4gYmUgY29ycmVjdGx5 IGFuZCB1bmFtYmlndW91c2x5IGlkZW50aWZpZWQgYW55d2hlcmUgaW4gdGhlIG5ldHdvcmsuDQog ICAgDQogICAgVG9tDQogICAgDQogICAgPg0KICAgID4NCiAgICA+IFMgNC4NCiAgICA+ID4NCiAg ICA+ID4gICAgICBUaGVyZSBhcmUgc2V2ZXJhbCBtb3RpdmF0aW9ucyBmb3IgZW5jcnlwdGlvbjoN CiAgICA+ID4NCiAgICA+ID4gICAgICBvICBPbmUgbW90aXZlIHRvIHVzZSBlbmNyeXB0aW9uIGlz IGEgcmVzcG9uc2UgdG8gcGVyY2VwdGlvbnMgdGhhdCB0aGUNCiAgICA+ID4gICAgICAgICBuZXR3 b3JrIGhhcyBiZWNvbWUgb3NzaWZpZWQgYnkgb3Zlci1yZWxpYW5jZSBvbiBtaWRkbGVib3hlcyB0 aGF0DQogICAgPiA+ICAgICAgICAgcHJldmVudCBuZXcgcHJvdG9jb2xzIGFuZCBtZWNoYW5pc21z IGZyb20gYmVpbmcgZGVwbG95ZWQuICBUaGlzDQogICAgPg0KICAgID4gVGhpcyBpc24ndCBqdXN0 IGEgcGVyY2VwdGlvbiwgaXQncyBhIGRlbW9uc3RyYWJsZSByZWFsaXR5Lg0KICAgID4NCiAgICA+ DQogICAgPiBTIDQuDQogICAgPiA+DQogICAgPiA+ICAgICAgbyAgT25lIG1vdGl2ZSB0byB1c2Ug ZW5jcnlwdGlvbiBpcyBhIHJlc3BvbnNlIHRvIHBlcmNlcHRpb25zIHRoYXQgdGhlDQogICAgPiA+ ICAgICAgICAgbmV0d29yayBoYXMgYmVjb21lIG9zc2lmaWVkIGJ5IG92ZXItcmVsaWFuY2Ugb24g bWlkZGxlYm94ZXMgdGhhdA0KICAgID4gPiAgICAgICAgIHByZXZlbnQgbmV3IHByb3RvY29scyBh bmQgbWVjaGFuaXNtcyBmcm9tIGJlaW5nIGRlcGxveWVkLiAgVGhpcw0KICAgID4gPiAgICAgICAg IGhhcyBsZWFkIHRvIGEgcGVyY2VwdGlvbiB0aGF0IHRoZXJlIGlzIHRvbyBtdWNoICJtYW5pcHVs YXRpb24iIG9mDQogICAgPiA+ICAgICAgICAgcHJvdG9jb2wgaGVhZGVycyB3aXRoaW4gdGhlIG5l dHdvcmssIGFuZCB0aGF0IGRlc2lnbmluZyB0byBkZXBsb3kNCiAgICA+DQogICAgPiBOb3QganVz dCBtYW5pcHVsYXRpb24sIGFsc28gaW5zcGVjdGlvbi4NCiAgICA+DQogICAgPg0KICAgID4gUyA0 Lg0KICAgID4gPg0KICAgID4gPiAgICAgICAgIE9uZSBleGFtcGxlIG9mIGVuY3J5cHRpb24gYXQg dGhlIG5ldHdvcmsgbGF5ZXIgaXMgdGhlIHVzZSBvZiBJUHNlYw0KICAgID4gPiAgICAgICAgIEVu Y2Fwc3VsYXRpbmcgU2VjdXJpdHkgUGF5bG9hZCAoRVNQKSBbUkZDNDMwM10gaW4gdHVubmVsIG1v ZGUuDQogICAgPiA+ICAgICAgICAgVGhpcyBlbmNyeXB0cyBhbmQgYXV0aGVudGljYXRlcyBhbGwg dHJhbnNwb3J0IGhlYWRlcnMsIHByZXZlbnRpbmcNCiAgICA+ID4gICAgICAgICB2aXNpYmlsaXR5 IG9mIHRoZSB0cmFuc3BvcnQgaGVhZGVycyBieSBpbi1uZXR3b3JrIGRldmljZXMuICBTb21lDQog ICAgPiA+ICAgICAgICAgVlBOIG1ldGhvZHMgYWxzbyBlbmNyeXB0IHRoZXNlIGhlYWRlcnMuDQog ICAgPg0KICAgID4gVGhpcyBzZWVtcyBsaWtlIGEgYmFkIGV4YW1wbGUgYXMgcGFydCBvZiB0aGUg cG9pbnQgb2YgYSBWUE4gaXMgdG8NCiAgICA+IGNvbmNlYWwgdGhlIGhlYWRlcnMgZm9ybSB0aGUg bmV0d29yay4NCiAgICA+DQogICAgPg0KICAgID4gUyA2LjEuDQogICAgPiA+DQogICAgPiA+ICAg Ni4xLiAgSW5kZXBlbmRlbnQgTWVhc3VyZW1lbnQNCiAgICA+ID4NCiAgICA+ID4gICAgICBJbmRl cGVuZGVudCBvYnNlcnZhdGlvbiBieSBtdWx0aXBsZSBhY3RvcnMgaXMgaW1wb3J0YW50IGlmIHRo ZQ0KICAgID4gPiAgICAgIHRyYW5zcG9ydCBjb21tdW5pdHkgaXMgdG8gbWFpbnRhaW4gYW4gYWNj dXJhdGUgdW5kZXJzdGFuZGluZyBvZiB0aGUNCiAgICA+ID4gICAgICBuZXR3b3JrLiAgRW5jcnlw dGluZyB0cmFuc3BvcnQgaGVhZGVyIGVuY3J5cHRpb24gY2hhbmdlcyB0aGUgYWJpbGl0eQ0KICAg ID4NCiAgICA+IFRoaXMgaXMgaXJvbmljIGJlY2F1c2UgUVVJQyBpcyBtdWNoIGJldHRlciBmb3Ig ZW5kcG9pbnQgbWVhc3VyZW1lbnQNCiAgICA+IHRoYW4gVENQIGJlY2F1c2UgdGhlIGRldGFpbHMg YXJlIGFjY2Vzc2libGUgYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyLg0KICAgID4NCiAgICA+DQog ICAgPiBTIDguDQogICAgPiA+ICAgICAgZXhhbXBsZSwgYW4gYXR0YWNrZXIgY291bGQgY29uc3Ry dWN0IGEgRE9TIGF0dGFjayBieSBzZW5kaW5nIHBhY2tldHMNCiAgICA+ID4gICAgICB3aXRoIGEg c2VxdWVuY2UgbnVtYmVyIHRoYXQgZmFsbHMgd2l0aGluIHRoZSBjdXJyZW50bHkgYWNjZXB0ZWQg cmFuZ2UNCiAgICA+ID4gICAgICBvZiBzZXF1ZW5jZSBudW1iZXJzIGF0IHRoZSByZWNlaXZpbmcg ZW5kcG9pbnQsIHRoaXMgd291bGQgdGhlbg0KICAgID4gPiAgICAgIGludHJvZHVjZSBhZGRpdGlv bmFsIHdvcmsgYXQgdGhlIHJlY2VpdmluZyBlbmRwb2ludCwgZXZlbiB0aG91Z2ggdGhlDQogICAg PiA+ICAgICAgZGF0YSBpbiB0aGUgYXR0YWNraW5nIHBhY2tldCBtYXkgbm90IGZpbmFsbHkgYmUg ZGVsaXZlcmVkIGJ5IHRoZQ0KICAgID4gPiAgICAgIHRyYW5zcG9ydCBsYXllci4gIFRoaXMgaXMg c29tZXRpbWVzIGtub3duIGFzIGEgInNoYWRvd2luZyBhdHRhY2siLg0KICAgID4NCiAgICA+IFRo aXMgZG9lc24ndCBzZWVtIHRvIGJlIGFuIGlzc3VlIHdpdGggcHJvdG9jb2xzIHRoYXQgYXV0aGVu dGljYXRlIHRoZSBTTi4NCiAgICA+DQogICAgPg0KICAgID4gUyA4Lg0KICAgID4gPg0KICAgID4g PiAgICAgIEFuIGF0dGFjayBjYW4sIGZvciBleGFtcGxlLCBkaXNydXB0IHJlY2VpdmVyIHByb2Nl c3NpbmcsIHRyaWdnZXIgbG9zcw0KICAgID4gPiAgICAgIGFuZCByZXRyYW5zbWlzc2lvbiwgb3Ig bWFrZSBhIHJlY2VpdmluZyBlbmRwb2ludCBwZXJmb3JtIHVucHJvZHVjdGl2ZQ0KICAgID4gPiAg ICAgIGRlY3J5cHRpb24gb2YgcGFja2V0cyB0aGF0IGNhbm5vdCBiZSBzdWNjZXNzZnVsbHkgZGVj cnlwdGVkIChmb3JjaW5nDQogICAgPiA+ICAgICAgYSByZWNlaXZlciB0byBjb21taXQgZGVjcnlw dGlvbiByZXNvdXJjZXMsIG9yIHRvIHVwZGF0ZSBhbmQgdGhlbg0KICAgID4gPiAgICAgIHJlc3Rv cmUgcHJvdG9jb2wgc3RhdGUpLg0KICAgID4NCiAgICA+IFRoaXMgaXMgbm90IGEgcmVhbCBpc3N1 ZSBmb3IgUVVJQyBvciBzaW1pbGFyIHByb3RvY29scw0KICAgID4NCiAgICA+DQogICAgPg0KICAg ID4NCiAgICA+DQogICAgPg0KICAgID4NCiAgICA+DQogICAgPg0KICAgID4NCiAgICA+DQogICAg Pg0KICAgID4NCiAgICA+DQogICAgPg0KICAgID4NCiAgICANCiAgICANCg0K From nobody Mon Nov 4 01:26:58 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36928120E0C; Mon, 4 Nov 2019 01:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOeoUlBeSeTu; Mon, 4 Nov 2019 01:26:45 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70050.outbound.protection.outlook.com [40.107.7.50]) (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 C75D8120D84; Mon, 4 Nov 2019 01:26:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FS8m6hcuTOQckae/3N3PywYXnSmFbRixdJ1dbR4uiHJ5qIhKYWF2o/RXvoMbcZ/QzbFebLrGW8I3gxlyRPamaMJ1+35ohPpI0I2WxZBYcjhyKQ1YoLHa+m0SikwAne7dTjlZIYb95RNnCBT6WK0gVN1gv6r0z49iwRdYuoCB/XfDtqhTLZg518X86pq/Wy8/DU458rPNSBKp+bl6JBD5YeNBmQZ8DNNbQ1mhp40i2/25+QaG7773OTj9tq0BLwzzQaf4fEBg5l8rYRst1UydbK+K4c2MNROYFdMJeKTWGC4hHG1w5lgr6bJcLViQyDXwI1yEuBFncRjrXimIRLn6rA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Abqr31sxdIjCQXuo0xrv3BmReiTFNAMatV60L4Oeh58=; b=YifavFvaL8m9XdGppnQhKvBGFiH9FYTAIrlcW/khZobSEW6402MuxPb0iQYrPrUTGiwd2F5zduSUyGJluSDLzkmgtiHz5M/rwlAxmsz8e1+LVaU8EcLuDlxaTkW1w1lSzw/pUq+0obOeZ3MdBGQSwT3JU4mDFBHjwMflgBRRoIWZdK6RVTIvPEBA2zYymn/HYcvgq6S8ya3mtaoy6hb9jGiQ1vIpOHvq0lCSJ+FrXE1kn/x1PnuBH3xMtJdB68A/8iZ9drPVyv4on/bxJREgf9JNnbWD0phpUFed9bNACkj+DqNKuf5isLhyOUqRUZCezMvYLRwKfn8mhFD8zyjuVA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Abqr31sxdIjCQXuo0xrv3BmReiTFNAMatV60L4Oeh58=; b=MtJlAev3Xo327GeScJQ5ywUiKAGgopcdyM2qnxDfae57yQ6wsw6lAOX6sPI25mxpjezwrJF3GNUpwBvouiYyhkRb3DiST2BZoWzEWcmSFGUOxt8aP6GSomCQ1P5blhIdsH6uYpuXj1N9DUYpntAVRo8tAn3puE9yVpV93koUY+w= Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB6387.eurprd07.prod.outlook.com (10.186.174.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Mon, 4 Nov 2019 09:26:42 +0000 Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4189:4ef8:bfc1:ec58]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4189:4ef8:bfc1:ec58%7]) with mapi id 15.20.2430.013; Mon, 4 Nov 2019 09:26:42 +0000 From: Mirja Kuehlewind To: Bernard Aboba , Eric Rescorla CC: tsvwg IETF list , "saag@ietf.org" Thread-Topic: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt Thread-Index: AQHVkqR0wv1Qw/jFZk2hvgC12JMRqqd6z2cA Date: Mon, 4 Nov 2019 09:26:41 +0000 Message-ID: References: <6E8A313A-2A3B-45D1-813C-029F90BA624B@gmail.com> In-Reply-To: <6E8A313A-2A3B-45D1-813C-029F90BA624B@gmail.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mirja.kuehlewind@ericsson.com; x-originating-ip: [2003:eb:4700:cf00:3d57:7e7e:af67:8db2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 98419dd2-cff7-4e8e-ec47-08d761091a5c x-ms-traffictypediagnostic: AM0PR07MB6387: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(396003)(136003)(346002)(39860400002)(199004)(189003)(53754006)(478600001)(8936002)(86362001)(6246003)(44832011)(33656002)(6306002)(6512007)(102836004)(110136005)(81166006)(81156014)(8676002)(2906002)(316002)(30864003)(66574012)(486006)(5660300002)(186003)(6436002)(25786009)(6116002)(305945005)(7736002)(256004)(2616005)(54906003)(229853002)(6486002)(14454004)(14444005)(66946007)(66446008)(446003)(966005)(66556008)(66476007)(46003)(64756008)(71190400001)(71200400001)(76116006)(76176011)(11346002)(99286004)(476003)(6506007)(53546011)(4326008)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB6387; H:AM0PR07MB4691.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: o7L6UmDesSoKchnh8IBWuQ6cEycjCP3E+mgdUXSI1bdWZW0rT9IApOR36JFC0Wz7FI8qglKAq7Jbay9qHwwtDX2F//CZaq2v9OYDK8KzR10SLS8YUFlK8O63NQliI4bM3CcXdt0Tlo2BnTQnxrin0rQt466LpPfQpzsXwHaalsjRtWQIxf5eKpmFv/ow7+eD38JCx4YFvFLA8rEBowZPR/Cm1ZxM2oQ18otbKsXPdsSA5s/6H5t2kJpZYnS53KQrZXT2KzqMXaIRbcxIoECyexrVL6D2iCVz7+zdw1ZEkaGU3BIfRvcpnLOi4UFbOv0dl2TmkTRyZgQbiSMcsX0dJSeT6AtYNKioIncXZKwEx2xQHTc11LgWufcfoaZoVU++E8pK/tYXEs4Ur2fvhaQUVKQPC//7NeU9UT1YDmqSq1xQb/kPBlqObwGWmnDPodSZM7Hue8NaqgWEJ9vA8EfgW/Gh92w+RFW3k0P1eP2U+zI= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <4828ABCB23F34346B58242DB69A1CE9B@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 98419dd2-cff7-4e8e-ec47-08d761091a5c X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2019 09:26:42.0552 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: VQ0+XOhBKY8slJ7DdCPk8gYnXYsG0oG3VXZUOZXeOmBexcV3PjMPhjhKUp+mgils4DV6oHm/U3mm3RHjXQjpu43q0YXvCjfo3cyvX27Kgc0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6387 Archived-At: Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 09:26:53 -0000 SGkgQmVybmFyZCwgaGkgYWxsLA0KDQpwbGVhc2Ugc2VlIGJlbG93LCBtYXJrZWQgd2l0aCBbTUtd Lg0KDQpNaXJqYQ0KDQrvu79PbiAwNC4xMS4xOSwgMDE6MTEsICJ0c3Z3ZyBvbiBiZWhhbGYgb2Yg QmVybmFyZCBBYm9iYSIgPHRzdndnLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGJlcm5h cmQuYWJvYmFAZ21haWwuY29tPiB3cm90ZToNCg0KICAgIFRoaXMgZG9jdW1lbnQgYXBwZWFycyB0 byBoYXZlIGEgKmxvdCogb2Ygb3ZlcmxhcCB3aXRoIFJGQyA4NDA0LiBTbyBnaXZlbiB0aGF0IHRo ZSBiYXNpYyBwb2ludCBoYXMgYWxyZWFkeSBiZWVuIG1hZGUsIGl0IHNlZW1zIHRvIG1lIHRoYXQg dGhpcyBkb2N1bWVudCBuZWVkcyB0byBmb2N1cyBvbiBuZXcgcG9pbnRzIGFuZC9vciBwcmFjdGlj YWwgcmVjb21tZW5kYXRpb25zIHRvIG1ha2UgaXRzIHB1YmxpY2F0aW9uIHdvcnRod2hpbGUuDQog ICAgDQogICAgVGhlIGlzc3VlcyByYWlzZWQgaGVyZSBhcmUgYnkgbm8gbWVhbnMgbmV3IC0gdGhl eSBmaXJzdCBhcm9zZSB3aXRoIHRoZSBpbnRyb2R1Y3Rpb24gb2YgSVBzZWMuIEVuZHBvaW50IG1v bml0b3JpbmcgbWFrZXMgaXQgcG9zc2libGUgZm9yIGVuZHBvaW50IG93bmVycyB0byBjb2xsZWN0 IGluZm9ybWF0aW9uIG9uIHBlcmZvcm1hbmNlIHRoYXQgdGhleSBjYW4gY2hvb3NlIHRvIHNoYXJl IHdpdGggb3BlcmF0b3JzLiANCg0KW01LXSBZZXMsIHRoZXNlIGlzc3VlcyBhcmUgbm90IG5ldyBi dXQgdGhhdCBtYWtlcyBpdCBldmVuIG1vcmUgaW1wb3J0YW50IHRvIGRvY3VtZW50IHRoZW0gaW4g YSB3ZWxsIHdyaXR0ZW4gUkZDLCBzbyB3ZSBoYXZlIGEgY29tbW9uIGJhc2lzIGZvciBhbnkgZnVy dGhlciBkaXNjdXNzaW9uLiBSRkM4NDA0IHRvdWNoZXMgdGhlc2UgcG9pbnRzIGJ1dCBhbHNvIG90 aGVycy4gVGhpcyBkb2N1bWVudCBoYXMgYSBtb3JlIG5hcnJvdyBmb2N1cyBhbmQgZ2l2ZXMgbW9y ZSBkZXRhaWwgd2hpY2ggSSB0aGluayBpcyB2YWx1YWJsZSBmb3IgZnV0dXJlIGRpc2N1c3Npb24g YW5kIHRoZXJlZm9yZSBJIHN1cHBvcnQgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4NCiAg ICANCiAgICBUaHVzIHRoZSBpc3N1ZSBoZXJlIGlzIG5vdCByZWFsbHkgdGhlIGxvc3Mgb2YgdHJh bnNwb3J0IHBlcmZvcm1hbmNlIGluZm9ybWF0aW9uIHNpbmNlIHRoYXQgcmVtYWlucyBhdmFpbGFi bGUgaWYgY29uc2VudCBjYW4gYmUgb2J0YWluZWQsIGJ1dCByYXRoZXIgdGhlIGNvbGxlY3Rpb24g b2YgdGhhdCBpbmZvcm1hdGlvbiBieSB1bmF1dGhvcml6ZWQgdGhpcmQgcGFydGllcy4NCg0KW01L XSBUaGUgaXNzdWUgaGVyZSBJUyBsb3NzIG9mIHZpc2libHkuIFllcyBpdCdzIG5vdCBncmVhdCB0 aGF0IHdlIGhhdmUgYWxsIHRoZSBtZWNoYW5pc21zIGluIHRoZSBuZXR3b3JrIG5vdyB0aGF0IHVz ZSB0aGUgaW5mb3JtYXRpb24gdGhhdCB3ZXJlIG5vdCBzdXBwb3NlZCB0byBiZSB1c2VkIGJ5IHRo ZSBuZXR3b3JrLiBIb3dldmVyLCB3ZSBjYW4ndCBkZW55IHRoYXQgaWYgd2UgY2hhbmdlIHRoZSBl bmQtdG8tZW5kIHByb3RvY29sIHRoYXQgdGhpcyB3aWxsIGhhdmUgYW4gaW1wYWN0IG9uIHRoZSBu ZXR3b3JrIGFuZCBob3cgd2UgbWFuZ2UgbmV0d29ya3MgdG9kYXkuIEluIHNvbWUgY2FzZXMgd2Ug Y2FuIGJlIGhhcHB5IHRoYXQgc29tZSBvZiB0aGUgYm94ZXMgd2lsbCBqdXN0IGdvIGF3YXkgYnV0 IGluIG90aGVyIGNhc2UgdGhpcyBjYW4gY2F1c2UgcHJvYmxlbXMgYW5kIGNhbiBub3RpY2VhYmx5 IGltcGFjdCBlbmQtdG8tZW5kIHBlcmZvcm1hbmNlLCBlLmcuIHdoZW4gYW4gb3BlcmF0b3IgaXMg bm90IGFibGUgdG8gcXVpY2tseSBsb2NhdGUgdGhlIHJvb3QgY2F1c2Ugb2YgYSBwcm9ibGVtIGFu eW1vcmUuDQoNCltNS10gUHJvdmlkaW5nIGVxdWl2YWxlbnQgaW5mb3JtYXRpb24gYmFzZWQgb24g Y29uc2VudCBpcyB0aGUgc29sdXRpb24gdG8gdGhlIHByb2JsZW0gZGVzY3JpYmVkIGluIHRoaXMg ZHJhZnQgYW5kIHNvbWV0aGluZyB3ZSBzaG91bGQgYmUgd29ya2luZyBvbiBidXQgaXMgbm90IHRo ZXJlIHlldC4NCg0KW01LXSBDb2xsZWN0aW9uIG9mIGluZm9ybWF0aW9uIGJ5IHVuYXV0aG9yaXpl ZCB0aGlyZCBwYXJ0eSBpcyBhbm90aGVyIHByb2JsZW0gd2hpY2ggc3RpbGwgZXhpc3RzIGFuZCBp cyBub3cganVzdCBzaGlmdGVkIHRvIGFub3RoZXIgbGF5ZXIgYnV0IHdvdWxkIGZvciBzdXJlIG5l ZWQgYW5vdGhlciBkcmFmdCAob3IgbXVsdGlwbGUgb25lcykuDQoNCiAgICANCiAgICA+IE9uIE5v diAzLCAyMDE5LCBhdCAyOjIwIFBNLCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+IHdyb3Rl Og0KICAgID4gDQogICAgPiANCiAgICA+IEFmdGVyIHJldmlld2luZyB0aGlzIGRvY3VtZW50LCBJ IHNoYXJlIENocmlzdGlhbiBIdWl0ZW1hJ3MgY29uY2Vybg0KICAgID4gYWJvdXQgdGhlIHRvbmUg YW5kIHBlcnNwZWN0aXZlIG9mIHRoaXMgZG9jdW1lbnQsIHdoaWNoLCB3aGlsZSBzYXlpbmcNCiAg ICA+IHRoYXQgZW5jcnlwdGlvbiBpcyBnb29kLCB0aGVuIHByb2NlZWRzIHRvIG1vc3RseSBsYW1l bnQgaG93IGRpZmZpY3VsdA0KICAgID4gaXQgbWFrZXMgbGlmZSBmb3IgdmFyaW91cyBlbnRpdGll cyBvdGhlciB0aGFuIHRoZSBlbmRwb2ludHMuIEl0IHNlZW1zDQogICAgPiB0byBtZSByYXRoZXIg cHJvYmxlbWF0aWMgdG8gcHVibGlzaCB0aGlzIGRvY3VtZW50IGFzIGFuIFJGQyBmb3INCiAgICA+ IHNldmVyYWwgcmVhc29uczoNCiAgICA+IA0KICAgID4gLSBZZXMsIGl0J3MgdHJ1ZSB0aGF0IHRo ZSB0cmVuZCB0b3dhcmRzIGVuY3J5cHRpbmcgZXZlcnl0aGluZyBoYXMNCiAgICA+ICAgYW5kIGNv bnRpbnVlcyB0byBtYWtlIGEgbnVtYmVyIG9mIGVudGl0aWVzIHNhZCwgYnV0IHRoYXQncyBhIHBv aW50DQogICAgPiAgIHdoaWNoIGlzIGFscmVhZHkgbWFkZSBpbiBSRkMgODQwNC4gSG93IGRvZXMg YWxsIG9mIHRoZSBhZGRpdGlvbmFsDQogICAgPiAgIGRldGFpbCBoZXJlIGhlbHA/DQogICAgPiAN CiAgICA+IC0gVGhlIGNvbW11bml0eSBvZiBwZW9wbGUgZGVzaWduaW5nIG5ldyB0cmFuc3BvcnQg cHJvdG9jb2xzIGhhcw0KICAgID4gICBhbHJlYWR5IHdlaWdoZWQgYWxsIHRoZSBjb25zaWRlcmF0 aW9ucyBoZXJlIGFuZCBjb21lIGRvd24gcHJldHR5DQogICAgPiAgIGRlY2lzaXZlbHkgb24gdGhl IHNpZGUgb2YgImVuY3J5cHQgYWxsIHRoZSB0aGluZ3MiLiBHaXZlbiB0aGF0DQogICAgPiAgIGJv dGggU0NUUC1vdmVyLURUTFMgYW5kIFFVSUMgZG8gdGhpcywgaXQgc2VlbXMgcHJldHR5IHVubGlr ZWx5DQogICAgPiAgIHdlJ3JlIGdvaW5nIHRvIGRlc2lnbiBhIG5ldyB0cmFuc3BvcnQgcHJvdG9j b2wgdGhhdCBkb2Vzbid0Lg0KICAgID4gDQogICAgPiAtIEhhdmluZyBhbiBJRVRGIENvbnNlbnN1 cyBSRkMgdGhhdCBpcyBzbyBoZWF2aWx5IHdlaWdodGVkIG9uIHRoZSBzaWRlDQogICAgPiAgIG9m ICJ0aGlzIGlzIGhvdyBlbmNyeXB0aW9uIGluY29udmVuaWVuY2VzIHVzIiBhbmQgc28gbGlnaHQg b24gInRoZXNlDQogICAgPiAgIGFyZSB0aGUgYXR0YWNrcyB3ZSBhcmUgcHJldmVudGluZyIgZ2l2 ZXMgYSBtaXNsZWFkaW5nIHBpY3R1cmUgb2YgdGhlDQogICAgPiAgIElFVEYgY29tbXVuaXR5J3Mg dmlldyBvZiB0aGUgcmVsYXRpdmUgcHJpb3JpdHkgb2YgdGhlc2UNCiAgICA+ICAgY29uY2VybnMu IElTVE0gdGhhdCBSRkMgODU1OCAtLSB0aG91Z2ggcGVyaGFwcyBpbXBlcmZlY3QgLS0gZmFyIG1v cmUNCiAgICA+ICAgY2xvc2VseSByZWZsZWN0cyB0aGF0IGNvbnNlbnN1cy4NCiAgICA+IA0KICAg ID4gSW4gc2hvcnQsIEkgZG8gbm90IHRoaW5rIHRoaXMgZHJhZnQgc2hvdWxkIGJlIHB1Ymxpc2hl ZCBhcyBhbiBSRkMuDQogICAgPiANCiAgICA+IEkgaGF2ZSBhcHBlbmRlZCBhIG51bWJlciBvZiBk ZXRhaWxlZCBjb21tZW50cyB3aGljaCBJTU8gbmVlZCB0byBiZQ0KICAgID4gYWRkcmVzc2VkIGlu IGFueSBjYXNlLCBidXQgZXZlbiBpZiB0aGV5IHdlcmUgcmVzb2x2ZWQsIHRoYXQgd291bGQgbm90 DQogICAgPiBhZGRyZXNzIG15IHByaW1hcnkgY29uY2Vybi4NCiAgICA+IA0KICAgID4gDQogICAg PiBDT01NRU5UUw0KICAgID4gUyAyLjEuDQogICAgPiA+ICAgMi4xLiAgVXNlIG9mIFRyYW5zcG9y dCBIZWFkZXIgSW5mb3JtYXRpb24gaW4gdGhlIE5ldHdvcmsNCiAgICA+ID4gICANCiAgICA+ID4g ICAgICBJbi1uZXR3b3JrIG1lYXN1cmVtZW50IG9mIHRyYW5zcG9ydCBmbG93IGNoYXJhY3Rlcmlz dGljcyBjYW4gYmUgdXNlZA0KICAgID4gPiAgICAgIHRvIGVuaGFuY2UgcGVyZm9ybWFuY2UsIGFu ZCBjb250cm9sIGNvc3QgYW5kIHNlcnZpY2UgcmVsaWFiaWxpdHkuDQogICAgPiA+ICAgICAgU29t ZSBvcGVyYXRvcnMgaGF2ZSBkZXBsb3llZCBmdW5jdGlvbmFsaXR5IGluIG1pZGRsZWJveGVzIHRv IGJvdGgNCiAgICA+ID4gICAgICBzdXBwb3J0IG5ldHdvcmsgb3BlcmF0aW9ucyBhbmQgZW5oYW5j ZSBwZXJmb3JtYW5jZS4gIFRoaXMgcmVsaWFuY2Ugb24NCiAgICA+IA0KICAgID4gVGhpcyBzZWVt cyBsaWtlIGEgY29udGVzdGVkIHBvaW50LiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgd2hpbGUN CiAgICA+IHRoZXNlIG1pZGRsZWJveGVzIGFyZSAqaW50ZW5kZWQqIHRvIGVuaGFuY2UgcGVyZm9y bWFuY2UgdGhhdCB0aGVyZSBpcw0KICAgID4gZG91YnQgdGhhdCB0aGV5IGFjdHVhbGx5IGRvLg0K ICAgID4gDQogICAgPiANCiAgICA+IFMgMi4xLg0KICAgID4gPiAgICAgIHRvIGVuaGFuY2UgcGVy Zm9ybWFuY2UsIGFuZCBjb250cm9sIGNvc3QgYW5kIHNlcnZpY2UgcmVsaWFiaWxpdHkuDQogICAg PiA+ICAgICAgU29tZSBvcGVyYXRvcnMgaGF2ZSBkZXBsb3llZCBmdW5jdGlvbmFsaXR5IGluIG1p ZGRsZWJveGVzIHRvIGJvdGgNCiAgICA+ID4gICAgICBzdXBwb3J0IG5ldHdvcmsgb3BlcmF0aW9u cyBhbmQgZW5oYW5jZSBwZXJmb3JtYW5jZS4gIFRoaXMgcmVsaWFuY2Ugb24NCiAgICA+ID4gICAg ICB0aGUgcHJlc2VuY2UgYW5kIHNlbWFudGljcyBvZiBzcGVjaWZpYyBoZWFkZXIgaW5mb3JtYXRp b24gbGVhZHMgdG8NCiAgICA+ID4gICAgICBvc3NpZmljYXRpb24sIHdoZXJlIGFuIGVuZHBvaW50 IGNvdWxkIGJlIHJlcXVpcmVkIHRvIHN1cHBseSBhDQogICAgPiA+ICAgICAgc3BlY2lmaWMgaGVh ZGVyIHRvIHJlY2VpdmUgdGhlIG5ldHdvcmsgc2VydmljZSB0aGF0IGl0IGRlc2lyZXMuICBJbg0K ICAgID4gDQogICAgPiBXZWxsLCBub3QganVzdCB0aGUgbmV0d29yayBzZXJ2aWNlIGl0IGRlc2ly ZXMgYnV0ICphbnkqIHNlcnZpY2UuDQogICAgPiANCiAgICA+IA0KICAgID4gUyAyLjEuDQogICAg PiA+ICAgICAgc3BlY2lmaWMgaGVhZGVyIHRvIHJlY2VpdmUgdGhlIG5ldHdvcmsgc2VydmljZSB0 aGF0IGl0IGRlc2lyZXMuICBJbg0KICAgID4gPiAgICAgIHNvbWUgY2FzZXMsIHRoaXMgY291bGQg YmUgYmVuaWduIG9yIGFkdmFudGFnZW91cyB0byB0aGUgcHJvdG9jb2wNCiAgICA+ID4gICAgICAo ZS5nLiwgcmVjb2duaXNpbmcgdGhlIHN0YXJ0IG9mIGEgY29ubmVjdGlvbiwgb3IgZXhwbGljaXRs eSBleHBvc2luZw0KICAgID4gPiAgICAgIHByb3RvY29sIGluZm9ybWF0aW9uIGNhbiBiZSBleHBl Y3RlZCB0byBwcm92aWRlIG1vcmUgY29uc2lzdGVudA0KICAgID4gPiAgICAgIGRlY2lzaW9ucyBi eSBvbi1wYXRoIGRldmljZXMgdGhhbiB0aGUgdXNlIG9mIGRpdmVyc2UgbWV0aG9kcyB0byBpbmZl cg0KICAgID4gPiAgICAgIHNlbWFudGljcyBmcm9tIG90aGVyIGZsb3cgcHJvcGVydGllcykuICBJ biBvdGhlciBjYXNlcywgdGhlDQogICAgPiANCiAgICA+IElzIHRoZXJlIGV2aWRlbmNlIG9mIHRo aXM/DQogICAgPiANCiAgICA+IA0KICAgID4gUyAyLjEuDQogICAgPiA+ICAgDQogICAgPiA+ICAg ICAgQXMgYW4gZXhhbXBsZSBvZiBvc3NpZmljYXRpb24sIGNvbnNpZGVyIHRoZSBleHBlcmllbmNl IG9mIGRldmVsb3BpbmcNCiAgICA+ID4gICAgICBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKFRM UykgMS4zIFtSRkM4NDQ2XS4gIFRoaXMgcmVxdWlyZWQgYSBkZXNpZ24NCiAgICA+ID4gICAgICB0 aGF0IHJlY29nbmlzZWQgdGhhdCBkZXBsb3llZCBtaWRkbGVib3hlcyByZWxpZWQgb24gdGhlIHBy ZXNlbmNlIG9mDQogICAgPiA+ICAgICAgY2VydGFpbiBoZWFkZXIgZmlsZWQgZXhwb3NlZCBpbiBU TFMgMS4yLCBhbmQgZmFpbGVkIGlmIHRob3NlIGhlYWRlcnMNCiAgICA+ID4gICAgICB3ZXJlIGNo YW5nZWQuICBPdGhlciBleGFtcGxlcyBvZiB0aGUgaW1wYWN0IG9mIG9zc2lmaWNhdGlvbiBjYW4g YmUNCiAgICA+IA0KICAgID4gSSB0aGluayB5b3UgbWVhbiAiZmllbGRzIiBhbmQgaXQgd2Fzbid0 IGhlYWRlcnMgc28gbXVjaCBhcyBoYW5kc2hha2UNCiAgICA+IGRhdGEuDQogICAgPiANCiAgICA+ IA0KICAgID4gUyAyLjIuDQogICAgPiA+ICAgICAgVGhpcyBzdXBwb3J0cyB1c2Ugb2YgdGhpcyBp bmZvcm1hdGlvbiBieSBvbi1wYXRoIGRldmljZXMsIGJ1dCBhdCB0aGUNCiAgICA+ID4gICAgICBz YW1lIHRpbWUgY2FuIGJlIGV4cGVjdGVkIHRvIGxlYWQgdG8gb3NzaWZpY2F0aW9uIG9mIHRoZSB0 cmFuc3BvcnQNCiAgICA+ID4gICAgICBoZWFkZXIsIGJlY2F1c2UgbmV0d29yayBmb3J3YXJkaW5n IGNvdWxkIGV2b2x2ZSB0byBkZXBlbmQgb24gdGhlDQogICAgPiA+ICAgICAgcHJlc2VuY2UgYW5k L29yIHZhbHVlIG9mIHRoZXNlIGZpZWxkcy4gIFRvIGF2b2lkIHVud2FudGVkIGluc3BlY3Rpb24s DQogICAgPiA+ICAgICAgYSBwcm90b2NvbCBjb3VsZCBpbnRlbnRpb25hbGx5IHZhcnkgdGhlIGZv cm1hdCBvciB2YWx1ZSBvZiBleHBvc2VkDQogICAgPiA+ICAgICAgaGVhZGVyIGZpZWxkcyBbSS1E LmlldGYtdGxzLWdyZWFzZV0uDQogICAgPiANCiAgICA+IEl0J3Mgbm90IGp1c3QgYSBtYXR0ZXIg b2YgdW53YW50ZWQgaW5zcGVjdGlvbi4gVGhlcmUncyBhIHJlYWwgcXVlc3Rpb24NCiAgICA+IGFi b3V0IHdoZXRoZXIgd2Ugd2FudCB0aGVzZSBvbi1wYXRoIGRldmljZXMgdG8gaGF2ZSB0aGlzIGlu Zm9ybWF0aW9uDQogICAgPiBhdCBhbGwsIGFzIGl0IGlzIHBvdGVudGlhbGx5IHVzZWQgZm9yIHN1 cnZlaWxsYW5jZSwgdHJhZmZpYw0KICAgID4gYW5hbHlzaXMsIGV0Yy4NCiAgICA+IA0KICAgID4g DQogICAgPiANCiAgICA+IFMgMi4uMi4NCiAgICA+ID4gICANCiAgICA+ID4gICAgICBXaGlsZSBl bmNyeXB0aW9uIGNhbiBoaWRlIHRyYW5zcG9ydCBoZWFkZXIgaW5mb3JtYXRpb24sIGl0IGRvZXMg bm90DQogICAgPiA+ICAgICAgcHJldmVudCBvc3NpZmljYXRpb24gb2YgdGhlIG5ldHdvcmsgc2Vy dmljZS4gIFBlb3BsZSBzZWVraW5nIHRvDQogICAgPiA+ICAgICAgdW5kZXJzdGFuZCBuZXR3b3Jr IHRyYWZmaWMgY291bGQgY29tZSB0byByZWx5IG9uIHBhdHRlcm4gaW5mZXJlbmNlcw0KICAgID4g PiAgICAgIGFuZCBvdGhlciBoZXVyaXN0aWNzIGFzIHRoZSBiYXNpcyBmb3IgbmV0d29yayBkZWNp c2lvbiBhbmQgdG8gZGVyaXZlDQogICAgPiA+ICAgICAgbWVhc3VyZW1lbnQgZGF0YS4gIFRoaXMg Y2FuIGNyZWF0ZSBuZXcgZGVwZW5kZW5jaWVzIG9uIHRoZSB0cmFuc3BvcnQNCiAgICA+IA0KICAg ID4gVGhpcyBhbHNvIHNlZW1zIHF1aXRlIGNvbnRlc3RlZC4gRG8geW91IGhhdmUgYW55IGV2aWRl bmNlIG9mIHN1Y2ggYQ0KICAgID4gdGhpbmcgaGFwcGVuaW5nPyANCiAgICA+IA0KICAgID4gDQog ICAgPiBTIDIuMy4NCiAgICA+ID4gICAgICAgICBhbm9tYWxpZXMsIGFuZCBmYWlsdXJlIHBhdGhv bG9naWVzIGF0IGFueSBwb2ludCBhbG9uZyB0aGUgSW50ZXJuZXQNCiAgICA+ID4gICAgICAgICBw YXRoLiAgSW4gbWFueSBjYXNlcywgaXQgaXMgaW1wb3J0YW50IHRvIHJlbGF0ZSBvYnNlcnZhdGlv bnMgdG8NCiAgICA+ID4gICAgICAgICBzcGVjaWZpYyBlcXVpcG1lbnQvY29uZmlndXJhdGlvbnMg b3IgbmV0d29yayBzZWdtZW50cy4NCiAgICA+ID4gICANCiAgICA+ID4gICAgICAgICBDb25jZWFs aW5nIHRyYW5zcG9ydCBoZWFkZXIgaW5mb3JtYXRpb24gbWFrZXMgcGVyZm9ybWFuY2UvDQogICAg PiA+ICAgICAgICAgYmVoYXZpb3VyIHVuYXZhaWxhYmxlIHRvIHBhc3NpdmUgb2JzZXJ2ZXJzIGFs b25nIHRoZSBwYXRoLA0KICAgID4gDQogICAgPiBXaGlsZSBhbHNvIG1ha2luZyB0cmFmZmljIGFu YWx5c2lzIG1vcmUgZGlmZmljdWx0Lg0KICAgID4gDQogICAgPiANCiAgICA+IFMgMi4zLg0KICAg ID4gPiAgICAgICAgIGFwcGxpY2F0aW9ucyBpdCBpcyBpbXBvcnRhbnQgdG8gcmVsYXRlIG9ic2Vy dmF0aW9ucyB0byBzcGVjaWZpYw0KICAgID4gPiAgICAgICAgIGVxdWlwbWVudC9jb25maWd1cmF0 aW9ucyBvciBwYXJ0aWN1bGFyIG5ldHdvcmsgc2VnbWVudHMuDQogICAgPiA+ICAgDQogICAgPiA+ ICAgICAgICAgQ29uY2VhbGluZyB0cmFuc3BvcnQgaGVhZGVyIGluZm9ybWF0aW9uIGNhbiBtYWtl IGFuYWx5c2lzIGhhcmRlcg0KICAgID4gPiAgICAgICAgIG9yIGltcG9zc2libGUuICBUaGlzIGNv dWxkIGltcGFjdCB0aGUgYWJpbGl0eSBmb3IgYW4gb3BlcmF0b3IgdG8NCiAgICA+ID4gICAgICAg ICBhbnRpY2lwYXRlIHRoZSBuZWVkIGZvciBuZXR3b3JrIHVwZ3JhZGVzIGFuZCByb2xsLW91dC4g IEl0IGNhbg0KICAgID4gDQogICAgPiBPciB0byByZWR1Y2UgdGhlIG9wcG9ydHVuaXRpZXMgZm9y IHRyYWZmaWMgZGlzY3JpbWluYXRpb24uDQogICAgPiANCiAgICA+IA0KICAgID4gUyAyLjMuDQog ICAgPiA+ICAgDQogICAgPiA+ICAgICAgRGlmZmVyZW50IHBhcnRpZXMgd2lsbCB2aWV3IHRoZSBy ZWxhdGl2ZSBpbXBvcnRhbmNlIG9mIHRoZXNlIGlzc3Vlcw0KICAgID4gPiAgICAgIGRpZmZlcmVu dGx5LiAgRm9yIHNvbWUsIHRoZSBiZW5lZml0cyBvZiBlbmNyeXB0aW5nIHNvbWUsIG9yIGFsbCwg b2YNCiAgICA+ID4gICAgICB0aGUgdHJhbnNwb3J0IGhlYWRlcnMgbWF5IG91dHdlaWdoIHRoZSBp bXBhY3Qgb2YgZG9pbmcgc287IG90aGVycw0KICAgID4gPiAgICAgIG1pZ2h0IG1ha2UgYSBkaWZm ZXJlbnQgdHJhZGUtb2ZmLiAgVGhlIHB1cnBvc2Ugb2YgaGlnaGxpZ2h0aW5nIHRoZQ0KICAgID4g PiAgICAgIHRyYWRlLW9mZnMgaXMgdG8gbWFrZSBzdWNoIGFuYWx5c2lzIHBvc3NpYmxlLg0KICAg ID4gDQogICAgPiBUaGlzIHdob2xlIHNlY3Rpb24gc2VlbXMgdG8gcmVhbGx5IGp1c3QgaWdub3Jl IHRoZSBmYWN0IHRoYXQgbWFueSBvZg0KICAgID4gdGhlc2UgcHJhY3RpY2VzIGFyZSB1bndhbnRl ZC4NCiAgICA+IA0KICAgID4gDQogICAgPiBTIDMuMS4NCiAgICA+ID4gICAgICBGaXJld2FsbHMp LiAgQ29tbW9uIGlzc3VlcyBjb25jZXJuaW5nIElQIGFkZHJlc3Mgc2hhcmluZyBhcmUNCiAgICA+ ID4gICAgICBkZXNjcmliZWQgaW4gW1JGQzYyNjldLg0KICAgID4gPiAgIA0KICAgID4gPiAgIDMu MS4gIE9ic2VydmluZyBUcmFuc3BvcnQgSW5mb3JtYXRpb24gaW4gdGhlIE5ldHdvcmsNCiAgICA+ ID4gICANCiAgICA+ID4gICAgICBJZiBpbi1uZXR3b3JrIG9ic2VydmF0aW9uIG9mIHRyYW5zcG9y dCBwcm90b2NvbCBoZWFkZXJzIGlzIG5lZWRlZCwNCiAgICA+IA0KICAgID4gV2h5IGlzIHRoaXMg bmVlZGVkPyBJIGtub3cgc29tZSBwZW9wbGUgbWlnaHQgd2FudCBpdC4NCiAgICA+IA0KICAgID4g DQogICAgPiBTIDMuMS4xLg0KICAgID4gPiAgIDMuMS4xLiAgRmxvdyBJZGVudGlmaWNhdGlvbiBV c2luZyBUcmFuc3BvcnQgTGF5ZXIgSGVhZGVycw0KICAgID4gPiAgIA0KICAgID4gPiAgICAgIEZs b3cgaWRlbnRpZmljYXRpb24gaXMgYSBjb21tb24gZnVuY3Rpb24uICBGb3IgZXhhbXBsZSwgcGVy Zm9ybWVkIGJ5DQogICAgPiA+ICAgICAgbWVhc3VyZW1lbnQgYWN0aXZpdGllcywgUW9TIGNsYXNz aWZpY2F0aW9uLCBmaXJld2FsbHMsIERlbmlhbCBvZg0KICAgID4gPiAgICAgIFNlcnZpY2UsIERP UywgcHJldmVudGlvbi4gIFRoaXMgYmVjb21lcyBtb3JlIGNvbXBsZXggYW5kIGxlc3MgZWFzaWx5 DQogICAgPiA+ICAgICAgYWNoaWV2ZWQgd2hlbiBtdWx0aXBsZXhpbmcgaXMgdXNlZCBhdCBvciBh Ym92ZSB0aGUgdHJhbnNwb3J0IGxheWVyLg0KICAgID4gDQogICAgPiBBbHNvIHRyYWZmaWMgZGlz Y3JpbWluYXRpb24gYW5kIGJsb2NraW5nLg0KICAgID4gDQogICAgPiANCiAgICA+IFMgMy4xLjEu DQogICAgPiA+ICAgICAgdXNlIGhldXJpc3RpY3MgdG8gaW5mZXIgdGhhdCBzaG9ydCBVRFAgcGFj a2V0cyB3aXRoIHJlZ3VsYXIgc3BhY2luZw0KICAgID4gPiAgICAgIGNhcnJ5IGF1ZGlvIHRyYWZm aWMuICBPcGVyYXRpb25hbCBwcmFjdGljZXMgYWltZWQgYXQgaW5mZXJyaW5nDQogICAgPiA+ICAg ICAgdHJhbnNwb3J0IHBhcmFtZXRlcnMgYXJlIG91dCBvZiBzY29wZSBmb3IgdGhpcyBkb2N1bWVu dCwgYW5kIGFyZSBvbmx5DQogICAgPiA+ICAgICAgbWVudGlvbmVkIGhlcmUgdG8gcmVjb2duaXpl IHRoYXQgZW5jcnlwdGlvbiBkb2VzIG5vdCBwcmV2ZW50DQogICAgPiA+ICAgICAgb3BlcmF0b3Jz IGZyb20gYXR0ZW1wdGluZyB0byBhcHBseSBwcmFjdGljZXMgdGhhdCB3ZXJlIHVzZWQgd2l0aA0K ICAgID4gPiAgICAgIHVuZW5jcnlwdGVkIHRyYW5zcG9ydCBoZWFkZXJzLg0KICAgID4gDQogICAg PiBUaGlzIGhhcyBhIHJlYWxseSB0aHJlYXRlbmluZyB0b25lLiBJZiB5b3UgZG9uJ3QgZ2l2ZSB1 cyB3aGF0IHdlIHdhbnQsDQogICAgPiBsb29rIHdoYXQgY291bGQgaGFwcGVuLg0KICAgID4gDQog ICAgPiANCiAgICA+IFMgMy4xLjIuDQogICAgPiA+ICAgDQogICAgPiA+ICAgICAgVGhpcyBpbmZv cm1hdGlvbiBjYW4gc3VwcG9ydCBuZXR3b3JrIG9wZXJhdGlvbnMsIGluZm9ybSBjYXBhY2l0eQ0K ICAgID4gPiAgICAgIHBsYW5uaW5nLCBhbmQgYXNzaXN0IGluIGRldGVybWluaW5nIHRoZSBuZWVk IGZvciBlcXVpcG1lbnQgYW5kL29yDQogICAgPiA+ICAgICAgY29uZmlndXJhdGlvbiBjaGFuZ2Vz IGJ5IG5ldHdvcmsgb3BlcmF0b3JzLiAgSXQgY2FuIGFsc28gaW5mb3JtDQogICAgPiA+ICAgICAg SW50ZXJuZXQgZW5naW5lZXJpbmcgYWN0aXZpdGllcyBieSBpbmZvcm1pbmcgdGhlIGRldmVsb3Bt ZW50IG9mIG5ldw0KICAgID4gPiAgICAgIHByb3RvY29scywgbWV0aG9kb2xvZ2llcywgYW5kIHBy b2NlZHVyZXMuDQogICAgPiANCiAgICA+IFdoYXQgaXMgdGhlIHBvaW50IG9mIHRoaXMgZXhoYXVz dGl2ZSBsaXN0Pw0KICAgID4gDQogICAgPiANCiAgICA+IFMgMy4xLjMuDQogICAgPiA+ICAgDQog ICAgPiA+ICAgICAgICAgQVFNIGFuZCBFQ04gb2ZmZXIgYSByYW5nZSBvZiBhbGdvcml0aG1zIGFu ZCBjb25maWd1cmF0aW9uIG9wdGlvbnMuDQogICAgPiA+ICAgICAgICAgVG9vbHMgdGhlcmVmb3Jl IG5lZWQgdG8gYmUgYXZhaWxhYmxlIHRvIG5ldHdvcmsgb3BlcmF0b3JzIGFuZA0KICAgID4gPiAg ICAgICAgIHJlc2VhcmNoZXJzIHRvIHVuZGVyc3RhbmQgdGhlIGltcGxpY2F0aW9uIG9mIGNvbmZp Z3VyYXRpb24gY2hvaWNlcw0KICAgID4gPiAgICAgICAgIGFuZCB0cmFuc3BvcnQgYmVoYXZpb3Vy IGFzIHRoZSB1c2Ugb2YgRUNOIGluY3JlYXNlcyBhbmQgbmV3DQogICAgPiA+ICAgICAgICAgbWV0 aG9kcyBlbWVyZ2UgW1JGQzc1NjddLg0KICAgID4gDQogICAgPiBRVUlDIHNvcnQgb2YgaGlkZXMg RUNOIGZlZWRiYWNrIGJ1dCBub3QgRUNOIG1hcmtpbmcuDQogICAgPiANCiAgICA+IA0KICAgID4g UyAzLjIuNC4NCiAgICA+ID4gICANCiAgICA+ID4gICAgICAgICBBIG5ldHdvcmsgb3BlcmF0b3Ig bmVlZHMgdG9vbHMgdG8gdW5kZXJzdGFuZCBpZiBkYXRhZ3JhbSBmbG93cw0KICAgID4gPiAgICAg ICAgIChlLmcuLCB1c2luZyBVRFApIGNvbXBseSB3aXRoIGNvbmdlc3Rpb24gY29udHJvbCBleHBl Y3RhdGlvbnMgYW5kDQogICAgPiA+ICAgICAgICAgdGhlcmVmb3JlIHdoZXRoZXIgdGhlcmUgaXMg YSBuZWVkIHRvIGRlcGxveSBtZXRob2RzIHN1Y2ggYXMgcmF0ZS0NCiAgICA+ID4gICAgICAgICBs aW1pdGVycywgdHJhbnNwb3J0IGNpcmN1aXQgYnJlYWtlcnMsIG9yIG90aGVyIG1ldGhvZHMgdG8g ZW5mb3JjZQ0KICAgID4gPiAgICAgICAgIGFjY2VwdGFibGUgdXNhZ2UgZm9yIHRoZSBvZmZlcmVk IHNlcnZpY2UuDQogICAgPiANCiAgICA+IERvZXMgaXQgKm5lZWQqIGl0IG9yIGRvZXMgaXQganVz dCB3YW50IGl0LiBOb3RlIHRoYXQgd2UgaGF2ZSBoYWQgRFRMUy0NCiAgICA+IFNDVFAgd2l0aCBX ZWJSVEMgd2l0aG91dCB0aGlzIHByb3BlcnR5IGZvciBzb21lIHRpbWUgbm93LiBDYW4geW91IHBy b3ZpZGUNCiAgICA+IHNvbWUgZXZpZGVuY2UgdGhhdCBvcGVyYXRvcnMgaGF2ZSBiZWVuIGluY29u dmVuaWVuY2VkIGJ5IG5vdCBoYXZpbmcgaXQuDQogICAgPiANCiAgICA+IA0KICAgID4gUyAzLjMu DQogICAgPiA+ICAgICAgb3BlcmF0b3JzIGJyaW5nIHRvZ2V0aGVyIGhldGVyb2dlbmVvdXMgdHlw ZXMgb2YgbmV0d29yayBlcXVpcG1lbnQgYW5kDQogICAgPiA+ICAgICAgc2VlayB0byBkZXBsb3kg b3Bwb3J0dW5pc3RpYyBtZXRob2RzIHRvIGFjY2VzcyByYWRpbyBzcGVjdHJ1bS4NCiAgICA+ID4g ICANCiAgICA+ID4gICAgICBBIGZsb3cgdGhhdCBjb25jZWFscyBpdHMgdHJhbnNwb3J0IGhlYWRl ciBpbmZvcm1hdGlvbiBjb3VsZCBpbXBseQ0KICAgID4gPiAgICAgICJkb24ndCB0b3VjaCIgdG8g c29tZSBvcGVyYXRvcnMuICBUaGlzIGNvdWxkIGxpbWl0IGEgdHJvdWJsZS1zaG9vdGluZw0KICAg ID4gPiAgICAgIHJlc3BvbnNlIHRvICJjYW4ndCBoZWxwLCBubyB0cm91YmxlIGZvdW5kIi4NCiAg ICA+IA0KICAgID4gV2UgaGF2ZSBxdWl0ZSBhIGJpdCBvZiBRVUlDIHRyYWZmaWMgbm93LiBJJ2Qg YmUgaW50ZXJlc3RlZCBpbiBoZWFyaW5nDQogICAgPiBmcm9tIHRoZSBnUVVJQyB0ZWFtIHdoZXRo ZXIgdGhleSBoYXZlIHNlZW4gYW55dGhpbmcgbGlrZSB0aGlzLg0KICAgID4gDQogICAgPiANCiAg ICA+IFMgNC4NCiAgICA+ID4gICANCiAgICA+ID4gICAgICBUaGVyZSBhcmUgc2V2ZXJhbCBtb3Rp dmF0aW9ucyBmb3IgZW5jcnlwdGlvbjoNCiAgICA+ID4gICANCiAgICA+ID4gICAgICBvICBPbmUg bW90aXZlIHRvIHVzZSBlbmNyeXB0aW9uIGlzIGEgcmVzcG9uc2UgdG8gcGVyY2VwdGlvbnMgdGhh dCB0aGUNCiAgICA+ID4gICAgICAgICBuZXR3b3JrIGhhcyBiZWNvbWUgb3NzaWZpZWQgYnkgb3Zl ci1yZWxpYW5jZSBvbiBtaWRkbGVib3hlcyB0aGF0DQogICAgPiA+ICAgICAgICAgcHJldmVudCBu ZXcgcHJvdG9jb2xzIGFuZCBtZWNoYW5pc21zIGZyb20gYmVpbmcgZGVwbG95ZWQuICBUaGlzDQog ICAgPiANCiAgICA+IFRoaXMgaXNuJ3QganVzdCBhIHBlcmNlcHRpb24sIGl0J3MgYSBkZW1vbnN0 cmFibGUgcmVhbGl0eS4NCiAgICA+IA0KICAgID4gDQogICAgPiBTIDQuDQogICAgPiA+ICAgDQog ICAgPiA+ICAgICAgbyAgT25lIG1vdGl2ZSB0byB1c2UgZW5jcnlwdGlvbiBpcyBhIHJlc3BvbnNl IHRvIHBlcmNlcHRpb25zIHRoYXQgdGhlDQogICAgPiA+ICAgICAgICAgbmV0d29yayBoYXMgYmVj b21lIG9zc2lmaWVkIGJ5IG92ZXItcmVsaWFuY2Ugb24gbWlkZGxlYm94ZXMgdGhhdA0KICAgID4g PiAgICAgICAgIHByZXZlbnQgbmV3IHByb3RvY29scyBhbmQgbWVjaGFuaXNtcyBmcm9tIGJlaW5n IGRlcGxveWVkLiAgVGhpcw0KICAgID4gPiAgICAgICAgIGhhcyBsZWFkIHRvIGEgcGVyY2VwdGlv biB0aGF0IHRoZXJlIGlzIHRvbyBtdWNoICJtYW5pcHVsYXRpb24iIG9mDQogICAgPiA+ICAgICAg ICAgcHJvdG9jb2wgaGVhZGVycyB3aXRoaW4gdGhlIG5ldHdvcmssIGFuZCB0aGF0IGRlc2lnbmlu ZyB0byBkZXBsb3kNCiAgICA+IA0KICAgID4gTm90IGp1c3QgbWFuaXB1bGF0aW9uLCBhbHNvIGlu c3BlY3Rpb24uDQogICAgPiANCiAgICA+IA0KICAgID4gUyA0Lg0KICAgID4gPiAgIA0KICAgID4g PiAgICAgICAgIE9uZSBleGFtcGxlIG9mIGVuY3J5cHRpb24gYXQgdGhlIG5ldHdvcmsgbGF5ZXIg aXMgdGhlIHVzZSBvZiBJUHNlYw0KICAgID4gPiAgICAgICAgIEVuY2Fwc3VsYXRpbmcgU2VjdXJp dHkgUGF5bG9hZCAoRVNQKSBbUkZDNDMwM10gaW4gdHVubmVsIG1vZGUuDQogICAgPiA+ICAgICAg ICAgVGhpcyBlbmNyeXB0cyBhbmQgYXV0aGVudGljYXRlcyBhbGwgdHJhbnNwb3J0IGhlYWRlcnMs IHByZXZlbnRpbmcNCiAgICA+ID4gICAgICAgICB2aXNpYmlsaXR5IG9mIHRoZSB0cmFuc3BvcnQg aGVhZGVycyBieSBpbi1uZXR3b3JrIGRldmljZXMuICBTb21lDQogICAgPiA+ICAgICAgICAgVlBO IG1ldGhvZHMgYWxzbyBlbmNyeXB0IHRoZXNlIGhlYWRlcnMuDQogICAgPiANCiAgICA+IFRoaXMg c2VlbXMgbGlrZSBhIGJhZCBleGFtcGxlIGFzIHBhcnQgb2YgdGhlIHBvaW50IG9mIGEgVlBOIGlz IHRvDQogICAgPiBjb25jZWFsIHRoZSBoZWFkZXJzIGZvcm0gdGhlIG5ldHdvcmsuDQogICAgPiAN CiAgICA+IA0KICAgID4gUyA2LjEuDQogICAgPiA+ICAgDQogICAgPiA+ICAgNi4xLiAgSW5kZXBl bmRlbnQgTWVhc3VyZW1lbnQNCiAgICA+ID4gICANCiAgICA+ID4gICAgICBJbmRlcGVuZGVudCBv YnNlcnZhdGlvbiBieSBtdWx0aXBsZSBhY3RvcnMgaXMgaW1wb3J0YW50IGlmIHRoZQ0KICAgID4g PiAgICAgIHRyYW5zcG9ydCBjb21tdW5pdHkgaXMgdG8gbWFpbnRhaW4gYW4gYWNjdXJhdGUgdW5k ZXJzdGFuZGluZyBvZiB0aGUNCiAgICA+ID4gICAgICBuZXR3b3JrLiAgRW5jcnlwdGluZyB0cmFu c3BvcnQgaGVhZGVyIGVuY3J5cHRpb24gY2hhbmdlcyB0aGUgYWJpbGl0eQ0KICAgID4gDQogICAg PiBUaGlzIGlzIGlyb25pYyBiZWNhdXNlIFFVSUMgaXMgbXVjaCBiZXR0ZXIgZm9yIGVuZHBvaW50 IG1lYXN1cmVtZW50DQogICAgPiB0aGFuIFRDUCBiZWNhdXNlIHRoZSBkZXRhaWxzIGFyZSBhY2Nl c3NpYmxlIGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllci4NCiAgICA+IA0KICAgID4gDQogICAgPiBT IDguDQogICAgPiA+ICAgICAgZXhhbXBsZSwgYW4gYXR0YWNrZXIgY291bGQgY29uc3RydWN0IGEg RE9TIGF0dGFjayBieSBzZW5kaW5nIHBhY2tldHMNCiAgICA+ID4gICAgICB3aXRoIGEgc2VxdWVu Y2UgbnVtYmVyIHRoYXQgZmFsbHMgd2l0aGluIHRoZSBjdXJyZW50bHkgYWNjZXB0ZWQgcmFuZ2UN CiAgICA+ID4gICAgICBvZiBzZXF1ZW5jZSBudW1iZXJzIGF0IHRoZSByZWNlaXZpbmcgZW5kcG9p bnQsIHRoaXMgd291bGQgdGhlbg0KICAgID4gPiAgICAgIGludHJvZHVjZSBhZGRpdGlvbmFsIHdv cmsgYXQgdGhlIHJlY2VpdmluZyBlbmRwb2ludCwgZXZlbiB0aG91Z2ggdGhlDQogICAgPiA+ICAg ICAgZGF0YSBpbiB0aGUgYXR0YWNraW5nIHBhY2tldCBtYXkgbm90IGZpbmFsbHkgYmUgZGVsaXZl cmVkIGJ5IHRoZQ0KICAgID4gPiAgICAgIHRyYW5zcG9ydCBsYXllci4gIFRoaXMgaXMgc29tZXRp bWVzIGtub3duIGFzIGEgInNoYWRvd2luZyBhdHRhY2siLg0KICAgID4gDQogICAgPiBUaGlzIGRv ZXNuJ3Qgc2VlbSB0byBiZSBhbiBpc3N1ZSB3aXRoIHByb3RvY29scyB0aGF0IGF1dGhlbnRpY2F0 ZSB0aGUgU04uDQogICAgPiANCiAgICA+IA0KICAgID4gUyA4Lg0KICAgID4gPiAgIA0KICAgID4g PiAgICAgIEFuIGF0dGFjayBjYW4sIGZvciBleGFtcGxlLCBkaXNydXB0IHJlY2VpdmVyIHByb2Nl c3NpbmcsIHRyaWdnZXIgbG9zcw0KICAgID4gPiAgICAgIGFuZCByZXRyYW5zbWlzc2lvbiwgb3Ig bWFrZSBhIHJlY2VpdmluZyBlbmRwb2ludCBwZXJmb3JtIHVucHJvZHVjdGl2ZQ0KICAgID4gPiAg ICAgIGRlY3J5cHRpb24gb2YgcGFja2V0cyB0aGF0IGNhbm5vdCBiZSBzdWNjZXNzZnVsbHkgZGVj cnlwdGVkIChmb3JjaW5nDQogICAgPiA+ICAgICAgYSByZWNlaXZlciB0byBjb21taXQgZGVjcnlw dGlvbiByZXNvdXJjZXMsIG9yIHRvIHVwZGF0ZSBhbmQgdGhlbg0KICAgID4gPiAgICAgIHJlc3Rv cmUgcHJvdG9jb2wgc3RhdGUpLg0KICAgID4gDQogICAgPiBUaGlzIGlzIG5vdCBhIHJlYWwgaXNz dWUgZm9yIFFVSUMgb3Igc2ltaWxhciBwcm90b2NvbHMNCiAgICA+IA0KICAgID4gDQogICAgPiAN CiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IA0K ICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IHNhYWcg bWFpbGluZyBsaXN0DQogICAgPiBzYWFnQGlldGYub3JnDQogICAgPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhYWcNCiAgICANCiAgICANCg0K From nobody Mon Nov 4 05:57:20 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1211A1200FE for ; Mon, 4 Nov 2019 05:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1e6jWYGGSHe for ; Mon, 4 Nov 2019 05:57:10 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 583E7120099 for ; Mon, 4 Nov 2019 05:57:09 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id t5so17737355ljk.0 for ; Mon, 04 Nov 2019 05:57:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YBOr5X+m51eixbBGegNB7yNh6CLl4PoVQUHCG0g2fD0=; b=ueMDpIaxQ/LkOjW8oPDit9gtWCxIkBpnZQBtN8C/vBYxZ+hKyFRpoXh8kPlVZz7vcC rioD6GdymOF7lR9i13OgVY7J+FKEYVZMvSrdGNyyfCpHoUlF8W3MdrZJ9aor+y88xoFb 972PaJgYwgEy9Ma2dJur9KIsX8SxkU4eKcBpBnMIry/5D6AkJYWblLRWss2VHR5LNcyL 7WjO4wXJV4zzi3lvILaN7Qio1Hzug2bHaLf8G/Np48G5hzLxfbJD6433R5eIeA3XPYPc BDRI5Ryv20R05k91ik0LfF4jnlUZDrZBi/nPukuOO7EbbymIrMSlw7D3V+5EtxS3QoqO Gh8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YBOr5X+m51eixbBGegNB7yNh6CLl4PoVQUHCG0g2fD0=; b=kUlokxzeCxng4vMaZYJ07bogRKeF9vAYzT8D/lBK+KpTXCIwYa7Q9EimoGCYaDJgnS 9Jg9O+2IThwhTLP/7Z3mLxmBXK/kpf1aWByoPQV+XHI0RX+6IxqtoXdGbthMO/7DJ/a3 4nX5gGam4elka/VjlhR7YruWoX5MjNqEc0T/RPLRw56gu4NUWz4SB3sWbFqky79iIgCp MmwOz7tS9hj6RuhsYJQZgiZmsv+iNLgUOnE2MqaQ8XbYWYbPQPKnlMRXxex+2hBM1aAX AMTzpXeDNBA/AwdFyyW8RyDwT6hh+UZs2m6uOMWrh6MyhgIvWzjfKTsNZcUeOvh9tsCX 4/1g== X-Gm-Message-State: APjAAAXEvFeAatWxiqQLDZX8diRTzqNCIiixznWHtqISgHxXN0KETNaV paGMoHi2PPD/ujPhBYVe0Q4r4WCHAbMClPjJrG8Wag== X-Google-Smtp-Source: APXvYqyBMyjhZbBnGrHq4qYQho5BfWJ8hGuWVBh4TEzG62BasBqT8Crl/Ebqt/u29x1T2t/CkfbsuLYQskcxukS4kWc= X-Received: by 2002:a2e:420a:: with SMTP id p10mr19677888lja.16.1572875827525; Mon, 04 Nov 2019 05:57:07 -0800 (PST) MIME-Version: 1.0 References: <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com> In-Reply-To: <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com> From: Eric Rescorla Date: Mon, 4 Nov 2019 05:56:31 -0800 Message-ID: To: Mirja Kuehlewind Cc: Tom Herbert , tsvwg IETF list , "saag@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f9cc2a059685b037" Archived-At: Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 13:57:14 -0000 --000000000000f9cc2a059685b037 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 4, 2019 at 1:14 AM Mirja Kuehlewind < mirja.kuehlewind@ericsson.com> wrote: > Hi Ekr, hi all, > > Just on this part: > > - The community of people designing new transport protocols has > > already weighed all the considerations here and come down pretty > > decisively on the side of "encrypt all the things". Given that > > both SCTP-over-DTLS and QUIC do this, it seems pretty unlikely > > we're going to design a new transport protocol that doesn't. > I disagree that this is the conclusion the community came to, otherwise w= e > would not have put a signal for the network in the QUIC header. Also > encryption has a cost and that's the discussion we continuously still > having in QUIC and well as other working groups. So "encrypt all the > things" is way too simplified and for sure not a consensus statement whic= h > this draft (draft-ietf-tsvwg-transport-encrypt) clearly shows. > Well, we put a single, optional, bit in the header and everything else we could figure out how to encrypt encrypted. It's true that encryption has a cost to the design of the protocol and to the endpoint implementations and we've been trying to balance that cost against the value, but that's not because the group isn't trying to encrypt as much as possible. I certainly realize that there are people who are sad about this -- as you rightly point out reflected in this draft -- but I believe they are in the rough, at least of the community of people actively designing and deploying new protocols. Do you see any plausible situation in which a new transport protocol isn't largely encrypted? -Ekr > Mirja > > > > =EF=BB=BFOn 04.11.19, 03:15, "tsvwg on behalf of Tom Herbert" < > tsvwg-bounces@ietf.org on behalf of tom@herbertland.com> wrote: > > On Sun, Nov 3, 2019 at 2:20 PM Eric Rescorla wrote: > > > > After reviewing this document, I share Christian Huitema's concern > > about the tone and perspective of this document, which, while sayin= g > > that encryption is good, then proceeds to mostly lament how difficu= lt > > it makes life for various entities other than the endpoints. It see= ms > > to me rather problematic to publish this document as an RFC for > > several reasons: > > > > - Yes, it's true that the trend towards encrypting everything has > > and continues to make a number of entities sad, but that's a poin= t > > which is already made in RFC 8404. How does all of the additional > > detail here help? > > > > - The community of people designing new transport protocols has > > already weighed all the considerations here and come down pretty > > decisively on the side of "encrypt all the things". Given that > > both SCTP-over-DTLS and QUIC do this, it seems pretty unlikely > > we're going to design a new transport protocol that doesn't. > > > > - Having an IETF Consensus RFC that is so heavily weighted on the > side > > of "this is how encryption inconveniences us" and so light on > "these > > are the attacks we are preventing" gives a misleading picture of > the > > IETF community's view of the relative priority of these > > concerns. ISTM that RFC 8558 -- though perhaps imperfect -- far > more > > closely reflects that consensus. > > > > In short, I do not think this draft should be published as an RFC. > > > I believe the problem with this draft is that it identifies a > perceived problem, but does little to offer a solution other than > saying don't encrypt the transport layer header. As I've mentioned > several times, putting transport layer information of interest into > HBH extension headers is the architecturally correct solution for > hosts to signal the network. This works with any transport layer > protocol and exposure of transport layer information to the network i= s > under explicit control of the end host. IMO, the draft does not > adequately explore this alternative solution and too easily just > brushes it off as being "undesirable" based on one set of snapshot > measurements that is now almost four years old. > > > I have appended a number of detailed comments which IMO need to be > > addressed in any case, but even if they were resolved, that would n= ot > > address my primary concern. > > > > > > COMMENTS > > S 2.1. > > > 2.1. Use of Transport Header Information in the Network > > > > > > In-network measurement of transport flow characteristics can > be used > > > to enhance performance, and control cost and service > reliability. > > > Some operators have deployed functionality in middleboxes to > both > > > support network operations and enhance performance. This > reliance on > > > > This seems like a contested point. My understanding is that while > > these middleboxes are *intended* to enhance performance that there = is > > doubt that they actually do. > > > > > > S 2.1. > > > to enhance performance, and control cost and service > reliability. > > > Some operators have deployed functionality in middleboxes to > both > > > support network operations and enhance performance. This > reliance on > > > the presence and semantics of specific header information > leads to > > > ossification, where an endpoint could be required to supply = a > > > specific header to receive the network service that it > desires. In > > > > Well, not just the network service it desires but *any* service. > > > > > > S 2.1. > > > specific header to receive the network service that it > desires. In > > > some cases, this could be benign or advantageous to the > protocol > > > (e.g., recognising the start of a connection, or explicitly > exposing > > > protocol information can be expected to provide more > consistent > > > decisions by on-path devices than the use of diverse methods > to infer > > > semantics from other flow properties). In other cases, the > > > > Is there evidence of this? > > > > > > S 2.1. > > > > > > As an example of ossification, consider the experience of > developing > > > Transport Layer Security (TLS) 1.3 [RFC8446]. This required > a design > > > that recognised that deployed middleboxes relied on the > presence of > > > certain header filed exposed in TLS 1.2, and failed if those > headers > > > were changed. Other examples of the impact of ossification > can be > > > > I think you mean "fields" and it wasn't headers so much as handshak= e > > data. > > > > > > S 2.2. > > > This supports use of this information by on-path devices, bu= t > at the > > > same time can be expected to lead to ossification of the > transport > > > header, because network forwarding could evolve to depend on > the > > > presence and/or value of these fields. To avoid unwanted > inspection, > > > a protocol could intentionally vary the format or value of > exposed > > > header fields [I-D.ietf-tls-grease]. > > > > It's not just a matter of unwanted inspection. There's a real > question > > about whether we want these on-path devices to have this informatio= n > > at all, as it is potentially used for surveillance, traffic > > analysis, etc. > > > > > > > > S 2..2. > > > > > > While encryption can hide transport header information, it > does not > > > prevent ossification of the network service. People seeking > to > > > understand network traffic could come to rely on pattern > inferences > > > and other heuristics as the basis for network decision and t= o > derive > > > measurement data. This can create new dependencies on the > transport > > > > This also seems quite contested. Do you have any evidence of such a > > thing happening? > > > > > > S 2.3. > > > anomalies, and failure pathologies at any point along the > Internet > > > path. In many cases, it is important to relate > observations to > > > specific equipment/configurations or network segments. > > > > > > Concealing transport header information makes performance= / > > > behaviour unavailable to passive observers along the path= , > > > > While also making traffic analysis more difficult. > > > > > > S 2.3. > > > applications it is important to relate observations to > specific > > > equipment/configurations or particular network segments. > > > > > > Concealing transport header information can make analysis > harder > > > or impossible. This could impact the ability for an > operator to > > > anticipate the need for network upgrades and roll-out. I= t > can > > > > Or to reduce the opportunities for traffic discrimination. > > > > > > S 2.3. > > > > > > Different parties will view the relative importance of these > issues > > > differently. For some, the benefits of encrypting some, or > all, of > > > the transport headers may outweigh the impact of doing so; > others > > > might make a different trade-off. The purpose of > highlighting the > > > trade-offs is to make such analysis possible. > > > > This whole section seems to really just ignore the fact that many o= f > > these practices are unwanted. > > > > > > S 3.1. > > > Firewalls). Common issues concerning IP address sharing are > > > described in [RFC6269]. > > > > > > 3.1. Observing Transport Information in the Network > > > > > > If in-network observation of transport protocol headers is > needed, > > > > Why is this needed? I know some people might want it. > > > > > > S 3.1.1. > > > 3.1.1. Flow Identification Using Transport Layer Headers > > > > > > Flow identification is a common function. For example, > performed by > > > measurement activities, QoS classification, firewalls, Denia= l > of > > > Service, DOS, prevention. This becomes more complex and les= s > easily > > > achieved when multiplexing is used at or above the transport > layer. > > > > Also traffic discrimination and blocking. > > > > > > S 3.1.1. > > > use heuristics to infer that short UDP packets with regular > spacing > > > carry audio traffic. Operational practices aimed at inferri= ng > > > transport parameters are out of scope for this document, and > are only > > > mentioned here to recognize that encryption does not prevent > > > operators from attempting to apply practices that were used > with > > > unencrypted transport headers. > > > > This has a really threatening tone. If you don't give us what we > want, > > look what could happen. > > > > > > S 3.1.2. > > > > > > This information can support network operations, inform > capacity > > > planning, and assist in determining the need for equipment > and/or > > > configuration changes by network operators. It can also > inform > > > Internet engineering activities by informing the development > of new > > > protocols, methodologies, and procedures. > > > > What is the point of this exhaustive list? > > > > > > S 3.1.3. > > > > > > AQM and ECN offer a range of algorithms and configuration > options. > > > Tools therefore need to be available to network operators > and > > > researchers to understand the implication of configuratio= n > choices > > > and transport behaviour as the use of ECN increases and n= ew > > > methods emerge [RFC7567]. > > > > QUIC sort of hides ECN feedback but not ECN marking. > > > > > > S 3.2.4. > > > > > > A network operator needs tools to understand if datagram > flows > > > (e.g., using UDP) comply with congestion control > expectations and > > > therefore whether there is a need to deploy methods such > as rate- > > > limiters, transport circuit breakers, or other methods to > enforce > > > acceptable usage for the offered service. > > > > Does it *need* it or does it just want it. Note that we have had > DTLS- > > SCTP with WebRTC without this property for some time now. Can you > provide > > some evidence that operators have been inconvenienced by not having > it. > > > > > > S 3.3. > > > operators bring together heterogeneous types of network > equipment and > > > seek to deploy opportunistic methods to access radio spectru= m. > > > > > > A flow that conceals its transport header information could > imply > > > "don't touch" to some operators. This could limit a > trouble-shooting > > > response to "can't help, no trouble found". > > > > We have quite a bit of QUIC traffic now. I'd be interested in heari= ng > > from the gQUIC team whether they have seen anything like this. > > QUIC presents a problem in itself since the QUIC harders are inside > the UDP payload so intermediate devices end up needing to parse the > UDP transport payload. I believe the only way to identify a QUIC > packet is by matching port numbers, but per RFC7605 interpretation of > port numbers in the middle of the network is prone to > misinterpretation. Eventually, something that looks like a QUIC packe= t > based on port number will be misinterpreted. Looking at > draft-ietf-quic-transport-23, I don't see any discussion about this o= r > reference to RFC7605. Note this is true for any use case of UDP > including transport layer or network layer encapsulation. Even if the > argument is that the information is only being read and > misinterpretation is innocuous, it still wouldn't be robust protocol. > This can be contrasted to putting the information in HBH options whic= h > can be correctly and unambiguously identified anywhere in the network= . > > Tom > > > > > > > S 4. > > > > > > There are several motivations for encryption: > > > > > > o One motive to use encryption is a response to perceptions > that the > > > network has become ossified by over-reliance on > middleboxes that > > > prevent new protocols and mechanisms from being deployed. > This > > > > This isn't just a perception, it's a demonstrable reality. > > > > > > S 4. > > > > > > o One motive to use encryption is a response to perceptions > that the > > > network has become ossified by over-reliance on > middleboxes that > > > prevent new protocols and mechanisms from being deployed. > This > > > has lead to a perception that there is too much > "manipulation" of > > > protocol headers within the network, and that designing t= o > deploy > > > > Not just manipulation, also inspection. > > > > > > S 4. > > > > > > One example of encryption at the network layer is the use > of IPsec > > > Encapsulating Security Payload (ESP) [RFC4303] in tunnel > mode. > > > This encrypts and authenticates all transport headers, > preventing > > > visibility of the transport headers by in-network > devices. Some > > > VPN methods also encrypt these headers. > > > > This seems like a bad example as part of the point of a VPN is to > > conceal the headers form the network. > > > > > > S 6.1. > > > > > > 6.1. Independent Measurement > > > > > > Independent observation by multiple actors is important if t= he > > > transport community is to maintain an accurate understanding > of the > > > network. Encrypting transport header encryption changes the > ability > > > > This is ironic because QUIC is much better for endpoint measurement > > than TCP because the details are accessible at the application laye= r. > > > > > > S 8. > > > example, an attacker could construct a DOS attack by sending > packets > > > with a sequence number that falls within the currently > accepted range > > > of sequence numbers at the receiving endpoint, this would th= en > > > introduce additional work at the receiving endpoint, even > though the > > > data in the attacking packet may not finally be delivered by > the > > > transport layer. This is sometimes known as a "shadowing > attack". > > > > This doesn't seem to be an issue with protocols that authenticate > the SN. > > > > > > S 8. > > > > > > An attack can, for example, disrupt receiver processing, > trigger loss > > > and retransmission, or make a receiving endpoint perform > unproductive > > > decryption of packets that cannot be successfully decrypted > (forcing > > > a receiver to commit decryption resources, or to update and > then > > > restore protocol state). > > > > This is not a real issue for QUIC or similar protocols > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --000000000000f9cc2a059685b037 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 4, 2019 at 1:14 AM Mirja = Kuehlewind <mirja.kuehl= ewind@ericsson.com> wrote:
Hi Ekr, hi all,

Just on this part:
=C2=A0 =C2=A0 > - The community of people designing new transport protoc= ols has
=C2=A0 =C2=A0 >=C2=A0 =C2=A0already weighed all the considerations here = and come down pretty
=C2=A0 =C2=A0 >=C2=A0 =C2=A0decisively on the side of "encrypt all = the things". Given that
=C2=A0 =C2=A0 >=C2=A0 =C2=A0both SCTP-over-DTLS and QUIC do this, it see= ms pretty unlikely
=C2=A0 =C2=A0 >=C2=A0 =C2=A0we're going to design a new transport pr= otocol that doesn't.
I disagree that this is the conclusion the community came to, otherwise we = would not have put a signal for the network in the QUIC header. Also encryp= tion has a cost and that's the discussion we continuously still having = in QUIC and well as other working groups. So "encrypt all the things&q= uot; is way too simplified and for sure not a consensus statement which thi= s draft (draft-ietf-tsvwg-transport-encrypt) clearly shows.

Well, we put a single, optional, bit in the header and= everything else we could figure out how to encrypt encrypted. It's tru= e that encryption has a cost to the design of the protocol and to the endpo= int implementations and we've been trying to balance that cost against = the value, but that's not because the group isn't trying to encrypt= as much as possible.

I certainly realize that the= re are people who are sad about this -- as you rightly point out reflected = in this draft -- but I believe they are in the rough, at least of the commu= nity of people actively designing and deploying new protocols. Do you see a= ny plausible situation in which a new transport protocol isn't largely = encrypted?

-Ekr


Mirja



=EF=BB=BFOn 04.11.19, 03:15, "tsvwg on behalf of Tom Herbert" <= ;tsvwg-bounces@= ietf.org on behalf of tom@herbertland.com> wrote:

=C2=A0 =C2=A0 On Sun, Nov 3, 2019 at 2:20 PM Eric Rescorla <ekr@rtfm.com> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > After reviewing this document, I share Christian Huitema= 's concern
=C2=A0 =C2=A0 > about the tone and perspective of this document, which, = while saying
=C2=A0 =C2=A0 > that encryption is good, then proceeds to mostly lament = how difficult
=C2=A0 =C2=A0 > it makes life for various entities other than the endpoi= nts. It seems
=C2=A0 =C2=A0 > to me rather problematic to publish this document as an = RFC for
=C2=A0 =C2=A0 > several reasons:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > - Yes, it's true that the trend towards encrypting e= verything has
=C2=A0 =C2=A0 >=C2=A0 =C2=A0and continues to make a number of entities s= ad, but that's a point
=C2=A0 =C2=A0 >=C2=A0 =C2=A0which is already made in RFC 8404. How does = all of the additional
=C2=A0 =C2=A0 >=C2=A0 =C2=A0detail here help?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > - The community of people designing new transport protoc= ols has
=C2=A0 =C2=A0 >=C2=A0 =C2=A0already weighed all the considerations here = and come down pretty
=C2=A0 =C2=A0 >=C2=A0 =C2=A0decisively on the side of "encrypt all = the things". Given that
=C2=A0 =C2=A0 >=C2=A0 =C2=A0both SCTP-over-DTLS and QUIC do this, it see= ms pretty unlikely
=C2=A0 =C2=A0 >=C2=A0 =C2=A0we're going to design a new transport pr= otocol that doesn't.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > - Having an IETF Consensus RFC that is so heavily weight= ed on the side
=C2=A0 =C2=A0 >=C2=A0 =C2=A0of "this is how encryption inconvenienc= es us" and so light on "these
=C2=A0 =C2=A0 >=C2=A0 =C2=A0are the attacks we are preventing" give= s a misleading picture of the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0IETF community's view of the relative pr= iority of these
=C2=A0 =C2=A0 >=C2=A0 =C2=A0concerns. ISTM that RFC 8558 -- though perha= ps imperfect -- far more
=C2=A0 =C2=A0 >=C2=A0 =C2=A0closely reflects that consensus.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > In short, I do not think this draft should be published = as an RFC.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 I believe the problem with this draft is that it identifies a=
=C2=A0 =C2=A0 perceived problem, but does little to offer a solution other = than
=C2=A0 =C2=A0 saying don't encrypt the transport layer header. As I'= ;ve mentioned
=C2=A0 =C2=A0 several times, putting transport layer information of interes= t into
=C2=A0 =C2=A0 HBH extension headers is the architecturally correct solution= for
=C2=A0 =C2=A0 hosts to signal the network. This works with any transport la= yer
=C2=A0 =C2=A0 protocol and exposure of transport layer information to the n= etwork is
=C2=A0 =C2=A0 under explicit control of the end host. IMO, the draft does n= ot
=C2=A0 =C2=A0 adequately explore this alternative solution and too easily j= ust
=C2=A0 =C2=A0 brushes it off as being "undesirable" based on one = set of snapshot
=C2=A0 =C2=A0 measurements that is now almost four years old.

=C2=A0 =C2=A0 > I have appended a number of detailed comments which IMO = need to be
=C2=A0 =C2=A0 > addressed in any case, but even if they were resolved, t= hat would not
=C2=A0 =C2=A0 > address my primary concern.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > COMMENTS
=C2=A0 =C2=A0 > S 2.1.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A02.1.=C2=A0 Use of Transport Header Info= rmation in the Network
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 In-network measurement of trans= port flow characteristics can be used
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 to enhance performance, and con= trol cost and service reliability.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Some operators have deployed fu= nctionality in middleboxes to both
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 support network operations and = enhance performance.=C2=A0 This reliance on
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > This seems like a contested point. My understanding is t= hat while
=C2=A0 =C2=A0 > these middleboxes are *intended* to enhance performance = that there is
=C2=A0 =C2=A0 > doubt that they actually do.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 2.1.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 to enhance performance, and con= trol cost and service reliability.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Some operators have deployed fu= nctionality in middleboxes to both
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 support network operations and = enhance performance.=C2=A0 This reliance on
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 the presence and semantics of s= pecific header information leads to
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 ossification, where an endpoint= could be required to supply a
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 specific header to receive the = network service that it desires.=C2=A0 In
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Well, not just the network service it desires but *any* = service.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 2.1.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 specific header to receive the = network service that it desires.=C2=A0 In
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 some cases, this could be benig= n or advantageous to the protocol
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 (e.g., recognising the start of= a connection, or explicitly exposing
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 protocol information can be exp= ected to provide more consistent
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 decisions by on-path devices th= an the use of diverse methods to infer
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 semantics from other flow prope= rties).=C2=A0 In other cases, the
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Is there evidence of this?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 2.1.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 As an example of ossification, = consider the experience of developing
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Transport Layer Security (TLS) = 1.3 [RFC8446].=C2=A0 This required a design
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 that recognised that deployed m= iddleboxes relied on the presence of
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 certain header filed exposed in= TLS 1.2, and failed if those headers
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 were changed.=C2=A0 Other examp= les of the impact of ossification can be
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I think you mean "fields" and it wasn't he= aders so much as handshake
=C2=A0 =C2=A0 > data.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 2.2.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 This supports use of this infor= mation by on-path devices, but at the
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 same time can be expected to le= ad to ossification of the transport
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 header, because network forward= ing could evolve to depend on the
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 presence and/or value of these = fields.=C2=A0 To avoid unwanted inspection,
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 a protocol could intentionally = vary the format or value of exposed
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 header fields [I-D.ietf-tls-gre= ase].
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > It's not just a matter of unwanted inspection. There= 's a real question
=C2=A0 =C2=A0 > about whether we want these on-path devices to have this= information
=C2=A0 =C2=A0 > at all, as it is potentially used for surveillance, traf= fic
=C2=A0 =C2=A0 > analysis, etc.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 2..2.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 While encryption can hide trans= port header information, it does not
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 prevent ossification of the net= work service.=C2=A0 People seeking to
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 understand network traffic coul= d come to rely on pattern inferences
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 and other heuristics as the bas= is for network decision and to derive
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 measurement data.=C2=A0 This ca= n create new dependencies on the transport
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > This also seems quite contested. Do you have any evidenc= e of such a
=C2=A0 =C2=A0 > thing happening?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 2.3.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0anomalies, and fai= lure pathologies at any point along the Internet
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path.=C2=A0 In man= y cases, it is important to relate observations to
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0specific equipment= /configurations or network segments.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Concealing transpo= rt header information makes performance/
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0behaviour unavaila= ble to passive observers along the path,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > While also making traffic analysis more difficult.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 2.3.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0applications it is= important to relate observations to specific
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0equipment/configur= ations or particular network segments.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Concealing transpo= rt header information can make analysis harder
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or impossible.=C2= =A0 This could impact the ability for an operator to
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0anticipate the nee= d for network upgrades and roll-out.=C2=A0 It can
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Or to reduce the opportunities for traffic discriminatio= n.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 2.3.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Different parties will view the= relative importance of these issues
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 differently.=C2=A0 For some, th= e benefits of encrypting some, or all, of
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 the transport headers may outwe= igh the impact of doing so; others
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 might make a different trade-of= f.=C2=A0 The purpose of highlighting the
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 trade-offs is to make such anal= ysis possible.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > This whole section seems to really just ignore the fact = that many of
=C2=A0 =C2=A0 > these practices are unwanted.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 3.1.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Firewalls).=C2=A0 Common issues= concerning IP address sharing are
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 described in [RFC6269].
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A03.1.=C2=A0 Observing Transport Informat= ion in the Network
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 If in-network observation of tr= ansport protocol headers is needed,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Why is this needed? I know some people might want it. =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 3.1.1.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A03.1.1.=C2=A0 Flow Identification Using = Transport Layer Headers
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Flow identification is a common= function.=C2=A0 For example, performed by
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 measurement activities, QoS cla= ssification, firewalls, Denial of
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Service, DOS, prevention.=C2=A0= This becomes more complex and less easily
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 achieved when multiplexing is u= sed at or above the transport layer.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Also traffic discrimination and blocking.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 3.1.1.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 use heuristics to infer that sh= ort UDP packets with regular spacing
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 carry audio traffic.=C2=A0 Oper= ational practices aimed at inferring
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 transport parameters are out of= scope for this document, and are only
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 mentioned here to recognize tha= t encryption does not prevent
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 operators from attempting to ap= ply practices that were used with
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 unencrypted transport headers.<= br> =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > This has a really threatening tone. If you don't giv= e us what we want,
=C2=A0 =C2=A0 > look what could happen.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 3.1.2.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 This information can support ne= twork operations, inform capacity
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 planning, and assist in determi= ning the need for equipment and/or
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 configuration changes by networ= k operators.=C2=A0 It can also inform
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Internet engineering activities= by informing the development of new
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 protocols, methodologies, and p= rocedures.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > What is the point of this exhaustive list?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 3.1.3.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0AQM and ECN offer = a range of algorithms and configuration options.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Tools therefore ne= ed to be available to network operators and
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0researchers to und= erstand the implication of configuration choices
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and transport beha= viour as the use of ECN increases and new
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0methods emerge [RF= C7567].
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > QUIC sort of hides ECN feedback but not ECN marking.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 3.2.4.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A network operator= needs tools to understand if datagram flows
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., using UDP) = comply with congestion control expectations and
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0therefore whether = there is a need to deploy methods such as rate-
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0limiters, transpor= t circuit breakers, or other methods to enforce
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0acceptable usage f= or the offered service.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Does it *need* it or does it just want it. Note that we = have had DTLS-
=C2=A0 =C2=A0 > SCTP with WebRTC without this property for some time now= . Can you provide
=C2=A0 =C2=A0 > some evidence that operators have been inconvenienced by= not having it.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 3.3.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 operators bring together hetero= geneous types of network equipment and
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 seek to deploy opportunistic me= thods to access radio spectrum.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 A flow that conceals its transp= ort header information could imply
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 "don't touch" to = some operators.=C2=A0 This could limit a trouble-shooting
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 response to "can't hel= p, no trouble found".
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > We have quite a bit of QUIC traffic now. I'd be inte= rested in hearing
=C2=A0 =C2=A0 > from the gQUIC team whether they have seen anything like= this.

=C2=A0 =C2=A0 QUIC presents a problem in itself since the QUIC harders are = inside
=C2=A0 =C2=A0 the UDP payload so intermediate devices end up needing to par= se the
=C2=A0 =C2=A0 UDP transport payload. I believe the only way to identify a Q= UIC
=C2=A0 =C2=A0 packet is by matching port numbers, but per RFC7605 interpret= ation of
=C2=A0 =C2=A0 port numbers in the middle of the network is prone to
=C2=A0 =C2=A0 misinterpretation. Eventually, something that looks like a QU= IC packet
=C2=A0 =C2=A0 based on port number will be misinterpreted. Looking at
=C2=A0 =C2=A0 draft-ietf-quic-transport-23, I don't see any discussion = about this or
=C2=A0 =C2=A0 reference to RFC7605. Note this is true for any use case of U= DP
=C2=A0 =C2=A0 including transport layer or network layer encapsulation. Eve= n if the
=C2=A0 =C2=A0 argument is that the information is only being read and
=C2=A0 =C2=A0 misinterpretation is innocuous, it still wouldn't be robu= st protocol.
=C2=A0 =C2=A0 This can be contrasted to putting the information in HBH opti= ons which
=C2=A0 =C2=A0 can be correctly and unambiguously identified anywhere in the= network.

=C2=A0 =C2=A0 Tom

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 4.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 There are several motivations f= or encryption:
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 o=C2=A0 One motive to use encry= ption is a response to perceptions that the
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0network has become= ossified by over-reliance on middleboxes that
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0prevent new protoc= ols and mechanisms from being deployed.=C2=A0 This
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > This isn't just a perception, it's a demonstrabl= e reality.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 4.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 o=C2=A0 One motive to use encry= ption is a response to perceptions that the
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0network has become= ossified by over-reliance on middleboxes that
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0prevent new protoc= ols and mechanisms from being deployed.=C2=A0 This
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has lead to a perc= eption that there is too much "manipulation" of
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0protocol headers w= ithin the network, and that designing to deploy
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Not just manipulation, also inspection.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 4.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0One example of enc= ryption at the network layer is the use of IPsec
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Encapsulating Secu= rity Payload (ESP) [RFC4303] in tunnel mode.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This encrypts and = authenticates all transport headers, preventing
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0visibility of the = transport headers by in-network devices.=C2=A0 Some
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0VPN methods also e= ncrypt these headers.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > This seems like a bad example as part of the point of a = VPN is to
=C2=A0 =C2=A0 > conceal the headers form the network.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 6.1.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A06.1.=C2=A0 Independent Measurement
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Independent observation by mult= iple actors is important if the
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 transport community is to maint= ain an accurate understanding of the
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 network.=C2=A0 Encrypting trans= port header encryption changes the ability
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > This is ironic because QUIC is much better for endpoint = measurement
=C2=A0 =C2=A0 > than TCP because the details are accessible at the appli= cation layer.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 8.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 example, an attacker could cons= truct a DOS attack by sending packets
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 with a sequence number that fal= ls within the currently accepted range
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 of sequence numbers at the rece= iving endpoint, this would then
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 introduce additional work at th= e receiving endpoint, even though the
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 data in the attacking packet ma= y not finally be delivered by the
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 transport layer.=C2=A0 This is = sometimes known as a "shadowing attack".
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > This doesn't seem to be an issue with protocols that= authenticate the SN.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 8.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 An attack can, for example, dis= rupt receiver processing, trigger loss
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 and retransmission, or make a r= eceiving endpoint perform unproductive
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 decryption of packets that cann= ot be successfully decrypted (forcing
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 a receiver to commit decryption= resources, or to update and then
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 restore protocol state).
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > This is not a real issue for QUIC or similar protocols =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >



--000000000000f9cc2a059685b037-- From nobody Mon Nov 4 07:00:05 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4253012093B; Mon, 4 Nov 2019 06:59:51 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WU8pWCk7_7U2; Mon, 4 Nov 2019 06:59:44 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50053.outbound.protection.outlook.com [40.107.5.53]) (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 BEE101209F5; Mon, 4 Nov 2019 06:59:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AJapp+fG8DelXv/bvKoST6Q06vZalpS58bWvONfa0YixdgZskVop/y/6DQqdbCaQJohgRmtXE8do8S79+L4QoektEejiGQ+j9dU2haSWE/+Z3aHYF2JQCcLVH/ThNAfDT9Q2PTIWfgJqqThV/5/oAeJfFsycjvZNSykExc/qhXjA5/NX2UI5/gt0Ax/8K3t/nmEj7C3hQhPdJ+8B7JKrit5UhA9r9cBisxRYTsGJ370HCR8Qx6cuUUVAbUY3TcJM7/hXyj7MZBjJRxDPfZl/ODu9/PI3Hn0cdfUKWJ02sbFVGFEKwTNVdUeOLZV/ZtSSmXwnk8ygCRX7f8anO2MA0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kVtJJ+S1XmYt8bov3fbgtlgoxJi7qpYTKFWuHl/XIgk=; b=Se28V774nULQDAyinpfYKlHoFNHpQStV9FcKWeX8oRlqWPcHdkz7CM7CW/GwaN7f6Mv1C/EMlRf7uvN/B+zIGdhChDZ0d+CPVYhadTkp7SIn6aTOlO6TM626n5GODSaCWHrgJbvyvBjem0wgXbJEVzMl9rljXQ8N9yLTOgr7+0ZGEpf8+RDGc4cnsD9YH02SCx8RBnFGnI4dihEdrPbIhuWNHSNSA/VWh1G8foPV8zh3BEJuqEp9/YvJ59+ZFnXokFSwVuj/GqtYTCvEQcMsI8srV9Mx2hLuk4CqZcz+YIMMXeCWEJ1vtSpTD0Cn3Zduu/BuKx5cq9dy6R0ioBaryA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kVtJJ+S1XmYt8bov3fbgtlgoxJi7qpYTKFWuHl/XIgk=; b=RWXFrIdEGseRzgiGoHJmdf1Dq+1U+YhgjddOWEWtqtuOFlI++jcWaTFlx1jepmOOPCN1vKSpYCe3NFy0krf2+SsGs7i7uEil2d+73B7uvW6e+Rl1qrqrQ4C3UtQgIbw6jA/d21GH2JrjcW7ANkPQBaogid6Yv1dYb9rKszQfXgM= Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB6017.eurprd07.prod.outlook.com (20.178.112.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.13; Mon, 4 Nov 2019 14:59:40 +0000 Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4189:4ef8:bfc1:ec58]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4189:4ef8:bfc1:ec58%7]) with mapi id 15.20.2430.013; Mon, 4 Nov 2019 14:59:40 +0000 From: Mirja Kuehlewind To: Eric Rescorla CC: Tom Herbert , tsvwg IETF list , "saag@ietf.org" Thread-Topic: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt Thread-Index: AQHVkpTuK59Ux5RWm0aKwFV5BLM7VKd6Ri6AgACF/4CAAD37gIAAImWA Date: Mon, 4 Nov 2019 14:59:40 +0000 Message-ID: References: <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mirja.kuehlewind@ericsson.com; x-originating-ip: [2003:eb:4700:cf00:3d57:7e7e:af67:8db2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ae818453-cc73-4eed-5f2d-08d761379e8f x-ms-traffictypediagnostic: AM0PR07MB6017: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(366004)(346002)(396003)(136003)(189003)(199004)(53754006)(54906003)(6116002)(46003)(4326008)(14444005)(256004)(6246003)(6436002)(76176011)(6486002)(86362001)(2906002)(33656002)(316002)(81156014)(8676002)(186003)(64756008)(76116006)(66446008)(446003)(66556008)(66946007)(66476007)(8936002)(25786009)(30864003)(486006)(6916009)(71190400001)(5660300002)(11346002)(2616005)(81166006)(478600001)(44832011)(14454004)(6512007)(6306002)(229853002)(102836004)(53546011)(6506007)(54896002)(236005)(99286004)(7736002)(71200400001)(36756003)(66574012)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB6017; H:AM0PR07MB4691.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JZwQuC2eSD6EnG3BMLPSHWx+jHzKNCioWUEnwkQl2gy9ysE05VAAJbM/4sCXwaX6pFk0nOfL9/Lvx9vyshqychERvLDnWiqIaGQpO9+oF6To88p9XhSYiE4+xitlOn4V3bj/hjQSDQyqUfnJDRH4Y4UlvbJ0aPaR/oHpy9ZGtzU50y5Lm221cv4GisxIyPaK3lS6otrgrdstixVsCkMnM8+ZiDPXP5VpnpwzLeRtZH5Y/fSh/71p9nVnpB3b3ORocAt4a4DTXEhfIArpLe/CfSPLqMuFG+T2svaIdkwgGs59dACIAsxU5txY1x0vtLNstVpU48+Tje1B+Z/Ej2+YfRYEb2brmO2gc0+E2Jda7bs7UD8YtRbGA6boH4nN0GnTeR5V/VO0++aGTtYjxXVd2k4CQJFkzQ1jWQC0ern1OY2aOPOfy+7M4gc3+6yv6yu4 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_D36061F0F8724054ACF0C9A88FCEC572ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: ae818453-cc73-4eed-5f2d-08d761379e8f X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2019 14:59:40.6077 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4VnPsO0NkevqkpSEF7JBNTO5kBenBMiazZAqy9eubPBPXM1QjMqB3NETNjrPFmrwGRk3JSKGO3q/uBj2zI2eK+r1iB8DP8FCZ4OxnRCVduE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6017 Archived-At: Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 14:59:55 -0000 --_000_D36061F0F8724054ACF0C9A88FCEC572ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRWtyLA0KDQpzZWUgaW5saW5lLCBtYXJrZWQgW01LXeKApg0KDQpNaXJqYQ0KDQoNCkZyb206 IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4NCkRhdGU6IE1vbmRheSwgNC4gTm92ZW1iZXIg MjAxOSBhdCAxNDo1Nw0KVG86IE1pcmphIEt1ZWhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAZXJp Y3Nzb24uY29tPg0KQ2M6IFRvbSBIZXJiZXJ0IDx0b21AaGVyYmVydGxhbmQuY29tPiwgdHN2d2cg SUVURiBsaXN0IDx0c3Z3Z0BpZXRmLm9yZz4sICJzYWFnQGlldGYub3JnIiA8c2FhZ0BpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbdHN2d2ddIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtdHN2d2ctdHJh bnNwb3J0LWVuY3J5cHQtMDgudHh0DQoNCg0KDQpPbiBNb24sIE5vdiA0LCAyMDE5IGF0IDE6MTQg QU0gTWlyamEgS3VlaGxld2luZCA8bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5jb208bWFpbHRv Om1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSBFa3IsIGhpIGFsbCwN Cg0KSnVzdCBvbiB0aGlzIHBhcnQ6DQogICAgPiAtIFRoZSBjb21tdW5pdHkgb2YgcGVvcGxlIGRl c2lnbmluZyBuZXcgdHJhbnNwb3J0IHByb3RvY29scyBoYXMNCiAgICA+ICAgYWxyZWFkeSB3ZWln aGVkIGFsbCB0aGUgY29uc2lkZXJhdGlvbnMgaGVyZSBhbmQgY29tZSBkb3duIHByZXR0eQ0KICAg ID4gICBkZWNpc2l2ZWx5IG9uIHRoZSBzaWRlIG9mICJlbmNyeXB0IGFsbCB0aGUgdGhpbmdzIi4g R2l2ZW4gdGhhdA0KICAgID4gICBib3RoIFNDVFAtb3Zlci1EVExTIGFuZCBRVUlDIGRvIHRoaXMs IGl0IHNlZW1zIHByZXR0eSB1bmxpa2VseQ0KICAgID4gICB3ZSdyZSBnb2luZyB0byBkZXNpZ24g YSBuZXcgdHJhbnNwb3J0IHByb3RvY29sIHRoYXQgZG9lc24ndC4NCkkgZGlzYWdyZWUgdGhhdCB0 aGlzIGlzIHRoZSBjb25jbHVzaW9uIHRoZSBjb21tdW5pdHkgY2FtZSB0bywgb3RoZXJ3aXNlIHdl IHdvdWxkIG5vdCBoYXZlIHB1dCBhIHNpZ25hbCBmb3IgdGhlIG5ldHdvcmsgaW4gdGhlIFFVSUMg aGVhZGVyLiBBbHNvIGVuY3J5cHRpb24gaGFzIGEgY29zdCBhbmQgdGhhdCdzIHRoZSBkaXNjdXNz aW9uIHdlIGNvbnRpbnVvdXNseSBzdGlsbCBoYXZpbmcgaW4gUVVJQyBhbmQgd2VsbCBhcyBvdGhl ciB3b3JraW5nIGdyb3Vwcy4gU28gImVuY3J5cHQgYWxsIHRoZSB0aGluZ3MiIGlzIHdheSB0b28g c2ltcGxpZmllZCBhbmQgZm9yIHN1cmUgbm90IGEgY29uc2Vuc3VzIHN0YXRlbWVudCB3aGljaCB0 aGlzIGRyYWZ0IChkcmFmdC1pZXRmLXRzdndnLXRyYW5zcG9ydC1lbmNyeXB0KSBjbGVhcmx5IHNo b3dzLg0KDQpXZWxsLCB3ZSBwdXQgYSBzaW5nbGUsIG9wdGlvbmFsLCBiaXQgaW4gdGhlIGhlYWRl ciBhbmQgZXZlcnl0aGluZyBlbHNlIHdlIGNvdWxkIGZpZ3VyZSBvdXQgaG93IHRvIGVuY3J5cHQg ZW5jcnlwdGVkLiBJdCdzIHRydWUgdGhhdCBlbmNyeXB0aW9uIGhhcyBhIGNvc3QgdG8gdGhlIGRl c2lnbiBvZiB0aGUgcHJvdG9jb2wgYW5kIHRvIHRoZSBlbmRwb2ludCBpbXBsZW1lbnRhdGlvbnMg YW5kIHdlJ3ZlIGJlZW4gdHJ5aW5nIHRvIGJhbGFuY2UgdGhhdCBjb3N0IGFnYWluc3QgdGhlIHZh bHVlLCBidXQgdGhhdCdzIG5vdCBiZWNhdXNlIHRoZSBncm91cCBpc24ndCB0cnlpbmcgdG8gZW5j cnlwdCBhcyBtdWNoIGFzIHBvc3NpYmxlLg0KDQpbTUtdSSBkb27igJl0IHRoaW5rIHdlIG5lZWQg dG8gbml0LXBpY2sgaGVyZSBidXQgSSB0aGluayAiZW5jcnlwdCBhbGwgdGhlIHRoaW5ncyIgYW5k IOKAnGVuY3J5cHQgYXMgbXVjaCBhcyBwb3NzaWJsZeKAnSBpcyBub3QgdGhlIHNhbWUsIGVzcGVj aWFsbHkgYXMg4oCccG9zc2libGXigJ0gaXMgc29tZXRoaW5nIHRvIGFyZ3VlIGFib3V0IHdoZW4g aXQgY29tZXMgdG8gdGhlIHF1ZXN0aW9uIG9mIGhvdyBtdWNoIHlvdSBhcmUgd2lsbGluZyB0byBw YXkuIEhvd2V2ZXIsIEkgZG9u4oCZdCB0aGluayB3ZSBuZWVkIHRvIGRpc2N1c3MgdGhpcyBpbiBk ZXRhaWxzIGhlcmUsIGp1c3Qgd2FudGVkIHRvIHNheSB0aGF0IEkgZG9u4oCZdCB0aGluayB0aGUg c2l0dWF0aW9uIGlzIGEgc2ltcGxlIGFzIHlvdSBoYXZlIHN0YXRlZCBhbmQgSSBkb27igJl0IHRo aW5rIHRoZXJlIGlzIGNvbnNlbnN1cyBmb3IgYSBzaW1wbGUgImVuY3J5cHQgYWxsIHRoZSB0aGlu Z3MiLg0KDQpJIGNlcnRhaW5seSByZWFsaXplIHRoYXQgdGhlcmUgYXJlIHBlb3BsZSB3aG8gYXJl IHNhZCBhYm91dCB0aGlzIC0tIGFzIHlvdSByaWdodGx5IHBvaW50IG91dCByZWZsZWN0ZWQgaW4g dGhpcyBkcmFmdCDigJMNCg0KW01LXSBJIGRvbuKAmXQgdGhpbmsgcGVvcGxlIGFyZSBzYWQgYWJv dXQgaW5jcmVhc2luZyBhbW91bnQgb2YgZW5jcnlwdGlvbi4gQnV0IHdoZW4gd2UgY2hhbmdlIHRo aW5ncyB3ZSBhbHNvIG5lZWQgdG8gaGF2ZSBhIGRpc2N1c3Npb24gb2YgdGhlIGltcGxpY2F0aW9u IG9mIHRoaXMgY2hhbmdlIGFuZCBjYW5ub3QganVzdCBjbG9zZSBvdXIgZXllcy4gQXMgSSBzYWlk IGluIHNvbWUgY2FzZXMgd2UgbWlnaHQgYmUgaGFwcHkgYWJvdXQgdGhpbmdzIHRoYXQgaG9wZWZ1 bGx5IGp1c3QgZ28gYXdheSwgaW4gb3RoZXIgY2FzZXMgaXQgbWF5IGFjdHVhbGx5IGhhdmUgbW9y ZSBzZXZlcmUgaW1wYWN0IG9mIHRoZSB2aWFiaWxpdHkgb2YgdGhlIEludGVybmV0IGFzIGEgaW50 ZXJjb25uZWN0ZWQgbmV0d29yayB0aGF0IGlzIG9wZXJhdGVkIGJ5IGRpZmZlcmVudCBlbnRpdGll cy4NCg0KYnV0IEkgYmVsaWV2ZSB0aGV5IGFyZSBpbiB0aGUgcm91Z2gsIGF0IGxlYXN0IG9mIHRo ZSBjb21tdW5pdHkgb2YgcGVvcGxlIGFjdGl2ZWx5IGRlc2lnbmluZyBhbmQgZGVwbG95aW5nIG5l dyBwcm90b2NvbHMuDQoNCltNS10gSSBkb27igJl0IGJlbGlldmUgdGhpcy4gT3RoZXJ3aXNlIEkg d29uZGVyaW5nIHdoeSB3ZSBoYWQgc3VjaCBhIGxlbmd0aHkgZGlzY3Vzc2lvbiBmb3IgbW9yZSB0 aGFuIGEgeWVhciBpbiB0aGUgUVVJQyB3b3JraW5nIGdyb3VwLg0KDQpEbyB5b3Ugc2VlIGFueSBw bGF1c2libGUgc2l0dWF0aW9uIGluIHdoaWNoIGEgbmV3IHRyYW5zcG9ydCBwcm90b2NvbCBpc24n dCBsYXJnZWx5IGVuY3J5cHRlZD8NCg0KW01LXSBUaGF04oCZcyBub3QgdGhlIGludGVudGlvbiBo ZXJlLiBCdXQgd2UgYWxzbyBuZWVkIHRvIGNvbnNpZGVyIHdheXMgdG8gaW50ZXJhY3Qgd2l0aCB0 aGUgbmV0d29yayB3aGVyZSB0aGlzIGJyaW5ncyBiZW5lZml0IHRvIGJvdGggdGhlIG5ldHdvcmsg YW5kIHRoZSBwZXJmb3JtYW5jZSBvZiB0aGUgZW5kLXRvLWVuZCB0cmFmZmljLiBUaGVyZSBhcmUg c2l0dWF0aW9uIHdoZXJlIHRoaXMgaXMgdGhlIGNhc2UuIEFuZCBJIGRvbuKAmXQgdGhpbmsgb25l IG1ha2VzIHNlbnNlIHdpdGhvdXQgdGhlIG90aGVyLg0KDQoNCg0KDQotRWtyDQoNCg0KTWlyamEN Cg0KDQoNCk9uIDA0LjExLjE5LCAwMzoxNSwgInRzdndnIG9uIGJlaGFsZiBvZiBUb20gSGVyYmVy dCIgPHRzdndnLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmc+ IG9uIGJlaGFsZiBvZiB0b21AaGVyYmVydGxhbmQuY29tPG1haWx0bzp0b21AaGVyYmVydGxhbmQu Y29tPj4gd3JvdGU6DQoNCiAgICBPbiBTdW4sIE5vdiAzLCAyMDE5IGF0IDI6MjAgUE0gRXJpYyBS ZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PiB3cm90ZToNCiAgICA+ DQogICAgPiBBZnRlciByZXZpZXdpbmcgdGhpcyBkb2N1bWVudCwgSSBzaGFyZSBDaHJpc3RpYW4g SHVpdGVtYSdzIGNvbmNlcm4NCiAgICA+IGFib3V0IHRoZSB0b25lIGFuZCBwZXJzcGVjdGl2ZSBv ZiB0aGlzIGRvY3VtZW50LCB3aGljaCwgd2hpbGUgc2F5aW5nDQogICAgPiB0aGF0IGVuY3J5cHRp b24gaXMgZ29vZCwgdGhlbiBwcm9jZWVkcyB0byBtb3N0bHkgbGFtZW50IGhvdyBkaWZmaWN1bHQN CiAgICA+IGl0IG1ha2VzIGxpZmUgZm9yIHZhcmlvdXMgZW50aXRpZXMgb3RoZXIgdGhhbiB0aGUg ZW5kcG9pbnRzLiBJdCBzZWVtcw0KICAgID4gdG8gbWUgcmF0aGVyIHByb2JsZW1hdGljIHRvIHB1 Ymxpc2ggdGhpcyBkb2N1bWVudCBhcyBhbiBSRkMgZm9yDQogICAgPiBzZXZlcmFsIHJlYXNvbnM6 DQogICAgPg0KICAgID4gLSBZZXMsIGl0J3MgdHJ1ZSB0aGF0IHRoZSB0cmVuZCB0b3dhcmRzIGVu Y3J5cHRpbmcgZXZlcnl0aGluZyBoYXMNCiAgICA+ICAgYW5kIGNvbnRpbnVlcyB0byBtYWtlIGEg bnVtYmVyIG9mIGVudGl0aWVzIHNhZCwgYnV0IHRoYXQncyBhIHBvaW50DQogICAgPiAgIHdoaWNo IGlzIGFscmVhZHkgbWFkZSBpbiBSRkMgODQwNC4gSG93IGRvZXMgYWxsIG9mIHRoZSBhZGRpdGlv bmFsDQogICAgPiAgIGRldGFpbCBoZXJlIGhlbHA/DQogICAgPg0KICAgID4gLSBUaGUgY29tbXVu aXR5IG9mIHBlb3BsZSBkZXNpZ25pbmcgbmV3IHRyYW5zcG9ydCBwcm90b2NvbHMgaGFzDQogICAg PiAgIGFscmVhZHkgd2VpZ2hlZCBhbGwgdGhlIGNvbnNpZGVyYXRpb25zIGhlcmUgYW5kIGNvbWUg ZG93biBwcmV0dHkNCiAgICA+ICAgZGVjaXNpdmVseSBvbiB0aGUgc2lkZSBvZiAiZW5jcnlwdCBh bGwgdGhlIHRoaW5ncyIuIEdpdmVuIHRoYXQNCiAgICA+ICAgYm90aCBTQ1RQLW92ZXItRFRMUyBh bmQgUVVJQyBkbyB0aGlzLCBpdCBzZWVtcyBwcmV0dHkgdW5saWtlbHkNCiAgICA+ICAgd2UncmUg Z29pbmcgdG8gZGVzaWduIGEgbmV3IHRyYW5zcG9ydCBwcm90b2NvbCB0aGF0IGRvZXNuJ3QuDQog ICAgPg0KICAgID4gLSBIYXZpbmcgYW4gSUVURiBDb25zZW5zdXMgUkZDIHRoYXQgaXMgc28gaGVh dmlseSB3ZWlnaHRlZCBvbiB0aGUgc2lkZQ0KICAgID4gICBvZiAidGhpcyBpcyBob3cgZW5jcnlw dGlvbiBpbmNvbnZlbmllbmNlcyB1cyIgYW5kIHNvIGxpZ2h0IG9uICJ0aGVzZQ0KICAgID4gICBh cmUgdGhlIGF0dGFja3Mgd2UgYXJlIHByZXZlbnRpbmciIGdpdmVzIGEgbWlzbGVhZGluZyBwaWN0 dXJlIG9mIHRoZQ0KICAgID4gICBJRVRGIGNvbW11bml0eSdzIHZpZXcgb2YgdGhlIHJlbGF0aXZl IHByaW9yaXR5IG9mIHRoZXNlDQogICAgPiAgIGNvbmNlcm5zLiBJU1RNIHRoYXQgUkZDIDg1NTgg LS0gdGhvdWdoIHBlcmhhcHMgaW1wZXJmZWN0IC0tIGZhciBtb3JlDQogICAgPiAgIGNsb3NlbHkg cmVmbGVjdHMgdGhhdCBjb25zZW5zdXMuDQogICAgPg0KICAgID4gSW4gc2hvcnQsIEkgZG8gbm90 IHRoaW5rIHRoaXMgZHJhZnQgc2hvdWxkIGJlIHB1Ymxpc2hlZCBhcyBhbiBSRkMuDQogICAgPg0K ICAgIEkgYmVsaWV2ZSB0aGUgcHJvYmxlbSB3aXRoIHRoaXMgZHJhZnQgaXMgdGhhdCBpdCBpZGVu dGlmaWVzIGENCiAgICBwZXJjZWl2ZWQgcHJvYmxlbSwgYnV0IGRvZXMgbGl0dGxlIHRvIG9mZmVy IGEgc29sdXRpb24gb3RoZXIgdGhhbg0KICAgIHNheWluZyBkb24ndCBlbmNyeXB0IHRoZSB0cmFu c3BvcnQgbGF5ZXIgaGVhZGVyLiBBcyBJJ3ZlIG1lbnRpb25lZA0KICAgIHNldmVyYWwgdGltZXMs IHB1dHRpbmcgdHJhbnNwb3J0IGxheWVyIGluZm9ybWF0aW9uIG9mIGludGVyZXN0IGludG8NCiAg ICBIQkggZXh0ZW5zaW9uIGhlYWRlcnMgaXMgdGhlIGFyY2hpdGVjdHVyYWxseSBjb3JyZWN0IHNv bHV0aW9uIGZvcg0KICAgIGhvc3RzIHRvIHNpZ25hbCB0aGUgbmV0d29yay4gVGhpcyB3b3JrcyB3 aXRoIGFueSB0cmFuc3BvcnQgbGF5ZXINCiAgICBwcm90b2NvbCBhbmQgZXhwb3N1cmUgb2YgdHJh bnNwb3J0IGxheWVyIGluZm9ybWF0aW9uIHRvIHRoZSBuZXR3b3JrIGlzDQogICAgdW5kZXIgZXhw bGljaXQgY29udHJvbCBvZiB0aGUgZW5kIGhvc3QuIElNTywgdGhlIGRyYWZ0IGRvZXMgbm90DQog ICAgYWRlcXVhdGVseSBleHBsb3JlIHRoaXMgYWx0ZXJuYXRpdmUgc29sdXRpb24gYW5kIHRvbyBl YXNpbHkganVzdA0KICAgIGJydXNoZXMgaXQgb2ZmIGFzIGJlaW5nICJ1bmRlc2lyYWJsZSIgYmFz ZWQgb24gb25lIHNldCBvZiBzbmFwc2hvdA0KICAgIG1lYXN1cmVtZW50cyB0aGF0IGlzIG5vdyBh bG1vc3QgZm91ciB5ZWFycyBvbGQuDQoNCiAgICA+IEkgaGF2ZSBhcHBlbmRlZCBhIG51bWJlciBv ZiBkZXRhaWxlZCBjb21tZW50cyB3aGljaCBJTU8gbmVlZCB0byBiZQ0KICAgID4gYWRkcmVzc2Vk IGluIGFueSBjYXNlLCBidXQgZXZlbiBpZiB0aGV5IHdlcmUgcmVzb2x2ZWQsIHRoYXQgd291bGQg bm90DQogICAgPiBhZGRyZXNzIG15IHByaW1hcnkgY29uY2Vybi4NCiAgICA+DQogICAgPg0KICAg ID4gQ09NTUVOVFMNCiAgICA+IFMgMi4xLg0KICAgID4gPiAgIDIuMS4gIFVzZSBvZiBUcmFuc3Bv cnQgSGVhZGVyIEluZm9ybWF0aW9uIGluIHRoZSBOZXR3b3JrDQogICAgPiA+DQogICAgPiA+ICAg ICAgSW4tbmV0d29yayBtZWFzdXJlbWVudCBvZiB0cmFuc3BvcnQgZmxvdyBjaGFyYWN0ZXJpc3Rp Y3MgY2FuIGJlIHVzZWQNCiAgICA+ID4gICAgICB0byBlbmhhbmNlIHBlcmZvcm1hbmNlLCBhbmQg Y29udHJvbCBjb3N0IGFuZCBzZXJ2aWNlIHJlbGlhYmlsaXR5Lg0KICAgID4gPiAgICAgIFNvbWUg b3BlcmF0b3JzIGhhdmUgZGVwbG95ZWQgZnVuY3Rpb25hbGl0eSBpbiBtaWRkbGVib3hlcyB0byBi b3RoDQogICAgPiA+ICAgICAgc3VwcG9ydCBuZXR3b3JrIG9wZXJhdGlvbnMgYW5kIGVuaGFuY2Ug cGVyZm9ybWFuY2UuICBUaGlzIHJlbGlhbmNlIG9uDQogICAgPg0KICAgID4gVGhpcyBzZWVtcyBs aWtlIGEgY29udGVzdGVkIHBvaW50LiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgd2hpbGUNCiAg ICA+IHRoZXNlIG1pZGRsZWJveGVzIGFyZSAqaW50ZW5kZWQqIHRvIGVuaGFuY2UgcGVyZm9ybWFu Y2UgdGhhdCB0aGVyZSBpcw0KICAgID4gZG91YnQgdGhhdCB0aGV5IGFjdHVhbGx5IGRvLg0KICAg ID4NCiAgICA+DQogICAgPiBTIDIuMS4NCiAgICA+ID4gICAgICB0byBlbmhhbmNlIHBlcmZvcm1h bmNlLCBhbmQgY29udHJvbCBjb3N0IGFuZCBzZXJ2aWNlIHJlbGlhYmlsaXR5Lg0KICAgID4gPiAg ICAgIFNvbWUgb3BlcmF0b3JzIGhhdmUgZGVwbG95ZWQgZnVuY3Rpb25hbGl0eSBpbiBtaWRkbGVi b3hlcyB0byBib3RoDQogICAgPiA+ICAgICAgc3VwcG9ydCBuZXR3b3JrIG9wZXJhdGlvbnMgYW5k IGVuaGFuY2UgcGVyZm9ybWFuY2UuICBUaGlzIHJlbGlhbmNlIG9uDQogICAgPiA+ICAgICAgdGhl IHByZXNlbmNlIGFuZCBzZW1hbnRpY3Mgb2Ygc3BlY2lmaWMgaGVhZGVyIGluZm9ybWF0aW9uIGxl YWRzIHRvDQogICAgPiA+ICAgICAgb3NzaWZpY2F0aW9uLCB3aGVyZSBhbiBlbmRwb2ludCBjb3Vs ZCBiZSByZXF1aXJlZCB0byBzdXBwbHkgYQ0KICAgID4gPiAgICAgIHNwZWNpZmljIGhlYWRlciB0 byByZWNlaXZlIHRoZSBuZXR3b3JrIHNlcnZpY2UgdGhhdCBpdCBkZXNpcmVzLiAgSW4NCiAgICA+ DQogICAgPiBXZWxsLCBub3QganVzdCB0aGUgbmV0d29yayBzZXJ2aWNlIGl0IGRlc2lyZXMgYnV0 ICphbnkqIHNlcnZpY2UuDQogICAgPg0KICAgID4NCiAgICA+IFMgMi4xLg0KICAgID4gPiAgICAg IHNwZWNpZmljIGhlYWRlciB0byByZWNlaXZlIHRoZSBuZXR3b3JrIHNlcnZpY2UgdGhhdCBpdCBk ZXNpcmVzLiAgSW4NCiAgICA+ID4gICAgICBzb21lIGNhc2VzLCB0aGlzIGNvdWxkIGJlIGJlbmln biBvciBhZHZhbnRhZ2VvdXMgdG8gdGhlIHByb3RvY29sDQogICAgPiA+ICAgICAgKGUuZy4sIHJl Y29nbmlzaW5nIHRoZSBzdGFydCBvZiBhIGNvbm5lY3Rpb24sIG9yIGV4cGxpY2l0bHkgZXhwb3Np bmcNCiAgICA+ID4gICAgICBwcm90b2NvbCBpbmZvcm1hdGlvbiBjYW4gYmUgZXhwZWN0ZWQgdG8g cHJvdmlkZSBtb3JlIGNvbnNpc3RlbnQNCiAgICA+ID4gICAgICBkZWNpc2lvbnMgYnkgb24tcGF0 aCBkZXZpY2VzIHRoYW4gdGhlIHVzZSBvZiBkaXZlcnNlIG1ldGhvZHMgdG8gaW5mZXINCiAgICA+ ID4gICAgICBzZW1hbnRpY3MgZnJvbSBvdGhlciBmbG93IHByb3BlcnRpZXMpLiAgSW4gb3RoZXIg Y2FzZXMsIHRoZQ0KICAgID4NCiAgICA+IElzIHRoZXJlIGV2aWRlbmNlIG9mIHRoaXM/DQogICAg Pg0KICAgID4NCiAgICA+IFMgMi4xLg0KICAgID4gPg0KICAgID4gPiAgICAgIEFzIGFuIGV4YW1w bGUgb2Ygb3NzaWZpY2F0aW9uLCBjb25zaWRlciB0aGUgZXhwZXJpZW5jZSBvZiBkZXZlbG9waW5n DQogICAgPiA+ICAgICAgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChUTFMpIDEuMyBbUkZDODQ0 Nl0uICBUaGlzIHJlcXVpcmVkIGEgZGVzaWduDQogICAgPiA+ICAgICAgdGhhdCByZWNvZ25pc2Vk IHRoYXQgZGVwbG95ZWQgbWlkZGxlYm94ZXMgcmVsaWVkIG9uIHRoZSBwcmVzZW5jZSBvZg0KICAg ID4gPiAgICAgIGNlcnRhaW4gaGVhZGVyIGZpbGVkIGV4cG9zZWQgaW4gVExTIDEuMiwgYW5kIGZh aWxlZCBpZiB0aG9zZSBoZWFkZXJzDQogICAgPiA+ICAgICAgd2VyZSBjaGFuZ2VkLiAgT3RoZXIg ZXhhbXBsZXMgb2YgdGhlIGltcGFjdCBvZiBvc3NpZmljYXRpb24gY2FuIGJlDQogICAgPg0KICAg ID4gSSB0aGluayB5b3UgbWVhbiAiZmllbGRzIiBhbmQgaXQgd2Fzbid0IGhlYWRlcnMgc28gbXVj aCBhcyBoYW5kc2hha2UNCiAgICA+IGRhdGEuDQogICAgPg0KICAgID4NCiAgICA+IFMgMi4yLg0K ICAgID4gPiAgICAgIFRoaXMgc3VwcG9ydHMgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgb24t cGF0aCBkZXZpY2VzLCBidXQgYXQgdGhlDQogICAgPiA+ICAgICAgc2FtZSB0aW1lIGNhbiBiZSBl eHBlY3RlZCB0byBsZWFkIHRvIG9zc2lmaWNhdGlvbiBvZiB0aGUgdHJhbnNwb3J0DQogICAgPiA+ ICAgICAgaGVhZGVyLCBiZWNhdXNlIG5ldHdvcmsgZm9yd2FyZGluZyBjb3VsZCBldm9sdmUgdG8g ZGVwZW5kIG9uIHRoZQ0KICAgID4gPiAgICAgIHByZXNlbmNlIGFuZC9vciB2YWx1ZSBvZiB0aGVz ZSBmaWVsZHMuICBUbyBhdm9pZCB1bndhbnRlZCBpbnNwZWN0aW9uLA0KICAgID4gPiAgICAgIGEg cHJvdG9jb2wgY291bGQgaW50ZW50aW9uYWxseSB2YXJ5IHRoZSBmb3JtYXQgb3IgdmFsdWUgb2Yg ZXhwb3NlZA0KICAgID4gPiAgICAgIGhlYWRlciBmaWVsZHMgW0ktRC5pZXRmLXRscy1ncmVhc2Vd Lg0KICAgID4NCiAgICA+IEl0J3Mgbm90IGp1c3QgYSBtYXR0ZXIgb2YgdW53YW50ZWQgaW5zcGVj dGlvbi4gVGhlcmUncyBhIHJlYWwgcXVlc3Rpb24NCiAgICA+IGFib3V0IHdoZXRoZXIgd2Ugd2Fu dCB0aGVzZSBvbi1wYXRoIGRldmljZXMgdG8gaGF2ZSB0aGlzIGluZm9ybWF0aW9uDQogICAgPiBh dCBhbGwsIGFzIGl0IGlzIHBvdGVudGlhbGx5IHVzZWQgZm9yIHN1cnZlaWxsYW5jZSwgdHJhZmZp Yw0KICAgID4gYW5hbHlzaXMsIGV0Yy4NCiAgICA+DQogICAgPg0KICAgID4NCiAgICA+IFMgMi4u Mi4NCiAgICA+ID4NCiAgICA+ID4gICAgICBXaGlsZSBlbmNyeXB0aW9uIGNhbiBoaWRlIHRyYW5z cG9ydCBoZWFkZXIgaW5mb3JtYXRpb24sIGl0IGRvZXMgbm90DQogICAgPiA+ICAgICAgcHJldmVu dCBvc3NpZmljYXRpb24gb2YgdGhlIG5ldHdvcmsgc2VydmljZS4gIFBlb3BsZSBzZWVraW5nIHRv DQogICAgPiA+ICAgICAgdW5kZXJzdGFuZCBuZXR3b3JrIHRyYWZmaWMgY291bGQgY29tZSB0byBy ZWx5IG9uIHBhdHRlcm4gaW5mZXJlbmNlcw0KICAgID4gPiAgICAgIGFuZCBvdGhlciBoZXVyaXN0 aWNzIGFzIHRoZSBiYXNpcyBmb3IgbmV0d29yayBkZWNpc2lvbiBhbmQgdG8gZGVyaXZlDQogICAg PiA+ICAgICAgbWVhc3VyZW1lbnQgZGF0YS4gIFRoaXMgY2FuIGNyZWF0ZSBuZXcgZGVwZW5kZW5j aWVzIG9uIHRoZSB0cmFuc3BvcnQNCiAgICA+DQogICAgPiBUaGlzIGFsc28gc2VlbXMgcXVpdGUg Y29udGVzdGVkLiBEbyB5b3UgaGF2ZSBhbnkgZXZpZGVuY2Ugb2Ygc3VjaCBhDQogICAgPiB0aGlu ZyBoYXBwZW5pbmc/DQogICAgPg0KICAgID4NCiAgICA+IFMgMi4zLg0KICAgID4gPiAgICAgICAg IGFub21hbGllcywgYW5kIGZhaWx1cmUgcGF0aG9sb2dpZXMgYXQgYW55IHBvaW50IGFsb25nIHRo ZSBJbnRlcm5ldA0KICAgID4gPiAgICAgICAgIHBhdGguICBJbiBtYW55IGNhc2VzLCBpdCBpcyBp bXBvcnRhbnQgdG8gcmVsYXRlIG9ic2VydmF0aW9ucyB0bw0KICAgID4gPiAgICAgICAgIHNwZWNp ZmljIGVxdWlwbWVudC9jb25maWd1cmF0aW9ucyBvciBuZXR3b3JrIHNlZ21lbnRzLg0KICAgID4g Pg0KICAgID4gPiAgICAgICAgIENvbmNlYWxpbmcgdHJhbnNwb3J0IGhlYWRlciBpbmZvcm1hdGlv biBtYWtlcyBwZXJmb3JtYW5jZS8NCiAgICA+ID4gICAgICAgICBiZWhhdmlvdXIgdW5hdmFpbGFi bGUgdG8gcGFzc2l2ZSBvYnNlcnZlcnMgYWxvbmcgdGhlIHBhdGgsDQogICAgPg0KICAgID4gV2hp bGUgYWxzbyBtYWtpbmcgdHJhZmZpYyBhbmFseXNpcyBtb3JlIGRpZmZpY3VsdC4NCiAgICA+DQog ICAgPg0KICAgID4gUyAyLjMuDQogICAgPiA+ICAgICAgICAgYXBwbGljYXRpb25zIGl0IGlzIGlt cG9ydGFudCB0byByZWxhdGUgb2JzZXJ2YXRpb25zIHRvIHNwZWNpZmljDQogICAgPiA+ICAgICAg ICAgZXF1aXBtZW50L2NvbmZpZ3VyYXRpb25zIG9yIHBhcnRpY3VsYXIgbmV0d29yayBzZWdtZW50 cy4NCiAgICA+ID4NCiAgICA+ID4gICAgICAgICBDb25jZWFsaW5nIHRyYW5zcG9ydCBoZWFkZXIg aW5mb3JtYXRpb24gY2FuIG1ha2UgYW5hbHlzaXMgaGFyZGVyDQogICAgPiA+ICAgICAgICAgb3Ig aW1wb3NzaWJsZS4gIFRoaXMgY291bGQgaW1wYWN0IHRoZSBhYmlsaXR5IGZvciBhbiBvcGVyYXRv ciB0bw0KICAgID4gPiAgICAgICAgIGFudGljaXBhdGUgdGhlIG5lZWQgZm9yIG5ldHdvcmsgdXBn cmFkZXMgYW5kIHJvbGwtb3V0LiAgSXQgY2FuDQogICAgPg0KICAgID4gT3IgdG8gcmVkdWNlIHRo ZSBvcHBvcnR1bml0aWVzIGZvciB0cmFmZmljIGRpc2NyaW1pbmF0aW9uLg0KICAgID4NCiAgICA+ DQogICAgPiBTIDIuMy4NCiAgICA+ID4NCiAgICA+ID4gICAgICBEaWZmZXJlbnQgcGFydGllcyB3 aWxsIHZpZXcgdGhlIHJlbGF0aXZlIGltcG9ydGFuY2Ugb2YgdGhlc2UgaXNzdWVzDQogICAgPiA+ ICAgICAgZGlmZmVyZW50bHkuICBGb3Igc29tZSwgdGhlIGJlbmVmaXRzIG9mIGVuY3J5cHRpbmcg c29tZSwgb3IgYWxsLCBvZg0KICAgID4gPiAgICAgIHRoZSB0cmFuc3BvcnQgaGVhZGVycyBtYXkg b3V0d2VpZ2ggdGhlIGltcGFjdCBvZiBkb2luZyBzbzsgb3RoZXJzDQogICAgPiA+ICAgICAgbWln aHQgbWFrZSBhIGRpZmZlcmVudCB0cmFkZS1vZmYuICBUaGUgcHVycG9zZSBvZiBoaWdobGlnaHRp bmcgdGhlDQogICAgPiA+ICAgICAgdHJhZGUtb2ZmcyBpcyB0byBtYWtlIHN1Y2ggYW5hbHlzaXMg cG9zc2libGUuDQogICAgPg0KICAgID4gVGhpcyB3aG9sZSBzZWN0aW9uIHNlZW1zIHRvIHJlYWxs eSBqdXN0IGlnbm9yZSB0aGUgZmFjdCB0aGF0IG1hbnkgb2YNCiAgICA+IHRoZXNlIHByYWN0aWNl cyBhcmUgdW53YW50ZWQuDQogICAgPg0KICAgID4NCiAgICA+IFMgMy4xLg0KICAgID4gPiAgICAg IEZpcmV3YWxscykuICBDb21tb24gaXNzdWVzIGNvbmNlcm5pbmcgSVAgYWRkcmVzcyBzaGFyaW5n IGFyZQ0KICAgID4gPiAgICAgIGRlc2NyaWJlZCBpbiBbUkZDNjI2OV0uDQogICAgPiA+DQogICAg PiA+ICAgMy4xLiAgT2JzZXJ2aW5nIFRyYW5zcG9ydCBJbmZvcm1hdGlvbiBpbiB0aGUgTmV0d29y aw0KICAgID4gPg0KICAgID4gPiAgICAgIElmIGluLW5ldHdvcmsgb2JzZXJ2YXRpb24gb2YgdHJh bnNwb3J0IHByb3RvY29sIGhlYWRlcnMgaXMgbmVlZGVkLA0KICAgID4NCiAgICA+IFdoeSBpcyB0 aGlzIG5lZWRlZD8gSSBrbm93IHNvbWUgcGVvcGxlIG1pZ2h0IHdhbnQgaXQuDQogICAgPg0KICAg ID4NCiAgICA+IFMgMy4xLjEuDQogICAgPiA+ICAgMy4xLjEuICBGbG93IElkZW50aWZpY2F0aW9u IFVzaW5nIFRyYW5zcG9ydCBMYXllciBIZWFkZXJzDQogICAgPiA+DQogICAgPiA+ICAgICAgRmxv dyBpZGVudGlmaWNhdGlvbiBpcyBhIGNvbW1vbiBmdW5jdGlvbi4gIEZvciBleGFtcGxlLCBwZXJm b3JtZWQgYnkNCiAgICA+ID4gICAgICBtZWFzdXJlbWVudCBhY3Rpdml0aWVzLCBRb1MgY2xhc3Np ZmljYXRpb24sIGZpcmV3YWxscywgRGVuaWFsIG9mDQogICAgPiA+ICAgICAgU2VydmljZSwgRE9T LCBwcmV2ZW50aW9uLiAgVGhpcyBiZWNvbWVzIG1vcmUgY29tcGxleCBhbmQgbGVzcyBlYXNpbHkN CiAgICA+ID4gICAgICBhY2hpZXZlZCB3aGVuIG11bHRpcGxleGluZyBpcyB1c2VkIGF0IG9yIGFi b3ZlIHRoZSB0cmFuc3BvcnQgbGF5ZXIuDQogICAgPg0KICAgID4gQWxzbyB0cmFmZmljIGRpc2Ny aW1pbmF0aW9uIGFuZCBibG9ja2luZy4NCiAgICA+DQogICAgPg0KICAgID4gUyAzLjEuMS4NCiAg ICA+ID4gICAgICB1c2UgaGV1cmlzdGljcyB0byBpbmZlciB0aGF0IHNob3J0IFVEUCBwYWNrZXRz IHdpdGggcmVndWxhciBzcGFjaW5nDQogICAgPiA+ICAgICAgY2FycnkgYXVkaW8gdHJhZmZpYy4g IE9wZXJhdGlvbmFsIHByYWN0aWNlcyBhaW1lZCBhdCBpbmZlcnJpbmcNCiAgICA+ID4gICAgICB0 cmFuc3BvcnQgcGFyYW1ldGVycyBhcmUgb3V0IG9mIHNjb3BlIGZvciB0aGlzIGRvY3VtZW50LCBh bmQgYXJlIG9ubHkNCiAgICA+ID4gICAgICBtZW50aW9uZWQgaGVyZSB0byByZWNvZ25pemUgdGhh dCBlbmNyeXB0aW9uIGRvZXMgbm90IHByZXZlbnQNCiAgICA+ID4gICAgICBvcGVyYXRvcnMgZnJv bSBhdHRlbXB0aW5nIHRvIGFwcGx5IHByYWN0aWNlcyB0aGF0IHdlcmUgdXNlZCB3aXRoDQogICAg PiA+ICAgICAgdW5lbmNyeXB0ZWQgdHJhbnNwb3J0IGhlYWRlcnMuDQogICAgPg0KICAgID4gVGhp cyBoYXMgYSByZWFsbHkgdGhyZWF0ZW5pbmcgdG9uZS4gSWYgeW91IGRvbid0IGdpdmUgdXMgd2hh dCB3ZSB3YW50LA0KICAgID4gbG9vayB3aGF0IGNvdWxkIGhhcHBlbi4NCiAgICA+DQogICAgPg0K ICAgID4gUyAzLjEuMi4NCiAgICA+ID4NCiAgICA+ID4gICAgICBUaGlzIGluZm9ybWF0aW9uIGNh biBzdXBwb3J0IG5ldHdvcmsgb3BlcmF0aW9ucywgaW5mb3JtIGNhcGFjaXR5DQogICAgPiA+ICAg ICAgcGxhbm5pbmcsIGFuZCBhc3Npc3QgaW4gZGV0ZXJtaW5pbmcgdGhlIG5lZWQgZm9yIGVxdWlw bWVudCBhbmQvb3INCiAgICA+ID4gICAgICBjb25maWd1cmF0aW9uIGNoYW5nZXMgYnkgbmV0d29y ayBvcGVyYXRvcnMuICBJdCBjYW4gYWxzbyBpbmZvcm0NCiAgICA+ID4gICAgICBJbnRlcm5ldCBl bmdpbmVlcmluZyBhY3Rpdml0aWVzIGJ5IGluZm9ybWluZyB0aGUgZGV2ZWxvcG1lbnQgb2YgbmV3 DQogICAgPiA+ICAgICAgcHJvdG9jb2xzLCBtZXRob2RvbG9naWVzLCBhbmQgcHJvY2VkdXJlcy4N CiAgICA+DQogICAgPiBXaGF0IGlzIHRoZSBwb2ludCBvZiB0aGlzIGV4aGF1c3RpdmUgbGlzdD8N CiAgICA+DQogICAgPg0KICAgID4gUyAzLjEuMy4NCiAgICA+ID4NCiAgICA+ID4gICAgICAgICBB UU0gYW5kIEVDTiBvZmZlciBhIHJhbmdlIG9mIGFsZ29yaXRobXMgYW5kIGNvbmZpZ3VyYXRpb24g b3B0aW9ucy4NCiAgICA+ID4gICAgICAgICBUb29scyB0aGVyZWZvcmUgbmVlZCB0byBiZSBhdmFp bGFibGUgdG8gbmV0d29yayBvcGVyYXRvcnMgYW5kDQogICAgPiA+ICAgICAgICAgcmVzZWFyY2hl cnMgdG8gdW5kZXJzdGFuZCB0aGUgaW1wbGljYXRpb24gb2YgY29uZmlndXJhdGlvbiBjaG9pY2Vz DQogICAgPiA+ICAgICAgICAgYW5kIHRyYW5zcG9ydCBiZWhhdmlvdXIgYXMgdGhlIHVzZSBvZiBF Q04gaW5jcmVhc2VzIGFuZCBuZXcNCiAgICA+ID4gICAgICAgICBtZXRob2RzIGVtZXJnZSBbUkZD NzU2N10uDQogICAgPg0KICAgID4gUVVJQyBzb3J0IG9mIGhpZGVzIEVDTiBmZWVkYmFjayBidXQg bm90IEVDTiBtYXJraW5nLg0KICAgID4NCiAgICA+DQogICAgPiBTIDMuMi40Lg0KICAgID4gPg0K ICAgID4gPiAgICAgICAgIEEgbmV0d29yayBvcGVyYXRvciBuZWVkcyB0b29scyB0byB1bmRlcnN0 YW5kIGlmIGRhdGFncmFtIGZsb3dzDQogICAgPiA+ICAgICAgICAgKGUuZy4sIHVzaW5nIFVEUCkg Y29tcGx5IHdpdGggY29uZ2VzdGlvbiBjb250cm9sIGV4cGVjdGF0aW9ucyBhbmQNCiAgICA+ID4g ICAgICAgICB0aGVyZWZvcmUgd2hldGhlciB0aGVyZSBpcyBhIG5lZWQgdG8gZGVwbG95IG1ldGhv ZHMgc3VjaCBhcyByYXRlLQ0KICAgID4gPiAgICAgICAgIGxpbWl0ZXJzLCB0cmFuc3BvcnQgY2ly Y3VpdCBicmVha2Vycywgb3Igb3RoZXIgbWV0aG9kcyB0byBlbmZvcmNlDQogICAgPiA+ICAgICAg ICAgYWNjZXB0YWJsZSB1c2FnZSBmb3IgdGhlIG9mZmVyZWQgc2VydmljZS4NCiAgICA+DQogICAg PiBEb2VzIGl0ICpuZWVkKiBpdCBvciBkb2VzIGl0IGp1c3Qgd2FudCBpdC4gTm90ZSB0aGF0IHdl IGhhdmUgaGFkIERUTFMtDQogICAgPiBTQ1RQIHdpdGggV2ViUlRDIHdpdGhvdXQgdGhpcyBwcm9w ZXJ0eSBmb3Igc29tZSB0aW1lIG5vdy4gQ2FuIHlvdSBwcm92aWRlDQogICAgPiBzb21lIGV2aWRl bmNlIHRoYXQgb3BlcmF0b3JzIGhhdmUgYmVlbiBpbmNvbnZlbmllbmNlZCBieSBub3QgaGF2aW5n IGl0Lg0KICAgID4NCiAgICA+DQogICAgPiBTIDMuMy4NCiAgICA+ID4gICAgICBvcGVyYXRvcnMg YnJpbmcgdG9nZXRoZXIgaGV0ZXJvZ2VuZW91cyB0eXBlcyBvZiBuZXR3b3JrIGVxdWlwbWVudCBh bmQNCiAgICA+ID4gICAgICBzZWVrIHRvIGRlcGxveSBvcHBvcnR1bmlzdGljIG1ldGhvZHMgdG8g YWNjZXNzIHJhZGlvIHNwZWN0cnVtLg0KICAgID4gPg0KICAgID4gPiAgICAgIEEgZmxvdyB0aGF0 IGNvbmNlYWxzIGl0cyB0cmFuc3BvcnQgaGVhZGVyIGluZm9ybWF0aW9uIGNvdWxkIGltcGx5DQog ICAgPiA+ICAgICAgImRvbid0IHRvdWNoIiB0byBzb21lIG9wZXJhdG9ycy4gIFRoaXMgY291bGQg bGltaXQgYSB0cm91YmxlLXNob290aW5nDQogICAgPiA+ICAgICAgcmVzcG9uc2UgdG8gImNhbid0 IGhlbHAsIG5vIHRyb3VibGUgZm91bmQiLg0KICAgID4NCiAgICA+IFdlIGhhdmUgcXVpdGUgYSBi aXQgb2YgUVVJQyB0cmFmZmljIG5vdy4gSSdkIGJlIGludGVyZXN0ZWQgaW4gaGVhcmluZw0KICAg ID4gZnJvbSB0aGUgZ1FVSUMgdGVhbSB3aGV0aGVyIHRoZXkgaGF2ZSBzZWVuIGFueXRoaW5nIGxp a2UgdGhpcy4NCg0KICAgIFFVSUMgcHJlc2VudHMgYSBwcm9ibGVtIGluIGl0c2VsZiBzaW5jZSB0 aGUgUVVJQyBoYXJkZXJzIGFyZSBpbnNpZGUNCiAgICB0aGUgVURQIHBheWxvYWQgc28gaW50ZXJt ZWRpYXRlIGRldmljZXMgZW5kIHVwIG5lZWRpbmcgdG8gcGFyc2UgdGhlDQogICAgVURQIHRyYW5z cG9ydCBwYXlsb2FkLiBJIGJlbGlldmUgdGhlIG9ubHkgd2F5IHRvIGlkZW50aWZ5IGEgUVVJQw0K ICAgIHBhY2tldCBpcyBieSBtYXRjaGluZyBwb3J0IG51bWJlcnMsIGJ1dCBwZXIgUkZDNzYwNSBp bnRlcnByZXRhdGlvbiBvZg0KICAgIHBvcnQgbnVtYmVycyBpbiB0aGUgbWlkZGxlIG9mIHRoZSBu ZXR3b3JrIGlzIHByb25lIHRvDQogICAgbWlzaW50ZXJwcmV0YXRpb24uIEV2ZW50dWFsbHksIHNv bWV0aGluZyB0aGF0IGxvb2tzIGxpa2UgYSBRVUlDIHBhY2tldA0KICAgIGJhc2VkIG9uIHBvcnQg bnVtYmVyIHdpbGwgYmUgbWlzaW50ZXJwcmV0ZWQuIExvb2tpbmcgYXQNCiAgICBkcmFmdC1pZXRm LXF1aWMtdHJhbnNwb3J0LTIzLCBJIGRvbid0IHNlZSBhbnkgZGlzY3Vzc2lvbiBhYm91dCB0aGlz IG9yDQogICAgcmVmZXJlbmNlIHRvIFJGQzc2MDUuIE5vdGUgdGhpcyBpcyB0cnVlIGZvciBhbnkg dXNlIGNhc2Ugb2YgVURQDQogICAgaW5jbHVkaW5nIHRyYW5zcG9ydCBsYXllciBvciBuZXR3b3Jr IGxheWVyIGVuY2Fwc3VsYXRpb24uIEV2ZW4gaWYgdGhlDQogICAgYXJndW1lbnQgaXMgdGhhdCB0 aGUgaW5mb3JtYXRpb24gaXMgb25seSBiZWluZyByZWFkIGFuZA0KICAgIG1pc2ludGVycHJldGF0 aW9uIGlzIGlubm9jdW91cywgaXQgc3RpbGwgd291bGRuJ3QgYmUgcm9idXN0IHByb3RvY29sLg0K ICAgIFRoaXMgY2FuIGJlIGNvbnRyYXN0ZWQgdG8gcHV0dGluZyB0aGUgaW5mb3JtYXRpb24gaW4g SEJIIG9wdGlvbnMgd2hpY2gNCiAgICBjYW4gYmUgY29ycmVjdGx5IGFuZCB1bmFtYmlndW91c2x5 IGlkZW50aWZpZWQgYW55d2hlcmUgaW4gdGhlIG5ldHdvcmsuDQoNCiAgICBUb20NCg0KICAgID4N CiAgICA+DQogICAgPiBTIDQuDQogICAgPiA+DQogICAgPiA+ICAgICAgVGhlcmUgYXJlIHNldmVy YWwgbW90aXZhdGlvbnMgZm9yIGVuY3J5cHRpb246DQogICAgPiA+DQogICAgPiA+ICAgICAgbyAg T25lIG1vdGl2ZSB0byB1c2UgZW5jcnlwdGlvbiBpcyBhIHJlc3BvbnNlIHRvIHBlcmNlcHRpb25z IHRoYXQgdGhlDQogICAgPiA+ICAgICAgICAgbmV0d29yayBoYXMgYmVjb21lIG9zc2lmaWVkIGJ5 IG92ZXItcmVsaWFuY2Ugb24gbWlkZGxlYm94ZXMgdGhhdA0KICAgID4gPiAgICAgICAgIHByZXZl bnQgbmV3IHByb3RvY29scyBhbmQgbWVjaGFuaXNtcyBmcm9tIGJlaW5nIGRlcGxveWVkLiAgVGhp cw0KICAgID4NCiAgICA+IFRoaXMgaXNuJ3QganVzdCBhIHBlcmNlcHRpb24sIGl0J3MgYSBkZW1v bnN0cmFibGUgcmVhbGl0eS4NCiAgICA+DQogICAgPg0KICAgID4gUyA0Lg0KICAgID4gPg0KICAg ID4gPiAgICAgIG8gIE9uZSBtb3RpdmUgdG8gdXNlIGVuY3J5cHRpb24gaXMgYSByZXNwb25zZSB0 byBwZXJjZXB0aW9ucyB0aGF0IHRoZQ0KICAgID4gPiAgICAgICAgIG5ldHdvcmsgaGFzIGJlY29t ZSBvc3NpZmllZCBieSBvdmVyLXJlbGlhbmNlIG9uIG1pZGRsZWJveGVzIHRoYXQNCiAgICA+ID4g ICAgICAgICBwcmV2ZW50IG5ldyBwcm90b2NvbHMgYW5kIG1lY2hhbmlzbXMgZnJvbSBiZWluZyBk ZXBsb3llZC4gIFRoaXMNCiAgICA+ID4gICAgICAgICBoYXMgbGVhZCB0byBhIHBlcmNlcHRpb24g dGhhdCB0aGVyZSBpcyB0b28gbXVjaCAibWFuaXB1bGF0aW9uIiBvZg0KICAgID4gPiAgICAgICAg IHByb3RvY29sIGhlYWRlcnMgd2l0aGluIHRoZSBuZXR3b3JrLCBhbmQgdGhhdCBkZXNpZ25pbmcg dG8gZGVwbG95DQogICAgPg0KICAgID4gTm90IGp1c3QgbWFuaXB1bGF0aW9uLCBhbHNvIGluc3Bl Y3Rpb24uDQogICAgPg0KICAgID4NCiAgICA+IFMgNC4NCiAgICA+ID4NCiAgICA+ID4gICAgICAg ICBPbmUgZXhhbXBsZSBvZiBlbmNyeXB0aW9uIGF0IHRoZSBuZXR3b3JrIGxheWVyIGlzIHRoZSB1 c2Ugb2YgSVBzZWMNCiAgICA+ID4gICAgICAgICBFbmNhcHN1bGF0aW5nIFNlY3VyaXR5IFBheWxv YWQgKEVTUCkgW1JGQzQzMDNdIGluIHR1bm5lbCBtb2RlLg0KICAgID4gPiAgICAgICAgIFRoaXMg ZW5jcnlwdHMgYW5kIGF1dGhlbnRpY2F0ZXMgYWxsIHRyYW5zcG9ydCBoZWFkZXJzLCBwcmV2ZW50 aW5nDQogICAgPiA+ICAgICAgICAgdmlzaWJpbGl0eSBvZiB0aGUgdHJhbnNwb3J0IGhlYWRlcnMg YnkgaW4tbmV0d29yayBkZXZpY2VzLiAgU29tZQ0KICAgID4gPiAgICAgICAgIFZQTiBtZXRob2Rz IGFsc28gZW5jcnlwdCB0aGVzZSBoZWFkZXJzLg0KICAgID4NCiAgICA+IFRoaXMgc2VlbXMgbGlr ZSBhIGJhZCBleGFtcGxlIGFzIHBhcnQgb2YgdGhlIHBvaW50IG9mIGEgVlBOIGlzIHRvDQogICAg PiBjb25jZWFsIHRoZSBoZWFkZXJzIGZvcm0gdGhlIG5ldHdvcmsuDQogICAgPg0KICAgID4NCiAg ICA+IFMgNi4xLg0KICAgID4gPg0KICAgID4gPiAgIDYuMS4gIEluZGVwZW5kZW50IE1lYXN1cmVt ZW50DQogICAgPiA+DQogICAgPiA+ICAgICAgSW5kZXBlbmRlbnQgb2JzZXJ2YXRpb24gYnkgbXVs dGlwbGUgYWN0b3JzIGlzIGltcG9ydGFudCBpZiB0aGUNCiAgICA+ID4gICAgICB0cmFuc3BvcnQg Y29tbXVuaXR5IGlzIHRvIG1haW50YWluIGFuIGFjY3VyYXRlIHVuZGVyc3RhbmRpbmcgb2YgdGhl DQogICAgPiA+ICAgICAgbmV0d29yay4gIEVuY3J5cHRpbmcgdHJhbnNwb3J0IGhlYWRlciBlbmNy eXB0aW9uIGNoYW5nZXMgdGhlIGFiaWxpdHkNCiAgICA+DQogICAgPiBUaGlzIGlzIGlyb25pYyBi ZWNhdXNlIFFVSUMgaXMgbXVjaCBiZXR0ZXIgZm9yIGVuZHBvaW50IG1lYXN1cmVtZW50DQogICAg PiB0aGFuIFRDUCBiZWNhdXNlIHRoZSBkZXRhaWxzIGFyZSBhY2Nlc3NpYmxlIGF0IHRoZSBhcHBs aWNhdGlvbiBsYXllci4NCiAgICA+DQogICAgPg0KICAgID4gUyA4Lg0KICAgID4gPiAgICAgIGV4 YW1wbGUsIGFuIGF0dGFja2VyIGNvdWxkIGNvbnN0cnVjdCBhIERPUyBhdHRhY2sgYnkgc2VuZGlu ZyBwYWNrZXRzDQogICAgPiA+ICAgICAgd2l0aCBhIHNlcXVlbmNlIG51bWJlciB0aGF0IGZhbGxz IHdpdGhpbiB0aGUgY3VycmVudGx5IGFjY2VwdGVkIHJhbmdlDQogICAgPiA+ICAgICAgb2Ygc2Vx dWVuY2UgbnVtYmVycyBhdCB0aGUgcmVjZWl2aW5nIGVuZHBvaW50LCB0aGlzIHdvdWxkIHRoZW4N CiAgICA+ID4gICAgICBpbnRyb2R1Y2UgYWRkaXRpb25hbCB3b3JrIGF0IHRoZSByZWNlaXZpbmcg ZW5kcG9pbnQsIGV2ZW4gdGhvdWdoIHRoZQ0KICAgID4gPiAgICAgIGRhdGEgaW4gdGhlIGF0dGFj a2luZyBwYWNrZXQgbWF5IG5vdCBmaW5hbGx5IGJlIGRlbGl2ZXJlZCBieSB0aGUNCiAgICA+ID4g ICAgICB0cmFuc3BvcnQgbGF5ZXIuICBUaGlzIGlzIHNvbWV0aW1lcyBrbm93biBhcyBhICJzaGFk b3dpbmcgYXR0YWNrIi4NCiAgICA+DQogICAgPiBUaGlzIGRvZXNuJ3Qgc2VlbSB0byBiZSBhbiBp c3N1ZSB3aXRoIHByb3RvY29scyB0aGF0IGF1dGhlbnRpY2F0ZSB0aGUgU04uDQogICAgPg0KICAg ID4NCiAgICA+IFMgOC4NCiAgICA+ID4NCiAgICA+ID4gICAgICBBbiBhdHRhY2sgY2FuLCBmb3Ig ZXhhbXBsZSwgZGlzcnVwdCByZWNlaXZlciBwcm9jZXNzaW5nLCB0cmlnZ2VyIGxvc3MNCiAgICA+ ID4gICAgICBhbmQgcmV0cmFuc21pc3Npb24sIG9yIG1ha2UgYSByZWNlaXZpbmcgZW5kcG9pbnQg cGVyZm9ybSB1bnByb2R1Y3RpdmUNCiAgICA+ID4gICAgICBkZWNyeXB0aW9uIG9mIHBhY2tldHMg dGhhdCBjYW5ub3QgYmUgc3VjY2Vzc2Z1bGx5IGRlY3J5cHRlZCAoZm9yY2luZw0KICAgID4gPiAg ICAgIGEgcmVjZWl2ZXIgdG8gY29tbWl0IGRlY3J5cHRpb24gcmVzb3VyY2VzLCBvciB0byB1cGRh dGUgYW5kIHRoZW4NCiAgICA+ID4gICAgICByZXN0b3JlIHByb3RvY29sIHN0YXRlKS4NCiAgICA+ DQogICAgPiBUaGlzIGlzIG5vdCBhIHJlYWwgaXNzdWUgZm9yIFFVSUMgb3Igc2ltaWxhciBwcm90 b2NvbHMNCiAgICA+DQogICAgPg0KICAgID4NCiAgICA+DQogICAgPg0KICAgID4NCiAgICA+DQog ICAgPg0KICAgID4NCiAgICA+DQogICAgPg0KICAgID4NCiAgICA+DQogICAgPg0KICAgID4NCiAg ICA+DQoNCg0K --_000_D36061F0F8724054ACF0C9A88FCEC572ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <4D59FC2E910C1F41A6E10DE5822882CF@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCA3MC44NXB0IDIuMGNtIDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iREUiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPkhpIEVrciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5zZWUg aW5saW5lLCBtYXJrZWQgW01LXeKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk1p cmphPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj5FcmljIFJlc2NvcmxhICZsdDtla3JAcnRmbS5jb20mZ3Q7PGJy Pg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgNC4gTm92ZW1iZXIgMjAxOSBhdCAxNDo1Nzxicj4NCjxi PlRvOiA8L2I+TWlyamEgS3VlaGxld2luZCAmbHQ7bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5j b20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5Ub20gSGVyYmVydCAmbHQ7dG9tQGhlcmJlcnRsYW5kLmNv bSZndDssIHRzdndnIElFVEYgbGlzdCAmbHQ7dHN2d2dAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtzYWFn QGlldGYub3JnJnF1b3Q7ICZsdDtzYWFnQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwv Yj5SZTogW3RzdndnXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXRzdndnLXRyYW5zcG9ydC1lbmNy eXB0LTA4LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+T24gTW9uLCBOb3YgNCwgMjAxOSBhdCAxOjE0IEFNIE1pcmphIEt1ZWhsZXdp bmQgJmx0OzxhIGhyZWY9Im1haWx0bzptaXJqYS5rdWVobGV3aW5kQGVyaWNzc29uLmNvbSI+bWly amEua3VlaGxld2luZEBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPkhpIEVrciwgaGkgYWxsLDxicj4NCjxicj4NCkp1c3Qgb24gdGhpcyBwYXJ0 Ojxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAtIFRoZSBjb21tdW5pdHkgb2YgcGVvcGxlIGRlc2ln bmluZyBuZXcgdHJhbnNwb3J0IHByb3RvY29scyBoYXM8YnI+DQombmJzcDsgJm5ic3A7ICZndDsm bmJzcDsgJm5ic3A7YWxyZWFkeSB3ZWlnaGVkIGFsbCB0aGUgY29uc2lkZXJhdGlvbnMgaGVyZSBh bmQgY29tZSBkb3duIHByZXR0eTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDtk ZWNpc2l2ZWx5IG9uIHRoZSBzaWRlIG9mICZxdW90O2VuY3J5cHQgYWxsIHRoZSB0aGluZ3MmcXVv dDsuIEdpdmVuIHRoYXQ8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7Ym90aCBT Q1RQLW92ZXItRFRMUyBhbmQgUVVJQyBkbyB0aGlzLCBpdCBzZWVtcyBwcmV0dHkgdW5saWtlbHk8 YnI+DQombmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7d2UncmUgZ29pbmcgdG8gZGVzaWdu IGEgbmV3IHRyYW5zcG9ydCBwcm90b2NvbCB0aGF0IGRvZXNuJ3QuPGJyPg0KSSBkaXNhZ3JlZSB0 aGF0IHRoaXMgaXMgdGhlIGNvbmNsdXNpb24gdGhlIGNvbW11bml0eSBjYW1lIHRvLCBvdGhlcndp c2Ugd2Ugd291bGQgbm90IGhhdmUgcHV0IGEgc2lnbmFsIGZvciB0aGUgbmV0d29yayBpbiB0aGUg UVVJQyBoZWFkZXIuIEFsc28gZW5jcnlwdGlvbiBoYXMgYSBjb3N0IGFuZCB0aGF0J3MgdGhlIGRp c2N1c3Npb24gd2UgY29udGludW91c2x5IHN0aWxsIGhhdmluZyBpbiBRVUlDIGFuZCB3ZWxsIGFz IG90aGVyIHdvcmtpbmcgZ3JvdXBzLg0KIFNvICZxdW90O2VuY3J5cHQgYWxsIHRoZSB0aGluZ3Mm cXVvdDsgaXMgd2F5IHRvbyBzaW1wbGlmaWVkIGFuZCBmb3Igc3VyZSBub3QgYSBjb25zZW5zdXMg c3RhdGVtZW50IHdoaWNoIHRoaXMgZHJhZnQgKGRyYWZ0LWlldGYtdHN2d2ctdHJhbnNwb3J0LWVu Y3J5cHQpIGNsZWFybHkgc2hvd3MuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5XZWxsLCB3ZSBwdXQgYSBzaW5nbGUsIG9wdGlvbmFsLCBi aXQgaW4gdGhlIGhlYWRlciBhbmQgZXZlcnl0aGluZyBlbHNlIHdlIGNvdWxkIGZpZ3VyZSBvdXQg aG93IHRvIGVuY3J5cHQgZW5jcnlwdGVkLiBJdCdzIHRydWUgdGhhdCBlbmNyeXB0aW9uIGhhcyBh IGNvc3QgdG8gdGhlIGRlc2lnbiBvZiB0aGUgcHJvdG9jb2wgYW5kIHRvIHRoZSBlbmRwb2ludCBp bXBsZW1lbnRhdGlvbnMNCiBhbmQgd2UndmUgYmVlbiB0cnlpbmcgdG8gYmFsYW5jZSB0aGF0IGNv c3QgYWdhaW5zdCB0aGUgdmFsdWUsIGJ1dCB0aGF0J3Mgbm90IGJlY2F1c2UgdGhlIGdyb3VwIGlz bid0IHRyeWluZyB0byBlbmNyeXB0IGFzIG11Y2ggYXMgcG9zc2libGUuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5bTUtdSSBkb27igJl0IHRoaW5rIHdlIG5lZWQg dG8gbml0LXBpY2sgaGVyZSBidXQgSSB0aGluaw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4m cXVvdDtlbmNyeXB0IGFsbCB0aGUgdGhpbmdzJnF1b3Q7IGFuZCDigJxlbmNyeXB0IGFzIG11Y2gg YXMgcG9zc2libGXigJ0gaXMgbm90IHRoZSBzYW1lLCBlc3BlY2lhbGx5IGFzIOKAnHBvc3NpYmxl 4oCdIGlzIHNvbWV0aGluZyB0byBhcmd1ZSBhYm91dCB3aGVuIGl0IGNvbWVzIHRvIHRoZSBxdWVz dGlvbiBvZiBob3cgbXVjaCB5b3UgYXJlIHdpbGxpbmcgdG8gcGF5LiBIb3dldmVyLCBJIGRvbuKA mXQgdGhpbmsgd2UgbmVlZCB0byBkaXNjdXNzDQogdGhpcyBpbiBkZXRhaWxzIGhlcmUsIGp1c3Qg d2FudGVkIHRvIHNheSB0aGF0IEkgZG9u4oCZdCB0aGluayB0aGUgc2l0dWF0aW9uIGlzIGEgc2lt cGxlIGFzIHlvdSBoYXZlIHN0YXRlZCBhbmQgSSBkb27igJl0IHRoaW5rIHRoZXJlIGlzIGNvbnNl bnN1cyBmb3IgYSBzaW1wbGUgJnF1b3Q7ZW5jcnlwdCBhbGwgdGhlIHRoaW5ncyZxdW90Oy48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBs YW5nPSJFTi1VUyI+SSBjZXJ0YWlubHkgcmVhbGl6ZSB0aGF0IHRoZXJlIGFyZSBwZW9wbGUgd2hv IGFyZSBzYWQgYWJvdXQgdGhpcyAtLSBhcyB5b3UgcmlnaHRseSBwb2ludCBvdXQgcmVmbGVjdGVk IGluIHRoaXMgZHJhZnQg4oCTPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5bTUtdIEkgZG9u4oCZdCB0aGlu ayBwZW9wbGUgYXJlIHNhZCBhYm91dCBpbmNyZWFzaW5nIGFtb3VudCBvZiBlbmNyeXB0aW9uLiBC dXQgd2hlbiB3ZSBjaGFuZ2UgdGhpbmdzIHdlIGFsc28gbmVlZCB0byBoYXZlIGEgZGlzY3Vzc2lv biBvZiB0aGUgaW1wbGljYXRpb24gb2YgdGhpcyBjaGFuZ2UgYW5kIGNhbm5vdCBqdXN0IGNsb3Nl IG91ciBleWVzLiBBcyBJIHNhaWQgaW4gc29tZQ0KIGNhc2VzIHdlIG1pZ2h0IGJlIGhhcHB5IGFi b3V0IHRoaW5ncyB0aGF0IGhvcGVmdWxseSBqdXN0IGdvIGF3YXksIGluIG90aGVyIGNhc2VzIGl0 IG1heSBhY3R1YWxseSBoYXZlIG1vcmUgc2V2ZXJlIGltcGFjdCBvZiB0aGUgdmlhYmlsaXR5IG9m IHRoZSBJbnRlcm5ldCBhcyBhIGludGVyY29ubmVjdGVkIG5ldHdvcmsgdGhhdCBpcyBvcGVyYXRl ZCBieSBkaWZmZXJlbnQgZW50aXRpZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIj5idXQgSSBiZWxpZXZlIHRoZXkgYXJlIGluIHRoZSByb3VnaCwgYXQgbGVh c3Qgb2YgdGhlIGNvbW11bml0eSBvZiBwZW9wbGUgYWN0aXZlbHkgZGVzaWduaW5nIGFuZCBkZXBs b3lpbmcgbmV3IHByb3RvY29scy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPltNS10gSSBkb27igJl0IGJlbGlldmUgdGhpcy4gT3RoZXJ3aXNlIEkg d29uZGVyaW5nIHdoeSB3ZSBoYWQgc3VjaCBhIGxlbmd0aHkgZGlzY3Vzc2lvbiBmb3IgbW9yZSB0 aGFuIGEgeWVhciBpbiB0aGUgUVVJQyB3b3JraW5nIGdyb3VwLg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5EbyB5b3Ugc2VlIGFueSBwbGF1c2libGUgc2l0 dWF0aW9uIGluIHdoaWNoIGEgbmV3IHRyYW5zcG9ydCBwcm90b2NvbCBpc24ndCBsYXJnZWx5IGVu Y3J5cHRlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPltNS10gVGhhdOKAmXMgbm90IHRoZSBpbnRlbnRp b24gaGVyZS4gQnV0IHdlIGFsc28gbmVlZCB0byBjb25zaWRlciB3YXlzIHRvIGludGVyYWN0IHdp dGggdGhlIG5ldHdvcmsgd2hlcmUgdGhpcyBicmluZ3MgYmVuZWZpdCB0byBib3RoIHRoZSBuZXR3 b3JrIGFuZCB0aGUgcGVyZm9ybWFuY2Ugb2YgdGhlIGVuZC10by1lbmQgdHJhZmZpYy4gVGhlcmUg YXJlIHNpdHVhdGlvbiB3aGVyZQ0KIHRoaXMgaXMgdGhlIGNhc2UuIEFuZCBJIGRvbuKAmXQgdGhp bmsgb25lIG1ha2VzIHNlbnNlIHdpdGhvdXQgdGhlIG90aGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4tRWtyPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21h cmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MzYuMHB0Ij4N Cjxicj4NCk1pcmphPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KT24gMDQuMTEuMTksIDAzOjE1LCAm cXVvdDt0c3Z3ZyBvbiBiZWhhbGYgb2YgVG9tIEhlcmJlcnQmcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzp0c3Z3Zy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHN2d2ctYm91bmNl c0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86dG9tQGhlcmJlcnRs YW5kLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRvbUBoZXJiZXJ0bGFuZC5jb208L2E+Jmd0OyB3cm90 ZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IE9uIFN1biwgTm92IDMsIDIwMTkgYXQgMjoyMCBQ TSBFcmljIFJlc2NvcmxhICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9 Il9ibGFuayI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJm5ic3A7ICZuYnNwOyAm Z3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IEFmdGVyIHJldmlld2luZyB0aGlzIGRvY3VtZW50 LCBJIHNoYXJlIENocmlzdGlhbiBIdWl0ZW1hJ3MgY29uY2Vybjxicj4NCiZuYnNwOyAmbmJzcDsg Jmd0OyBhYm91dCB0aGUgdG9uZSBhbmQgcGVyc3BlY3RpdmUgb2YgdGhpcyBkb2N1bWVudCwgd2hp Y2gsIHdoaWxlIHNheWluZzxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyB0aGF0IGVuY3J5cHRpb24g aXMgZ29vZCwgdGhlbiBwcm9jZWVkcyB0byBtb3N0bHkgbGFtZW50IGhvdyBkaWZmaWN1bHQ8YnI+ DQombmJzcDsgJm5ic3A7ICZndDsgaXQgbWFrZXMgbGlmZSBmb3IgdmFyaW91cyBlbnRpdGllcyBv dGhlciB0aGFuIHRoZSBlbmRwb2ludHMuIEl0IHNlZW1zPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7 IHRvIG1lIHJhdGhlciBwcm9ibGVtYXRpYyB0byBwdWJsaXNoIHRoaXMgZG9jdW1lbnQgYXMgYW4g UkZDIGZvcjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBzZXZlcmFsIHJlYXNvbnM6PGJyPg0KJm5i c3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IC0gWWVzLCBpdCdzIHRydWUg dGhhdCB0aGUgdHJlbmQgdG93YXJkcyBlbmNyeXB0aW5nIGV2ZXJ5dGhpbmcgaGFzPGJyPg0KJm5i c3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwO2FuZCBjb250aW51ZXMgdG8gbWFrZSBhIG51bWJl ciBvZiBlbnRpdGllcyBzYWQsIGJ1dCB0aGF0J3MgYSBwb2ludDxicj4NCiZuYnNwOyAmbmJzcDsg Jmd0OyZuYnNwOyAmbmJzcDt3aGljaCBpcyBhbHJlYWR5IG1hZGUgaW4gUkZDIDg0MDQuIEhvdyBk b2VzIGFsbCBvZiB0aGUgYWRkaXRpb25hbDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAm bmJzcDtkZXRhaWwgaGVyZSBoZWxwPzxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNw OyAmbmJzcDsgJmd0OyAtIFRoZSBjb21tdW5pdHkgb2YgcGVvcGxlIGRlc2lnbmluZyBuZXcgdHJh bnNwb3J0IHByb3RvY29scyBoYXM8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7 YWxyZWFkeSB3ZWlnaGVkIGFsbCB0aGUgY29uc2lkZXJhdGlvbnMgaGVyZSBhbmQgY29tZSBkb3du IHByZXR0eTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDtkZWNpc2l2ZWx5IG9u IHRoZSBzaWRlIG9mICZxdW90O2VuY3J5cHQgYWxsIHRoZSB0aGluZ3MmcXVvdDsuIEdpdmVuIHRo YXQ8YnI+DQombmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7Ym90aCBTQ1RQLW92ZXItRFRM UyBhbmQgUVVJQyBkbyB0aGlzLCBpdCBzZWVtcyBwcmV0dHkgdW5saWtlbHk8YnI+DQombmJzcDsg Jm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7d2UncmUgZ29pbmcgdG8gZGVzaWduIGEgbmV3IHRyYW5z cG9ydCBwcm90b2NvbCB0aGF0IGRvZXNuJ3QuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0K Jm5ic3A7ICZuYnNwOyAmZ3Q7IC0gSGF2aW5nIGFuIElFVEYgQ29uc2Vuc3VzIFJGQyB0aGF0IGlz IHNvIGhlYXZpbHkgd2VpZ2h0ZWQgb24gdGhlIHNpZGU8YnI+DQombmJzcDsgJm5ic3A7ICZndDsm bmJzcDsgJm5ic3A7b2YgJnF1b3Q7dGhpcyBpcyBob3cgZW5jcnlwdGlvbiBpbmNvbnZlbmllbmNl cyB1cyZxdW90OyBhbmQgc28gbGlnaHQgb24gJnF1b3Q7dGhlc2U8YnI+DQombmJzcDsgJm5ic3A7 ICZndDsmbmJzcDsgJm5ic3A7YXJlIHRoZSBhdHRhY2tzIHdlIGFyZSBwcmV2ZW50aW5nJnF1b3Q7 IGdpdmVzIGEgbWlzbGVhZGluZyBwaWN0dXJlIG9mIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 OyZuYnNwOyAmbmJzcDtJRVRGIGNvbW11bml0eSdzIHZpZXcgb2YgdGhlIHJlbGF0aXZlIHByaW9y aXR5IG9mIHRoZXNlPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwO2NvbmNlcm5z LiBJU1RNIHRoYXQgUkZDIDg1NTggLS0gdGhvdWdoIHBlcmhhcHMgaW1wZXJmZWN0IC0tIGZhciBt b3JlPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwO2Nsb3NlbHkgcmVmbGVjdHMg dGhhdCBjb25zZW5zdXMuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNw OyAmZ3Q7IEluIHNob3J0LCBJIGRvIG5vdCB0aGluayB0aGlzIGRyYWZ0IHNob3VsZCBiZSBwdWJs aXNoZWQgYXMgYW4gUkZDLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJz cDsgSSBiZWxpZXZlIHRoZSBwcm9ibGVtIHdpdGggdGhpcyBkcmFmdCBpcyB0aGF0IGl0IGlkZW50 aWZpZXMgYTxicj4NCiZuYnNwOyAmbmJzcDsgcGVyY2VpdmVkIHByb2JsZW0sIGJ1dCBkb2VzIGxp dHRsZSB0byBvZmZlciBhIHNvbHV0aW9uIG90aGVyIHRoYW48YnI+DQombmJzcDsgJm5ic3A7IHNh eWluZyBkb24ndCBlbmNyeXB0IHRoZSB0cmFuc3BvcnQgbGF5ZXIgaGVhZGVyLiBBcyBJJ3ZlIG1l bnRpb25lZDxicj4NCiZuYnNwOyAmbmJzcDsgc2V2ZXJhbCB0aW1lcywgcHV0dGluZyB0cmFuc3Bv cnQgbGF5ZXIgaW5mb3JtYXRpb24gb2YgaW50ZXJlc3QgaW50bzxicj4NCiZuYnNwOyAmbmJzcDsg SEJIIGV4dGVuc2lvbiBoZWFkZXJzIGlzIHRoZSBhcmNoaXRlY3R1cmFsbHkgY29ycmVjdCBzb2x1 dGlvbiBmb3I8YnI+DQombmJzcDsgJm5ic3A7IGhvc3RzIHRvIHNpZ25hbCB0aGUgbmV0d29yay4g VGhpcyB3b3JrcyB3aXRoIGFueSB0cmFuc3BvcnQgbGF5ZXI8YnI+DQombmJzcDsgJm5ic3A7IHBy b3RvY29sIGFuZCBleHBvc3VyZSBvZiB0cmFuc3BvcnQgbGF5ZXIgaW5mb3JtYXRpb24gdG8gdGhl IG5ldHdvcmsgaXM8YnI+DQombmJzcDsgJm5ic3A7IHVuZGVyIGV4cGxpY2l0IGNvbnRyb2wgb2Yg dGhlIGVuZCBob3N0LiBJTU8sIHRoZSBkcmFmdCBkb2VzIG5vdDxicj4NCiZuYnNwOyAmbmJzcDsg YWRlcXVhdGVseSBleHBsb3JlIHRoaXMgYWx0ZXJuYXRpdmUgc29sdXRpb24gYW5kIHRvbyBlYXNp bHkganVzdDxicj4NCiZuYnNwOyAmbmJzcDsgYnJ1c2hlcyBpdCBvZmYgYXMgYmVpbmcgJnF1b3Q7 dW5kZXNpcmFibGUmcXVvdDsgYmFzZWQgb24gb25lIHNldCBvZiBzbmFwc2hvdDxicj4NCiZuYnNw OyAmbmJzcDsgbWVhc3VyZW1lbnRzIHRoYXQgaXMgbm93IGFsbW9zdCBmb3VyIHllYXJzIG9sZC48 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgSSBoYXZlIGFwcGVuZGVkIGEgbnVtYmVyIG9m IGRldGFpbGVkIGNvbW1lbnRzIHdoaWNoIElNTyBuZWVkIHRvIGJlPGJyPg0KJm5ic3A7ICZuYnNw OyAmZ3Q7IGFkZHJlc3NlZCBpbiBhbnkgY2FzZSwgYnV0IGV2ZW4gaWYgdGhleSB3ZXJlIHJlc29s dmVkLCB0aGF0IHdvdWxkIG5vdDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBhZGRyZXNzIG15IHBy aW1hcnkgY29uY2Vybi48YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7 ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgQ09NTUVOVFM8YnI+DQombmJzcDsgJm5ic3A7 ICZndDsgUyAyLjEuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7Mi4x LiZuYnNwOyBVc2Ugb2YgVHJhbnNwb3J0IEhlYWRlciBJbmZvcm1hdGlvbiBpbiB0aGUgTmV0d29y azxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbi1uZXR3b3JrIG1lYXN1cmVtZW50IG9mIHRyYW5zcG9y dCBmbG93IGNoYXJhY3RlcmlzdGljcyBjYW4gYmUgdXNlZDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdG8gZW5oYW5jZSBwZXJmb3JtYW5jZSwgYW5kIGNv bnRyb2wgY29zdCBhbmQgc2VydmljZSByZWxpYWJpbGl0eS48YnI+DQombmJzcDsgJm5ic3A7ICZn dDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IFNvbWUgb3BlcmF0b3JzIGhhdmUgZGVwbG95ZWQg ZnVuY3Rpb25hbGl0eSBpbiBtaWRkbGVib3hlcyB0byBib3RoPGJyPg0KJm5ic3A7ICZuYnNwOyAm Z3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBzdXBwb3J0IG5ldHdvcmsgb3BlcmF0aW9ucyBh bmQgZW5oYW5jZSBwZXJmb3JtYW5jZS4mbmJzcDsgVGhpcyByZWxpYW5jZSBvbjxicj4NCiZuYnNw OyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBUaGlzIHNlZW1zIGxpa2UgYSBj b250ZXN0ZWQgcG9pbnQuIE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB3aGlsZTxicj4NCiZuYnNw OyAmbmJzcDsgJmd0OyB0aGVzZSBtaWRkbGVib3hlcyBhcmUgKmludGVuZGVkKiB0byBlbmhhbmNl IHBlcmZvcm1hbmNlIHRoYXQgdGhlcmUgaXM8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgZG91YnQg dGhhdCB0aGV5IGFjdHVhbGx5IGRvLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNw OyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBTIDIuMS48YnI+DQombmJzcDsg Jm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IHRvIGVuaGFuY2UgcGVyZm9ybWFu Y2UsIGFuZCBjb250cm9sIGNvc3QgYW5kIHNlcnZpY2UgcmVsaWFiaWxpdHkuPGJyPg0KJm5ic3A7 ICZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBTb21lIG9wZXJhdG9ycyBoYXZl IGRlcGxveWVkIGZ1bmN0aW9uYWxpdHkgaW4gbWlkZGxlYm94ZXMgdG8gYm90aDxicj4NCiZuYnNw OyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgc3VwcG9ydCBuZXR3b3JrIG9w ZXJhdGlvbnMgYW5kIGVuaGFuY2UgcGVyZm9ybWFuY2UuJm5ic3A7IFRoaXMgcmVsaWFuY2Ugb248 YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSBwcmVz ZW5jZSBhbmQgc2VtYW50aWNzIG9mIHNwZWNpZmljIGhlYWRlciBpbmZvcm1hdGlvbiBsZWFkcyB0 bzxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgb3NzaWZp Y2F0aW9uLCB3aGVyZSBhbiBlbmRwb2ludCBjb3VsZCBiZSByZXF1aXJlZCB0byBzdXBwbHkgYTxi cj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgc3BlY2lmaWMg aGVhZGVyIHRvIHJlY2VpdmUgdGhlIG5ldHdvcmsgc2VydmljZSB0aGF0IGl0IGRlc2lyZXMuJm5i c3A7IEluPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IFdl bGwsIG5vdCBqdXN0IHRoZSBuZXR3b3JrIHNlcnZpY2UgaXQgZGVzaXJlcyBidXQgKmFueSogc2Vy dmljZS48YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+ DQombmJzcDsgJm5ic3A7ICZndDsgUyAyLjEuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyBzcGVjaWZpYyBoZWFkZXIgdG8gcmVjZWl2ZSB0aGUgbmV0d29y ayBzZXJ2aWNlIHRoYXQgaXQgZGVzaXJlcy4mbmJzcDsgSW48YnI+DQombmJzcDsgJm5ic3A7ICZn dDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IHNvbWUgY2FzZXMsIHRoaXMgY291bGQgYmUgYmVu aWduIG9yIGFkdmFudGFnZW91cyB0byB0aGUgcHJvdG9jb2w8YnI+DQombmJzcDsgJm5ic3A7ICZn dDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IChlLmcuLCByZWNvZ25pc2luZyB0aGUgc3RhcnQg b2YgYSBjb25uZWN0aW9uLCBvciBleHBsaWNpdGx5IGV4cG9zaW5nPGJyPg0KJm5ic3A7ICZuYnNw OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBwcm90b2NvbCBpbmZvcm1hdGlvbiBjYW4g YmUgZXhwZWN0ZWQgdG8gcHJvdmlkZSBtb3JlIGNvbnNpc3RlbnQ8YnI+DQombmJzcDsgJm5ic3A7 ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IGRlY2lzaW9ucyBieSBvbi1wYXRoIGRldmlj ZXMgdGhhbiB0aGUgdXNlIG9mIGRpdmVyc2UgbWV0aG9kcyB0byBpbmZlcjxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgc2VtYW50aWNzIGZyb20gb3RoZXIg ZmxvdyBwcm9wZXJ0aWVzKS4mbmJzcDsgSW4gb3RoZXIgY2FzZXMsIHRoZTxicj4NCiZuYnNwOyAm bmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBJcyB0aGVyZSBldmlkZW5jZSBvZiB0 aGlzPzxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4N CiZuYnNwOyAmbmJzcDsgJmd0OyBTIDIuMS48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0Ozxi cj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgQXMgYW4gZXhh bXBsZSBvZiBvc3NpZmljYXRpb24sIGNvbnNpZGVyIHRoZSBleHBlcmllbmNlIG9mIGRldmVsb3Bp bmc8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IFRyYW5z cG9ydCBMYXllciBTZWN1cml0eSAoVExTKSAxLjMgW1JGQzg0NDZdLiZuYnNwOyBUaGlzIHJlcXVp cmVkIGEgZGVzaWduPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyB0aGF0IHJlY29nbmlzZWQgdGhhdCBkZXBsb3llZCBtaWRkbGVib3hlcyByZWxpZWQgb24g dGhlIHByZXNlbmNlIG9mPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyBjZXJ0YWluIGhlYWRlciBmaWxlZCBleHBvc2VkIGluIFRMUyAxLjIsIGFuZCBmYWls ZWQgaWYgdGhvc2UgaGVhZGVyczxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgd2VyZSBjaGFuZ2VkLiZuYnNwOyBPdGhlciBleGFtcGxlcyBvZiB0aGUgaW1w YWN0IG9mIG9zc2lmaWNhdGlvbiBjYW4gYmU8YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQom bmJzcDsgJm5ic3A7ICZndDsgSSB0aGluayB5b3UgbWVhbiAmcXVvdDtmaWVsZHMmcXVvdDsgYW5k IGl0IHdhc24ndCBoZWFkZXJzIHNvIG11Y2ggYXMgaGFuZHNoYWtlPGJyPg0KJm5ic3A7ICZuYnNw OyAmZ3Q7IGRhdGEuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAm Z3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IFMgMi4yLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhpcyBzdXBwb3J0cyB1c2Ugb2YgdGhpcyBpbmZv cm1hdGlvbiBieSBvbi1wYXRoIGRldmljZXMsIGJ1dCBhdCB0aGU8YnI+DQombmJzcDsgJm5ic3A7 ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IHNhbWUgdGltZSBjYW4gYmUgZXhwZWN0ZWQg dG8gbGVhZCB0byBvc3NpZmljYXRpb24gb2YgdGhlIHRyYW5zcG9ydDxicj4NCiZuYnNwOyAmbmJz cDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgaGVhZGVyLCBiZWNhdXNlIG5ldHdvcmsg Zm9yd2FyZGluZyBjb3VsZCBldm9sdmUgdG8gZGVwZW5kIG9uIHRoZTxicj4NCiZuYnNwOyAmbmJz cDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgcHJlc2VuY2UgYW5kL29yIHZhbHVlIG9m IHRoZXNlIGZpZWxkcy4mbmJzcDsgVG8gYXZvaWQgdW53YW50ZWQgaW5zcGVjdGlvbiw8YnI+DQom bmJzcDsgJm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IGEgcHJvdG9jb2wgY291 bGQgaW50ZW50aW9uYWxseSB2YXJ5IHRoZSBmb3JtYXQgb3IgdmFsdWUgb2YgZXhwb3NlZDxicj4N CiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgaGVhZGVyIGZpZWxk cyBbSS1ELmlldGYtdGxzLWdyZWFzZV0uPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5i c3A7ICZuYnNwOyAmZ3Q7IEl0J3Mgbm90IGp1c3QgYSBtYXR0ZXIgb2YgdW53YW50ZWQgaW5zcGVj dGlvbi4gVGhlcmUncyBhIHJlYWwgcXVlc3Rpb248YnI+DQombmJzcDsgJm5ic3A7ICZndDsgYWJv dXQgd2hldGhlciB3ZSB3YW50IHRoZXNlIG9uLXBhdGggZGV2aWNlcyB0byBoYXZlIHRoaXMgaW5m b3JtYXRpb248YnI+DQombmJzcDsgJm5ic3A7ICZndDsgYXQgYWxsLCBhcyBpdCBpcyBwb3RlbnRp YWxseSB1c2VkIGZvciBzdXJ2ZWlsbGFuY2UsIHRyYWZmaWM8YnI+DQombmJzcDsgJm5ic3A7ICZn dDsgYW5hbHlzaXMsIGV0Yy48YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5i c3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsg UyAyLi4yLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAm Z3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBXaGlsZSBlbmNyeXB0aW9uIGNhbiBoaWRlIHRy YW5zcG9ydCBoZWFkZXIgaW5mb3JtYXRpb24sIGl0IGRvZXMgbm90PGJyPg0KJm5ic3A7ICZuYnNw OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBwcmV2ZW50IG9zc2lmaWNhdGlvbiBvZiB0 aGUgbmV0d29yayBzZXJ2aWNlLiZuYnNwOyBQZW9wbGUgc2Vla2luZyB0bzxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdW5kZXJzdGFuZCBuZXR3b3JrIHRy YWZmaWMgY291bGQgY29tZSB0byByZWx5IG9uIHBhdHRlcm4gaW5mZXJlbmNlczxicj4NCiZuYnNw OyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgYW5kIG90aGVyIGhldXJpc3Rp Y3MgYXMgdGhlIGJhc2lzIGZvciBuZXR3b3JrIGRlY2lzaW9uIGFuZCB0byBkZXJpdmU8YnI+DQom bmJzcDsgJm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IG1lYXN1cmVtZW50IGRh dGEuJm5ic3A7IFRoaXMgY2FuIGNyZWF0ZSBuZXcgZGVwZW5kZW5jaWVzIG9uIHRoZSB0cmFuc3Bv cnQ8YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgVGhpcyBh bHNvIHNlZW1zIHF1aXRlIGNvbnRlc3RlZC4gRG8geW91IGhhdmUgYW55IGV2aWRlbmNlIG9mIHN1 Y2ggYTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyB0aGluZyBoYXBwZW5pbmc/PGJyPg0KJm5ic3A7 ICZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAm Z3Q7IFMgMi4zLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2Fub21hbGllcywgYW5kIGZhaWx1cmUgcGF0aG9sb2dpZXMgYXQgYW55 IHBvaW50IGFsb25nIHRoZSBJbnRlcm5ldDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3BhdGguJm5ic3A7IEluIG1hbnkgY2FzZXMs IGl0IGlzIGltcG9ydGFudCB0byByZWxhdGUgb2JzZXJ2YXRpb25zIHRvPGJyPg0KJm5ic3A7ICZu YnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3BlY2lmaWMg ZXF1aXBtZW50L2NvbmZpZ3VyYXRpb25zIG9yIG5ldHdvcmsgc2VnbWVudHMuPGJyPg0KJm5ic3A7 ICZuYnNwOyAmZ3Q7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDb25jZWFsaW5nIHRyYW5zcG9ydCBoZWFkZXIgaW5mb3Jt YXRpb24gbWFrZXMgcGVyZm9ybWFuY2UvPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YmVoYXZpb3VyIHVuYXZhaWxhYmxlIHRvIHBh c3NpdmUgb2JzZXJ2ZXJzIGFsb25nIHRoZSBwYXRoLDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxi cj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBXaGlsZSBhbHNvIG1ha2luZyB0cmFmZmljIGFuYWx5c2lz IG1vcmUgZGlmZmljdWx0Ljxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJz cDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBTIDIuMy48YnI+DQombmJzcDsgJm5ic3A7 ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthcHBsaWNhdGlvbnMg aXQgaXMgaW1wb3J0YW50IHRvIHJlbGF0ZSBvYnNlcnZhdGlvbnMgdG8gc3BlY2lmaWM8YnI+DQom bmJzcDsgJm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtl cXVpcG1lbnQvY29uZmlndXJhdGlvbnMgb3IgcGFydGljdWxhciBuZXR3b3JrIHNlZ21lbnRzLjxi cj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Q29uY2VhbGluZyB0cmFuc3BvcnQgaGVh ZGVyIGluZm9ybWF0aW9uIGNhbiBtYWtlIGFuYWx5c2lzIGhhcmRlcjxicj4NCiZuYnNwOyAmbmJz cDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO29yIGltcG9zc2li bGUuJm5ic3A7IFRoaXMgY291bGQgaW1wYWN0IHRoZSBhYmlsaXR5IGZvciBhbiBvcGVyYXRvciB0 bzxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2FudGljaXBhdGUgdGhlIG5lZWQgZm9yIG5ldHdvcmsgdXBncmFkZXMgYW5kIHJvbGwt b3V0LiZuYnNwOyBJdCBjYW48YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5i c3A7ICZndDsgT3IgdG8gcmVkdWNlIHRoZSBvcHBvcnR1bml0aWVzIGZvciB0cmFmZmljIGRpc2Ny aW1pbmF0aW9uLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBTIDIuMy48YnI+DQombmJzcDsgJm5ic3A7ICZndDsg Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgRGlm ZmVyZW50IHBhcnRpZXMgd2lsbCB2aWV3IHRoZSByZWxhdGl2ZSBpbXBvcnRhbmNlIG9mIHRoZXNl IGlzc3Vlczxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg ZGlmZmVyZW50bHkuJm5ic3A7IEZvciBzb21lLCB0aGUgYmVuZWZpdHMgb2YgZW5jcnlwdGluZyBz b21lLCBvciBhbGwsIG9mPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyB0aGUgdHJhbnNwb3J0IGhlYWRlcnMgbWF5IG91dHdlaWdoIHRoZSBpbXBhY3Qgb2Yg ZG9pbmcgc287IG90aGVyczxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgbWlnaHQgbWFrZSBhIGRpZmZlcmVudCB0cmFkZS1vZmYuJm5ic3A7IFRoZSBwdXJw b3NlIG9mIGhpZ2hsaWdodGluZyB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7IHRyYWRlLW9mZnMgaXMgdG8gbWFrZSBzdWNoIGFuYWx5c2lzIHBvc3Np YmxlLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBUaGlz IHdob2xlIHNlY3Rpb24gc2VlbXMgdG8gcmVhbGx5IGp1c3QgaWdub3JlIHRoZSBmYWN0IHRoYXQg bWFueSBvZjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyB0aGVzZSBwcmFjdGljZXMgYXJlIHVud2Fu dGVkLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4N CiZuYnNwOyAmbmJzcDsgJmd0OyBTIDMuMS48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7IEZpcmV3YWxscykuJm5ic3A7IENvbW1vbiBpc3N1ZXMgY29uY2Vy bmluZyBJUCBhZGRyZXNzIHNoYXJpbmcgYXJlPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyBkZXNjcmliZWQgaW4gW1JGQzYyNjldLjxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7 My4xLiZuYnNwOyBPYnNlcnZpbmcgVHJhbnNwb3J0IEluZm9ybWF0aW9uIGluIHRoZSBOZXR3b3Jr PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7IElmIGluLW5ldHdvcmsgb2JzZXJ2YXRpb24gb2YgdHJhbnNw b3J0IHByb3RvY29sIGhlYWRlcnMgaXMgbmVlZGVkLDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxi cj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBXaHkgaXMgdGhpcyBuZWVkZWQ/IEkga25vdyBzb21lIHBl b3BsZSBtaWdodCB3YW50IGl0Ljxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAm bmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBTIDMuMS4xLjxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOzMuMS4xLiZuYnNwOyBGbG93IElkZW50aWZpY2F0 aW9uIFVzaW5nIFRyYW5zcG9ydCBMYXllciBIZWFkZXJzPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7 ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IEZs b3cgaWRlbnRpZmljYXRpb24gaXMgYSBjb21tb24gZnVuY3Rpb24uJm5ic3A7IEZvciBleGFtcGxl LCBwZXJmb3JtZWQgYnk8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7IG1lYXN1cmVtZW50IGFjdGl2aXRpZXMsIFFvUyBjbGFzc2lmaWNhdGlvbiwgZmlyZXdh bGxzLCBEZW5pYWwgb2Y8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7IFNlcnZpY2UsIERPUywgcHJldmVudGlvbi4mbmJzcDsgVGhpcyBiZWNvbWVzIG1vcmUg Y29tcGxleCBhbmQgbGVzcyBlYXNpbHk8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7IGFjaGlldmVkIHdoZW4gbXVsdGlwbGV4aW5nIGlzIHVzZWQgYXQgb3Ig YWJvdmUgdGhlIHRyYW5zcG9ydCBsYXllci48YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQom bmJzcDsgJm5ic3A7ICZndDsgQWxzbyB0cmFmZmljIGRpc2NyaW1pbmF0aW9uIGFuZCBibG9ja2lu Zy48YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQom bmJzcDsgJm5ic3A7ICZndDsgUyAzLjEuMS48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7IHVzZSBoZXVyaXN0aWNzIHRvIGluZmVyIHRoYXQgc2hvcnQgVURQ IHBhY2tldHMgd2l0aCByZWd1bGFyIHNwYWNpbmc8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7IGNhcnJ5IGF1ZGlvIHRyYWZmaWMuJm5ic3A7IE9wZXJhdGlv bmFsIHByYWN0aWNlcyBhaW1lZCBhdCBpbmZlcnJpbmc8YnI+DQombmJzcDsgJm5ic3A7ICZndDsg Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IHRyYW5zcG9ydCBwYXJhbWV0ZXJzIGFyZSBvdXQgb2Yg c2NvcGUgZm9yIHRoaXMgZG9jdW1lbnQsIGFuZCBhcmUgb25seTxicj4NCiZuYnNwOyAmbmJzcDsg Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgbWVudGlvbmVkIGhlcmUgdG8gcmVjb2duaXpl IHRoYXQgZW5jcnlwdGlvbiBkb2VzIG5vdCBwcmV2ZW50PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7 ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBvcGVyYXRvcnMgZnJvbSBhdHRlbXB0aW5nIHRvIGFw cGx5IHByYWN0aWNlcyB0aGF0IHdlcmUgdXNlZCB3aXRoPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7 ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyB1bmVuY3J5cHRlZCB0cmFuc3BvcnQgaGVhZGVycy48 YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgVGhpcyBoYXMg YSByZWFsbHkgdGhyZWF0ZW5pbmcgdG9uZS4gSWYgeW91IGRvbid0IGdpdmUgdXMgd2hhdCB3ZSB3 YW50LDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBsb29rIHdoYXQgY291bGQgaGFwcGVuLjxicj4N CiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyBTIDMuMS4yLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJm5i c3A7ICZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGlzIGluZm9ybWF0aW9u IGNhbiBzdXBwb3J0IG5ldHdvcmsgb3BlcmF0aW9ucywgaW5mb3JtIGNhcGFjaXR5PGJyPg0KJm5i c3A7ICZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBwbGFubmluZywgYW5kIGFz c2lzdCBpbiBkZXRlcm1pbmluZyB0aGUgbmVlZCBmb3IgZXF1aXBtZW50IGFuZC9vcjxicj4NCiZu YnNwOyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgY29uZmlndXJhdGlvbiBj aGFuZ2VzIGJ5IG5ldHdvcmsgb3BlcmF0b3JzLiZuYnNwOyBJdCBjYW4gYWxzbyBpbmZvcm08YnI+ DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IEludGVybmV0IGVu Z2luZWVyaW5nIGFjdGl2aXRpZXMgYnkgaW5mb3JtaW5nIHRoZSBkZXZlbG9wbWVudCBvZiBuZXc8 YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IHByb3RvY29s cywgbWV0aG9kb2xvZ2llcywgYW5kIHByb2NlZHVyZXMuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7 PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IFdoYXQgaXMgdGhlIHBvaW50IG9mIHRoaXMgZXhoYXVz dGl2ZSBsaXN0Pzxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBTIDMuMS4zLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 OyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7QVFNIGFuZCBFQ04gb2ZmZXIgYSByYW5nZSBvZiBhbGdvcml0aG1zIGFuZCBj b25maWd1cmF0aW9uIG9wdGlvbnMuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VG9vbHMgdGhlcmVmb3JlIG5lZWQgdG8gYmUgYXZh aWxhYmxlIHRvIG5ldHdvcmsgb3BlcmF0b3JzIGFuZDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Jlc2VhcmNoZXJzIHRvIHVuZGVy c3RhbmQgdGhlIGltcGxpY2F0aW9uIG9mIGNvbmZpZ3VyYXRpb24gY2hvaWNlczxicj4NCiZuYnNw OyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FuZCB0 cmFuc3BvcnQgYmVoYXZpb3VyIGFzIHRoZSB1c2Ugb2YgRUNOIGluY3JlYXNlcyBhbmQgbmV3PGJy Pg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7bWV0aG9kcyBlbWVyZ2UgW1JGQzc1NjddLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4N CiZuYnNwOyAmbmJzcDsgJmd0OyBRVUlDIHNvcnQgb2YgaGlkZXMgRUNOIGZlZWRiYWNrIGJ1dCBu b3QgRUNOIG1hcmtpbmcuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNw OyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IFMgMy4yLjQuPGJyPg0KJm5ic3A7ICZuYnNw OyAmZ3Q7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtBIG5ldHdvcmsgb3BlcmF0b3IgbmVlZHMgdG9vbHMgdG8gdW5kZXJz dGFuZCBpZiBkYXRhZ3JhbSBmbG93czxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyhlLmcuLCB1c2luZyBVRFApIGNvbXBseSB3aXRo IGNvbmdlc3Rpb24gY29udHJvbCBleHBlY3RhdGlvbnMgYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyAm Z3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlcmVmb3JlIHdoZXRo ZXIgdGhlcmUgaXMgYSBuZWVkIHRvIGRlcGxveSBtZXRob2RzIHN1Y2ggYXMgcmF0ZS08YnI+DQom bmJzcDsgJm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDts aW1pdGVycywgdHJhbnNwb3J0IGNpcmN1aXQgYnJlYWtlcnMsIG9yIG90aGVyIG1ldGhvZHMgdG8g ZW5mb3JjZTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO2FjY2VwdGFibGUgdXNhZ2UgZm9yIHRoZSBvZmZlcmVkIHNlcnZpY2UuPGJy Pg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IERvZXMgaXQgKm5l ZWQqIGl0IG9yIGRvZXMgaXQganVzdCB3YW50IGl0LiBOb3RlIHRoYXQgd2UgaGF2ZSBoYWQgRFRM Uy08YnI+DQombmJzcDsgJm5ic3A7ICZndDsgU0NUUCB3aXRoIFdlYlJUQyB3aXRob3V0IHRoaXMg cHJvcGVydHkgZm9yIHNvbWUgdGltZSBub3cuIENhbiB5b3UgcHJvdmlkZTxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyBzb21lIGV2aWRlbmNlIHRoYXQgb3BlcmF0b3JzIGhhdmUgYmVlbiBpbmNvbnZl bmllbmNlZCBieSBub3QgaGF2aW5nIGl0Ljxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZu YnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBTIDMuMy48YnI+DQombmJz cDsgJm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IG9wZXJhdG9ycyBicmluZyB0 b2dldGhlciBoZXRlcm9nZW5lb3VzIHR5cGVzIG9mIG5ldHdvcmsgZXF1aXBtZW50IGFuZDxicj4N CiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgc2VlayB0byBkZXBs b3kgb3Bwb3J0dW5pc3RpYyBtZXRob2RzIHRvIGFjY2VzcyByYWRpbyBzcGVjdHJ1bS48YnI+DQom bmJzcDsgJm5ic3A7ICZndDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgQSBmbG93IHRoYXQgY29uY2VhbHMgaXRzIHRyYW5zcG9ydCBoZWFkZXIg aW5mb3JtYXRpb24gY291bGQgaW1wbHk8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZxdW90O2Rvbid0IHRvdWNoJnF1b3Q7IHRvIHNvbWUgb3BlcmF0b3Jz LiZuYnNwOyBUaGlzIGNvdWxkIGxpbWl0IGEgdHJvdWJsZS1zaG9vdGluZzxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVzcG9uc2UgdG8gJnF1b3Q7Y2Fu J3QgaGVscCwgbm8gdHJvdWJsZSBmb3VuZCZxdW90Oy48YnI+DQombmJzcDsgJm5ic3A7ICZndDs8 YnI+DQombmJzcDsgJm5ic3A7ICZndDsgV2UgaGF2ZSBxdWl0ZSBhIGJpdCBvZiBRVUlDIHRyYWZm aWMgbm93LiBJJ2QgYmUgaW50ZXJlc3RlZCBpbiBoZWFyaW5nPGJyPg0KJm5ic3A7ICZuYnNwOyAm Z3Q7IGZyb20gdGhlIGdRVUlDIHRlYW0gd2hldGhlciB0aGV5IGhhdmUgc2VlbiBhbnl0aGluZyBs aWtlIHRoaXMuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBRVUlDIHByZXNlbnRzIGEgcHJvYmxl bSBpbiBpdHNlbGYgc2luY2UgdGhlIFFVSUMgaGFyZGVycyBhcmUgaW5zaWRlPGJyPg0KJm5ic3A7 ICZuYnNwOyB0aGUgVURQIHBheWxvYWQgc28gaW50ZXJtZWRpYXRlIGRldmljZXMgZW5kIHVwIG5l ZWRpbmcgdG8gcGFyc2UgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyBVRFAgdHJhbnNwb3J0IHBheWxv YWQuIEkgYmVsaWV2ZSB0aGUgb25seSB3YXkgdG8gaWRlbnRpZnkgYSBRVUlDPGJyPg0KJm5ic3A7 ICZuYnNwOyBwYWNrZXQgaXMgYnkgbWF0Y2hpbmcgcG9ydCBudW1iZXJzLCBidXQgcGVyIFJGQzc2 MDUgaW50ZXJwcmV0YXRpb24gb2Y8YnI+DQombmJzcDsgJm5ic3A7IHBvcnQgbnVtYmVycyBpbiB0 aGUgbWlkZGxlIG9mIHRoZSBuZXR3b3JrIGlzIHByb25lIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyBt aXNpbnRlcnByZXRhdGlvbi4gRXZlbnR1YWxseSwgc29tZXRoaW5nIHRoYXQgbG9va3MgbGlrZSBh IFFVSUMgcGFja2V0PGJyPg0KJm5ic3A7ICZuYnNwOyBiYXNlZCBvbiBwb3J0IG51bWJlciB3aWxs IGJlIG1pc2ludGVycHJldGVkLiBMb29raW5nIGF0PGJyPg0KJm5ic3A7ICZuYnNwOyBkcmFmdC1p ZXRmLXF1aWMtdHJhbnNwb3J0LTIzLCBJIGRvbid0IHNlZSBhbnkgZGlzY3Vzc2lvbiBhYm91dCB0 aGlzIG9yPGJyPg0KJm5ic3A7ICZuYnNwOyByZWZlcmVuY2UgdG8gUkZDNzYwNS4gTm90ZSB0aGlz IGlzIHRydWUgZm9yIGFueSB1c2UgY2FzZSBvZiBVRFA8YnI+DQombmJzcDsgJm5ic3A7IGluY2x1 ZGluZyB0cmFuc3BvcnQgbGF5ZXIgb3IgbmV0d29yayBsYXllciBlbmNhcHN1bGF0aW9uLiBFdmVu IGlmIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgYXJndW1lbnQgaXMgdGhhdCB0aGUgaW5mb3JtYXRp b24gaXMgb25seSBiZWluZyByZWFkIGFuZDxicj4NCiZuYnNwOyAmbmJzcDsgbWlzaW50ZXJwcmV0 YXRpb24gaXMgaW5ub2N1b3VzLCBpdCBzdGlsbCB3b3VsZG4ndCBiZSByb2J1c3QgcHJvdG9jb2wu PGJyPg0KJm5ic3A7ICZuYnNwOyBUaGlzIGNhbiBiZSBjb250cmFzdGVkIHRvIHB1dHRpbmcgdGhl IGluZm9ybWF0aW9uIGluIEhCSCBvcHRpb25zIHdoaWNoPGJyPg0KJm5ic3A7ICZuYnNwOyBjYW4g YmUgY29ycmVjdGx5IGFuZCB1bmFtYmlndW91c2x5IGlkZW50aWZpZWQgYW55d2hlcmUgaW4gdGhl IG5ldHdvcmsuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUb208YnI+DQo8YnI+DQombmJzcDsg Jm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZn dDsgUyA0Ljxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAm Z3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGVyZSBhcmUgc2V2ZXJhbCBtb3RpdmF0aW9u cyBmb3IgZW5jcnlwdGlvbjo8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0Ozxicj4NCiZuYnNw OyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgbyZuYnNwOyBPbmUgbW90aXZl IHRvIHVzZSBlbmNyeXB0aW9uIGlzIGEgcmVzcG9uc2UgdG8gcGVyY2VwdGlvbnMgdGhhdCB0aGU8 YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtuZXR3b3JrIGhhcyBiZWNvbWUgb3NzaWZpZWQgYnkgb3Zlci1yZWxpYW5jZSBvbiBtaWRk bGVib3hlcyB0aGF0PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7cHJldmVudCBuZXcgcHJvdG9jb2xzIGFuZCBtZWNoYW5pc21zIGZy b20gYmVpbmcgZGVwbG95ZWQuJm5ic3A7IFRoaXM8YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+ DQombmJzcDsgJm5ic3A7ICZndDsgVGhpcyBpc24ndCBqdXN0IGEgcGVyY2VwdGlvbiwgaXQncyBh IGRlbW9uc3RyYWJsZSByZWFsaXR5Ljxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNw OyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBTIDQuPGJyPg0KJm5ic3A7ICZu YnNwOyAmZ3Q7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7IG8mbmJzcDsgT25lIG1vdGl2ZSB0byB1c2UgZW5jcnlwdGlvbiBpcyBhIHJlc3BvbnNl IHRvIHBlcmNlcHRpb25zIHRoYXQgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bmV0d29yayBoYXMgYmVjb21lIG9zc2lmaWVk IGJ5IG92ZXItcmVsaWFuY2Ugb24gbWlkZGxlYm94ZXMgdGhhdDxicj4NCiZuYnNwOyAmbmJzcDsg Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3ByZXZlbnQgbmV3IHBy b3RvY29scyBhbmQgbWVjaGFuaXNtcyBmcm9tIGJlaW5nIGRlcGxveWVkLiZuYnNwOyBUaGlzPGJy Pg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7aGFzIGxlYWQgdG8gYSBwZXJjZXB0aW9uIHRoYXQgdGhlcmUgaXMgdG9vIG11Y2ggJnF1b3Q7 bWFuaXB1bGF0aW9uJnF1b3Q7IG9mPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cHJvdG9jb2wgaGVhZGVycyB3aXRoaW4gdGhlIG5l dHdvcmssIGFuZCB0aGF0IGRlc2lnbmluZyB0byBkZXBsb3k8YnI+DQombmJzcDsgJm5ic3A7ICZn dDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgTm90IGp1c3QgbWFuaXB1bGF0aW9uLCBhbHNvIGlu c3BlY3Rpb24uPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7 PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IFMgNC48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0 Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO09uZSBleGFtcGxlIG9mIGVuY3J5cHRpb24gYXQgdGhlIG5ldHdvcmsgbGF5ZXIgaXMg dGhlIHVzZSBvZiBJUHNlYzxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0VuY2Fwc3VsYXRpbmcgU2VjdXJpdHkgUGF5bG9hZCAoRVNQ KSBbUkZDNDMwM10gaW4gdHVubmVsIG1vZGUuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhpcyBlbmNyeXB0cyBhbmQgYXV0aGVu dGljYXRlcyBhbGwgdHJhbnNwb3J0IGhlYWRlcnMsIHByZXZlbnRpbmc8YnI+DQombmJzcDsgJm5i c3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt2aXNpYmlsaXR5 IG9mIHRoZSB0cmFuc3BvcnQgaGVhZGVycyBieSBpbi1uZXR3b3JrIGRldmljZXMuJm5ic3A7IFNv bWU8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtWUE4gbWV0aG9kcyBhbHNvIGVuY3J5cHQgdGhlc2UgaGVhZGVycy48YnI+DQombmJz cDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgVGhpcyBzZWVtcyBsaWtlIGEg YmFkIGV4YW1wbGUgYXMgcGFydCBvZiB0aGUgcG9pbnQgb2YgYSBWUE4gaXMgdG88YnI+DQombmJz cDsgJm5ic3A7ICZndDsgY29uY2VhbCB0aGUgaGVhZGVycyBmb3JtIHRoZSBuZXR3b3JrLjxicj4N CiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyBTIDYuMS48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0Ozxicj4NCiZuYnNw OyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOzYuMS4mbmJzcDsgSW5kZXBlbmRlbnQgTWVh c3VyZW1lbnQ8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsg Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgSW5kZXBlbmRlbnQgb2JzZXJ2YXRpb24gYnkg bXVsdGlwbGUgYWN0b3JzIGlzIGltcG9ydGFudCBpZiB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZn dDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IHRyYW5zcG9ydCBjb21tdW5pdHkgaXMgdG8gbWFp bnRhaW4gYW4gYWNjdXJhdGUgdW5kZXJzdGFuZGluZyBvZiB0aGU8YnI+DQombmJzcDsgJm5ic3A7 ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IG5ldHdvcmsuJm5ic3A7IEVuY3J5cHRpbmcg dHJhbnNwb3J0IGhlYWRlciBlbmNyeXB0aW9uIGNoYW5nZXMgdGhlIGFiaWxpdHk8YnI+DQombmJz cDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgVGhpcyBpcyBpcm9uaWMgYmVj YXVzZSBRVUlDIGlzIG11Y2ggYmV0dGVyIGZvciBlbmRwb2ludCBtZWFzdXJlbWVudDxicj4NCiZu YnNwOyAmbmJzcDsgJmd0OyB0aGFuIFRDUCBiZWNhdXNlIHRoZSBkZXRhaWxzIGFyZSBhY2Nlc3Np YmxlIGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllci48YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+ DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgUyA4Ljxicj4NCiZu YnNwOyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgZXhhbXBsZSwgYW4gYXR0 YWNrZXIgY291bGQgY29uc3RydWN0IGEgRE9TIGF0dGFjayBieSBzZW5kaW5nIHBhY2tldHM8YnI+ DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IHdpdGggYSBzZXF1 ZW5jZSBudW1iZXIgdGhhdCBmYWxscyB3aXRoaW4gdGhlIGN1cnJlbnRseSBhY2NlcHRlZCByYW5n ZTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgb2Ygc2Vx dWVuY2UgbnVtYmVycyBhdCB0aGUgcmVjZWl2aW5nIGVuZHBvaW50LCB0aGlzIHdvdWxkIHRoZW48 YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IGludHJvZHVj ZSBhZGRpdGlvbmFsIHdvcmsgYXQgdGhlIHJlY2VpdmluZyBlbmRwb2ludCwgZXZlbiB0aG91Z2gg dGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBkYXRh IGluIHRoZSBhdHRhY2tpbmcgcGFja2V0IG1heSBub3QgZmluYWxseSBiZSBkZWxpdmVyZWQgYnkg dGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyB0cmFu c3BvcnQgbGF5ZXIuJm5ic3A7IFRoaXMgaXMgc29tZXRpbWVzIGtub3duIGFzIGEgJnF1b3Q7c2hh ZG93aW5nIGF0dGFjayZxdW90Oy48YnI+DQombmJzcDsgJm5ic3A7ICZndDs8YnI+DQombmJzcDsg Jm5ic3A7ICZndDsgVGhpcyBkb2Vzbid0IHNlZW0gdG8gYmUgYW4gaXNzdWUgd2l0aCBwcm90b2Nv bHMgdGhhdCBhdXRoZW50aWNhdGUgdGhlIFNOLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4N CiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBTIDguPGJyPg0KJm5i c3A7ICZuYnNwOyAmZ3Q7ICZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7IEFuIGF0dGFjayBjYW4sIGZvciBleGFtcGxlLCBkaXNydXB0IHJlY2VpdmVy IHByb2Nlc3NpbmcsIHRyaWdnZXIgbG9zczxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgYW5kIHJldHJhbnNtaXNzaW9uLCBvciBtYWtlIGEgcmVjZWl2aW5n IGVuZHBvaW50IHBlcmZvcm0gdW5wcm9kdWN0aXZlPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBkZWNyeXB0aW9uIG9mIHBhY2tldHMgdGhhdCBjYW5ub3Qg YmUgc3VjY2Vzc2Z1bGx5IGRlY3J5cHRlZCAoZm9yY2luZzxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgYSByZWNlaXZlciB0byBjb21taXQgZGVjcnlwdGlv biByZXNvdXJjZXMsIG9yIHRvIHVwZGF0ZSBhbmQgdGhlbjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVzdG9yZSBwcm90b2NvbCBzdGF0ZSkuPGJyPg0K Jm5ic3A7ICZuYnNwOyAmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IFRoaXMgaXMgbm90IGEg cmVhbCBpc3N1ZSBmb3IgUVVJQyBvciBzaW1pbGFyIHByb3RvY29sczxicj4NCiZuYnNwOyAmbmJz cDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxi cj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNw OyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsg Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4N CiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAm bmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 Ozxicj4NCiZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_D36061F0F8724054ACF0C9A88FCEC572ericssoncom_-- From nobody Mon Nov 4 08:16:47 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B36120120; Mon, 4 Nov 2019 08:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77HgEs3m11Cx; Mon, 4 Nov 2019 08:16:34 -0800 (PST) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::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 85C721200EF; Mon, 4 Nov 2019 08:16:34 -0800 (PST) Received: by mail-oi1-x236.google.com with SMTP id l20so2509336oie.10; Mon, 04 Nov 2019 08:16:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=igC8Ah4rtkDYZYAPETW+32AyaS8CMGgavqZvRtJ6Axg=; b=uAjp7dv3XY06jpG8NoqSvDONUdNl+QumMiPmxCXN5fab2vY+SpqpmZ4tD9HLX/qdDf FHxUyr4jdiUl7TkmpDlydeWzixGcGWgmP2DnbjuGvK5NyEp7Z3LCAUYFl0DbNPcMNme9 iyTC247sbPUAylpAFkd33bHalZiMWRjHTVeh7uPqVWvVKUW1dR4OjQ7nBY70fv1kJMQZ 5r2b07ugK7yxJRgzQqYrT2MYrlAzlgsh/eXEN2h40H/A8uXgyzZd1i4vkiwcV86IJhKK HT4+xKZCz5D3xKF48TMZcm4XSCphZOFgqOLnzMt9kUeUhEpnGwBx6fiGS4afJ4PgIweu IuSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=igC8Ah4rtkDYZYAPETW+32AyaS8CMGgavqZvRtJ6Axg=; b=ov/lBKImRzJUai8Mo0kp8hPCUVBABBPOZVHKEMJ+391wy8xrHfRkbc3DZ+ASE3Vgod K0SFFXYgyLr7e4AQWUxmTAFq2XhTCrFC46kdJPZ0P/T/hOm109rfqCIvr8Ap9y7Ya3K8 V/zqDF7WIskebvcmg85+UqKEviKJgrcoKjolDYQUky8RyukWAV28BQ0AesJk4Qo5g78Y xT4Gm6VdAlnd5ODIcROdinD9rBRD6HagVQKx8FXWvQp53y6LuGqVN32NWoJB5Ec5lmuf rao/j47LmKMp01mBugmlogwznmEihqNryblgUkHbKilD/fzsFXXnlEVLiP4OW6Wc1MAH oUUA== X-Gm-Message-State: APjAAAVcaTjMjm+ZE2/Db0Z24UgzQ814SikMUpvp2rQu99WbaKV7mK/6 seIltLY+pj5j5Y2RihhDeEP0RjnFMj1PtVMhjek= X-Google-Smtp-Source: APXvYqy9YFuzvpjmR5Syv6ED/qJuzQUjw1lu1WaqJZZlyfqX44oBAP0Q07OCUoX2zWPMtCFPTEXNd1z7Q7viKhH/cgk= X-Received: by 2002:aca:5d8a:: with SMTP id r132mr19193132oib.119.1572884193579; Mon, 04 Nov 2019 08:16:33 -0800 (PST) MIME-Version: 1.0 References: <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com> In-Reply-To: From: Kathleen Moriarty Date: Mon, 4 Nov 2019 11:15:57 -0500 Message-ID: To: Mirja Kuehlewind Cc: Eric Rescorla , Tom Herbert , tsvwg IETF list , "saag@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a19785059687a3d8" Archived-At: Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 16:16:40 -0000 --000000000000a19785059687a3d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 4, 2019 at 10:00 AM Mirja Kuehlewind wrote: > Hi Ekr, > > > > see inline, marked [MK]=E2=80=A6 > > > > Mirja > > > > > > *From: *Eric Rescorla > *Date: *Monday, 4. November 2019 at 14:57 > *To: *Mirja Kuehlewind > *Cc: *Tom Herbert , tsvwg IETF list = , > "saag@ietf.org" > *Subject: *Re: [tsvwg] Comments on > draft-ietf-tsvwg-transport-encrypt-08.txt > > > > > > > > On Mon, Nov 4, 2019 at 1:14 AM Mirja Kuehlewind < > mirja.kuehlewind@ericsson.com> wrote: > > Hi Ekr, hi all, > > Just on this part: > > - The community of people designing new transport protocols has > > already weighed all the considerations here and come down pretty > > decisively on the side of "encrypt all the things". Given that > > both SCTP-over-DTLS and QUIC do this, it seems pretty unlikely > > we're going to design a new transport protocol that doesn't. > I disagree that this is the conclusion the community came to, otherwise w= e > would not have put a signal for the network in the QUIC header. Also > encryption has a cost and that's the discussion we continuously still > having in QUIC and well as other working groups. So "encrypt all the > things" is way too simplified and for sure not a consensus statement whic= h > this draft (draft-ietf-tsvwg-transport-encrypt) clearly shows. > > > > Well, we put a single, optional, bit in the header and everything else we > could figure out how to encrypt encrypted. It's true that encryption has = a > cost to the design of the protocol and to the endpoint implementations an= d > we've been trying to balance that cost against the value, but that's not > because the group isn't trying to encrypt as much as possible. > > > > [MK]I don=E2=80=99t think we need to nit-pick here but I think "encrypt a= ll the > things" and =E2=80=9Cencrypt as much as possible=E2=80=9D is not the same= , especially as > =E2=80=9Cpossible=E2=80=9D is something to argue about when it comes to t= he question of how > much you are willing to pay. However, I don=E2=80=99t think we need to di= scuss this > in details here, just wanted to say that I don=E2=80=99t think the situat= ion is a > simple as you have stated and I don=E2=80=99t think there is consensus fo= r a simple > "encrypt all the things". > > > > I certainly realize that there are people who are sad about this -- as yo= u > rightly point out reflected in this draft =E2=80=93 > > > > [MK] I don=E2=80=99t think people are sad about increasing amount of encr= yption. > But when we change things we also need to have a discussion of the > implication of this change and cannot just close our eyes. As I said in > some cases we might be happy about things that hopefully just go away, in > other cases it may actually have more severe impact of the viability of t= he > Internet as a interconnected network that is operated by different entiti= es. > > > > but I believe they are in the rough, at least of the community of people > actively designing and deploying new protocols. > > > > [MK] I don=E2=80=99t believe this. Otherwise I wondering why we had such = a lengthy > discussion for more than a year in the QUIC working group. > > > > Do you see any plausible situation in which a new transport protocol isn'= t > largely encrypted? > > > > [MK] That=E2=80=99s not the intention here. But we also need to consider = ways to > interact with the network where this brings benefit to both the network a= nd > the performance of the end-to-end traffic. There are situation where this > is the case. And I don=E2=80=99t think one makes sense without the other. > > > I agree with Mirja. I don't think there is consensus to ignore the problems. If the issues to operators are not enumerated and allowed to be discussed, a way forward for increased deployment of strong e2e is much more difficult. Discussing problems enables a way to create a path forward and will likely lead to faster deployment of strong e2e. People will be resistant if problems are minimally not discussed, if not addressed in other ways. Best regards, Kathleen > > > > > > -Ekr > > > > > Mirja > > > > On 04.11.19, 03:15, "tsvwg on behalf of Tom Herbert" < > tsvwg-bounces@ietf.org on behalf of tom@herbertland.com> wrote: > > On Sun, Nov 3, 2019 at 2:20 PM Eric Rescorla wrote: > > > > After reviewing this document, I share Christian Huitema's concern > > about the tone and perspective of this document, which, while sayin= g > > that encryption is good, then proceeds to mostly lament how difficu= lt > > it makes life for various entities other than the endpoints. It see= ms > > to me rather problematic to publish this document as an RFC for > > several reasons: > > > > - Yes, it's true that the trend towards encrypting everything has > > and continues to make a number of entities sad, but that's a poin= t > > which is already made in RFC 8404. How does all of the additional > > detail here help? > > > > - The community of people designing new transport protocols has > > already weighed all the considerations here and come down pretty > > decisively on the side of "encrypt all the things". Given that > > both SCTP-over-DTLS and QUIC do this, it seems pretty unlikely > > we're going to design a new transport protocol that doesn't. > > > > - Having an IETF Consensus RFC that is so heavily weighted on the > side > > of "this is how encryption inconveniences us" and so light on > "these > > are the attacks we are preventing" gives a misleading picture of > the > > IETF community's view of the relative priority of these > > concerns. ISTM that RFC 8558 -- though perhaps imperfect -- far > more > > closely reflects that consensus. > > > > In short, I do not think this draft should be published as an RFC. > > > I believe the problem with this draft is that it identifies a > perceived problem, but does little to offer a solution other than > saying don't encrypt the transport layer header. As I've mentioned > several times, putting transport layer information of interest into > HBH extension headers is the architecturally correct solution for > hosts to signal the network. This works with any transport layer > protocol and exposure of transport layer information to the network i= s > under explicit control of the end host. IMO, the draft does not > adequately explore this alternative solution and too easily just > brushes it off as being "undesirable" based on one set of snapshot > measurements that is now almost four years old. > > > I have appended a number of detailed comments which IMO need to be > > addressed in any case, but even if they were resolved, that would n= ot > > address my primary concern. > > > > > > COMMENTS > > S 2.1. > > > 2.1. Use of Transport Header Information in the Network > > > > > > In-network measurement of transport flow characteristics can > be used > > > to enhance performance, and control cost and service > reliability. > > > Some operators have deployed functionality in middleboxes to > both > > > support network operations and enhance performance. This > reliance on > > > > This seems like a contested point. My understanding is that while > > these middleboxes are *intended* to enhance performance that there = is > > doubt that they actually do. > > > > > > S 2.1. > > > to enhance performance, and control cost and service > reliability. > > > Some operators have deployed functionality in middleboxes to > both > > > support network operations and enhance performance. This > reliance on > > > the presence and semantics of specific header information > leads to > > > ossification, where an endpoint could be required to supply = a > > > specific header to receive the network service that it > desires. In > > > > Well, not just the network service it desires but *any* service. > > > > > > S 2.1. > > > specific header to receive the network service that it > desires. In > > > some cases, this could be benign or advantageous to the > protocol > > > (e.g., recognising the start of a connection, or explicitly > exposing > > > protocol information can be expected to provide more > consistent > > > decisions by on-path devices than the use of diverse methods > to infer > > > semantics from other flow properties). In other cases, the > > > > Is there evidence of this? > > > > > > S 2.1. > > > > > > As an example of ossification, consider the experience of > developing > > > Transport Layer Security (TLS) 1.3 [RFC8446]. This required > a design > > > that recognised that deployed middleboxes relied on the > presence of > > > certain header filed exposed in TLS 1.2, and failed if those > headers > > > were changed. Other examples of the impact of ossification > can be > > > > I think you mean "fields" and it wasn't headers so much as handshak= e > > data. > > > > > > S 2.2. > > > This supports use of this information by on-path devices, bu= t > at the > > > same time can be expected to lead to ossification of the > transport > > > header, because network forwarding could evolve to depend on > the > > > presence and/or value of these fields. To avoid unwanted > inspection, > > > a protocol could intentionally vary the format or value of > exposed > > > header fields [I-D.ietf-tls-grease]. > > > > It's not just a matter of unwanted inspection. There's a real > question > > about whether we want these on-path devices to have this informatio= n > > at all, as it is potentially used for surveillance, traffic > > analysis, etc. > > > > > > > > S 2..2. > > > > > > While encryption can hide transport header information, it > does not > > > prevent ossification of the network service. People seeking > to > > > understand network traffic could come to rely on pattern > inferences > > > and other heuristics as the basis for network decision and t= o > derive > > > measurement data. This can create new dependencies on the > transport > > > > This also seems quite contested. Do you have any evidence of such a > > thing happening? > > > > > > S 2.3. > > > anomalies, and failure pathologies at any point along the > Internet > > > path. In many cases, it is important to relate > observations to > > > specific equipment/configurations or network segments. > > > > > > Concealing transport header information makes performance= / > > > behaviour unavailable to passive observers along the path= , > > > > While also making traffic analysis more difficult. > > > > > > S 2.3. > > > applications it is important to relate observations to > specific > > > equipment/configurations or particular network segments. > > > > > > Concealing transport header information can make analysis > harder > > > or impossible. This could impact the ability for an > operator to > > > anticipate the need for network upgrades and roll-out. I= t > can > > > > Or to reduce the opportunities for traffic discrimination. > > > > > > S 2.3. > > > > > > Different parties will view the relative importance of these > issues > > > differently. For some, the benefits of encrypting some, or > all, of > > > the transport headers may outweigh the impact of doing so; > others > > > might make a different trade-off. The purpose of > highlighting the > > > trade-offs is to make such analysis possible. > > > > This whole section seems to really just ignore the fact that many o= f > > these practices are unwanted. > > > > > > S 3.1. > > > Firewalls). Common issues concerning IP address sharing are > > > described in [RFC6269]. > > > > > > 3.1. Observing Transport Information in the Network > > > > > > If in-network observation of transport protocol headers is > needed, > > > > Why is this needed? I know some people might want it. > > > > > > S 3.1.1. > > > 3.1.1. Flow Identification Using Transport Layer Headers > > > > > > Flow identification is a common function. For example, > performed by > > > measurement activities, QoS classification, firewalls, Denia= l > of > > > Service, DOS, prevention. This becomes more complex and les= s > easily > > > achieved when multiplexing is used at or above the transport > layer. > > > > Also traffic discrimination and blocking. > > > > > > S 3.1.1. > > > use heuristics to infer that short UDP packets with regular > spacing > > > carry audio traffic. Operational practices aimed at inferri= ng > > > transport parameters are out of scope for this document, and > are only > > > mentioned here to recognize that encryption does not prevent > > > operators from attempting to apply practices that were used > with > > > unencrypted transport headers. > > > > This has a really threatening tone. If you don't give us what we > want, > > look what could happen. > > > > > > S 3.1.2. > > > > > > This information can support network operations, inform > capacity > > > planning, and assist in determining the need for equipment > and/or > > > configuration changes by network operators. It can also > inform > > > Internet engineering activities by informing the development > of new > > > protocols, methodologies, and procedures. > > > > What is the point of this exhaustive list? > > > > > > S 3.1.3. > > > > > > AQM and ECN offer a range of algorithms and configuration > options. > > > Tools therefore need to be available to network operators > and > > > researchers to understand the implication of configuratio= n > choices > > > and transport behaviour as the use of ECN increases and n= ew > > > methods emerge [RFC7567]. > > > > QUIC sort of hides ECN feedback but not ECN marking. > > > > > > S 3.2.4. > > > > > > A network operator needs tools to understand if datagram > flows > > > (e.g., using UDP) comply with congestion control > expectations and > > > therefore whether there is a need to deploy methods such > as rate- > > > limiters, transport circuit breakers, or other methods to > enforce > > > acceptable usage for the offered service. > > > > Does it *need* it or does it just want it. Note that we have had > DTLS- > > SCTP with WebRTC without this property for some time now. Can you > provide > > some evidence that operators have been inconvenienced by not having > it. > > > > > > S 3.3. > > > operators bring together heterogeneous types of network > equipment and > > > seek to deploy opportunistic methods to access radio spectru= m. > > > > > > A flow that conceals its transport header information could > imply > > > "don't touch" to some operators. This could limit a > trouble-shooting > > > response to "can't help, no trouble found". > > > > We have quite a bit of QUIC traffic now. I'd be interested in heari= ng > > from the gQUIC team whether they have seen anything like this. > > QUIC presents a problem in itself since the QUIC harders are inside > the UDP payload so intermediate devices end up needing to parse the > UDP transport payload. I believe the only way to identify a QUIC > packet is by matching port numbers, but per RFC7605 interpretation of > port numbers in the middle of the network is prone to > misinterpretation. Eventually, something that looks like a QUIC packe= t > based on port number will be misinterpreted. Looking at > draft-ietf-quic-transport-23, I don't see any discussion about this o= r > reference to RFC7605. Note this is true for any use case of UDP > including transport layer or network layer encapsulation. Even if the > argument is that the information is only being read and > misinterpretation is innocuous, it still wouldn't be robust protocol. > This can be contrasted to putting the information in HBH options whic= h > can be correctly and unambiguously identified anywhere in the network= . > > Tom > > > > > > > S 4. > > > > > > There are several motivations for encryption: > > > > > > o One motive to use encryption is a response to perceptions > that the > > > network has become ossified by over-reliance on > middleboxes that > > > prevent new protocols and mechanisms from being deployed. > This > > > > This isn't just a perception, it's a demonstrable reality. > > > > > > S 4. > > > > > > o One motive to use encryption is a response to perceptions > that the > > > network has become ossified by over-reliance on > middleboxes that > > > prevent new protocols and mechanisms from being deployed. > This > > > has lead to a perception that there is too much > "manipulation" of > > > protocol headers within the network, and that designing t= o > deploy > > > > Not just manipulation, also inspection. > > > > > > S 4. > > > > > > One example of encryption at the network layer is the use > of IPsec > > > Encapsulating Security Payload (ESP) [RFC4303] in tunnel > mode. > > > This encrypts and authenticates all transport headers, > preventing > > > visibility of the transport headers by in-network > devices. Some > > > VPN methods also encrypt these headers. > > > > This seems like a bad example as part of the point of a VPN is to > > conceal the headers form the network. > > > > > > S 6.1. > > > > > > 6.1. Independent Measurement > > > > > > Independent observation by multiple actors is important if t= he > > > transport community is to maintain an accurate understanding > of the > > > network. Encrypting transport header encryption changes the > ability > > > > This is ironic because QUIC is much better for endpoint measurement > > than TCP because the details are accessible at the application laye= r. > > > > > > S 8. > > > example, an attacker could construct a DOS attack by sending > packets > > > with a sequence number that falls within the currently > accepted range > > > of sequence numbers at the receiving endpoint, this would th= en > > > introduce additional work at the receiving endpoint, even > though the > > > data in the attacking packet may not finally be delivered by > the > > > transport layer. This is sometimes known as a "shadowing > attack". > > > > This doesn't seem to be an issue with protocols that authenticate > the SN. > > > > > > S 8. > > > > > > An attack can, for example, disrupt receiver processing, > trigger loss > > > and retransmission, or make a receiving endpoint perform > unproductive > > > decryption of packets that cannot be successfully decrypted > (forcing > > > a receiver to commit decryption resources, or to update and > then > > > restore protocol state). > > > > This is not a real issue for QUIC or similar protocols > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --=20 Best regards, Kathleen --000000000000a19785059687a3d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 4, 2019 at 10:00 AM Mirja= Kuehlewind <mirja.kuehlewind=3D40ericsson.com@dmarc.ietf.org> wrote:

Hi Ekr,

=C2=A0

see inline, marked [MK]=E2=80= =A6

=C2=A0

Mirja

=C2=A0

=C2=A0

From: Eric Rescorla <ekr@rtfm.com>
Date: Monday, 4. November 2019 at 14:57
To: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
Cc: Tom Herbert <tom@herbertland.com>, tsvwg IETF list <tsvwg@ietf.org>, "saag@ietf.org" <saag@ietf.org>
Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-= 08.txt

=C2=A0

=C2=A0

=C2=A0

On Mon, Nov 4, 2019 at 1:= 14 AM Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> wrote:

Hi Ekr, hi all,

Just on this part:
=C2=A0 =C2=A0 > - The community of people designing new transport protoc= ols has
=C2=A0 =C2=A0 >=C2=A0 =C2=A0already weighed all the considerations here = and come down pretty
=C2=A0 =C2=A0 >=C2=A0 =C2=A0decisively on the side of "encrypt all = the things". Given that
=C2=A0 =C2=A0 >=C2=A0 =C2=A0both SCTP-over-DTLS and QUIC do this, it see= ms pretty unlikely
=C2=A0 =C2=A0 >=C2=A0 =C2=A0we're going to design a new transport pr= otocol that doesn't.
I disagree that this is the conclusion the community came to, otherwise we = would not have put a signal for the network in the QUIC header. Also encryp= tion has a cost and that's the discussion we continuously still having = in QUIC and well as other working groups. So "encrypt all the things" is way too simplified and for sure n= ot a consensus statement which this draft (draft-ietf-tsvwg-transport-encry= pt) clearly shows.

=C2=A0

Well, we put a single, op= tional, bit in the header and everything else we could figure out how to en= crypt encrypted. It's true that encryption has a cost to the design of = the protocol and to the endpoint implementations and we've been trying to balance that cost against the value, but that= 's not because the group isn't trying to encrypt as much as possibl= e.

=C2=A0

[MK]I don=E2=80=99t think we ne= ed to nit-pick here but I think "encrypt all the things" and =E2=80= =9Cencrypt as much as possible=E2=80=9D is not the same, especially as =E2= =80=9Cpossible=E2=80=9D is something to argue about when it comes to the qu= estion of how much you are willing to pay. However, I don=E2=80=99t think w= e need to discuss this in details here, just wanted to say that I don=E2=80=99t think the si= tuation is a simple as you have stated and I don=E2=80=99t think there is c= onsensus for a simple "encrypt all the things".

<= /u>=C2=A0

I ce= rtainly realize that there are people who are sad about this -- as you righ= tly point out reflected in this draft =E2=80=93

=C2=A0

[MK] I don=E2=80=99t think peop= le are sad about increasing amount of encryption. But when we change things= we also need to have a discussion of the implication of this change and ca= nnot just close our eyes. As I said in some cases we might be happy about things that hopefully just go away, in other= cases it may actually have more severe impact of the viability of the Inte= rnet as a interconnected network that is operated by different entities.=

=C2=A0

but = I believe they are in the rough, at least of the community of people active= ly designing and deploying new protocols.

=C2=A0

[MK] I don=E2=80=99t believe th= is. Otherwise I wondering why we had such a lengthy discussion for more tha= n a year in the QUIC working group.

=C2=A0

Do y= ou see any plausible situation in which a new transport protocol isn't = largely encrypted?

=C2=A0

[MK] That=E2=80=99s not the int= ention here. But we also need to consider ways to interact with the network= where this brings benefit to both the network and the performance of the e= nd-to-end traffic. There are situation where this is the case. And I don=E2=80=99t think one makes sense without the ot= her.

=C2=A0

<= /div>

I agree with Mirja.= =C2=A0 I don't think there is consensus to ignore the problems.=C2=A0 = =C2=A0If the issues to operators are not enumerated and allowed to be discu= ssed, a way forward for increased deployment of strong e2e is much more dif= ficult.=C2=A0 Discussing problems enables a way to create a path forward an= d will likely lead to faster deployment of strong e2e. People will be resis= tant if problems are minimally not discussed, if not addressed in other way= s.=C2=A0

Best regards,
Kathleen

=

=C2=A0

=C2=A0

<= /u>=C2=A0

-Ekr

=C2=A0


Mirja



On 04.11.19, 03:15, "tsvwg on behalf of Tom Herbert" <tsvwg-bounces@ietf.org= on behalf of tom@herbertland.co= m> wrote:

=C2=A0 =C2=A0 On Sun, Nov 3, 2019 at 2:20 PM Eric Rescorla <ekr@rtfm.com> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > After reviewing this document, I share Christian Huitema= 's concern
=C2=A0 =C2=A0 > about the tone and perspective of this document, which, = while saying
=C2=A0 =C2=A0 > that encryption is good, then proceeds to mostly lament = how difficult
=C2=A0 =C2=A0 > it makes life for various entities other than the endpoi= nts. It seems
=C2=A0 =C2=A0 > to me rather problematic to publish this document as an = RFC for
=C2=A0 =C2=A0 > several reasons:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > - Yes, it's true that the trend towards encrypting e= verything has
=C2=A0 =C2=A0 >=C2=A0 =C2=A0and continues to make a number of entities s= ad, but that's a point
=C2=A0 =C2=A0 >=C2=A0 =C2=A0which is already made in RFC 8404. How does = all of the additional
=C2=A0 =C2=A0 >=C2=A0 =C2=A0detail here help?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > - The community of people designing new transport protoc= ols has
=C2=A0 =C2=A0 >=C2=A0 =C2=A0already weighed all the considerations here = and come down pretty
=C2=A0 =C2=A0 >=C2=A0 =C2=A0decisively on the side of "encrypt all = the things". Given that
=C2=A0 =C2=A0 >=C2=A0 =C2=A0both SCTP-over-DTLS and QUIC do this, it see= ms pretty unlikely
=C2=A0 =C2=A0 >=C2=A0 =C2=A0we're going to design a new transport pr= otocol that doesn't.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > - Having an IETF Consensus RFC that is so heavily weight= ed on the side
=C2=A0 =C2=A0 >=C2=A0 =C2=A0of "this is how encryption inconvenienc= es us" and so light on "these
=C2=A0 =C2=A0 >=C2=A0 =C2=A0are the attacks we are preventing" give= s a misleading picture of the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0IETF community's view of the relative pr= iority of these
=C2=A0 =C2=A0 >=C2=A0 =C2=A0concerns. ISTM that RFC 8558 -- though perha= ps imperfect -- far more
=C2=A0 =C2=A0 >=C2=A0 =C2=A0closely reflects that consensus.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > In short, I do not think this draft should be published = as an RFC.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 I believe the problem with this draft is that it identifies a=
=C2=A0 =C2=A0 perceived problem, but does little to offer a solution other = than
=C2=A0 =C2=A0 saying don't encrypt the transport layer header. As I'= ;ve mentioned
=C2=A0 =C2=A0 several times, putting transport layer information of interes= t into
=C2=A0 =C2=A0 HBH extension headers is the architecturally correct solution= for
=C2=A0 =C2=A0 hosts to signal the network. This works with any transport la= yer
=C2=A0 =C2=A0 protocol and exposure of transport layer information to the n= etwork is
=C2=A0 =C2=A0 under explicit control of the end host. IMO, the draft does n= ot
=C2=A0 =C2=A0 adequately explore this alternative solution and too easily j= ust
=C2=A0 =C2=A0 brushes it off as being "undesirable" based on one = set of snapshot
=C2=A0 =C2=A0 measurements that is now almost four years old.

=C2=A0 =C2=A0 > I have appended a number of detailed comments which IMO = need to be
=C2=A0 =C2=A0 > addressed in any case, but even if they were resolved, t= hat would not
=C2=A0 =C2=A0 > address my primary concern.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > COMMENTS
=C2=A0 =C2=A0 > S 2.1.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A02.1.=C2=A0 Use of Transport Header Info= rmation in the Network
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 In-network measurement of trans= port flow characteristics can be used
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 to enhance performance, and con= trol cost and service reliability.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Some operators have deployed fu= nctionality in middleboxes to both
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 support network operations and = enhance performance.=C2=A0 This reliance on
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > This seems like a contested point. My understanding is t= hat while
=C2=A0 =C2=A0 > these middleboxes are *intended* to enhance performance = that there is
=C2=A0 =C2=A0 > doubt that they actually do.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 2.1.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 to enhance performance, and con= trol cost and service reliability.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Some operators have deployed fu= nctionality in middleboxes to both
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 support network operations and = enhance performance.=C2=A0 This reliance on
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 the presence and semantics of s= pecific header information leads to
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 ossification, where an endpoint= could be required to supply a
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 specific header to receive the = network service that it desires.=C2=A0 In
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Well, not just the network service it desires but *any* = service.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 2.1.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 specific header to receive the = network service that it desires.=C2=A0 In
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 some cases, this could be benig= n or advantageous to the protocol
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 (e.g., recognising the start of= a connection, or explicitly exposing
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 protocol information can be exp= ected to provide more consistent
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 decisions by on-path devices th= an the use of diverse methods to infer
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 semantics from other flow prope= rties).=C2=A0 In other cases, the
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Is there evidence of this?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 2.1.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 As an example of ossification, = consider the experience of developing
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Transport Layer Security (TLS) = 1.3 [RFC8446].=C2=A0 This required a design
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 that recognised that deployed m= iddleboxes relied on the presence of
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 certain header filed exposed in= TLS 1.2, and failed if those headers
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 were changed.=C2=A0 Other examp= les of the impact of ossification can be
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I think you mean "fields" and it wasn't he= aders so much as handshake
=C2=A0 =C2=A0 > data.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 2.2.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 This supports use of this infor= mation by on-path devices, but at the
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 same time can be expected to le= ad to ossification of the transport
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 header, because network forward= ing could evolve to depend on the
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 presence and/or value of these = fields.=C2=A0 To avoid unwanted inspection,
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 a protocol could intentionally = vary the format or value of exposed
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 header fields [I-D.ietf-tls-gre= ase].
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > It's not just a matter of unwanted inspection. There= 's a real question
=C2=A0 =C2=A0 > about whether we want these on-path devices to have this= information
=C2=A0 =C2=A0 > at all, as it is potentially used for surveillance, traf= fic
=C2=A0 =C2=A0 > analysis, etc.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 2..2.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 While encryption can hide trans= port header information, it does not
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 prevent ossification of the net= work service.=C2=A0 People seeking to
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 understand network traffic coul= d come to rely on pattern inferences
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 and other heuristics as the bas= is for network decision and to derive
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 measurement data.=C2=A0 This ca= n create new dependencies on the transport
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > This also seems quite contested. Do you have any evidenc= e of such a
=C2=A0 =C2=A0 > thing happening?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 2.3.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0anomalies, and fai= lure pathologies at any point along the Internet
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path.=C2=A0 In man= y cases, it is important to relate observations to
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0specific equipment= /configurations or network segments.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Concealing transpo= rt header information makes performance/
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0behaviour unavaila= ble to passive observers along the path,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > While also making traffic analysis more difficult.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 2.3.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0applications it is= important to relate observations to specific
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0equipment/configur= ations or particular network segments.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Concealing transpo= rt header information can make analysis harder
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or impossible.=C2= =A0 This could impact the ability for an operator to
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0anticipate the nee= d for network upgrades and roll-out.=C2=A0 It can
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Or to reduce the opportunities for traffic discriminatio= n.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 2.3.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Different parties will view the= relative importance of these issues
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 differently.=C2=A0 For some, th= e benefits of encrypting some, or all, of
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 the transport headers may outwe= igh the impact of doing so; others
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 might make a different trade-of= f.=C2=A0 The purpose of highlighting the
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 trade-offs is to make such anal= ysis possible.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > This whole section seems to really just ignore the fact = that many of
=C2=A0 =C2=A0 > these practices are unwanted.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 3.1.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Firewalls).=C2=A0 Common issues= concerning IP address sharing are
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 described in [RFC6269].
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A03.1.=C2=A0 Observing Transport Informat= ion in the Network
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 If in-network observation of tr= ansport protocol headers is needed,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Why is this needed? I know some people might want it. =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 3.1.1.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A03.1.1.=C2=A0 Flow Identification Using = Transport Layer Headers
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Flow identification is a common= function.=C2=A0 For example, performed by
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 measurement activities, QoS cla= ssification, firewalls, Denial of
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Service, DOS, prevention.=C2=A0= This becomes more complex and less easily
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 achieved when multiplexing is u= sed at or above the transport layer.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Also traffic discrimination and blocking.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 3.1.1.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 use heuristics to infer that sh= ort UDP packets with regular spacing
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 carry audio traffic.=C2=A0 Oper= ational practices aimed at inferring
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 transport parameters are out of= scope for this document, and are only
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 mentioned here to recognize tha= t encryption does not prevent
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 operators from attempting to ap= ply practices that were used with
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 unencrypted transport headers.<= br> =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > This has a really threatening tone. If you don't giv= e us what we want,
=C2=A0 =C2=A0 > look what could happen.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 3.1.2.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 This information can support ne= twork operations, inform capacity
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 planning, and assist in determi= ning the need for equipment and/or
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 configuration changes by networ= k operators.=C2=A0 It can also inform
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Internet engineering activities= by informing the development of new
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 protocols, methodologies, and p= rocedures.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > What is the point of this exhaustive list?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 3.1.3.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0AQM and ECN offer = a range of algorithms and configuration options.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Tools therefore ne= ed to be available to network operators and
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0researchers to und= erstand the implication of configuration choices
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and transport beha= viour as the use of ECN increases and new
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0methods emerge [RF= C7567].
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > QUIC sort of hides ECN feedback but not ECN marking.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 3.2.4.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A network operator= needs tools to understand if datagram flows
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., using UDP) = comply with congestion control expectations and
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0therefore whether = there is a need to deploy methods such as rate-
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0limiters, transpor= t circuit breakers, or other methods to enforce
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0acceptable usage f= or the offered service.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Does it *need* it or does it just want it. Note that we = have had DTLS-
=C2=A0 =C2=A0 > SCTP with WebRTC without this property for some time now= . Can you provide
=C2=A0 =C2=A0 > some evidence that operators have been inconvenienced by= not having it.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 3.3.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 operators bring together hetero= geneous types of network equipment and
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 seek to deploy opportunistic me= thods to access radio spectrum.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 A flow that conceals its transp= ort header information could imply
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 "don't touch" to = some operators.=C2=A0 This could limit a trouble-shooting
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 response to "can't hel= p, no trouble found".
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > We have quite a bit of QUIC traffic now. I'd be inte= rested in hearing
=C2=A0 =C2=A0 > from the gQUIC team whether they have seen anything like= this.

=C2=A0 =C2=A0 QUIC presents a problem in itself since the QUIC harders are = inside
=C2=A0 =C2=A0 the UDP payload so intermediate devices end up needing to par= se the
=C2=A0 =C2=A0 UDP transport payload. I believe the only way to identify a Q= UIC
=C2=A0 =C2=A0 packet is by matching port numbers, but per RFC7605 interpret= ation of
=C2=A0 =C2=A0 port numbers in the middle of the network is prone to
=C2=A0 =C2=A0 misinterpretation. Eventually, something that looks like a QU= IC packet
=C2=A0 =C2=A0 based on port number will be misinterpreted. Looking at
=C2=A0 =C2=A0 draft-ietf-quic-transport-23, I don't see any discussion = about this or
=C2=A0 =C2=A0 reference to RFC7605. Note this is true for any use case of U= DP
=C2=A0 =C2=A0 including transport layer or network layer encapsulation. Eve= n if the
=C2=A0 =C2=A0 argument is that the information is only being read and
=C2=A0 =C2=A0 misinterpretation is innocuous, it still wouldn't be robu= st protocol.
=C2=A0 =C2=A0 This can be contrasted to putting the information in HBH opti= ons which
=C2=A0 =C2=A0 can be correctly and unambiguously identified anywhere in the= network.

=C2=A0 =C2=A0 Tom

=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 4.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 There are several motivations f= or encryption:
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 o=C2=A0 One motive to use encry= ption is a response to perceptions that the
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0network has become= ossified by over-reliance on middleboxes that
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0prevent new protoc= ols and mechanisms from being deployed.=C2=A0 This
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > This isn't just a perception, it's a demonstrabl= e reality.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 4.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 o=C2=A0 One motive to use encry= ption is a response to perceptions that the
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0network has become= ossified by over-reliance on middleboxes that
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0prevent new protoc= ols and mechanisms from being deployed.=C2=A0 This
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has lead to a perc= eption that there is too much "manipulation" of
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0protocol headers w= ithin the network, and that designing to deploy
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Not just manipulation, also inspection.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 4.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0One example of enc= ryption at the network layer is the use of IPsec
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Encapsulating Secu= rity Payload (ESP) [RFC4303] in tunnel mode.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This encrypts and = authenticates all transport headers, preventing
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0visibility of the = transport headers by in-network devices.=C2=A0 Some
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0VPN methods also e= ncrypt these headers.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > This seems like a bad example as part of the point of a = VPN is to
=C2=A0 =C2=A0 > conceal the headers form the network.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 6.1.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A06.1.=C2=A0 Independent Measurement
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Independent observation by mult= iple actors is important if the
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 transport community is to maint= ain an accurate understanding of the
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 network.=C2=A0 Encrypting trans= port header encryption changes the ability
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > This is ironic because QUIC is much better for endpoint = measurement
=C2=A0 =C2=A0 > than TCP because the details are accessible at the appli= cation layer.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 8.
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 example, an attacker could cons= truct a DOS attack by sending packets
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 with a sequence number that fal= ls within the currently accepted range
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 of sequence numbers at the rece= iving endpoint, this would then
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 introduce additional work at th= e receiving endpoint, even though the
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 data in the attacking packet ma= y not finally be delivered by the
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 transport layer.=C2=A0 This is = sometimes known as a "shadowing attack".
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > This doesn't seem to be an issue with protocols that= authenticate the SN.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > S 8.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 An attack can, for example, dis= rupt receiver processing, trigger loss
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 and retransmission, or make a r= eceiving endpoint perform unproductive
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 decryption of packets that cann= ot be successfully decrypted (forcing
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 a receiver to commit decryption= resources, or to update and then
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 restore protocol state).
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > This is not a real issue for QUIC or similar protocols =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >


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


--

Best regards,
Kathleen
--000000000000a19785059687a3d8-- From nobody Mon Nov 4 08:17:19 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB79C120B83 for ; Mon, 4 Nov 2019 08:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8bNOxr5sClx for ; Mon, 4 Nov 2019 08:17:03 -0800 (PST) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 815C3120AFD for ; Mon, 4 Nov 2019 08:17:01 -0800 (PST) Received: by mail-ed1-x532.google.com with SMTP id k14so4729162eds.4 for ; Mon, 04 Nov 2019 08:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=AXsIaOHUPo7nTCanI+gCJERUbJZ0wdx3ZL45JTpitoY=; b=hvu50dfgR8WbErzpj8yEkzh52Ey+b6q0XWCgMPDWu53Od4ZEVU5w4th0XLKVi0wIx2 OTkbAXwgdimd1asNKIfCjbCjkzm47NpWjTFOAH0aDFQuWyoP5nr08+YYQveHPLx8oUI/ ghtLgSVxn55WYbwiPCzx9pWLN7Xq12KkSMJdcnW5WdtsSnWAQzIqXS60x+tEdr7Dc6Rk MdD0s6Orl5UYPKATDHVbXA21rWdFRM5IFC+jKxFw9b/kD0DGoZgNYjquRK7gooLfofjT IWTKXl+HxJ9q6yckBMo3yyFc+pzQv2GBf2LhG/dVojTtkeYqcZddJN3aDpcoV6nKKeoj GQ6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=AXsIaOHUPo7nTCanI+gCJERUbJZ0wdx3ZL45JTpitoY=; b=LqXM2tDeaWCp8j32T+hyvG37g06Ziqo7jlzV3uac8JMTfM3A4MOSaeKjcXGrru/Ay7 kU91E9qszZ4zUYqj5Tn8waWepdHDpE2GA4dgmi45J/jCIKMbVe6n1iVKxZHlQk7fNYY/ 2AjGVOj02/dlYxGBfVGFn9HZS4PAQpDW24WZsjkywv665q7OUZj6ZEl0wUnIxkiEMzWv E2J3X8MQY0a8VCt+VAVWbFPluxnd3OP5uuGRj8S1vAK+1o4AfyyW5dtjFlYKZUHfcOF8 jHvjMKAgwV3dYiayb0O9TXtJLWZAiIMlN3RMPJKi1yqFRl6dXgVC3rj5OJ+PrToyJzeI lACQ== X-Gm-Message-State: APjAAAUPAwtezITHOC57r32y88F7HcLptjMyHgoaopJYa/5HxYjKrslF DHMtAF76i/pb9SukEJIoMR3k5e613aJfEOxEeOUY/ohh X-Google-Smtp-Source: APXvYqw5IRAGEkTLV5q37eQoGErHOGD4Avk2idcZp4XykNMcdQYkgAyZjiitd6qZe5Nd+Pp2PeP5kUtGiaOasQYmGas= X-Received: by 2002:a17:907:1114:: with SMTP id qu20mr4563098ejb.42.1572884219625; Mon, 04 Nov 2019 08:16:59 -0800 (PST) MIME-Version: 1.0 References: <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com> In-Reply-To: From: Tom Herbert Date: Mon, 4 Nov 2019 08:16:48 -0800 Message-ID: To: Mirja Kuehlewind Cc: Eric Rescorla , tsvwg IETF list , "saag@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 16:17:10 -0000 On Mon, Nov 4, 2019 at 6:59 AM Mirja Kuehlewind wrote: > > Hi Ekr, > > > > see inline, marked [MK]=E2=80=A6 > > > > Mirja > > > > > > From: Eric Rescorla > Date: Monday, 4. November 2019 at 14:57 > To: Mirja Kuehlewind > Cc: Tom Herbert , tsvwg IETF list , = "saag@ietf.org" > Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.tx= t > > > > > > > > On Mon, Nov 4, 2019 at 1:14 AM Mirja Kuehlewind wrote: > > Hi Ekr, hi all, > > Just on this part: > > - The community of people designing new transport protocols has > > already weighed all the considerations here and come down pretty > > decisively on the side of "encrypt all the things". Given that > > both SCTP-over-DTLS and QUIC do this, it seems pretty unlikely > > we're going to design a new transport protocol that doesn't. > I disagree that this is the conclusion the community came to, otherwise w= e would not have put a signal for the network in the QUIC header. Also encr= yption has a cost and that's the discussion we continuously still having in= QUIC and well as other working groups. So "encrypt all the things" is way = too simplified and for sure not a consensus statement which this draft (dra= ft-ietf-tsvwg-transport-encrypt) clearly shows. > > > > Well, we put a single, optional, bit in the header and everything else we= could figure out how to encrypt encrypted. It's true that encryption has a= cost to the design of the protocol and to the endpoint implementations and= we've been trying to balance that cost against the value, but that's not b= ecause the group isn't trying to encrypt as much as possible. > > > > [MK]I don=E2=80=99t think we need to nit-pick here but I think "encrypt a= ll the things" and =E2=80=9Cencrypt as much as possible=E2=80=9D is not the= same, especially as =E2=80=9Cpossible=E2=80=9D is something to argue about= when it comes to the question of how much you are willing to pay. However,= I don=E2=80=99t think we need to discuss this in details here, just wanted= to say that I don=E2=80=99t think the situation is a simple as you have st= ated and I don=E2=80=99t think there is consensus for a simple "encrypt all= the things". > > > > I certainly realize that there are people who are sad about this -- as yo= u rightly point out reflected in this draft =E2=80=93 > > > > [MK] I don=E2=80=99t think people are sad about increasing amount of encr= yption. But when we change things we also need to have a discussion of the = implication of this change and cannot just close our eyes. As I said in som= e cases we might be happy about things that hopefully just go away, in othe= r cases it may actually have more severe impact of the viability of the Int= ernet as a interconnected network that is operated by different entities. > > > > but I believe they are in the rough, at least of the community of people = actively designing and deploying new protocols. > > > > [MK] I don=E2=80=99t believe this. Otherwise I wondering why we had such = a lengthy discussion for more than a year in the QUIC working group. > > > > Do you see any plausible situation in which a new transport protocol isn'= t largely encrypted? > > > > [MK] That=E2=80=99s not the intention here. But we also need to consider = ways to interact with the network where this brings benefit to both the net= work and the performance of the end-to-end traffic. There are situation whe= re this is the case. And I don=E2=80=99t think one makes sense without the = other. Mirja, Yes, that is true. We need a way to allow hosts to signal the network. But doing this in the transport layer is architecturally incorrect, has led to protocol ossification, isn't robust like in the case of QUIC, presents a security and privacy risk, and doesn't scale beyond supporting one or maybe two transport protocols. Expliciting signaling contained in the network layer headers that is under control of the sending host is the correct alternative IMO. Tom > > > > > > > > > > -Ekr > > > > > Mirja > > > > On 04.11.19, 03:15, "tsvwg on behalf of Tom Herbert" wrote: > > On Sun, Nov 3, 2019 at 2:20 PM Eric Rescorla wrote: > > > > After reviewing this document, I share Christian Huitema's concern > > about the tone and perspective of this document, which, while sayin= g > > that encryption is good, then proceeds to mostly lament how difficu= lt > > it makes life for various entities other than the endpoints. It see= ms > > to me rather problematic to publish this document as an RFC for > > several reasons: > > > > - Yes, it's true that the trend towards encrypting everything has > > and continues to make a number of entities sad, but that's a poin= t > > which is already made in RFC 8404. How does all of the additional > > detail here help? > > > > - The community of people designing new transport protocols has > > already weighed all the considerations here and come down pretty > > decisively on the side of "encrypt all the things". Given that > > both SCTP-over-DTLS and QUIC do this, it seems pretty unlikely > > we're going to design a new transport protocol that doesn't. > > > > - Having an IETF Consensus RFC that is so heavily weighted on the s= ide > > of "this is how encryption inconveniences us" and so light on "th= ese > > are the attacks we are preventing" gives a misleading picture of = the > > IETF community's view of the relative priority of these > > concerns. ISTM that RFC 8558 -- though perhaps imperfect -- far m= ore > > closely reflects that consensus. > > > > In short, I do not think this draft should be published as an RFC. > > > I believe the problem with this draft is that it identifies a > perceived problem, but does little to offer a solution other than > saying don't encrypt the transport layer header. As I've mentioned > several times, putting transport layer information of interest into > HBH extension headers is the architecturally correct solution for > hosts to signal the network. This works with any transport layer > protocol and exposure of transport layer information to the network i= s > under explicit control of the end host. IMO, the draft does not > adequately explore this alternative solution and too easily just > brushes it off as being "undesirable" based on one set of snapshot > measurements that is now almost four years old. > > > I have appended a number of detailed comments which IMO need to be > > addressed in any case, but even if they were resolved, that would n= ot > > address my primary concern. > > > > > > COMMENTS > > S 2.1. > > > 2.1. Use of Transport Header Information in the Network > > > > > > In-network measurement of transport flow characteristics can= be used > > > to enhance performance, and control cost and service reliabi= lity. > > > Some operators have deployed functionality in middleboxes to= both > > > support network operations and enhance performance. This re= liance on > > > > This seems like a contested point. My understanding is that while > > these middleboxes are *intended* to enhance performance that there = is > > doubt that they actually do. > > > > > > S 2.1. > > > to enhance performance, and control cost and service reliabi= lity. > > > Some operators have deployed functionality in middleboxes to= both > > > support network operations and enhance performance. This re= liance on > > > the presence and semantics of specific header information le= ads to > > > ossification, where an endpoint could be required to supply = a > > > specific header to receive the network service that it desir= es. In > > > > Well, not just the network service it desires but *any* service. > > > > > > S 2.1. > > > specific header to receive the network service that it desir= es. In > > > some cases, this could be benign or advantageous to the prot= ocol > > > (e.g., recognising the start of a connection, or explicitly = exposing > > > protocol information can be expected to provide more consist= ent > > > decisions by on-path devices than the use of diverse methods= to infer > > > semantics from other flow properties). In other cases, the > > > > Is there evidence of this? > > > > > > S 2.1. > > > > > > As an example of ossification, consider the experience of de= veloping > > > Transport Layer Security (TLS) 1.3 [RFC8446]. This required= a design > > > that recognised that deployed middleboxes relied on the pres= ence of > > > certain header filed exposed in TLS 1.2, and failed if those= headers > > > were changed. Other examples of the impact of ossification = can be > > > > I think you mean "fields" and it wasn't headers so much as handshak= e > > data. > > > > > > S 2.2. > > > This supports use of this information by on-path devices, bu= t at the > > > same time can be expected to lead to ossification of the tra= nsport > > > header, because network forwarding could evolve to depend on= the > > > presence and/or value of these fields. To avoid unwanted in= spection, > > > a protocol could intentionally vary the format or value of e= xposed > > > header fields [I-D.ietf-tls-grease]. > > > > It's not just a matter of unwanted inspection. There's a real quest= ion > > about whether we want these on-path devices to have this informatio= n > > at all, as it is potentially used for surveillance, traffic > > analysis, etc. > > > > > > > > S 2..2. > > > > > > While encryption can hide transport header information, it d= oes not > > > prevent ossification of the network service. People seeking= to > > > understand network traffic could come to rely on pattern inf= erences > > > and other heuristics as the basis for network decision and t= o derive > > > measurement data. This can create new dependencies on the t= ransport > > > > This also seems quite contested. Do you have any evidence of such a > > thing happening? > > > > > > S 2.3. > > > anomalies, and failure pathologies at any point along the= Internet > > > path. In many cases, it is important to relate observati= ons to > > > specific equipment/configurations or network segments. > > > > > > Concealing transport header information makes performance= / > > > behaviour unavailable to passive observers along the path= , > > > > While also making traffic analysis more difficult. > > > > > > S 2.3. > > > applications it is important to relate observations to sp= ecific > > > equipment/configurations or particular network segments. > > > > > > Concealing transport header information can make analysis= harder > > > or impossible. This could impact the ability for an oper= ator to > > > anticipate the need for network upgrades and roll-out. I= t can > > > > Or to reduce the opportunities for traffic discrimination. > > > > > > S 2.3. > > > > > > Different parties will view the relative importance of these= issues > > > differently. For some, the benefits of encrypting some, or = all, of > > > the transport headers may outweigh the impact of doing so; o= thers > > > might make a different trade-off. The purpose of highlighti= ng the > > > trade-offs is to make such analysis possible. > > > > This whole section seems to really just ignore the fact that many o= f > > these practices are unwanted. > > > > > > S 3.1. > > > Firewalls). Common issues concerning IP address sharing are > > > described in [RFC6269]. > > > > > > 3.1. Observing Transport Information in the Network > > > > > > If in-network observation of transport protocol headers is n= eeded, > > > > Why is this needed? I know some people might want it. > > > > > > S 3.1.1. > > > 3.1.1. Flow Identification Using Transport Layer Headers > > > > > > Flow identification is a common function. For example, perf= ormed by > > > measurement activities, QoS classification, firewalls, Denia= l of > > > Service, DOS, prevention. This becomes more complex and les= s easily > > > achieved when multiplexing is used at or above the transport= layer. > > > > Also traffic discrimination and blocking. > > > > > > S 3.1.1. > > > use heuristics to infer that short UDP packets with regular = spacing > > > carry audio traffic. Operational practices aimed at inferri= ng > > > transport parameters are out of scope for this document, and= are only > > > mentioned here to recognize that encryption does not prevent > > > operators from attempting to apply practices that were used = with > > > unencrypted transport headers. > > > > This has a really threatening tone. If you don't give us what we wa= nt, > > look what could happen. > > > > > > S 3.1.2. > > > > > > This information can support network operations, inform capa= city > > > planning, and assist in determining the need for equipment a= nd/or > > > configuration changes by network operators. It can also inf= orm > > > Internet engineering activities by informing the development= of new > > > protocols, methodologies, and procedures. > > > > What is the point of this exhaustive list? > > > > > > S 3.1.3. > > > > > > AQM and ECN offer a range of algorithms and configuration= options. > > > Tools therefore need to be available to network operators= and > > > researchers to understand the implication of configuratio= n choices > > > and transport behaviour as the use of ECN increases and n= ew > > > methods emerge [RFC7567]. > > > > QUIC sort of hides ECN feedback but not ECN marking. > > > > > > S 3.2.4. > > > > > > A network operator needs tools to understand if datagram = flows > > > (e.g., using UDP) comply with congestion control expectat= ions and > > > therefore whether there is a need to deploy methods such = as rate- > > > limiters, transport circuit breakers, or other methods to= enforce > > > acceptable usage for the offered service. > > > > Does it *need* it or does it just want it. Note that we have had DT= LS- > > SCTP with WebRTC without this property for some time now. Can you p= rovide > > some evidence that operators have been inconvenienced by not having= it. > > > > > > S 3.3. > > > operators bring together heterogeneous types of network equi= pment and > > > seek to deploy opportunistic methods to access radio spectru= m. > > > > > > A flow that conceals its transport header information could = imply > > > "don't touch" to some operators. This could limit a trouble= -shooting > > > response to "can't help, no trouble found". > > > > We have quite a bit of QUIC traffic now. I'd be interested in heari= ng > > from the gQUIC team whether they have seen anything like this. > > QUIC presents a problem in itself since the QUIC harders are inside > the UDP payload so intermediate devices end up needing to parse the > UDP transport payload. I believe the only way to identify a QUIC > packet is by matching port numbers, but per RFC7605 interpretation of > port numbers in the middle of the network is prone to > misinterpretation. Eventually, something that looks like a QUIC packe= t > based on port number will be misinterpreted. Looking at > draft-ietf-quic-transport-23, I don't see any discussion about this o= r > reference to RFC7605. Note this is true for any use case of UDP > including transport layer or network layer encapsulation. Even if the > argument is that the information is only being read and > misinterpretation is innocuous, it still wouldn't be robust protocol. > This can be contrasted to putting the information in HBH options whic= h > can be correctly and unambiguously identified anywhere in the network= . > > Tom > > > > > > > S 4. > > > > > > There are several motivations for encryption: > > > > > > o One motive to use encryption is a response to perceptions= that the > > > network has become ossified by over-reliance on middlebox= es that > > > prevent new protocols and mechanisms from being deployed.= This > > > > This isn't just a perception, it's a demonstrable reality. > > > > > > S 4. > > > > > > o One motive to use encryption is a response to perceptions= that the > > > network has become ossified by over-reliance on middlebox= es that > > > prevent new protocols and mechanisms from being deployed.= This > > > has lead to a perception that there is too much "manipula= tion" of > > > protocol headers within the network, and that designing t= o deploy > > > > Not just manipulation, also inspection. > > > > > > S 4. > > > > > > One example of encryption at the network layer is the use= of IPsec > > > Encapsulating Security Payload (ESP) [RFC4303] in tunnel = mode. > > > This encrypts and authenticates all transport headers, pr= eventing > > > visibility of the transport headers by in-network devices= . Some > > > VPN methods also encrypt these headers. > > > > This seems like a bad example as part of the point of a VPN is to > > conceal the headers form the network. > > > > > > S 6.1. > > > > > > 6.1. Independent Measurement > > > > > > Independent observation by multiple actors is important if t= he > > > transport community is to maintain an accurate understanding= of the > > > network. Encrypting transport header encryption changes the= ability > > > > This is ironic because QUIC is much better for endpoint measurement > > than TCP because the details are accessible at the application laye= r. > > > > > > S 8. > > > example, an attacker could construct a DOS attack by sending= packets > > > with a sequence number that falls within the currently accep= ted range > > > of sequence numbers at the receiving endpoint, this would th= en > > > introduce additional work at the receiving endpoint, even th= ough the > > > data in the attacking packet may not finally be delivered by= the > > > transport layer. This is sometimes known as a "shadowing at= tack". > > > > This doesn't seem to be an issue with protocols that authenticate t= he SN. > > > > > > S 8. > > > > > > An attack can, for example, disrupt receiver processing, tri= gger loss > > > and retransmission, or make a receiving endpoint perform unp= roductive > > > decryption of packets that cannot be successfully decrypted = (forcing > > > a receiver to commit decryption resources, or to update and = then > > > restore protocol state). > > > > This is not a real issue for QUIC or similar protocols > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From nobody Mon Nov 4 08:30:15 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88616120B17 for ; Mon, 4 Nov 2019 08:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbhQfcw9ysYE for ; Mon, 4 Nov 2019 08:30:11 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 6C45812096B for ; Mon, 4 Nov 2019 08:30:10 -0800 (PST) Received: from xse455.mail2web.com ([66.113.197.201] helo=xse.mail2web.com) by mx147.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iRfEi-0006WQ-Se for saag@ietf.org; Mon, 04 Nov 2019 17:30:00 +0100 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 476JCP3XXQz3yZm for ; Mon, 4 Nov 2019 08:29:05 -0800 (PST) Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1iRfE1-0002bB-BW for saag@ietf.org; Mon, 04 Nov 2019 08:29:05 -0800 Received: (qmail 6719 invoked from network); 4 Nov 2019 16:29:04 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.58.43.152]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 4 Nov 2019 16:29:04 -0000 To: Mirja Kuehlewind , Eric Rescorla Cc: Tom Herbert , tsvwg IETF list , "saag@ietf.org" References: <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <2d3c909f-b21c-3916-1eb9-db6de5c661e3@huitema.net> Date: Mon, 4 Nov 2019 08:29:04 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------81A18ADC0E6C560E0D73ADFC" Content-Language: en-US X-Originating-IP: 66.113.197.201 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0T9zDZOvA8ND4p2eQxdfzLSpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDRitNmXY60Gx0fFyUeQSRQrgN zB/4Jkrw1eDLcif59fukRP/WFMu8+CZmniSwX+b3U7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/GLPGseHORnR7zfibQ2DIPryme9ldZJ7uNXfg/GfS8fUvP/L5 rCqHDsKZM+xa1iwJX+gRCHfMVnsAk591zk0uilUI+ZL4xWiN8NS6C+dmX6OEdA4u1aThyWrQ/ou2 +v/lmX4Em37yFgrCB6NHRn1g+f3uncIqYSL3lhh5c81YyJqFoLZMmkWsaurVZfvqROaDnDtHb8z5 dpPkEuJ8Snwqla7jUnW3hy14Yji8fo+4xCnSRo4Rcu5Z37rMuDjCny5fE9ykbJ7I9co1MAEE3ruN Xsm8UJsAPvDcVSKtDCYkioPY5Qx4fJOk03R5fJtf/Dv/dkIzS7m4GUpXCY1Y3j3ileOfMnQTuxRu w7b3K/aRb5igZQ+n9Vd4zr6nNv8/QtdBqCtiNHFle7yLh38hfDoPs6kO2hoxH0CJovpmoVo2/zh8 g2fGU86cSswil+kDetUfttbLHdNhiUq2jBEvMVLlZ4GThCScvU0cCIiHSQbmcVIihC4jb+HDhBqY /RXkNv1jY4NhlpOo+XFzBzK20cyXxuXZufaXY1tLtgtWIKWsFuK18tNaK4/WLm8wgr209EiVXPWl FdaGOH191uXjgjQN/RTaYTLUj/RFhcnr3Qktcdi4JMs0yemlR/l6Uv8YKaym1vEjHyvS2QZiR+AZ YvfxEvZFKu+ZM2mB1CpThxyaBpbeNHk15VolAGHS5rCXQKDyCQUljhSWDhWh87HBSLhNUo4qiB0X MVQG2R7iUfOzATaF5R3hQJk8CwyURYKQ0Ye0iR3bHfnMCIEU+nrglojKwJanfcoq9IsR6l/OZb9V MEM= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 16:30:14 -0000 This is a multi-part message in MIME format. --------------81A18ADC0E6C560E0D73ADFC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/4/2019 6:59 AM, Mirja Kuehlewind wrote: > ... > > Well, we put a single, optional, bit in the header and everything else > we could figure out how to encrypt encrypted. It's true that > encryption has a cost to the design of the protocol and to the > endpoint implementations and we've been trying to balance that cost > against the value, but that's not because the group isn't trying to > encrypt as much as possible. > > =C2=A0 > > [MK]I don=E2=80=99t think we need to nit-pick here but I think "encrypt= all > the things" and =E2=80=9Cencrypt as much as possible=E2=80=9D is not th= e same, > especially as =E2=80=9Cpossible=E2=80=9D is something to argue about wh= en it comes to > the question of how much you are willing to pay. However, I don=E2=80=99= t > think we need to discuss this in details here, just wanted to say that > I don=E2=80=99t think the situation is a simple as you have stated and = I don=E2=80=99t > think there is consensus for a simple "encrypt all the things". > > =C2=A0 > > I certainly realize that there are people who are sad about this -- as > you rightly point out reflected in this draft =E2=80=93 > > =C2=A0 > > [MK] I don=E2=80=99t think people are sad about increasing amount of > encryption. But when we change things we also need to have a > discussion of the implication of this change and cannot just close our > eyes. As I said in some cases we might be happy about things that > hopefully just go away, in other cases it may actually have more > severe impact of the viability of the Internet as a interconnected > network that is operated by different entities. > > =C2=A0 > > but I believe they are in the rough, at least of the community of > people actively designing and deploying new protocols. > > =C2=A0 > > [MK] I don=E2=80=99t believe this. Otherwise I wondering why we had suc= h a > lengthy discussion for more than a year in the QUIC working group. > We had that discussion, and there were indeed two opposing ideas: on one hand, expose some information to the path for network management purpose; on the other hand avoid exposing information to prevent ossification and interference, and to avoid privacy issues. Only some the "network management" arguments actually gained some traction: enabling measurements of network latency, enabling measurement of data rates, and enabling measurement of packet losses. One of the problem with the current draft is that it does not distinguish between these "common ground" objectives and a slew of other "network management" practices, such as discriminating between flows or interfering with transport protocols. It also mixes in transport protocol debugging, which is a different subject. Just because we have some consensus on the legitimacy of measuring latency, data rates and packet losses does not mean that we want to incorporate support in the transport protocol. We quickly realize that there is nothing particular needed for measuring data rates, beside separating flows by five tuples and counting packets. We struggled with the privacy implications of measuring latency, because doing so may enable triangulation and does enable the detection of proxies. We also failed to achieve consensus on a specific way to enable packet loss measurement, because we could not reach consensus on a specific algorithm= =2E The QUIC working group converged on enabling latency measurements on a fraction of the flow. It appears that measuring a relatively small fraction of the flows is sufficient to gather statistically significant measurements of latency. Ensuring that a sufficient fraction of the flows is not measurable enables privacy protection for sensitive flows that need to hide usage of proxies. The draft does not include this kind of discussions. > =C2=A0 > > Do you see any plausible situation in which a new transport protocol > isn't largely encrypted? > > =C2=A0 > > [MK] That=E2=80=99s not the intention here. But we also need to conside= r ways > to interact with the network where this brings benefit to both the > network and the performance of the end-to-end traffic. There are > situation where this is the case. And I don=E2=80=99t think one makes s= ense > without the other. > You seem to be arguing for something like "performance enhancing proxies". End-to-end encryption is indeed a way to opt out of such proxying. Measurements so far indicate that opting out has very little impact on actual performance, and that whatever impact there is could be reduced by improvements in end-to-end algorithms. In fact, in many cases, end to end performance is better without such proxies. But the real reason for the opposition to the concept is ossification. Enabling such proxies would quickly ossify the new transports, and a such there is a strong consensus in the end-to-end transport designers to use encryption and prevent interference by such devices. This does not mean that network level deployment have no role in the future. I could see for example tunnels deployed that use FEC or local retransmission to mask the poor performance of a particular subnet. Or I could see end-to-end devices opting into some kinds of application level caching services in order to improve performance. But the draft should be clear: transport protocols do not have to enable interference with the transport bits. My take is that this draft should not be published as is. It should be rewritten to actually reflect the consensus of the transport area, which has to reflect in particular the work in the QUIC working group. -- Christian Huitema --------------81A18ADC0E6C560E0D73ADFC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 11/4/2019 6:59 AM, Mirja Kuehlewind wrote:
...

Well, we put a single, optional, bit in the header and everything else we could figure out how to encrypt encrypted. It's true that encryption has a cost to the design of the protocol and to the endpoint implementations and we've been trying to balance that cost against the value, but that's not because the group isn't trying to encrypt as much as possible.

 

[MK]I don’t think we need to nit-pick here but I think "encrypt all the things" and “encrypt as much as possible” is not the same, especially as “possible” is something to argue about when it comes to the question of how much you are willing to pay. However, I don’t think we need to discuss this in details here, just wanted to say that I don’t think the situation is a simple as you have stated and I don’t think there is consensus for a simple "encrypt all the things".

 

I certainly realize that there are people who are sad about this -- as you rightly point out reflected in this draft –

 

[MK] I don’t think people are sad about increasing amount of encryption. But when we change things we also need to have a discussion of the implication of this change and cannot just close our eyes. As I said in some cases we might be happy about things that hopefully just go away, in other cases it may actually have more severe impact of the viability of the Internet as a interconnected network that is operated by different entities.

 

but I believe they are in the rough, at least of the community of people actively designing and deploying new protocols.

 

[MK] I don’t believe this. Otherwise I wondering why we had such a lengthy discussion for more than a year in the QUIC working group.

We had that discussion, and there were indeed two opposing ideas: on one hand, expose some information to the path for network management purpose; on the other hand avoid exposing information to prevent ossification and interference, and to avoid privacy issues. Only some the "network management" arguments actually gained some traction: enabling measurements of network latency, enabling measurement of data rates, and enabling measurement of packet losses. One of the problem with the current draft is that it does not distinguish between these "common ground" objectives and a slew of other "network management" practices, such as discriminating between flows or interfering with transport protocols. It also mixes in transport protocol debugging, which is a different subject.

Just because we have some consensus on the legitimacy of measuring latency, data rates and packet losses does not mean that we want to incorporate support in the transport protocol. We quickly realize that there is nothing particular needed for measuring data rates, beside separating flows by five tuples and counting packets. We struggled with the privacy implications of measuring latency, because doing so may enable triangulation and does enable the detection of proxies. We also failed to achieve consensus on a specific way to enable packet loss measurement, because we could not reach consensus on a specific algorithm.

The QUIC working group converged on enabling latency measurements on a fraction of the flow. It appears that measuring a relatively small fraction of the flows is sufficient to gather statistically significant measurements of latency. Ensuring that a sufficient fraction of the flows is not measurable enables privacy protection for sensitive flows that need to hide usage of proxies.

The draft does not include this kind of discussions.

 

Do you see any plausible situation in which a new transport protocol isn't largely encrypted?

 

[MK] That’s not the intention here. But we also need to consider ways to interact with the network where this brings benefit to both the network and the performance of the end-to-end traffic. There are situation where this is the case. And I don’t think one makes sense without the other.


You seem to be arguing for something like "performance enhancing proxies". End-to-end encryption is indeed a way to opt out of such proxying. Measurements so far indicate that opting out has very little impact on actual performance, and that whatever impact there is could be reduced by improvements in end-to-end algorithms. In fact, in many cases, end to end performance is better without such proxies. But the real reason for the opposition to the concept is ossification. Enabling such proxies would quickly ossify the new transports, and a such there is a strong consensus in the end-to-end transport designers to use encryption and prevent interference by such devices.

This does not mean that network level deployment have no role in the future. I could see for example tunnels deployed that use FEC or local retransmission to mask the poor performance of a particular subnet. Or I could see end-to-end devices opting into some kinds of application level caching services in order to improve performance. But the draft should be clear: transport protocols do not have to enable interference with the transport bits.

My take is that this draft should not be published as is. It should be rewritten to actually reflect the consensus of the transport area, which has to reflect in particular the work in the QUIC working group.

-- Christian Huitema

--------------81A18ADC0E6C560E0D73ADFC-- From nobody Mon Nov 4 08:32:09 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7AA120BC3 for ; Mon, 4 Nov 2019 08:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YB9oMG5ZIoSk for ; Mon, 4 Nov 2019 08:31:58 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 C6D21120BAF for ; Mon, 4 Nov 2019 08:31:57 -0800 (PST) Received: from xse258.mail2web.com ([66.113.197.4] helo=xse.mail2web.com) by mx114.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iRfGl-000fNW-C0 for saag@ietf.org; Mon, 04 Nov 2019 17:31:58 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 476JGP2wRhz3pX3 for ; Mon, 4 Nov 2019 08:31:41 -0800 (PST) Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1iRfGX-0000s2-9J for saag@ietf.org; Mon, 04 Nov 2019 08:31:41 -0800 Received: (qmail 17902 invoked from network); 4 Nov 2019 16:31:40 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.58.43.152]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 4 Nov 2019 16:31:40 -0000 To: Tom Herbert , Mirja Kuehlewind Cc: tsvwg IETF list , "saag@ietf.org" References: <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <77cf17ad-d7e7-6c67-1a4f-d3a60e7c63ec@huitema.net> Date: Mon, 4 Nov 2019 08:31:40 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3FB8095B0038F2FBB6D9BEA9" Content-Language: en-US X-Originating-IP: 66.113.197.4 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0T9zDZOvA8ND4p2eQxdfzLSpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDRitNmXY60Gx0fFyUeQSRQrgN zB/4Jkrw1eDLcif59fsBC3C4WQfV20oFrIOH8Pv+U7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/d/hBjqsxautjlVXfyJaQKbyme9ldZJ7uNXfg/GfS8fUvP/L5 rCqHDsKZM+xa1iwJX+gRCHfMVnsAk591zk0uilUI+ZL4xWiN8NS6C+dmX6OEdA4u1aThyWrQ/ou2 +v/lmX4Em37yFgrCB6NHRn1g+f3uncIqYSL3lhh5c81YyJqFoLZMmkWsaurVZfvqROaDnDtHb8z5 dpPkEuJ8Snwqla7jUnW3hy14Yji8fo+4xCnSRo4Rcu5Z37rMuDjCny5fE9ykbJ7I9co1MAEE3ruN Xsm8UJsAPvDcVSKtDCYkioPY5Qx4fJOk03R5fJtf/Dv/dkIzS7m4GUpXCY1Y3j3ilUN7TTX3qb0a 8RNcOLCOSd5csd6/DQyP1F2MXqSxFa+QP4a1A8LRbuHS7vVbrTLB8qHoXDDqibrE8JfG+rJMrFgv UwPy3x0FYtCNEb10sHyQCLHEvD1OqP6bgZ4L66GcgBg66gs5OuzYxJgw5atIxeNDvjI/CYe5WPy0 +t1RP0azwcibdUrqXy2udBLHTvLA/5xMPnetLBJMh51NiRRoHIBcI73qUcunwd7eQxHoPaSSmiK7 x42VjdzChZMe6O/DiVLaBeTIR35/MiUfTTd1C49nVuY2hI7gKraphkDJZmOF1vEjHyvS2QZiR+AZ YvfxEvZFKu+ZM2mB1CpThxyaBpbeNHk15VolAGHS5rCXQKDyCQUljhSWDhWh87HBSLhNUo4qiB0X MVQG2R7iUfOzATaF5R3hQJk8CwyURYKQ0Ye0iR3bHfnMCIEU+nrglojKwJanfcoq9IsR6l/OZb9V MEM= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 16:32:08 -0000 This is a multi-part message in MIME format. --------------3FB8095B0038F2FBB6D9BEA9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 11/4/2019 8:16 AM, Tom Herbert wrote: >> [MK] That’s not the intention here. But we also need to consider ways to interact with the network where this brings benefit to both the network and the performance of the end-to-end traffic. There are situation where this is the case. And I don’t think one makes sense without the other. > Mirja, > > Yes, that is true. We need a way to allow hosts to signal the network. > But doing this in the transport layer is architecturally incorrect, > has led to protocol ossification, isn't robust like in the case of > QUIC, presents a security and privacy risk, and doesn't scale beyond > supporting one or maybe two transport protocols. Expliciting signaling > contained in the network layer headers that is under control of the > sending host is the correct alternative IMO. +1. We would be better off if we started work on this sooner rather than later. -- Christian Huitema --------------3FB8095B0038F2FBB6D9BEA9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 11/4/2019 8:16 AM, Tom Herbert wrote:
[MK] That’s not the intention here. But we also need to consider ways to interact with the network where this brings benefit to both the network and the performance of the end-to-end traffic. There are situation where this is the case. And I don’t think one makes sense without the other.

Mirja,

Yes, that is true. We need a way to allow hosts to signal the network.
But doing this in the transport layer is architecturally incorrect,
has led to protocol ossification, isn't robust like in the case of
QUIC, presents a security and privacy risk, and doesn't scale beyond
supporting one or maybe two transport protocols. Expliciting signaling
contained in the network layer headers that is under control of the
sending host is the correct alternative IMO.

+1.

We would be better off if we started work on this sooner rather than later.

-- Christian Huitema


    

  


--------------3FB8095B0038F2FBB6D9BEA9--


From nobody Mon Nov  4 09:05:43 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3A4120AB8; Mon,  4 Nov 2019 09:05:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcwACM8UBg_A; Mon,  4 Nov 2019 09:05:37 -0800 (PST)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 9FDAA120B0C; Mon,  4 Nov 2019 09:05:36 -0800 (PST)
Received: by mail-lf1-x134.google.com with SMTP id 195so12792899lfj.6; Mon, 04 Nov 2019 09:05:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O5dFTh2vdcAfmP2Jccfmj7BZSHYc4DpnWpV5kTSvW84=; b=AqL7RZTMLcwyCaA7lyFb65IN3RzX+NnYVxMwwvxO6WvcS07PVxScKRBDgfEgojjD6g p4CLYAXrnk/be+V6Q2M1cRgoI7gpVFNXrOR/spKW84flFdh8uQDSRIY5pKv8NPX4VZmJ 0qs+lnFuUAbOaKU8c17ufJSfDNna1juQLBravdHwu6wb23NgTIKdD6U9TPc0frgS0jwA inx+tqfqu2kE/wW3PvK0eU1Aryi3hbhEHc24NnLJQ8uz6AJn71EGqduhswkk9nO33qDd 9VRkmdh/jsCkEC2yRyJReyrB/q8YAzyesuWYwQq1Np9sYTPMhbRC2mVBslw0TK9qm4Vr jWUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O5dFTh2vdcAfmP2Jccfmj7BZSHYc4DpnWpV5kTSvW84=; b=lpicZhJkDxKm4eTxEKOyboTvNjqnL5VjUF8w1PPWgTLjvapG+d4skPKRnZSutrpSEG hFAJtNcxUsWfse82ieRawAQ8dde5+P71wcfJY6qZNFEh3b+0+s3o181HGWa30CPuOGIx GpaYH0mm7ZAe6pCH7Av7Hfg3eUIQ3eYVnDc4bW2c4+e2oGUe2DBbI0rzr8uffcgxihcQ TzWVsjUwza2K3lII1Th2Itk9oMgGzaLwzKqIlYq4K5HqbiOBooN1IA7/9xYFA+eaWUd4 lyU4uXVHnc0j5LVzGvTbthGdFw8hClIoBBKY3nJJZkYOBOmqIulfvqenYn44p6wVrb6M 3wJg==
X-Gm-Message-State: APjAAAXHj3JEq1GQsfxs/HHel6HmvF/8Z5cINTUCGPcAJPwx7ZRqxGio B6nIPYpAkXAB0Ypc4vzSiuP6fk1JTPzxY5mw0ss=
X-Google-Smtp-Source: APXvYqw8aylXA/Th3zj6aXPnVsZbkTujS3/6npehal9N7jJknTpi934X6TVuOwJfidciHh52mLBpzJC0rSY7CudHnPw=
X-Received: by 2002:ac2:4856:: with SMTP id 22mr16446807lfy.131.1572887134135;  Mon, 04 Nov 2019 09:05:34 -0800 (PST)
MIME-Version: 1.0
References:  <6E8A313A-2A3B-45D1-813C-029F90BA624B@gmail.com> 
In-Reply-To: 
From: Bernard Aboba 
Date: Mon, 4 Nov 2019 09:05:23 -0800
Message-ID: 
To: Mirja Kuehlewind 
Cc: Eric Rescorla , tsvwg IETF list , "saag@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000e6e9950596885280"
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Nov 2019 17:05:41 -0000

--000000000000e6e9950596885280
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

[MK] Yes, these issues are not new but that makes it even more important to
document them in a well written RFC, so we have a common basis for any
further discussion. RFC8404 touches these points but also others. This
document has a more narrow focus and gives more detail which I think is
valuable for future discussion and therefore I support publication of this
document.

[BA] I would argue that this work item, even when combined with
draft-ietf-quic-manageability, does not document the current state of
operations and regulation nor the potential solutions in a comprehensive
way. Over the last decade, with the revolution in "big data" and machine
learning, there has been a sea change in the way performance data is
collected, analyzed and regulated.  The move to "cloud services" has
resulted in applications developers (who also represent large consumers and
sometimes operators of network services) routinely collecting large amounts
of performance data (e.g. see:  https://w3c.github.io/webrtc-stats/ ) so as
to support performance analysis and capacity planning. At the same time,
the collection, use and retention of performance data is increasingly
subject to regulation (e.g. GDPR and "network neutrality" regulations,
among others).  Today, to accommodate the increasing concerns by regulators
and civil society, SDOs such as W3C  are conducting increasingly detailed
privacy reviews of their specifications.

This situation is quite different from the  that which existed a decade
ago, when application deployment and monitoring was often a customer
responsibility delegated to network operators, network operations
management techniques were unregulated and operators routinely built
network management systems relying upon Deep Packet Inspection (DPI) and
other snooping techniques.   Given these major changes, documents such as
this one need to acknowledge the changes in operational practice and
broaden their definition of "manageability".

[MK] The issue here IS loss of visibility.

[BA] If appropriate manageability standards are developed, it should still
be possible for applications developers to manage applications and network
performance.  The extent to which this is possible is a good question for
the document to answer - but it does not attempt to answer that question
because it is stuck in a decade-old mindset.

Nothing prevents applications developers from sharing appropriately
aggregated and anonymized data with network operators. What IS lost is the
ability of third parties to collect performance information without
authorization or regulatory scrutiny - but in many parts of the world, that
door closed quite a while ago.

On Mon, Nov 4, 2019 at 1:26 AM Mirja Kuehlewind <
mirja.kuehlewind@ericsson.com> wrote:

> Hi Bernard, hi all,
>
> please see below, marked with [MK].
>
> Mirja
>
> =EF=BB=BFOn 04.11.19, 01:11, "tsvwg on behalf of Bernard Aboba" <
> tsvwg-bounces@ietf.org on behalf of bernard.aboba@gmail.com> wrote:
>
>     This document appears to have a *lot* of overlap with RFC 8404. So
> given that the basic point has already been made, it seems to me that thi=
s
> document needs to focus on new points and/or practical recommendations to
> make its publication worthwhile.
>
>     The issues raised here are by no means new - they first arose with th=
e
> introduction of IPsec. Endpoint monitoring makes it possible for endpoint
> owners to collect information on performance that they can choose to shar=
e
> with operators.
>
> [MK] Yes, these issues are not new but that makes it even more important
> to document them in a well written RFC, so we have a common basis for any
> further discussion. RFC8404 touches these points but also others. This
> document has a more narrow focus and gives more detail which I think is
> valuable for future discussion and therefore I support publication of thi=
s
> document.
>
>     Thus the issue here is not really the loss of transport performance
> information since that remains available if consent can be obtained, but
> rather the collection of that information by unauthorized third parties.
>
> [MK] The issue here IS loss of visibly. Yes it's not great that we have
> all the mechanisms in the network now that use the information that were
> not supposed to be used by the network. However, we can't deny that if we
> change the end-to-end protocol that this will have an impact on the netwo=
rk
> and how we mange networks today. In some cases we can be happy that some =
of
> the boxes will just go away but in other case this can cause problems and
> can noticeably impact end-to-end performance, e.g. when an operator is no=
t
> able to quickly locate the root cause of a problem anymore.
>
> [MK] Providing equivalent information based on consent is the solution to
> the problem described in this draft and something we should be working on
> but is not there yet.
>
> [MK] Collection of information by unauthorized third party is another
> problem which still exists and is now just shifted to another layer but
> would for sure need another draft (or multiple ones).
>
>
>     > On Nov 3, 2019, at 2:20 PM, Eric Rescorla  wrote:
>     >
>     >
>     > After reviewing this document, I share Christian Huitema's concern
>     > about the tone and perspective of this document, which, while sayin=
g
>     > that encryption is good, then proceeds to mostly lament how difficu=
lt
>     > it makes life for various entities other than the endpoints. It see=
ms
>     > to me rather problematic to publish this document as an RFC for
>     > several reasons:
>     >
>     > - Yes, it's true that the trend towards encrypting everything has
>     >   and continues to make a number of entities sad, but that's a poin=
t
>     >   which is already made in RFC 8404. How does all of the additional
>     >   detail here help?
>     >
>     > - The community of people designing new transport protocols has
>     >   already weighed all the considerations here and come down pretty
>     >   decisively on the side of "encrypt all the things". Given that
>     >   both SCTP-over-DTLS and QUIC do this, it seems pretty unlikely
>     >   we're going to design a new transport protocol that doesn't.
>     >
>     > - Having an IETF Consensus RFC that is so heavily weighted on the
> side
>     >   of "this is how encryption inconveniences us" and so light on
> "these
>     >   are the attacks we are preventing" gives a misleading picture of
> the
>     >   IETF community's view of the relative priority of these
>     >   concerns. ISTM that RFC 8558 -- though perhaps imperfect -- far
> more
>     >   closely reflects that consensus.
>     >
>     > In short, I do not think this draft should be published as an RFC.
>     >
>     > I have appended a number of detailed comments which IMO need to be
>     > addressed in any case, but even if they were resolved, that would n=
ot
>     > address my primary concern.
>     >
>     >
>     > COMMENTS
>     > S 2.1.
>     > >   2.1.  Use of Transport Header Information in the Network
>     > >
>     > >      In-network measurement of transport flow characteristics can
> be used
>     > >      to enhance performance, and control cost and service
> reliability.
>     > >      Some operators have deployed functionality in middleboxes to
> both
>     > >      support network operations and enhance performance.  This
> reliance on
>     >
>     > This seems like a contested point. My understanding is that while
>     > these middleboxes are *intended* to enhance performance that there =
is
>     > doubt that they actually do.
>     >
>     >
>     > S 2.1.
>     > >      to enhance performance, and control cost and service
> reliability.
>     > >      Some operators have deployed functionality in middleboxes to
> both
>     > >      support network operations and enhance performance.  This
> reliance on
>     > >      the presence and semantics of specific header information
> leads to
>     > >      ossification, where an endpoint could be required to supply =
a
>     > >      specific header to receive the network service that it
> desires.  In
>     >
>     > Well, not just the network service it desires but *any* service.
>     >
>     >
>     > S 2.1.
>     > >      specific header to receive the network service that it
> desires.  In
>     > >      some cases, this could be benign or advantageous to the
> protocol
>     > >      (e.g., recognising the start of a connection, or explicitly
> exposing
>     > >      protocol information can be expected to provide more
> consistent
>     > >      decisions by on-path devices than the use of diverse methods
> to infer
>     > >      semantics from other flow properties).  In other cases, the
>     >
>     > Is there evidence of this?
>     >
>     >
>     > S 2.1.
>     > >
>     > >      As an example of ossification, consider the experience of
> developing
>     > >      Transport Layer Security (TLS) 1.3 [RFC8446].  This required
> a design
>     > >      that recognised that deployed middleboxes relied on the
> presence of
>     > >      certain header filed exposed in TLS 1.2, and failed if those
> headers
>     > >      were changed.  Other examples of the impact of ossification
> can be
>     >
>     > I think you mean "fields" and it wasn't headers so much as handshak=
e
>     > data.
>     >
>     >
>     > S 2.2.
>     > >      This supports use of this information by on-path devices, bu=
t
> at the
>     > >      same time can be expected to lead to ossification of the
> transport
>     > >      header, because network forwarding could evolve to depend on
> the
>     > >      presence and/or value of these fields.  To avoid unwanted
> inspection,
>     > >      a protocol could intentionally vary the format or value of
> exposed
>     > >      header fields [I-D.ietf-tls-grease].
>     >
>     > It's not just a matter of unwanted inspection. There's a real
> question
>     > about whether we want these on-path devices to have this informatio=
n
>     > at all, as it is potentially used for surveillance, traffic
>     > analysis, etc.
>     >
>     >
>     >
>     > S 2..2.
>     > >
>     > >      While encryption can hide transport header information, it
> does not
>     > >      prevent ossification of the network service.  People seeking
> to
>     > >      understand network traffic could come to rely on pattern
> inferences
>     > >      and other heuristics as the basis for network decision and t=
o
> derive
>     > >      measurement data.  This can create new dependencies on the
> transport
>     >
>     > This also seems quite contested. Do you have any evidence of such a
>     > thing happening?
>     >
>     >
>     > S 2.3.
>     > >         anomalies, and failure pathologies at any point along the
> Internet
>     > >         path.  In many cases, it is important to relate
> observations to
>     > >         specific equipment/configurations or network segments.
>     > >
>     > >         Concealing transport header information makes performance=
/
>     > >         behaviour unavailable to passive observers along the path=
,
>     >
>     > While also making traffic analysis more difficult.
>     >
>     >
>     > S 2.3.
>     > >         applications it is important to relate observations to
> specific
>     > >         equipment/configurations or particular network segments.
>     > >
>     > >         Concealing transport header information can make analysis
> harder
>     > >         or impossible.  This could impact the ability for an
> operator to
>     > >         anticipate the need for network upgrades and roll-out.  I=
t
> can
>     >
>     > Or to reduce the opportunities for traffic discrimination.
>     >
>     >
>     > S 2.3.
>     > >
>     > >      Different parties will view the relative importance of these
> issues
>     > >      differently.  For some, the benefits of encrypting some, or
> all, of
>     > >      the transport headers may outweigh the impact of doing so;
> others
>     > >      might make a different trade-off.  The purpose of
> highlighting the
>     > >      trade-offs is to make such analysis possible.
>     >
>     > This whole section seems to really just ignore the fact that many o=
f
>     > these practices are unwanted.
>     >
>     >
>     > S 3.1.
>     > >      Firewalls).  Common issues concerning IP address sharing are
>     > >      described in [RFC6269].
>     > >
>     > >   3.1.  Observing Transport Information in the Network
>     > >
>     > >      If in-network observation of transport protocol headers is
> needed,
>     >
>     > Why is this needed? I know some people might want it.
>     >
>     >
>     > S 3.1.1.
>     > >   3.1.1.  Flow Identification Using Transport Layer Headers
>     > >
>     > >      Flow identification is a common function.  For example,
> performed by
>     > >      measurement activities, QoS classification, firewalls, Denia=
l
> of
>     > >      Service, DOS, prevention.  This becomes more complex and les=
s
> easily
>     > >      achieved when multiplexing is used at or above the transport
> layer.
>     >
>     > Also traffic discrimination and blocking.
>     >
>     >
>     > S 3.1.1.
>     > >      use heuristics to infer that short UDP packets with regular
> spacing
>     > >      carry audio traffic.  Operational practices aimed at inferri=
ng
>     > >      transport parameters are out of scope for this document, and
> are only
>     > >      mentioned here to recognize that encryption does not prevent
>     > >      operators from attempting to apply practices that were used
> with
>     > >      unencrypted transport headers.
>     >
>     > This has a really threatening tone. If you don't give us what we
> want,
>     > look what could happen.
>     >
>     >
>     > S 3.1.2.
>     > >
>     > >      This information can support network operations, inform
> capacity
>     > >      planning, and assist in determining the need for equipment
> and/or
>     > >      configuration changes by network operators.  It can also
> inform
>     > >      Internet engineering activities by informing the development
> of new
>     > >      protocols, methodologies, and procedures.
>     >
>     > What is the point of this exhaustive list?
>     >
>     >
>     > S 3.1.3.
>     > >
>     > >         AQM and ECN offer a range of algorithms and configuration
> options.
>     > >         Tools therefore need to be available to network operators
> and
>     > >         researchers to understand the implication of configuratio=
n
> choices
>     > >         and transport behaviour as the use of ECN increases and n=
ew
>     > >         methods emerge [RFC7567].
>     >
>     > QUIC sort of hides ECN feedback but not ECN marking.
>     >
>     >
>     > S 3.2.4.
>     > >
>     > >         A network operator needs tools to understand if datagram
> flows
>     > >         (e.g., using UDP) comply with congestion control
> expectations and
>     > >         therefore whether there is a need to deploy methods such
> as rate-
>     > >         limiters, transport circuit breakers, or other methods to
> enforce
>     > >         acceptable usage for the offered service.
>     >
>     > Does it *need* it or does it just want it. Note that we have had
> DTLS-
>     > SCTP with WebRTC without this property for some time now. Can you
> provide
>     > some evidence that operators have been inconvenienced by not having
> it.
>     >
>     >
>     > S 3.3.
>     > >      operators bring together heterogeneous types of network
> equipment and
>     > >      seek to deploy opportunistic methods to access radio spectru=
m.
>     > >
>     > >      A flow that conceals its transport header information could
> imply
>     > >      "don't touch" to some operators.  This could limit a
> trouble-shooting
>     > >      response to "can't help, no trouble found".
>     >
>     > We have quite a bit of QUIC traffic now. I'd be interested in heari=
ng
>     > from the gQUIC team whether they have seen anything like this.
>     >
>     >
>     > S 4.
>     > >
>     > >      There are several motivations for encryption:
>     > >
>     > >      o  One motive to use encryption is a response to perceptions
> that the
>     > >         network has become ossified by over-reliance on
> middleboxes that
>     > >         prevent new protocols and mechanisms from being deployed.
> This
>     >
>     > This isn't just a perception, it's a demonstrable reality.
>     >
>     >
>     > S 4.
>     > >
>     > >      o  One motive to use encryption is a response to perceptions
> that the
>     > >         network has become ossified by over-reliance on
> middleboxes that
>     > >         prevent new protocols and mechanisms from being deployed.
> This
>     > >         has lead to a perception that there is too much
> "manipulation" of
>     > >         protocol headers within the network, and that designing t=
o
> deploy
>     >
>     > Not just manipulation, also inspection.
>     >
>     >
>     > S 4.
>     > >
>     > >         One example of encryption at the network layer is the use
> of IPsec
>     > >         Encapsulating Security Payload (ESP) [RFC4303] in tunnel
> mode.
>     > >         This encrypts and authenticates all transport headers,
> preventing
>     > >         visibility of the transport headers by in-network
> devices.  Some
>     > >         VPN methods also encrypt these headers.
>     >
>     > This seems like a bad example as part of the point of a VPN is to
>     > conceal the headers form the network.
>     >
>     >
>     > S 6.1.
>     > >
>     > >   6.1.  Independent Measurement
>     > >
>     > >      Independent observation by multiple actors is important if t=
he
>     > >      transport community is to maintain an accurate understanding
> of the
>     > >      network.  Encrypting transport header encryption changes the
> ability
>     >
>     > This is ironic because QUIC is much better for endpoint measurement
>     > than TCP because the details are accessible at the application laye=
r.
>     >
>     >
>     > S 8.
>     > >      example, an attacker could construct a DOS attack by sending
> packets
>     > >      with a sequence number that falls within the currently
> accepted range
>     > >      of sequence numbers at the receiving endpoint, this would th=
en
>     > >      introduce additional work at the receiving endpoint, even
> though the
>     > >      data in the attacking packet may not finally be delivered by
> the
>     > >      transport layer.  This is sometimes known as a "shadowing
> attack".
>     >
>     > This doesn't seem to be an issue with protocols that authenticate
> the SN.
>     >
>     >
>     > S 8.
>     > >
>     > >      An attack can, for example, disrupt receiver processing,
> trigger loss
>     > >      and retransmission, or make a receiving endpoint perform
> unproductive
>     > >      decryption of packets that cannot be successfully decrypted
> (forcing
>     > >      a receiver to commit decryption resources, or to update and
> then
>     > >      restore protocol state).
>     >
>     > This is not a real issue for QUIC or similar protocols
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > saag mailing list
>     > saag@ietf.org
>     > https://www.ietf.org/mailman/listinfo/saag
>
>
>
>

--000000000000e6e9950596885280
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



[MK] Yes, these issues are not new but that makes i=
t even more important to document them in a well written RFC, so we have a =
common basis for any further discussion. RFC8404 touches these points but a=
lso others. This document has a more narrow focus and gives more detail whi=
ch I think is valuable for future discussion and therefore I support public=
ation of this document.=C2=A0

[BA] I would argue that th=
is work item, even when combined with draft-ietf-quic-manageability, does n=
ot document the current state of operations and regulation nor the potentia=
l solutions in a comprehensive way. Over the last decade, with the revoluti=
on in "big data" and machine learning, there has been a sea chang=
e in the way performance data is collected, analyzed and regulated.=C2=A0 T=
he move to "cloud services" has resulted in applications develope=
rs (who also represent large consumers and sometimes operators of network s=
ervices) routinely collecting large amounts of performance data (e.g. see:=
=C2=A0=C2=A0https://w3c.git=
hub.io/webrtc-stats/=C2=A0) so as to support performance analysis and c=
apacity planning. At the same time, the collection, use and retention of pe=
rformance data is increasingly subject to regulation (e.g. GDPR and "n=
etwork neutrality" regulations, among others).=C2=A0

Today, to accommodate the increasing concerns by regulators and civil socie=
ty, SDOs such as W3C=C2=A0

 are conducting increasingly detailed privacy reviews of their specificatio=
ns.

This situation is quite different from the=C2=
=A0 that which existed a decade ago, when application deployment and monito=
ring was often a customer responsibility delegated to network operators, ne=
twork operations management techniques were unregulated and operators routi=
nely built network management systems relying upon Deep Packet Inspection (=
DPI) and other snooping techniques.=C2=A0 =C2=A0Given these major changes, =
documents such as this one need to acknowledge the changes in operational p=
ractice and broaden their definition of "manageability".=C2=A0

[MK] The issue here IS loss of visibility.

[BA] If appropriate manageability standards are developed, =
it should still be possible for applications developers to manage applicati=
ons and network performance.=C2=A0 The extent to which this is possible is =
a good question for the document to answer - but it does not attempt to ans=
wer that question because it is stuck in a decade-old mindset.
Nothing prevents applications developers from sharing appropri=
ately aggregated and anonymized data with network operators. What IS lost i=
s the ability of third parties to collect performance information without a=
uthorization or regulatory scrutiny - but in many parts of the world, that =
door closed quite a while ago.=C2=A0

On Mon, Nov 4, 2019 at 1:26=
 AM Mirja Kuehlewind <m=
irja.kuehlewind@ericsson.com> wrote:
Hi Bernard, hi all,



please see below, marked with [MK].



Mirja



=EF=BB=BFOn 04.11.19, 01:11, "tsvwg on behalf of Bernard Aboba" &=
lt;tsvwg-bounce=
s@ietf.org on behalf of bernard.aboba@gmail.com> wrote:



=C2=A0 =C2=A0 This document appears to have a *lot* of overlap with RFC 840=
4. So given that the basic point has already been made, it seems to me that=
 this document needs to focus on new points and/or practical recommendation=
s to make its publication worthwhile.



=C2=A0 =C2=A0 The issues raised here are by no means new - they first arose=
 with the introduction of IPsec. Endpoint monitoring makes it possible for =
endpoint owners to collect information on performance that they can choose =
to share with operators. 



[MK] Yes, these issues are not new but that makes it even more important to=
 document them in a well written RFC, so we have a common basis for any fur=
ther discussion. RFC8404 touches these points but also others. This documen=
t has a more narrow focus and gives more detail which I think is valuable f=
or future discussion and therefore I support publication of this document.<=
br>


=C2=A0 =C2=A0 Thus the issue here is not really the loss of transport perfo=
rmance information since that remains available if consent can be obtained,=
 but rather the collection of that information by unauthorized third partie=
s.



[MK] The issue here IS loss of visibly. Yes it's not great that we have=
 all the mechanisms in the network now that use the information that were n=
ot supposed to be used by the network. However, we can't deny that if w=
e change the end-to-end protocol that this will have an impact on the netwo=
rk and how we mange networks today. In some cases we can be happy that some=
 of the boxes will just go away but in other case this can cause problems a=
nd can noticeably impact end-to-end performance, e.g. when an operator is n=
ot able to quickly locate the root cause of a problem anymore.



[MK] Providing equivalent information based on consent is the solution to t=
he problem described in this draft and something we should be working on bu=
t is not there yet.



[MK] Collection of information by unauthorized third party is another probl=
em which still exists and is now just shifted to another layer but would fo=
r sure need another draft (or multiple ones).





=C2=A0 =C2=A0 > On Nov 3, 2019, at 2:20 PM, Eric Rescorla <ekr@rtfm.com> wrote:

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > After reviewing this document, I share Christian Huitema=
's concern

=C2=A0 =C2=A0 > about the tone and perspective of this document, which, =
while saying

=C2=A0 =C2=A0 > that encryption is good, then proceeds to mostly lament =
how difficult

=C2=A0 =C2=A0 > it makes life for various entities other than the endpoi=
nts. It seems

=C2=A0 =C2=A0 > to me rather problematic to publish this document as an =
RFC for

=C2=A0 =C2=A0 > several reasons:

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > - Yes, it's true that the trend towards encrypting e=
verything has

=C2=A0 =C2=A0 >=C2=A0 =C2=A0and continues to make a number of entities s=
ad, but that's a point

=C2=A0 =C2=A0 >=C2=A0 =C2=A0which is already made in RFC 8404. How does =
all of the additional

=C2=A0 =C2=A0 >=C2=A0 =C2=A0detail here help?

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > - The community of people designing new transport protoc=
ols has

=C2=A0 =C2=A0 >=C2=A0 =C2=A0already weighed all the considerations here =
and come down pretty

=C2=A0 =C2=A0 >=C2=A0 =C2=A0decisively on the side of "encrypt all =
the things". Given that

=C2=A0 =C2=A0 >=C2=A0 =C2=A0both SCTP-over-DTLS and QUIC do this, it see=
ms pretty unlikely

=C2=A0 =C2=A0 >=C2=A0 =C2=A0we're going to design a new transport pr=
otocol that doesn't.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > - Having an IETF Consensus RFC that is so heavily weight=
ed on the side

=C2=A0 =C2=A0 >=C2=A0 =C2=A0of "this is how encryption inconvenienc=
es us" and so light on "these

=C2=A0 =C2=A0 >=C2=A0 =C2=A0are the attacks we are preventing" give=
s a misleading picture of the

=C2=A0 =C2=A0 >=C2=A0 =C2=A0IETF community's view of the relative pr=
iority of these

=C2=A0 =C2=A0 >=C2=A0 =C2=A0concerns. ISTM that RFC 8558 -- though perha=
ps imperfect -- far more

=C2=A0 =C2=A0 >=C2=A0 =C2=A0closely reflects that consensus.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > In short, I do not think this draft should be published =
as an RFC.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > I have appended a number of detailed comments which IMO =
need to be

=C2=A0 =C2=A0 > addressed in any case, but even if they were resolved, t=
hat would not

=C2=A0 =C2=A0 > address my primary concern.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > COMMENTS

=C2=A0 =C2=A0 > S 2.1.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A02.1.=C2=A0 Use of Transport Header Info=
rmation in the Network

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 In-network measurement of trans=
port flow characteristics can be used

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 to enhance performance, and con=
trol cost and service reliability.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Some operators have deployed fu=
nctionality in middleboxes to both

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 support network operations and =
enhance performance.=C2=A0 This reliance on

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > This seems like a contested point. My understanding is t=
hat while

=C2=A0 =C2=A0 > these middleboxes are *intended* to enhance performance =
that there is

=C2=A0 =C2=A0 > doubt that they actually do.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > S 2.1.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 to enhance performance, and con=
trol cost and service reliability.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Some operators have deployed fu=
nctionality in middleboxes to both

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 support network operations and =
enhance performance.=C2=A0 This reliance on

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 the presence and semantics of s=
pecific header information leads to

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 ossification, where an endpoint=
 could be required to supply a

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 specific header to receive the =
network service that it desires.=C2=A0 In

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > Well, not just the network service it desires but *any* =
service.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > S 2.1.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 specific header to receive the =
network service that it desires.=C2=A0 In

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 some cases, this could be benig=
n or advantageous to the protocol

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 (e.g., recognising the start of=
 a connection, or explicitly exposing

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 protocol information can be exp=
ected to provide more consistent

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 decisions by on-path devices th=
an the use of diverse methods to infer

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 semantics from other flow prope=
rties).=C2=A0 In other cases, the

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > Is there evidence of this?

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > S 2.1.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 As an example of ossification, =
consider the experience of developing

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Transport Layer Security (TLS) =
1.3 [RFC8446].=C2=A0 This required a design

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 that recognised that deployed m=
iddleboxes relied on the presence of

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 certain header filed exposed in=
 TLS 1.2, and failed if those headers

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 were changed.=C2=A0 Other examp=
les of the impact of ossification can be

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > I think you mean "fields" and it wasn't he=
aders so much as handshake

=C2=A0 =C2=A0 > data.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > S 2.2.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 This supports use of this infor=
mation by on-path devices, but at the

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 same time can be expected to le=
ad to ossification of the transport

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 header, because network forward=
ing could evolve to depend on the

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 presence and/or value of these =
fields.=C2=A0 To avoid unwanted inspection,

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 a protocol could intentionally =
vary the format or value of exposed

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 header fields [I-D.ietf-tls-gre=
ase].

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > It's not just a matter of unwanted inspection. There=
's a real question

=C2=A0 =C2=A0 > about whether we want these on-path devices to have this=
 information

=C2=A0 =C2=A0 > at all, as it is potentially used for surveillance, traf=
fic

=C2=A0 =C2=A0 > analysis, etc.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > S 2..2.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 While encryption can hide trans=
port header information, it does not

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 prevent ossification of the net=
work service.=C2=A0 People seeking to

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 understand network traffic coul=
d come to rely on pattern inferences

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 and other heuristics as the bas=
is for network decision and to derive

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 measurement data.=C2=A0 This ca=
n create new dependencies on the transport

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > This also seems quite contested. Do you have any evidenc=
e of such a

=C2=A0 =C2=A0 > thing happening? 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > S 2.3.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0anomalies, and fai=
lure pathologies at any point along the Internet

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path.=C2=A0 In man=
y cases, it is important to relate observations to

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0specific equipment=
/configurations or network segments.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Concealing transpo=
rt header information makes performance/

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0behaviour unavaila=
ble to passive observers along the path,

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > While also making traffic analysis more difficult.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > S 2.3.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0applications it is=
 important to relate observations to specific

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0equipment/configur=
ations or particular network segments.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Concealing transpo=
rt header information can make analysis harder

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or impossible.=C2=
=A0 This could impact the ability for an operator to

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0anticipate the nee=
d for network upgrades and roll-out.=C2=A0 It can

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > Or to reduce the opportunities for traffic discriminatio=
n.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > S 2.3.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Different parties will view the=
 relative importance of these issues

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 differently.=C2=A0 For some, th=
e benefits of encrypting some, or all, of

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 the transport headers may outwe=
igh the impact of doing so; others

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 might make a different trade-of=
f.=C2=A0 The purpose of highlighting the

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 trade-offs is to make such anal=
ysis possible.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > This whole section seems to really just ignore the fact =
that many of

=C2=A0 =C2=A0 > these practices are unwanted.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > S 3.1.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Firewalls).=C2=A0 Common issues=
 concerning IP address sharing are

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 described in [RFC6269].

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0

=C2=A0 =C2=A0 > >=C2=A0 =C2=A03.1.=C2=A0 Observing Transport Informat=
ion in the Network

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 If in-network observation of tr=
ansport protocol headers is needed,

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > Why is this needed? I know some people might want it.
=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > S 3.1.1.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A03.1.1.=C2=A0 Flow Identification Using =
Transport Layer Headers

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Flow identification is a common=
 function.=C2=A0 For example, performed by

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 measurement activities, QoS cla=
ssification, firewalls, Denial of

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Service, DOS, prevention.=C2=A0=
 This becomes more complex and less easily

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 achieved when multiplexing is u=
sed at or above the transport layer.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > Also traffic discrimination and blocking.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > S 3.1.1.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 use heuristics to infer that sh=
ort UDP packets with regular spacing

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 carry audio traffic.=C2=A0 Oper=
ational practices aimed at inferring

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 transport parameters are out of=
 scope for this document, and are only

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 mentioned here to recognize tha=
t encryption does not prevent

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 operators from attempting to ap=
ply practices that were used with

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 unencrypted transport headers.<=
br>
=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > This has a really threatening tone. If you don't giv=
e us what we want,

=C2=A0 =C2=A0 > look what could happen.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > S 3.1.2.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 This information can support ne=
twork operations, inform capacity

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 planning, and assist in determi=
ning the need for equipment and/or

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 configuration changes by networ=
k operators.=C2=A0 It can also inform

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Internet engineering activities=
 by informing the development of new

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 protocols, methodologies, and p=
rocedures.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > What is the point of this exhaustive list?

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > S 3.1.3.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0AQM and ECN offer =
a range of algorithms and configuration options.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Tools therefore ne=
ed to be available to network operators and

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0researchers to und=
erstand the implication of configuration choices

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and transport beha=
viour as the use of ECN increases and new

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0methods emerge [RF=
C7567].

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > QUIC sort of hides ECN feedback but not ECN marking.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > S 3.2.4.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A network operator=
 needs tools to understand if datagram flows

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., using UDP) =
comply with congestion control expectations and

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0therefore whether =
there is a need to deploy methods such as rate-

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0limiters, transpor=
t circuit breakers, or other methods to enforce

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0acceptable usage f=
or the offered service.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > Does it *need* it or does it just want it. Note that we =
have had DTLS-

=C2=A0 =C2=A0 > SCTP with WebRTC without this property for some time now=
. Can you provide

=C2=A0 =C2=A0 > some evidence that operators have been inconvenienced by=
 not having it.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > S 3.3.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 operators bring together hetero=
geneous types of network equipment and

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 seek to deploy opportunistic me=
thods to access radio spectrum.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 A flow that conceals its transp=
ort header information could imply

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 "don't touch" to =
some operators.=C2=A0 This could limit a trouble-shooting

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 response to "can't hel=
p, no trouble found".

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > We have quite a bit of QUIC traffic now. I'd be inte=
rested in hearing

=C2=A0 =C2=A0 > from the gQUIC team whether they have seen anything like=
 this.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > S 4.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 There are several motivations f=
or encryption:

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 o=C2=A0 One motive to use encry=
ption is a response to perceptions that the

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0network has become=
 ossified by over-reliance on middleboxes that

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0prevent new protoc=
ols and mechanisms from being deployed.=C2=A0 This

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > This isn't just a perception, it's a demonstrabl=
e reality.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > S 4.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 o=C2=A0 One motive to use encry=
ption is a response to perceptions that the

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0network has become=
 ossified by over-reliance on middleboxes that

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0prevent new protoc=
ols and mechanisms from being deployed.=C2=A0 This

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has lead to a perc=
eption that there is too much "manipulation" of

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0protocol headers w=
ithin the network, and that designing to deploy

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > Not just manipulation, also inspection.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > S 4.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0One example of enc=
ryption at the network layer is the use of IPsec

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Encapsulating Secu=
rity Payload (ESP) [RFC4303] in tunnel mode.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This encrypts and =
authenticates all transport headers, preventing

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0visibility of the =
transport headers by in-network devices.=C2=A0 Some

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0VPN methods also e=
ncrypt these headers.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > This seems like a bad example as part of the point of a =
VPN is to

=C2=A0 =C2=A0 > conceal the headers form the network.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > S 6.1.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0

=C2=A0 =C2=A0 > >=C2=A0 =C2=A06.1.=C2=A0 Independent Measurement

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 Independent observation by mult=
iple actors is important if the

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 transport community is to maint=
ain an accurate understanding of the

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 network.=C2=A0 Encrypting trans=
port header encryption changes the ability

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > This is ironic because QUIC is much better for endpoint =
measurement

=C2=A0 =C2=A0 > than TCP because the details are accessible at the appli=
cation layer.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > S 8.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 example, an attacker could cons=
truct a DOS attack by sending packets

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 with a sequence number that fal=
ls within the currently accepted range

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 of sequence numbers at the rece=
iving endpoint, this would then

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 introduce additional work at th=
e receiving endpoint, even though the

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 data in the attacking packet ma=
y not finally be delivered by the

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 transport layer.=C2=A0 This is =
sometimes known as a "shadowing attack".

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > This doesn't seem to be an issue with protocols that=
 authenticate the SN.

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > S 8.

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 An attack can, for example, dis=
rupt receiver processing, trigger loss

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 and retransmission, or make a r=
eceiving endpoint perform unproductive

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 decryption of packets that cann=
ot be successfully decrypted (forcing

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 a receiver to commit decryption=
 resources, or to update and then

=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 restore protocol state).

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > This is not a real issue for QUIC or similar protocols
=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > 

=C2=A0 =C2=A0 > _______________________________________________

=C2=A0 =C2=A0 > saag mailing list

=C2=A0 =C2=A0 > saag@=
ietf.org

=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/s=
aag










--000000000000e6e9950596885280--


From nobody Mon Nov  4 09:46:41 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655801208F3; Mon,  4 Nov 2019 09:46:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZ5VTrVFP-A7; Mon,  4 Nov 2019 09:46:36 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB17120232; Mon,  4 Nov 2019 09:46:35 -0800 (PST)
Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 3AAFF1B000A3; Mon,  4 Nov 2019 17:46:28 +0000 (GMT)
Message-ID: <5DC063F2.8040502@erg.abdn.ac.uk>
Date: Mon, 04 Nov 2019 17:46:26 +0000
From: Gorry Fairhurst 
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Christian Huitema 
CC: Mirja Kuehlewind ,  Eric Rescorla , tsvwg IETF list , "saag@ietf.org" 
References:   <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com>   <2d3c909f-b21c-3916-1eb9-db6de5c661e3@huitema.net>
In-Reply-To: <2d3c909f-b21c-3916-1eb9-db6de5c661e3@huitema.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Nov 2019 17:46:39 -0000

Just focussing on the end...

On 04/11/2019, 16:29, Christian Huitema wrote:
>>
>> [MK] That’s not the intention here. But we also need to consider ways 
>> to interact with the network where this brings benefit to both the 
>> network and the performance of the end-to-end traffic. There are 
>> situation where this is the case. And I don’t think one makes sense 
>> without the other.
>>
> You seem to be arguing for something like "performance enhancing 
> proxies". End-to-end encryption is indeed a way to opt out of such 
> proxying. Measurements so far indicate that opting out has very little 
> impact on actual performance, and that whatever impact there is could 
> be reduced by improvements in end-to-end algorithms. In fact, in many 
> cases, end to end performance is better without such proxies. But the 
> real reason for the opposition to the concept is ossification. 
> Enabling such proxies would quickly ossify the new transports, and a 
> such there is a strong consensus in the end-to-end transport designers 
> to use encryption and prevent interference by such devices.
>
On PEPs: The current case for many of the network segments I see is that 
QUIC is quite good, but it is considerably worse (currently) than a PEP 
using Split-TCP. That's not to say it can't improve - but that's not 
true yet. However: It's curious that people keep going back to PEPs, 
because network devices that change the transport header were 
specifically out-of-scope for this ID!
>
> This does not mean that network level deployment have no role in the 
> future. I could see for example tunnels deployed that use FEC or local 
> retransmission to mask the poor performance of a particular subnet. Or 
> I could see end-to-end devices opting into some kinds of application 
> level caching services in order to improve performance. But the draft 
> should be clear: transport protocols do not have to enable 
> interference with the transport bits.
>
There are also many operators - e.g., enterprise who rely on the methods 
currently mentioned in this draft. In this case, they also actually *do* 
care about the performance of the networks they operate. They also do 
care about the topics, which matters most depends on which organisation.
>
> My take is that this draft should not be published as is. It should be 
> rewritten to actually reflect the consensus of the transport area, 
> which has to reflect in particular the work in the QUIC working group.
>
I suspect the information you wish to see about QUIC's design is 
actually available. I'm not sure documenting QUIC is helpful here, if 
the QUIC WG wants to so that, can't it be added to the manageability draft?

I dispute the claim that the entire transport area has the same 
priorities as that voiced at the QUIC WG. I think this discussion needs 
to look outside the QUIC working group and examine other transports and 
WGs. As far as I know the RTP people are still doing specs in the IETF, 
as are various other transport working groups. Also, this draft has been 
presented at OPsec, and has contributors from other areas outside 
transport...

My assertion is that *current* practice is using transport header 
information & header authentication/encryption is becoming common, let's 
set out what the current facts are. I'm also going to oppose documenting 
new ideas for how we can go forward - as Spencer insisted when this was 
chartered: Proposing new methods belong in a different draft - paraphrased.

Gorry


From nobody Mon Nov  4 09:54:39 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABD9120843; Mon,  4 Nov 2019 09:54:30 -0800 (PST)
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,  DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrot8eUn7i1v; Mon,  4 Nov 2019 09:54:27 -0800 (PST)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02on062b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe07::62b]) (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 22121120BAE; Mon,  4 Nov 2019 09:54:27 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h31aW0J5ASwe3fid083Mk260Dyx89z8Dw2T2LuPeZ1vagC9kIPPFw4ywNiEez/YrUg8suqPOkf9XNlCch3+T4n8C3wrVSlGEBeyiFWCQEXz7tPKQd4Go4eP/YoPtESu4+/duebpZb6YYPb0cpbnRurQaU+gVyohx6A9pop9AFtDGfR0i9cjIqipsq7eqW97iRMz4BSm8vNJzby4SPgw7lVwzGgy4hGudieo06Wfhmc4KfR0aa2TmmiwIvYgKJUNoevD0JTHpcP08CFRoFNfwEJlueXt6KmfTmYFc9ncsKx9haEeDEb4ejQnUgefUs/OOsBfvWmYxGWhjq47Q6xKvKw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LBNhyvRhgsk3GYopqGJqlD/r263k2vvbIfO602jPOlo=; b=ZZYA7gTIX4TrVbkDXsYWCqZGhX0GNDwRnW24rhIbRSgC4ssvPKnoUASFZoszPr/yvMhf8Lh0XIVTntQDsU6bfMStqgJn1BgTUEcBmNgZS98CZmHAvTo450NMv3RLFJRRANBnf9eFBvNwgCnpE4bpX7SvWRIL9aUQKeHesnnGxnbZ4q3gWss/QE8rgKX2pDDxhmJJG4mJkgFmWgteqYAW5nApH7/3CgfhRJ5jdiw9YWbvj5kuW6Ny3cfejYk3N9fWIzUB0rWQGiyMVd3hcTTnfjeNAht8LrNwYW+GLtqdiJN9qQymh+Wiv0XV5lRJrnzYgmC3EP3GiGui+TuKPaeKhA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LBNhyvRhgsk3GYopqGJqlD/r263k2vvbIfO602jPOlo=; b=gk3A56/gC8fjsVPuw3XC9sJTdpABXXXQ3TrZcxtf06Fhe6xsWR6gaO6Xe4YBFWJqWdKhK4KR4Mb62hRoDyjNTEcQwv7ULWe26e1IK1PPhXGj6yGl4F12FVgzGDNoEBkd3C4XztJxrlBCgwfcVaP59G24sSanJ4ekT2Vm9MDQVek=
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB6004.eurprd07.prod.outlook.com (20.178.114.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Mon, 4 Nov 2019 17:54:24 +0000
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4189:4ef8:bfc1:ec58]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4189:4ef8:bfc1:ec58%7]) with mapi id 15.20.2430.013; Mon, 4 Nov 2019 17:54:24 +0000
From: Mirja Kuehlewind 
To: Christian Huitema , Tom Herbert 
CC: tsvwg IETF list , "saag@ietf.org" 
Thread-Topic: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
Thread-Index: AQHVkpTuK59Ux5RWm0aKwFV5BLM7VKd6Ri6AgACF/4CAAD37gIAAImWAgAAEzQCAAAQnAIAAJ+CA
Date: Mon, 4 Nov 2019 17:54:24 +0000
Message-ID: 
References:   <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com>    <77cf17ad-d7e7-6c67-1a4f-d3a60e7c63ec@huitema.net>
In-Reply-To: <77cf17ad-d7e7-6c67-1a4f-d3a60e7c63ec@huitema.net>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mirja.kuehlewind@ericsson.com; 
x-originating-ip: [2003:eb:4700:cf00:3d57:7e7e:af67:8db2]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a36feeb8-a8ae-443b-a1ba-08d7615007a6
x-ms-traffictypediagnostic: AM0PR07MB6004:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0211965D06
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(366004)(396003)(346002)(136003)(199004)(189003)(5660300002)(8936002)(6506007)(81166006)(53546011)(81156014)(44832011)(46003)(486006)(99286004)(7736002)(2616005)(11346002)(446003)(476003)(8676002)(86362001)(76176011)(76116006)(14454004)(316002)(33656002)(102836004)(186003)(25786009)(2906002)(4326008)(6246003)(54896002)(6306002)(6512007)(6116002)(36756003)(71190400001)(478600001)(66946007)(66476007)(256004)(14444005)(71200400001)(66556008)(64756008)(66446008)(54906003)(6436002)(6486002)(110136005)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB6004; H:AM0PR07MB4691.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: czMYS/VC/31UuLJGe/EpwD2dcC2DKoHHlowQFbAfyy8aDMtCiX5Fj4W4rpF60gGLfg0sSCmHSI1JB1qE59qq9jmk23tJIHMbAR/pmtzGZbCMIWSlXh3Dp6++IurAFcCN0JvA9dRs4E5nJP6lavfmS/FbxltdAYSUXf3awTmir194NF8KKbGif4IZAqT8Nr0QUBM4KDq2JvQW+yRuBQifaTPrMLYF+6HpoNF6bkJwOHXqL3HoQS5v4WKk8POqZp6DiDyOsAiqGfc3PsKeOAmRnoUn/Aai+FwZ62jSki44RXmKnHwzJkHvGXSxB9vFimDf6beBadcbAP9vBcI7KnHr+eO+AzadvsjFNqnNaeB+A+R0Ul/ucYrAqv79XZ+WDwvGnhYubDMQ5Svv7yqxe98E9v9GP+Dlr102ei161w817FQNtPPLmWyomnXMrAmJGSDs
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_E497DF67C6AB4AF485E2CDC381D86E64ericssoncom_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a36feeb8-a8ae-443b-a1ba-08d7615007a6
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2019 17:54:24.8554 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: I7rQmQZF0nDfm25oV5wADzlqMCUBypmxxFRH5V0qOJGUKyapXLzAgH/bPWePlCOQPYw3Cp/xm5sV6M3dvuLAEf1lSZV759k6CHOUYWdgO4E=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6004
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Nov 2019 17:54:37 -0000

--_000_E497DF67C6AB4AF485E2CDC381D86E64ericssoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgVG9tLCBoaSBDaHJpc3RpYW4sDQoNCnNlZSBiZWxvdy4NCg0KRnJvbTogQ2hyaXN0aWFuIEh1
aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ+DQpEYXRlOiBNb25kYXksIDQuIE5vdmVtYmVyIDIw
MTkgYXQgMTc6MzINClRvOiBUb20gSGVyYmVydCA8dG9tQGhlcmJlcnRsYW5kLmNvbT4sIE1pcmph
IEt1ZWhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tPg0KQ2M6IHRzdndnIElF
VEYgbGlzdCA8dHN2d2dAaWV0Zi5vcmc+LCAic2FhZ0BpZXRmLm9yZyIgPHNhYWdAaWV0Zi5vcmc+
DQpTdWJqZWN0OiBSZTogW3NhYWddIFt0c3Z3Z10gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi10c3Z3
Zy10cmFuc3BvcnQtZW5jcnlwdC0wOC50eHQNCg0KDQoNCk9uIDExLzQvMjAxOSA4OjE2IEFNLCBU
b20gSGVyYmVydCB3cm90ZToNCg0KW01LXSBUaGF04oCZcyBub3QgdGhlIGludGVudGlvbiBoZXJl
LiBCdXQgd2UgYWxzbyBuZWVkIHRvIGNvbnNpZGVyIHdheXMgdG8gaW50ZXJhY3Qgd2l0aCB0aGUg
bmV0d29yayB3aGVyZSB0aGlzIGJyaW5ncyBiZW5lZml0IHRvIGJvdGggdGhlIG5ldHdvcmsgYW5k
IHRoZSBwZXJmb3JtYW5jZSBvZiB0aGUgZW5kLXRvLWVuZCB0cmFmZmljLiBUaGVyZSBhcmUgc2l0
dWF0aW9uIHdoZXJlIHRoaXMgaXMgdGhlIGNhc2UuIEFuZCBJIGRvbuKAmXQgdGhpbmsgb25lIG1h
a2VzIHNlbnNlIHdpdGhvdXQgdGhlIG90aGVyLg0KDQpNaXJqYSwNCg0KDQoNClllcywgdGhhdCBp
cyB0cnVlLiBXZSBuZWVkIGEgd2F5IHRvIGFsbG93IGhvc3RzIHRvIHNpZ25hbCB0aGUgbmV0d29y
ay4NCg0KQnV0IGRvaW5nIHRoaXMgaW4gdGhlIHRyYW5zcG9ydCBsYXllciBpcyBhcmNoaXRlY3R1
cmFsbHkgaW5jb3JyZWN0LA0KDQpoYXMgbGVkIHRvIHByb3RvY29sIG9zc2lmaWNhdGlvbiwgaXNu
J3Qgcm9idXN0IGxpa2UgaW4gdGhlIGNhc2Ugb2YNCg0KUVVJQywgcHJlc2VudHMgYSBzZWN1cml0
eSBhbmQgcHJpdmFjeSByaXNrLCBhbmQgZG9lc24ndCBzY2FsZSBiZXlvbmQNCg0Kc3VwcG9ydGlu
ZyBvbmUgb3IgbWF5YmUgdHdvIHRyYW5zcG9ydCBwcm90b2NvbHMuIEV4cGxpY2l0aW5nIHNpZ25h
bGluZw0KDQpjb250YWluZWQgaW4gdGhlIG5ldHdvcmsgbGF5ZXIgaGVhZGVycyB0aGF0IGlzIHVu
ZGVyIGNvbnRyb2wgb2YgdGhlDQoNCnNlbmRpbmcgaG9zdCBpcyB0aGUgY29ycmVjdCBhbHRlcm5h
dGl2ZSBJTU8uDQoNCisxLg0KDQpXZSB3b3VsZCBiZSBiZXR0ZXIgb2ZmIGlmIHdlIHN0YXJ0ZWQg
d29yayBvbiB0aGlzIHNvb25lciByYXRoZXIgdGhhbiBsYXRlci4NCg0KSSBhZ3JlZSBidXQgaW4g
dGhlIGVuZCB3ZSBoYXZlIHRvIGJlIHJlYWxpc3RpYyB3aGF0IGNhbiBiZSBkZXBsb3llZC4gSW4g
Y2FzZSBvZiB0aGUgc3BpbiBiaXQsIHRoaXMgaXMgaW5mb3JtYXRpb24gdGhhdCBpcywgYnkgY2hh
bmNlLCBtZWFzdXJhYmxlIGluIFRDUCBhbmQgdGhlcmVmb3JlIG9ubHkgYSBwcm9ibGVtIHdpdGgg
UVVJQyB0cmFmZmljIChmb3Igbm93IGFzIGxvbmcgYXMgd2UgZG9u4oCZdCBkZXZlbG9wIGFueSBu
ZXcgdHJhbnNwb3J0cykuIFllcywgaGF2aW5nIGEgdHJhbnNwb3J0LWluZGVwZW5kZW50IG1ldGhv
ZCB3b3VsZCBiZSBldmVuIGJldHRlciBidXQgaWYgd2UgY2FuIGdldCB0aGUgc3BpbiBiaXQgZGVw
bG95ZWQgYW5kIGl0IGFkZHJlc3NlcyB0aGUgcHJvYmxlbSB3ZSBoYXZlLCBJ4oCZbSBhbGwgZm9y
IHRoYXQhDQoNCk1pcmphDQoNCg0KDQoNCg0KDQoNCi0tIENocmlzdGlhbiBIdWl0ZW1hDQo=

--_000_E497DF67C6AB4AF485E2CDC381D86E64ericssoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz
Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z
ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow
Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRp
b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246
dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp
bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3
Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1z
dHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t
cmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBj
bTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm
O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl
Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu
azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1h
aWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5
OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1
bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA
cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1
cHQgNzAuODVwdCAyLjBjbSA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk
U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5rPSIj
MDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT
Ij5IaSBUb20sIGhpIENocmlzdGlhbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+c2VlIGJlbG93LjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n
dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt
IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw
dCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8
L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5DaHJp
c3RpYW4gSHVpdGVtYSAmbHQ7aHVpdGVtYUBodWl0ZW1hLm5ldCZndDs8YnI+DQo8Yj5EYXRlOiA8
L2I+TW9uZGF5LCA0LiBOb3ZlbWJlciAyMDE5IGF0IDE3OjMyPGJyPg0KPGI+VG86IDwvYj5Ub20g
SGVyYmVydCAmbHQ7dG9tQGhlcmJlcnRsYW5kLmNvbSZndDssIE1pcmphIEt1ZWhsZXdpbmQgJmx0
O21pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+dHN2d2cg
SUVURiBsaXN0ICZsdDt0c3Z3Z0BpZXRmLm9yZyZndDssICZxdW90O3NhYWdAaWV0Zi5vcmcmcXVv
dDsgJmx0O3NhYWdAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbc2FhZ10g
W3RzdndnXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXRzdndnLXRyYW5zcG9ydC1lbmNyeXB0LTA4
LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0
Ij5PbiAxMS80LzIwMTkgODoxNiBBTSwgVG9tIEhlcmJlcnQgd3JvdGU6PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv
dHRvbTo1LjBwdCI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxl
PSJjb2xvcjpibGFjayI+W01LXSBUaGF04oCZcyBub3QgdGhlIGludGVudGlvbiBoZXJlLiBCdXQg
d2UgYWxzbyBuZWVkIHRvIGNvbnNpZGVyIHdheXMgdG8gaW50ZXJhY3Qgd2l0aCB0aGUgbmV0d29y
ayB3aGVyZSB0aGlzIGJyaW5ncyBiZW5lZml0IHRvIGJvdGggdGhlIG5ldHdvcmsgYW5kIHRoZSBw
ZXJmb3JtYW5jZSBvZiB0aGUgZW5kLXRvLWVuZCB0cmFmZmljLiBUaGVyZSBhcmUgc2l0dWF0aW9u
IHdoZXJlIHRoaXMgaXMgdGhlIGNhc2UuIEFuZCBJIGRvbuKAmXQgdGhpbmsgb25lIG1ha2VzIHNl
bnNlIHdpdGhvdXQgdGhlIG90aGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1
b3RlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5NaXJqYSw8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5ZZXMsIHRoYXQgaXMgdHJ1ZS4g
V2UgbmVlZCBhIHdheSB0byBhbGxvdyBob3N0cyB0byBzaWduYWwgdGhlIG5ldHdvcmsuPG86cD48
L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+QnV0IGRvaW5nIHRo
aXMgaW4gdGhlIHRyYW5zcG9ydCBsYXllciBpcyBhcmNoaXRlY3R1cmFsbHkgaW5jb3JyZWN0LDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPmhhcyBsZWQg
dG8gcHJvdG9jb2wgb3NzaWZpY2F0aW9uLCBpc24ndCByb2J1c3QgbGlrZSBpbiB0aGUgY2FzZSBv
ZjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlFVSUMs
IHByZXNlbnRzIGEgc2VjdXJpdHkgYW5kIHByaXZhY3kgcmlzaywgYW5kIGRvZXNuJ3Qgc2NhbGUg
YmV5b25kPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+
c3VwcG9ydGluZyBvbmUgb3IgbWF5YmUgdHdvIHRyYW5zcG9ydCBwcm90b2NvbHMuIEV4cGxpY2l0
aW5nIHNpZ25hbGluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoz
Ni4wcHQiPmNvbnRhaW5lZCBpbiB0aGUgbmV0d29yayBsYXllciBoZWFkZXJzIHRoYXQgaXMgdW5k
ZXIgY29udHJvbCBvZiB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl
ZnQ6MzYuMHB0Ij5zZW5kaW5nIGhvc3QgaXMgdGhlIGNvcnJlY3QgYWx0ZXJuYXRpdmUgSU1PLjxv
OnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu
MHB0Ij4mIzQzOzEuPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0
Ij5XZSB3b3VsZCBiZSBiZXR0ZXIgb2ZmIGlmIHdlIHN0YXJ0ZWQgd29yayBvbiB0aGlzIHNvb25l
ciByYXRoZXIgdGhhbiBsYXRlci48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT
Ij5JIGFncmVlIGJ1dCBpbiB0aGUgZW5kIHdlIGhhdmUgdG8gYmUgcmVhbGlzdGljIHdoYXQgY2Fu
IGJlIGRlcGxveWVkLiBJbiBjYXNlIG9mIHRoZSBzcGluIGJpdCwgdGhpcyBpcyBpbmZvcm1hdGlv
biB0aGF0IGlzLCBieSBjaGFuY2UsIG1lYXN1cmFibGUgaW4gVENQIGFuZCB0aGVyZWZvcmUgb25s
eSBhIHByb2JsZW0gd2l0aCBRVUlDIHRyYWZmaWMgKGZvciBub3cgYXMgbG9uZyBhcyB3ZSBkb27i
gJl0IGRldmVsb3ANCiBhbnkgbmV3IHRyYW5zcG9ydHMpLiBZZXMsIGhhdmluZyBhIHRyYW5zcG9y
dC1pbmRlcGVuZGVudCBtZXRob2Qgd291bGQgYmUgZXZlbiBiZXR0ZXIgYnV0IGlmIHdlIGNhbiBn
ZXQgdGhlIHNwaW4gYml0IGRlcGxveWVkIGFuZCBpdCBhZGRyZXNzZXMgdGhlIHByb2JsZW0gd2Ug
aGF2ZSwgSeKAmW0gYWxsIGZvciB0aGF0IQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNw
YW4gbGFuZz0iRU4tVVMiPk1pcmphPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFu
Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO
LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw
dCI+LS0gQ2hyaXN0aWFuIEh1aXRlbWE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K
PC9odG1sPg0K

--_000_E497DF67C6AB4AF485E2CDC381D86E64ericssoncom_--


From nobody Mon Nov  4 10:02:20 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC92120C88; Mon,  4 Nov 2019 10:02:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vThHzZY1As9T; Mon,  4 Nov 2019 10:02:05 -0800 (PST)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60066.outbound.protection.outlook.com [40.107.6.66]) (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 A2980120C7C; Mon,  4 Nov 2019 10:02:04 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iWCJA1X5tpz8G6e3Nrdw3HyqBsxovU/knMVU8frcEMUeCFVFsxFCGIuIPmlxZ3m1kD8LHNN2KEfABlZwCVn1JLlIQDslUNb92gTTvtLzb5XFlaOqBGTIAS/jnVrx5tO7bbAr2IxpHhfcApQzhUK/JPahwg5YwfPpF7+HOKlY7f+QQCvUTtHO3krt8q+AIr/5RFucpfJyYquZJFJOW7AF3ges3rTZF5w0rquuCCB7XynFGctMhnvtxbw8KU+tbNIrdiqpmOtQ72WAkrRbKgIE4S7Qv/yYKOpPqTFeJl4P99JChI65tG5f4fhjAtXAZzcLCtwfbL/rU4wbmh2FNt/K3Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ONZXoxVYzYYWk0zhNDXNI2AJ6L3OF5bOoTBrX7SdmW4=; b=NjI5VP5aleiQMoZ4KDgfAGE0uEjTZi5dwMPRSZXzEY92j6ki+uzkNZeASa+INuV/Z/8QV4r1fmzsXNyPqqB5OfqGTcBTbs5861ciZcCyPRc2CDWDUF8yPVGYx8idvMWfbU1BN+kMFjm8K33CDLzCa2EkWWfKBmiIOv7akIrJzzleHYRagQ6OLCRgORk5ymfUvbqETtTgjqQzdUJKQuH4mS6uBo5n/tjbo8F8PQE+DKOonMLXTQjaZqdazOSkyQRJY+o8f02wiO/qJFqdwZ8IShyPmD6NVh9lcapJasMgD9c0r43ef726zH/J70gqfikw7D6uVeS/DnxqEpcY9gtHWQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ONZXoxVYzYYWk0zhNDXNI2AJ6L3OF5bOoTBrX7SdmW4=; b=kXGbyNhabpEagezO/jns0QxYsWAJZ61MeMjrmGyFlzT0DqnhBvTmAdok20i8juRtU0bSqcF7IhzvzJWtB6N3yncLjMSZFvjDxyXLATVHdpAyUJg5u0B+x3sgEsiR37/VUuURhevHSO/to8syD86zhTGbr0/Y5JGWa+7BY+UjiBY=
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB6242.eurprd07.prod.outlook.com (10.186.172.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Mon, 4 Nov 2019 18:02:02 +0000
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4189:4ef8:bfc1:ec58]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4189:4ef8:bfc1:ec58%7]) with mapi id 15.20.2430.013; Mon, 4 Nov 2019 18:02:02 +0000
From: Mirja Kuehlewind 
To: "gorry@erg.abdn.ac.uk" , Christian Huitema 
CC: Eric Rescorla , tsvwg IETF list , "saag@ietf.org" 
Thread-Topic: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
Thread-Index: AQHVky08JY2FDXmr60OAsbMwFkv5fad7STQAgAAVH4A=
Date: Mon, 4 Nov 2019 18:02:02 +0000
Message-ID: 
References:   <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com>   <2d3c909f-b21c-3916-1eb9-db6de5c661e3@huitema.net> <5DC063F2.8040502@erg.abdn.ac.uk>
In-Reply-To: <5DC063F2.8040502@erg.abdn.ac.uk>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mirja.kuehlewind@ericsson.com; 
x-originating-ip: [2003:eb:4700:cf00:3d57:7e7e:af67:8db2]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 221b6ed1-7c82-4659-1a67-08d76151185d
x-ms-traffictypediagnostic: AM0PR07MB6242:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0211965D06
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(396003)(346002)(39860400002)(366004)(189003)(199004)(6486002)(2501003)(2906002)(76176011)(478600001)(6246003)(6436002)(102836004)(53546011)(296002)(316002)(54906003)(110136005)(14454004)(71190400001)(229853002)(71200400001)(44832011)(6512007)(256004)(5660300002)(486006)(305945005)(7736002)(6506007)(186003)(25786009)(86362001)(11346002)(46003)(2616005)(36756003)(446003)(64756008)(476003)(76116006)(66476007)(66556008)(66946007)(8936002)(33656002)(66446008)(99286004)(81166006)(81156014)(8676002)(14444005)(6116002)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB6242; H:AM0PR07MB4691.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 846VQorsEGGA8L2WF5hbdavkQr8FjNR2kndvV2/hxaa6L1W+N1G/FsxcUl1q1af04JcWk8Bed2pzKIO2n/miyL7YOmKSQ+W8SFFMNElSvpVvTAlKhe4+OlE3MAIa8fRbo8nP9LhTvewobuxPyQTfSMIXmo6mHE7OgyZYV0WAw6HjlrezU+SuCbNX2ZpK75m3CwAgus95mfMZpwZfvwBjzmknree/zR6Ub1c1m8PFCq01pph7+Yahs/tazAw5lkhI1I7rS9koR6uN0rkdtADNTPp4LPwd9vMlS4wqBILPx8eZ81zH6gXOPeAkCoiiWbfhaA94pTyQ6+girbVrFEd5MkTd+Btfr8simaeYrDrWKe5+iUDmQBY/ECuQY+1RAZEcuCwLLUSnJXGUHbrmLbJw0y7kky2m79PBj0fAibH9O2zKSaID4LjA1UrNaaonMqax
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <318504C219FC7940BC6995480CD119A6@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 221b6ed1-7c82-4659-1a67-08d76151185d
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2019 18:02:02.4634 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: IGrNDnK8gJJM3fO5Yj37aeiNbI8asfkTvyKbD3VpepGfrGjyiDejR1YjLfNpZCejvnJRyi45WF/FPxfkH3laFmBQ/IESdu7OzGkICP0EOdA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6242
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Nov 2019 18:02:12 -0000

SGkgQ2hyaXN0aWFuLA0KDQpwbGVhc2Ugc2VlIHR3byBjb21tZW50cyBiZWxvdyAobWFya2VkIHdp
dGggW01LXSkuDQoNCk1pcmphDQoNCu+7v09uIDA0LjExLjE5LCAxODo0NiwgIkdvcnJ5IEZhaXJo
dXJzdCIgPGdvcnJ5QGVyZy5hYmRuLmFjLnVrPiB3cm90ZToNCg0KICAgIEp1c3QgZm9jdXNzaW5n
IG9uIHRoZSBlbmQuLi4NCiAgICANCiAgICBPbiAwNC8xMS8yMDE5LCAxNjoyOSwgQ2hyaXN0aWFu
IEh1aXRlbWEgd3JvdGU6DQogICAgPj4NCiAgICA+PiBbTUtdIFRoYXTigJlzIG5vdCB0aGUgaW50
ZW50aW9uIGhlcmUuIEJ1dCB3ZSBhbHNvIG5lZWQgdG8gY29uc2lkZXIgd2F5cyANCiAgICA+PiB0
byBpbnRlcmFjdCB3aXRoIHRoZSBuZXR3b3JrIHdoZXJlIHRoaXMgYnJpbmdzIGJlbmVmaXQgdG8g
Ym90aCB0aGUgDQogICAgPj4gbmV0d29yayBhbmQgdGhlIHBlcmZvcm1hbmNlIG9mIHRoZSBlbmQt
dG8tZW5kIHRyYWZmaWMuIFRoZXJlIGFyZSANCiAgICA+PiBzaXR1YXRpb24gd2hlcmUgdGhpcyBp
cyB0aGUgY2FzZS4gQW5kIEkgZG9u4oCZdCB0aGluayBvbmUgbWFrZXMgc2Vuc2UgDQogICAgPj4g
d2l0aG91dCB0aGUgb3RoZXIuDQogICAgPj4NCiAgICA+IFlvdSBzZWVtIHRvIGJlIGFyZ3Vpbmcg
Zm9yIHNvbWV0aGluZyBsaWtlICJwZXJmb3JtYW5jZSBlbmhhbmNpbmcgDQogICAgPiBwcm94aWVz
Ii4gRW5kLXRvLWVuZCBlbmNyeXB0aW9uIGlzIGluZGVlZCBhIHdheSB0byBvcHQgb3V0IG9mIHN1
Y2ggDQogICAgPiBwcm94eWluZy4gTWVhc3VyZW1lbnRzIHNvIGZhciBpbmRpY2F0ZSB0aGF0IG9w
dGluZyBvdXQgaGFzIHZlcnkgbGl0dGxlIA0KICAgID4gaW1wYWN0IG9uIGFjdHVhbCBwZXJmb3Jt
YW5jZSwgYW5kIHRoYXQgd2hhdGV2ZXIgaW1wYWN0IHRoZXJlIGlzIGNvdWxkIA0KICAgID4gYmUg
cmVkdWNlZCBieSBpbXByb3ZlbWVudHMgaW4gZW5kLXRvLWVuZCBhbGdvcml0aG1zLiBJbiBmYWN0
LCBpbiBtYW55IA0KICAgID4gY2FzZXMsIGVuZCB0byBlbmQgcGVyZm9ybWFuY2UgaXMgYmV0dGVy
IHdpdGhvdXQgc3VjaCBwcm94aWVzLiBCdXQgdGhlIA0KICAgID4gcmVhbCByZWFzb24gZm9yIHRo
ZSBvcHBvc2l0aW9uIHRvIHRoZSBjb25jZXB0IGlzIG9zc2lmaWNhdGlvbi4gDQogICAgPiBFbmFi
bGluZyBzdWNoIHByb3hpZXMgd291bGQgcXVpY2tseSBvc3NpZnkgdGhlIG5ldyB0cmFuc3BvcnRz
LCBhbmQgYSANCiAgICA+IHN1Y2ggdGhlcmUgaXMgYSBzdHJvbmcgY29uc2Vuc3VzIGluIHRoZSBl
bmQtdG8tZW5kIHRyYW5zcG9ydCBkZXNpZ25lcnMgDQogICAgPiB0byB1c2UgZW5jcnlwdGlvbiBh
bmQgcHJldmVudCBpbnRlcmZlcmVuY2UgYnkgc3VjaCBkZXZpY2VzLg0KICAgID4NCiAgICBPbiBQ
RVBzOiBUaGUgY3VycmVudCBjYXNlIGZvciBtYW55IG9mIHRoZSBuZXR3b3JrIHNlZ21lbnRzIEkg
c2VlIGlzIHRoYXQgDQogICAgUVVJQyBpcyBxdWl0ZSBnb29kLCBidXQgaXQgaXMgY29uc2lkZXJh
Ymx5IHdvcnNlIChjdXJyZW50bHkpIHRoYW4gYSBQRVAgDQogICAgdXNpbmcgU3BsaXQtVENQLiBU
aGF0J3Mgbm90IHRvIHNheSBpdCBjYW4ndCBpbXByb3ZlIC0gYnV0IHRoYXQncyBub3QgDQogICAg
dHJ1ZSB5ZXQuIEhvd2V2ZXI6IEl0J3MgY3VyaW91cyB0aGF0IHBlb3BsZSBrZWVwIGdvaW5nIGJh
Y2sgdG8gUEVQcywgDQogICAgYmVjYXVzZSBuZXR3b3JrIGRldmljZXMgdGhhdCBjaGFuZ2UgdGhl
IHRyYW5zcG9ydCBoZWFkZXIgd2VyZSANCiAgICBzcGVjaWZpY2FsbHkgb3V0LW9mLXNjb3BlIGZv
ciB0aGlzIElEIQ0KICAgID4NCiAgICA+IFRoaXMgZG9lcyBub3QgbWVhbiB0aGF0IG5ldHdvcmsg
bGV2ZWwgZGVwbG95bWVudCBoYXZlIG5vIHJvbGUgaW4gdGhlIA0KICAgID4gZnV0dXJlLiBJIGNv
dWxkIHNlZSBmb3IgZXhhbXBsZSB0dW5uZWxzIGRlcGxveWVkIHRoYXQgdXNlIEZFQyBvciBsb2Nh
bCANCiAgICA+IHJldHJhbnNtaXNzaW9uIHRvIG1hc2sgdGhlIHBvb3IgcGVyZm9ybWFuY2Ugb2Yg
YSBwYXJ0aWN1bGFyIHN1Ym5ldC4gT3IgDQogICAgPiBJIGNvdWxkIHNlZSBlbmQtdG8tZW5kIGRl
dmljZXMgb3B0aW5nIGludG8gc29tZSBraW5kcyBvZiBhcHBsaWNhdGlvbiANCiAgICA+IGxldmVs
IGNhY2hpbmcgc2VydmljZXMgaW4gb3JkZXIgdG8gaW1wcm92ZSBwZXJmb3JtYW5jZS4gQnV0IHRo
ZSBkcmFmdCANCiAgICA+IHNob3VsZCBiZSBjbGVhcjogdHJhbnNwb3J0IHByb3RvY29scyBkbyBu
b3QgaGF2ZSB0byBlbmFibGUgDQogICAgPiBpbnRlcmZlcmVuY2Ugd2l0aCB0aGUgdHJhbnNwb3J0
IGJpdHMuDQoNCltNS10gVGhpcyBpcyBub3Qgd2hhdCB0aGUgZHJhZnQgaXMgYXNraW5nIGZvci4g
DQoNCiAgICA+DQogICAgVGhlcmUgYXJlIGFsc28gbWFueSBvcGVyYXRvcnMgLSBlLmcuLCBlbnRl
cnByaXNlIHdobyByZWx5IG9uIHRoZSBtZXRob2RzIA0KICAgIGN1cnJlbnRseSBtZW50aW9uZWQg
aW4gdGhpcyBkcmFmdC4gSW4gdGhpcyBjYXNlLCB0aGV5IGFsc28gYWN0dWFsbHkgKmRvKiANCiAg
ICBjYXJlIGFib3V0IHRoZSBwZXJmb3JtYW5jZSBvZiB0aGUgbmV0d29ya3MgdGhleSBvcGVyYXRl
LiBUaGV5IGFsc28gZG8gDQogICAgY2FyZSBhYm91dCB0aGUgdG9waWNzLCB3aGljaCBtYXR0ZXJz
IG1vc3QgZGVwZW5kcyBvbiB3aGljaCBvcmdhbmlzYXRpb24uDQogICAgPg0KICAgID4gTXkgdGFr
ZSBpcyB0aGF0IHRoaXMgZHJhZnQgc2hvdWxkIG5vdCBiZSBwdWJsaXNoZWQgYXMgaXMuIEl0IHNo
b3VsZCBiZSANCiAgICA+IHJld3JpdHRlbiB0byBhY3R1YWxseSByZWZsZWN0IHRoZSBjb25zZW5z
dXMgb2YgdGhlIHRyYW5zcG9ydCBhcmVhLCANCiAgICA+IHdoaWNoIGhhcyB0byByZWZsZWN0IGlu
IHBhcnRpY3VsYXIgdGhlIHdvcmsgaW4gdGhlIFFVSUMgd29ya2luZyBncm91cC4NCg0KW01LXSBU
aGUgcHVycG9zZSBvZiB0aGlzIGRyYWZ0IGlzIGV4YWN0bHkgdG8gZmluZCBhbmQgZG9jdW1lbnQg
Y29uc2Vuc3VzIGluIHRoZSB0cmFuc3BvcnQgYXJlYSBhbmQgaW4gdGhlIElFVEYuIEkgZG9uJ3Qg
dGhpbmsgYW55IGluZGl2aWR1YWwgYXQgdGhpcyBwb2ludHMga25vd3Mgd2hhdCB0aGUgY29uc2Vu
c3VzIGFjdHVhbGx5IGlzLiBUaGlzIGRvY3VtZW50IGhhcyBzdXBwb3J0IGluIHRzdndnIChvdGhl
cndpc2UgaXQgd291bGQgbm90IGhhdmUgYmVlbiBhZG9wdGVkIGFzIHdnIGRvY3VtZW50KSBhbmQg
SSBhbHNvIGRvbid0IHRoaW5rIHRoZXJlIGlzIGFueXRoaW5nIGluIHRoZSBkcmFmdCB0aGF0IGNv
bnRyYWRpY3RzIGFueSB3b3JrIGluIHRoZSBRVUlDIGdyb3VwLg0KDQoNCiAgICA+DQogICAgSSBz
dXNwZWN0IHRoZSBpbmZvcm1hdGlvbiB5b3Ugd2lzaCB0byBzZWUgYWJvdXQgUVVJQydzIGRlc2ln
biBpcyANCiAgICBhY3R1YWxseSBhdmFpbGFibGUuIEknbSBub3Qgc3VyZSBkb2N1bWVudGluZyBR
VUlDIGlzIGhlbHBmdWwgaGVyZSwgaWYgDQogICAgdGhlIFFVSUMgV0cgd2FudHMgdG8gc28gdGhh
dCwgY2FuJ3QgaXQgYmUgYWRkZWQgdG8gdGhlIG1hbmFnZWFiaWxpdHkgZHJhZnQ/DQogICAgDQog
ICAgSSBkaXNwdXRlIHRoZSBjbGFpbSB0aGF0IHRoZSBlbnRpcmUgdHJhbnNwb3J0IGFyZWEgaGFz
IHRoZSBzYW1lIA0KICAgIHByaW9yaXRpZXMgYXMgdGhhdCB2b2ljZWQgYXQgdGhlIFFVSUMgV0cu
IEkgdGhpbmsgdGhpcyBkaXNjdXNzaW9uIG5lZWRzIA0KICAgIHRvIGxvb2sgb3V0c2lkZSB0aGUg
UVVJQyB3b3JraW5nIGdyb3VwIGFuZCBleGFtaW5lIG90aGVyIHRyYW5zcG9ydHMgYW5kIA0KICAg
IFdHcy4gQXMgZmFyIGFzIEkga25vdyB0aGUgUlRQIHBlb3BsZSBhcmUgc3RpbGwgZG9pbmcgc3Bl
Y3MgaW4gdGhlIElFVEYsIA0KICAgIGFzIGFyZSB2YXJpb3VzIG90aGVyIHRyYW5zcG9ydCB3b3Jr
aW5nIGdyb3Vwcy4gQWxzbywgdGhpcyBkcmFmdCBoYXMgYmVlbiANCiAgICBwcmVzZW50ZWQgYXQg
T1BzZWMsIGFuZCBoYXMgY29udHJpYnV0b3JzIGZyb20gb3RoZXIgYXJlYXMgb3V0c2lkZSANCiAg
ICB0cmFuc3BvcnQuLi4NCiAgICANCiAgICBNeSBhc3NlcnRpb24gaXMgdGhhdCAqY3VycmVudCog
cHJhY3RpY2UgaXMgdXNpbmcgdHJhbnNwb3J0IGhlYWRlciANCiAgICBpbmZvcm1hdGlvbiAmIGhl
YWRlciBhdXRoZW50aWNhdGlvbi9lbmNyeXB0aW9uIGlzIGJlY29taW5nIGNvbW1vbiwgbGV0J3Mg
DQogICAgc2V0IG91dCB3aGF0IHRoZSBjdXJyZW50IGZhY3RzIGFyZS4gSSdtIGFsc28gZ29pbmcg
dG8gb3Bwb3NlIGRvY3VtZW50aW5nIA0KICAgIG5ldyBpZGVhcyBmb3IgaG93IHdlIGNhbiBnbyBm
b3J3YXJkIC0gYXMgU3BlbmNlciBpbnNpc3RlZCB3aGVuIHRoaXMgd2FzIA0KICAgIGNoYXJ0ZXJl
ZDogUHJvcG9zaW5nIG5ldyBtZXRob2RzIGJlbG9uZyBpbiBhIGRpZmZlcmVudCBkcmFmdCAtIHBh
cmFwaHJhc2VkLg0KICAgIA0KICAgIEdvcnJ5DQogICAgDQogICAgDQoNCg==


From nobody Mon Nov  4 10:24:29 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C492D120C3F; Mon,  4 Nov 2019 10:24:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXq53ctoKZK0; Mon,  4 Nov 2019 10:24:08 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0986D120CDA; Mon,  4 Nov 2019 10:24:07 -0800 (PST)
Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id A3F0E1B00223; Mon,  4 Nov 2019 18:24:01 +0000 (GMT)
Message-ID: <5DC06CC1.5070407@erg.abdn.ac.uk>
Date: Mon, 04 Nov 2019 18:24:01 +0000
From: Gorry Fairhurst 
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Tom Herbert 
CC: Mirja Kuehlewind ,  tsvwg IETF list , "saag@ietf.org" 
References:   <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com>   
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Nov 2019 18:24:20 -0000

On 04/11/2019, 16:16, Tom Herbert wrote:
> On Mon, Nov 4, 2019 at 6:59 AM Mirja Kuehlewind
>   wrote:
>> Hi Ekr,
>>
>>
>>
>> see inline, marked [MK]…
>>
>>
>>
>> Mirja
>>
>>
>>
>>
>>
>> From: Eric Rescorla
>> Date: Monday, 4. November 2019 at 14:57
>> To: Mirja Kuehlewind
>> Cc: Tom Herbert, tsvwg IETF list, "saag@ietf.org"
>> Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Nov 4, 2019 at 1:14 AM Mirja Kuehlewind  wrote:
>>
>> Hi Ekr, hi all,
>>
>> Just on this part:
>>      >  - The community of people designing new transport protocols has
>>      >    already weighed all the considerations here and come down pretty
>>      >    decisively on the side of "encrypt all the things". Given that
>>      >    both SCTP-over-DTLS and QUIC do this, it seems pretty unlikely
>>      >    we're going to design a new transport protocol that doesn't.
>> I disagree that this is the conclusion the community came to, otherwise we would not have put a signal for the network in the QUIC header. Also encryption has a cost and that's the discussion we continuously still having in QUIC and well as other working groups. So "encrypt all the things" is way too simplified and for sure not a consensus statement which this draft (draft-ietf-tsvwg-transport-encrypt) clearly shows.
>>
>>
>>
>> Well, we put a single, optional, bit in the header and everything else we could figure out how to encrypt encrypted. It's true that encryption has a cost to the design of the protocol and to the endpoint implementations and we've been trying to balance that cost against the value, but that's not because the group isn't trying to encrypt as much as possible.
>>
>>
>>
>> [MK]I don’t think we need to nit-pick here but I think "encrypt all the things" and “encrypt as much as possible” is not the same, especially as “possible” is something to argue about when it comes to the question of how much you are willing to pay. However, I don’t think we need to discuss this in details here, just wanted to say that I don’t think the situation is a simple as you have stated and I don’t think there is consensus for a simple "encrypt all the things".
>>
>>
>>
>> I certainly realize that there are people who are sad about this -- as you rightly point out reflected in this draft –
>>
>>
>>
>> [MK] I don’t think people are sad about increasing amount of encryption. But when we change things we also need to have a discussion of the implication of this change and cannot just close our eyes. As I said in some cases we might be happy about things that hopefully just go away, in other cases it may actually have more severe impact of the viability of the Internet as a interconnected network that is operated by different entities.
>>
>>
>>
>> but I believe they are in the rough, at least of the community of people actively designing and deploying new protocols.
>>
>>
>>
>> [MK] I don’t believe this. Otherwise I wondering why we had such a lengthy discussion for more than a year in the QUIC working group.
>>
>>
>>
>> Do you see any plausible situation in which a new transport protocol isn't largely encrypted?
>>
>>
>>
>> [MK] That’s not the intention here. But we also need to consider ways to interact with the network where this brings benefit to both the network and the performance of the end-to-end traffic. There are situation where this is the case. And I don’t think one makes sense without the other.
> Mirja,
>
> Yes, that is true. We need a way to allow hosts to signal the network.
> But doing this in the transport layer is architecturally incorrect,
> has led to protocol ossification, isn't robust like in the case of
> QUIC, presents a security and privacy risk, and doesn't scale beyond
> supporting one or maybe two transport protocols. Expliciting signaling
> contained in the network layer headers that is under control of the
> sending host is the correct alternative IMO.
>
> Tom
>
I don't agree that has been the case: The transport-layer specified by 
the IETF has always had elements visible to other layers. (My very first 
job - a little whiole ago - was to look for SYN flags to control access 
at a gateway, we've seen all sorts of signalling methods and protocol in 
transport over the years) - QUIC over UDP reveals the minimal. SRTP 
chose other approaches. TCP, SCTP and a myriad of other protocols have 
been made, and toolkits built around these to support a wide range of 
uses - some good, some bad, etc.

My real hope would be we publish this ID (with more work if needed) and 
move to look to the future!

I am pretty sure we can choose to do other things than transport 
headers. However, this isn't yet where we are. I do agree that explicit 
signaling contained in the network layer headers could seem to be an 
alternative in future - to me, this is also fine in a transport header 
(RTP seems to have done things in this space, etc), but we'd need to all 
agree on where to place the info - using lower-layer methods/tunnels is 
perhaps seems less attractive to me, but may be exactly what some 
operators wish. Is

With relation to the present draft - I understand it is out-of-scope to 
speculate/predict about how do this in future.

Gorry
>>
>>
>> -Ekr
>>
>>
>>
>>
>> Mirja
>>
>>
>>
>> On 04.11.19, 03:15, "tsvwg on behalf of Tom Herbert"  wrote:
>>
>>      On Sun, Nov 3, 2019 at 2:20 PM Eric Rescorla  wrote:
>>      >
>>      >  After reviewing this document, I share Christian Huitema's concern
>>      >  about the tone and perspective of this document, which, while saying
>>      >  that encryption is good, then proceeds to mostly lament how difficult
>>      >  it makes life for various entities other than the endpoints. It seems
>>      >  to me rather problematic to publish this document as an RFC for
>>      >  several reasons:
>>      >
>>      >  - Yes, it's true that the trend towards encrypting everything has
>>      >    and continues to make a number of entities sad, but that's a point
>>      >    which is already made in RFC 8404. How does all of the additional
>>      >    detail here help?
>>      >
>>      >  - The community of people designing new transport protocols has
>>      >    already weighed all the considerations here and come down pretty
>>      >    decisively on the side of "encrypt all the things". Given that
>>      >    both SCTP-over-DTLS and QUIC do this, it seems pretty unlikely
>>      >    we're going to design a new transport protocol that doesn't.
>>      >
>>      >  - Having an IETF Consensus RFC that is so heavily weighted on the side
>>      >    of "this is how encryption inconveniences us" and so light on "these
>>      >    are the attacks we are preventing" gives a misleading picture of the
>>      >    IETF community's view of the relative priority of these
>>      >    concerns. ISTM that RFC 8558 -- though perhaps imperfect -- far more
>>      >    closely reflects that consensus.
>>      >
>>      >  In short, I do not think this draft should be published as an RFC.
>>      >
>>      I believe the problem with this draft is that it identifies a
>>      perceived problem, but does little to offer a solution other than
>>      saying don't encrypt the transport layer header. As I've mentioned
>>      several times, putting transport layer information of interest into
>>      HBH extension headers is the architecturally correct solution for
>>      hosts to signal the network. This works with any transport layer
>>      protocol and exposure of transport layer information to the network is
>>      under explicit control of the end host. IMO, the draft does not
>>      adequately explore this alternative solution and too easily just
>>      brushes it off as being "undesirable" based on one set of snapshot
>>      measurements that is now almost four years old.
>>
>>      >  I have appended a number of detailed comments which IMO need to be
>>      >  addressed in any case, but even if they were resolved, that would not
>>      >  address my primary concern.
>>      >
>>      >
>>      >  COMMENTS
>>      >  S 2.1.
>>      >  >    2.1.  Use of Transport Header Information in the Network
>>      >  >
>>      >  >       In-network measurement of transport flow characteristics can be used
>>      >  >       to enhance performance, and control cost and service reliability.
>>      >  >       Some operators have deployed functionality in middleboxes to both
>>      >  >       support network operations and enhance performance.  This reliance on
>>      >
>>      >  This seems like a contested point. My understanding is that while
>>      >  these middleboxes are *intended* to enhance performance that there is
>>      >  doubt that they actually do.
>>      >
>>      >
>>      >  S 2.1.
>>      >  >       to enhance performance, and control cost and service reliability.
>>      >  >       Some operators have deployed functionality in middleboxes to both
>>      >  >       support network operations and enhance performance.  This reliance on
>>      >  >       the presence and semantics of specific header information leads to
>>      >  >       ossification, where an endpoint could be required to supply a
>>      >  >       specific header to receive the network service that it desires.  In
>>      >
>>      >  Well, not just the network service it desires but *any* service.
>>      >
>>      >
>>      >  S 2.1.
>>      >  >       specific header to receive the network service that it desires.  In
>>      >  >       some cases, this could be benign or advantageous to the protocol
>>      >  >       (e.g., recognising the start of a connection, or explicitly exposing
>>      >  >       protocol information can be expected to provide more consistent
>>      >  >       decisions by on-path devices than the use of diverse methods to infer
>>      >  >       semantics from other flow properties).  In other cases, the
>>      >
>>      >  Is there evidence of this?
>>      >
>>      >
>>      >  S 2.1.
>>      >  >
>>      >  >       As an example of ossification, consider the experience of developing
>>      >  >       Transport Layer Security (TLS) 1.3 [RFC8446].  This required a design
>>      >  >       that recognised that deployed middleboxes relied on the presence of
>>      >  >       certain header filed exposed in TLS 1.2, and failed if those headers
>>      >  >       were changed.  Other examples of the impact of ossification can be
>>      >
>>      >  I think you mean "fields" and it wasn't headers so much as handshake
>>      >  data.
>>      >
>>      >
>>      >  S 2.2.
>>      >  >       This supports use of this information by on-path devices, but at the
>>      >  >       same time can be expected to lead to ossification of the transport
>>      >  >       header, because network forwarding could evolve to depend on the
>>      >  >       presence and/or value of these fields.  To avoid unwanted inspection,
>>      >  >       a protocol could intentionally vary the format or value of exposed
>>      >  >       header fields [I-D.ietf-tls-grease].
>>      >
>>      >  It's not just a matter of unwanted inspection. There's a real question
>>      >  about whether we want these on-path devices to have this information
>>      >  at all, as it is potentially used for surveillance, traffic
>>      >  analysis, etc.
>>      >
>>      >
>>      >
>>      >  S 2..2.
>>      >  >
>>      >  >       While encryption can hide transport header information, it does not
>>      >  >       prevent ossification of the network service.  People seeking to
>>      >  >       understand network traffic could come to rely on pattern inferences
>>      >  >       and other heuristics as the basis for network decision and to derive
>>      >  >       measurement data.  This can create new dependencies on the transport
>>      >
>>      >  This also seems quite contested. Do you have any evidence of such a
>>      >  thing happening?
>>      >
>>      >
>>      >  S 2.3.
>>      >  >          anomalies, and failure pathologies at any point along the Internet
>>      >  >          path.  In many cases, it is important to relate observations to
>>      >  >          specific equipment/configurations or network segments.
>>      >  >
>>      >  >          Concealing transport header information makes performance/
>>      >  >          behaviour unavailable to passive observers along the path,
>>      >
>>      >  While also making traffic analysis more difficult.
>>      >
>>      >
>>      >  S 2.3.
>>      >  >          applications it is important to relate observations to specific
>>      >  >          equipment/configurations or particular network segments.
>>      >  >
>>      >  >          Concealing transport header information can make analysis harder
>>      >  >          or impossible.  This could impact the ability for an operator to
>>      >  >          anticipate the need for network upgrades and roll-out.  It can
>>      >
>>      >  Or to reduce the opportunities for traffic discrimination.
>>      >
>>      >
>>      >  S 2.3.
>>      >  >
>>      >  >       Different parties will view the relative importance of these issues
>>      >  >       differently.  For some, the benefits of encrypting some, or all, of
>>      >  >       the transport headers may outweigh the impact of doing so; others
>>      >  >       might make a different trade-off.  The purpose of highlighting the
>>      >  >       trade-offs is to make such analysis possible.
>>      >
>>      >  This whole section seems to really just ignore the fact that many of
>>      >  these practices are unwanted.
>>      >
>>      >
>>      >  S 3.1.
>>      >  >       Firewalls).  Common issues concerning IP address sharing are
>>      >  >       described in [RFC6269].
>>      >  >
>>      >  >    3.1.  Observing Transport Information in the Network
>>      >  >
>>      >  >       If in-network observation of transport protocol headers is needed,
>>      >
>>      >  Why is this needed? I know some people might want it.
>>      >
>>      >
>>      >  S 3.1.1.
>>      >  >    3.1.1.  Flow Identification Using Transport Layer Headers
>>      >  >
>>      >  >       Flow identification is a common function.  For example, performed by
>>      >  >       measurement activities, QoS classification, firewalls, Denial of
>>      >  >       Service, DOS, prevention.  This becomes more complex and less easily
>>      >  >       achieved when multiplexing is used at or above the transport layer.
>>      >
>>      >  Also traffic discrimination and blocking.
>>      >
>>      >
>>      >  S 3.1.1.
>>      >  >       use heuristics to infer that short UDP packets with regular spacing
>>      >  >       carry audio traffic.  Operational practices aimed at inferring
>>      >  >       transport parameters are out of scope for this document, and are only
>>      >  >       mentioned here to recognize that encryption does not prevent
>>      >  >       operators from attempting to apply practices that were used with
>>      >  >       unencrypted transport headers.
>>      >
>>      >  This has a really threatening tone. If you don't give us what we want,
>>      >  look what could happen.
>>      >
>>      >
>>      >  S 3.1.2.
>>      >  >
>>      >  >       This information can support network operations, inform capacity
>>      >  >       planning, and assist in determining the need for equipment and/or
>>      >  >       configuration changes by network operators.  It can also inform
>>      >  >       Internet engineering activities by informing the development of new
>>      >  >       protocols, methodologies, and procedures.
>>      >
>>      >  What is the point of this exhaustive list?
>>      >
>>      >
>>      >  S 3.1.3.
>>      >  >
>>      >  >          AQM and ECN offer a range of algorithms and configuration options.
>>      >  >          Tools therefore need to be available to network operators and
>>      >  >          researchers to understand the implication of configuration choices
>>      >  >          and transport behaviour as the use of ECN increases and new
>>      >  >          methods emerge [RFC7567].
>>      >
>>      >  QUIC sort of hides ECN feedback but not ECN marking.
>>      >
>>      >
>>      >  S 3.2.4.
>>      >  >
>>      >  >          A network operator needs tools to understand if datagram flows
>>      >  >          (e.g., using UDP) comply with congestion control expectations and
>>      >  >          therefore whether there is a need to deploy methods such as rate-
>>      >  >          limiters, transport circuit breakers, or other methods to enforce
>>      >  >          acceptable usage for the offered service.
>>      >
>>      >  Does it *need* it or does it just want it. Note that we have had DTLS-
>>      >  SCTP with WebRTC without this property for some time now. Can you provide
>>      >  some evidence that operators have been inconvenienced by not having it.
>>      >
>>      >
>>      >  S 3.3.
>>      >  >       operators bring together heterogeneous types of network equipment and
>>      >  >       seek to deploy opportunistic methods to access radio spectrum.
>>      >  >
>>      >  >       A flow that conceals its transport header information could imply
>>      >  >       "don't touch" to some operators.  This could limit a trouble-shooting
>>      >  >       response to "can't help, no trouble found".
>>      >
>>      >  We have quite a bit of QUIC traffic now. I'd be interested in hearing
>>      >  from the gQUIC team whether they have seen anything like this.
>>
>>      QUIC presents a problem in itself since the QUIC harders are inside
>>      the UDP payload so intermediate devices end up needing to parse the
>>      UDP transport payload. I believe the only way to identify a QUIC
>>      packet is by matching port numbers, but per RFC7605 interpretation of
>>      port numbers in the middle of the network is prone to
>>      misinterpretation. Eventually, something that looks like a QUIC packet
>>      based on port number will be misinterpreted. Looking at
>>      draft-ietf-quic-transport-23, I don't see any discussion about this or
>>      reference to RFC7605. Note this is true for any use case of UDP
>>      including transport layer or network layer encapsulation. Even if the
>>      argument is that the information is only being read and
>>      misinterpretation is innocuous, it still wouldn't be robust protocol.
>>      This can be contrasted to putting the information in HBH options which
>>      can be correctly and unambiguously identified anywhere in the network..
>>
>>      Tom
>>
>>      >
>>      >
>>      >  S 4.
>>      >  >
>>      >  >       There are several motivations for encryption:
>>      >  >
>>      >  >       o  One motive to use encryption is a response to perceptions that the
>>      >  >          network has become ossified by over-reliance on middleboxes that
>>      >  >          prevent new protocols and mechanisms from being deployed.  This
>>      >
>>      >  This isn't just a perception, it's a demonstrable reality.
>>      >
>>      >
>>      >  S 4.
>>      >  >
>>      >  >       o  One motive to use encryption is a response to perceptions that the
>>      >  >          network has become ossified by over-reliance on middleboxes that
>>      >  >          prevent new protocols and mechanisms from being deployed.  This
>>      >  >          has lead to a perception that there is too much "manipulation" of
>>      >  >          protocol headers within the network, and that designing to deploy
>>      >
>>      >  Not just manipulation, also inspection.
>>      >
>>      >
>>      >  S 4.
>>      >  >
>>      >  >          One example of encryption at the network layer is the use of IPsec
>>      >  >          Encapsulating Security Payload (ESP) [RFC4303] in tunnel mode.
>>      >  >          This encrypts and authenticates all transport headers, preventing
>>      >  >          visibility of the transport headers by in-network devices..  Some
>>      >  >          VPN methods also encrypt these headers.
>>      >
>>      >  This seems like a bad example as part of the point of a VPN is to
>>      >  conceal the headers form the network.
>>      >
>>      >
>>      >  S 6.1.
>>      >  >
>>      >  >    6.1.  Independent Measurement
>>      >  >
>>      >  >       Independent observation by multiple actors is important if the
>>      >  >       transport community is to maintain an accurate understanding of the
>>      >  >       network.  Encrypting transport header encryption changes the ability
>>      >
>>      >  This is ironic because QUIC is much better for endpoint measurement
>>      >  than TCP because the details are accessible at the application layer.
>>      >
>>      >
>>      >  S 8.
>>      >  >       example, an attacker could construct a DOS attack by sending packets
>>      >  >       with a sequence number that falls within the currently accepted range
>>      >  >       of sequence numbers at the receiving endpoint, this would then
>>      >  >       introduce additional work at the receiving endpoint, even though the
>>      >  >       data in the attacking packet may not finally be delivered by the
>>      >  >       transport layer.  This is sometimes known as a "shadowing attack".
>>      >
>>      >  This doesn't seem to be an issue with protocols that authenticate the SN.
>>      >
>>      >
>>      >  S 8.
>>      >  >
>>      >  >       An attack can, for example, disrupt receiver processing, trigger loss
>>      >  >       and retransmission, or make a receiving endpoint perform unproductive
>>      >  >       decryption of packets that cannot be successfully decrypted (forcing
>>      >  >       a receiver to commit decryption resources, or to update and then
>>      >  >       restore protocol state).
>>      >
>>      >  This is not a real issue for QUIC or similar protocols
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >
>>      >
>>
>>


From nobody Mon Nov  4 10:34:52 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C63120044 for ; Mon,  4 Nov 2019 10:34:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VHSOEmmbxXa for ; Mon,  4 Nov 2019 10:34:43 -0800 (PST)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 B7F891200FE for ; Mon,  4 Nov 2019 10:34:42 -0800 (PST)
Received: by mail-ed1-x535.google.com with SMTP id b72so13997908edf.1 for ; Mon, 04 Nov 2019 10:34:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xZOp6dkrLqeNUuUJxc1F5y/4QXrTINhSYiWOLsB/zf4=; b=yK5NrsmO/G4rKx0duMXevJbRR3oE0ba/YzAY+o/ieQ4klglq6FhjagS/YMHEFYKfCL tz2kfeCNwbgeRopUoF1FHwj4guBJ50F2B+eYsuAwCXGmI8KXs1YquM+AG3QIh3TpAFSZ Z7HXUNN1Gr6kW2+hp2Qo9u1z1eqArtA6o6rncjSDTLoFNZXCeWNmFsXWQrGvq8oNEx3t hMETopCtCUQu8EYDkZKC+g5hMgtf4tx5tJ5IFk4NPav3vEiOI7SPluGrbSnqiWvCoIXg q2/BUiWc63nyVKF+jH4v0PYWYnk3DKi/TDYbHQNPOTGhUCX/Iu8s18sSXd5R3J3RJldQ 0Svg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xZOp6dkrLqeNUuUJxc1F5y/4QXrTINhSYiWOLsB/zf4=; b=jvVNfROmrEZUC5kkiBELPADacDCjFzBYDo/qJIOeqofjfn3zTtWr0ZLFyi1sewrdnn Okw8A18hn641tMP27MYyv86fr82MDK1zXUFcgoUe8FU9+1OaRhhGPf5bMpqiB2B0FdR4 vuaLN1mgu1AoMUwIfYpdqNNlKPpweQi7j9LSH3Yz06bPSEr52NeKq/91BaGKYR+XT+8f vDJmR1WyQtBS6fFPJHujGeoYvqStAnenJmiISeiI4JGw7s3Oj7GvKtTxuOCG9UlJyf/O 7ygjKXMKlR8FnCotoOT/UG6/8v5aFKQHghnDW/FW8Ze/+Ww6cqMeQrcSoun+tIi4ltLW nDOQ==
X-Gm-Message-State: APjAAAVvfoJRLgVk+b1rrrzhDhOQi7zeMMipbCJg9tSS3fWUFc+yTKeG Qq1X+CZ8wzdJ0hh/r5MoF0/uXELOaSdPKv8G6I7FFQ==
X-Google-Smtp-Source: APXvYqwLbyGn6egaToyCvHv5AONDrEUcCbvu1aGGS+vBX6TsR8sCBz6KXN9I09pFehKpf0gV2s7RtGQwkhyAVGfcJ6c=
X-Received: by 2002:a50:cd14:: with SMTP id z20mr30401342edi.226.1572892480852;  Mon, 04 Nov 2019 10:34:40 -0800 (PST)
MIME-Version: 1.0
References:   <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com>   <2d3c909f-b21c-3916-1eb9-db6de5c661e3@huitema.net> <5DC063F2.8040502@erg.abdn.ac.uk>
In-Reply-To: <5DC063F2.8040502@erg.abdn.ac.uk>
From: Tom Herbert 
Date: Mon, 4 Nov 2019 10:34:29 -0800
Message-ID: 
To: Gorry Fairhurst 
Cc: Christian Huitema , "saag@ietf.org" ,  Mirja Kuehlewind ,  tsvwg IETF list 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Nov 2019 18:34:45 -0000

On Mon, Nov 4, 2019 at 9:47 AM Gorry Fairhurst  wrote=
:
>
> Just focussing on the end...
>
> On 04/11/2019, 16:29, Christian Huitema wrote:
> >>
> >> [MK] That=E2=80=99s not the intention here. But we also need to consid=
er ways
> >> to interact with the network where this brings benefit to both the
> >> network and the performance of the end-to-end traffic. There are
> >> situation where this is the case. And I don=E2=80=99t think one makes =
sense
> >> without the other.
> >>
> > You seem to be arguing for something like "performance enhancing
> > proxies". End-to-end encryption is indeed a way to opt out of such
> > proxying. Measurements so far indicate that opting out has very little
> > impact on actual performance, and that whatever impact there is could
> > be reduced by improvements in end-to-end algorithms. In fact, in many
> > cases, end to end performance is better without such proxies. But the
> > real reason for the opposition to the concept is ossification.
> > Enabling such proxies would quickly ossify the new transports, and a
> > such there is a strong consensus in the end-to-end transport designers
> > to use encryption and prevent interference by such devices.
> >
> On PEPs: The current case for many of the network segments I see is that
> QUIC is quite good, but it is considerably worse (currently) than a PEP
> using Split-TCP. That's not to say it can't improve - but that's not
> true yet. However: It's curious that people keep going back to PEPs,
> because network devices that change the transport header were
> specifically out-of-scope for this ID!
> >
> > This does not mean that network level deployment have no role in the
> > future. I could see for example tunnels deployed that use FEC or local
> > retransmission to mask the poor performance of a particular subnet. Or
> > I could see end-to-end devices opting into some kinds of application
> > level caching services in order to improve performance. But the draft
> > should be clear: transport protocols do not have to enable
> > interference with the transport bits.
> >
> There are also many operators - e.g., enterprise who rely on the methods
> currently mentioned in this draft. In this case, they also actually *do*
> care about the performance of the networks they operate. They also do
> care about the topics, which matters most depends on which organisation.
> >

Gorry,

"Many" is not "all". And even if all operators cared about this, they
will be all over the board about what information they need. If the
draft were to say that items X, Y, and Z are needed to be exposed in
the transport layer then that might be something we can work with and
this would be a different conversation. But, I don't believe you'll
ever get agreement on that. This is _exactly_ the same quandy we got
into we asked the operators what information they needed out of
transport payload when discussing encrypting transport payloads.

So basically what we're left with is plain text transport layer
information _may_ be important for some use case and _may_ have
legitimate reason to be read in the network, but we _can't_ describe
the exact circumstances when the information is required, we _don't_
know what a priori what transport protocols the network can even parse
so it can extract the information, the set of required information is
_undefined_, and we _don't_ have a good assessment of what the
security and privacy risks are. Given this, I still don't see much of
an argument that transport developers shouldn't encrypt as much a
possible-- to me it's clear the benefits outweigh the cost.

> > My take is that this draft should not be published as is. It should be
> > rewritten to actually reflect the consensus of the transport area,
> > which has to reflect in particular the work in the QUIC working group.
> >
> I suspect the information you wish to see about QUIC's design is
> actually available. I'm not sure documenting QUIC is helpful here, if
> the QUIC WG wants to so that, can't it be added to the manageability draf=
t?
>
> I dispute the claim that the entire transport area has the same
> priorities as that voiced at the QUIC WG. I think this discussion needs
> to look outside the QUIC working group and examine other transports and
> WGs. As far as I know the RTP people are still doing specs in the IETF,
> as are various other transport working groups. Also, this draft has been
> presented at OPsec, and has contributors from other areas outside
> transport...
>
> My assertion is that *current* practice is using transport header
> information & header authentication/encryption is becoming common, let's
> set out what the current facts are. I'm also going to oppose documenting
> new ideas for how we can go forward - as Spencer insisted when this was
> chartered: Proposing new methods belong in a different draft - paraphrase=
d.
>
Then I suggest to remove any discussion along those lines including
the references to alternatives include the discussion about and the
inherently negative comments about their potential use.

Tom

> Gorry
>


From nobody Mon Nov  4 11:10:53 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3C3120816; Mon,  4 Nov 2019 11:10:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHToFy_Ld7RB; Mon,  4 Nov 2019 11:10:15 -0800 (PST)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 B40E6120114; Mon,  4 Nov 2019 11:10:13 -0800 (PST)
Received: by mail-lf1-x12a.google.com with SMTP id f5so13120140lfp.1; Mon, 04 Nov 2019 11:10:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jMTJuPKj27tohTQCbiGlAKfO8CjPHeUoPwytq2veJMY=; b=YiQu5RxaPgJf0F6B4jW+b3r8/bZC3jANfGTm2uNL9fG9o8PRzSMiavKKicFG0g0Icy DTI3u88b6qk6mZ8rBtC5gMXyZHVO8FBFgOGPOziGCqeB9rvK6VLA/3+Zy1+h6+DS9dl1 B4I0PIsT6KOpCd1u4Q6wEUOqk5L209kQDYrL4bydJWiErJdVbhA5Y1wjn3quUQIQSUXz 87eZ9KqJy6c85kZKI6xHfcYhwODvxxbX6CAv6HOhS61Wx9OJlyNfFrqrF91GyNJODgkU LcFSDxP68HDgu+uwFaguM3ZRIdbwbtyCFiUbe1q0yZgc2vHb1zeNRNHpl8OV1VSEA9VK GtOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jMTJuPKj27tohTQCbiGlAKfO8CjPHeUoPwytq2veJMY=; b=nuRRG9w9AQHEQUXZxoPUvC9TOMGh1YF6c2Uf4g9+4AlZY3WTOd6uoWWWYjbRovfAwr wpVQnPiEn6xeqqVHqeb0ftNk90ogSZuUHn96c3uenJOESlQJJuaopNEwtTTS7G6xSOwB qW+18p2MjiB7VXSLQWiSSyk4CjyATtCw4CXCRjmyLQ37pto0hXiCLi0/ng2of0o9gRRx lyLib1QUabGboF5pZOL7jvkJrj+TKL2idD/P7wjpHwrlMoKgt3kIggxhUejzNpGZiBce KJMRROanTH9nB15kJ/o0CPeuajZVlQzSon7n3MJVEJKdFjqi5gbTH88AnaKpRDq6838k sCbA==
X-Gm-Message-State: APjAAAUgOUktaImFeLkp/HN+XEOFt7SGm0E3bExLiEYchldDHhQAG6To pYk2CIKuGYMt+sA6XLHZnw7qmoA0gPXqEBzSyIe99+Mk
X-Google-Smtp-Source: APXvYqya9WhivT2Duu8EakwXIY46124mInD7C7BZau7f47ET/FkEyIySec8IpGwxzq59WJ7dnAV9vpygk/w8NPR/7fE=
X-Received: by 2002:ac2:5210:: with SMTP id a16mr18133325lfl.156.1572894611632;  Mon, 04 Nov 2019 11:10:11 -0800 (PST)
MIME-Version: 1.0
References:   <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com>   <2d3c909f-b21c-3916-1eb9-db6de5c661e3@huitema.net> <5DC063F2.8040502@erg.abdn.ac.uk>
In-Reply-To: <5DC063F2.8040502@erg.abdn.ac.uk>
From: Bernard Aboba 
Date: Mon, 4 Nov 2019 11:10:00 -0800
Message-ID: 
To: gorry@erg.abdn.ac.uk
Cc: Christian Huitema , "saag@ietf.org" ,  Mirja Kuehlewind ,  tsvwg IETF list 
Content-Type: multipart/alternative; boundary="00000000000098774505968a10dc"
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 04 Nov 2019 19:10:25 -0000

--00000000000098774505968a10dc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Gorry said:

"I'm also going to oppose documenting new ideas for how we can go forward"

[BA] The problem is that the "current practices" described in the document
are more representative of where we were 10+ years ago, than where we are
today, with Infrastructure as a Service (IAAS), Platform As A Service,  and
Application as a Service (AAAS) providers all operating at enormous scale,
all measuring performance using "new ideas" (developed largely outside the
IETF).

"The RTP people are still in IETF"

[BA] The way realtime applications performance assessment has been
conducted has changed markedly over the last decade, particularly as the
world has moved toward the development and deployment of web-based
applications (e.g. Electron, React, PWAs, etc.) where performance data is
collected by the Application as a Service Provider rather than the network
operator (though the two may collaborate).



On Mon, Nov 4, 2019 at 9:46 AM Gorry Fairhurst  wrote=
:

> Just focussing on the end...
>
> On 04/11/2019, 16:29, Christian Huitema wrote:
> >>
> >> [MK] That=E2=80=99s not the intention here. But we also need to consid=
er ways
> >> to interact with the network where this brings benefit to both the
> >> network and the performance of the end-to-end traffic. There are
> >> situation where this is the case. And I don=E2=80=99t think one makes =
sense
> >> without the other.
> >>
> > You seem to be arguing for something like "performance enhancing
> > proxies". End-to-end encryption is indeed a way to opt out of such
> > proxying. Measurements so far indicate that opting out has very little
> > impact on actual performance, and that whatever impact there is could
> > be reduced by improvements in end-to-end algorithms. In fact, in many
> > cases, end to end performance is better without such proxies. But the
> > real reason for the opposition to the concept is ossification.
> > Enabling such proxies would quickly ossify the new transports, and a
> > such there is a strong consensus in the end-to-end transport designers
> > to use encryption and prevent interference by such devices.
> >
> On PEPs: The current case for many of the network segments I see is that
> QUIC is quite good, but it is considerably worse (currently) than a PEP
> using Split-TCP. That's not to say it can't improve - but that's not
> true yet. However: It's curious that people keep going back to PEPs,
> because network devices that change the transport header were
> specifically out-of-scope for this ID!
> >
> > This does not mean that network level deployment have no role in the
> > future. I could see for example tunnels deployed that use FEC or local
> > retransmission to mask the poor performance of a particular subnet. Or
> > I could see end-to-end devices opting into some kinds of application
> > level caching services in order to improve performance. But the draft
> > should be clear: transport protocols do not have to enable
> > interference with the transport bits.
> >
> There are also many operators - e.g., enterprise who rely on the methods
> currently mentioned in this draft. In this case, they also actually *do*
> care about the performance of the networks they operate. They also do
> care about the topics, which matters most depends on which organisation.
> >
> > My take is that this draft should not be published as is. It should be
> > rewritten to actually reflect the consensus of the transport area,
> > which has to reflect in particular the work in the QUIC working group.
> >
> I suspect the information you wish to see about QUIC's design is
> actually available. I'm not sure documenting QUIC is helpful here, if
> the QUIC WG wants to so that, can't it be added to the manageability draf=
t?
>
> I dispute the claim that the entire transport area has the same
> priorities as that voiced at the QUIC WG. I think this discussion needs
> to look outside the QUIC working group and examine other transports and
> WGs. As far as I know the RTP people are still doing specs in the IETF,
> as are various other transport working groups. Also, this draft has been
> presented at OPsec, and has contributors from other areas outside
> transport...
>
> My assertion is that *current* practice is using transport header
> information & header authentication/encryption is becoming common, let's
> set out what the current facts are. I'm also going to oppose documenting
> new ideas for how we can go forward - as Spencer insisted when this was
> chartered: Proposing new methods belong in a different draft - paraphrase=
d.
>
> Gorry
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>

--00000000000098774505968a10dc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Gorry said:=C2=A0

&quo=
t;I'm also going to oppose documenting new ideas for how we can go forw=
ard"

[BA] The problem is that the "curre=
nt practices" described in the document are more representative of whe=
re we were 10+ years ago, than where we are today, with Infrastructure as a=
 Service (IAAS), Platform As A Service,=C2=A0 and Application as a Service =
(AAAS) providers all operating at enormous scale, all measuring performance=
 using "new ideas" (developed largely outside the IETF).=C2=A0

"The RTP people are still in IETF"

[BA] The way realtime applications performance assessment=
 has been conducted has changed markedly over the last decade, particularly=
 as the world has moved toward the development and deployment of web-based =
applications (e.g. Electron, React, PWAs, etc.) where performance data is c=
ollected by the Application as a Service Provider rather than the network o=
perator (though the two may collaborate).=C2=A0


On Mon, Nov 4, 2019 at 9:46 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
Just focussing on the =
end...



On 04/11/2019, 16:29, Christian Huitema wrote:

>>

>> [MK] That=E2=80=99s not the intention here. But we also need to co=
nsider ways 

>> to interact with the network where this brings benefit to both the=
 

>> network and the performance of the end-to-end traffic. There are <=
br>
>> situation where this is the case. And I don=E2=80=99t think one ma=
kes sense 

>> without the other.

>>

> You seem to be arguing for something like "performance enhancing =


> proxies". End-to-end encryption is indeed a way to opt out of suc=
h 

> proxying. Measurements so far indicate that opting out has very little=
 

> impact on actual performance, and that whatever impact there is could =


> be reduced by improvements in end-to-end algorithms. In fact, in many =


> cases, end to end performance is better without such proxies. But the =


> real reason for the opposition to the concept is ossification. 

> Enabling such proxies would quickly ossify the new transports, and a <=
br>
> such there is a strong consensus in the end-to-end transport designers=
 

> to use encryption and prevent interference by such devices.

>

On PEPs: The current case for many of the network segments I see is that 
QUIC is quite good, but it is considerably worse (currently) than a PEP 
using Split-TCP. That's not to say it can't improve - but that'=
s not 

true yet. However: It's curious that people keep going back to PEPs, 
because network devices that change the transport header were 

specifically out-of-scope for this ID!

>

> This does not mean that network level deployment have no role in the <=
br>
> future. I could see for example tunnels deployed that use FEC or local=
 

> retransmission to mask the poor performance of a particular subnet. Or=
 

> I could see end-to-end devices opting into some kinds of application <=
br>
> level caching services in order to improve performance. But the draft =


> should be clear: transport protocols do not have to enable 

> interference with the transport bits.

>

There are also many operators - e.g., enterprise who rely on the methods 
currently mentioned in this draft. In this case, they also actually *do* 
care about the performance of the networks they operate. They also do 

care about the topics, which matters most depends on which organisation.
>

> My take is that this draft should not be published as is. It should be=
 

> rewritten to actually reflect the consensus of the transport area, 
> which has to reflect in particular the work in the QUIC working group.=


>

I suspect the information you wish to see about QUIC's design is 

actually available. I'm not sure documenting QUIC is helpful here, if <=
br>
the QUIC WG wants to so that, can't it be added to the manageability dr=
aft?



I dispute the claim that the entire transport area has the same 

priorities as that voiced at the QUIC WG. I think this discussion needs 
to look outside the QUIC working group and examine other transports and 
WGs. As far as I know the RTP people are still doing specs in the IETF, 
as are various other transport working groups. Also, this draft has been 
presented at OPsec, and has contributors from other areas outside 

transport...



My assertion is that *current* practice is using transport header 

information & header authentication/encryption is becoming common, let&=
#39;s 

set out what the current facts are. I'm also going to oppose documentin=
g 

new ideas for how we can go forward - as Spencer insisted when this was 
chartered: Proposing new methods belong in a different draft - paraphrased.=




Gorry



_______________________________________________

saag mailing list

saag@ietf.org

https://www.ietf.org/mailman/listinfo/saag




--00000000000098774505968a10dc--


From nobody Mon Nov  4 18:39:53 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A4C12006B; Mon,  4 Nov 2019 18:39:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4tiSY55vOb4; Mon,  4 Nov 2019 18:39:33 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 3788612004D; Mon,  4 Nov 2019 18:39:33 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 476Ylm6fF1z1x0PZ; Mon,  4 Nov 2019 18:39:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1572921572; bh=YB4ILCq09o4Qo0v6Y3Y8wTn9YfNPZjU1TjWHDryiBJk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=YbzHKabWBtBqyTwSHKdmO/hqvpbRZtYIRwMwDKT8kZTQCAQX6helyR4kBgE+ft9B5 PpTfcvuX7NcRnz/vIyGBdujxfSq93lobq/nODprgCF4E2PWgzy6crMHPZBSc6d76aA TVd2vyNrrMsBwUQB/fNDM0lpDkf0P05GG1Mn28JM=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 476Yll59n1z1x0PY; Mon,  4 Nov 2019 18:39:31 -0800 (PST)
To: Peter Gutmann 
Cc: "tsvwg@ietf.org" , "IETF IPPM WG (ippm@ietf.org)" , tsvwg-chairs , "opsawg@ietf.org" , "quic@ietf.org" , "saag@ietf.org" 
References:  <4460_1571933453_5DB1CD0D_4460_57_4_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931F030A0@OPEXCAUBM44.corporate.adroot.infra.ftgroup> <1572918247420.10381@cs.auckland.ac.nz> 
From: "Joel M. Halpern" 
Message-ID: 
Date: Mon, 4 Nov 2019 21:39:28 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [saag] [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Nov 2019 02:39:35 -0000

If the authors want to publish it as an RFC so as to comment on other 
RFCs, they could approach the Independent Stream Editor.  That sort of 
publication is one of the explicit purposes of the Independent Stream.

Yours,
Joel

On 11/4/2019 9:34 PM, Eric Rescorla wrote:
> 
> 
> On Mon, Nov 4, 2019 at 5:44 PM Peter Gutmann  > wrote:
> 
>     I actually think it's a pretty good summary, and delivers exactly what's
>     promised in the title.  OTOH I can also see that it's going to get
>     bikeshedded
>     to death, and will probably never be editable into a form where
>     people won't
>     complain about it no matter how many changes are made. 
>     Alternatively, it'll
>     end up watered down to a point where no-one can complain any more
>     but it won't
>     say anything terribly useful by then.
> 
>     Perhaps it could be published as is with a comment that it
>     represents the
>     opinions of the authors?  Although given that it's Informational and not
>     Standards-track or a BCP, that should be a given anyway.
> 
> 
> Actually, no. Most IETF documents, even informational ones, bear a 
> statement that they have IETF Consensus.
> 
> See: https://tools.ietf.org/html/rfc5741#section-3.2.1 
> 
> 
> -Ekr
> 
> 
>     Peter.
> 
> 
> 
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
> 


From nobody Mon Nov  4 18:48:33 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20A812004D; Mon,  4 Nov 2019 18:48:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.219
X-Spam-Level: 
X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juEw0VAwdU6y; Mon,  4 Nov 2019 18:48:15 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 84D0112006B; Mon,  4 Nov 2019 18:48:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=MI9VPaT4MWXUkvZ3EDHHG7c+aFzawpuCBeYNDUjeBPM=; b=S99XQZIcmaScOKcfk6ijkkKHA mEQumxwXHoDAp6H0f4AYW2QRSB5VfmOr8SciQDbMAFR1angMb16MPgJ84ncLJz9pgrwfzNVwJxv6U n6JASNY8QoXSJsQpz4pFnBST1pq1qYXcprmUUqjiNEuCBFg0Bx6UgIoB+abfuzCHYgvfcKZkwyGdx ZC8RjQgezhg2YcHFBuwuPTSIM3vXWxPogrOfCbGwDPnSh9yYRQl1iqGpXh5WsqnJ/gkD9Q9y0qyv8 e4zBd4oYdZBn1Xz8LpPSUp45vc2TYF8C4JMsIkHcr8sQZSR2x6Wzs3v8+xx0BW4o+LtfCMGkcsW49 ghxULFubg==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:59561 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iRot8-0021UN-2s; Mon, 04 Nov 2019 21:48:14 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch 
In-Reply-To: 
Date: Mon, 4 Nov 2019 18:48:09 -0800
Cc: Peter Gutmann , "tsvwg@ietf.org" , "IETF IPPM WG (ippm@ietf.org)" , tsvwg-chairs , "opsawg@ietf.org" , "quic@ietf.org" , "saag@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <7E9CB639-6CAD-4152-8927-86EC44DF5B9A@strayalpha.com>
References:  <4460_1571933453_5DB1CD0D_4460_57_4_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931F030A0@OPEXCAUBM44.corporate.adroot.infra.ftgroup> <1572918247420.10381@cs.auckland.ac.nz>  
To: "Joel M. Halpern" 
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
Archived-At: 
Subject: Re: [saag] [tsvwg] [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Nov 2019 02:48:17 -0000

> On Nov 4, 2019, at 6:39 PM, Joel M. Halpern  =
wrote:
>=20
> If the authors want to publish it as an RFC so as to comment on other =
RFCs, they could approach the Independent Stream Editor.  That sort of =
publication is one of the explicit purposes of the Independent Stream.

That only happens if the WG and IESG say this is out of scope for the =
IETF. I.e., the ISE isn=E2=80=99t an end-run.

IMO, given the fact that this is squarely within TSVWG and there=E2=80=99s=
 no consensus, the way forward is clear.

Not every ID turns into an RFC, nor should it.

Joe=


From nobody Mon Nov  4 20:06:39 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10BD12003F; Mon,  4 Nov 2019 20:06:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u73f2vGFNedt; Mon,  4 Nov 2019 20:06:16 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 108F312002F; Mon,  4 Nov 2019 20:06:16 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 476bgr00GWz1x0MG; Mon,  4 Nov 2019 20:06:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1572926776; bh=Lje+uXNlnXInbUhNE/+tD+X7+7fIBoMR2+dA7T66uSs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ZlGlZ52OVBWzkCIcwIXUT0dpICycA6pyVwaS049+drHqSnjzQOLZJKR5/XTZ0lh/A 4cVUVFUvlTCSUIphb0dk2GppRuYYhKnVrzg3L7Gzw8m9P44CUGnqalaVSKbLHUDCy5 shen4pDYRJFAeODXp9TEO+xPUsRxHx9ubDihmVFI=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 476bgp1XHfz1x0M3; Mon,  4 Nov 2019 20:06:14 -0800 (PST)
To: Joe Touch 
Cc: Peter Gutmann , "tsvwg@ietf.org" , "IETF IPPM WG (ippm@ietf.org)" , tsvwg-chairs , "opsawg@ietf.org" , "quic@ietf.org" , "saag@ietf.org" 
References:  <4460_1571933453_5DB1CD0D_4460_57_4_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931F030A0@OPEXCAUBM44.corporate.adroot.infra.ftgroup> <1572918247420.10381@cs.auckland.ac.nz>   <7E9CB639-6CAD-4152-8927-86EC44DF5B9A@strayalpha.com>
From: "Joel M. Halpern" 
Message-ID: 
Date: Mon, 4 Nov 2019 23:06:10 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <7E9CB639-6CAD-4152-8927-86EC44DF5B9A@strayalpha.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [saag] [tsvwg] [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Nov 2019 04:06:18 -0000

Actually Joe, the rules clearly allow the case wehre an Independent 
Stream I-D disagrees with the IETF rough consensus.  Many such have been 
published.  Some of them were held so that they were not published until 
the relevant IETF work was published.

To be explicit, while the IESG can request that the ISE not publish 
something, and can provide a note they wish to have included if it is 
published, they do not have the power to enforce a do-not-publish if the 
ISE disagrees.
And Joe, you have lived aspects of this more closely than I have, so I 
am sure you are aware of it.

Yours,
Joel

On 11/4/2019 9:48 PM, Joe Touch wrote:
> 
> 
>> On Nov 4, 2019, at 6:39 PM, Joel M. Halpern  wrote:
>>
>> If the authors want to publish it as an RFC so as to comment on other RFCs, they could approach the Independent Stream Editor.  That sort of publication is one of the explicit purposes of the Independent Stream.
> 
> That only happens if the WG and IESG say this is out of scope for the IETF. I.e., the ISE isn’t an end-run.
> 
> IMO, given the fact that this is squarely within TSVWG and there’s no consensus, the way forward is clear.
> 
> Not every ID turns into an RFC, nor should it.
> 
> Joe
> 


From nobody Mon Nov  4 20:36:30 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EABDC12003F for ; Mon,  4 Nov 2019 20:36:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2BEwDGw1Qlh for ; Mon,  4 Nov 2019 20:36:26 -0800 (PST)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 A842312000F for ; Mon,  4 Nov 2019 20:36:25 -0800 (PST)
Received: by mail-ed1-x533.google.com with SMTP id m13so8684155edv.9 for ; Mon, 04 Nov 2019 20:36:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=yKtl12sE2aQzP7ZrfUsuEs1Dj7jhl+9kOCh0RfL8H1w=; b=thMNi9H51B0XCuqNvUcOGzAZN+OYJgq7VE6VIAEWSunZwh0HwyM6auSc/r9+kNpBjt eJZjuWyl0aTa7syXwBjVjbKrCbDovJW6e9G64O/zyii5g9PAp/ovgMxoQczqj4TbNJp9 JpE0IrvTbk2CE3PLE5jfkaasGHF1L7h8/kXIE/XZNagWv5Ipe8Hx8VsSpkGAXz8sOcKL 4PAa56zDf7HYCV4or3QNXsWw0CXkLEoLHZ6yExe/SsUtzvZ86+oNDDNSyyWIRAG8mia1 NNaMQ9KPMly5DjiFa/5wSSXrm1IJ7YJxQ8FyvNnHwMWmytVRzQMHDndZKDjTq9z5pE5G IkBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=yKtl12sE2aQzP7ZrfUsuEs1Dj7jhl+9kOCh0RfL8H1w=; b=gyC8xm4hlBC9TMS2ZtceFbKY/VgTxts1iTKea3/ZfwVxvOEFZ89KmjdM/tRa5m3jk8 /HfqJ0ZWKxgBm7UhMJPzXAGxOHNG5uhhqB6WdIeOQS/QF+TFpcKEQSahLRES6wjRD3md GrFisNYwVkTJgq4BP0QAl4inZJYG9a0Z6Bemmq0yec0Le24QGET3Rb0Wu/xMkINeHy+c Rh/e2rd3Xbnkc9P6ZZWjw7/cLjHMf4MbsQVPzbYgn0QD6XrYSMtToOn88Wdkj5hbrPTG 6VhpEPUTshLxMp+u/Rn39g5GiDEFKNHEWYx/xL4DnzWPbaPl+bbTuYLMCS+yyHv4k1uy KEQw==
X-Gm-Message-State: APjAAAWC6idcfe0AkgNY2DFtjkURddNu+2KTGg6TVvrJu1ZAoo8SQeTr 6M4EamldOSPdAxoyleZtjhHtM4dEvCuFBcB5l7QXeA==
X-Google-Smtp-Source: APXvYqxMfIMpufXgVSsxg0qMwqyZ3Ywo9JoQtqF6BkRyRkac0RXWzEXR2BJvLXuopNEsPMRbG2gFuhJea5nE/40xMQM=
X-Received: by 2002:a17:906:c801:: with SMTP id cx1mr28032724ejb.266.1572928583969;  Mon, 04 Nov 2019 20:36:23 -0800 (PST)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: Tom Herbert 
Date: Mon, 4 Nov 2019 20:36:12 -0800
Message-ID: 
To: Martin Thomson 
Cc: saag@ietf.org, tsvwg 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Nov 2019 04:36:28 -0000

On Sun, Nov 3, 2019 at 7:18 PM Martin Thomson  wrote:
>
> On Mon, Nov 4, 2019, at 13:15, Tom Herbert wrote:
> > QUIC presents a problem in itself since the QUIC harders are inside
> > the UDP payload so intermediate devices end up needing to parse the
> > UDP transport payload. I believe the only way to identify a QUIC
> > packet is by matching port numbers, but per RFC7605 interpretation of
> > port numbers in the middle of the network is prone to
> > misinterpretation. Eventually, something that looks like a QUIC packet
> > based on port number will be misinterpreted. Looking at
> > draft-ietf-quic-transport-23, I don't see any discussion about this or
> > reference to RFC7605.
>
> Please refer to draft-ietf-quic-manageability for that discussion.
>
Martin,

I looked at that draft. While it does mention RFC7605, the explanation
for how non-QUIC packets that match port 443 aren't misinterpreted
isn't particularly satisfying. Other than assuming port number match
is sufficient, the recommended approach seems to be for middleboxes to
track flows by handshake. But, that then requires state to be
maintained and implies that packets for the flow must be consistently
be routed through the same device (a common problem for any stateful
device in the network). I don't think the QUIC spin bit serves as an
exemplar for reliably exposing transport layer information in a
transport protocol that is otherwise encrypted.

Tom

> Note that while there has been extensive discussion on what QUIC should e=
xpose in terms of loss and latency, I recall relatively little discussion a=
bout distinguishing QUIC from other protocols outside of the narrow context=
 of ensuring that QUIC can be effectively multiplexed with certain other pr=
otocols.
>
> My sense is that some people are assuming that they can use port numbers,=
 which are fraught for the reasons you identify.  Others might choose to in=
fer the use of QUIC using the "QUIC bit": the 0x40 bit in QUIC version 1 is=
 fixed.
>
> Personally, I think that endpoints are not obligated to signal which prot=
ocol they are using to the network.  Maybe the QUIC bit is that signal and =
I'm just in denial.  I guess we'll see whether I can send packets with a 0 =
value for that bit...
>
> > This can be contrasted to putting the information in HBH options which
> > can be correctly and unambiguously identified anywhere in the network.
>
> I happen to agree, though I don't think that this is as simple as you mig=
ht be implying.  https://tools.ietf.org/html/rfc8558 makes a similar assert=
ion, but identifies some of the underlying complexities.
>


From nobody Mon Nov  4 21:09:46 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1098912002F; Mon,  4 Nov 2019 21:09:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=L8gSwNln; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=xm35xXjh
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 84d2uvG4LJgO; Mon,  4 Nov 2019 21:09:38 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90EA4120020; Mon,  4 Nov 2019 21:09:38 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3496821FE5; Tue,  5 Nov 2019 00:09:37 -0500 (EST)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 05 Nov 2019 00:09:37 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm3; bh=WF6DxDbkIL0Y8Kl8ix6kG7pvYjQv WTzRtJIvU2C3WOY=; b=L8gSwNlnAYxruPbKrDltlZ6L9BJSertrmtrB8R/uWA1Q fiMOZVYkoJdZRI7HP13gSmomBBq2Ty52ZC+7RscL7iZYHk0TyqZzBhg5bKSonA9I 0eQZfDI0CDnNQtNc9rqVi6uv0OLTNLN5wutIYEz8zlzih9JM7eK3QhPPjtvNhoN4 c8NpZ62Slx3c1XqWX7gyaVXKM+K9VEG1SyjKka+E19ZzN7OBFO5EHJ6T0fziQ6i8 7ryyOSBxlkdcUbMKcH5cTVfCRiNoHNeuQzkQ6BR0MUx3lthRFiYDYmnU3iQlw7S7 vx9NVgOkOuDbZGvL9YFw2PI/hRuJwUV25H0CjfUejg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=WF6DxD bkIL0Y8Kl8ix6kG7pvYjQvWTzRtJIvU2C3WOY=; b=xm35xXjhaIwQ9p5pZm0WqB uqF6iwInZrxY9NznecZGMRuw6jCjIJSyOGLPUI5m2E/Rw/JAdublt47ryeoxs3xQ pZTzJ644fS2ywH10jVRzxcs1vUBOBq+iywUGvStPqMPK10hFLk493lRLb4wauz5R AA7Ae9YXcLjVlPs/zpoXZeQf72NAjQ8ao6DYTaw6SlKEAf9NgYtdQpNqewUNl0nO BI+d5Hi8qGGWvr5VS/wY1FYjHvuuWBTomEkZw8U/0DeR/YRVyHuGv8Ez7reAcwKM ecRud7pXxelHQdUiwG6MtPoJm3mX92wBxwg2rLBEv8TytSA6BFVLshDx6QK+U5Fg ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddugedgjeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehloh ifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8B584E00A3; Tue,  5 Nov 2019 00:09:36 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1
Mime-Version: 1.0
Message-Id: <8b26fae5-0db0-48b0-859e-1a5faf6310ea@www.fastmail.com>
In-Reply-To: 
References:    
Date: Tue, 05 Nov 2019 16:09:16 +1100
From: "Martin Thomson" 
To: "Tom Herbert" 
Cc: saag@ietf.org, tsvwg 
Content-Type: text/plain
Archived-At: 
Subject: Re: [saag]  =?utf-8?q?=5Btsvwg=5D__Comments_on_draft-ietf-tsvwg-trans?= =?utf-8?q?port-encrypt-08=2Etxt?=
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Nov 2019 05:09:40 -0000

On Tue, Nov 5, 2019, at 15:36, Tom Herbert wrote:
> > Please refer to draft-ietf-quic-manageability for that discussion.
>
> I looked at that draft. While it does mention RFC7605, the explanation
> for how non-QUIC packets that match port 443 aren't misinterpreted
> isn't particularly satisfying. Other than assuming port number match
> is sufficient, the recommended approach seems to be for middleboxes to
> track flows by handshake. But, that then requires state to be
> maintained and implies that packets for the flow must be consistently
> be routed through the same device (a common problem for any stateful
> device in the network). I don't think the QUIC spin bit serves as an
> exemplar for reliably exposing transport layer information in a
> transport protocol that is otherwise encrypted.

Yeah, not saying that this is ideal, but it's what we're handing out.  Well, some of us might, I don't think that our implementation has any intention of leaking anything at this stage.

Note also that QUIC allows for migration where the new path will not see the handshake.

I don't think that there is a lack of interest in this subject, just that there is no real drive toward finding e2m and m2e signaling that will be deployed.  Personally, my interests are aligned more with removing signals, not adding them.


From nobody Tue Nov  5 02:27:07 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CB01208B1; Tue,  5 Nov 2019 02:26:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96pqZCMY__5d; Tue,  5 Nov 2019 02:26:51 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 12B661208AA; Tue,  5 Nov 2019 02:26:50 -0800 (PST)
Received: from gorry-mac.erg.abdn.ac.uk (unknown [IPv6:2001:630:42:110:e55f:a14f:6fbb:b4cc]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id BF6AB1B001D2; Tue,  5 Nov 2019 10:26:39 +0000 (GMT)
To: "Joel M. Halpern" , Peter Gutmann 
Cc: "tsvwg@ietf.org" , "IETF IPPM WG (ippm@ietf.org)" , tsvwg-chairs , "opsawg@ietf.org" , "quic@ietf.org" , "saag@ietf.org" 
References:  <4460_1571933453_5DB1CD0D_4460_57_4_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931F030A0@OPEXCAUBM44.corporate.adroot.infra.ftgroup> <1572918247420.10381@cs.auckland.ac.nz>  
From: Gorry Fairhurst 
Message-ID: <5df30dd2-6841-7140-43bf-8c1b9603653f@erg.abdn.ac.uk>
Date: Tue, 5 Nov 2019 10:26:39 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [saag] [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Nov 2019 10:26:53 -0000

Thanks for the various comments on process.

I expect both editors and the Chairs to work with our AD to confirm the 
intended scope, and then to decide on the next steps. This author wants 
to clarify how IETF transport protocols have been designed and have 
been/are being used.

Gorry (as one of the editors of this document).


On 05/11/2019 02:39, Joel M. Halpern wrote:
> If the authors want to publish it as an RFC so as to comment on other 
> RFCs, they could approach the Independent Stream Editor.  That sort of 
> publication is one of the explicit purposes of the Independent Stream.
>
> Yours,
> Joel
>
> On 11/4/2019 9:34 PM, Eric Rescorla wrote:
>>
>>
>> On Mon, Nov 4, 2019 at 5:44 PM Peter Gutmann 
>> > wrote:
>>
>>     I actually think it's a pretty good summary, and delivers exactly 
>> what's
>>     promised in the title.  OTOH I can also see that it's going to get
>>     bikeshedded
>>     to death, and will probably never be editable into a form where
>>     people won't
>>     complain about it no matter how many changes are made. 
>> Alternatively, it'll
>>     end up watered down to a point where no-one can complain any more
>>     but it won't
>>     say anything terribly useful by then.
>>
>>     Perhaps it could be published as is with a comment that it
>>     represents the
>>     opinions of the authors?  Although given that it's Informational 
>> and not
>>     Standards-track or a BCP, that should be a given anyway.
>>
>>
>> Actually, no. Most IETF documents, even informational ones, bear a 
>> statement that they have IETF Consensus.
>>
>> See: https://tools.ietf.org/html/rfc5741#section-3.2.1 
>> 
>>
>> -Ekr
>>
>>
>>     Peter.
>>
>>
>>
>>
>> _______________________________________________
>> OPSAWG mailing list
>> OPSAWG@ietf.org
>> https://www.ietf.org/mailman/listinfo/opsawg
>>


From nobody Tue Nov  5 07:11:05 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16EF120089 for ; Tue,  5 Nov 2019 07:10:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDxrVOdLpEQU for ; Tue,  5 Nov 2019 07:10:56 -0800 (PST)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 9D2331200B4 for ; Tue,  5 Nov 2019 07:10:56 -0800 (PST)
Received: by mail-ed1-x52a.google.com with SMTP id f11so5894372edt.10 for ; Tue, 05 Nov 2019 07:10:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6IW5A2K/yhQoPOoskXuYiDoDQnNs4zl2Rju0/lKFA48=; b=wOxbq7GM+Ek6+LZ4+k+i97FTVohXs1bSv0NOc03ruct/ck055m/BszGCedQjwEvkPi Z6iPVxKFohtmj8YN0gjkzTC+BsOWkIK8yzQbqIjtW7t1W77xyP+kSuAUq8MXU1sG4xCl TqG8Ru/vAZMeFHhT5GygL7uir+nYtNmr+XR1KEyfB0DveoMtqncHAsnlBakpWAxCTgf4 //4VVl/l4Rvdy4XRDdctUJsxRMEjj4Gk12gTn8DDr8dyMsQC9WWLCMDLeghpxUEXzP9x cA39dlypH+/sn0u5LJEew/u+fVmjQvLr4eTfS7pJ2040X7FIV8hhDkGYvfERUO85yxz5 2Ikg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6IW5A2K/yhQoPOoskXuYiDoDQnNs4zl2Rju0/lKFA48=; b=kOufn4jIk2i4AJYurJREYdV0KS3E87cGKpuR7QtdXRqOF5w62gMlKTifrs4EcpPUGt qCwUKaP1I0ypsejB7q/vXO0zGwaJ9j6YD0g1y7VHEr0yX0c1+LtAbOpoA2HbHQLKRalM +Tm4PcQBnnZQ6YFjKjEWCnVaMFMqnKnhugFSAHAamWvVFiE1H867o6MlXsWowrH/syay vIuOuBnQ2tE8cJZkFI/eZ0AdojFYsJNauQ8+mxc9aZSlI+LEF6k/ZWpdiXCXw+nafhq4 pO7J7MmwLQ05B7bLPfQ6QIZf8igPex19Kustd9psncYVTeXnsvEQ3J2c30nPm3ETas3l hwjA==
X-Gm-Message-State: APjAAAVDO/We6CSq5gqsw+oSVebEl2c2wvyI2V1xYa7eFPOu/2aA1dPz xK4bj3T3Sl750eFmHEdmUo3Xf35ftP6mkvIJamF48UFc
X-Google-Smtp-Source: APXvYqznyR9D0JkZUWee/IjIfrpEczSCks1rZC/Hu25YiSoaNHi7u7j127WzhxD68CZEX777oWUA6K7LwIuld48+jIg=
X-Received: by 2002:a50:ec83:: with SMTP id e3mr13746044edr.292.1572966655013;  Tue, 05 Nov 2019 07:10:55 -0800 (PST)
MIME-Version: 1.0
References:     <8b26fae5-0db0-48b0-859e-1a5faf6310ea@www.fastmail.com>
In-Reply-To: <8b26fae5-0db0-48b0-859e-1a5faf6310ea@www.fastmail.com>
From: Tom Herbert 
Date: Tue, 5 Nov 2019 07:10:44 -0800
Message-ID: 
To: Martin Thomson 
Cc: saag@ietf.org, tsvwg 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Nov 2019 15:10:59 -0000

On Mon, Nov 4, 2019 at 9:09 PM Martin Thomson  wrote:
>
> On Tue, Nov 5, 2019, at 15:36, Tom Herbert wrote:
> > > Please refer to draft-ietf-quic-manageability for that discussion.
> >
> > I looked at that draft. While it does mention RFC7605, the explanation
> > for how non-QUIC packets that match port 443 aren't misinterpreted
> > isn't particularly satisfying. Other than assuming port number match
> > is sufficient, the recommended approach seems to be for middleboxes to
> > track flows by handshake. But, that then requires state to be
> > maintained and implies that packets for the flow must be consistently
> > be routed through the same device (a common problem for any stateful
> > device in the network). I don't think the QUIC spin bit serves as an
> > exemplar for reliably exposing transport layer information in a
> > transport protocol that is otherwise encrypted.
>
> Yeah, not saying that this is ideal, but it's what we're handing out.  Well, some of us might, I don't think that our implementation has any intention of leaking anything at this stage.
>
> Note also that QUIC allows for migration where the new path will not see the handshake.
>
> I don't think that there is a lack of interest in this subject, just that there is no real drive toward finding e2m and m2e signaling that will be deployed.  Personally, my interests are aligned more with removing signals, not adding them.

That is happening in IPPM WG and others. Options are being defined in
extension headers for the purposes of host to network signaling.


From nobody Tue Nov  5 11:59:51 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CD91200A4 for ; Tue,  5 Nov 2019 11:59:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjTYIgUJk9pA for ; Tue,  5 Nov 2019 11:59:41 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6115E12011E for ; Tue,  5 Nov 2019 11:59:34 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id k15so11201503lja.3 for ; Tue, 05 Nov 2019 11:59:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wfWof+oWvw61V1BM2zohLZy5WA3LAAsoi066yQ6HWEM=; b=ACeCHrYMxMcE1YNFIP3fLNgca3JMnRrbjqYojJL/pOYNSlZTlaV5/y8NEfzVSWZz5G 4PoNlS+8zDx4j1OIffgEAmuxQUj6TIa4K1qBfsZ+OxtWe3ZPYtfeUol+rk0jicuPXSjh OwZlldYeEjsPgmsMCaBkatxWHgXod71XLe+43VjmLdKiuKvYApThTKDYJ2jqqjmpmWor h1xSYlf8p48gigubOSbvPuhREZrBj3O/hiBcMqq32dXPg/Di/8xliO8zo6XHMYU0jkfu ssBwTE1iGu/GlMjfh4c10qtKcEGHsa+3tRxnHYjMdWCCBhFNOgq+EGdnMev2ZOvp/IdR qYfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wfWof+oWvw61V1BM2zohLZy5WA3LAAsoi066yQ6HWEM=; b=Dw1nJ1mWzTEugqtZoNYiJQU1gIp8LfWBK/ZpOIM2B+DwbdB6jus6YJsICtibHyZpsd Zqri1zIYPo4Z2e1PbHZgEPKEcd7dv0hGDbYDf5gogDRrF4rOaBXJtenzVGTfZcyF+wk8 2jOQlzDd9fjp7qTORmU7Oxh+YOt4wIzBy1ogWwG/wxwKHmNHF0c2hVlxR/GxIhfTPTOd UrfYvMqLSLcfOZACWY0zrCO2zQmZGnxQfZ4Jq8+ZDk4koJUfTh5/1o+g3GoGWINq2dtj pTY2G2DrDRqopzxIHhjmefT554E3iFb8WOUimpAFgzGhvIizewE2QP+E/TgT8W6muyc7 Q9Iw==
X-Gm-Message-State: APjAAAUbpzAesHY6HSWLcAxXpTfBFjDJvkxwhYd/SAHmL3QfIJ5hgPQN 65wo4VYwCyTLaLvrfu33iPez2V4W7HVO2rwV/3o2Tw==
X-Google-Smtp-Source: APXvYqyfBNJoLK2T9EzvhdNYSfwMR6dauZmsMpsX0jEv3X0WpBXhXZCkYnSdQ+qvO38c36PYtaKR0DPqXhXzw5RZ6IM=
X-Received: by 2002:a2e:3e18:: with SMTP id l24mr24737579lja.48.1572983972383;  Tue, 05 Nov 2019 11:59:32 -0800 (PST)
MIME-Version: 1.0
References:   <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com>   <2d3c909f-b21c-3916-1eb9-db6de5c661e3@huitema.net> <5DC063F2.8040502@erg.abdn.ac.uk> 
In-Reply-To: 
From: Eric Rescorla 
Date: Tue, 5 Nov 2019 11:58:55 -0800
Message-ID: 
To: Mirja Kuehlewind 
Cc: "gorry@erg.abdn.ac.uk" , Christian Huitema ,  tsvwg IETF list , "saag@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000e964a505969ede02"
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Nov 2019 19:59:44 -0000

--000000000000e964a505969ede02
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 4, 2019 at 10:02 AM Mirja Kuehlewind <
mirja.kuehlewind@ericsson.com> wrote:

> Hi Christian,
>
> please see two comments below (marked with [MK]).
>
> Mirja
>
> =EF=BB=BFOn 04.11.19, 18:46, "Gorry Fairhurst"  wro=
te:
>
>     Just focussing on the end...
>
>     On 04/11/2019, 16:29, Christian Huitema wrote:
>     >>
>     >> [MK] That=E2=80=99s not the intention here. But we also need to co=
nsider
> ways
>     >> to interact with the network where this brings benefit to both the
>     >> network and the performance of the end-to-end traffic. There are
>     >> situation where this is the case. And I don=E2=80=99t think one ma=
kes sense
>     >> without the other.
>     >>
>     > You seem to be arguing for something like "performance enhancing
>     > proxies". End-to-end encryption is indeed a way to opt out of such
>     > proxying. Measurements so far indicate that opting out has very
> little
>     > impact on actual performance, and that whatever impact there is
> could
>     > be reduced by improvements in end-to-end algorithms. In fact, in
> many
>     > cases, end to end performance is better without such proxies. But
> the
>     > real reason for the opposition to the concept is ossification.
>     > Enabling such proxies would quickly ossify the new transports, and =
a
>     > such there is a strong consensus in the end-to-end transport
> designers
>     > to use encryption and prevent interference by such devices.
>     >
>     On PEPs: The current case for many of the network segments I see is
> that
>     QUIC is quite good, but it is considerably worse (currently) than a
> PEP
>     using Split-TCP. That's not to say it can't improve - but that's not
>     true yet. However: It's curious that people keep going back to PEPs,
>     because network devices that change the transport header were
>     specifically out-of-scope for this ID!
>     >
>     > This does not mean that network level deployment have no role in th=
e
>     > future. I could see for example tunnels deployed that use FEC or
> local
>     > retransmission to mask the poor performance of a particular subnet.
> Or
>     > I could see end-to-end devices opting into some kinds of applicatio=
n
>     > level caching services in order to improve performance. But the
> draft
>     > should be clear: transport protocols do not have to enable
>     > interference with the transport bits.
>
> [MK] This is not what the draft is asking for.
>
>     >
>     There are also many operators - e.g., enterprise who rely on the
> methods
>     currently mentioned in this draft. In this case, they also actually
> *do*
>     care about the performance of the networks they operate. They also do
>     care about the topics, which matters most depends on which
> organisation.
>     >
>     > My take is that this draft should not be published as is. It should
> be
>     > rewritten to actually reflect the consensus of the transport area,
>     > which has to reflect in particular the work in the QUIC working
> group.
>
> [MK] The purpose of this draft is exactly to find and document consensus
> in the transport area and in the IETF. I don't think any individual at th=
is
> points knows what the consensus actually is.


Well, in that case this document shouldn't be being advanced.


This document has support in tsvwg (otherwise it would not have been
> adopted as wg document) and I also don't think there is anything in the
> draft that contradicts any work in the QUIC group.
>

Well, I think what you're hearing is that people think that it is badly
aligned with the consensus of other parts of the IETF.

-Ekr

--000000000000e964a505969ede02
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Nov 4, 2019 at 10:02 AM Mirja=
 Kuehlewind <mirja.kueh=
lewind@ericsson.com> wrote:
Hi Christian,



please see two comments below (marked with [MK]).



Mirja



=EF=BB=BFOn 04.11.19, 18:46, "Gorry Fairhurst" <gorry@erg.abdn.ac.uk> wr=
ote:



=C2=A0 =C2=A0 Just focussing on the end...



=C2=A0 =C2=A0 On 04/11/2019, 16:29, Christian Huitema wrote:

=C2=A0 =C2=A0 >>

=C2=A0 =C2=A0 >> [MK] That=E2=80=99s not the intention here. But we a=
lso need to consider ways 

=C2=A0 =C2=A0 >> to interact with the network where this brings benef=
it to both the 

=C2=A0 =C2=A0 >> network and the performance of the end-to-end traffi=
c. There are 

=C2=A0 =C2=A0 >> situation where this is the case. And I don=E2=80=99=
t think one makes sense 

=C2=A0 =C2=A0 >> without the other.

=C2=A0 =C2=A0 >>

=C2=A0 =C2=A0 > You seem to be arguing for something like "performa=
nce enhancing 

=C2=A0 =C2=A0 > proxies". End-to-end encryption is indeed a way to =
opt out of such 

=C2=A0 =C2=A0 > proxying. Measurements so far indicate that opting out h=
as very little 

=C2=A0 =C2=A0 > impact on actual performance, and that whatever impact t=
here is could 

=C2=A0 =C2=A0 > be reduced by improvements in end-to-end algorithms. In =
fact, in many 

=C2=A0 =C2=A0 > cases, end to end performance is better without such pro=
xies. But the 

=C2=A0 =C2=A0 > real reason for the opposition to the concept is ossific=
ation. 

=C2=A0 =C2=A0 > Enabling such proxies would quickly ossify the new trans=
ports, and a 

=C2=A0 =C2=A0 > such there is a strong consensus in the end-to-end trans=
port designers 

=C2=A0 =C2=A0 > to use encryption and prevent interference by such devic=
es.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 On PEPs: The current case for many of the network segments I =
see is that 

=C2=A0 =C2=A0 QUIC is quite good, but it is considerably worse (currently) =
than a PEP 

=C2=A0 =C2=A0 using Split-TCP. That's not to say it can't improve -=
 but that's not 

=C2=A0 =C2=A0 true yet. However: It's curious that people keep going ba=
ck to PEPs, 

=C2=A0 =C2=A0 because network devices that change the transport header were=
 

=C2=A0 =C2=A0 specifically out-of-scope for this ID!

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > This does not mean that network level deployment have no=
 role in the 

=C2=A0 =C2=A0 > future. I could see for example tunnels deployed that us=
e FEC or local 

=C2=A0 =C2=A0 > retransmission to mask the poor performance of a particu=
lar subnet. Or 

=C2=A0 =C2=A0 > I could see end-to-end devices opting into some kinds of=
 application 

=C2=A0 =C2=A0 > level caching services in order to improve performance. =
But the draft 

=C2=A0 =C2=A0 > should be clear: transport protocols do not have to enab=
le 

=C2=A0 =C2=A0 > interference with the transport bits.



[MK] This is not what the draft is asking for. 



=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 There are also many operators - e.g., enterprise who rely on =
the methods 

=C2=A0 =C2=A0 currently mentioned in this draft. In this case, they also ac=
tually *do* 

=C2=A0 =C2=A0 care about the performance of the networks they operate. They=
 also do 

=C2=A0 =C2=A0 care about the topics, which matters most depends on which or=
ganisation.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > My take is that this draft should not be published as is=
. It should be 

=C2=A0 =C2=A0 > rewritten to actually reflect the consensus of the trans=
port area, 

=C2=A0 =C2=A0 > which has to reflect in particular the work in the QUIC =
working group.



[MK] The purpose of this draft is exactly to find and document consensus in=
 the transport area and in the IETF. I don't think any individual at th=
is points knows what the consensus actually is. 

Well, in that case this document shouldn't be being advanced.

 
This document has support in tsvwg (otherwise it would not have bee=
n adopted as wg document) and I also don't think there is anything in t=
he draft that contradicts any work in the QUIC group.
=

Well, I think what you're hearing is that people think t=
hat it is badly aligned with the consensus of other parts of the IETF.

-Ekr






--000000000000e964a505969ede02--


From nobody Tue Nov  5 12:19:35 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64DD120B7F; Tue,  5 Nov 2019 12:19:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsUljQT3XZ07; Tue,  5 Nov 2019 12:19:30 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 64645120B73; Tue,  5 Nov 2019 12:19:30 -0800 (PST)
Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 933721B0023F; Tue,  5 Nov 2019 20:19:22 +0000 (GMT)
Message-ID: <5DC1D94A.9040602@erg.abdn.ac.uk>
Date: Tue, 05 Nov 2019 20:19:22 +0000
From: Gorry Fairhurst 
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Eric Rescorla 
CC: Mirja Kuehlewind ,  Christian Huitema , tsvwg IETF list , "saag@ietf.org" 
References:   <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com>   <2d3c909f-b21c-3916-1eb9-db6de5c661e3@huitema.net> <5DC063F2.8040502@erg.abdn.ac.uk>  
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Nov 2019 20:19:33 -0000

On 05/11/2019, 19:58, Eric Rescorla wrote:
>
>
> On Mon, Nov 4, 2019 at 10:02 AM Mirja Kuehlewind 
> > 
> wrote:
>
>     Hi Christian,
>
>     please see two comments below (marked with [MK]).
>
>     Mirja
>
>     On 04.11.19, 18:46, "Gorry Fairhurst"      > wrote:
>
>         Just focussing on the end...
>
>         On 04/11/2019, 16:29, Christian Huitema wrote:
>     >>
>     >> [MK] That’s not the intention here. But we also need to
>     consider ways
>     >> to interact with the network where this brings benefit to both the
>     >> network and the performance of the end-to-end traffic. There are
>     >> situation where this is the case. And I don’t think one makes
>     sense
>     >> without the other.
>     >>
>     > You seem to be arguing for something like "performance enhancing
>     > proxies". End-to-end encryption is indeed a way to opt out of such
>     > proxying. Measurements so far indicate that opting out has very
>     little
>     > impact on actual performance, and that whatever impact there is
>     could
>     > be reduced by improvements in end-to-end algorithms. In fact, in
>     many
>     > cases, end to end performance is better without such proxies.
>     But the
>     > real reason for the opposition to the concept is ossification.
>     > Enabling such proxies would quickly ossify the new transports,
>     and a
>     > such there is a strong consensus in the end-to-end transport
>     designers
>     > to use encryption and prevent interference by such devices.
>     >
>         On PEPs: The current case for many of the network segments I
>     see is that
>         QUIC is quite good, but it is considerably worse (currently)
>     than a PEP
>         using Split-TCP. That's not to say it can't improve - but
>     that's not
>         true yet. However: It's curious that people keep going back to
>     PEPs,
>         because network devices that change the transport header were
>         specifically out-of-scope for this ID!
>     >
>     > This does not mean that network level deployment have no role in
>     the
>     > future. I could see for example tunnels deployed that use FEC or
>     local
>     > retransmission to mask the poor performance of a particular
>     subnet. Or
>     > I could see end-to-end devices opting into some kinds of
>     application
>     > level caching services in order to improve performance. But the
>     draft
>     > should be clear: transport protocols do not have to enable
>     > interference with the transport bits.
>
>     [MK] This is not what the draft is asking for.
>
>     >
>         There are also many operators - e.g., enterprise who rely on
>     the methods
>         currently mentioned in this draft. In this case, they also
>     actually *do*
>         care about the performance of the networks they operate. They
>     also do
>         care about the topics, which matters most depends on which
>     organisation.
>     >
>     > My take is that this draft should not be published as is. It
>     should be
>     > rewritten to actually reflect the consensus of the transport area,
>     > which has to reflect in particular the work in the QUIC working
>     group.
>
>     [MK] The purpose of this draft is exactly to find and document
>     consensus in the transport area and in the IETF. I don't think any
>     individual at this points knows what the consensus actually is. 
>
>
> Well, in that case this document shouldn't be being advanced.
>
>
>     This document has support in tsvwg (otherwise it would not have
>     been adopted as wg document) and I also don't think there is
>     anything in the draft that contradicts any work in the QUIC group.
>
>
> Well, I think what you're hearing is that people think that it is 
> badly aligned with the consensus of other parts of the IETF.
>
> -Ekr

Than ks Ekr, but of course, I don't agree on your thoughts. Which is why 
this needs to be carefully considered.

Gorry


From nobody Tue Nov  5 12:35:05 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB95A120B73; Tue,  5 Nov 2019 12:34:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdzM--RtiT9t; Tue,  5 Nov 2019 12:34:54 -0800 (PST)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20066.outbound.protection.outlook.com [40.107.2.66]) (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 BFBAF120B80; Tue,  5 Nov 2019 12:34:50 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kpShYlpi4rK7e3vdpje0+5skFfimIjZXDJ6zuJyYoXckc2gjeibdwWzXtGO8NESp3xNaM4WLyD3GbJ/EJt8pCtVJ5rGnZR6Ly9edjJAj5/DOB3vxv/FeQoojt339GltH0f7oKmYMF1NZAlGoWa8iDTKIBlM0CquDlvyAD3IBahZDQgZPHUrluI5MBJoLF+ZN39BxOG4RE+LeYoKG3/AaqgG2MXv8iHwCOIIxlVJ87DjdymbOrIyVv49owL87nrpMUhmXP4bXrJYqyuUJyrAA56By4cQtBvsSH0VXNSHGpqf3JSkmTOgYoUm4Mdr+MJgv1mpEIZmZE/NgJSlrpkiiVQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MOsOOx/h10YgEKj1yhe8BZbJUIrL+kwhrFrGjhmLO6s=; b=e66+O4s397BV4bRw1vPhTD4DA+t3bfZ3TrgecWm0nkDxqdkz3jdPjJ3yWGo/z3/K19wFzbfovaQXRYaUIEIpaf4oZZzPfym3CvaJ6SWy3iFs/6muxV6b4id60JAx6ssbf9e/3KgxMNGh5unH2f//muGNfPcYiddXHzgNqh9SPoMUjvxVMaHqM++H5p0RT3710pA7XY5dG7wPycX5HrP2p2SfC36tAiIkszqtJq+ujI4uXCvTqMIfnxFFlJuKCtmRbrE/6vE7tF+TmFEYGQgrm6vfTgXf+HxQY+vvdUzNEmoGQPYZbfpKT8YwbZt8YnFIFd+sSN8RGTFV7KdB+n6VUw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MOsOOx/h10YgEKj1yhe8BZbJUIrL+kwhrFrGjhmLO6s=; b=nk1z7KYYUbzR1r9N8yyLxhfEZ4e8qs/WGKCF2XuGEW2rs3YYZvobLSFyAvvm4f1PYCmDnVgsfGiPSg61nqdc7YehMW6Wz2PlystObon2rM5ni+5SwN8Bt2KBpBQh4yBj/bt837NIOUkLrFUOzwA1vOy0VzE2HnFuEW6vY1HOBoo=
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB4449.eurprd07.prod.outlook.com (52.135.149.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Tue, 5 Nov 2019 20:34:47 +0000
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4189:4ef8:bfc1:ec58]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4189:4ef8:bfc1:ec58%7]) with mapi id 15.20.2430.014; Tue, 5 Nov 2019 20:34:47 +0000
From: Mirja Kuehlewind 
To: "gorry@erg.abdn.ac.uk" 
CC: Eric Rescorla , Christian Huitema , tsvwg IETF list , "saag@ietf.org" 
Thread-Topic: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
Thread-Index: AQHVky08JY2FDXmr60OAsbMwFkv5fad7STQAgAAVH4CAAaI6gIAABbcAgAAET4A=
Date: Tue, 5 Nov 2019 20:34:47 +0000
Message-ID: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com>
References:   <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com>   <2d3c909f-b21c-3916-1eb9-db6de5c661e3@huitema.net> <5DC063F2.8040502@erg.abdn.ac.uk>   <5DC1D94A.9040602@erg.abdn.ac.uk>
In-Reply-To: <5DC1D94A.9040602@erg.abdn.ac.uk>
Accept-Language: en-US
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mirja.kuehlewind@ericsson.com; 
x-originating-ip: [109.42.0.91]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 616b1b8f-4e67-4a4e-715c-08d7622f99ba
x-ms-traffictypediagnostic: AM0PR07MB4449:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:5236;
x-forefront-prvs: 0212BDE3BE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(346002)(136003)(366004)(39860400002)(189003)(199004)(14454004)(8936002)(66616009)(81156014)(66066001)(2351001)(1730700003)(6246003)(4326008)(99286004)(81166006)(86362001)(71190400001)(6486002)(6436002)(6916009)(71200400001)(66446008)(99936001)(64756008)(44832011)(66946007)(66556008)(66476007)(5660300002)(76116006)(7736002)(305945005)(2906002)(229853002)(11346002)(486006)(476003)(2616005)(446003)(478600001)(296002)(6512007)(8676002)(25786009)(26005)(316002)(3846002)(54906003)(36756003)(5640700003)(2501003)(6116002)(256004)(14444005)(6506007)(102836004)(53546011)(76176011)(186003)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4449; H:AM0PR07MB4691.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: xxRSkmdnUa3REQqlsiZ26Zd2p4Q5rZVlgUJQ/7jCCbJAgTy2/MWG/Zns35bcV5Ite7JCgOsfxnhTa+LoU/s5UGQ+fGjuHQ4wKiUUZVT0KGT/SVJg41ZTV3DFt/NJimxJ6asAPpOJv/+hC7KDM9MZupAFrp/mPB2dgM3b2mPegSQsploB5Rq6htKzyhEKpNa1zcYJZGVCww36PtCpYElTPzVMWbOHOAzblqzS6kQX3DAV78C19qR6+q+MPsGE/KMbtU6VgBgA1K/9hMs61BQcFElA0Z2p7DEdFI6Q7P0blnq1qHNBhT7I9gUi21PDRkD0bKGGaTdqlYSekQMeYwfLC+I9ipzdpL2twnK6ZwtUSzLo3UvmZO2fQtw6H5iBiQ2iPhp1v5njx6tO7rGDG2cBYTutja5fV8tgNVTlakk4VaC9/g/oJNRaB14Zh+aI6UB6
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; boundary=Apple-Mail-F1D630A4-D7D2-4AD1-ABAF-779ABE5B62B9; protocol="application/pkcs7-signature"; micalg=sha-256
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 616b1b8f-4e67-4a4e-715c-08d7622f99ba
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2019 20:34:47.7382 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: NgKyi2HH/uVRT9YqQvgAAl/CzQgcWSCy64x+mX8x3t8eXA37sH2c8iF1qEVwi1hl0qL1KFqlHi8gBoBhgsJjFyWw7SIMWQPXGiWsg0jxiT8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4449
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Nov 2019 20:34:57 -0000

--Apple-Mail-F1D630A4-D7D2-4AD1-ABAF-779ABE5B62B9
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: base64

U2VlIGJlbG93Lg0KDQo+IEFtIDA1LjExLjIwMTkgdW0gMjE6MTkgc2NocmllYiBHb3JyeSBGYWly
aHVyc3QgPGdvcnJ5QGVyZy5hYmRuLmFjLnVrPjoNCj4gDQo+PiBPbiAwNS8xMS8yMDE5LCAxOTo1
OCwgRXJpYyBSZXNjb3JsYSB3cm90ZToNCj4+IA0KPj4gDQo+PiBPbiBNb24sIE5vdiA0LCAyMDE5
IGF0IDEwOjAyIEFNIE1pcmphIEt1ZWhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24u
Y29tIDxtYWlsdG86bWlyamEua3VlaGxld2luZEBlcmljc3Nvbi5jb20+PiB3cm90ZToNCj4+IA0K
Pj4gICAgSGkgQ2hyaXN0aWFuLA0KPj4gDQo+PiAgICBwbGVhc2Ugc2VlIHR3byBjb21tZW50cyBi
ZWxvdyAobWFya2VkIHdpdGggW01LXSkuDQo+PiANCj4+ICAgIE1pcmphDQo+PiANCj4+ICAgIO+7
v09uIDA0LjExLjE5LCAxODo0NiwgIkdvcnJ5IEZhaXJodXJzdCIgPGdvcnJ5QGVyZy5hYmRuLmFj
LnVrDQo+PiAgICA8bWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrPj4gd3JvdGU6DQo+PiANCj4+
ICAgICAgICBKdXN0IGZvY3Vzc2luZyBvbiB0aGUgZW5kLi4uDQo+PiANCj4+ICAgICAgICBPbiAw
NC8xMS8yMDE5LCAxNjoyOSwgQ2hyaXN0aWFuIEh1aXRlbWEgd3JvdGU6DQo+PiAgICA+Pg0KPj4g
ICAgPj4gW01LXSBUaGF04oCZcyBub3QgdGhlIGludGVudGlvbiBoZXJlLiBCdXQgd2UgYWxzbyBu
ZWVkIHRvDQo+PiAgICBjb25zaWRlciB3YXlzDQo+PiAgICA+PiB0byBpbnRlcmFjdCB3aXRoIHRo
ZSBuZXR3b3JrIHdoZXJlIHRoaXMgYnJpbmdzIGJlbmVmaXQgdG8gYm90aCB0aGUNCj4+ICAgID4+
IG5ldHdvcmsgYW5kIHRoZSBwZXJmb3JtYW5jZSBvZiB0aGUgZW5kLXRvLWVuZCB0cmFmZmljLiBU
aGVyZSBhcmUNCj4+ICAgID4+IHNpdHVhdGlvbiB3aGVyZSB0aGlzIGlzIHRoZSBjYXNlLiBBbmQg
SSBkb27igJl0IHRoaW5rIG9uZSBtYWtlcw0KPj4gICAgc2Vuc2UNCj4+ICAgID4+IHdpdGhvdXQg
dGhlIG90aGVyLg0KPj4gICAgPj4NCj4+ICAgID4gWW91IHNlZW0gdG8gYmUgYXJndWluZyBmb3Ig
c29tZXRoaW5nIGxpa2UgInBlcmZvcm1hbmNlIGVuaGFuY2luZw0KPj4gICAgPiBwcm94aWVzIi4g
RW5kLXRvLWVuZCBlbmNyeXB0aW9uIGlzIGluZGVlZCBhIHdheSB0byBvcHQgb3V0IG9mIHN1Y2gN
Cj4+ICAgID4gcHJveHlpbmcuIE1lYXN1cmVtZW50cyBzbyBmYXIgaW5kaWNhdGUgdGhhdCBvcHRp
bmcgb3V0IGhhcyB2ZXJ5DQo+PiAgICBsaXR0bGUNCj4+ICAgID4gaW1wYWN0IG9uIGFjdHVhbCBw
ZXJmb3JtYW5jZSwgYW5kIHRoYXQgd2hhdGV2ZXIgaW1wYWN0IHRoZXJlIGlzDQo+PiAgICBjb3Vs
ZA0KPj4gICAgPiBiZSByZWR1Y2VkIGJ5IGltcHJvdmVtZW50cyBpbiBlbmQtdG8tZW5kIGFsZ29y
aXRobXMuIEluIGZhY3QsIGluDQo+PiAgICBtYW55DQo+PiAgICA+IGNhc2VzLCBlbmQgdG8gZW5k
IHBlcmZvcm1hbmNlIGlzIGJldHRlciB3aXRob3V0IHN1Y2ggcHJveGllcy4NCj4+ICAgIEJ1dCB0
aGUNCj4+ICAgID4gcmVhbCByZWFzb24gZm9yIHRoZSBvcHBvc2l0aW9uIHRvIHRoZSBjb25jZXB0
IGlzIG9zc2lmaWNhdGlvbi4NCj4+ICAgID4gRW5hYmxpbmcgc3VjaCBwcm94aWVzIHdvdWxkIHF1
aWNrbHkgb3NzaWZ5IHRoZSBuZXcgdHJhbnNwb3J0cywNCj4+ICAgIGFuZCBhDQo+PiAgICA+IHN1
Y2ggdGhlcmUgaXMgYSBzdHJvbmcgY29uc2Vuc3VzIGluIHRoZSBlbmQtdG8tZW5kIHRyYW5zcG9y
dA0KPj4gICAgZGVzaWduZXJzDQo+PiAgICA+IHRvIHVzZSBlbmNyeXB0aW9uIGFuZCBwcmV2ZW50
IGludGVyZmVyZW5jZSBieSBzdWNoIGRldmljZXMuDQo+PiAgICA+DQo+PiAgICAgICAgT24gUEVQ
czogVGhlIGN1cnJlbnQgY2FzZSBmb3IgbWFueSBvZiB0aGUgbmV0d29yayBzZWdtZW50cyBJDQo+
PiAgICBzZWUgaXMgdGhhdA0KPj4gICAgICAgIFFVSUMgaXMgcXVpdGUgZ29vZCwgYnV0IGl0IGlz
IGNvbnNpZGVyYWJseSB3b3JzZSAoY3VycmVudGx5KQ0KPj4gICAgdGhhbiBhIFBFUA0KPj4gICAg
ICAgIHVzaW5nIFNwbGl0LVRDUC4gVGhhdCdzIG5vdCB0byBzYXkgaXQgY2FuJ3QgaW1wcm92ZSAt
IGJ1dA0KPj4gICAgdGhhdCdzIG5vdA0KPj4gICAgICAgIHRydWUgeWV0LiBIb3dldmVyOiBJdCdz
IGN1cmlvdXMgdGhhdCBwZW9wbGUga2VlcCBnb2luZyBiYWNrIHRvDQo+PiAgICBQRVBzLA0KPj4g
ICAgICAgIGJlY2F1c2UgbmV0d29yayBkZXZpY2VzIHRoYXQgY2hhbmdlIHRoZSB0cmFuc3BvcnQg
aGVhZGVyIHdlcmUNCj4+ICAgICAgICBzcGVjaWZpY2FsbHkgb3V0LW9mLXNjb3BlIGZvciB0aGlz
IElEIQ0KPj4gICAgPg0KPj4gICAgPiBUaGlzIGRvZXMgbm90IG1lYW4gdGhhdCBuZXR3b3JrIGxl
dmVsIGRlcGxveW1lbnQgaGF2ZSBubyByb2xlIGluDQo+PiAgICB0aGUNCj4+ICAgID4gZnV0dXJl
LiBJIGNvdWxkIHNlZSBmb3IgZXhhbXBsZSB0dW5uZWxzIGRlcGxveWVkIHRoYXQgdXNlIEZFQyBv
cg0KPj4gICAgbG9jYWwNCj4+ICAgID4gcmV0cmFuc21pc3Npb24gdG8gbWFzayB0aGUgcG9vciBw
ZXJmb3JtYW5jZSBvZiBhIHBhcnRpY3VsYXINCj4+ICAgIHN1Ym5ldC4gT3INCj4+ICAgID4gSSBj
b3VsZCBzZWUgZW5kLXRvLWVuZCBkZXZpY2VzIG9wdGluZyBpbnRvIHNvbWUga2luZHMgb2YNCj4+
ICAgIGFwcGxpY2F0aW9uDQo+PiAgICA+IGxldmVsIGNhY2hpbmcgc2VydmljZXMgaW4gb3JkZXIg
dG8gaW1wcm92ZSBwZXJmb3JtYW5jZS4gQnV0IHRoZQ0KPj4gICAgZHJhZnQNCj4+ICAgID4gc2hv
dWxkIGJlIGNsZWFyOiB0cmFuc3BvcnQgcHJvdG9jb2xzIGRvIG5vdCBoYXZlIHRvIGVuYWJsZQ0K
Pj4gICAgPiBpbnRlcmZlcmVuY2Ugd2l0aCB0aGUgdHJhbnNwb3J0IGJpdHMuDQo+PiANCj4+ICAg
IFtNS10gVGhpcyBpcyBub3Qgd2hhdCB0aGUgZHJhZnQgaXMgYXNraW5nIGZvci4NCj4+IA0KPj4g
ICAgPg0KPj4gICAgICAgIFRoZXJlIGFyZSBhbHNvIG1hbnkgb3BlcmF0b3JzIC0gZS5nLiwgZW50
ZXJwcmlzZSB3aG8gcmVseSBvbg0KPj4gICAgdGhlIG1ldGhvZHMNCj4+ICAgICAgICBjdXJyZW50
bHkgbWVudGlvbmVkIGluIHRoaXMgZHJhZnQuIEluIHRoaXMgY2FzZSwgdGhleSBhbHNvDQo+PiAg
ICBhY3R1YWxseSAqZG8qDQo+PiAgICAgICAgY2FyZSBhYm91dCB0aGUgcGVyZm9ybWFuY2Ugb2Yg
dGhlIG5ldHdvcmtzIHRoZXkgb3BlcmF0ZS4gVGhleQ0KPj4gICAgYWxzbyBkbw0KPj4gICAgICAg
IGNhcmUgYWJvdXQgdGhlIHRvcGljcywgd2hpY2ggbWF0dGVycyBtb3N0IGRlcGVuZHMgb24gd2hp
Y2gNCj4+ICAgIG9yZ2FuaXNhdGlvbi4NCj4+ICAgID4NCj4+ICAgID4gTXkgdGFrZSBpcyB0aGF0
IHRoaXMgZHJhZnQgc2hvdWxkIG5vdCBiZSBwdWJsaXNoZWQgYXMgaXMuIEl0DQo+PiAgICBzaG91
bGQgYmUNCj4+ICAgID4gcmV3cml0dGVuIHRvIGFjdHVhbGx5IHJlZmxlY3QgdGhlIGNvbnNlbnN1
cyBvZiB0aGUgdHJhbnNwb3J0IGFyZWEsDQo+PiAgICA+IHdoaWNoIGhhcyB0byByZWZsZWN0IGlu
IHBhcnRpY3VsYXIgdGhlIHdvcmsgaW4gdGhlIFFVSUMgd29ya2luZw0KPj4gICAgZ3JvdXAuDQo+
PiANCj4+ICAgIFtNS10gVGhlIHB1cnBvc2Ugb2YgdGhpcyBkcmFmdCBpcyBleGFjdGx5IHRvIGZp
bmQgYW5kIGRvY3VtZW50DQo+PiAgICBjb25zZW5zdXMgaW4gdGhlIHRyYW5zcG9ydCBhcmVhIGFu
ZCBpbiB0aGUgSUVURi4gSSBkb24ndCB0aGluayBhbnkNCj4+ICAgIGluZGl2aWR1YWwgYXQgdGhp
cyBwb2ludHMga25vd3Mgd2hhdCB0aGUgY29uc2Vuc3VzIGFjdHVhbGx5IGlzLiANCj4+IA0KPj4g
V2VsbCwgaW4gdGhhdCBjYXNlIHRoaXMgZG9jdW1lbnQgc2hvdWxkbid0IGJlIGJlaW5nIGFkdmFu
Y2VkLg0KPj4gDQo+PiANCj4+ICAgIFRoaXMgZG9jdW1lbnQgaGFzIHN1cHBvcnQgaW4gdHN2d2cg
KG90aGVyd2lzZSBpdCB3b3VsZCBub3QgaGF2ZQ0KPj4gICAgYmVlbiBhZG9wdGVkIGFzIHdnIGRv
Y3VtZW50KSBhbmQgSSBhbHNvIGRvbid0IHRoaW5rIHRoZXJlIGlzDQo+PiAgICBhbnl0aGluZyBp
biB0aGUgZHJhZnQgdGhhdCBjb250cmFkaWN0cyBhbnkgd29yayBpbiB0aGUgUVVJQyBncm91cC4N
Cj4+IA0KPj4gDQo+PiBXZWxsLCBJIHRoaW5rIHdoYXQgeW91J3JlIGhlYXJpbmcgaXMgdGhhdCBw
ZW9wbGUgdGhpbmsgdGhhdCBpdCBpcyBiYWRseSBhbGlnbmVkIHdpdGggdGhlIGNvbnNlbnN1cyBv
ZiBvdGhlciBwYXJ0cyBvZiB0aGUgSUVURi4NCg0KV2hhdCBJ4oCZbSBoZWFyaW5nIGlzIHRoYXQg
Mi0zIHBlb3BsZSB0aGluayB0aGlzIGlzIG5vdCBhbGlnbmVkIGJ1dCBkb27igJl0IGFjdHVhbGx5
IHNheSB3aHkgZXhhY3RseSB0aGV5IHRoaW5rIHRoYXQgd2hpbGUgdGhlcmUgYXJlIGEgYnVuY2gg
b2YgcGVvcGxlIHN1cHBvcnRpbmcgdGhpcyBkb2N1bWVudCAoIHRocm91Z2hvdXQgdGhlIHdob2xl
IHdnIHByb2Nlc3MpLg0KDQpNaXJqYQ0KDQo+PiANCj4+IC1Fa3INCj4gDQo+IFRoYW4ga3MgRWty
LCBidXQgb2YgY291cnNlLCBJIGRvbid0IGFncmVlIG9uIHlvdXIgdGhvdWdodHMuIFdoaWNoIGlz
IHdoeSB0aGlzIG5lZWRzIHRvIGJlIGNhcmVmdWxseSBjb25zaWRlcmVkLg0KPiANCj4gR29ycnkN
Cj4gDQo=

--Apple-Mail-F1D630A4-D7D2-4AD1-ABAF-779ABE5B62B9
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDM0w
ggYDMIID66ADAgECAg8BaU6kmW/78jyVZPgb4ikwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMC
U0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENB
IHYzMB4XDTE5MDMwNTE2MTY0M1oXDTIyMDMwNTE2MTY0MlowbjERMA8GA1UECgwIRXJpY3Nzb24x
GTAXBgNVBAMMEE1pcmphIEt1ZWhsZXdpbmQxEDAOBgNVBAUTB2VraGxtcmoxLDAqBgkqhkiG9w0B
CQEWHW1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAzbEm7ACaZBiLCo5AMLb1pe7+qin+EDW/6F5OkuzBE5awAB0DcYPCPnVmvKTjByQE
wXfcv4GpesID1ZoIIw9yvE3JS3e0G9EESbDD/P1dEsvUbfKzqbiogFjxPTcO5393z+S6/lZhh1HE
Xzn5eN4rqXaphkOdt235jtuXr9p9hCXTbk2s2u+Q+UBBsJfDZFnupphfgSJdO2ZDIr54posGTI29
o2Z8Yp0kXGUdReJYhB3U7IyusRfGGlabLLSEb405hQyckqhCqnNDBqgw8s2kCsvCV5vvsU4HxRQB
h6TAo+Qowd5LjjhUb5pWjDzNBw9HDCuv50t6JuUbToV4VodAyQIDAQABo4IBwzCCAb8wHwYDVR0j
BBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwHQYDVR0OBBYEFOS9IY8huUonCxTez1fXbiljN+tp
MA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIB
FixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAoBgNVHREEITAf
gR1taXJqYS5rdWVobGV3aW5kQGVyaWNzc29uLmNvbTBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8v
Y3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMB0GA1UdJQQW
MBQGCCsGAQUFBwMEBggrBgEFBQcDAjCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRw
Oi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVs
aWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwDQYJKoZIhvcNAQELBQAD
ggIBAEifFgbyma9dHCxsY3R0wp+4sjcmAiEvA3S0YKJl7SBd897BV8O/Nq6z6QCx2zKTpfia7bF5
Yzou0/2PS2qX/2TXRsgGKRhWmYyBsiAvKmuEeA9t/3NZOImicaYCn2WVu3tfFE8lnXlH+O/sMRdU
gq7yMusDm9YDO6urKezkh6IZrLWIyz4s4Uy2SMyXc2ujvB0doUB26+ld070A0x+isDjY3of/23Yg
4xAvr5AK5sQtq+0D7tRUlPefXrA1bI/PDEZiq5Bvqa9tfyd7HPlhzHhrQAS5t42fybMpwdGxLvjH
XME5fPB0xRH5kchOawsd2BPSv2ZVWt9WYGDbkAgEtCW37zNwdzX5ix43f8C0TRU5AiU531gObLbr
KWZyhLRurGlwtSqvmGCyCiTN3jhzjVTAM3uiLosG2SZbyq5ZFWI7MezHM1owAQvm0sOEEfXp88nc
Xa7SxkwiJr/UH6P3pRADsVC55HoQVS1GydEBnDBNAyIcnsM7sPbkGF92F7U16PWpJYQaZbVd2Vkj
FahNN9uWbn55A/daE+QiF2QcfCVnFOSj9ah1ke6M3MahqcqkJpXoUizv8DwiKXGkKOiLB3x8pqSr
cCUQ5Pjt3wFjPCuVJ7AoiBYP2GmXAyEXtYeh0nVlKQuVtloCpsyR5bumbOoQf/r6FoUY/xgh8/pg
pOMiMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYD
VQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEw
MjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv
bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEB
BQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6V
iqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1l
VtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV
2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTS
uG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvA
l7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQg
YFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8
s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3W
LJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e
6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzAB
hiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9y
ZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjAS
BgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUH
AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwRE
MEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFy
b290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIB
BjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV
6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1A
soZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46g
zKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQG
pieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+L
Faaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOr
MGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5Qxib
XqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6
PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfY
PGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/
HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICyjCCAsYCAQEwWjBHMQswCQYDVQQGEwJTRTER
MA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMC
DwFpTqSZb/vyPJVk+BviKTANBglghkgBZQMEAgEFAKCCAUEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkxMTA1MjAzNDQ3WjAvBgkqhkiG9w0BCQQxIgQghWwixdtQ
66OYCL6t4zByGBmCafDcfB1f09am2LtfbjwwaQYJKwYBBAGCNxAEMVwwWjBHMQswCQYDVQQGEwJT
RTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0Eg
djMCDwFpTqSZb/vyPJVk+BviKTBrBgsqhkiG9w0BCRACCzFcoFowRzELMAkGA1UEBhMCU0UxETAP
BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8B
aU6kmW/78jyVZPgb4ikwDQYJKoZIhvcNAQEBBQAEggEAyTBlfT3+VyC3n6+K6Wn7UticKPkxgLiy
VltqBSPv+i2jjCvsrdgOe14lyW9Eg6qTJEAuOiGUgpUmkdRzNpoZXmf8mbiz4aazJmU43XGT3w5D
XKOqVvcfqBQIM4BFn6WSN8RXiLK1SH7lTPj7dkTIjZodlNicK+kzv3gmoBCovFAspk1/LV5LRMRb
3wf1nB2bna7DStN48/rGUdXbRjdwbpFyqmsntB3IhXUNIsvUE0kCVm2ehnU7voLrUF9PnptO1ZoM
lMq0+ln6p1UdRM/T+hfPD6Hnb6oCOgs2ob6MnDyiDaMx607zgqq+yFkpEQ1O2KDmXhhrSjl+z5lR
+/6vJgAAAAAAAA==

--Apple-Mail-F1D630A4-D7D2-4AD1-ABAF-779ABE5B62B9--


From nobody Tue Nov  5 12:45:40 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7B6120BFE for ; Tue,  5 Nov 2019 12:45:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5ys-_yjZqbP for ; Tue,  5 Nov 2019 12:45:38 -0800 (PST)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 C1A17120BF3 for ; Tue,  5 Nov 2019 12:45:37 -0800 (PST)
Received: by mail-lf1-x12a.google.com with SMTP id 195so16168933lfj.6 for ; Tue, 05 Nov 2019 12:45:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XlrdPLkPNzpZtj1Mee+w6mVGKdJ+D41a8zri8kzubF0=; b=H91epACQnVU6IK7nId6Tt/Cpzkl4PyeW8uRY8vtFO/j0kuWMC6ZkpSAqckZgqli5de ZsTSDkJmTdWUsyXjDmigMg6lOiBxuPUtEVE7+KHCW79xIghzmyKM6mGTiDJqs5arrA2o fmTxoAbzYT6+ldLnXAJn7txjC/etSnCAPxRTFT/iWu3ocXw1DPQs4QxbomsSLJZGlwn0 qeVoO6etPWjnMP0cQUWhO/QJs4i2aqrQnYOMILJWlxlkvEyxumk/nIV4ar0jsT9/1a7i zN0i0yTwqFoy1Hj8GyGM6ugHmAR0/T8PnfU9e99F+BEQESOP5bt/BmmTGF9tKmrEHzMY ZD5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XlrdPLkPNzpZtj1Mee+w6mVGKdJ+D41a8zri8kzubF0=; b=C0p+Md12fh+EjeHBO3ahrX4WfXM+6uyojGc0AXZE0mjmrzoklf77jtBoWBTqtqYnxI SyCrZa+H7lh0Yc16TmsS3DdR9mfYCVw0nU9pMe4zj6qgVf50QHA5ZtCJaaGm25wQjN9K h0W9zf6Ih6p7d6Vym6xaHP0SR09+pCrZVUp91RhqMNd4sgtSLDrTbsmtxpJrJ7rAUEIa qOg1+zcDCzR0xUwz/gL1WGEzmi+8lN40dNsTPHr3FdTtfX+uYrfFuiQlusuAvx5DYHGS q1IUqAubVEfqdMQZ/yxcQ33rKkdmB9fbJ8+IR9fgsGk+r6y4TRUSK6PGUzGxcrohTuRZ 4Pgw==
X-Gm-Message-State: APjAAAVXTf+F0P/rVLSI6QlC+7/g3vymLI2H9IiMkVSnFM0+7WgVurx/ 5fA0njZu2+PdeNFAMxIMb/m64Gc2tN/EWQO+Zc8L1A==
X-Google-Smtp-Source: APXvYqySZbKa+aE1kVmYvICn2n97MiO0fQCmmXPuTTLgQ2sGGFuqo0kBMNN6k34k4BZdb2/4fi7+Z32VaC3unwqZMV4=
X-Received: by 2002:a19:f107:: with SMTP id p7mr21244942lfh.91.1572986736049;  Tue, 05 Nov 2019 12:45:36 -0800 (PST)
MIME-Version: 1.0
References:   <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com>   <2d3c909f-b21c-3916-1eb9-db6de5c661e3@huitema.net> <5DC063F2.8040502@erg.abdn.ac.uk>   <5DC1D94A.9040602@erg.abdn.ac.uk> <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com>
In-Reply-To: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com>
From: Eric Rescorla 
Date: Tue, 5 Nov 2019 12:44:59 -0800
Message-ID: 
To: Mirja Kuehlewind 
Cc: "gorry@erg.abdn.ac.uk" , Christian Huitema ,  tsvwg IETF list , "saag@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000a392e805969f83bf"
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Nov 2019 20:45:40 -0000

--000000000000a392e805969f83bf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 5, 2019 at 12:34 PM Mirja Kuehlewind <
mirja.kuehlewind@ericsson.com> wrote:

> >> Well, I think what you're hearing is that people think that it is badl=
y
> aligned with the consensus of other parts of the IETF.
>
> What I=E2=80=99m hearing is that 2-3 people think this is not aligned but=
 don=E2=80=99t
> actually say why exactly they think that


I wrote a fairly long note about it, I can understand that you don't agree,
but I don't really think "don't exactly say why they think that" is a fair
characterization.


while there are a bunch of people supporting this document ( throughout the
> whole wg process).
>

Well, it's often the case that a WG has internal support for something, but
then when it gets brought to the wider IETF community, it turns out that
there isn't IETF-wide consensus. I'll leave it to the Chairs and ADs to
determine if that's the case here.

-Ekr


> Mirja
>
> >>
> >> -Ekr
> >
> > Than ks Ekr, but of course, I don't agree on your thoughts. Which is wh=
y
> this needs to be carefully considered.
> >
> > Gorry
> >
>

--000000000000a392e805969f83bf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Nov 5, 2019 at 12:34 PM Mirja=
 Kuehlewind <mirja.kueh=
lewind@ericsson.com> wrote:

>> Well, I think what you're hearing is that people think that it=
 is badly aligned with the consensus of other parts of the IETF.



What I=E2=80=99m hearing is that 2-3 people think this is not aligned but d=
on=E2=80=99t actually say why exactly they think that

=

I wrote a fairly long note about it, I can understand that you d=
on't agree, but I don't really think "don't exactly say wh=
y they think that" is a fair characterization.


 while there =
are a bunch of people supporting this document ( throughout the whole wg pr=
ocess).

Well, it's often the case t=
hat a WG has internal support for something, but then when it gets brought =
to the wider IETF community, it turns out that there isn't IETF-wide co=
nsensus. I'll leave it to the Chairs and ADs to determine if that's=
 the case here.

-Ekr




Mirja



>> 

>> -Ekr

> 

> Than ks Ekr, but of course, I don't agree on your thoughts. Which =
is why this needs to be carefully considered.

> 

> Gorry

> 




--000000000000a392e805969f83bf--


From nobody Tue Nov  5 13:04:20 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4F7120C69; Tue,  5 Nov 2019 13:04:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.219
X-Spam-Level: 
X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8r9QWhXKpff; Tue,  5 Nov 2019 13:04:09 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 73903120C65; Tue,  5 Nov 2019 13:04:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=BUq0dzQ299ceoE0Fur3waDAnxArz/qPSbM9d99Hd7uQ=; b=unt23BMHFz7tzgFPCdsgj2GWYp uxliCej5KhB3y7k6QxSU2Gb2FIHGW59USlL1Fls6B1lmQNVvLpCIEQi9Oi9/u/sgxfz7jjCLT95PA GiYZWYw9876BJ/yAzWD8+yN2X/k9nha2hhSei/7pXyFVf7cBWL6FG4OD6Q4Y+OsLjKuOb4bHXBCAx D1EUpCcmaTh5D3r+1vwbYfciZnX/PYlxcdanIuweZIcOAmaqc7gQH+tUl+ViciWHhJWTEEya3U9cr XlPSZ7cxeJDR20t832dIz33b5s3P9xvPd+qQbfTl6uQimLXUfLOH+pX/1p72wuMaALyJ/NWvMZKwK 8t8jF3ew==;
Received: from [38.64.80.138] (port=52120 helo=[172.21.17.84]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iS5ze-002SEO-4n; Tue, 05 Nov 2019 16:04:06 -0500
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
From: Joe Touch 
In-Reply-To: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com>
Date: Tue, 5 Nov 2019 13:04:01 -0800
Cc: "gorry@erg.abdn.ac.uk" , Christian Huitema , tsvwg IETF list , "saag@ietf.org" 
Message-Id: <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com>
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com>
To: Mirja Kuehlewind 
X-Mailer: iPhone Mail (17B84)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Nov 2019 21:04:12 -0000

> On Nov 5, 2019, at 12:35 PM, Mirja Kuehlewind  wrote:
>=20
> What I=E2=80=99m hearing is that 2-3 people think this is not aligned but d=
on=E2=80=99t actually say why exactly they think that

That=E2=80=99s not what we=E2=80=99re saying. We gave reasons.=20

Joe=20=


From nobody Tue Nov  5 13:16:54 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F230F12095B for ; Tue,  5 Nov 2019 13:16:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=ZC24fsLQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UacBRw01
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 5Y9N3tN43A9d for ; Tue,  5 Nov 2019 13:16:51 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F51120B7E for ; Tue,  5 Nov 2019 13:16:50 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id BF10321FF3 for ; Tue,  5 Nov 2019 16:16:48 -0500 (EST)
Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Tue, 05 Nov 2019 16:16:48 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=5KkXq DIQFguBSKGYzrSPdI7SWOh+LXQrUyXQyRoUw9w=; b=ZC24fsLQDwCHbMvh6grip MtO9fnTAZ3Di17jTd9PoEXXB6Xm4d6elJFjNjmQaE2hfCYv/LrqSD15667LHEafS /uT4Zw8ryfrjpEcYV4sF9MjtEFhALIbtc97kB5o5iWLRn+z7Var8Ef+9rpEKcrO9 0SHjahNiT6wJ/8r+wE6ynXDARU+B0dWTH4SDvjuy86ZEnvLChH38er8YCO6FvM5A ClhgWXz6i3A9oE6CpYS2bUbmKquMHOinomgQccRPHxGtL7GEYmtQTeSHuVs+4B9L 8FoG/jqqqJS7SQcf+HFTQ6bWvlfHyC5FCfwGM05J5VuW/JhlUV2TVvWMCgVRfyo9 w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=5KkXqDIQFguBSKGYzrSPdI7SWOh+LXQrUyXQyRoUw 9w=; b=UacBRw015LSdVkCz80lE36ebwkvvvZoRJZ9UGc/CyWl5f0rBWaRNT2Rmk wov56XG5V4Y8bM/ztOmB5XF9XnlpGSxWAOXa1BtvvJ+pEV90U3KvvEddfbOUoM28 azGUGhZhqh8TDSqm+G3lEluExNr376rqT+gLw8WE6+4ciuBvLnaajkF78w+EEFlK CY9No+n5UGz/jE960nvRAGRIFGGr+iiRWLnbBsZVUumtYIQbBYZrbswVFC7fbLov KFVTqT4JC/yIoLSerwX2+uVQeP8Bxr88UKmHmD8ex/SE1O/gMJ/Z+pTMMqWgaFj2 Nyu2L8dvI9NomFKzHwsqk2gDBBC1g==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduhedgudegjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgse htqhertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegt rgifsehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorh hgnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhn vghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 431E83C00A1; Tue,  5 Nov 2019 16:16:48 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1
Mime-Version: 1.0
Message-Id: <618f8dc5-e61d-4a09-a1a2-b4712eb6f96f@www.fastmail.com>
In-Reply-To: 
References:   <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com>   <2d3c909f-b21c-3916-1eb9-db6de5c661e3@huitema.net> <5DC063F2.8040502@erg.abdn.ac.uk>   <5DC1D94A.9040602@erg.abdn.ac.uk> <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> 
Date: Tue, 05 Nov 2019 13:16:28 -0800
From: "Christopher Wood" 
To: saag@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [saag]  =?utf-8?q?=5Btsvwg=5D_Comments_on_draft-ietf-tsvwg-transp?= =?utf-8?q?ort-encrypt-08=2Etxt?=
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Nov 2019 21:16:53 -0000

On Tue, Nov 5, 2019, at 12:44 PM, Eric Rescorla wrote:
>=20
>=20
> On Tue, Nov 5, 2019 at 12:34 PM Mirja Kuehlewind=20
>  wrote:
> >  >> Well, I think what you're hearing is that people think that it i=
s badly aligned with the consensus of other parts of the IETF.
> >=20
> >  What I=E2=80=99m hearing is that 2-3 people think this is not align=
ed but don=E2=80=99t actually say why exactly they think that
>=20
> I wrote a fairly long note about it, I can understand that you don't=20=

> agree, but I don't really think "don't exactly say why they think that=
"=20
> is a fair characterization.
>=20
>=20
> >  while there are a bunch of people supporting this document ( throug=
hout the whole wg process).
>=20
> Well, it's often the case that a WG has internal support for something=
,=20
> but then when it gets brought to the wider IETF community, it turns ou=
t=20
> that there isn't IETF-wide consensus. I'll leave it to the Chairs and=20=

> ADs to determine if that's the case here.

In my opinion, this seems to be the case. Based on this discussion and o=
ther reviews [1], I think it's clear that the document does not necessar=
ily reflect consensus from the transport (and security) area(s) in gener=
al, and the QUIC WG in particular. Thus, I do not think it should be pub=
lished at this time.=20

Best,
Chris

[1] https://datatracker.ietf.org/doc/review-ietf-tsvwg-transport-encrypt=
-01-secdir-early-wood-2018-12-27/


From nobody Tue Nov  5 14:10:34 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33888120025; Tue,  5 Nov 2019 14:10:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPP83oiNfvaz; Tue,  5 Nov 2019 14:10:24 -0800 (PST)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::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 9848E12008F; Tue,  5 Nov 2019 14:10:23 -0800 (PST)
Received: by mail-lj1-x235.google.com with SMTP id r7so15017589ljg.2; Tue, 05 Nov 2019 14:10:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1wHlvxPUraVXaiYgJnudSvaGhOYUzSvgFCVMeEJpjLU=; b=JtqYKLjjNDLmvBpaLV4SiU64mVY+Th3rge66At3Eh/mPGDWMECv/n2J/85BSju5Vi9 2Gj0M4XMMMavAX4JN9f0QOkp3ACv5xg2GvqFrWq8NmU6EpRN8wtls3nG8706c/VwhagU 46tP521ILM13zY/Fuz5LKCP9IuRH+hFV1j6sCmgt/nC6NoDrYnGGC2wCgxI9gBJSgasr ZEToQcIrM3qO5h0X4F35FGagzIZOukgRgWPjTvjSWL5/zVZ0rY8+gSkevrmtBQxeBTHf JvHUW/SXDL+l1b4tl/yA7WETTCawTZzQSDwiGWq6MNT84pgn7evyDFlSiFtTtwT2OwCh n8ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1wHlvxPUraVXaiYgJnudSvaGhOYUzSvgFCVMeEJpjLU=; b=Kfp31npWTa8kub3gpix6e0avx0i32NEHvcMnMLNnY15GOMkydDx5MKRcI+jUMHKVIE Cd8RVkcWs97uk4Ut5M2AcWCdLptx0s1V/HMP1VSf14ERlMVPI7e6ViluQ3P1Gu93Ujxv 2GavqgC84uXz048GY7Nlq2jkGEjbNPmsOc6UjORX5qVtYU+a1jpcrpet8gAWnW/xKyBL +waySM+2yhOk8rmqtaylkVsBkJsFoQikGc0GIT5bPVNaFJa9R9sVNtipDkJTf/W7uw1m AQCpZVnzVYv7r0gCN2TEc3mG28P9e2obzBob2WHFVvQ0YnVe+IMMsMZc1U4n9C9PRMFZ NVcA==
X-Gm-Message-State: APjAAAXWIodKbrwJoWegIoopEw4dF2VNMjk9wMVHGrQFdXI3mnGPkBo0 Wp98AI/KPQd+odZePQtfNa4j5O8DFlz8CK7xms0=
X-Google-Smtp-Source: APXvYqwGvs/Sjdro0ldR6H0XknwLNBRngUZYRq1LTgkhncS35xEo262LlL2KjUFvu3x62oz92aYBPnKszV25k53PO2c=
X-Received: by 2002:a2e:9016:: with SMTP id h22mr16347603ljg.137.1572991821653;  Tue, 05 Nov 2019 14:10:21 -0800 (PST)
MIME-Version: 1.0
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com>
In-Reply-To: <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com>
From: David Schinazi 
Date: Tue, 5 Nov 2019 14:10:10 -0800
Message-ID: 
To: Joe Touch 
Cc: Mirja Kuehlewind ,  "gorry@erg.abdn.ac.uk" , Christian Huitema ,  tsvwg IETF list , "saag@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000c3abaf0596a0b256"
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Nov 2019 22:10:26 -0000

--000000000000c3abaf0596a0b256
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I also oppose publication of draft-ietf-tsvwg-transport-encrypt. This
document discourages transport header encryption and publishing it could
harm future protocol development.

David

On Tue, Nov 5, 2019 at 1:04 PM Joe Touch  wrote:

>
>
> > On Nov 5, 2019, at 12:35 PM, Mirja Kuehlewind  40ericsson.com@dmarc.ietf.org> wrote:
> >
> > What I=E2=80=99m hearing is that 2-3 people think this is not aligned b=
ut don=E2=80=99t
> actually say why exactly they think that
>
> That=E2=80=99s not what we=E2=80=99re saying. We gave reasons.
>
> Joe
>

--000000000000c3abaf0596a0b256
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I also oppose publication of=C2=A0draft-ietf-tsvwg-transpo=
rt-encrypt. This document discourages transport header encryption and publi=
shing it could harm future protocol development.

David

On Tue, Nov 5, 2019 at 1:04 PM Joe Touch <touch@strayalpha.com> wrote:




> On Nov 5, 2019, at 12:35 PM, Mirja Kuehlewind <mirja.kuehlewind=3D<=
a href=3D"mailto:40ericsson.com@dmarc.ietf.org" target=3D"_blank">40ericsso=
n.com@dmarc.ietf.org> wrote:

> 

> What I=E2=80=99m hearing is that 2-3 people think this is not aligned =
but don=E2=80=99t actually say why exactly they think that



That=E2=80=99s not what we=E2=80=99re saying. We gave reasons. 



Joe 




--000000000000c3abaf0596a0b256--


From nobody Tue Nov  5 20:10:31 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C4312004D; Tue,  5 Nov 2019 20:10:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=ITb3JIF4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MxQFyLCx
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 VBDnCFYWL3yL; Tue,  5 Nov 2019 20:10:21 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38CCD12002E; Tue,  5 Nov 2019 20:10:21 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B9F7D21A92; Tue,  5 Nov 2019 23:10:19 -0500 (EST)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 05 Nov 2019 23:10:19 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm3; bh=ST z3GdKSIj/u5/+p4J10CA0Bswh0HWRR8oAKYUkK+CU=; b=ITb3JIF4fEbW1KT2rX bLviQ6BZHHkYk8xYowtCbFQc+Jv5TQqnS0kOUEquP9Jfj5x4dmvoap/u2ELZ3Hay WECC0BLTejaVIEQw9z3mIXJ+oH6/6G/redtWej2jkLAe27UGFffTWcOH8mH8bQQT MJZtK5rW+j79uvsZHsAhvj6kpCNSuVow8SmLtHP0PRb+tM0qPnaEtGi2O2heiwtq DMfEtVXvyA0cea7QHSzjAs1ahG+1QiGCnSQ+s6EkOB+PozbRJppnjA0oM/6Al4a3 9HRMSwLnFYlxil+dzXOfCUR4U4wqjcaU/VPEFIUPheYlUcLRB6a5zP5JPtBRIb1G /8oQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=STz3GdKSIj/u5/+p4J10CA0Bswh0HWRR8oAKYUkK+ CU=; b=MxQFyLCxPfgafFvvdzPLEWzWYto4O4zwrIleELafSgnRwgdNb/ydGL3eV odGtb/nyjs++C7rG+aw8YdPTwtyZRP4RMtwcCusBfo5DtVDmDRHt8KCY403pgV1U emND/2Gb5bIDWjv6CmDBpoEmdcqqe0xnHz0xVeRrrhzmby4zoNFOsQsYb7n64ji+ IQw0n6yzwDFUIC7G717WfvvfYzLOAyp+0qeheUYM0nWOTSEQ2XxEjbgjEpDSauCk 7Q2k87eG4FALxSnBiFFfccFcpaH3iPuZeymoWh0fnRxY2wxeFIH5JRT2j+aPqCDH H/nSqXFrPwCzMwmt2s84Hx6yX1nKA==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduiedgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfofgr rhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenuc ffohhmrghinhepihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmthes lhhofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3B086E00A3; Tue,  5 Nov 2019 23:10:19 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1
Mime-Version: 1.0
Message-Id: <118e630a-3f04-4aa9-8c1f-8083194865e4@www.fastmail.com>
In-Reply-To: 
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com> 
Date: Wed, 06 Nov 2019 15:09:59 +1100
From: "Martin Thomson" 
To: "David Schinazi" 
Cc: "tsvwg IETF list" , "saag@ietf.org" 
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [saag]  =?utf-8?q?=5Btsvwg=5D_Comments_on_draft-ietf-tsvwg-transp?= =?utf-8?q?ort-encrypt-08=2Etxt?=
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Nov 2019 04:10:23 -0000

I just read this document.  tl;dr, I agree with David, but I'd like to p=
rovide rationale in long-form.


The introductory material is largely quite good.  Though I found it to b=
e a little long-winded and a bit repetitious, the thesis it sets up is a=
n oft-repeated theme of recent discussion: encryption has these benefits=
, but increased deployment of encryption affects certain existing practi=
ces.  Add text on ossification.  In the abstract, that's all non-controv=
ersial.  The risk that this is a repetition of RFC8404 is tempered by th=
e prospect that this document might include a more detailed analysis of =
transport-level mechanisms.

However, the remainder of the document says something different.  In rea=
ding Ekr's review here, I thought that might be through implication, but=
 I found that it was far more direct.  There is an assumption throughout=
 that the listed practices are privileged and therefore deserving of pro=
tection.  No attempt is made to acknowledge that some of these practices=
 are can be harmful in various ways.  No recognition is given to the pos=
sibility that involving endpoints might offer alternative methods toward=
 the same ends.  This is perhaps exemplified in the conclusion, which st=
ates:

> An increased pace of evolution therefore needs to be accompanied by me=
thods that can be successfully deployed and used across operational netw=
orks.

And:

> Protocols that change their transport header format (wire image) or th=
eir behaviour (e.g., algorithms that are needed to classify and characte=
rise the protocol), will require new network tooling to be developed to =
catch-up with each change. =20

The use of "needs" and "will" in these statements is emblematic of the t=
heme that carries throughout this conclusion and - to a lesser extent - =
the preceding sections: the document clearly states that these goals are=
 important and stresses the importance of finding replacements.  For ins=
tance, I don't think it is appropriate for an on-path box to reset a flo=
w that doesn't conform to some ideal (S3.2.4).  If I were to state the r=
equirement for a network operator it would be that it be possible to ide=
ntify and isolate sources of traffic that are consuming disproportionate=
 amounts of resources.  That might avoid any implication that the networ=
k operator be able to measure goodput (S3.1.2), for instance.

End-to-middle and middle-to-end signaling is something this organization=
 has repeatedly attempted to tackle.  It's a hard problem.  Success has =
been patchy.  Though we might debate relative success, successful signal=
s are few in number.  This document contains a direct and specific plea.=


It is possible that this problem could be addressed by adding water unti=
l this skew is sufficiently diluted.  Sadly, the homeopathic approach we=
 took with RFC 8404 failed.  The IETF ended up publishing an RFC in the =
absence of consensus.  I don't see that tactic being any more effective =
in this case.  The catalogue of techniques here is somewhat interesting,=
 even if it is now outdated as Bernard suggests.  A document with the ri=
ght framing might work, but that would omit any conclusion other than th=
e one that says that these techniques are approaching extinction.  Thoug=
h that might be a shame in some ways - the loss of the ability to conduc=
t research in some ways is a loss - those are the facts on the ground.

As this is a document that intends to represent consensus, I have to opp=
ose publication on the grounds that it includes an ask I disagree with. =
 I assert that it would be better to concentrate on building those signa=
ls, even if it is one hard-earned bit at a time.  For instance, let's se=
e how ECN and spin work out in QUIC.


On Wed, Nov 6, 2019, at 09:10, David Schinazi wrote:
> I also oppose publication of draft-ietf-tsvwg-transport-encrypt. This=20=

> document discourages transport header encryption and publishing it=20
> could harm future protocol development.
>=20
> David
>=20
> On Tue, Nov 5, 2019 at 1:04 PM Joe Touch  wrote:=

> >=20
> >=20
> >  > On Nov 5, 2019, at 12:35 PM, Mirja Kuehlewind  wrote:
> >  >=20
> >  > What I=E2=80=99m hearing is that 2-3 people think this is not ali=
gned but don=E2=80=99t actually say why exactly they think that
> >=20
> >  That=E2=80=99s not what we=E2=80=99re saying. We gave reasons.=20
> >=20
> >  Joe=20
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>


From nobody Tue Nov  5 23:14:34 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE9D120048; Tue,  5 Nov 2019 23:14:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYsO9mHZ2sar; Tue,  5 Nov 2019 23:14:25 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130040.outbound.protection.outlook.com [40.107.13.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C800120026; Tue,  5 Nov 2019 23:14:24 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f64JUjoVHHZEWR90x6paV8J/bPojQgik43yKsZrVcvsDIU6zFo35dEt4CsHW0y8dzbsIobP2ktOJDUCJiI8MD7cOoD7hlrwzNfB03fLrfEUYk0vi02deAhC4u+TCM0RKDl01NDhTCvH3djYOEMb9U7JiVln9MlNKZsz0mOv9cWh0D/k/hPZwsmW3v7ycFffQvxuDMqvzpn+I6g29xrsDXYE5VpFZT3u8BUUezF1UAlXoK3pX9KOOYh6+dmDKB7aKkedwA0UgttBZdpipOZF4PBmvYRTS9HIS59hMlx9lVNC5XEYQEOZTGEQzTifyTChtMA7+USs4ZnwZTTw+QOxXHw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4XmKcUg2mxCimKXL1oPc3nBptNo6J6v3ayoNns1cYb8=; b=V/QfJmpd89N0tXMqHjU8U3U60U60lVz0XcKOg04pmvisk5u3hsSME2r4RSkBRxDH1x6yNaIDBQHcpWU7TEGG5hhNH9Mpa5nsds++ygoZ0tZTWF5sWe43Pl0LU18co8ghJ2G8KQYZLWf//BSxOni0zV2rrxOYWX4eoBaXlomiLQfqwuHXHI7wDVCKU0fMA+4peTaMV0MZI3Sz7FrnU+Z7dnF5wpim7TwGFioLJ2fXttd+UHlXVXT0WKPU4L4uR/uIT37T40W5aXbmdy7G5UlX85qvxCQla5+BYd16iDtRxzZckPL8EdB7XBrD2eKnE4b5nuqPBYXyu6v9LSi/q7bdPw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4XmKcUg2mxCimKXL1oPc3nBptNo6J6v3ayoNns1cYb8=; b=e9g5DgPz95QIJtDkWndel5YSqkElLWbbGl0s0kwByVLtHWFSG1FvBNvzD8GK6+ZzCZhL6BPk0X23vLUuaFjAqb+m7M4dqb3L2FpVP/Nv0g7chQMXgS55KbFQS4GkmgTDuKUmB4pGQnytTXIx7Ek8u5mjGwh5h9muUcCG1g8vxcY=
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB6324.eurprd07.prod.outlook.com (10.186.173.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Wed, 6 Nov 2019 07:14:21 +0000
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4189:4ef8:bfc1:ec58]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4189:4ef8:bfc1:ec58%7]) with mapi id 15.20.2430.014; Wed, 6 Nov 2019 07:14:21 +0000
From: Mirja Kuehlewind 
To: David Schinazi 
CC: Joe Touch , "gorry@erg.abdn.ac.uk" , Christian Huitema , tsvwg IETF list , "saag@ietf.org" 
Thread-Topic: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
Thread-Index: AQHVky08JY2FDXmr60OAsbMwFkv5fad7STQAgAAVH4CAAaI6gIAABbcAgAAET4CAAAgqgIAAEnwAgACYCgA=
Date: Wed, 6 Nov 2019 07:14:20 +0000
Message-ID: <9687A3AC-870A-46E1-BD2A-7041410CFF75@ericsson.com>
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mirja.kuehlewind@ericsson.com; 
x-originating-ip: [109.41.192.8]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 83f4c8d5-dea7-4fdb-4460-08d76288f1ee
x-ms-traffictypediagnostic: AM0PR07MB6324:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 02135EB356
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(136003)(366004)(346002)(376002)(189003)(199004)(6486002)(36756003)(66946007)(99936001)(25786009)(14444005)(256004)(6506007)(6436002)(102836004)(486006)(76176011)(33656002)(2616005)(53546011)(4326008)(476003)(11346002)(44832011)(5660300002)(6916009)(316002)(54906003)(446003)(6246003)(236005)(14454004)(7736002)(6512007)(478600001)(3846002)(81166006)(8676002)(81156014)(54896002)(2906002)(6116002)(8936002)(66066001)(86362001)(229853002)(186003)(99286004)(26005)(76116006)(66476007)(66556008)(64756008)(66446008)(66616009)(71190400001)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB6324; H:AM0PR07MB4691.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: WuXA3L+00CFbcwk/959ePrG7Wg5FFoZHHuamb8C47/wtp99GZ+363TxkyrtuSlMucI0hUlg5cRGj3yNR4tOaFCj0Z4h/+ZOlSxq8VXMlSbQ4bGJNHnd6MLsFp0RYPHFXs+YwjtCvCHL3jY/omS5srLuoRKMjtNkipAhmCSEcpJ70Vh2aE4dqdRTKAaKcZLl9WdvYA4CslS/g8dUzIXvabHCbrmgxJ8ucBSSWHXVa4hhRJiNeJC5RBVxJ9LMchvRNko/Uq8UrapuNiPoBu+Q6VH6FFepCmZeheJ+t1tA8aNeMoVptGsNpsEvqkRwGMKdj2rvb3GnEJs7WNwN8tbW2wZPQOaLjWPcyCtSFA5nOyK3GHR4FIQTrCMmnR8+3FgnXDtiKR4/Go2NoNs7rZboZEOnAgdI1jXNQLfPdqVGuKELBBLztvFYrav4y3ic3iboX
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; boundary=Apple-Mail-06D53EA6-F6E8-40A3-A362-2D2E998E81BB; protocol="application/pkcs7-signature"; micalg=sha-256
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 83f4c8d5-dea7-4fdb-4460-08d76288f1ee
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 07:14:20.9823 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: i3edS0aorAqF5xgSRESN2HYuTN9nZe14yQuk/Xe8wJcBI7WIoiDCBUXR36Q1wDvwZU2MLMusgThMqZYknDy6bNVGcUHLuYza6K1k6BX87MU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6324
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Nov 2019 07:14:27 -0000

--Apple-Mail-06D53EA6-F6E8-40A3-A362-2D2E998E81BB
Content-Type: multipart/alternative;
	boundary=Apple-Mail-EBEE305A-0A42-42D7-AACA-BE56DCC7CC67
Content-Transfer-Encoding: 7bit


--Apple-Mail-EBEE305A-0A42-42D7-AACA-BE56DCC7CC67
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: base64

SGkgRGF2aWQsDQoNClRoaXMgZG9jdW1lbnQgaXMgbm90IGludGVuZGVkIHRvIGRpc2NvdXJhZ2Ug
aGVhZGVyIGVuY3J5cHRpb24gYnV0IHRvIG1ha2Ugc3VyZSB0aGF0IG9wZXJhdGlvbmFsIGNvbnNp
ZGVyYXRpb25zIGFyZSB0YWtlbiBpbnRvIGFjY291bnQgd2hlbiBleGFjdGx5IGRlc2lnbiBuZXcg
cHJvdG9jb2xzIHRoYXQgc2hvdWxkIGhhdmUgaGVhZGVyIGVuY3J5cHRpb24gKGFzIHdlbGwgYXMg
cGF5bG9hZCBlbmNyeXB0aW9uKS4gSWYgeW91IHRoaW5rIHRoaXMgZG9jdW1lbnQgZGlzY291cmFn
ZXMgaGVhZGVyIGVuY3J5cHRpb24sIHdlIG5lZWQgdG8gZml4IHRoYXQuIFdvdWxkIGJlIGhlbHBm
dWwgaWYgeW91IGNvdWxkIGluZGljYXRlIHRvIHRoZSBhdXRob3JzIHdoZXJlIHlvdSB0aGluayB0
aGlzIGlzIHRoZSBjYXNlLg0KDQpNaXJqYQ0KDQoNCj4gQW0gMDUuMTEuMjAxOSB1bSAyMzoxMCBz
Y2hyaWViIERhdmlkIFNjaGluYXppIDxkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb20+Og0KPiANCj4g
SSBhbHNvIG9wcG9zZSBwdWJsaWNhdGlvbiBvZiBkcmFmdC1pZXRmLXRzdndnLXRyYW5zcG9ydC1l
bmNyeXB0LiBUaGlzIGRvY3VtZW50IGRpc2NvdXJhZ2VzIHRyYW5zcG9ydCBoZWFkZXIgZW5jcnlw
dGlvbiBhbmQgcHVibGlzaGluZyBpdCBjb3VsZCBoYXJtIGZ1dHVyZSBwcm90b2NvbCBkZXZlbG9w
bWVudC4NCj4gDQo+IERhdmlkDQo+IA0KPj4gT24gVHVlLCBOb3YgNSwgMjAxOSBhdCAxOjA0IFBN
IEpvZSBUb3VjaCA8dG91Y2hAc3RyYXlhbHBoYS5jb20+IHdyb3RlOg0KPj4gDQo+PiANCj4+ID4g
T24gTm92IDUsIDIwMTksIGF0IDEyOjM1IFBNLCBNaXJqYSBLdWVobGV3aW5kIDxtaXJqYS5rdWVo
bGV3aW5kPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPiB3cm90ZToNCj4+ID4gDQo+PiA+
IFdoYXQgSeKAmW0gaGVhcmluZyBpcyB0aGF0IDItMyBwZW9wbGUgdGhpbmsgdGhpcyBpcyBub3Qg
YWxpZ25lZCBidXQgZG9u4oCZdCBhY3R1YWxseSBzYXkgd2h5IGV4YWN0bHkgdGhleSB0aGluayB0
aGF0DQo+PiANCj4+IFRoYXTigJlzIG5vdCB3aGF0IHdl4oCZcmUgc2F5aW5nLiBXZSBnYXZlIHJl
YXNvbnMuIA0KPj4gDQo+PiBKb2UgDQo=

--Apple-Mail-EBEE305A-0A42-42D7-AACA-BE56DCC7CC67
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXYgZGlyPSJs
dHIiPjwvZGl2PjxkaXYgZGlyPSJsdHIiPkhpIERhdmlkLDwvZGl2PjxkaXYgZGlyPSJsdHIiPjxi
cj48L2Rpdj48ZGl2IGRpcj0ibHRyIj5UaGlzIGRvY3VtZW50IGlzIG5vdCBpbnRlbmRlZCB0byBk
aXNjb3VyYWdlIGhlYWRlciBlbmNyeXB0aW9uIGJ1dCB0byBtYWtlIHN1cmUgdGhhdCBvcGVyYXRp
b25hbCBjb25zaWRlcmF0aW9ucyBhcmUgdGFrZW4gaW50byBhY2NvdW50IHdoZW4gZXhhY3RseSBk
ZXNpZ24gbmV3IHByb3RvY29scyB0aGF0IHNob3VsZCBoYXZlIGhlYWRlciBlbmNyeXB0aW9uIChh
cyB3ZWxsIGFzIHBheWxvYWQgZW5jcnlwdGlvbikuIElmIHlvdSB0aGluayB0aGlzIGRvY3VtZW50
IGRpc2NvdXJhZ2VzIGhlYWRlciBlbmNyeXB0aW9uLCB3ZSBuZWVkIHRvIGZpeCB0aGF0LiBXb3Vs
ZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBpbmRpY2F0ZSB0byB0aGUgYXV0aG9ycyB3aGVyZSB5
b3UgdGhpbmsgdGhpcyBpcyB0aGUgY2FzZS48L2Rpdj48ZGl2IGRpcj0ibHRyIj48YnI+PC9kaXY+
PGRpdiBkaXI9Imx0ciI+TWlyamE8L2Rpdj48ZGl2IGRpcj0ibHRyIj48YnI+PC9kaXY+PGRpdiBk
aXI9Imx0ciI+PGJyPkFtIDA1LjExLjIwMTkgdW0gMjM6MTAgc2NocmllYiBEYXZpZCBTY2hpbmF6
aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbSI+ZHNjaGluYXpp
LmlldGZAZ21haWwuY29tPC9hPiZndDs6PGJyPjxicj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJj
aXRlIj48ZGl2IGRpcj0ibHRyIj48bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRl
bnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+PGRpdiBkaXI9Imx0ciI+SSBhbHNvIG9wcG9z
ZSBwdWJsaWNhdGlvbiBvZiZuYnNwO2RyYWZ0LWlldGYtdHN2d2ctdHJhbnNwb3J0LWVuY3J5cHQu
IFRoaXMgZG9jdW1lbnQgZGlzY291cmFnZXMgdHJhbnNwb3J0IGhlYWRlciBlbmNyeXB0aW9uIGFu
ZCBwdWJsaXNoaW5nIGl0IGNvdWxkIGhhcm0gZnV0dXJlIHByb3RvY29sIGRldmVsb3BtZW50Ljxk
aXY+PGJyPjwvZGl2PjxkaXY+RGF2aWQ8L2Rpdj48L2Rpdj48YnI+PGRpdiBjbGFzcz0iZ21haWxf
cXVvdGUiPjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBUdWUsIE5vdiA1LCAy
MDE5IGF0IDE6MDQgUE0gSm9lIFRvdWNoICZsdDs8YSBocmVmPSJtYWlsdG86dG91Y2hAc3RyYXlh
bHBoYS5jb20iPnRvdWNoQHN0cmF5YWxwaGEuY29tPC9hPiZndDsgd3JvdGU6PGJyPjwvZGl2Pjxi
bG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAw
LjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6
MWV4Ij48YnI+DQo8YnI+DQomZ3Q7IE9uIE5vdiA1LCAyMDE5LCBhdCAxMjozNSBQTSwgTWlyamEg
S3VlaGxld2luZCAmbHQ7bWlyamEua3VlaGxld2luZD08YSBocmVmPSJtYWlsdG86NDBlcmljc3Nv
bi5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGVyaWNzc29uLmNvbUBkbWFy
Yy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBXaGF0IEnigJlt
IGhlYXJpbmcgaXMgdGhhdCAyLTMgcGVvcGxlIHRoaW5rIHRoaXMgaXMgbm90IGFsaWduZWQgYnV0
IGRvbuKAmXQgYWN0dWFsbHkgc2F5IHdoeSBleGFjdGx5IHRoZXkgdGhpbmsgdGhhdDxicj4NCjxi
cj4NClRoYXTigJlzIG5vdCB3aGF0IHdl4oCZcmUgc2F5aW5nLiBXZSBnYXZlIHJlYXNvbnMuIDxi
cj4NCjxicj4NCkpvZSA8YnI+DQo8L2Jsb2NrcXVvdGU+PC9kaXY+DQo8L2Rpdj48L2Jsb2NrcXVv
dGU+PC9ib2R5PjwvaHRtbD4=

--Apple-Mail-EBEE305A-0A42-42D7-AACA-BE56DCC7CC67--

--Apple-Mail-06D53EA6-F6E8-40A3-A362-2D2E998E81BB
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDM0w
ggYDMIID66ADAgECAg8BaU6kmW/78jyVZPgb4ikwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMC
U0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENB
IHYzMB4XDTE5MDMwNTE2MTY0M1oXDTIyMDMwNTE2MTY0MlowbjERMA8GA1UECgwIRXJpY3Nzb24x
GTAXBgNVBAMMEE1pcmphIEt1ZWhsZXdpbmQxEDAOBgNVBAUTB2VraGxtcmoxLDAqBgkqhkiG9w0B
CQEWHW1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAzbEm7ACaZBiLCo5AMLb1pe7+qin+EDW/6F5OkuzBE5awAB0DcYPCPnVmvKTjByQE
wXfcv4GpesID1ZoIIw9yvE3JS3e0G9EESbDD/P1dEsvUbfKzqbiogFjxPTcO5393z+S6/lZhh1HE
Xzn5eN4rqXaphkOdt235jtuXr9p9hCXTbk2s2u+Q+UBBsJfDZFnupphfgSJdO2ZDIr54posGTI29
o2Z8Yp0kXGUdReJYhB3U7IyusRfGGlabLLSEb405hQyckqhCqnNDBqgw8s2kCsvCV5vvsU4HxRQB
h6TAo+Qowd5LjjhUb5pWjDzNBw9HDCuv50t6JuUbToV4VodAyQIDAQABo4IBwzCCAb8wHwYDVR0j
BBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwHQYDVR0OBBYEFOS9IY8huUonCxTez1fXbiljN+tp
MA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIB
FixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAoBgNVHREEITAf
gR1taXJqYS5rdWVobGV3aW5kQGVyaWNzc29uLmNvbTBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8v
Y3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMB0GA1UdJQQW
MBQGCCsGAQUFBwMEBggrBgEFBQcDAjCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRw
Oi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVs
aWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwDQYJKoZIhvcNAQELBQAD
ggIBAEifFgbyma9dHCxsY3R0wp+4sjcmAiEvA3S0YKJl7SBd897BV8O/Nq6z6QCx2zKTpfia7bF5
Yzou0/2PS2qX/2TXRsgGKRhWmYyBsiAvKmuEeA9t/3NZOImicaYCn2WVu3tfFE8lnXlH+O/sMRdU
gq7yMusDm9YDO6urKezkh6IZrLWIyz4s4Uy2SMyXc2ujvB0doUB26+ld070A0x+isDjY3of/23Yg
4xAvr5AK5sQtq+0D7tRUlPefXrA1bI/PDEZiq5Bvqa9tfyd7HPlhzHhrQAS5t42fybMpwdGxLvjH
XME5fPB0xRH5kchOawsd2BPSv2ZVWt9WYGDbkAgEtCW37zNwdzX5ix43f8C0TRU5AiU531gObLbr
KWZyhLRurGlwtSqvmGCyCiTN3jhzjVTAM3uiLosG2SZbyq5ZFWI7MezHM1owAQvm0sOEEfXp88nc
Xa7SxkwiJr/UH6P3pRADsVC55HoQVS1GydEBnDBNAyIcnsM7sPbkGF92F7U16PWpJYQaZbVd2Vkj
FahNN9uWbn55A/daE+QiF2QcfCVnFOSj9ah1ke6M3MahqcqkJpXoUizv8DwiKXGkKOiLB3x8pqSr
cCUQ5Pjt3wFjPCuVJ7AoiBYP2GmXAyEXtYeh0nVlKQuVtloCpsyR5bumbOoQf/r6FoUY/xgh8/pg
pOMiMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYD
VQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEw
MjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv
bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEB
BQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6V
iqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1l
VtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV
2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTS
uG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvA
l7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQg
YFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8
s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3W
LJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e
6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzAB
hiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9y
ZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjAS
BgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUH
AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwRE
MEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFy
b290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIB
BjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV
6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1A
soZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46g
zKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQG
pieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+L
Faaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOr
MGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5Qxib
XqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6
PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfY
PGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/
HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICyjCCAsYCAQEwWjBHMQswCQYDVQQGEwJTRTER
MA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMC
DwFpTqSZb/vyPJVk+BviKTANBglghkgBZQMEAgEFAKCCAUEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkxMTA2MDcxNDIwWjAvBgkqhkiG9w0BCQQxIgQgW8e8JFGH
McYrBNBvromY7pQ45qP8cVru7+9DuT/9EBUwaQYJKwYBBAGCNxAEMVwwWjBHMQswCQYDVQQGEwJT
RTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0Eg
djMCDwFpTqSZb/vyPJVk+BviKTBrBgsqhkiG9w0BCRACCzFcoFowRzELMAkGA1UEBhMCU0UxETAP
BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8B
aU6kmW/78jyVZPgb4ikwDQYJKoZIhvcNAQEBBQAEggEAQIxDwY6rZrSUhwe/B7nVQd5LU3qxKz5d
Pqnyg5HvX8/Vs1Tlib1hkSkb+Bt6m8UczRgIU2AvNYcFiqSgN3eB2xTN+do9bbXRoqsa7rvvuQo1
OEL+jJv+woh6b8DNeceWB4tZkpo3XdDNbELLxGasVpcBksoXfuJlaJ6+cHH+BpWn69vgAsP7+zve
UUvEslXBOg6OrR4bOXTJI3wgjOfO6jPSVVKxCkWuVwFqDOPBwmMswIQhXiWcjI5lD9EPcN2IEk4C
jziba9GpaMDOjHVuRQCiYwn37h6+W5HaMWAqOYgvAAdIXxB+hl8nnuYPhaHF2PbVo49g5cRwvLcj
jsSp2AAAAAAAAA==

--Apple-Mail-06D53EA6-F6E8-40A3-A362-2D2E998E81BB--


From nobody Tue Nov  5 23:32:14 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675F912004F; Tue,  5 Nov 2019 23:32:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id colDHN_BtQQO; Tue,  5 Nov 2019 23:32:09 -0800 (PST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140081.outbound.protection.outlook.com [40.107.14.81]) (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 10FD5120024; Tue,  5 Nov 2019 23:32:08 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EDLHys/+IlTV+YSzzMAMfrbvCYW1ZOxoBx1GKgSS0+2dzGgAlzwgL/Wpi0SI5W2RFc1Hkmtf67FArjoHI7fhLGl9ESz/Vm7OZIRzwt1wKDvsSM8fl7dy5/GKrwPE9XDvl7d6jK6RauMgOtleIFZbSlSjvyTgJe+cChZ0luBifoqj7qDZ1r+ijtwCWPgGu4/3aFVAS5ccH3XWw2xoN8kzgDalgH6Y9LaxpG4bbxvAxXfiZ4AiHyawBJ3WEz7/u64t+IaH0GsuJ2Q+tmPO8mXYrBqd0ppxH4x6eCJ8v+0s8B6VOQyRcvhPQsjonQ7+0lnljKbdsRDGdQavu1mOauBcfw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qdnpiWaz7r4xK0EbQ8IkgElo2FCNd3M4ltQyKamVnA4=; b=ADR9cP1SOHMqUb+sCRb00nnX8QV49Ebjl9pn94+QpD+qE1IwhNyU6Os3rD+mQXbtNcvo4dKfiKdqNE0/EvAF/WbAJmSvxIHZMrb04z3k5PFDpOpSS3veWgMo7L6yEtLeI3al6elo+BKutCSu1il1/0zJJ/BU07eytrAVBcgtomAKrvC1/SRAKGbg9heF8yToT/XWTy4ORl7BYpBnxQR7JOqgBICxoO9kzBJeM6GWU9HsauTCbztfTasIDMrApY1AA+y2Vo+0GjTkdmgTlJNv+t2BSCgFqMvcDAdH6oobNcV7pOVbJzv6bIRU0BOsdNduacjLr5sAtrwpjhZGQ//Xow==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qdnpiWaz7r4xK0EbQ8IkgElo2FCNd3M4ltQyKamVnA4=; b=qw2mw4HcljJe5nviGc+jlnDx0kY1RMptXK9YpH3hs915b8fUjNKC0PVuWxr4DSQUZMfIJDLJpKwpw4MjFSkdEB4zbHeQI4r99RhENvEtcvpq0S3XNnWdDlXCZKqQc0djt6iabAiOoYb3ATRvxfjK4J2/KdsUN3LzGivOW0nUyfI=
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB5665.eurprd07.prod.outlook.com (20.178.115.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Wed, 6 Nov 2019 07:32:05 +0000
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4189:4ef8:bfc1:ec58]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4189:4ef8:bfc1:ec58%7]) with mapi id 15.20.2430.014; Wed, 6 Nov 2019 07:32:05 +0000
From: Mirja Kuehlewind 
To: Martin Thomson 
CC: David Schinazi , tsvwg IETF list , "saag@ietf.org" 
Thread-Topic: [tsvwg]  [saag]  Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
Thread-Index: AQHVlFgnDgpdd/GtUkWp5DmTXAsvvKd9v+EA
Date: Wed, 6 Nov 2019 07:32:05 +0000
Message-ID: <9EC2E60F-6044-4135-A802-1665028E6075@ericsson.com>
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com>  <118e630a-3f04-4aa9-8c1f-8083194865e4@www.fastmail.com>
In-Reply-To: <118e630a-3f04-4aa9-8c1f-8083194865e4@www.fastmail.com>
Accept-Language: en-US
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mirja.kuehlewind@ericsson.com; 
x-originating-ip: [109.41.192.8]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 14ee8c58-969f-4930-4dc1-08d7628b6c73
x-ms-traffictypediagnostic: AM0PR07MB5665:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02135EB356
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(39860400002)(396003)(376002)(366004)(199004)(189003)(256004)(8936002)(54906003)(966005)(229853002)(316002)(8676002)(81166006)(71190400001)(6486002)(486006)(11346002)(478600001)(446003)(99286004)(476003)(71200400001)(36756003)(2616005)(5660300002)(6436002)(76176011)(26005)(44832011)(53546011)(76116006)(66616009)(66476007)(6506007)(66556008)(66446008)(64756008)(102836004)(25786009)(186003)(6246003)(6512007)(6306002)(14454004)(66946007)(7736002)(305945005)(6916009)(66066001)(4326008)(86362001)(81156014)(6116002)(99936001)(3846002)(33656002)(2906002)(14444005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB5665; H:AM0PR07MB4691.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 3XK8cYyu4xLwTEHlt9cZGxzv9UFewNujchXIIkRpk+ZSwXb7xImtxhBsCjplo7P3P5fzFWAYVDeJjGMMBSJQS6lExYcSpHeT/o+OqrE37h9aEmH5xwX8oJHzz4KV4mf+XmF90+nkYcKnRCBEuIJaMMs1elzfC5n1LuQJ+nL41x5o9GUIPATfWCtZOjToXlDDLQYBY6XdFsJatgnbAIe1GkXNoQMniuoMEf1kSvlx7DKrREdFjMpf+bxPiHgcig3WaGEUUorjZJwEl1HyFbpZA07NChlgrX8zMOt9ojTwPKaIYV4Fks9ruaQ0nnKat8RCxpJXfm28lOh8Itcd4BaZcoldybxyWlRLZE8S79CKo/9RyDx+ipqGRnub97mAohhpOY4T+l1yEf0fe846i/Ykpqf6KJgKgywmRIrOEOsSn/r/cSwKwPWIEquXEB4LtT3j
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; boundary=Apple-Mail-B8302B21-684B-4D2A-8029-B3CBCC5F30F7; protocol="application/pkcs7-signature"; micalg=sha-256
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 14ee8c58-969f-4930-4dc1-08d7628b6c73
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 07:32:05.4437 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: JlDlFnq829q7k+mQvH/RhYtes0WRbQzh482dB9E5107Pd3HQWFbz3kUEotPxw2iOt7U+s2dUIyQdvhQbwRAkRnX/4YSF017tpcRr3tA3H5k=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5665
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Nov 2019 07:32:12 -0000

--Apple-Mail-B8302B21-684B-4D2A-8029-B3CBCC5F30F7
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: base64

SGkgTWFydGluLA0KDQpUaGFua3MgZm9yIHlvdXIgbW9yZSBlbGFib3JhdGVkIHJldmlldy4gSSBk
b27igJl0IHRoaW5rIHRoZXJlIHdhcyBhbiBpbnRlbnRpb24gaW4gdGhlIGRvY3VtZW50IHRvIHNh
eSB0aGF0IOKAnmxpc3RlZCBwcmFjdGljZXMgYXJlIHByaXZpbGVnZWQgYW5kIHRoZXJlZm9yZSBk
ZXNlcnZpbmcgb2YgcHJvdGVjdGlvbuKAnCBidXQgSSBjYW4gc2VlIGhvdyB5b3UgY291bGQgcmVh
ZCBpdCB0aGlzIHdheS4gSSB0aGluayB0aGUgaW50ZW50aW9uIHdhcyB0byByYXRoZXIgbm90IG1h
a2UgYSBqdWRnZW1lbnQgaWYgdGhlc2UgcHJhY3RpY2VzIGFyZSDigJ5nb29k4oCcIG9yIOKAnmJh
ZOKAnCBiZWNhdXNlIHRoZSBhc3N1bXB0aW9uIHdhcyB0aGF0IGl0IHdvdWxkIGJlIGV2ZW4gaGFy
ZGVyIHRvIGZpbmQgY29uc2Vuc3VzIG9uIHRoYXQgYnV0IEkgYWdyZWUgdGhhdCB0aGUgZG9jdW1l
bnQgY291bGQgYXQgbGVhc3QgZXhwbGljaXRseSBzdGF0ZSB0aGF0IHRoZXNlIHByYWN0aWNlcyBh
cmUgbm90IGVuZG9yc2VkIGFuZCBub3QgYWxsIG9mIHRoZW0gYXJlIHNlZW4gYXMgd29ydGggc3Vw
cG9ydGluZyBpbiBmdXR1cmUgb3IgYW55IHdheSBkZXNpcmFibGUuDQoNCkhvd2V2ZXIgSSBzdGls
bCB0aGluayBpdCBpcyBpbXBvcnRhbnQgdG8gZG9jdW1lbnQgY3VycmVudCBwcmFjdGljZXMgYW5k
IHNwZWxsIG91dCBpbXBsaWNhdGlvbiB0aGF0IGNoYW5nZXMgaW4gdGhlIFRyYW5zcG9ydCBMYXll
ciBjYW4gaGF2ZS4gIEkgYWxzbyBhZ3JlZSB0aGF0IHRoZSBkb2N1bWVudCBnb3QgYSBiaXQgcmVk
dW5kYW50IGluIHRoZSBtZWFuIHRpbWUgYW5kIHNvbWUgb2YgdGhlIOKAnmNvdWxk4oCcIGFuZCDi
gJ5taWdodOKAnCBtaWdodCBhY3R1YWxseSBnbyB0b28gZmFyIGJleW9uZCB0aGUgZ29hbCBvZiBk
b2N1bWVudGF0aW9uLiANCg0KVGhlIGRvY3VtZW50IHdhcyBpbml0aWFsbHkgbm90IGludGVudCB0
byB0YWxrIGFib3V0IHBvdGVudGlhbCBzb2x1dGlvbnMgb3IgZnV0dXJlIGFwcHJvYWNoZXMgdG8g
YWRkcmVzcyBkZXNpcmVkIGltcGxpY2F0aW9ucyB0aGF0IGhhdmUgYmVlbiBpZGVudGlmaWVkLiBI
b3dldmVyIHRoZXJlIHdhcyBxdWl0ZSBhIGJpdCBvZiBmZWVkYmFjayB0aGF0IHRoZSBkb2N1bWVu
dCBzaG91bGQgZ28gb25lIHN0ZXAgZnVydGhlci4gV2UgY291bGQgcmVjb25zaWRlciB0aGlzIGFw
cHJvYWNoIGJ1dCBJIGFjdHVhbGx5IHRoaW5rIHRoZSBkb2N1bWVudCBkb2VzIGEgZ29vZCBqb2Ig
bGlzdGluZyBwb3RlbnRpYWwgb3B0aW9uIHRvIG1vdmUgZm9yd2FyZC4gSSBob3BlIHRoaXMgZG9j
dW1lbnQgY2FuIHByb3ZpZGUgYSBjb21tb24gYmFzaXMgZm9yIHVuZGVyc3RhbmRpbmcgcHJvYmxl
bXMgYW5kIHRoZXJlZm9yZSBkZXNpZ24gd29yayB0aGUgaWV0ZiBtaWdodCBkbyBpbiBmdXR1cmUg
aW4gdGhpcyBzcGFjZS4gSG93ZXZlciB0aGUgZ29hbCByaWdodCBub3cgaXMgcmVhbGx5IGRvY3Vt
ZW50YXRpb24gYW5kIG5vdCBtYWtpbmcgZGVzaWduIGRlY2lzaW9ucy4gDQoNCk1pcmphDQoNCg0K
PiBBbSAwNi4xMS4yMDE5IHVtIDA1OjEwIHNjaHJpZWIgTWFydGluIFRob21zb24gPG10QGxvd2Vu
dHJvcHkubmV0PjoNCj4gDQo+IEkganVzdCByZWFkIHRoaXMgZG9jdW1lbnQuICB0bDtkciwgSSBh
Z3JlZSB3aXRoIERhdmlkLCBidXQgSSdkIGxpa2UgdG8gcHJvdmlkZSByYXRpb25hbGUgaW4gbG9u
Zy1mb3JtLg0KPiANCj4gDQo+IFRoZSBpbnRyb2R1Y3RvcnkgbWF0ZXJpYWwgaXMgbGFyZ2VseSBx
dWl0ZSBnb29kLiAgVGhvdWdoIEkgZm91bmQgaXQgdG8gYmUgYSBsaXR0bGUgbG9uZy13aW5kZWQg
YW5kIGEgYml0IHJlcGV0aXRpb3VzLCB0aGUgdGhlc2lzIGl0IHNldHMgdXAgaXMgYW4gb2Z0LXJl
cGVhdGVkIHRoZW1lIG9mIHJlY2VudCBkaXNjdXNzaW9uOiBlbmNyeXB0aW9uIGhhcyB0aGVzZSBi
ZW5lZml0cywgYnV0IGluY3JlYXNlZCBkZXBsb3ltZW50IG9mIGVuY3J5cHRpb24gYWZmZWN0cyBj
ZXJ0YWluIGV4aXN0aW5nIHByYWN0aWNlcy4gIEFkZCB0ZXh0IG9uIG9zc2lmaWNhdGlvbi4gIElu
IHRoZSBhYnN0cmFjdCwgdGhhdCdzIGFsbCBub24tY29udHJvdmVyc2lhbC4gIFRoZSByaXNrIHRo
YXQgdGhpcyBpcyBhIHJlcGV0aXRpb24gb2YgUkZDODQwNCBpcyB0ZW1wZXJlZCBieSB0aGUgcHJv
c3BlY3QgdGhhdCB0aGlzIGRvY3VtZW50IG1pZ2h0IGluY2x1ZGUgYSBtb3JlIGRldGFpbGVkIGFu
YWx5c2lzIG9mIHRyYW5zcG9ydC1sZXZlbCBtZWNoYW5pc21zLg0KPiANCj4gSG93ZXZlciwgdGhl
IHJlbWFpbmRlciBvZiB0aGUgZG9jdW1lbnQgc2F5cyBzb21ldGhpbmcgZGlmZmVyZW50LiAgSW4g
cmVhZGluZyBFa3IncyByZXZpZXcgaGVyZSwgSSB0aG91Z2h0IHRoYXQgbWlnaHQgYmUgdGhyb3Vn
aCBpbXBsaWNhdGlvbiwgYnV0IEkgZm91bmQgdGhhdCBpdCB3YXMgZmFyIG1vcmUgZGlyZWN0LiAg
VGhlcmUgaXMgYW4gYXNzdW1wdGlvbiB0aHJvdWdob3V0IHRoYXQgdGhlIGxpc3RlZCBwcmFjdGlj
ZXMgYXJlIHByaXZpbGVnZWQgYW5kIHRoZXJlZm9yZSBkZXNlcnZpbmcgb2YgcHJvdGVjdGlvbi4g
IE5vIGF0dGVtcHQgaXMgbWFkZSB0byBhY2tub3dsZWRnZSB0aGF0IHNvbWUgb2YgdGhlc2UgcHJh
Y3RpY2VzIGFyZSBjYW4gYmUgaGFybWZ1bCBpbiB2YXJpb3VzIHdheXMuICBObyByZWNvZ25pdGlv
biBpcyBnaXZlbiB0byB0aGUgcG9zc2liaWxpdHkgdGhhdCBpbnZvbHZpbmcgZW5kcG9pbnRzIG1p
Z2h0IG9mZmVyIGFsdGVybmF0aXZlIG1ldGhvZHMgdG93YXJkIHRoZSBzYW1lIGVuZHMuICBUaGlz
IGlzIHBlcmhhcHMgZXhlbXBsaWZpZWQgaW4gdGhlIGNvbmNsdXNpb24sIHdoaWNoIHN0YXRlczoN
Cj4gDQo+PiBBbiBpbmNyZWFzZWQgcGFjZSBvZiBldm9sdXRpb24gdGhlcmVmb3JlIG5lZWRzIHRv
IGJlIGFjY29tcGFuaWVkIGJ5IG1ldGhvZHMgdGhhdCBjYW4gYmUgc3VjY2Vzc2Z1bGx5IGRlcGxv
eWVkIGFuZCB1c2VkIGFjcm9zcyBvcGVyYXRpb25hbCBuZXR3b3Jrcy4NCj4gDQo+IEFuZDoNCj4g
DQo+PiBQcm90b2NvbHMgdGhhdCBjaGFuZ2UgdGhlaXIgdHJhbnNwb3J0IGhlYWRlciBmb3JtYXQg
KHdpcmUgaW1hZ2UpIG9yIHRoZWlyIGJlaGF2aW91ciAoZS5nLiwgYWxnb3JpdGhtcyB0aGF0IGFy
ZSBuZWVkZWQgdG8gY2xhc3NpZnkgYW5kIGNoYXJhY3RlcmlzZSB0aGUgcHJvdG9jb2wpLCB3aWxs
IHJlcXVpcmUgbmV3IG5ldHdvcmsgdG9vbGluZyB0byBiZSBkZXZlbG9wZWQgdG8gY2F0Y2gtdXAg
d2l0aCBlYWNoIGNoYW5nZS4gIA0KPiANCj4gVGhlIHVzZSBvZiAibmVlZHMiIGFuZCAid2lsbCIg
aW4gdGhlc2Ugc3RhdGVtZW50cyBpcyBlbWJsZW1hdGljIG9mIHRoZSB0aGVtZSB0aGF0IGNhcnJp
ZXMgdGhyb3VnaG91dCB0aGlzIGNvbmNsdXNpb24gYW5kIC0gdG8gYSBsZXNzZXIgZXh0ZW50IC0g
dGhlIHByZWNlZGluZyBzZWN0aW9uczogdGhlIGRvY3VtZW50IGNsZWFybHkgc3RhdGVzIHRoYXQg
dGhlc2UgZ29hbHMgYXJlIGltcG9ydGFudCBhbmQgc3RyZXNzZXMgdGhlIGltcG9ydGFuY2Ugb2Yg
ZmluZGluZyByZXBsYWNlbWVudHMuICBGb3IgaW5zdGFuY2UsIEkgZG9uJ3QgdGhpbmsgaXQgaXMg
YXBwcm9wcmlhdGUgZm9yIGFuIG9uLXBhdGggYm94IHRvIHJlc2V0IGEgZmxvdyB0aGF0IGRvZXNu
J3QgY29uZm9ybSB0byBzb21lIGlkZWFsIChTMy4yLjQpLiAgSWYgSSB3ZXJlIHRvIHN0YXRlIHRo
ZSByZXF1aXJlbWVudCBmb3IgYSBuZXR3b3JrIG9wZXJhdG9yIGl0IHdvdWxkIGJlIHRoYXQgaXQg
YmUgcG9zc2libGUgdG8gaWRlbnRpZnkgYW5kIGlzb2xhdGUgc291cmNlcyBvZiB0cmFmZmljIHRo
YXQgYXJlIGNvbnN1bWluZyBkaXNwcm9wb3J0aW9uYXRlIGFtb3VudHMgb2YgcmVzb3VyY2VzLiAg
VGhhdCBtaWdodCBhdm9pZCBhbnkgaW1wbGljYXRpb24gdGhhdCB0aGUgbmV0d29yayBvcGVyYXRv
ciBiZSBhYmxlIHRvIG1lYXN1cmUgZ29vZHB1dCAoUzMuMS4yKSwgZm9yIGluc3RhbmNlLg0KPiAN
Cj4gRW5kLXRvLW1pZGRsZSBhbmQgbWlkZGxlLXRvLWVuZCBzaWduYWxpbmcgaXMgc29tZXRoaW5n
IHRoaXMgb3JnYW5pemF0aW9uIGhhcyByZXBlYXRlZGx5IGF0dGVtcHRlZCB0byB0YWNrbGUuICBJ
dCdzIGEgaGFyZCBwcm9ibGVtLiAgU3VjY2VzcyBoYXMgYmVlbiBwYXRjaHkuICBUaG91Z2ggd2Ug
bWlnaHQgZGViYXRlIHJlbGF0aXZlIHN1Y2Nlc3MsIHN1Y2Nlc3NmdWwgc2lnbmFscyBhcmUgZmV3
IGluIG51bWJlci4gIFRoaXMgZG9jdW1lbnQgY29udGFpbnMgYSBkaXJlY3QgYW5kIHNwZWNpZmlj
IHBsZWEuDQo+IA0KPiBJdCBpcyBwb3NzaWJsZSB0aGF0IHRoaXMgcHJvYmxlbSBjb3VsZCBiZSBh
ZGRyZXNzZWQgYnkgYWRkaW5nIHdhdGVyIHVudGlsIHRoaXMgc2tldyBpcyBzdWZmaWNpZW50bHkg
ZGlsdXRlZC4gIFNhZGx5LCB0aGUgaG9tZW9wYXRoaWMgYXBwcm9hY2ggd2UgdG9vayB3aXRoIFJG
QyA4NDA0IGZhaWxlZC4gIFRoZSBJRVRGIGVuZGVkIHVwIHB1Ymxpc2hpbmcgYW4gUkZDIGluIHRo
ZSBhYnNlbmNlIG9mIGNvbnNlbnN1cy4gIEkgZG9uJ3Qgc2VlIHRoYXQgdGFjdGljIGJlaW5nIGFu
eSBtb3JlIGVmZmVjdGl2ZSBpbiB0aGlzIGNhc2UuICBUaGUgY2F0YWxvZ3VlIG9mIHRlY2huaXF1
ZXMgaGVyZSBpcyBzb21ld2hhdCBpbnRlcmVzdGluZywgZXZlbiBpZiBpdCBpcyBub3cgb3V0ZGF0
ZWQgYXMgQmVybmFyZCBzdWdnZXN0cy4gIEEgZG9jdW1lbnQgd2l0aCB0aGUgcmlnaHQgZnJhbWlu
ZyBtaWdodCB3b3JrLCBidXQgdGhhdCB3b3VsZCBvbWl0IGFueSBjb25jbHVzaW9uIG90aGVyIHRo
YW4gdGhlIG9uZSB0aGF0IHNheXMgdGhhdCB0aGVzZSB0ZWNobmlxdWVzIGFyZSBhcHByb2FjaGlu
ZyBleHRpbmN0aW9uLiAgVGhvdWdoIHRoYXQgbWlnaHQgYmUgYSBzaGFtZSBpbiBzb21lIHdheXMg
LSB0aGUgbG9zcyBvZiB0aGUgYWJpbGl0eSB0byBjb25kdWN0IHJlc2VhcmNoIGluIHNvbWUgd2F5
cyBpcyBhIGxvc3MgLSB0aG9zZSBhcmUgdGhlIGZhY3RzIG9uIHRoZSBncm91bmQuDQo+IA0KPiBB
cyB0aGlzIGlzIGEgZG9jdW1lbnQgdGhhdCBpbnRlbmRzIHRvIHJlcHJlc2VudCBjb25zZW5zdXMs
IEkgaGF2ZSB0byBvcHBvc2UgcHVibGljYXRpb24gb24gdGhlIGdyb3VuZHMgdGhhdCBpdCBpbmNs
dWRlcyBhbiBhc2sgSSBkaXNhZ3JlZSB3aXRoLiAgSSBhc3NlcnQgdGhhdCBpdCB3b3VsZCBiZSBi
ZXR0ZXIgdG8gY29uY2VudHJhdGUgb24gYnVpbGRpbmcgdGhvc2Ugc2lnbmFscywgZXZlbiBpZiBp
dCBpcyBvbmUgaGFyZC1lYXJuZWQgYml0IGF0IGEgdGltZS4gIEZvciBpbnN0YW5jZSwgbGV0J3Mg
c2VlIGhvdyBFQ04gYW5kIHNwaW4gd29yayBvdXQgaW4gUVVJQy4NCj4gDQo+IA0KPj4gT24gV2Vk
LCBOb3YgNiwgMjAxOSwgYXQgMDk6MTAsIERhdmlkIFNjaGluYXppIHdyb3RlOg0KPj4gSSBhbHNv
IG9wcG9zZSBwdWJsaWNhdGlvbiBvZiBkcmFmdC1pZXRmLXRzdndnLXRyYW5zcG9ydC1lbmNyeXB0
LiBUaGlzIA0KPj4gZG9jdW1lbnQgZGlzY291cmFnZXMgdHJhbnNwb3J0IGhlYWRlciBlbmNyeXB0
aW9uIGFuZCBwdWJsaXNoaW5nIGl0IA0KPj4gY291bGQgaGFybSBmdXR1cmUgcHJvdG9jb2wgZGV2
ZWxvcG1lbnQuDQo+PiANCj4+IERhdmlkDQo+PiANCj4+PiBPbiBUdWUsIE5vdiA1LCAyMDE5IGF0
IDE6MDQgUE0gSm9lIFRvdWNoIDx0b3VjaEBzdHJheWFscGhhLmNvbT4gd3JvdGU6DQo+Pj4gDQo+
Pj4gDQo+Pj4+IE9uIE5vdiA1LCAyMDE5LCBhdCAxMjozNSBQTSwgTWlyamEgS3VlaGxld2luZCA8
bWlyamEua3VlaGxld2luZD00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQo+
Pj4+IA0KPj4+PiBXaGF0IEnigJltIGhlYXJpbmcgaXMgdGhhdCAyLTMgcGVvcGxlIHRoaW5rIHRo
aXMgaXMgbm90IGFsaWduZWQgYnV0IGRvbuKAmXQgYWN0dWFsbHkgc2F5IHdoeSBleGFjdGx5IHRo
ZXkgdGhpbmsgdGhhdA0KPj4+IA0KPj4+IFRoYXTigJlzIG5vdCB3aGF0IHdl4oCZcmUgc2F5aW5n
LiBXZSBnYXZlIHJlYXNvbnMuIA0KPj4+IA0KPj4+IEpvZSANCj4+IF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzYWFnIG1haWxpbmcgbGlzdA0KPj4g
c2FhZ0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z
YWFnDQo+PiANCj4gDQo=

--Apple-Mail-B8302B21-684B-4D2A-8029-B3CBCC5F30F7
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDM0w
ggYDMIID66ADAgECAg8BaU6kmW/78jyVZPgb4ikwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMC
U0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENB
IHYzMB4XDTE5MDMwNTE2MTY0M1oXDTIyMDMwNTE2MTY0MlowbjERMA8GA1UECgwIRXJpY3Nzb24x
GTAXBgNVBAMMEE1pcmphIEt1ZWhsZXdpbmQxEDAOBgNVBAUTB2VraGxtcmoxLDAqBgkqhkiG9w0B
CQEWHW1pcmphLmt1ZWhsZXdpbmRAZXJpY3Nzb24uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAzbEm7ACaZBiLCo5AMLb1pe7+qin+EDW/6F5OkuzBE5awAB0DcYPCPnVmvKTjByQE
wXfcv4GpesID1ZoIIw9yvE3JS3e0G9EESbDD/P1dEsvUbfKzqbiogFjxPTcO5393z+S6/lZhh1HE
Xzn5eN4rqXaphkOdt235jtuXr9p9hCXTbk2s2u+Q+UBBsJfDZFnupphfgSJdO2ZDIr54posGTI29
o2Z8Yp0kXGUdReJYhB3U7IyusRfGGlabLLSEb405hQyckqhCqnNDBqgw8s2kCsvCV5vvsU4HxRQB
h6TAo+Qowd5LjjhUb5pWjDzNBw9HDCuv50t6JuUbToV4VodAyQIDAQABo4IBwzCCAb8wHwYDVR0j
BBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwHQYDVR0OBBYEFOS9IY8huUonCxTez1fXbiljN+tp
MA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIB
FixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAoBgNVHREEITAf
gR1taXJqYS5rdWVobGV3aW5kQGVyaWNzc29uLmNvbTBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8v
Y3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMB0GA1UdJQQW
MBQGCCsGAQUFBwMEBggrBgEFBQcDAjCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRw
Oi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVs
aWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwDQYJKoZIhvcNAQELBQAD
ggIBAEifFgbyma9dHCxsY3R0wp+4sjcmAiEvA3S0YKJl7SBd897BV8O/Nq6z6QCx2zKTpfia7bF5
Yzou0/2PS2qX/2TXRsgGKRhWmYyBsiAvKmuEeA9t/3NZOImicaYCn2WVu3tfFE8lnXlH+O/sMRdU
gq7yMusDm9YDO6urKezkh6IZrLWIyz4s4Uy2SMyXc2ujvB0doUB26+ld070A0x+isDjY3of/23Yg
4xAvr5AK5sQtq+0D7tRUlPefXrA1bI/PDEZiq5Bvqa9tfyd7HPlhzHhrQAS5t42fybMpwdGxLvjH
XME5fPB0xRH5kchOawsd2BPSv2ZVWt9WYGDbkAgEtCW37zNwdzX5ix43f8C0TRU5AiU531gObLbr
KWZyhLRurGlwtSqvmGCyCiTN3jhzjVTAM3uiLosG2SZbyq5ZFWI7MezHM1owAQvm0sOEEfXp88nc
Xa7SxkwiJr/UH6P3pRADsVC55HoQVS1GydEBnDBNAyIcnsM7sPbkGF92F7U16PWpJYQaZbVd2Vkj
FahNN9uWbn55A/daE+QiF2QcfCVnFOSj9ah1ke6M3MahqcqkJpXoUizv8DwiKXGkKOiLB3x8pqSr
cCUQ5Pjt3wFjPCuVJ7AoiBYP2GmXAyEXtYeh0nVlKQuVtloCpsyR5bumbOoQf/r6FoUY/xgh8/pg
pOMiMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYD
VQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEw
MjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv
bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEB
BQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6V
iqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1l
VtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV
2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTS
uG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvA
l7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQg
YFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8
s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3W
LJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e
6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzAB
hiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9y
ZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjAS
BgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUH
AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwRE
MEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFy
b290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIB
BjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV
6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1A
soZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46g
zKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQG
pieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+L
Faaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOr
MGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5Qxib
XqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6
PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfY
PGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/
HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICyjCCAsYCAQEwWjBHMQswCQYDVQQGEwJTRTER
MA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMC
DwFpTqSZb/vyPJVk+BviKTANBglghkgBZQMEAgEFAKCCAUEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkxMTA2MDczMjA0WjAvBgkqhkiG9w0BCQQxIgQgbfTV6oRu
4FPUwoxByJHO/a8letDsa9vePMsFhhfMDvswaQYJKwYBBAGCNxAEMVwwWjBHMQswCQYDVQQGEwJT
RTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0Eg
djMCDwFpTqSZb/vyPJVk+BviKTBrBgsqhkiG9w0BCRACCzFcoFowRzELMAkGA1UEBhMCU0UxETAP
BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8B
aU6kmW/78jyVZPgb4ikwDQYJKoZIhvcNAQEBBQAEggEAVKgCCOgipxo+v5A9LrAYnwetGLreSPyh
Xu7wgdXB2ub5IsybPRPdepTcUFv1cy4T+alEUMW8+dt+y+zzY0TeVrGrf9BpC982301erCx6D3Ze
jEmWSPaMspxd1/2mU3b7RSt9CMj4z09DZxd6AjwDzvHQwBEcT45ls7mmf/zHrlpLOcUm7dFpVoEv
93VLFpJ9CKqosB+h0OiB2oE94BQyu6HTEa3oy57r36PNIZIZyDk65uxPmjU9/TI4QOsL1vsteddr
AujOgojKqFdm8TpYaE6ahnc/hV1JjyJ1e5MoqISMHdWVpmWgIfUfjZP4IDaTp4mMd45YN2mxCE3Z
hnWZ9wAAAAAAAA==

--Apple-Mail-B8302B21-684B-4D2A-8029-B3CBCC5F30F7--


From nobody Wed Nov  6 01:13:21 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D66120129; Wed,  6 Nov 2019 01:13:19 -0800 (PST)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tele.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 lgTpo41R54QS; Wed,  6 Nov 2019 01:13:17 -0800 (PST)
Received: from gorgon.tele.no (gorgon.tele.no [IPv6:2001:700:800::70]) (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 4F6AC120125; Wed,  6 Nov 2019 01:13:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tele.no; s=20180731; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Agu656NfNDbGIrPOcDaxZS/52ER+N23/icqhznLOASA=; b=kFkcSbMyrVJUVtwog+1bBFCaxR gTYTGgYAwFTflsPBMCwADn1FemGa4RLyfzr1dWc2EW1lteNH7UWAq4DLNFqrji3AQJvdsc/YgSl0u c++YpeZHig7NrFPCRhTjr/SyNEOtPeVTYEnk6iABrx7Lpw4W8/uXkZwX5fsXN8kPstJtEbalQyvZw BIFyW62GYK0Eby9L2nBsWlTL3Ag6DvRGxtn3KmdhFoahUbRQ6zXj0gX6WZAf42C+1mO53ASFzXpJb rl7YzLQzkwvPZZ7gnDRWH00cVdRO+Jo0GCDU6EUqf1kBiAbZevBsfNjjZsUXbh0719znAS5PIoCPl 72RJN/Eg==;
Received: from pilt1.tele.no ([2001:700:800::20] helo=[IPv6:::1]) by gorgon.tele.no with esmtp (Exim 4.92) (envelope-from ) id 1iSHNK-0000zc-81; Wed, 06 Nov 2019 10:13:14 +0100
To: Martin Thomson 
Cc: tsvwg IETF list , "saag@ietf.org" 
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com>  <118e630a-3f04-4aa9-8c1f-8083194865e4@www.fastmail.com>
From: Frode Kileng 
Message-ID: <443cd271-cfae-37ff-7e33-d85d108e17f4@tele.no>
Date: Wed, 6 Nov 2019 10:13:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <118e630a-3f04-4aa9-8c1f-8083194865e4@www.fastmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Nov 2019 09:13:20 -0000

Being involved in discussions in operator communities wrt. "implications 
of encryption" for  years, the following statement from Martin 
summarizes why I also do not support publication of this draft:

On 06/11/2019 05:09, Martin Thomson wrote:
> There is an assumption throughout that the listed practices are privileged and therefore deserving of protection.  No attempt is made to acknowledge that some of these practices are can be harmful in various ways.  No recognition is given to the possibility that involving endpoints might offer alternative methods toward the same ends.

To this list I wold also add a lack of qualification of a perceived 
usefulness and some quantification of how common the practices are.

frodek


From nobody Wed Nov  6 01:58:57 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C456120813; Wed,  6 Nov 2019 01:58:55 -0800 (PST)
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=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Toaxuk_KQrJt; Wed,  6 Nov 2019 01:58:53 -0800 (PST)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960F3120810; Wed,  6 Nov 2019 01:58:53 -0800 (PST)
Received: from [82.132.236.15] (port=44821 helo=[172.20.10.5]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iSI5S-0007kd-Ic; Wed, 06 Nov 2019 09:58:50 +0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Colin Perkins 
In-Reply-To: <9EC2E60F-6044-4135-A802-1665028E6075@ericsson.com>
Date: Wed, 6 Nov 2019 09:58:39 +0000
Cc: Martin Thomson , tsvwg IETF list , "saag@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <54B33418-28D8-4176-A2EE-29FF27E5CE44@csperkins.org>
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com>  <118e630a-3f04-4aa9-8c1f-8083194865e4@www.fastmail.com> <9EC2E60F-6044-4135-A802-1665028E6075@ericsson.com>
To: Mirja Kuehlewind 
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 4
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Nov 2019 09:58:55 -0000

> On 6 Nov 2019, at 07:32, Mirja Kuehlewind =
 wrote:
>=20
> Hi Martin,
>=20
> Thanks for your more elaborated review. I don=E2=80=99t think there =
was an intention in the document to say that =E2=80=9Elisted practices =
are privileged and therefore deserving of protection=E2=80=9C but I can =
see how you could read it this way. I think the intention was to rather =
not make a judgement if these practices are =E2=80=9Egood=E2=80=9C or =
=E2=80=9Ebad=E2=80=9C because the assumption was that it would be even =
harder to find consensus on that but I agree that the document could at =
least explicitly state that these practices are not endorsed and not all =
of them are seen as worth supporting in future or any way desirable.

It certainly wasn=E2=80=99t my intent with this draft to say that all =
these practices should be kept; rather to stimulate the discussion about =
what should be preserved, what it=E2=80=99s necessary to find =
alternatives for; etc. If this doesn=E2=80=99t come across clearly in =
the draft. we should fix it.=20

> However I still think it is important to document current practices =
and spell out implication that changes in the Transport Layer can have.  =
I also agree that the document got a bit redundant in the mean time and =
some of the =E2=80=9Ecould=E2=80=9C and =E2=80=9Emight=E2=80=9C might =
actually go too far beyond the goal of documentation.=20
>=20
> The document was initially not intent to talk about potential =
solutions or future approaches to address desired implications that have =
been identified. However there was quite a bit of feedback that the =
document should go one step further. We could reconsider this approach =
but I actually think the document does a good job listing potential =
option to move forward. I hope this document can provide a common basis =
for understanding problems and therefore design work the ietf might do =
in future in this space. However the goal right now is really =
documentation and not making design decisions.=20

Exactly.
Colin



> Mirja
>=20
>=20
>> Am 06.11.2019 um 05:10 schrieb Martin Thomson :
>>=20
>> I just read this document.  tl;dr, I agree with David, but I'd like =
to provide rationale in long-form.
>>=20
>>=20
>> The introductory material is largely quite good.  Though I found it =
to be a little long-winded and a bit repetitious, the thesis it sets up =
is an oft-repeated theme of recent discussion: encryption has these =
benefits, but increased deployment of encryption affects certain =
existing practices.  Add text on ossification.  In the abstract, that's =
all non-controversial.  The risk that this is a repetition of RFC8404 is =
tempered by the prospect that this document might include a more =
detailed analysis of transport-level mechanisms.
>>=20
>> However, the remainder of the document says something different.  In =
reading Ekr's review here, I thought that might be through implication, =
but I found that it was far more direct.  There is an assumption =
throughout that the listed practices are privileged and therefore =
deserving of protection.  No attempt is made to acknowledge that some of =
these practices are can be harmful in various ways.  No recognition is =
given to the possibility that involving endpoints might offer =
alternative methods toward the same ends.  This is perhaps exemplified =
in the conclusion, which states:
>>=20
>>> An increased pace of evolution therefore needs to be accompanied by =
methods that can be successfully deployed and used across operational =
networks.
>>=20
>> And:
>>=20
>>> Protocols that change their transport header format (wire image) or =
their behaviour (e.g., algorithms that are needed to classify and =
characterise the protocol), will require new network tooling to be =
developed to catch-up with each change. =20
>>=20
>> The use of "needs" and "will" in these statements is emblematic of =
the theme that carries throughout this conclusion and - to a lesser =
extent - the preceding sections: the document clearly states that these =
goals are important and stresses the importance of finding replacements. =
 For instance, I don't think it is appropriate for an on-path box to =
reset a flow that doesn't conform to some ideal (S3.2.4).  If I were to =
state the requirement for a network operator it would be that it be =
possible to identify and isolate sources of traffic that are consuming =
disproportionate amounts of resources.  That might avoid any implication =
that the network operator be able to measure goodput (S3.1.2), for =
instance.
>>=20
>> End-to-middle and middle-to-end signaling is something this =
organization has repeatedly attempted to tackle.  It's a hard problem.  =
Success has been patchy.  Though we might debate relative success, =
successful signals are few in number.  This document contains a direct =
and specific plea.
>>=20
>> It is possible that this problem could be addressed by adding water =
until this skew is sufficiently diluted.  Sadly, the homeopathic =
approach we took with RFC 8404 failed.  The IETF ended up publishing an =
RFC in the absence of consensus.  I don't see that tactic being any more =
effective in this case.  The catalogue of techniques here is somewhat =
interesting, even if it is now outdated as Bernard suggests.  A document =
with the right framing might work, but that would omit any conclusion =
other than the one that says that these techniques are approaching =
extinction.  Though that might be a shame in some ways - the loss of the =
ability to conduct research in some ways is a loss - those are the facts =
on the ground.
>>=20
>> As this is a document that intends to represent consensus, I have to =
oppose publication on the grounds that it includes an ask I disagree =
with.  I assert that it would be better to concentrate on building those =
signals, even if it is one hard-earned bit at a time.  For instance, =
let's see how ECN and spin work out in QUIC.
>>=20
>>=20
>>> On Wed, Nov 6, 2019, at 09:10, David Schinazi wrote:
>>> I also oppose publication of draft-ietf-tsvwg-transport-encrypt. =
This=20
>>> document discourages transport header encryption and publishing it=20=

>>> could harm future protocol development.
>>>=20
>>> David
>>>=20
>>>> On Tue, Nov 5, 2019 at 1:04 PM Joe Touch  =
wrote:
>>>>=20
>>>>=20
>>>>> On Nov 5, 2019, at 12:35 PM, Mirja Kuehlewind =
 wrote:
>>>>>=20
>>>>> What I=E2=80=99m hearing is that 2-3 people think this is not =
aligned but don=E2=80=99t actually say why exactly they think that
>>>>=20
>>>> That=E2=80=99s not what we=E2=80=99re saying. We gave reasons.=20
>>>>=20
>>>> Joe=20
>>> _______________________________________________
>>> saag mailing list
>>> saag@ietf.org
>>> https://www.ietf.org/mailman/listinfo/saag
>>>=20
>>=20



--=20
Colin Perkins
https://csperkins.org/





From nobody Wed Nov  6 02:11:46 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861B9120835; Wed,  6 Nov 2019 02:11:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
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 osI2B5UgLGiJ; Wed,  6 Nov 2019 02:11:35 -0800 (PST)
Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 E54B4120829; Wed,  6 Nov 2019 02:11:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1573035095; x=1604571095; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+sQXlU9sg8AwhUefQMqAGRaapk7UG4EzQHi5oVNGOgc=; b=N1ab8kwoG+LY37atgq8R3QksUEjDfJxi3fiYD1qya1HtW8XLlVXfe+hg HiAEoJbIOW0z+FYv6Dinx45VRmtBWKnqpmOchfWSaF5YzltYzwkAQPac1 aQIJY1uAcNXTTvj90H/UMcq+Niyxg3YLyfMbvrk0LRl2O1EcOZQn9WFX/ KLAoya9usLmYh9A98lmAYJDM5avL6v1FMC63ETCOoXLhi58ukCQ+sztPo pS4fPbvzrf2YMYwiB9TAW8BTeVck+52XSJQHNgroXgsfEAK6ibPeh3Xmq FMf4RHlsDR6iUlezPHFViJmgpkvaEU+96vV5M6FQj7y+CRvFPDwxbd1h5 A==;
X-IronPort-AV: E=Sophos;i="5.68,274,1569240000"; d="scan'208";a="98362132"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.3.4 - Outgoing - Outgoing
Received: from uxcn13-tdc-c.uoa.auckland.ac.nz ([10.6.3.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 06 Nov 2019 23:11:32 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 6 Nov 2019 23:11:32 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Wed, 6 Nov 2019 23:11:32 +1300
From: Peter Gutmann 
To: David Schinazi , Joe Touch 
CC: "gorry@erg.abdn.ac.uk" , Mirja Kuehlewind , tsvwg IETF list , "saag@ietf.org" 
Thread-Topic: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
Thread-Index: AQHVkyCjrwMtocCjZ0izavTli3wJVKd6WcIAgAAVngCAAARbAIABsv2AgAAFtwCAAARPgIAACCuAgAASewCAAaJ3cA==
Date: Wed, 6 Nov 2019 10:11:31 +0000
Message-ID: <1573035094775.62307@cs.auckland.ac.nz>
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com>, 
In-Reply-To: 
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Nov 2019 10:11:38 -0000

David Schinazi  writes:=0A=
=0A=
>I also oppose publication of draft-ietf-tsvwg-transport-encrypt. This=0A=
>document discourages transport header encryption and publishing it could h=
arm=0A=
>future protocol development.=0A=
=0A=
More than any other comment, this one seems to sum up the real opposition t=
o=0A=
publication of this document:=0A=
=0A=
  This document conflicts with my political agenda, so it cannot be allowed=
 to=0A=
  be published.=0A=
=0A=
It's a well-written discussion of issues that need to be taken into account=
=0A=
when considering header encryption.  Taking the "lalalalala-I'm-not-listeni=
ng-=0A=
lalalala" approach won't make these issues go away, it just means that they=
'll=0A=
come and bite implementers and deployers of header-encryption protocols=0A=
because the document that would have discussed them in order to allow them =
to=0A=
be addressed at the design stage before they became a problem was suppresse=
d.=0A=
=0A=
May I instead rephrase the above objection slightly to:=0A=
=0A=
  I also support publication of draft-ietf-tsvwg-transport-encrypt.  This=
=0A=
  document points out real issues that need to be taken into consideration=
=0A=
  when encrypting headers, and not publishing it will harm future protocol=
=0A=
  development.=0A=
=0A=
Peter.=


From nobody Wed Nov  6 08:24:00 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A043120C4F; Wed,  6 Nov 2019 08:23:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.965
X-Spam-Level: 
X-Spam-Status: No, score=-0.965 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, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 XvrIbhxrnb0c; Wed,  6 Nov 2019 08:23:29 -0800 (PST)
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 5E9B2120CE8; Wed,  6 Nov 2019 08:23:22 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 728DBBE51; Wed,  6 Nov 2019 16:23:20 +0000 (GMT)
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 gtpWcNcrtDQZ; Wed,  6 Nov 2019 16:23:19 +0000 (GMT)
Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DE6E0BE47; Wed,  6 Nov 2019 16:23:18 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1573057399; bh=TwLUVBjZDKs4gfyu9OVvhtqr3QHUCqmcw0cZqtJUGdc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=McKDcGptg+684W6qgcES7/ocC4DiMEWHRlsTZJ79o5GVUZBcqolaJKtLeM/NO5qOi 1M9n0C3LHA5HnsuFCN3OOk3vJlPVGqo6P2yktIIMjL2KHHpXHH9NINHfaHKej+w0Y+ rSFxEXcGC+AXn2vYliMmpj2VRrq2i1JQ42ouZdVo=
To: Peter Gutmann , David Schinazi , Joe Touch 
Cc: "gorry@erg.abdn.ac.uk" , Mirja Kuehlewind , tsvwg IETF list , "saag@ietf.org" 
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com>  <1573035094775.62307@cs.auckland.ac.nz>
From: Stephen Farrell 
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <87d3bcef-42e4-1535-db1f-06a8408d38d5@cs.tcd.ie>
Date: Wed, 6 Nov 2019 16:23:17 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2
MIME-Version: 1.0
In-Reply-To: <1573035094775.62307@cs.auckland.ac.nz>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="R3Ca9IEuMX5WYyCFHKLSaznr14K4Ah49q"
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Nov 2019 16:23:32 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--R3Ca9IEuMX5WYyCFHKLSaznr14K4Ah49q
Content-Type: multipart/mixed; boundary="K9Eyhuli6nGlCgn8YBDVJn8xbDB5jkihw";
 protected-headers="v1"
From: Stephen Farrell 
To: Peter Gutmann ,
 David Schinazi , Joe Touch 
Cc: "gorry@erg.abdn.ac.uk" ,
 Mirja Kuehlewind ,
 tsvwg IETF list , "saag@ietf.org" 
Message-ID: <87d3bcef-42e4-1535-db1f-06a8408d38d5@cs.tcd.ie>
Subject: Re: [saag] [tsvwg] Comments on
 draft-ietf-tsvwg-transport-encrypt-08.txt
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com>
 <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com>
 
 <1573035094775.62307@cs.auckland.ac.nz>
In-Reply-To: <1573035094775.62307@cs.auckland.ac.nz>

--K9Eyhuli6nGlCgn8YBDVJn8xbDB5jkihw
Content-Type: multipart/mixed;
 boundary="------------0170C8555003E18A7726FD4C"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------0170C8555003E18A7726FD4C
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 06/11/2019 10:11, Peter Gutmann wrote:
>=20
> It's a well-written discussion of issues that need to be taken into acc=
ount
> when considering header encryption.

FWIW, I don't agree that this is (yet) sufficiently well
written. I generally agree with Martin T's criticism of
the way things are described.

In addition, the document is missing any real description
of the harmful ways in which cleartext headers are being
(ab)used today. I believe I raised this point on draft-05,
and the authors' response was that it'd be too hard to
include that. (IIRC for sorta understandable reasons that
I mostly forget;-)

=46rom my POV, that means that the text (not the authors,
the text) is biased against encrypting headers as it has
to end up having loads of text about why encrypting is
perceived as bad by some and almost no text on why not
encrypting is perceived as bad by some.

I do think the text is fixable, but suspect getting that
done will require a lot of work, given the precedent of
RFC8404. I'm unconvinced that is the best way for those
who choose to be involved to spend their IETF cycles.

Cheers,
S.

PS: I did skim the version before last, but haven't read
the latest. I do plan to do so sometime, so I might have
other comments too later on.


--------------0170C8555003E18A7726FD4C
Content-Type: application/pgp-keys;
 name="0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem
CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT
q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE
gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy
+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5
iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9
to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV
B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5
FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK
7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t
lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB
tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9
UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG
CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk
rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr
sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ
sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG
nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk
d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG
FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV
N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v
ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv
tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9
UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok
Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm
uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT
AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ
IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5
DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X
CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq
Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h
cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp
MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB
ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ
yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V
4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy
I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv
X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg
2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc
/MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu
4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8
pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh
jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm
bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6
+uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh
5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K
LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv
8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5
6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB
g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs
QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC
HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO
M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP
2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s
/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj
Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k
4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl
AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg
vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r
wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o
4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA
xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd
8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6
NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc
Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY
tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1
WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E
DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv
e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK
CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP
GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT
MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9
gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX
ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF
L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D
Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb
hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M
SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt
GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA
5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+
ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb
tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/
l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX
4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo
7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj
CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR
Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg
Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx
mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88
zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2
EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI
z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr
Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB
4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF
CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl
vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk
bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB
p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE
5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3
berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL
3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy
ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R
WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc
EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI
6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h
qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y
BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1
n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq
hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw
2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY
m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T
5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB
LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H
Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S
oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06
TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs
0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk
mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9
M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo
DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK
BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0
H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO
JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh
B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB
KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48
ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw
nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool
sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ
lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws
4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd
AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY
zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk
rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04
fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N
kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+
FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8
AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB
BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt
tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg
evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7
vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB
HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD
8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M
sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE
4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb
TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3
vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm
oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r
+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f
Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7
Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1
gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF
6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd
n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25
2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN
JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw
rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs
okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY
o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk
d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU
yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk
vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3
YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST
=3DYzQY
-----END PGP PUBLIC KEY BLOCK-----

--------------0170C8555003E18A7726FD4C--

--K9Eyhuli6nGlCgn8YBDVJn8xbDB5jkihw--

--R3Ca9IEuMX5WYyCFHKLSaznr14K4Ah49q
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl3C83UACgkQWrL68XsX
K+pjhg//ZHt07nLDhsbcpCLrlWMumnCRP/rGX9WnKjdlyk4xHko7CEpdaQ2qZDTE
JRYwTxSdNsoouL7aKsugTbaWquCes7m29oOM7CRxSZqWRZZHF+CS5UxOLpw4jlJ8
26/WsYpyC1sT2XNxQar7wSXZyA/EMizS8d1dEA+Xqn0MKGLgmAuImaWkftuP/M2f
9OFMmmSQPM5iu811ZJ5Iyim/i+4KH70yvOA2mmZVL2O5Kfjhc/FJ7EQLqpHiThk1
2U0fpgguXKvl8jqhirdq1VbtA3XN+BlLkkvWD/ykQ4zk2bx8tgFdvJq1CYTo8xab
zsiukeWvbNvt5+Qw5WCw41GFwHCHbrg54BNTGkU7Aok5LzqBskNRt8qijITk6BP6
jNclrWZCAOoeAz8KztcDW/xAKpB7FOf5L2/CyE2IIgKR+Zsiz4Eegypy8SUb+Bsl
v02X1zWhxQ5Ki4BqMN55ssogKR8CW4Qx6PrrqUK8B9x0rP2HchGUEbSl1wmYI+Nc
WlkLjG5g+RwtMVXuLdSE+d4+mK3Qh62PbKH+L4TI2lkfxR2R4/abb8jmWH2Kgj5e
IeyoR4oQ6GwkRXWRsYNdhcy0uWlA5aeO9OFJOYKZe80ZUVmP4BMkkvA/Q73AvmA8
98kU9CoZY+/xje5gGeIaqsrqDpcfFJK3twNDuIebLZI378tvYSc=
=9j5n
-----END PGP SIGNATURE-----

--R3Ca9IEuMX5WYyCFHKLSaznr14K4Ah49q--


From nobody Wed Nov  6 08:40:58 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A16612000F; Mon,  4 Nov 2019 17:44:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level: 
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
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 pzfhV7cqoDPA; Mon,  4 Nov 2019 17:44:13 -0800 (PST)
Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 824ED120033; Mon,  4 Nov 2019 17:44:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1572918253; x=1604454253; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=v06AubMYBI63No/+e/4pe+PhkbntGMz4rHlASP9wNeM=; b=2xabdLa9qfvut/zf7AT+nTf5CUMW7z9HbSQcMt1v8Vmh8U+koBo6y5+Q 88WSVWiMMMnynXWG20k7DWfQWMmnA7IjW3hR1b6XYoThAYKYgVPDlY0zN m/XRjbrFC68I72d0Dzo6JgVrwgtnfNufGOFEL673h63Vo5Rugs8wfUds8 vmqXcFPvCwIfrsuu0GG4b51e5WKjKSqf4NqDayn5VYQct1qzDnSvxmIUU CAoEdgXD11i0Vj/BlhvU1GyECBUcSrZXbVv2aJSMbYUBUZkVwnbNs/pt1 SiZA3R5XWSTObpHhgGHw2SWi7a9o0SPGfyCVh+MTufz36VxuC9JVWV4VR g==;
X-IronPort-AV: E=Sophos; i="5.68,269,1569240000"; d="scan'208,217"; a="98116100"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing
Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-ogg-a.UoA.auckland.ac.nz) ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 05 Nov 2019 14:44:07 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.2) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 5 Nov 2019 14:44:06 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Tue, 5 Nov 2019 14:44:06 +1300
From: Peter Gutmann 
To: "emile.stephan@orange.com" , "Gorry Fairhurst (gorry@erg.abdn.ac.uk)" , tsvwg-chairs , "Black, David" 
CC: "tsvwg@ietf.org" , "IETF IPPM WG (ippm@ietf.org)" , "etosat@ietf.org" , "saag@ietf.org" , "opsawg@ietf.org" , "quic@ietf.org" 
Thread-Topic: TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
Thread-Index: AdV+HJIZhebOrRcXTIK6bGArgFWweQEbzmAgAfqMkPACQR0OKQ==
Date: Tue, 5 Nov 2019 01:44:06 +0000
Message-ID: <1572918247420.10381@cs.auckland.ac.nz>
References:  ,  <4460_1571933453_5DB1CD0D_4460_57_4_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931F030A0@OPEXCAUBM44.corporate.adroot.infra.ftgroup>
In-Reply-To: <4460_1571933453_5DB1CD0D_4460_57_4_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931F030A0@OPEXCAUBM44.corporate.adroot.infra.ftgroup>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: multipart/alternative; boundary="_000_157291824742010381csaucklandacnz_"
MIME-Version: 1.0
Archived-At: 
X-Mailman-Approved-At: Wed, 06 Nov 2019 08:40:57 -0800
Subject: Re: [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Nov 2019 01:44:15 -0000

--_000_157291824742010381csaucklandacnz_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I actually think it's a pretty good summary, and delivers exactly what's
promised in the title.  OTOH I can also see that it's going to get bikeshed=
ded
to death, and will probably never be editable into a form where people won'=
t
complain about it no matter how many changes are made.  Alternatively, it'l=
l
end up watered down to a point where no-one can complain any more but it wo=
n't
say anything terribly useful by then.

Perhaps it could be published as is with a comment that it represents the
opinions of the authors?  Although given that it's Informational and not
Standards-track or a BCP, that should be a given anyway.

Peter.




--_000_157291824742010381csaucklandacnz_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










I actually think it's a pretty good summary, and delivers exactly what=
's


promised in the title.  OTOH I can also see that it's going to ge=
t bikeshedded


to death, and will probably never be editable into a form where people=
 won't


complain about it no matter how many changes are made.  Alternati=
vely, it'll


end up watered down to a point where no-one can complain any more but =
it won't


say anything terribly useful by then.







Perhaps it could be published as is with a comment that it represents =
the


opinions of the authors?  Although given that it's Informational =
and not


Standards-track or a BCP, that should be a given anyway.







Peter.
















--_000_157291824742010381csaucklandacnz_--


From nobody Wed Nov  6 08:41:07 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3744112008C for ; Mon,  4 Nov 2019 18:35:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQnavWef9S-f for ; Mon,  4 Nov 2019 18:35:36 -0800 (PST)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 4F51C12004D for ; Mon,  4 Nov 2019 18:35:36 -0800 (PST)
Received: by mail-lf1-x12e.google.com with SMTP id y127so13830617lfc.0 for ; Mon, 04 Nov 2019 18:35:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6CtuZCErZWIlvQlP8U6/r+0Lss1CXFNRNhLUvq7R2Ic=; b=v0xuM26HjUUO6khZ657q+fbTvZTtG6aDQPn1Mh5XoW49sv1BjcmLL99ZpsLq72uX0t S2CctrWm1OHMs7VbZmymFdy+y0RfE3RnpGBO9QAqfrl8wzG2L0p+C18gBneffCNMoqsO E8hwevX7wk/TMw2hJ2saA5RyFfjDgkhabeLfebfpGtBNCNGLVCT1JuM8GYiR5YYORmWN c2w8fcQG6bGdU9f4ql74WnUqLlpIVLPlsxYVqzJ6AWOGzEXZccw9gwm+vJm5upZGXgrF n3diCtJJKwBr9QUh2HfcB945cWhThm68nsxnJyg8NlJdxbMjSma0qjfa+K8mbwMT1d44 79/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6CtuZCErZWIlvQlP8U6/r+0Lss1CXFNRNhLUvq7R2Ic=; b=d7Y2sDn+q5L6Gi9YVifiCZvQ3nlL3SOD1LXzNNfGSCFosJ3a7OYxv7bEAHVPwh9FGS rCIyM1CleXizkwYEQP7/kvzjM/JNmPkft07JMhBDoQ7SvcVvCB8R0dB9JdzfPyb10q9B RnL1GwBzPuAWiyYWStJ+Bd3v9o0T11XGSI7nsjc9COsLVM+yx18hbj+Pab/et5gOwHEh 3yKOuBmHsEEGMUoW5KO3I6aq58cn1A735oU2jZNwnG+kLKMf0QecY2e1nU9HUwqVNjiC ogM6PIM4XCpgoJkIT+xhE/dJS0Q1yR+iRPKyGOT73p4MCHBevObQi3LCYJWb1rDWLv23 JWjQ==
X-Gm-Message-State: APjAAAV5o7ntXftJFtD0rUicX+XbcmN+ku25yJ+vG2p5q1oP8UyjNT9N f7Fj+DUx/8iuH8ppc+YC08wClO8mAndZH6BMpXG9hA==
X-Google-Smtp-Source: APXvYqwi1FyyRGlyfwiqVtuZx9EGPncLwaugCYGhoJBx6n22ljg3ojU4hPd4yK03iA1VmR/mimb+Ypr9HcnHVPS71Xs=
X-Received: by 2002:a19:c6d6:: with SMTP id w205mr17284236lff.17.1572921334550;  Mon, 04 Nov 2019 18:35:34 -0800 (PST)
MIME-Version: 1.0
References:  <4460_1571933453_5DB1CD0D_4460_57_4_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931F030A0@OPEXCAUBM44.corporate.adroot.infra.ftgroup> <1572918247420.10381@cs.auckland.ac.nz>
In-Reply-To: <1572918247420.10381@cs.auckland.ac.nz>
From: Eric Rescorla 
Date: Mon, 4 Nov 2019 18:34:58 -0800
Message-ID: 
To: Peter Gutmann 
Cc: "emile.stephan@orange.com" ,  "Gorry Fairhurst (gorry@erg.abdn.ac.uk)" , tsvwg-chairs ,  "Black, David" , "tsvwg@ietf.org" ,  "IETF IPPM WG (ippm@ietf.org)" , "etosat@ietf.org" , "saag@ietf.org" ,  "opsawg@ietf.org" , "quic@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000067e6fa0596904939"
Archived-At: 
X-Mailman-Approved-At: Wed, 06 Nov 2019 08:40:57 -0800
Subject: Re: [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Nov 2019 02:35:38 -0000

--00000000000067e6fa0596904939
Content-Type: text/plain; charset="UTF-8"

On Mon, Nov 4, 2019 at 5:44 PM Peter Gutmann 
wrote:

> I actually think it's a pretty good summary, and delivers exactly what's
> promised in the title.  OTOH I can also see that it's going to get
> bikeshedded
> to death, and will probably never be editable into a form where people
> won't
> complain about it no matter how many changes are made.  Alternatively,
> it'll
> end up watered down to a point where no-one can complain any more but it
> won't
> say anything terribly useful by then.
>
> Perhaps it could be published as is with a comment that it represents the
> opinions of the authors?  Although given that it's Informational and not
> Standards-track or a BCP, that should be a given anyway.
>

Actually, no. Most IETF documents, even informational ones, bear a
statement that they have IETF Consensus.

See: https://tools.ietf.org/html/rfc5741#section-3.2.1

-Ekr


> Peter.
>
>
>
>

--00000000000067e6fa0596904939
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Nov 4, 2019 at 5:44 PM Peter =
Gutmann <pgut001@cs.aucklan=
d.ac.nz> wrote:










I actually think it's a pretty good summary, and delivers exactly =
what's


promised in the title.=C2=A0 OTOH I can also see that it's going t=
o get bikeshedded


to death, and will probably never be editable into a form where people=
 won't


complain about it no matter how many changes are made.=C2=A0 Alternati=
vely, it'll


end up watered down to a point where no-one can complain any more but =
it won't


say anything terribly useful by then.







Perhaps it could be published as is with a comment that it represents =
the


opinions of the authors?=C2=A0 Although given that it's Informatio=
nal and not


Standards-track or a BCP, that should be a given anyway.

Actually, no. Most IETF documents, even info=
rmational ones, bear a statement that they have IETF Consensus.
<=
br>

<=
/div>
-Ekr








Peter.



















--00000000000067e6fa0596904939--


From nobody Wed Nov  6 08:41:37 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38162120147; Mon,  4 Nov 2019 18:40:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level: 
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
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 j3USHftv-oT0; Mon,  4 Nov 2019 18:40:52 -0800 (PST)
Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 3D1A512006B; Mon,  4 Nov 2019 18:40:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1572921653; x=1604457653; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=uiXm5m3IwH0Ms7tsP06Xt+EDWbDLmLQ6ZLvD6l1dqqM=; b=MGFOQRqdl9jIuM4XL6LkwwgqdqCanw7imDbPH0CMKfAZ1J0kgAVofwkG vQzBb/UkAPE42i6ucb7w5Dn4qYx6mqKiIf9qDIC2T3HniLIDz9NpnGTY7 /aYY7rVDR4L7TNeGMmLrjvl889CepVEkX036zRVolAkX7fQNGQZtu23xM O38ykVaoSq+T6QMQL5KlMURpaXwWKtnLmFeizAaUp/zCs7+6vL1HXCOoe zu4e5o7xP/ODPC3YbeTLZnjCwX64xouTlxW72NMNd4y0Y/EEoD710+ybv ba0IYFm8ZYT8B8glW3B2gW8e/dAGeXhWFDrMgW3u7J99mohFK0gyyFE1w w==;
X-IronPort-AV: E=Sophos;i="5.68,269,1569240000"; d="scan'208";a="98130017"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing
Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-tdc-b.UoA.auckland.ac.nz) ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 05 Nov 2019 15:40:49 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.3) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 5 Nov 2019 15:40:48 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Tue, 5 Nov 2019 15:40:48 +1300
From: Peter Gutmann 
To: Eric Rescorla 
CC: "emile.stephan@orange.com" , "Gorry Fairhurst (gorry@erg.abdn.ac.uk)" , tsvwg-chairs , "Black, David" , "tsvwg@ietf.org" , "IETF IPPM WG (ippm@ietf.org)" , "etosat@ietf.org" , "saag@ietf.org" , "opsawg@ietf.org" , "quic@ietf.org" 
Thread-Topic: TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
Thread-Index: AdV+HJIZhebOrRcXTIK6bGArgFWweQEbzmAgAfqMkPACQR0OKf//NGgAgADai0A=
Date: Tue, 5 Nov 2019 02:40:48 +0000
Message-ID: <1572921649364.66797@cs.auckland.ac.nz>
References:  <4460_1571933453_5DB1CD0D_4460_57_4_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931F030A0@OPEXCAUBM44.corporate.adroot.infra.ftgroup> <1572918247420.10381@cs.auckland.ac.nz>, 
In-Reply-To: 
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
X-Mailman-Approved-At: Wed, 06 Nov 2019 08:40:57 -0800
Subject: Re: [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 05 Nov 2019 02:40:59 -0000

Eric Rescorla  writes:=0A=
=0A=
>Actually, no. Most IETF documents, even informational ones, bear a stateme=
nt=0A=
>that they have IETF Consensus.=0A=
=0A=
Ah, OK.  In that case publish it with a statement that commentators couldn'=
t=0A=
agree on what it should say, which I think is better than watering it down =
to=0A=
a level where commentators can't disagree with what it says.  It's an=0A=
interesting document which makes good points, and worth putting out there=
=0A=
while it still has good points to make.=0A=
=0A=
Peter.=0A=
=0A=
=0A=
        =


From nobody Wed Nov  6 09:52:56 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCFC120943; Wed,  6 Nov 2019 09:52:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yv0QKd7Crm9N; Wed,  6 Nov 2019 09:52:46 -0800 (PST)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::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 53F2512084D; Wed,  6 Nov 2019 09:52:46 -0800 (PST)
Received: by mail-lj1-x22f.google.com with SMTP id k15so15030472lja.3; Wed, 06 Nov 2019 09:52:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W7rhooxw1YPBCokn6AsiMtjDj6rKk0RscxFvzjxr4Ow=; b=J40TGKVNgcHNXqgW/AcOhUcFc780jDFC4cP9A9xuozFkOpHl6lSVl9a6JH46tmW/dw ckRHE0ZJwi6NEnz7jHu2oTa0JMOJEPunFPUsntgtzu/nPoW6gtxXobcKxcbhaXxcPRnM HAQCT2nmcn/26vJbOVh7pkLH5mR/48h2Oa9cdXxHjf9yY1hmvFAww6qWRMG87ftjwrih 4luLt5VRl4a/oQ0IR2VoVVu5sWyPCqvta9gXSMyqS1tEr+Qnq+zOQaKfbErn3U3+Ijzp tpHhErWXAxfQ333iBJrOiIpP/BLr2ufhvIDapKYAZkozf8uVBSHTNOkfuBkcABVzdDKS stSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W7rhooxw1YPBCokn6AsiMtjDj6rKk0RscxFvzjxr4Ow=; b=Be6hd70L5NieqNnA7/gwVUZN+uVQiDe5A2N+Ovkwx9tfRQyn3r8Gjq2J6FHUW5fDmx qtBj+Q28gjSat/DmwAGUgFjepaFRLg7Vt5TsbNwREF0KSmFEuxeCHiALSDsGNdO9yDun RiDSZ6JrWSOAI8c7pw5IkA4IW15HtmFDlOAZKU9NS73bSVAKJ3kj4ElfPDfrVyRDouTy p2p6TRatfAc2HcmgpDpOznkWghhtW1W5jQwIIV54tw7uapnBNUOIJBJKaw+u1vRQ0lGI cYQvz3tChWqymt8uBT3121vGmkdWGdUjKFwSOyJ14WT1Ln9qwtY8AulxNKN+2FbgtytX MBRA==
X-Gm-Message-State: APjAAAXJ5I0POnhB7eWz1UQXVsXigZ5vJTDId7BNloaV11FQBlAMgtDs 4nriw6wpquksQ4Wf7MzJo4gyemLr9/qM+57sdcw=
X-Google-Smtp-Source: APXvYqyVfsDvZBnUYV/5K9LP2pgbLAVFyMaMSzhHfBXzDhZB8W3HfHyMcP06fDgTTuxOb/0i5N7IWgiCOsVgnoOGur8=
X-Received: by 2002:a2e:2c19:: with SMTP id s25mr2896951ljs.26.1573062764417;  Wed, 06 Nov 2019 09:52:44 -0800 (PST)
MIME-Version: 1.0
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com>  <9687A3AC-870A-46E1-BD2A-7041410CFF75@ericsson.com>
In-Reply-To: <9687A3AC-870A-46E1-BD2A-7041410CFF75@ericsson.com>
From: David Schinazi 
Date: Wed, 6 Nov 2019 09:52:33 -0800
Message-ID: 
To: Mirja Kuehlewind 
Cc: Joe Touch , "gorry@erg.abdn.ac.uk" ,  Christian Huitema , tsvwg IETF list , "saag@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000048565a0596b1376a"
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Nov 2019 17:52:54 -0000

--00000000000048565a0596b1376a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Mirja,

Perhaps I misunderstood the document. The draft makes a lists
of issues that arise when you encrypt transport headers, then
concludes with a call to action to take these issues into
consideration. In your reading, what is the desired outcome of
this document? As a protocol designer, what do you expect me
to do differently when I design my next protocol after reading this
document? The tone seems to imply that I should leave some
headers unencrypted in order "to ensure network operators,
researchers and other stakeholders have appropriate tools to
manage their networks". If this is not the intent of this draft, then
what is it? What exact outcome or we hoping for?

Thanks,
David


On Tue, Nov 5, 2019 at 11:14 PM Mirja Kuehlewind <
mirja.kuehlewind@ericsson.com> wrote:

> Hi David,
>
> This document is not intended to discourage header encryption but to make
> sure that operational considerations are taken into account when exactly
> design new protocols that should have header encryption (as well as paylo=
ad
> encryption). If you think this document discourages header encryption, we
> need to fix that. Would be helpful if you could indicate to the authors
> where you think this is the case.
>
> Mirja
>
>
> Am 05.11.2019 um 23:10 schrieb David Schinazi :
>
> I also oppose publication of draft-ietf-tsvwg-transport-encrypt. This
> document discourages transport header encryption and publishing it could
> harm future protocol development.
>
> David
>
> On Tue, Nov 5, 2019 at 1:04 PM Joe Touch  wrote:
>
>>
>>
>> > On Nov 5, 2019, at 12:35 PM, Mirja Kuehlewind > 40ericsson.com@dmarc.ietf.org> wrote:
>> >
>> > What I=E2=80=99m hearing is that 2-3 people think this is not aligned =
but don=E2=80=99t
>> actually say why exactly they think that
>>
>> That=E2=80=99s not what we=E2=80=99re saying. We gave reasons.
>>
>> Joe
>>
>

--00000000000048565a0596b1376a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Mirja,

Perhaps I misunder=
stood the document. The draft makes a lists
of issues that arise =
when you encrypt transport headers, then
concludes with=C2=A0a ca=
ll to action to take these issues into
consideration. In your rea=
ding, what is the desired outcome of
this document? As a protocol=
 designer, what do you expect me
to do differently=C2=A0when I de=
sign my next protocol after reading this
document? The tone seems=
 to imply that I should leave some
headers unencrypted in order &=
quot;to ensure network operators,
researchers and other stakehold=
ers have appropriate tools to
manage their networks". If thi=
s is not the intent of this draft, then
what is it? What exact ou=
tcome or we hoping for?

Thanks,
David


On Tue, Nov 5, 2019 at 11:14 PM Mirja Kuehlewind <=
;mirja.kuehlewind@ericsson=
.com> wrote:
Hi David,

This document is not intended=
 to discourage header encryption but to make sure that operational consider=
ations are taken into account when exactly design new protocols that should=
 have header encryption (as well as payload encryption). If you think this =
document discourages header encryption, we need to fix that. Would be helpf=
ul if you could indicate to the authors where you think this is the case.

Mirja


Am 05.11.2019 um 23:10 schrieb David Schina=
zi <dschin=
azi.ietf@gmail.com>:

I also oppose publication of=C2=A0draft-ietf-tsvw=
g-transport-encrypt. This document discourages transport header encryption =
and publishing it could harm future protocol development.

David

On Tue, Nov 5, 2019 at 1:04 PM Joe Touch <touch@strayalpha.com> wrote=
:




> On Nov 5, 2019, at 12:35 PM, Mirja Kuehlewind <mirja.kuehlewind=3D<=
a href=3D"mailto:40ericsson.com@dmarc.ietf.org" target=3D"_blank">40ericsso=
n.com@dmarc.ietf.org> wrote:

> 

> What I=E2=80=99m hearing is that 2-3 people think this is not aligned =
but don=E2=80=99t actually say why exactly they think that



That=E2=80=99s not what we=E2=80=99re saying. We gave reasons. 



Joe 






--00000000000048565a0596b1376a--


From nobody Wed Nov  6 18:15:39 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03F71200C3; Wed,  6 Nov 2019 18:15:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=rNa+IsA0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=F9SFHs1R
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 qv9EzPl_gTNF; Wed,  6 Nov 2019 18:15:29 -0800 (PST)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5164E12008F; Wed,  6 Nov 2019 18:15:29 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 85BA64CD; Wed,  6 Nov 2019 21:15:28 -0500 (EST)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 06 Nov 2019 21:15:28 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm3; bh=yD CIi5UNyY922++dP2q36DzvDCigWVjRJDeYWsn0bGc=; b=rNa+IsA0B35YDsPXf3 Xv7uhi4W/aAAlgDpHYPkXDv7cZ+HeagK8tkgAMF2zLvi+mWENqc2Bq7JbKI3gkhX uFfBADVSwc1AMMmtIT9mZqnw++9lKl46O8bp89acuGkQEviQ8e+V9PMcibnqAauo LoCSjqfCFK16fchNHV7bmsi4R0mak/IjhHPgZbK9t/kaJ3tQLWbU4l4ETYEaef5F O77s4DfGp3dKc+UiXaXyd48xq1NeO+LIgGj8eN0TX87m+aDxGnVo+wwIquPKdgPG KtYNdL7D4SWdI/NhTLwAM03H8nSbY3FK2rdSv0+wxW/qbvfUc/mcIDt8MfsAjl/t j+YQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=yDCIi5UNyY922++dP2q36DzvDCigWVjRJDeYWsn0b Gc=; b=F9SFHs1RwcnP8aNFLOZsq4cACSzESWN5ajKLi5oCUkw/GuNCR7CuF776V iCaAjV9tzVvOtO6qB5zHijau8Sf7fDL+ew6/5zHFhVH82VtUx6bgN6f5iPS4DxFr 5WpaE97ORsLzWqqtwd/2O4DIQYkViMvcXpZvoi++UWaLl+84d04r0hN1i2rOYpGc 6i1Xm7sMew1wYkToRWHs5nK2tKy9HD2Fi1b836EjcUhMI7Dz6EMNkMXuK9a4vhon yTKX9FLr89TGkdRZrjVSssf8IGsST/Qmfw2rFoNk6uhDkC6qZWmbJNI+zS5/NhVG 5vc1oIent1GFUjVGyfsf0106cQARg==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddukedggeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfofgr rhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenuc frrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucev lhhushhtvghrufhiiigvpedt
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id BB0F1E00A3; Wed,  6 Nov 2019 21:15:26 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1
Mime-Version: 1.0
Message-Id: <8dd558db-6f22-487f-a714-9f0ba71e74dc@www.fastmail.com>
In-Reply-To: <54B33418-28D8-4176-A2EE-29FF27E5CE44@csperkins.org>
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com>  <118e630a-3f04-4aa9-8c1f-8083194865e4@www.fastmail.com> <9EC2E60F-6044-4135-A802-1665028E6075@ericsson.com> <54B33418-28D8-4176-A2EE-29FF27E5CE44@csperkins.org>
Date: Thu, 07 Nov 2019 13:14:15 +1100
From: "Martin Thomson" 
To: "Colin Perkins" , "Mirja Kuehlewind" 
Cc: "tsvwg IETF list" , "saag@ietf.org" 
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [saag]  =?utf-8?q?=5Btsvwg=5D__Comments_on_draft-ietf-tsvwg-trans?= =?utf-8?q?port-encrypt-08=2Etxt?=
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Nov 2019 02:15:32 -0000

On Wed, Nov 6, 2019, at 20:58, Colin Perkins wrote:
> It certainly wasn=E2=80=99t my intent with this draft to say that all =
these=20
> practices should be kept; rather to stimulate the discussion about wha=
t=20
> should be preserved, what it=E2=80=99s necessary to find alternatives =
for; etc.=20
> If this doesn=E2=80=99t come across clearly in the draft. we should fi=
x it.

Thanks Colin,

I didn't start with that expectation and the introduction does a fine jo=
b of setting this out.  However the draft makes some very strong stateme=
nts in the conclusion and - in a few places - the body that leave very l=
ittle room for interpretation.

I'm happy to help identify specific cases, but it seemed to be fairly co=
nsistent throughout.  For the bulk of the document, perhaps the right th=
ing to do is take another pass with a critical eye.  I don't know what t=
o do about the conclusions section though.

I just want to say that while I appreciate the effort taken to document =
techniques, I'm not entirely convinced that it is the only way forward. =
 Discussion of existing practice can distract from the underlying needs.=


To take the example of capacity planning, I had a great conversation abo=
ut 18 months ago with Lee Howard about what that might look like in the =
presence of more opaque data flows between endpoints.  I don't think tha=
t we reached a specific conclusion, but it was refreshing to talk about =
the actual problem and not get bogged down in the detail of specific tec=
hniques.  Though the discussion touched on many existing and potential m=
ethods, our focus never left the important question of what the goals we=
re and how there might be some shared interest in achieving that goal.

Being able to focus on the underlying requirements like that can be hard=
, but my sense is that this is where we'll need to reach before anything=
 meaningful will happen.  I have to confess, despite enduring the spin b=
it debate, I find the fact that I have still trouble articulating exactl=
y what requirements that mechanism addresses to be concerning.


From nobody Wed Nov  6 22:51:09 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730D8120074; Wed,  6 Nov 2019 22:51:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level: 
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
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 DphaOsJbbgD3; Wed,  6 Nov 2019 22:51:06 -0800 (PST)
Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 6069212002E; Wed,  6 Nov 2019 22:51:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1573109466; x=1604645466; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cBRQ/3vFbCwYYlVIEThsJ15egkt2BUV1U0VKdaUL3Bk=; b=jWpb5GSfu90eNcVMW1knembglhQNTI40fG3M6dA7lzXN3SHYGNzPA8sy enniAiGf/Kr5OS7oLKyK19+wnpn7jNBLCcWJfB4BcLlFGuI/2PCMt7TvO 9LIy9jMphn66m3Ba5PrSAX4O6bnGF2L90Aln5cfNM2qAMHHV+w+/YLSCx jm+82+zvKc6cyt+y+btHB/FIqEWCfdTa9EV3oKTxyrKDktWf9UvJCrUMS uaOx+NQVwxoyVho/xr42iUNEjPq5Z4fFugjzVNkpletGsvSQn0tDwRvmM XmQ+U+ISq1p+mdCtcCuhnitK5aomBSZZyXCGTvSPAD5tkpXvOxYFq+zun Q==;
X-IronPort-AV: E=Sophos;i="5.68,277,1569240000"; d="scan'208";a="98525334"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing
Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-ogg-a.UoA.auckland.ac.nz) ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 07 Nov 2019 19:51:03 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.2) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 7 Nov 2019 19:51:02 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Thu, 7 Nov 2019 19:51:02 +1300
From: Peter Gutmann 
To: Stephen Farrell , David Schinazi , Joe Touch 
CC: "gorry@erg.abdn.ac.uk" , Mirja Kuehlewind , tsvwg IETF list , "saag@ietf.org" 
Thread-Topic: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
Thread-Index: AQHVkyCjrwMtocCjZ0izavTli3wJVKd6WcIAgAAVngCAAARbAIABsv2AgAAFtwCAAARPgIAACCuAgAASewCAAaJ3cP//jvOAgAHLw4Q=
Date: Thu, 7 Nov 2019 06:51:02 +0000
Message-ID: <1573109463764.56084@cs.auckland.ac.nz>
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com>  <1573035094775.62307@cs.auckland.ac.nz>, <87d3bcef-42e4-1535-db1f-06a8408d38d5@cs.tcd.ie>
In-Reply-To: <87d3bcef-42e4-1535-db1f-06a8408d38d5@cs.tcd.ie>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Nov 2019 06:51:09 -0000

Stephen Farrell  writes:=0A=
=0A=
>In addition, the document is missing any real description of the harmful w=
ays=0A=
>in which cleartext headers are being (ab)used today.=0A=
=0A=
That's actually something that's missing in general, not specifically in th=
is=0A=
document.  Header encryption seems to be taken as an article of faith, we m=
ust=0A=
do this because it's something we must do, and yet from long experience wit=
h=0A=
the two protocols that do header encryption (or at least protection), IPsec=
=0A=
and SSH, for the former all it's produced is endless and ongoing headaches =
for=0A=
devices that need to forward/route/manage IPsec traffic, and for the latter=
=0A=
all it's produced is a string of security vulnerabilities.=0A=
=0A=
So what's the sound technical - not religious - argument for header=0A=
encryption?  Calling it "abuse" is a purely subjective statement, one perso=
n's=0A=
abuse is another's essential functionality.  One big example of this DNS=0A=
manipulation to implement captive portals, which the DNSSEC folks I've talk=
ed=0A=
to regard as anathema but without which maybe 90% [figure totally invented]=
 of=0A=
public WiFi won't work.  So to the DNSSEC fans it's abuse, to pretty much=
=0A=
everyone else except a few DNSSEC fans it's fine because they want public W=
iFi=0A=
to work for them.=0A=
=0A=
In particular for header encryption there have been at least two dozen pape=
rs=0A=
published, and many commercial products created, that bypass encryption to =
do=0A=
fairly extensive traffic analysis *of encrypted traffic*, encrypted headers=
 or=0A=
no.  So on the one hand we've got real-world experience with two protocols=
=0A=
that do header encryption/protection which has yielded endless problems=0A=
(IPsec) and security vulns (SSH), and on the other hand we've got what seem=
s=0A=
to be a faith-based belief in something that numerous academic papers have=
=0A=
shown doesn't provide the service it claims to.=0A=
=0A=
Where's the technical argument for header encryption, backed by actual=0A=
research showing that it's effective, and that the benefits outweigh the=0A=
disadvantages?=0A=
=0A=
Peter.=0A=


From nobody Thu Nov  7 08:16:30 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814281209D2 for ; Thu,  7 Nov 2019 08:16:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TG5WI5ayf7Kb for ; Thu,  7 Nov 2019 08:16:15 -0800 (PST)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 9C2851209A7 for ; Thu,  7 Nov 2019 08:16:14 -0800 (PST)
Received: by mail-ed1-x533.google.com with SMTP id a21so2352150edj.8 for ; Thu, 07 Nov 2019 08:16:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=alSnbw1yE+TfgP/karC+3lzh/7xuva8JEnQInYPiaBw=; b=zARQhWtoM2HfpFYqtvjITfabOJgfWONKu5yzxI2JmN/InRZovOTpkfL1rpz2/pl8kJ /m5cdsT3TKa5HOpKhNNNPGTjeTm1dPiVdk1GE27KQmnO2IeheAjKKen+CkmCzQOU48d8 qyZIWCv5c0zdkpWyaq7njGCZaBWS6hMy8pO4T652xmqLfoJUAWP8ZqtJE3djfzHsWHq8 ILsNPeYk1mf4yuKebP0CjAKL8TIxnSkcqiVxNamT7cvpr+uunlks81rCe1g05Rdv0ZWI uIGS9MVfaqu7Yv4WABCfy0SBXdPEOMd5G5WOLLeiaFW+b2PMM0oE/7LoHhTfdHgoqCn8 8KNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=alSnbw1yE+TfgP/karC+3lzh/7xuva8JEnQInYPiaBw=; b=BCN5CrLamxmlUM36zCSNDpVdaFlJtdNv7tAn5j1eJWs9qIw0ic4GuIUvK2IcBBngmR 7oJnRUoSGLVla6eYDfbQ9c9b16r9B/4oyTUmD4+NFUsWeUtahTnmX6w8YsMZsOnyFjhl UUHB8WhLWB2OGqoVeK3x+oEFGusER0v1tK495US5P01ha7yxp1x+8NQded1gJ8ARn4nV wDTWsagZ8/SraCp+RAAAPXl5qtHkltsZ69LeHldUBe+03A2zIa91xTqU7IeYa0TO2rRj 6rLjF7FjAaZ5U4Hr0UcwekIYacPLI6X6ZEJ2G8vRUqTSZBB7lfLujEmYnxPUaMMnSQJT 2rbw==
X-Gm-Message-State: APjAAAUmADeI/Q5pI/2iaTNPRAkf3OhoNab2dmg2S0JZgRlzhqlRQVNt W257/wD5mMQZkPxG64UnVFFhwhuweAOhuGvqSUsxsw==
X-Google-Smtp-Source: APXvYqwFAAOawdTCPtspL0WOwJT7I1ul2HZ+3Sg8N98LJ3a4oFfG9ad+GkQ+ivZoZ1jkACr0m0cO09Mkr24wkexKmG0=
X-Received: by 2002:a17:907:1114:: with SMTP id qu20mr3967787ejb.42.1573143372914;  Thu, 07 Nov 2019 08:16:12 -0800 (PST)
MIME-Version: 1.0
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com>  <1573035094775.62307@cs.auckland.ac.nz> <87d3bcef-42e4-1535-db1f-06a8408d38d5@cs.tcd.ie> <1573109463764.56084@cs.auckland.ac.nz>
In-Reply-To: <1573109463764.56084@cs.auckland.ac.nz>
From: Tom Herbert 
Date: Thu, 7 Nov 2019 08:16:01 -0800
Message-ID: 
To: Peter Gutmann 
Cc: Stephen Farrell , David Schinazi ,  Joe Touch , "gorry@erg.abdn.ac.uk" , Mirja Kuehlewind ,  tsvwg IETF list , "saag@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Nov 2019 16:16:20 -0000

On Wed, Nov 6, 2019 at 10:51 PM Peter Gutmann  wrote:
>
> Stephen Farrell  writes:
>
> >In addition, the document is missing any real description of the harmful ways
> >in which cleartext headers are being (ab)used today.
>
> That's actually something that's missing in general, not specifically in this
> document.  Header encryption seems to be taken as an article of faith, we must
> do this because it's something we must do, and yet from long experience with
> the two protocols that do header encryption (or at least protection), IPsec
> and SSH, for the former all it's produced is endless and ongoing headaches for
> devices that need to forward/route/manage IPsec traffic, and for the latter
> all it's produced is a string of security vulnerabilities.
>
> So what's the sound technical - not religious - argument for header
> encryption?  Calling it "abuse" is a purely subjective statement, one person's
> abuse is another's essential functionality.  One big example of this DNS
> manipulation to implement captive portals, which the DNSSEC folks I've talked
> to regard as anathema but without which maybe 90% [figure totally invented] of
> public WiFi won't work.  So to the DNSSEC fans it's abuse, to pretty much
> everyone else except a few DNSSEC fans it's fine because they want public WiFi
> to work for them.
>
> In particular for header encryption there have been at least two dozen papers
> published, and many commercial products created, that bypass encryption to do
> fairly extensive traffic analysis *of encrypted traffic*, encrypted headers or
> no.  So on the one hand we've got real-world experience with two protocols
> that do header encryption/protection which has yielded endless problems
> (IPsec) and security vulns (SSH), and on the other hand we've got what seems
> to be a faith-based belief in something that numerous academic papers have
> shown doesn't provide the service it claims to.
>
Peter,

The problems of protocol ossification and middleboxes meddling in E2E
protocols has been discussed at length in IETF in various contexts.
This is a real problem. It is well known that encryption of as much as
the packet as possible is one mitigation to present protocol
ossification. For instance, this was exactly the rationale in QUIC to
encrypt the whole transport layer.

On the other hand, the draft provides most anecdotal information that
plaintext headers are useful. For instance, there's a lot of
discussion about network operations. It is conceivable that this
unencrypted headers might help network operators, but then that raises
some obvious questions. Do all operators look into transport layer? Do
all network operator require the same information from the transport
layer header? If they do, what is the EXACT set of transport layer
information they need? Do they all support the same transport layer
protocols? What if we start using a new transport layer protocol from
hosts, are we out of luck because that protocol is not on the
"approved list"?

If there were answers to such questions then real requirements both on
the host side and network side could be articulated and there might be
a basis for a meaningful discussion, but in lieu of that all we are
left with is vague guidance for the transport layer protocol designer
that they should consider how middleboxes _might_ to meddle in the
protocol.

Tom

> Where's the technical argument for header encryption, backed by actual
> research showing that it's effective, and that the benefits outweigh the
> disadvantages?
>
> Peter.
>


From nobody Thu Nov  7 11:10:20 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD07E120144; Thu,  7 Nov 2019 11:10:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I762qAhnfcYo; Thu,  7 Nov 2019 11:10:16 -0800 (PST)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27A95120025; Thu,  7 Nov 2019 11:10:16 -0800 (PST)
Received: from [82.152.40.192] (port=61261 helo=[192.168.1.135]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iSnAZ-0000fZ-6i; Thu, 07 Nov 2019 19:10:11 +0000
From: Colin Perkins 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_42569CB8-9B5B-43B2-A57B-15EC50EA73DE"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 7 Nov 2019 19:10:03 +0000
In-Reply-To: 
Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , Gorry Fairhurst , Joe Touch , tsvwg IETF list , "saag@ietf.org" 
To: David Schinazi 
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com>  <9687A3AC-870A-46E1-BD2A-7041410CFF75@ericsson.com> 
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 14
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Nov 2019 19:10:19 -0000

--Apple-Mail=_42569CB8-9B5B-43B2-A57B-15EC50EA73DE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

David,

I don=E2=80=99t know what Mirja thinks is the desired outcome, but my =
intent =E2=80=93 as an author of the draft =E2=80=93 is that you think =
about the issues raised and how they relate to your protocol, then make =
an informed decision about what parts of the headers to protect and what =
parts it might make sense to expose.

And, to be explicit, if you think about the issues discussed in the =
draft and then decide to encrypt all the transport layer headers, =
that=E2=80=99s fine by me.=20

Colin


> On 6 Nov 2019, at 17:52, David Schinazi  =
wrote:
>=20
> Hi Mirja,
>=20
> Perhaps I misunderstood the document. The draft makes a lists
> of issues that arise when you encrypt transport headers, then
> concludes with a call to action to take these issues into
> consideration. In your reading, what is the desired outcome of
> this document? As a protocol designer, what do you expect me
> to do differently when I design my next protocol after reading this
> document? The tone seems to imply that I should leave some
> headers unencrypted in order "to ensure network operators,
> researchers and other stakeholders have appropriate tools to
> manage their networks". If this is not the intent of this draft, then
> what is it? What exact outcome or we hoping for?
>=20
> Thanks,
> David
>=20
>=20
> On Tue, Nov 5, 2019 at 11:14 PM Mirja Kuehlewind =
> =
wrote:
> Hi David,
>=20
> This document is not intended to discourage header encryption but to =
make sure that operational considerations are taken into account when =
exactly design new protocols that should have header encryption (as well =
as payload encryption). If you think this document discourages header =
encryption, we need to fix that. Would be helpful if you could indicate =
to the authors where you think this is the case.
>=20
> Mirja
>=20
>=20
> Am 05.11.2019 um 23:10 schrieb David Schinazi =
>:
>=20
>> I also oppose publication of draft-ietf-tsvwg-transport-encrypt. This =
document discourages transport header encryption and publishing it could =
harm future protocol development.
>>=20
>> David
>>=20
>> On Tue, Nov 5, 2019 at 1:04 PM Joe Touch > wrote:
>>=20
>>=20
>> > On Nov 5, 2019, at 12:35 PM, Mirja Kuehlewind =
> wrote:
>> >=20
>> > What I=E2=80=99m hearing is that 2-3 people think this is not =
aligned but don=E2=80=99t actually say why exactly they think that
>>=20
>> That=E2=80=99s not what we=E2=80=99re saying. We gave reasons.=20
>>=20
>> Joe=20
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag



--=20
Colin Perkins
https://csperkins.org/





--Apple-Mail=_42569CB8-9B5B-43B2-A57B-15EC50EA73DE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

David,

I =
don=E2=80=99t know what Mirja thinks is the desired outcome, but my =
intent =E2=80=93 as an author of the draft =E2=80=93 is that you think =
about the issues raised and how they relate to your protocol, then make =
an informed decision about what parts of the headers to protect and what =
parts it might make sense to expose.

And, to be explicit, if you think about =
the issues discussed in the draft and then decide to encrypt all the =
transport layer headers, that=E2=80=99s fine by =
me. 

Colin


On 6 Nov =
2019, at 17:52, David Schinazi <dschinazi.ietf@gmail.com> wrote:

Hi Mirja,

Perhaps I misunderstood the document. =
The draft makes a lists
of issues that arise when =
you encrypt transport headers, then
concludes =
with a call to action to take these issues into
consideration. In your reading, what is the desired outcome =
of
this document? As a protocol designer, what do =
you expect me
to do differently when I design =
my next protocol after reading this
document? The =
tone seems to imply that I should leave some
headers =
unencrypted in order "to ensure network operators,
researchers and other stakeholders have appropriate tools =
to
manage their networks". If this is not the =
intent of this draft, then
what is it? What exact =
outcome or we hoping for?

Thanks,
David


On Tue, Nov =
5, 2019 at 11:14 PM Mirja Kuehlewind <mirja.kuehlewind@ericsson..com> wrote:
Hi =
David,

This document is not intended to discourage =
header encryption but to make sure that operational considerations are =
taken into account when exactly design new protocols that should have =
header encryption (as well as payload encryption). If you think this =
document discourages header encryption, we need to fix that. Would be =
helpful if you could indicate to the authors where you think this is the =
case.

Mirja


Am =
05.11.2019 um 23:10 schrieb David Schinazi <dschinazi.ietf@gmail.com>:

I also oppose publication =
of draft-ietf-tsvwg-transport-encrypt. This document discourages =
transport header encryption and publishing it could harm future protocol =
development.

David

On Tue, Nov 5, 2019 at 1:04 PM Joe =
Touch <touch@strayalpha.com> wrote:




> On Nov 5, 2019, at 12:35 PM, Mirja Kuehlewind =
<mirja.kuehlewind=3D40ericsson.com@dmarc.ietf.org> =
wrote:

> 

> What I=E2=80=99m hearing is that 2-3 people think this is not =
aligned but don=E2=80=99t actually say why exactly they think that



That=E2=80=99s not what we=E2=80=99re saying. We gave reasons. 



Joe 





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




-- 
Colin Perkins
https://csperkins.org/








=

--Apple-Mail=_42569CB8-9B5B-43B2-A57B-15EC50EA73DE--


From nobody Thu Nov  7 11:24:27 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F07D120B22; Thu,  7 Nov 2019 11:24:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNdg-Hj_2rdw; Thu,  7 Nov 2019 11:24:16 -0800 (PST)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::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 6A181120A2D; Thu,  7 Nov 2019 11:24:16 -0800 (PST)
Received: by mail-lj1-x22b.google.com with SMTP id y23so3532310ljh.10; Thu, 07 Nov 2019 11:24:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bRwRgqVmH/cYqZUbyCuOrZz5BbspH6VkjdCoFNsQUzE=; b=pGM/xpVc30I9m/GyDfo43WLtdTT8314odFWXL/i8ckyGpGfypaah0IZvwqwK08jG7b 6VBMA/paAjDt9Zac5wqNdFAnvYR7w21sWLyfAi7Fr6HPz1VnTRO8cuz9EDifHQykrDRp e0UW7AwJTm3rH4MDqTBVTy+HoPGi9Qt8o0hc9GUwxOwssCYk/cWK0kLfgurKLU4kCZU+ uKvRfBuIAsX7ksMLKASOwyW+CA/sJIeudpG9TqO1B3+v/NQSNwYg4XibOi5iIn1vgLdM DJ4WMmRVtTLgL7S1bRkOhVLTVNOfl/+RrFbRGy/0km2BsOiLoQZd3u5CqmBy3meRv1wR BvsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bRwRgqVmH/cYqZUbyCuOrZz5BbspH6VkjdCoFNsQUzE=; b=VLMX6JMRFrDhM122agyM/udgNOMd6yGd3L3sG11uW6Sq/e0s4WNeFfuYDieeSJEkRV v33ZY75YluXRKl3yrpqqfTCAig7CdYnl2ImjHWtRalq1LnYTc/rsFXbF8AxsB6Vg79n8 k7uepVPRJtbXhWRzIcR3QZmz/uljNPVpLyloTVsGKXT2ExBhU4InPQ27bC1dU11egpoF DOju3fX8UUaKcyp8/iGzkheEEd2NcI92/FNPKAaZmHyx5pwAFEoQLWRFyT7pctYjKHn+ lxSFdIQKmI1of4cwKhzTQHklIGYqQirtH0JjmuEqdOQOfcyCKgwHGzD5tU6OI7S9RA+/ MBYw==
X-Gm-Message-State: APjAAAVojRqk5s9iwc9MWc74dRNP24BMdkqCUpkUHQa2pkicfJg+g1O8 +GxAD3AqzPEXkSfmOD4Gew9busKesrgjWeTaA8Y53Q==
X-Google-Smtp-Source: APXvYqxdN21z8dgcgTracpbAj6kfVr3k2vBt6sLzrolPGnDAwwjndRJ0u2SIPDgi++GZtqUb2NIfIynyHSSZzuCnmxc=
X-Received: by 2002:a2e:2c19:: with SMTP id s25mr3674472ljs.26.1573154654408;  Thu, 07 Nov 2019 11:24:14 -0800 (PST)
MIME-Version: 1.0
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com>  <9687A3AC-870A-46E1-BD2A-7041410CFF75@ericsson.com>  
In-Reply-To: 
From: David Schinazi 
Date: Thu, 7 Nov 2019 11:24:02 -0800
Message-ID: 
To: Colin Perkins 
Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= ,  Gorry Fairhurst , Joe Touch ,  tsvwg IETF list , "saag@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000005a54cc0596c69c3e"
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Nov 2019 19:24:20 -0000

--0000000000005a54cc0596c69c3e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Colin,

Thanks for the clarification. If the intent is to get protocol developers
to think, that's always a good thing. However, I think the tone of the
document does not match this intent. I realize that this is purely
subjective, but upon reading it I really had the impression that this
document suggests that the downsides of encrypting transport
headers outweigh the benefits. Perhaps the document should
instead aim for a middle-of-the-road approach. For example, the
document could expand the mention of QUIC into a case study: the
draft could explain how QUIC considered these issues and made
the informed decision to encrypt its transport headers.

David

On Thu, Nov 7, 2019 at 11:10 AM Colin Perkins  wrote:

> David,
>
> I don=E2=80=99t know what Mirja thinks is the desired outcome, but my int=
ent =E2=80=93 as
> an author of the draft =E2=80=93 is that you think about the issues raise=
d and how
> they relate to your protocol, then make an informed decision about what
> parts of the headers to protect and what parts it might make sense to
> expose.
>
> And, to be explicit, if you think about the issues discussed in the draft
> and then decide to encrypt all the transport layer headers, *that=E2=80=
=99s fine
> by me. *
>
> Colin
>
>
> On 6 Nov 2019, at 17:52, David Schinazi  wrote:
>
> Hi Mirja,
>
> Perhaps I misunderstood the document. The draft makes a lists
> of issues that arise when you encrypt transport headers, then
> concludes with a call to action to take these issues into
> consideration. In your reading, what is the desired outcome of
> this document? As a protocol designer, what do you expect me
> to do differently when I design my next protocol after reading this
> document? The tone seems to imply that I should leave some
> headers unencrypted in order "to ensure network operators,
> researchers and other stakeholders have appropriate tools to
> manage their networks". If this is not the intent of this draft, then
> what is it? What exact outcome or we hoping for?
>
> Thanks,
> David
>
>
> On Tue, Nov 5, 2019 at 11:14 PM Mirja Kuehlewind <
> mirja.kuehlewind@ericsson..com > wrote:
>
>> Hi David,
>>
>> This document is not intended to discourage header encryption but to mak=
e
>> sure that operational considerations are taken into account when exactly
>> design new protocols that should have header encryption (as well as payl=
oad
>> encryption). If you think this document discourages header encryption, w=
e
>> need to fix that. Would be helpful if you could indicate to the authors
>> where you think this is the case.
>>
>> Mirja
>>
>>
>> Am 05.11.2019 um 23:10 schrieb David Schinazi =
:
>>
>> I also oppose publication of draft-ietf-tsvwg-transport-encrypt. This
>> document discourages transport header encryption and publishing it could
>> harm future protocol development.
>>
>> David
>>
>> On Tue, Nov 5, 2019 at 1:04 PM Joe Touch  wrote:
>>
>>>
>>>
>>> > On Nov 5, 2019, at 12:35 PM, Mirja Kuehlewind >> 40ericsson.com@dmarc.ietf.org> wrote:
>>> >
>>> > What I=E2=80=99m hearing is that 2-3 people think this is not aligned=
 but
>>> don=E2=80=99t actually say why exactly they think that
>>>
>>> That=E2=80=99s not what we=E2=80=99re saying. We gave reasons.
>>>
>>> Joe
>>>
>> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>
>
>
>
> --
> Colin Perkins
> https://csperkins.org/
>
>
>
>
>

--0000000000005a54cc0596c69c3e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Colin,

Thanks for the clarification.=
 If the intent is to get protocol developers
to think, that's=
 always a good thing. However, I think the tone of the
document d=
oes not match this intent. I realize that this is purely
subjecti=
ve, but upon reading it I really had the impression that this
doc=
ument suggests that the downsides of encrypting transport
headers=
 outweigh the benefits. Perhaps the document should
instead aim f=
or a middle-of-the-road approach. For example, the
document could=
 expand the mention of QUIC into a case study: the
draft could ex=
plain how QUIC considered these issues and made
the informed deci=
sion to encrypt its transport headers.

David
=


=
On Thu, Nov 7, 2019 at 11:10 AM Colin Perkins <csp@csperkins.org> wrote:
Davi=
d,

I don=E2=80=99t know what Mirja thinks is the desired=
 outcome, but my intent =E2=80=93 as an author of the draft =E2=80=93 is th=
at you think about the issues raised and how they relate to your protocol, =
then make an informed decision about what parts of the headers to protect a=
nd what parts it might make sense to expose.

And, =
to be explicit, if you think about the issues discussed in the draft and th=
en decide to encrypt all the transport layer headers, that=E2=80=99s fin=
e by me.=C2=A0

Colin


On 6 Nov 2019, at 17:52, David Schinazi <dschinazi.ietf@=
gmail.com> wrote:

Hi Mirja,

Perhaps I misunderstood the document. The draft makes =
a lists
of issues that arise when you encrypt transport headers, =
then
concludes with=C2=A0a call to action to take these issues in=
to
consideration. In your reading, what is the desired outcome of=

this document? As a protocol designer, what do you expect me
to do differently=C2=A0when I design my next protocol after reading =
this
document? The tone seems to imply that I should leave some
headers unencrypted in order "to ensure network operators,
researchers and other stakeholders have appropriate tools to
<=
div>manage their networks". If this is not the intent of this draft, t=
hen
what is it? What exact outcome or we hoping for?
Thanks,
David


On Tue, Nov 5=
, 2019 at 11:14 PM Mirja Kuehlewind <mirja.kuehlewind@ericsson..com> wrot=
e:
Hi David,

This document is not intended to discourage he=
ader encryption but to make sure that operational considerations are taken =
into account when exactly design new protocols that should have header encr=
yption (as well as payload encryption). If you think this document discoura=
ges header encryption, we need to fix that. Would be helpful if you could i=
ndicate to the authors where you think this is the case.

Mirja


Am 05.11.2019 um 23:10 schrieb David Schinazi <dschinazi.ietf@gmail.co=
m>:

I also oppose publication of=C2=A0draft-ietf-tsvwg-transport-encry=
pt. This document discourages transport header encryption and publishing it=
 could harm future protocol development.

David

On T=
ue, Nov 5, 2019 at 1:04 PM Joe Touch <touch@strayalpha.com> wrote:




> On Nov 5, 2019, at 12:35 PM, Mirja Kuehlewind <mirja.kuehlewind=3D<=
a href=3D"mailto:40ericsson.com@dmarc.ietf.org" target=3D"_blank">40ericsso=
n.com@dmarc.ietf.org> wrote:

> 

> What I=E2=80=99m hearing is that 2-3 people think this is not aligned =
but don=E2=80=99t actually say why exactly they think that



That=E2=80=99s not what we=E2=80=99re saying. We gave reasons. 



Joe 





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




--=C2=A0
Colin Perkins
https://csperkins.org/









--0000000000005a54cc0596c69c3e--


From nobody Thu Nov  7 12:06:43 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BBC1208C2; Thu,  7 Nov 2019 12:06:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxgVxh0ZgGkg; Thu,  7 Nov 2019 12:06:12 -0800 (PST)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::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 9EC51120255; Thu,  7 Nov 2019 12:06:11 -0800 (PST)
Received: by mail-lj1-x229.google.com with SMTP id t5so3706598ljk.0; Thu, 07 Nov 2019 12:06:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9y7HqqlCW1QXhEBr/F6UnNbID2hR5pc0UGz+VM1VhqE=; b=IF1NMHKZagEAnNHbU9I23QmJ0uEnaoyiQnlU2x1E3Xm53Zm4sv12ucSJPnubyf6FyJ 24s6DLLNyscqcPeIHt1GdkdyrZDQ34+vpOieH0iT5Wan914KqvMDg//xn5GOQWl37VVx oLI242QGTo30vv4ZX1oBIYTbAAFRvMAk51TlPBW0SQ3hyKPFWzcrONMuSf9T7V/dC+7X rPX2FVbG04Zs2Ff3m5/nUdqb0JeXdOkSpa5Xuw90lUTrsgzOlqTYll1lUpL4c2ogqQ2v oo9YzjWupdxxQD64PV4fBKcqd6Pwje9kNekmOlx3pvjdHZgq2E6PNhifQdby0Kd/V3xd JPGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9y7HqqlCW1QXhEBr/F6UnNbID2hR5pc0UGz+VM1VhqE=; b=WRGqDZnZVaEYZRYWtZR5JBdImyWnC/s2Z19rLr0HcGxGZuPj5b7A6a4n9wzJ/H0ZD4 ZgYyjxPJeEa7c2j5/5E0SuyXQn3EJUKLEdHrCUl2l/N/HAvLSf0BCcQRwadKnlhqXgzb H6e4fjyrnZPCMh4oyAozWvE+CvKTxW3x88y7GjJUXiYERt/zbimBc2E6rtFWwMqMfE9E Qv+ibj04a+Fz9vTxbq5EdqroSiwX0Cqps24y66chYcWBwUotQTfckUmdr+feR+4uvoM9 Md152zJDzADZJqGdHzFjP+qDrly8TXgp60wS5B7a0f45btrZF6ngR1zNQ0vsb3DyRIEB UPeA==
X-Gm-Message-State: APjAAAXWoDtN5Qvp8nO3rb8pmLjAMqzVMywzOkiChZqZNudQgbYpyhZE qD31THlj0jAkUAvFAFVLZliHLF8vdzTNDUAJtGU=
X-Google-Smtp-Source: APXvYqzpHZox5cYKjuHWl03/GvE+2jcuJxqJj4IBXtre8Cqh3OAfwd3RIfumS/uvoxrK5rpgadsDgEMQ0i9Gv8Gp5qQ=
X-Received: by 2002:a05:651c:111a:: with SMTP id d26mr3759126ljo.168.1573157169530;  Thu, 07 Nov 2019 12:06:09 -0800 (PST)
MIME-Version: 1.0
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com>  <118e630a-3f04-4aa9-8c1f-8083194865e4@www.fastmail.com> <9EC2E60F-6044-4135-A802-1665028E6075@ericsson.com> <54B33418-28D8-4176-A2EE-29FF27E5CE44@csperkins.org> <8dd558db-6f22-487f-a714-9f0ba71e74dc@www.fastmail.com>
In-Reply-To: <8dd558db-6f22-487f-a714-9f0ba71e74dc@www.fastmail.com>
From: Bernard Aboba 
Date: Thu, 7 Nov 2019 12:05:58 -0800
Message-ID: 
To: Martin Thomson 
Cc: Mirja Kuehlewind ,  tsvwg IETF list , "saag@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000440da90596c73241"
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Nov 2019 20:06:14 -0000

--000000000000440da90596c73241
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Martin said:

"To take the example of capacity planning, I had a great conversation about
18 months ago with Lee Howard about what that might look like in the
presence of more opaque data flows between endpoints.  I don't think that
we reached a specific conclusion, but it was refreshing to talk about the
actual problem and not get bogged down in the detail of specific
techniques.  Though the discussion touched on many existing and potential
methods, our focus never left the important question of what the goals were
and how there might be some shared interest in achieving that goal."

[BA] Indeed, it would be very useful for there to be an IETF document that
covered the manageability problem (including capacity planning) from a
variety of perspectives, including that of the endpoints and application
service providers.  Unfortunately, draft-ietf-quic-manageability is not
(yet) that document.

On Wed, Nov 6, 2019 at 6:16 PM Martin Thomson  wrote:

> On Wed, Nov 6, 2019, at 20:58, Colin Perkins wrote:
> > It certainly wasn=E2=80=99t my intent with this draft to say that all t=
hese
> > practices should be kept; rather to stimulate the discussion about what
> > should be preserved, what it=E2=80=99s necessary to find alternatives f=
or; etc.
> > If this doesn=E2=80=99t come across clearly in the draft. we should fix=
 it.
>
> Thanks Colin,
>
> I didn't start with that expectation and the introduction does a fine job
> of setting this out.  However the draft makes some very strong statements
> in the conclusion and - in a few places - the body that leave very little
> room for interpretation.
>
> I'm happy to help identify specific cases, but it seemed to be fairly
> consistent throughout.  For the bulk of the document, perhaps the right
> thing to do is take another pass with a critical eye.  I don't know what =
to
> do about the conclusions section though.
>
> I just want to say that while I appreciate the effort taken to document
> techniques, I'm not entirely convinced that it is the only way forward.
> Discussion of existing practice can distract from the underlying needs.
>
> To take the example of capacity planning, I had a great conversation abou=
t
> 18 months ago with Lee Howard about what that might look like in the
> presence of more opaque data flows between endpoints.  I don't think that
> we reached a specific conclusion, but it was refreshing to talk about the
> actual problem and not get bogged down in the detail of specific
> techniques.  Though the discussion touched on many existing and potential
> methods, our focus never left the important question of what the goals we=
re
> and how there might be some shared interest in achieving that goal.
>
> Being able to focus on the underlying requirements like that can be hard,
> but my sense is that this is where we'll need to reach before anything
> meaningful will happen.  I have to confess, despite enduring the spin bit
> debate, I find the fact that I have still trouble articulating exactly wh=
at
> requirements that mechanism addresses to be concerning.
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>

--000000000000440da90596c73241
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Martin said:=C2=A0

&qu=
ot;To take the example of capacity planning, I had a great conversation abo=
ut 18 months ago with Lee Howard about what that might look like in the pre=
sence of more opaque data flows between endpoints.=C2=A0 I don't think =
that we reached a specific conclusion, but it was refreshing to talk about =
the actual problem and not get bogged down in the detail of specific techni=
ques.=C2=A0 Though the discussion touched on many existing and potential me=
thods, our focus never left the important question of what the goals were a=
nd how there might be some shared interest in achieving that goal."

[BA] Indeed, it would be very useful for there to be=
 an IETF document that covered the manageability problem (including capacit=
y planning) from a variety of perspectives, including that of the endpoints=
 and application service providers.=C2=A0 Unfortunately, draft-ietf-quic-ma=
nageability is not (yet) that document.=C2=A0=C2=A0

On Wed, Nov =
6, 2019 at 6:16 PM Martin Thomson <=
mt@lowentropy.net> wrote:
On Wed, Nov 6, 2019, at 20:58, Colin Perkins wrote:

> It certainly wasn=E2=80=99t my intent with this draft to say that all =
these 

> practices should be kept; rather to stimulate the discussion about wha=
t 

> should be preserved, what it=E2=80=99s necessary to find alternatives =
for; etc. 

> If this doesn=E2=80=99t come across clearly in the draft. we should fi=
x it.



Thanks Colin,



I didn't start with that expectation and the introduction does a fine j=
ob of setting this out.=C2=A0 However the draft makes some very strong stat=
ements in the conclusion and - in a few places - the body that leave very l=
ittle room for interpretation.



I'm happy to help identify specific cases, but it seemed to be fairly c=
onsistent throughout.=C2=A0 For the bulk of the document, perhaps the right=
 thing to do is take another pass with a critical eye.=C2=A0 I don't kn=
ow what to do about the conclusions section though.



I just want to say that while I appreciate the effort taken to document tec=
hniques, I'm not entirely convinced that it is the only way forward.=C2=
=A0 Discussion of existing practice can distract from the underlying needs.=




To take the example of capacity planning, I had a great conversation about =
18 months ago with Lee Howard about what that might look like in the presen=
ce of more opaque data flows between endpoints.=C2=A0 I don't think tha=
t we reached a specific conclusion, but it was refreshing to talk about the=
 actual problem and not get bogged down in the detail of specific technique=
s.=C2=A0 Though the discussion touched on many existing and potential metho=
ds, our focus never left the important question of what the goals were and =
how there might be some shared interest in achieving that goal.



Being able to focus on the underlying requirements like that can be hard, b=
ut my sense is that this is where we'll need to reach before anything m=
eaningful will happen.=C2=A0 I have to confess, despite enduring the spin b=
it debate, I find the fact that I have still trouble articulating exactly w=
hat requirements that mechanism addresses to be concerning.



_______________________________________________

saag mailing list

saag@ietf.org

https://www.ietf.org/mailman/listinfo/saag




--000000000000440da90596c73241--


From nobody Fri Nov  8 01:12:27 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632B612080F; Fri,  8 Nov 2019 01:12:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaDTEIikJ-gJ; Fri,  8 Nov 2019 01:12:15 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id A7562120122; Fri,  8 Nov 2019 01:12:14 -0800 (PST)
Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 1247F1B00081; Fri,  8 Nov 2019 09:12:06 +0000 (GMT)
Message-ID: <5DC53165.3030601@erg.abdn.ac.uk>
Date: Fri, 08 Nov 2019 09:12:05 +0000
From: Gorry Fairhurst 
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Colin Perkins 
CC: David Schinazi , =?UTF-8?B?TWlyamEgS8O8aGxl?= =?UTF-8?B?d2luZA==?= ,  Joe Touch , tsvwg IETF list , "saag@ietf.org" 
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com>  <9687A3AC-870A-46E1-BD2A-7041410CFF75@ericsson.com>  
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Nov 2019 09:12:18 -0000

On 07/11/2019, 19:10, Colin Perkins wrote:
> David,
>
> I don’t know what Mirja thinks is the desired outcome, but my intent – 
> as an author of the draft – is that you think about the issues raised 
> and how they relate to your protocol, then make an informed decision 
> about what parts of the headers to protect and what parts it might 
> make sense to expose.
>
> And, to be explicit, if you think about the issues discussed in the 
> draft and then decide to encrypt all the transport layer headers, 
> /that’s fine by me. /
>
> Colin
>
+1.

My personal view is that this seeks to provide input to those developing 
IETF specifications to describe how they have considered PM, and, if the 
attack is relevant to the work to be published, be able to justify 
related design decisions.

Gorry

>
>> On 6 Nov 2019, at 17:52, David Schinazi > > wrote:
>>
>> Hi Mirja,
>>
>> Perhaps I misunderstood the document. The draft makes a lists
>> of issues that arise when you encrypt transport headers, then
>> concludes with a call to action to take these issues into
>> consideration. In your reading, what is the desired outcome of
>> this document? As a protocol designer, what do you expect me
>> to do differently when I design my next protocol after reading this
>> document? The tone seems to imply that I should leave some
>> headers unencrypted in order "to ensure network operators,
>> researchers and other stakeholders have appropriate tools to
>> manage their networks". If this is not the intent of this draft, then
>> what is it? What exact outcome or we hoping for?
>>
>> Thanks,
>> David
>>
>>
>> On Tue, Nov 5, 2019 at 11:14 PM Mirja Kuehlewind 
>> > > wrote:
>>
>>     Hi David,
>>
>>     This document is not intended to discourage header encryption but
>>     to make sure that operational considerations are taken into
>>     account when exactly design new protocols that should have header
>>     encryption (as well as payload encryption). If you think this
>>     document discourages header encryption, we need to fix that.
>>     Would be helpful if you could indicate to the authors where you
>>     think this is the case.
>>
>>     Mirja
>>
>>
>>     Am 05.11.2019 um 23:10 schrieb David Schinazi
>>     >:
>>
>>>     I also oppose publication of draft-ietf-tsvwg-transport-encrypt.
>>>     This document discourages transport header encryption and
>>>     publishing it could harm future protocol development.
>>>
>>>     David
>>>
>>>     On Tue, Nov 5, 2019 at 1:04 PM Joe Touch >>     > wrote:
>>>
>>>
>>>
>>>         > On Nov 5, 2019, at 12:35 PM, Mirja Kuehlewind
>>>         >>         > wrote:
>>>         >
>>>         > What I’m hearing is that 2-3 people think this is not
>>>         aligned but don’t actually say why exactly they think that
>>>
>>>         That’s not what we’re saying. We gave reasons.
>>>
>>>         Joe
>>>
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org 
>> https://www.ietf.org/mailman/listinfo/saag
>
>
>
> -- 
> Colin Perkins
> https://csperkins.org/
>
>
>
>


From nobody Fri Nov  8 09:28:06 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920551208E3; Fri,  8 Nov 2019 09:27:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Level: 
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.082, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKpCiReyyiSf; Fri,  8 Nov 2019 09:27:58 -0800 (PST)
Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) (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 3AFE112088D; Fri,  8 Nov 2019 09:27:58 -0800 (PST)
Received: by mail-oi1-f179.google.com with SMTP id l202so5940301oig.1; Fri, 08 Nov 2019 09:27:58 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o0t3sLXi0j3TVGQjYlXTjdT10qLpwl0urho7VVfPwwo=; b=FRN6gExKYNvgHBILlyH95oxgPjNlJJfXllEAELojKXpvNiveVT6+w8cfXkeZP9bBWw NK6XRpSgGT1IiP8+FT3MI7iJEzW2Q6CnRa7y8xS+UB9gsTByeT4G2muCeRdKgHGQ5Yfh SR3EQUeIud/WftSnIj8DU/AIO+RT6ObSZWbvaXYU6TuoFDuLhsvOIYqvGPxfmUQ+iG1V Tl/nkaZM9Bh28gZLmYTrcikyXNWKCpRjlQ9LcfF4VmslargsLXDEb5gft+vElx72vNLD /wQqzmRb9WjHaTbQODIaUHMg5Gy15BcFAIUp4cyDy861GQLZARvGU9hE+1EZYvecXh7Z Q2cg==
X-Gm-Message-State: APjAAAXTTp0sEAoRn48KXXKdRIUXaubTtUfJGnm0kbPfdc5IPCHKT3vc 6BeCImU4mZcSFQZpGvywGJ8UV/0j4n7c8/dCJNDGKw==
X-Google-Smtp-Source: APXvYqw4MUjB4NNVIB2CcbV8oSDfL6RmJkEPRCt8TYk5Y59iqazzv1exttYwLmKAsjeaaL4T8iqgVar6PKQi1UZkbrA=
X-Received: by 2002:aca:5058:: with SMTP id e85mr10972843oib.100.1573234077175;  Fri, 08 Nov 2019 09:27:57 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Phillip Hallam-Baker 
Date: Fri, 8 Nov 2019 12:27:47 -0500
Message-ID: 
To: Eric Rescorla 
Cc: tsvwg IETF list , IETF SAAG 
Content-Type: multipart/alternative; boundary="00000000000051954b0596d91a31"
Archived-At: 
Subject: Re: [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Nov 2019 17:28:05 -0000

--00000000000051954b0596d91a31
Content-Type: text/plain; charset="UTF-8"

I have a slightly different perspective on this. To me, a Web Server is
just another type of middle-box.

Specifically, it is a middle-box between the content provider and the
content-consumer. And those are the ends I wish to achieve end-to-end
security between.

Transport security is useful but that has been our only hammer for 25 years
now. Data in transport is a solved problem, the breaches occur in data at
rest. And as a famous Snowden breach slide shows: 'TLS added and removed
here'.

This is not to say anyone made an error in design. What was possible when
we were looking at this in 1993 was considerably less than what we can do
today. We were using export grade encryption for a start. And we could
barely use one layer of encryption. And so we adopted TLS as a Golidlocks
solution that provided most of the network layer security we need and most
of the application layer security.

I think we need to change our perspective somewhat because we need TLS and
Data at rest security (DARS) and we do need certain types of metering. But
in the network, not in the inter-network.

Alice uploads content to Carol's Cloud, Bob reads it with his browser.
There are three (potentially) separate networks here.

Alice's local network
Bob's local network
Carol's local network

Alice, Bob and Carol might all see the need to do certain types of
monitoring. But the principle of least privilege should apply in each case.
Carol's need to monitor her network is strictly limited to Carol's needs.

In addition, we have the inter-network which as Einer Stefferud used to
remind us, isn't a network, it is a network of networks. And so the
communication graph is:

Alice <-> Internet <-> Carol <-> Internet <-> Bob

And that matters, because the primary concerns we are addressing in TLS are
the ones raised by that 'Internet' hop. The advantage of IPSEC over TLS is
that it allows us a much more closely targeted solution that locks down the
Internet hop without affecting anything else. The disadvantages of IPSEC...

So what I see happening at the moment is QUIC/TLS morphing into what IPSEC
was originally trying to do. Which is fine except that as EKR is point out,
this is compromising us at the upper layers. Which is where Shen and SHTTP
were originally intended to work.


I am actually planning to use three layers of encryption for Mesh services

Transport - (TLS) to provide traffic analysis resistance.
Presentation - (DARE) to authenticate client/server interactions
Data - To protect data at rest

The concern that Transport Layer Security inevitably creates is that any
scheme which provides any traction against traffic analysis is going to
make monitoring difficult because it is traffic analysis.

In summary, there is no way to square this circle because what
distinguishes traffic analysis attack from monitoring is intent and
machines can't tell the intent. And so if people want to expose information
at the lower layers, they are going to need to think about additional
layers of crypto being added at the top.

--00000000000051954b0596d91a31
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I h=
ave a slightly different perspective on this. To me, a Web Server is just a=
nother type of middle-box.

Specifically, it is a middle-box between the content provider and the con=
tent-consumer. And those are the ends I wish to achieve end-to-end security=
 between.

<=
/div>
Transport secur=
ity is useful but that has been our only hammer for 25 years now. Data in t=
ransport is a solved problem, the breaches occur in data at rest. And as a =
famous Snowden breach slide shows: 'TLS added and removed here'.

This is not to say anyone m=
ade an error in design. What was possible when we were looking at this in 1=
993 was considerably less than what we can do today. We were using export g=
rade encryption for a start. And we could barely use one layer of encryptio=
n. And so we adopted TLS as a Golidlocks solution that provided most of the=
 network layer security we need and most of the application layer security.=


I think we need to chang=
e our perspective somewhat because we need TLS and Data at rest security (D=
ARS) and we do need certain types of metering. But in the network, not in t=
he inter-network.

Alice u=
ploads content to Carol's Cloud, Bob reads it with his browser. There a=
re three (potentially) separate networks here.

Alice's local network
Bob's local network
Carol's local network

Alice, Bob and Carol might all=
 see the need to do certain types of monitoring. But the principle of least=
 privilege should apply in each case. Carol's need to monitor her netwo=
rk is strictly limited to Carol's needs.

In addition, we have the inter-network which as Einer =
Stefferud used to remind us, isn't a network, it is a network of networ=
ks. And so the communication graph is:

Alice <-> Internet <-> Carol <-> Internet &=
lt;-> Bob
And that mat=
ters, because the primary concerns we are addressing in TLS are the ones ra=
ised by that 'Internet' hop. The advantage of IPSEC over TLS is tha=
t it allows us a much more closely targeted solution that locks down the In=
ternet hop without affecting anything else. The disadvantages of IPSEC...=
=C2=A0

So what I see happ=
ening at the moment is QUIC/TLS morphing into what IPSEC was originally try=
ing to do. Which is fine except that as EKR is point out, this is compromis=
ing us at the upper layers. Which is where Shen and SHTTP were originally i=
ntended to work.


I am actually plan=
ning to use three layers of encryption for Mesh services

Transport - (TLS) to provide traffic analys=
is resistance.
=
Presentation - (DARE) to authenticate client/server interactions
Data - To protect data at=
 rest

The concern that Tr=
ansport Layer Security inevitably creates is that any scheme which provides=
 any traction against traffic analysis is going to make monitoring difficul=
t because it is traffic analysis.

In summary, there is no way to square this circle because what d=
istinguishes traffic analysis attack from monitoring is intent and machines=
 can't tell the intent. And so if people want to expose information at =
the lower layers, they are going to need to think about additional layers o=
f crypto being added at the top.


--00000000000051954b0596d91a31--


From nobody Sat Nov  9 09:41:19 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C1C1200DF; Sat,  9 Nov 2019 09:41:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.646
X-Spam-Level: 
X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_ou4yZr77mp; Sat,  9 Nov 2019 09:41:11 -0800 (PST)
Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) (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 97C7C12001E; Sat,  9 Nov 2019 09:41:11 -0800 (PST)
Received: by mail-ot1-f50.google.com with SMTP id r24so7931938otk.12; Sat, 09 Nov 2019 09:41:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4Z2nrpbkl7DAGEImb1j1IU8wCyTShzhSLhrCU2apWGM=; b=PtNSLUwdET0DSoMOoAMi2beRQWFFOlIuDjFXjGwZftlN1vXZrKQ2T/yhILezVUkUyJ pgI3x/Ej8nWv5Sx66PJrGHLGz6c/NtpGqZqUDIZ4Kp+VgroT78PfND2XAPG0+I8oDYGJ 3Nqh4reYKsta9eWqC7SpvPAfVdov6TliPY/thUvirXItVXR4WZbBse4GOGw/aPLLsCAw TZoFr5UJZJPHQ+/5D9vVMNaZsm04W4k3GrujNK8yEZdVGLEnC5t4L76t1UBnQ1/nRc5L TDo+hFNtBMs5CWn/Dcf55wmvByLZURuLWyjYmeZyI9cXAQcwcx+CaG8fRa9YtEOTHemd xzGw==
X-Gm-Message-State: APjAAAWsc6kscYg43JBvhs8D4C50PRXLVt2hWE7wFJ7YCG0KyXJeEOul scyIp9wZE7u+TeLTzwxgK3rBH5yuQIQLpKP67VIObQ==
X-Google-Smtp-Source: APXvYqx11V670DL4Z1T5oy4mrxGKV222w34anhLmSbBKyv93X1pzyVFhKq96FcX0kwYkoNPTdJwcrUAaY3tFw2rq1Y8=
X-Received: by 2002:a9d:6f15:: with SMTP id n21mr11002779otq.231.1573321270727;  Sat, 09 Nov 2019 09:41:10 -0800 (PST)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Phillip Hallam-Baker 
Date: Sat, 9 Nov 2019 12:40:59 -0500
Message-ID: 
To: Eric Rescorla 
Cc: tsvwg IETF list , IETF SAAG 
Content-Type: multipart/alternative; boundary="0000000000007598730596ed6787"
Archived-At: 
Subject: Re: [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 09 Nov 2019 17:41:13 -0000

--0000000000007598730596ed6787
Content-Type: text/plain; charset="UTF-8"

People have asked me for an infographic to illustrate my point. Well I only
have text here.

Encryption is like a too-short blanket when you are trying to sleep in bed.
If you pull it up over your shoulders, you get cold toes. If you cover your
feet, the rest of you gets cold. There is nowhere that you can put that
blanket that is going to keep all of you warm and they only come in one
size. So what you need is more blankets.

If we only have one layer of encryption for headers and payload, it is all
or nothing. If the payload is encrypted inside the encrypted transport, we
can strip off the transport encryption with much less risk.


And that is part of what we will be discussing in the MATHMESH BOF in the
first session of the first day in Singapore.

--0000000000007598730596ed6787
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


People have asked me for an infographic to illustrate my poin=
t. Well I only have text here.

Encryption is like a too-short blanket when you are trying to sleep i=
n bed. If you pull it up over your shoulders, you get cold toes. If you cov=
er your feet, the rest of you gets cold. There is nowhere that you can put =
that blanket that is going to keep all of you warm and they only come in on=
e size. So what you need is more blankets.

If we only have one layer of encryption for headers and p=
ayload, it is all or nothing. If the payload is encrypted inside the encryp=
ted transport, we can strip off the transport encryption with much less ris=
k.


And that is part of what we wi=
ll be discussing in the MATHMESH BOF in the first session of the first day =
in Singapore.
<=
br>




--0000000000007598730596ed6787--


From nobody Sun Nov 10 21:32:43 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC71A1201C6 for ; Sun, 10 Nov 2019 21:32:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuPb8i-RQq5M for ; Sun, 10 Nov 2019 21:32:40 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA3FF1201AA for ; Sun, 10 Nov 2019 21:32:39 -0800 (PST)
Received: from [192.168.42.200] (unknown [209.171.88.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by tuna.sandelman.ca (Postfix) with ESMTPSA id D974F3897C for ; Mon, 11 Nov 2019 00:29:31 -0500 (EST)
To: saag@ietf.org
References:   
From: Michael Richardson 
Openpgp: preference=signencrypt
Autocrypt: addr=mcr+ietf@sandelman.ca; keydata= mQGNBF3EaO8BDADNdcAioLgGWFMLcmR6SuX1ioVH0v1fcprk0Wl1Qc7LCdwqj+QSdv84oNe1 h6lTf+CsmzO+TZtL+2iUzR3WHyXViEJcSHldx2YIfgxGZkzqgqozDj2IoHCU6ezhQz2TwJO7 l6H7fIPBbemIu8qVezwP1azLVq3D+cXZkkOvsFhTiw1bF/WF8lIIAYEbQ4YyYyjk5DS30x59 kxFNSv6om8rqSAKs2epneEWpzybB0J82dBnB4VDDsMmTJWPkszvQoCjCbrvgDAuoRtL5su2V IQWw61O6N5p1mwJ7VQoPDWYyeFH4NrVlL71FwRLueVPle76Oi3ybE2IMUvHZ/e42jVBizlQj 1N/2x7mGk35Zrvz0WHjZLcFJYJkDOnLsMU1smhdRtxNfYf576DTlzQKVcLmNCfOKAWnz4DdQ gRI4pNs24NoxLXl5v5mhDHRX5Me+CuckkFNGSlCXZ5kMXzPPFAV6CwMlm65P1tVJq9td8Uh0 5I5okPcENk5iY+FniqMXamsAEQEAAbQlTWljaGFlbCBSaWNoYXJkc29uIDxtY3JAc2FuZGVs bWFuLmNhPokB1AQTAQgAPhYhBKMP9ag1YAG1i9s8WHACrsLM2IBDBQJdxGjwAhsDBQkB4TOA BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEHACrsLM2IBDeJ4MAMvUmQjFqXgsg4KhIWQb QBcgNPxrtp9jW/i2m//0zVA2iGxbeTOZD6cmcNDRj153TbSGTEH03oJIeYbdwlOCe5blA6h4 FTEBwt/qX+mjRYKXuA3uvFdEJQJPFcaWFF68rgQMxgLPPUAnTYQ00SqaBEg+Vh4gSh8yOHuU 8VTgenm4JpBdJQx7/7syvIaQilhN2fF25CcA7hArmebkaG691x+cFD60s8ITI9PSf82SVUnp mspJTGptxFxH/GM/kW40iB4tUjZrUSQfTfWIXA/5j005XbVbo1DIYirWWNK0WPVsh51ullzt u37BDVj/SmgbGhvTUXwsBi4b+T2cJHLt+8QT/KM8OA+UA8AlkNPleKtOzxsg5z22m0fzollE Zcw9VIojPKIhTUYU79InmibEUoGfb05MFJM9aXX5BMoJNpKcB92PKI/gMsrxMwH1exs0cY/E K/xYdpFo3rTPw5KSsDkr7ZbqGPgz+QP2H+TLwgLKMFTBlVKpj+oqBnqeEVVrC7kBjQRdxGjv AQwA0T5oxtsQkr3I3FxBi5TkNSh0HZ7ND5xJJkyM6wLAsljLk5KhdcxjTlo6htNjRUuUy1Ld 0bARmezZf5GqKRh6fR7WX9EdYjGm0RbcK3tQ3L61h4p3EOplKgMSoGpGamLSDzRs3SAJu4GF iHfzQ20R0PxBN/CbzWh6ROPcxQ8wwt8G4ZOwU4zXfSmZqZwNp/6xosLCl3TKvFWX6421Vb/L WAOOAz/xSyS0GCUs/grBUfzu95+TTskRk7kkeYSQ//1Oq9srPlIU9lx3Y4jDgPkXIwd9eXOq e7/5y4bQkILGGMIux878DhAED865hPMBuHlkDNzIuo6HhjRkShLBM16yQhK+NJ0WI77+m1FD 7r5QL6iU57zI/B5U03JKZhW0Pm3Bm+RWZPWGVawkPUnvxoMFbw+x1+MnKZgXwRmRmbFsCHhD VmrDKLWXRm9QvTB+k0ZnTdme9ZwSNCn0CXME2rNtOR39Yh6dsWH2nMPvg/G5iUmZyO9Oa01W xhWcXnKA+v+VABEBAAGJAbwEGAEIACYWIQSjD/WoNWABtYvbPFhwAq7CzNiAQwUCXcRo7wIb DAUJAeEzgAAKCRBwAq7CzNiAQwaOC/4olaVHP/npCn2CrtAOstbyytePFmS9NAwdT8A6mA4s +WshPo1DhKEnKnYzW/S0jLf0iqlzT8LUqu2G8f6elGzghRR8WJVn0zH7LVCKMWo/tHE2rWyi Q1zuX9o7ChTodQ8cXx0lM1xdY8v4Amc5fFxyyhJprKZAtiDJ897vv1jP09fWLEBhaDsHqLhg ckQpIoee0Id4FXGt7wxDsPwa64SUUCTYdt98EiLoUY6eAWQnyelgbFU+D/bxkeytmmvWOVr7 UXVMQlEKG7E31G1XQMk6sFATF1dwiH/laLQPLuMYr7owUC+ef/YAWSHMTYeIfwdt/Yd8ngJ8 SFA6Uc+Bjr0i1jdnxS5H3EF4V1FNY2rh4zNPVNj2UrZaShK/XH4hnTJUYL5fo2ygt2ZM98ot 8lIsHGAJQHDl2/EffLsAL85pXDPl8E+nvOUOE1kwmfOgv/oV8z0469qu/hNiEpGp8xKBqGEL NWHd8fH5S9JxVix9Ed34vi9Cyf24iLjiWZBemXw=
Message-ID: <2cd8eb79-12b4-8a1a-e5a9-938a98a68c51@sandelman.ca>
Date: Mon, 11 Nov 2019 13:32:30 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wyUXnMwxma4rrruslkAYvmwxMfoHpeOSJ"
Archived-At: 
Subject: Re: [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Nov 2019 05:32:42 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--wyUXnMwxma4rrruslkAYvmwxMfoHpeOSJ
Content-Type: multipart/mixed; boundary="9KctCTByRZuJBoTSP1VCb0Ol4rCy6vrDx";
 protected-headers="v1"
From: Michael Richardson 
To: saag@ietf.org
Message-ID: <2cd8eb79-12b4-8a1a-e5a9-938a98a68c51@sandelman.ca>
Subject: Re: [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
References: 
 
 
In-Reply-To: 

--9KctCTByRZuJBoTSP1VCb0Ol4rCy6vrDx
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US



On 2019-11-10 1:40 a.m., Phillip Hallam-Baker wrote:
> People have asked me for an infographic to illustrate my point. Well I
> only have text here.
>
> Encryption is like a too-short blanket when you are trying to sleep in
> bed. If you pull it up over your shoulders, you get cold toes. If you
> cover your feet, the rest of you gets cold. There is nowhere that you
> can put that blanket that is going to keep all of you warm and they
> only come in one size. So what you need is more blankets.

That's an interesting analogy, and maybe it's the start a good infographi=
c.
But, can you please map this to our world?=C2=A0 What does it mean today =
pull
the blanket up over your shoulders, and how does that reveal the feet?

> If we only have one layer of encryption for headers and payload, it is
> all or nothing. If the payload is encrypted inside the encrypted
> transport, we can strip off the transport encryption with much less ris=
k.

Agreed, I get this.

>
>
> And that is part of what we will be discussing in the MATHMESH BOF in
> the first session of the first day in Singapore.
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag



--9KctCTByRZuJBoTSP1VCb0Ol4rCy6vrDx--

--wyUXnMwxma4rrruslkAYvmwxMfoHpeOSJ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQGzBAEBCAAdFiEEow/1qDVgAbWL2zxYcAKuwszYgEMFAl3I8m4ACgkQcAKuwszY
gEMUagv/dgWKEq6aplIRshmhUvYCZ6xjAzadXnbjc9ECRqLz/8yKPjGnMchxoytg
1LLbdrQY/cuhp4ysWVOVWphXHwz4AejaF0xpkpMiHXvNAG3wFyipf3NCYla8Ka3n
P73qjxePoHH94tqyT/qKesy0Kccqh0ihSuoB0KQM1/x80vPZtn/xjJUy/MKSkfeX
IQFAiDpbMmWLdMhN98Xb0fq1S3txFJxU/WB1hoJxeGkbDHWaXwQS/S+Z5EezO34H
dIGabi5wJSYKt1a1TlPARLimCffeM8uQdAVExArS9cu44qqC4DDt7VdZjwYK1Ayr
f2FCOrx+i+/TdPv8iOJzPO9PZ2j9ufxO93Szeleb0VrR+QDXvP5bUIMJvWHwADI2
EpswKj4ywcMJNl59icG4/nVGwSp84oIY/9GTK+N8bg4TApzEZ4FsbmZcYuPEjJzo
6w0hPCtpKQ4/P5iwi6xQVlHJI6g7yZCes9q/7MGzEx3KjIcoiJKUEMmSLNh5/bBh
Q662xzbd
=r9Qm
-----END PGP SIGNATURE-----

--wyUXnMwxma4rrruslkAYvmwxMfoHpeOSJ--


From nobody Mon Nov 11 17:12:51 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF58D12003F; Mon, 11 Nov 2019 17:12:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=XW6830Ho; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=IKegWSIK
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 wo8ESSM9o8Yg; Mon, 11 Nov 2019 17:12:46 -0800 (PST)
Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (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 9B8B6120025; Mon, 11 Nov 2019 17:12:44 -0800 (PST)
Received: from pps.filterd (m0170393.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAC14h2v009995; Mon, 11 Nov 2019 20:12:42 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=smtpout1; bh=zryO4hOqPe3b8sUtcOpX3mDD1QTbasTdRSIU3pSN4yo=; b=XW6830HoxZD4PpTrj0FvGxt9pG1m9c2UhJiAefgKpHmLo3IfwiBCVb3/zbqgJ2Ir9l+K G8SiV0C4iRPLp7Xw+uOFeL6wqEHRrsEsRUXbSNxxqWfJg5E86aotXeSNpqlkdRp1BAeY TBhcHCwdT+OtLiVSgBNwG1T+8HNKiVCIzYKZ08xDlLCyYc0B+N55JvK6W44Q+7OnHkVq 9fKFdQPYPxyJPlKP3muuZWEdHUSkj/TPdt/O612+irPyRa8U7cPniVXGuJyPe2NDENJZ q3ioS3VdeQ3WPuZg2suB46q9VM1M9HigN9GnIFd9pJqdQkP7CX8L/oDnYe3u7kYLZO1X tQ== 
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0a-00154904.pphosted.com with ESMTP id 2w5snkt2q3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Nov 2019 20:12:42 -0500
Received: from pps.filterd (m0134318.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAC1CehI069087; Mon, 11 Nov 2019 20:12:41 -0500
Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp2050.outbound.protection.outlook.com [104.47.37.50]) by mx0a-00154901.pphosted.com with ESMTP id 2w5ryggph3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 11 Nov 2019 20:12:41 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ia/Hy28jjE5aciUCVkhkTfhZi6LFN+oMyQdznE9lCAXWR/nfCn/akbG0fwHwCqL78WdU/5/sBQSofVrlyqFW9AQqPaQ2sMlFwVJvHxDd7XNyAcefTOPZ87fPlt96lKxS+Urbt5VKFIB/aJs03Fqx/1Ee0rRbyF7bIvqYh2WF9E0UhMrP/6GPXInPbtWxrs5EylK0QXZYbYqH3EnAqMv/oOgVXPHENCSKZkll7wM8gGSDHvVazOGGnzkLKm8wbjLmi3qUX3g3vshI99/GqXR77sHYH9fjaZkptk2obsirCaUmMRxvFYeBRGJvxtPgE6zibwtCRA7RjZ8+pJ+8dvcaaQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zryO4hOqPe3b8sUtcOpX3mDD1QTbasTdRSIU3pSN4yo=; b=QKMoDgOpJ8u0+DU3348H0oeC3doOeiz4g3FWiILXPpKcgJjLB/pi97dQiLyAYu8FcVxg9OiKfmzqtowKElYUrGkIeHNoKUnX83LA0UsBBOExrvY8MuCbtZCLnchm1VChy/E1xJzbZoSFPnuhGNKaPN6j4JA1D3Eamu0KTP0PNqK23gHGwIZU5cRgxy+4/UR0eKnZdlHybTKxhNqhpCTHuCNycLrSitnhiCrx1gtj7sRhXQZ2GGybPP063qoOMKGEbWU5+wC6Os+VqmJcex4m8de8MIag946i/ox1kkXaVEUnyr1W8nNSdKz5Y2LtFlv+Qi7jlXStPNhfFetP1UwUog==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dell.onmicrosoft.com;  s=selector1-Dell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zryO4hOqPe3b8sUtcOpX3mDD1QTbasTdRSIU3pSN4yo=; b=IKegWSIKR+1yipkTtgU8hMJYAgOu7Mjqq8BDEoYX42BjsHvxX4FXkn71ywVpDBhBISW6iYyJjlOr8gn43aJGkCN9Gx/lpH9feVceVfdAWITXSxvK5kYWFr9LJcGjA/3EyXv/1E62tk0IDFrOCRrZCKQBwTOg0TSELvMRQYx6wsE=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (10.186.145.137) by MN2PR19MB2592.namprd19.prod.outlook.com (20.179.82.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.20; Tue, 12 Nov 2019 01:12:34 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8893:d435:ce32:3594]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8893:d435:ce32:3594%6]) with mapi id 15.20.2430.027; Tue, 12 Nov 2019 01:12:34 +0000
From: "Black, David" 
To: "saag@ietf.org" , "opsawg@ietf.org" , "tsvwg@ietf.org" 
CC: tsvwg-chairs , "Black, David" 
Thread-Topic: TSVWG: Conclusion of WGLC for draft-ietf-tsvwg-transport-encrypt-08
Thread-Index: AdWY9jtimOrb4bahSyKqcsQbapr+5A==
Date: Tue, 12 Nov 2019 01:12:34 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2019-10-08T21:02:00.0767379Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public
x-originating-ip: [137.69.117.201]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0c3e51e6-13d8-4ce4-4b44-08d7670d6631
x-ms-traffictypediagnostic: MN2PR19MB2592:
x-ms-exchange-purlcount: 1
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: 
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 021975AE46
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(136003)(346002)(396003)(366004)(7502003)(199004)(189003)(786003)(55016002)(81166006)(81156014)(606006)(256004)(14454004)(478600001)(186003)(66446008)(316002)(966005)(8676002)(236005)(8936002)(9686003)(54896002)(6306002)(54906003)(7696005)(5660300002)(66946007)(110136005)(76116006)(450100002)(52536014)(7736002)(26005)(71190400001)(6506007)(66574012)(486006)(71200400001)(107886003)(3846002)(99286004)(53546011)(102836004)(2906002)(33656002)(4326008)(86362001)(64756008)(66556008)(66476007)(476003)(6116002)(6436002)(790700001)(25786009)(74316002)(2201001)(2501003)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR19MB2592; H:MN2PR19MB4045.namprd19.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: dell.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: MivRteUqZ9isj2/AgKyUIfbFss3Ovatg2BDJjhXJukCk9zMCMGO/DN+84NcEKj/BnSNZD8fK7h3riXZEYGNsxIfgtO5Ou6b1wNVMML75YuxgpzaI6qtQdUqqG7iaM/BoEmsMy4z6BRQnhwCo0cm20YtZUId/KJvvQM5vSN0a5a6yOEyVH39aF5n+UDf4EZUZSqhozHcJCfSF7EtyRPS8WWJXTSWg8joJQ2wPaoYr6v8ha8+Z9K0ca2XaI9Wg9WD6TGCwFd9T0sLINtjOCqixFmRBFaOyH34vD76k6VXGOEjtCRm9u3kDU6RAZd9gGUjWNjR7bJ52HmLfR4I2pFi3SbcCbesUGbbQj565+lXIlm6YXzJHxMUSjuLDi3ho+LuXnBCP8z8z03KXrXudEZWNUOPTkG5lVkujS1jBe28/NR6dJ+TLZcV+WeyVYLeE0jMzWjYImoByu5opUZJPtbRXF1XRsds+GIvyzW9b4VZzUQI=
Content-Type: multipart/alternative; boundary="_000_MN2PR19MB40457F255E0BC44356B5996783770MN2PR19MB4045namp_"
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0c3e51e6-13d8-4ce4-4b44-08d7670d6631
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2019 01:12:34.1433 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: WJ58MK6Ei6EPTcmIk2aMgNqQHjJnaL13H3hu66nK+PjR2MkxjdJi0jRBi+V8njU6bAYjzFsUf+UYbsz/qQU3pA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB2592
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-11_07:2019-11-11,2019-11-11 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 bulkscore=0 mlxscore=0 spamscore=0 malwarescore=0 mlxlogscore=999 priorityscore=1501 lowpriorityscore=0 adultscore=0 suspectscore=0 clxscore=1015 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911120008
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 bulkscore=0 phishscore=0 spamscore=0 adultscore=0 clxscore=1015 suspectscore=0 priorityscore=1501 mlxscore=0 lowpriorityscore=0 malwarescore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911120007
Archived-At: 
Subject: [saag] TSVWG: Conclusion of WGLC for draft-ietf-tsvwg-transport-encrypt-08
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Nov 2019 01:12:50 -0000

--_000_MN2PR19MB40457F255E0BC44356B5996783770MN2PR19MB4045namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The TSVWG Working Group Last Call (WGLC) for this draft has now concluded. =
  I want to thank everyone for their contributions to the discussion.

The overall WGLC conclusion is that the draft needs to be revised, and ther=
e will be another WGLC.  A major goal of the draft revision will be for the=
 draft to take a roughly neutral stance on transport header encryption - ne=
ither in favor of nor opposed to, but rather with a primary purpose of expl=
aining some design considerations.   The recently-posted -09 version is a s=
tep in that direction, but there is more to come.

Thanks, --David (TSVWG co-chair and shepherd for draft-ietf-tsvwg-transport=
-encrypt)

From: Black, David 
Sent: Tuesday, October 8, 2019 5:09 PM
To: saag@ietf.org; opsawg@ietf.org
Cc: tsvwg-chairs; Black, David
Subject: TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 Octob=
er 2019

FYI - some OPS area and SEC area eyes on this TSVWG draft now (during WGLC)=
 would be a good thing ;-).

Thanks, --David (TSVWG co-chair)

From: Black, David >
Sent: Tuesday, October 8, 2019 5:06 PM
To: tsvwg@ietf.org
Cc: Black, David
Subject: WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 201=
9


This email announces a TSVWG Working Group Last Call (WGLC) on:



The Impact of Transport Header Confidentiality on Network Operation and

                       Evolution of the Internet

                 draft-ietf-tsvwg-transport-encrypt-08

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/



This draft is intended to become an Informational RFC.



This WGLC will run through the end of the day on Wednesday, October 23.

That should allow time before the Singapore draft submission cutoff for

the authors to revise the draft with any changes that result from WGLC.



Comments should be sent to the tsvwg@ietf.org list, =
although purely

editorial comments may be sent directly to the authors. Please cc: the

WG chairs at tsvwg-chairs@ietf.org  if you wo=
uld like the chairs to

track such editorial comments as part of the WGLC process.



No IPR disclosures have been submitted directly on this draft.



Thanks,

David, Gorry and Wes

(TSVWG Co-Chairs)


--_000_MN2PR19MB40457F255E0BC44356B5996783770MN2PR19MB4045namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











The TSVWG Working Grou=
p Last Call (WGLC) for this draft has now concluded.   I want to =
thank everyone for their contributions to the discussion.=



 


The overall WGLC concl=
usion is that the draft needs to be revised, and there will be another WGLC=
.  A major goal of the draft revision will be for the draft to take a =
roughly neutral stance on transport header
 encryption - neither in favor of nor opposed to, but rather with a primary=
 purpose of explaining some design considerations.   The recently=
-posted -09 version is a step in that direction, but there is more to come.=



 




Thanks, --David (TSVWG=
 co-chair and shepherd for draft-ietf-tsvwg-transport-encrypt)




 








From: Black, David <david.black@emc.com>=
; 

Sent: Tuesday, October 8, 2019 5:09 PM

To: saag@ietf.org; opsawg@ietf.org

Cc: tsvwg-chairs; Black, David

Subject: TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 2=
3 October 2019






 


FYI – some OPS a=
rea and SEC area eyes on this TSVWG draft now (during WGLC) would be a good=
 thing ;-).


 




Thanks, --David (TSVWG=
 co-chair)




 






From: Black, David <david.black@emc.com>


Sent: Tuesday, October 8, 2019 5:06 PM

To: tsvwg@ietf.org

Cc: Black, David

Subject: WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 Octo=
ber 2019






 


This email announces a TSVWG Working Group Last C=
all (WGLC) on:



 


The Impact of Transport Header Confidentiality on=
 Network Operation and


        &=
nbsp;           &nbs=
p;  Evolution of the Internet


        &=
nbsp;        draft-ietf-tsvwg-transport-=
encrypt-08


https://datatracker.ietf.org/doc/draft-ietf=
-tsvwg-transport-encrypt/


 


This draft is intended to become an Informational=
 RFC.


 


This WGLC will run through the end of the day on =
Wednesday, October 23.


That should allow time before the Singapore draft=
 submission cutoff for


the authors to revise the draft with any changes =
that result from WGLC.


 


Comments should be sent to the 
tsvwg@ietf.org list, although purely


editorial comments may be sent directly to the au=
thors. Please cc: the


WG chairs at tsvwg-chairs@ietf.org  if you would like the chairs to


track such editorial comments as part of the WGLC=
 process.


 


No IPR disclosures have been submitted directly o=
n this draft.


 


Thanks,


David, Gorry and Wes


(TSVWG Co-Chairs)


 








--_000_MN2PR19MB40457F255E0BC44356B5996783770MN2PR19MB4045namp_--


From nobody Mon Nov 11 23:07:07 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B5212016E; Mon, 11 Nov 2019 23:07:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level: 
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
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 XzMH_zRXH9LX; Mon, 11 Nov 2019 23:07:02 -0800 (PST)
Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 3105F120145; Mon, 11 Nov 2019 23:07:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1573542422; x=1605078422; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=U0OMiPdaIgA95nO98BKZhliN9ovsHho/XZ2tSQMdZho=; b=DzYOz4AwLEdsgtCbt5n0IOmE2vGRRzau8oTv0bm/OgMfFLpr5+VHFbpH Ja+OjSt6dYdVdjuL3hTBXHItvtq1JZYMrIIoTPUKwjAmptXfKBBUxU4CO XYeUFCSlIczRmlUXjCFe68KMZw39axkBrydEkG0VuNqS0SkSDnMFkM9N0 9v+i60m+qZp95E0MLKluB9c7sUbkrp+wXIrn9pvHKzbCgHSne72BMldSI xnEjpGuK1XPRPe9ZgQIhELK5EhLg8DMxk/8QP79KRwkAagYCZ5ydxqNu+ HgKQwBQHJtwSxF5yo+aL7SeaysO53iwpBN/uxcQQWChThi8uJZ0oV3Mf2 A==;
X-IronPort-AV: E=Sophos;i="5.68,295,1569240000"; d="scan'208";a="99375063"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing
Received: from uxcn13-ogg-a.uoa.auckland.ac.nz ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 12 Nov 2019 20:06:58 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.2) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 12 Nov 2019 20:06:57 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Tue, 12 Nov 2019 20:06:58 +1300
From: Peter Gutmann 
To: Tom Herbert 
CC: Stephen Farrell , David Schinazi , Joe Touch , "gorry@erg.abdn.ac.uk" , Mirja Kuehlewind , tsvwg IETF list , "saag@ietf.org" 
Thread-Topic: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
Thread-Index: AQHVlYavl0m+OZkGmkq1dk9tU/YKeqeHJEC3
Date: Tue, 12 Nov 2019 07:06:58 +0000
Message-ID: <1573542420083.60501@cs.auckland.ac.nz>
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com>  <1573035094775.62307@cs.auckland.ac.nz> <87d3bcef-42e4-1535-db1f-06a8408d38d5@cs.tcd.ie> <1573109463764.56084@cs.auckland.ac.nz>, 
In-Reply-To: 
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Nov 2019 07:07:06 -0000

Tom Herbert  writes:=0A=
=0A=
>The problems of protocol ossification and middleboxes meddling in E2E=0A=
>protocols has been discussed at length in IETF in various contexts.=0A=
=0A=
I'm aware of RFC 3234, which was written seventeen years ago and focuses on=
=0A=
middleboxes messing with application-layer data, as well as farcical stuff=
=0A=
like RFC 3424, of the same vintage, but it's mostly complaining rather than=
=0A=
actual rigorous analysis, and often seems to be based on opposition to=0A=
middleboxes as an article of faith, notoriously manifested in IPsec's "NAT =
is=0A=
bad, therefore we will make sure IPsec breaks NAT, because NAT is bad", whi=
ch=0A=
has caused endless headaches for pretty much anyone who's ever had to work=
=0A=
with IPsec ever since.=0A=
=0A=
In particular for this case, since the discussion is about header encryptio=
n=0A=
and not middleboxes in general, I'm not aware of any rigorous analysis of i=
ts=0A=
purported benefits, or even a clear statement of its purported benefits,=0A=
something like "here is a definition of the service that header encryption=
=0A=
provides, here is a real-world study showing that it provides this and=0A=
demonstrating that it can't be readily defeated".  Contrast this with the t=
wo=0A=
dozen plus studies that look at the analysis of encrypted traffic despite t=
he=0A=
encryption, an example being (just one picked at random) "Identifying HTTPS=
-=0A=
Protected Netflix Videos in Real-Time", Andrew Reed and Michael Kranch,=0A=
Proceedings of the 7th Conference on Data and Application Security and Priv=
acy=0A=
(CODASPY'17), March 2017, p.361.=0A=
=0A=
So when people complain that the draft doesn't say enough about all the Goo=
d=0A=
Things header encryption provides, I would respond that it does, it's cited=
=0A=
all of the available literature on the benefits of header encryption, and a=
ll=0A=
of the studies showing that it's effective, in Appendix B.=0A=
=0A=
The draft is actually quite restrained in this regard, as I mentioned in my=
=0A=
previous message the two notable examples of header encryption/protection=
=0A=
deployed at scale into the real world, IPsec and SSH, have both been a=0A=
disaster (for functionality, IPsec, and security, SSH), but it very politel=
y=0A=
omits mention of this.=0A=
=0A=
Peter.=0A=


From nobody Tue Nov 12 06:43:18 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58746120273; Tue, 12 Nov 2019 06:43:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5SNnBkTyt4m; Tue, 12 Nov 2019 06:43:14 -0800 (PST)
Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::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 28D8C12020A; Tue, 12 Nov 2019 06:43:14 -0800 (PST)
Received: by mail-oi1-x233.google.com with SMTP id l20so14946946oie.10; Tue, 12 Nov 2019 06:43:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jws/dHrRDLttxup3Lu54WSwKLTs55bwKbiX/NoYtYTg=; b=GyO19HPh+IpWOC50Sd9spCvEQEkHaqOMi1sYWu5nWTJPjaGKCeCjdfYaH7d5zVoTfz Qip6GBHtgN3+RYtV14I9zzVVO0T3OubSAU3JTe8zsYQo2+L4+dct7y3Qu7KBDMn8K3HN 2PGJ6bpBVhh2DTFtGYLhUuojShYgdPVmg+bRNI8UGwb6euJkkdE2XvIttZqa44tGCISh gTSIfse1uZvfZCq9rgtaJ16etzRODFncyQjkcCGB+vg0xiQlty7pjARJgyzLO/McqtiV LPUpzBAIOtlHChMEMNtRdd0FxARVolYTUveR8IfrHJi25D78tDYWWDSbJ6Aab8+djZez Q6vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jws/dHrRDLttxup3Lu54WSwKLTs55bwKbiX/NoYtYTg=; b=tD6j11QW0JCTmQq6WJiSwdsMp4AE41W7umlZ7SuwUHxh8tJRUxQlCqIHu6XNhcwLvC pBpGVrR9k/y3+yZRZyXMTuWjxh7h15uaiq97ufy8V5+lIU3XMUG5KUdfwLFFPi6ILqes PnWKe8xfV3xyLNwiy00Cc/Cj/Z6Dw45xeBXWx1XOa39S2915ErBzAbk2bSXhKWSWuioX 6PmD5bNSZ8O2riGtbxBngUGO596Nhqo7zR8Ryj8GHt/RL9awRdQoCkHe5sMPIjRGRdIj eEQnhofXYoPKsZGtZmynpmOLodDNYWDTJluoPwcNnAcjkIYUzfQuV+EC9+rwHizlpkpY Id1Q==
X-Gm-Message-State: APjAAAX4fB1WHvpDYKMXOTLTA8rOvLIH41p2a6ZWqZaFgidthgKrt/Wb oZVpEDW6tsQDYYJE8AFyoNb6SllrYMqjpeNAB9g=
X-Google-Smtp-Source: APXvYqxtMaCNvrYSm8fk32o98TKgPpY65GUpyqW1qTBT2AuB5Bf6O2L1qPtKrkxeOTEkaU6WYcVi9cyvqeIOAEdqyNs=
X-Received: by 2002:aca:280a:: with SMTP id 10mr4122186oix.119.1573569793475;  Tue, 12 Nov 2019 06:43:13 -0800 (PST)
MIME-Version: 1.0
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com>  <1573035094775.62307@cs.auckland.ac.nz> <87d3bcef-42e4-1535-db1f-06a8408d38d5@cs.tcd.ie> <1573109463764.56084@cs.auckland.ac.nz>  <1573542420083.60501@cs.auckland.ac.nz>
In-Reply-To: <1573542420083.60501@cs.auckland.ac.nz>
From: Kathleen Moriarty 
Date: Tue, 12 Nov 2019 09:42:37 -0500
Message-ID: 
To: Peter Gutmann 
Cc: Tom Herbert , "gorry@erg.abdn.ac.uk" ,  Joe Touch , tsvwg IETF list ,  Mirja Kuehlewind ,  "saag@ietf.org" , David Schinazi 
Content-Type: multipart/alternative; boundary="00000000000091ca1905972744c4"
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Nov 2019 14:43:16 -0000

--00000000000091ca1905972744c4
Content-Type: text/plain; charset="UTF-8"

On Tue, Nov 12, 2019 at 2:07 AM Peter Gutmann 
wrote:

> Tom Herbert  writes:
>
> >The problems of protocol ossification and middleboxes meddling in E2E
> >protocols has been discussed at length in IETF in various contexts.
>
> I'm aware of RFC 3234, which was written seventeen years ago and focuses on
> middleboxes messing with application-layer data, as well as farcical stuff
> like RFC 3424, of the same vintage, but it's mostly complaining rather than
> actual rigorous analysis, and often seems to be based on opposition to
> middleboxes as an article of faith, notoriously manifested in IPsec's "NAT
> is
> bad, therefore we will make sure IPsec breaks NAT, because NAT is bad",
> which
> has caused endless headaches for pretty much anyone who's ever had to work
> with IPsec ever since.
>
> In particular for this case, since the discussion is about header
> encryption
> and not middleboxes in general, I'm not aware of any rigorous analysis of
> its
> purported benefits, or even a clear statement of its purported benefits,
> something like "here is a definition of the service that header encryption
> provides, here is a real-world study showing that it provides this and
> demonstrating that it can't be readily defeated".  Contrast this with the
> two
> dozen plus studies that look at the analysis of encrypted traffic despite
> the
> encryption, an example being (just one picked at random) "Identifying
> HTTPS-
> Protected Netflix Videos in Real-Time", Andrew Reed and Michael Kranch,
> Proceedings of the 7th Conference on Data and Application Security and
> Privacy
> (CODASPY'17), March 2017, p.361.
>
> So when people complain that the draft doesn't say enough about all the
> Good
> Things header encryption provides, I would respond that it does, it's cited
> all of the available literature on the benefits of header encryption, and
> all
> of the studies showing that it's effective, in Appendix B.
>
> After work on RFC8404, I do think having such research conducted would be
beneficial.  This was one of the aims of the proposed group SMART.  If
there is interest in conducting this work (writing research drafts, etc.),
please let me or Kirsty Paine know.

Best regards,
Kathleen



> The draft is actually quite restrained in this regard, as I mentioned in my
> previous message the two notable examples of header encryption/protection
> deployed at scale into the real world, IPsec and SSH, have both been a
> disaster (for functionality, IPsec, and security, SSH), but it very
> politely
> omits mention of this.
>
> Peter.
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>


-- 

Best regards,
Kathleen

--00000000000091ca1905972744c4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Nov 12, 2019 at 2:07 AM Peter=
 Gutmann <pgut001@cs.auckla=
nd.ac.nz> wrote:
Tom Herbert <tom@herbertland.com> writes:



>The problems of protocol ossification and middleboxes meddling in E2E
>protocols has been discussed at length in IETF in various contexts.



I'm aware of RFC 3234, which was written seventeen years ago and focuse=
s on

middleboxes messing with application-layer data, as well as farcical stuff<=
br>
like RFC 3424, of the same vintage, but it's mostly complaining rather =
than

actual rigorous analysis, and often seems to be based on opposition to

middleboxes as an article of faith, notoriously manifested in IPsec's &=
quot;NAT is

bad, therefore we will make sure IPsec breaks NAT, because NAT is bad"=
, which

has caused endless headaches for pretty much anyone who's ever had to w=
ork

with IPsec ever since.



In particular for this case, since the discussion is about header encryptio=
n

and not middleboxes in general, I'm not aware of any rigorous analysis =
of its

purported benefits, or even a clear statement of its purported benefits,
something like "here is a definition of the service that header encryp=
tion

provides, here is a real-world study showing that it provides this and

demonstrating that it can't be readily defeated".=C2=A0 Contrast t=
his with the two

dozen plus studies that look at the analysis of encrypted traffic despite t=
he

encryption, an example being (just one picked at random) "Identifying =
HTTPS-

Protected Netflix Videos in Real-Time", Andrew Reed and Michael Kranch=
,

Proceedings of the 7th Conference on Data and Application Security and Priv=
acy

(CODASPY'17), March 2017, p.361.



So when people complain that the draft doesn't say enough about all the=
 Good

Things header encryption provides, I would respond that it does, it's c=
ited

all of the available literature on the benefits of header encryption, and a=
ll

of the studies showing that it's effective, in Appendix B.


After work on RFC8404, I do think having such researc=
h conducted would be beneficial.=C2=A0 This was one of the aims of the prop=
osed group SMART.=C2=A0 If there is interest in conducting this work (writi=
ng research drafts, etc.), please let me or Kirsty Paine know.
Best regards,
Kathleen

=C2=
=A0

The draft is actually quite restrained in this regard, as I mentioned in my=


previous message the two notable examples of header encryption/protection
deployed at scale into the real world, IPsec and SSH, have both been a

disaster (for functionality, IPsec, and security, SSH), but it very politel=
y

omits mention of this.



Peter.



_______________________________________________

saag mailing list

saag@ietf.org

https://www.ietf.org/mailman/listinfo/saag




-- 

Best regards,
Kathleen


--00000000000091ca1905972744c4--


From nobody Tue Nov 12 07:55:53 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776C912082E for ; Tue, 12 Nov 2019 07:55:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmCX-8TG9LVo for ; Tue, 12 Nov 2019 07:55:37 -0800 (PST)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::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 5742212004F for ; Tue, 12 Nov 2019 07:55:37 -0800 (PST)
Received: by mail-lj1-x229.google.com with SMTP id d22so6853540lji.8 for ; Tue, 12 Nov 2019 07:55:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EPZNeg+JV3mFIqz2COEoeHPNE1NMOngYfazcZI04m1o=; b=omTyp6sB1q8Ebn3Nzb2iFk8zqmWbZSWc/DW25AKwv0ERvf7erq5R+gOIB8wQBskP9F 8vUz0teIovsivInW6XSkoo2YSoguhISXMzJ3aTfQ9GQFwpQE+mgzqpuPg0Ray3phoJ1b BOC618qcd4OYVLsgq1AMjFBUuCcLAEJvBrYCACC/zYyLMUQxmDno+ZwjF8UY3Lh7p4d1 WewuU6Vc0fHqDQMMK4lKnyoTYqM3Ehg8QF0NM+Aem2DuucgmGVoeGZvCL2sWxpZm3Kst +PdfQC/LDHFQYn9YUwmFVCvZ2jktuGwFMLEmAOXC5WOSX4JTsCnJ5hFgf0uJyMNXX8C8 uTFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EPZNeg+JV3mFIqz2COEoeHPNE1NMOngYfazcZI04m1o=; b=EVVIzIJkNGnQEsxVdr/y/PFlRahLOCvqHzy68gVzG/rO2eOh8bwxrIyakDcBgaBzMX eA2JAElPdC5mysIqxH3gLUFccTgJI/+QFZBfYFpdWg2RUBK/oTaUE4s6oXlLdu8+6WXi o8qpYUOvXePfqDEzeswQ6vOTzescQOZv2F4xjHMdwxWWYGSIiw9VGXIeekVkPDYu6yIl 4rYO9HBjjQaREsao2yBDuqMyeu4+Yqd0zxL4XrLUrsUpK8iCyfe+XkZ1MUhEzMAKFwhi Ar3o9WeGOsFEb/Td+q9ue6VFvhKFKFxhAzeMxd4lkuz9kxy0515K1KsVsYqLTS8VevZN p6IQ==
X-Gm-Message-State: APjAAAV3rsgRMrwBk27psr5wpsC//NwsHFqprUwoJwcbht2uEk1Sig55 jrHRBICDKD4bgPq2kMgwmZULc4oMkYM7sUXkxBaWyg==
X-Google-Smtp-Source: APXvYqxLew27YKO2uDDuDYuDzbjn/sI0xcmBTTVHqgiZCkIhVR9MSMMDyFgW+Ec39JAO8DceCMbET+Cwp5kGeWlX+Ho=
X-Received: by 2002:a2e:7301:: with SMTP id o1mr12928516ljc.16.1573574135512;  Tue, 12 Nov 2019 07:55:35 -0800 (PST)
MIME-Version: 1.0
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com>  <1573035094775.62307@cs.auckland.ac.nz> <87d3bcef-42e4-1535-db1f-06a8408d38d5@cs.tcd.ie> <1573109463764.56084@cs.auckland.ac.nz>
In-Reply-To: <1573109463764.56084@cs.auckland.ac.nz>
From: Eric Rescorla 
Date: Tue, 12 Nov 2019 07:54:58 -0800
Message-ID: 
To: Peter Gutmann 
Cc: Stephen Farrell , David Schinazi ,  Joe Touch , "gorry@erg.abdn.ac.uk" , Mirja Kuehlewind ,  tsvwg IETF list , "saag@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000006011e80597284754"
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Nov 2019 15:55:41 -0000

--0000000000006011e80597284754
Content-Type: text/plain; charset="UTF-8"

On Wed, Nov 6, 2019 at 10:51 PM Peter Gutmann 
wrote:

> .  So on the one hand we've got real-world experience with two protocols
> that do header encryption/protection which has yielded endless problems
> (IPsec) and security vulns (SSH), and on the other hand we've got what
> seems
> to be a faith-based belief in something that numerous academic papers have
> shown doesn't provide the service it claims to.
>

On the other hand, we also have WebRTC which tunnels SCTP over DTLS (thus
encrypting the SCTP headers) and that seems to work out fine.

As far as "the services it claims to", the primary argument for encrypting
headers in QUIC (and the handshake metadata in TLS 1.3) is to prevent
middleboxes interfering with protocol evolution. We certainly have evidence
of a number of cass where that has happened, though I don't think we yet
have strong evidence that encrypting more of the metadata prevents this
from happening because we mostly just started doing so. OTOH, I'm not aware
of any academic papers showing the contrary.

-Ekr

--0000000000006011e80597284754
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Nov 6, 2019 at 10:51 PM Peter=
 Gutmann <pgut001@cs.auckla=
nd.ac.nz> wrote:
.=C2=A0 So on the one hand we've got real-world experience with=
 two protocols

that do header encryption/protection which has yielded endless problems

(IPsec) and security vulns (SSH), and on the other hand we've got what =
seems

to be a faith-based belief in something that numerous academic papers have<=
br>
shown doesn't provide the service it claims to.
On the other hand, we also have WebRTC which tunnels SCTP over=
 DTLS (thus encrypting the SCTP headers) and that seems to work out fine.

As far as "the services it claims to", th=
e primary argument for encrypting headers in QUIC (and the handshake metada=
ta in TLS 1.3) is to prevent middleboxes interfering with protocol evolutio=
n. We certainly have evidence of a number of cass where that has happened, =
though I don't think we yet have strong evidence that encrypting more o=
f the metadata prevents this from happening because we mostly just started =
doing so. OTOH, I'm not aware of any academic papers showing the contra=
ry.

-Ekr


 


--0000000000006011e80597284754--


From nobody Tue Nov 12 08:19:09 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F28C12004A for ; Tue, 12 Nov 2019 08:19:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gnT5sjCssaG for ; Tue, 12 Nov 2019 08:18:59 -0800 (PST)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 BA516120098 for ; Tue, 12 Nov 2019 08:18:58 -0800 (PST)
Received: by mail-ed1-x532.google.com with SMTP id p59so15395530edp.7 for ; Tue, 12 Nov 2019 08:18:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dRl4pnSQcmDP3hsHR8pJ8assp/9ILZYSXXd5C2TzRpM=; b=a1GnZAdaPvYxChRU48M3tvkq4uXfORwuKPieUGR7vQ6PuUEgfzHQTfkwEQaTqYybCU 0ZpYqIC1i6hDDC1nRGmw4xrgiR4NlK2wT8LvBTfV96F3+TkdnMqGsqUwl8jbL7/Q0gqt MWiegPbxkZWvegCCMNC3ilQD4+UcS6YnM37NiDM1rhrPAF+VF8/d7sBRueOeR7lQ40nX GLYKQ/p/4Qs2hC9pzr1n66y9PRo3/WjEYdGxLTJ1B+lEjlqv1dZg23Kl150qiR6dhkQ6 VC1gvk9MepMve/6IxENB4Ha0MtGpG1z6QrqT3qQ1Nib29Uryf7SpSAQ315iTImYlxuAs RZZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dRl4pnSQcmDP3hsHR8pJ8assp/9ILZYSXXd5C2TzRpM=; b=L1l7JucTsTnXgnVkIxBJZasoNpPDGVqxNvBboRCI7/dToT0HND64lH93F5SRP2iTwe jjL34iFhJg7xG/RZDU/zBWekR8zCngYNM1K9AQO46joFg7CGodRUn/4SvhmuAY04FTPX 7z9PvJ2lzEXvKfk9TtVqnur90+YDTE/GkkXS0yAaj4+NPty6TAmjEbMDdxXP3N1vZgcX aALLiPeI2f27CbtVY/goB1Uhnc9HKAzYIrGekQjfYpa3hLV+m57v3QvjLRzjNaIP0Uac 983HP5j5dSG4SH4oxG2y9f0+DVhNAuys6twhJtlU4XfZ8mg2Mh1aylzi+ja2HAlpDTu0 xJOw==
X-Gm-Message-State: APjAAAV9SW5IJC1+9GIkTtIN0rj2+KhzKz2vrrcjG9obxW2emuBzvp1h V1/L5tI9InnF52vNtA2RI23yUJObXbWd7h+SwkTOdw==
X-Google-Smtp-Source: APXvYqyX3bjG66IhqDCOri85eJUIh6kp+KB8u2ec6Rax03VT+a7W22s/cMucz1+UPkNLE4u3QSeHyA08txFwr1bqPq8=
X-Received: by 2002:a17:906:d9db:: with SMTP id qk27mr13990844ejb.309.1573575536790;  Tue, 12 Nov 2019 08:18:56 -0800 (PST)
MIME-Version: 1.0
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com>  <1573035094775.62307@cs.auckland.ac.nz> <87d3bcef-42e4-1535-db1f-06a8408d38d5@cs.tcd.ie> <1573109463764.56084@cs.auckland.ac.nz>  <1573542420083.60501@cs.auckland.ac.nz>
In-Reply-To: <1573542420083.60501@cs.auckland.ac.nz>
From: Tom Herbert 
Date: Tue, 12 Nov 2019 08:18:44 -0800
Message-ID: 
To: Peter Gutmann 
Cc: Stephen Farrell , David Schinazi ,  Joe Touch , "gorry@erg.abdn.ac.uk" , Mirja Kuehlewind ,  tsvwg IETF list , "saag@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Nov 2019 16:19:04 -0000

On Mon, Nov 11, 2019 at 11:07 PM Peter Gutmann
 wrote:
>
> Tom Herbert  writes:
>
> >The problems of protocol ossification and middleboxes meddling in E2E
> >protocols has been discussed at length in IETF in various contexts.
>
> I'm aware of RFC 3234, which was written seventeen years ago and focuses on
> middleboxes messing with application-layer data, as well as farcical stuff
> like RFC 3424, of the same vintage, but it's mostly complaining rather than
> actual rigorous analysis, and often seems to be based on opposition to
> middleboxes as an article of faith, notoriously manifested in IPsec's "NAT is
> bad, therefore we will make sure IPsec breaks NAT, because NAT is bad", which
> has caused endless headaches for pretty much anyone who's ever had to work
> with IPsec ever since.
>
> In particular for this case, since the discussion is about header encryption
> and not middleboxes in general, I'm not aware of any rigorous analysis of its
> purported benefits, or even a clear statement of its purported benefits,
> something like "here is a definition of the service that header encryption
> provides, here is a real-world study showing that it provides this and
> demonstrating that it can't be readily defeated".  Contrast this with the two
> dozen plus studies that look at the analysis of encrypted traffic despite the
> encryption, an example being (just one picked at random) "Identifying HTTPS-
> Protected Netflix Videos in Real-Time", Andrew Reed and Michael Kranch,
> Proceedings of the 7th Conference on Data and Application Security and Privacy
> (CODASPY'17), March 2017, p.361.

Peter,

https://www.iab.org/wp-content/IAB-uploads/2014/12/semi2015_huitema.pdf
describes with some detail how encryption of the transport layer is
beneficial to resolve the tussel that results in protocol
ossification.

>From that document: "We know that embedding encryption and
authentication inside the transport protocol provides a powerful API
to applications, and also enables sophisticated handling of path
redundancy and mobility... We know all that because we have tried it
before.", also "The effect of middle-boxes on transport protocols is
obvious."

Tom

>
> So when people complain that the draft doesn't say enough about all the Good
> Things header encryption provides, I would respond that it does, it's cited
> all of the available literature on the benefits of header encryption, and all
> of the studies showing that it's effective, in Appendix B.
>
> The draft is actually quite restrained in this regard, as I mentioned in my
> previous message the two notable examples of header encryption/protection
> deployed at scale into the real world, IPsec and SSH, have both been a
> disaster (for functionality, IPsec, and security, SSH), but it very politely
> omits mention of this.
>
> Peter.


From nobody Tue Nov 12 11:47:56 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81E612008C for ; Tue, 12 Nov 2019 11:47:53 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 amxjQsi77-Yj for ; Tue, 12 Nov 2019 11:47:32 -0800 (PST)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 C961B12004A for ; Tue, 12 Nov 2019 11:47:31 -0800 (PST)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id xACJlUlY031463 for ; Tue, 12 Nov 2019 14:47:30 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu xACJlUlY031463
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1573588050; bh=OS+OkSnn6W6+9FIW8cKtfcSgzgDylfMO5BhEvmAL6BQ=; h=From:To:Subject:Date:From; b=pPis83Lnyja9fZc1dsDDF/hj1sH8POv5cY8fF3n1WuqJTWtxguoduFzrlvMi3bMeN 02g4eGxlVpJnBHVR5u1Ej17+OQowUArxhXDZ7hzukVjEJHVKE4AIDj3BjcH/uejKGF dt5G4rE6mkJJmW0Kp5olxxAUGybp+zYQhYe76OXM=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id xACJlRkf043081 for ; Tue, 12 Nov 2019 14:47:27 -0500
Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0468.000; Tue, 12 Nov 2019 14:47:27 -0500
From: Roman Danyliw 
To: "saag@ietf.org" 
Thread-Topic: Office Hours with the SEC ADs at IETF 106
Thread-Index: AdWZkP6xDTMFQCqgStGTDxss0M7kBA==
Date: Tue, 12 Nov 2019 19:47:26 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01E70A84DB@marchand>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [saag] Office Hours with the SEC ADs at IETF 106
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Nov 2019 19:47:54 -0000

Hi!

We'll be holding SEC Area office hours from 1500-1600 on Sunday, November 1=
7, 2019 in the Clark Room.  Please join us if there is a security related t=
opic you'd like to discuss.

Regards,
Roman and Ben


From nobody Tue Nov 12 23:20:38 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E8F12088E for ; Tue, 12 Nov 2019 23:20:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57SDWMOYhx08 for ; Tue, 12 Nov 2019 23:20:35 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 D3D81120886 for ; Tue, 12 Nov 2019 23:20:33 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xAD7KToh028556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 13 Nov 2019 02:20:32 -0500
Date: Tue, 12 Nov 2019 23:20:29 -0800
From: Benjamin Kaduk 
To: saag@ietf.org
Message-ID: <20191113072029.GU32847@kduck.mit.edu>
References: <157348692828.7549.5693363954495959926.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <157348692828.7549.5693363954495959926.idtracker@ietfa.amsl.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: [saag] Fwd: Last Call:  (Operational Security Considerations for IPv6 Networks) to Informational RFC
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Nov 2019 07:20:37 -0000

Hi all,

A lot of different topics in here, but might be worth a skim to see if
there's anything related to your respective expertise...

-Ben

On Mon, Nov 11, 2019 at 07:42:08AM -0800, The IESG wrote:
> 
> The IESG has received a request from the Operational Security Capabilities
> for IP Network Infrastructure WG (opsec) to consider the following document:
> - 'Operational Security Considerations for IPv6 Networks'
>    as Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> last-call@ietf.org mailing lists by 2019-12-02. Exceptionally, comments may
> be sent to iesg@ietf.org instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>    Knowledge and experience on how to operate IPv4 securely is
>    available: whether it is the Internet or an enterprise internal
>    network.  However, IPv6 presents some new security challenges.  RFC
>    4942 describes the security issues in the protocol but network
>    managers also need a more practical, operations-minded document to
>    enumerate advantages and/or disadvantages of certain choices.
> 
>    This document analyzes the operational security issues in several
>    places of a network (enterprises, service providers and residential
>    users) and proposes technical and procedural mitigations techniques.
>    Some very specific places of a network such as the Internet of Things
>    are not discussed in this document.
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce


From nobody Tue Nov 19 19:06:13 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40301201EF for ; Tue, 19 Nov 2019 19:06:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nightwatchcybersecurity-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXENoWBWk-se for ; Tue, 19 Nov 2019 19:06:04 -0800 (PST)
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 84C30120935 for ; Tue, 19 Nov 2019 19:06:04 -0800 (PST)
Received: by mail-pj1-x1029.google.com with SMTP id y21so3524993pjn.9 for ; Tue, 19 Nov 2019 19:06:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=7qSjECtEzQGVsAvvs9T2A4xEYm5VUWvLTbwgaW6Q6/M=; b=kQBCSHLpRNeCT5mY6sJqIjtGfsdAXXlidAKZnopO3O8sD/Mcf3kGJWvqBi2fuFM/Tc H+GPHgcoWnJaZTmxcqrzotEzfAXZv/B9RCTqElAUe0e/kXOKiIGiBMIO/i2yeRe+LaMX 8idN6soqC6mc2EZ3GzEVNHHF2xwI+ygZA+SDHx8omq7O6SefyMFR000g0nfxi+Od3yr9 dRBiywR6dp1VGdLJfcgzDuySBSl7GI4QxVeYV1naMyfCgYYaDwHEn2H01KFiH9z3/btb WVKpwxlxRThR9B1ZiCC4c4ezWiGO3m7weIgi8HacRqSaGgMxEZ+/AGnOKk4VvdB3lNDz x4Aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=7qSjECtEzQGVsAvvs9T2A4xEYm5VUWvLTbwgaW6Q6/M=; b=qasZ6F853Y4LZjrJQClLC7ZOjukxkfNHA0UUQJRjfgXbcIZzR1GfPUstRHym7EWGrQ z2f5WrkJSAPWBZl1uk3VQzyjz1iOFUTbXAnU+qDOU9aSew+E9ZU6Z9AgVNexAs2yuy1P AzAS3Xw/fVyY2g882ll14ZfFfosYyCcOtH9MAMPuQHhgy/y6lzY7KOdpc1uw26ylv6S7 Aj2Dvod5DHFGV8Ye6NsBqwy05wMzytG8ePLoAOditVnmYheCorKI4CnwSu7wbQiqWy6c 7hryoHzGreLstETg9VP0Irjw1FnwVFMtJ63/a5n3BDQgvIsfPY3yRBioZouENBlOjtcf tduw==
X-Gm-Message-State: APjAAAV/f2kqrwAtMUQ+ypy+yqlrAquGaA8AuA2NlIO8W4XG32T/nKlw qbEqQrHB6mWi80mpeZ35J8UQozZVWpLn1Wg+QuKAiswp
X-Google-Smtp-Source: APXvYqw4deJ8PPeCeWArCdmnLvwyB0LKY0KV6WBm4M/Lm+ne1ZWXXOwwHyl46e00zhjIYVwpoR3pCsfY+OzjVFmOBi4=
X-Received: by 2002:a17:902:d693:: with SMTP id v19mr584080ply.220.1574219163736;  Tue, 19 Nov 2019 19:06:03 -0800 (PST)
MIME-Version: 1.0
References: <157421854777.5309.2237262569805387905.idtracker@ietfa.amsl.com>
In-Reply-To: <157421854777.5309.2237262569805387905.idtracker@ietfa.amsl.com>
From: Yakov Shafranovich 
Date: Tue, 19 Nov 2019 22:05:27 -0500
Message-ID: 
To: Security Area Advisory Group 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: [saag] Fwd: New Version Notification for draft-foudil-securitytxt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Nov 2019 03:06:11 -0000

FYI

---------- Forwarded message ---------
From: 
Date: Tue, Nov 19, 2019 at 9:55 PM
Subject: New Version Notification for draft-foudil-securitytxt-08.txt
To: Edwin Foudil , Yakov Shafranovich




A new version of I-D, draft-foudil-securitytxt-08.txt
has been successfully submitted by Yakov Shafranovich and posted to the
IETF repository.

Name:           draft-foudil-securitytxt
Revision:       08
Title:          A Method for Web Security Policies
Document date:  2019-11-19
Group:          Individual Submission
Pages:          24
URL:
https://www.ietf.org/internet-drafts/draft-foudil-securitytxt-08.txt
Status:         https://datatracker.ietf.org/doc/draft-foudil-securitytxt/
Htmlized:       https://tools.ietf.org/html/draft-foudil-securitytxt-08
Htmlized:       https://datatracker.ietf.org/doc/html/draft-foudil-securitytxt
Diff:           https://www.ietf.org/rfcdiff?url2=draft-foudil-securitytxt-08

Abstract:
   When security vulnerabilities are discovered by independent security
   researchers, they often lack the channels to report them properly.
   As a result, security vulnerabilities may be left unreported.  This
   document defines a format ("security.txt") to help organizations
   describe the process for security researchers to follow in order to
   report security vulnerabilities.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


From nobody Tue Nov 19 20:34:24 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F2D1201E0; Tue, 19 Nov 2019 20:34:22 -0800 (PST)
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,  DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSs7_9HRivD2; Tue, 19 Nov 2019 20:34:20 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03on061f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe08::61f]) (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 45C24120143; Tue, 19 Nov 2019 20:34:20 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UWGeVF3tJh568SJywj/5PMn4xRo2tCgNw9dSyL77UByOvtMBblp/2U0B20v+lFVD2vw9rfxYqjNI1/oeILRLXeACpIn5VEdt+ydLqk9UV3TNNmwqgrc8Z39IN1hs2EsGUnfkesZD/CVWrw29KW+znMBHahnEF+V0nSrCvPWVFbBDjxyV7SQesr0ybLa3cuG9vcfOgaaCuBUPWYK4fJJxF0n+jdTz6gDuzULdVJWAj4WU6WIN5jomZ87WfSqb/YAyMM36ASQ27MclYEZMz3+cYJQtIT6hnqzFFSryeMn1ZtoHAqrZUOAEz8A5jV/XqTRZ0KwDoXZF2pwyBEcyYpgACQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eKkdlM1991WvkVBuRB9H3CXetuxum8OPhq3dSlQrPXI=; b=mn3B8QZUKVCSTspLr8YEFbCeb+mw8lluVIqxHODJkspJyMvfCXBNP3Vnrt7d9wgI5Ms4F0hd366p1tUDt4S6i3nSJQ5xEaNc2pp23DzWwuYgUXbdBdJ7iThkT6Zs4fMY6XzFG7D6dIa3+lby1hKTmfQDkBUmELqRT7irqtVdiw7OZopsN5crEbfpAM4+QZWI+ZqeirU7UtzbGSWV8a8G/O4Pb2HYjZgAkd3UUZKOFz8jc2yWa3H2NXi4je3X1+lwd2/b13SgTcxnY83xb1VF/Wtj27OtE/Iolk3/QmmuCMiT8cxsBlyOLFAOFM0f8OQbFmiXsk7wZ2AyK9YBv+Q5Dg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eKkdlM1991WvkVBuRB9H3CXetuxum8OPhq3dSlQrPXI=; b=ZDJwhdOy3sw0rKkD1qunncNduLcg9gGP6Y7qX5/C0Sp52tgI/FUMIoZaDAsfyKp9hNyP6cYEPPmq15kmiJEBxQRZATgOA1hJ+gGl5RCvTUD+/k7iYJuS3QBn+wqhucAmTUVTQM8FEjZOGwImpRZchxE25UKfcq1zo7npqyyEfPI=
Received: from VI1PR07MB5469.eurprd07.prod.outlook.com (20.178.14.214) by VI1PR07MB3936.eurprd07.prod.outlook.com (52.134.28.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.9; Wed, 20 Nov 2019 04:34:18 +0000
Received: from VI1PR07MB5469.eurprd07.prod.outlook.com ([fe80::a8d5:a784:a19:5c76]) by VI1PR07MB5469.eurprd07.prod.outlook.com ([fe80::a8d5:a784:a19:5c76%6]) with mapi id 15.20.2474.015; Wed, 20 Nov 2019 04:34:18 +0000
From: Francesca Palombini 
To: "saag@ietf.org" , "secdispatch@ietf.org" 
CC: "Dr. Pala" , Nick Sullivan , Justin Richer , Joachim Fabini , Brian Campbell 
Thread-Topic: SECDISPATCH WG Summary from IETF 106
Thread-Index: AQHVn1vFDxHCv1ors0i+tXiIXiWbjg==
Date: Wed, 20 Nov 2019 04:34:17 +0000
Message-ID: <3088D698-1616-4A74-9CBC-4A9345E46C15@ericsson.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; 
x-originating-ip: [2001:67c:370:128:686f:cddf:6958:2afd]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cecbbc79-a465-40e8-69ad-08d76d72e7ea
x-ms-traffictypediagnostic: VI1PR07MB3936:
x-ms-exchange-purlcount: 6
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 02272225C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(39860400002)(396003)(136003)(376002)(199004)(189003)(54906003)(99286004)(25786009)(102836004)(71190400001)(71200400001)(110136005)(33656002)(316002)(8936002)(81166006)(81156014)(66476007)(14454004)(966005)(186003)(66946007)(66446008)(5660300002)(2501003)(66556008)(8676002)(478600001)(64756008)(14444005)(256004)(36756003)(6436002)(2616005)(7736002)(6116002)(6486002)(2906002)(6506007)(4326008)(486006)(44832011)(86362001)(476003)(6512007)(54896002)(6306002)(66574012)(76116006)(46003)(91956017); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3936; H:VI1PR07MB5469.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: BFZHgjM6ayFcyxLiJ1niHK09qEKcaisMu3U5P7joaZ6nAqZFnb6qIafD00V2UW0wuXx9/Ux9KheY5R+WtfpGayaXkhYdA0fwg7RamEkt/Crfbcv7i/4Md22WfbIR/BqbFrSm6BYYso1OeKxAAOtpQfO9eVzBQd/ZnlWmQCUDPkw2H3KPlz0nEyTdPoDiCk78g8/wTolS7Q6VZjdH5WPQnQAHTJpncvjRkWRIW5ANCmmg9oTwQqS2lCnzniArie+wrsaeSIu/RMwEQuiNUIPPkhBNO8ql7je6ORYhUItG40A3mKxOG2u0c7BP0WhsfpYKkurZmzaP7iiDQrf0NoMLtoW4GWXMMX9OOkr+AkuBkBS5V4IG+6uCNi6lY/qolkE0dOA94RQ1xvuCfU8d+jdbIEM4nORkRShzWLobpNKas6jWM6GMiU0Rz687KoB/STJ0x4k1wODTp+4lkBZLgrlbYREGYb3h152Of2PAw7j9uBQ=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_3088D69816164A749CBC4A9345E46C15ericssoncom_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cecbbc79-a465-40e8-69ad-08d76d72e7ea
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2019 04:34:17.9444 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: mh7yYZxM6HE8npz5jjDbsPn4wJFk44Tcy/mUbXK6+4dtZHAA5MIA4njSsd/RTjFp56xwmzGORRtCoy/Uj4KFsRZlQavhTqD69ts/zDaFIWFLzicutJTrDblJ9EPccziP
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3936
Archived-At: 
Subject: [saag] SECDISPATCH WG Summary from IETF 106
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Nov 2019 04:34:23 -0000

--_000_3088D69816164A749CBC4A9345E46C15ericssoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIFNFQ0RJU1BBVENIIFdHIG1ldCBvbiBUdWVzZGF5IE5vdmVtYmVyIDE5LiAgVGhlIGFnZW5k
YSBpdGVtcyB3ZXJlIGRpc3BhdGNoZWQgYXMgZm9sbG93czoNCg0KKDEpIFByb2JsZW0gc3RhdGVt
ZW50IGZvciBwb3N0LXF1YW50dW0gbXVsdGktYWxnb3JpdGhtIFBLSSAoTWF4IFBhbGEpDQpkcmFm
dHM6ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wcS1wa2l4LXByb2Js
ZW0tc3RhdGVtZW50Lw0KICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k
cmFmdC1vdW5zd29ydGgtcHEtY29tcG9zaXRlLXNpZ3MvDQotLT4gZGlzcGF0Y2ggdG8gTEFNUFMg
V0cgKGNvbmZpcm0gb24gbWFpbGluZyBsaXN0KQ0KDQooMikgT0NTUHYyIC0gSW1wcm92aW5nIE9D
U1AgUmVzcG9uc2VzIChNYXggUGFsYSkNCkxBTVBTICYgUEtJWCBkaXNjdXNzaW9uczoNCkRyYWZ0
OiAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhbGEtb2NzcHYyLTAwDQotLT4g
Y3JlYXRlIGEgQm9GIGZvciBzbWFsbCBmb2N1c2VkIFdHDQoNCigzKSBQcml2YWN5IFBhc3MgUHJv
dG9jb2wgKE5pY2sgU3VsbGl2YW4pDQpkcmFmdHM6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v
cmcvZG9jL2RyYWZ0LXByaXZhY3ktcGFzcy8NCi0tPiB3b3JrIG9uIGNoYXJ0ZXIgdGV4dCB0aGVu
IEJvRiBmb3Igc21hbGwgZm9jdXNlZCBXRw0KDQooNCkgSFRUUCBSZXF1ZXN0IHNpZ25pbmcgKEp1
c3RpbiBSaWNoZXIpDQpkcmFmdDogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNh
dmFnZS1odHRwLXNpZ25hdHVyZXMNCi0tPiBkaXNwYXRjaGVkIHRvIEhUVFBCSVMgV0cNCg0KKDUp
IENvbW11bmljYXRpb24gTmV0d29yayBQZXJzcGVjdGl2ZSBvbiBNYWx3YXJlIExpZmVjeWNsZSAo
Sm9hY2hpbSBGYWJpbmkpDQpkcmFmdDogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv
ZHJhZnQtZmFiaW5pLXNtYXJ0LW1hbHdhcmUtbGlmZWN5Y2xlLw0KLS0+IGNoZWNrIHRoZSBJQUIg
cHJvamVjdCAodGFsayB0byBUZWQpDQoNCig2KSBTZWN1cmluZyBwcm90b2NvbHMgYmV0d2VlbiBw
cm94aWVzIGFuZCBiYWNrZW5kIChIVFRQPykgc2VydmVycyAoQnJpYW4gQ2FtcGJlbGwpDQpkcmFm
dDogTG9va2luZyBmb3Igc3VwcG9ydC9jb250cmlidXRvcnMsIG5vIGRyYWZ0IHlldA0KLS0+IG5l
ZWRzIGRyYWZ0DQoNCkRldGFpbGVkIG1pbnV0ZXMgd2lsbCBiZSBjb21pbmcgaW4gdGhlIG5leHQg
Y291cGxlIG9mIHdlZWtzLg0KDQpUaGFua3MsDQpGcmFuY2VzY2ENCg==

--_000_3088D69816164A749CBC4A9345E46C15ericssoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bh
bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7
DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs
aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJ
dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5
bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl
cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5
cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNv
LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy
LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2
LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk
Pg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk
aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIFNFQ0RJU1BBVENIIFdHIG1ldCBvbiBUdWVzZGF5IE5v
dmVtYmVyIDE5LiZuYnNwOyBUaGUgYWdlbmRhIGl0ZW1zIHdlcmUgZGlzcGF0Y2hlZCBhcyBmb2xs
b3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+KDEpIFByb2Js
ZW0gc3RhdGVtZW50IGZvciBwb3N0LXF1YW50dW0gbXVsdGktYWxnb3JpdGhtIFBLSSAoTWF4IFBh
bGEpDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPmRyYWZ0czombmJzcDsgaHR0cHM6Ly9k
YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcHEtcGtpeC1wcm9ibGVtLXN0YXRlbWVudC88
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJT
ViIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1vdW5z
d29ydGgtcHEtY29tcG9zaXRlLXNpZ3MvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPi0tJmd0OyBkaXNwYXRjaCB0byBMQU1Q
UyBXRyAoY29uZmlybSBvbiBtYWlsaW5nIGxpc3QpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0Ij4oMikgT0NTUHYyIC0gSW1wcm92aW5nIE9DU1AgUmVzcG9uc2VzIChN
YXggUGFsYSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TEFNUFMgJmFtcDsgUEtJWCBkaXNjdXNzaW9uczog
PG86cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+RHJhZnQ6Jm5ic3A7IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1wYWxhLW9jc3B2Mi0wMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4tLSZndDsgY3JlYXRl
IGEgQm9GIGZvciBzbWFsbCBmb2N1c2VkIFdHPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdCI+KDMpIFByaXZhY3kgUGFzcyBQcm90b2NvbCAoTmljayBT
dWxsaXZhbik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPmRyYWZ0czogaHR0cHM6Ly9kYXRh
dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcHJpdmFjeS1wYXNzLzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
Ij4tLSZndDsgd29yayBvbiBjaGFydGVyIHRleHQgdGhlbiBCb0YgZm9yIHNtYWxsIGZvY3VzZWQg
V0c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPig0KSBIVFRQIFJl
cXVlc3Qgc2lnbmluZyAoSnVzdGluIFJpY2hlcik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi
PmRyYWZ0OiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2F2YWdlLWh0dHAtc2ln
bmF0dXJlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4tLSZndDsgZGlzcGF0Y2hlZCB0byBIVFRQQklTIFdH
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4oNSkgQ29tbXVuaWNh
dGlvbiBOZXR3b3JrIFBlcnNwZWN0aXZlIG9uIE1hbHdhcmUgTGlmZWN5Y2xlIChKb2FjaGltIEZh
YmluaSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPmRyYWZ0OiBodHRwczovL2RhdGF0cmFj
a2VyLmlldGYub3JnL2RvYy9kcmFmdC1mYWJpbmktc21hcnQtbWFsd2FyZS1saWZlY3ljbGUvPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQiPi0tJmd0OyBjaGVjayB0aGUgSUFCIHByb2plY3QgKHRhbGsgdG8gVGVk
KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+KDYpIFNlY3VyaW5n
IHByb3RvY29scyBiZXR3ZWVuIHByb3hpZXMgYW5kIGJhY2tlbmQgKEhUVFA/KSBzZXJ2ZXJzIChC
cmlhbiBDYW1wYmVsbCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ZHJhZnQ6IExvb2tpbmcgZm9yIHN1cHBv
cnQvY29udHJpYnV0b3JzLCBubyBkcmFmdCB5ZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+LS0mZ3Q7IG5l
ZWRzIGRyYWZ0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5EZXRh
aWxlZCBtaW51dGVzIHdpbGwgYmUgY29taW5nIGluIHRoZSBuZXh0IGNvdXBsZSBvZiB3ZWVrcy48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rcyw8YnI+DQpG
cmFuY2VzY2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N
Cg==

--_000_3088D69816164A749CBC4A9345E46C15ericssoncom_--


From nobody Wed Nov 20 01:32:14 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1BF12009C for ; Wed, 20 Nov 2019 01:32:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=NRN5znzJ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=M9+E1pxG
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 hXYp1PpHZj9P for ; Wed, 20 Nov 2019 01:32:10 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71993120AC7 for ; Wed, 20 Nov 2019 01:32:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4123; q=dns/txt; s=iport; t=1574242330; x=1575451930; h=from:to:subject:date:message-id:mime-version; bh=bvju0txPF2ZALWMi5wBV4CCLptyY2b74HUeVLBE8nZM=; b=NRN5znzJ8kstsHq9rvMGxjY4CtR404DlaAPdMz73UloVxgsYB6NzfzNz qoc41urBBnLqQGT7Yi+AhOZnx2miVsERuqDFsV+dZtZtGZhwC50QQGsI2 VIOIoPR7uZYlz9jUGoNrKGJEQRVAuO4W3W/dphUe5qrRhYsqofWUU5P5r o=;
IronPort-PHdr: =?us-ascii?q?9a23=3APSZQIRTFT/+Y2mE0qHUZx7OGR9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOioxFcFdVVlq13q6KkNSXs35Yg6arw=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CFDAA6B9Vd/4oNJK1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgX6BHC9QBWxYIAQLKoQqg0YDinROlS6EYoJSA1QJAQEBDAEBIwo?= =?us-ascii?q?CAQGEQBmCDyQ4EwIDDQEBBAEBAQIBBQRthTcBC4VqER0BATgRAQw+AgQwDxg?= =?us-ascii?q?ENYMAAYF5TQMuAQ6lFAKBOIhgdYEygn4BAQWBSEFAgjgYghcDBoE2jBUYgX+?= =?us-ascii?q?BEScfg3OBeQIDAYIKgmMygiyQE4VHmFMKgiuHGo41G5oRhkaIAog4kVACBAI?= =?us-ascii?q?EBQIOAQEFgWkigVhwFWUBgkFQERSRGoNzhRSFP3SBKI4RAQE?=
X-IronPort-AV: E=Sophos;i="5.69,221,1571702400";  d="scan'208,217";a="580101687"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Nov 2019 09:32:08 +0000
Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id xAK9W8Rc003842 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 20 Nov 2019 09:32:09 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Nov 2019 03:32:07 -0600
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Nov 2019 03:32:07 -0600
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 20 Nov 2019 03:32:05 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HaW3g7Ihpy9gSET+2gU7UG+VdZgzLRgz/DD3JuotRmjftqI8DrEH3l1vcsOhcJ2VjevjODCHBs0hcVcGgda2EJLZiGjx7HMb9uQSzFbP4sIJqzzxl8cFqIDLAMN4z57EnpnaJdHTLfcHkGOS+aRr4GTJq880bNZAseG6QNiMFFQh3Ou5r0+/7C9O9DLagMkb3YTHePn2I87EqkBvFfOrcFa3XWhpP4ye73bNcdhlnzaCzJubv876i/IleuAd36EJbiyFz8OW7kD/ePZtnXbyzbxX7XXzlhqP2bLZJ8FvyDc61eB+U/aCCbz6jTyVEPZGJVVNDUVawv0cim/fAivCgQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bvju0txPF2ZALWMi5wBV4CCLptyY2b74HUeVLBE8nZM=; b=c7uJSX33mDytLT7yuNww/5P25d9qch8rrBXjHc/UZnemb/aNOsWHlAXV1s+OVFHZ4UXoGztigfbCi64R5MsAdopm+XkhueJUnCx+4ste2t6WOhIL5pr8wdvZ6sd+vIe3uQEf8HjeckNchBsdml+HOXJlrU7vw5L1/6giW/8aQLM56P1y2zqHMsBC+6lFdboLjLghabQgfovoi8vfl6VNIpSNj2ctbQ/tm4aEgQmyXVqLI48e439/tWFMX1OnGRAylxOjJKCIPGVsD4ao6LoQ0L9GeAWpHakBPMWgp8RLZ4SdMxgChAKqo3i/wjce9Q2Z115cL2uWn1BPdnfTo8HrOQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bvju0txPF2ZALWMi5wBV4CCLptyY2b74HUeVLBE8nZM=; b=M9+E1pxGB73OLQDRezMbZMdsquLLVRzNV0Q82JcA6gQvJNJihlfREP6W5Q44pOtI0lnoQi4WU3D5K1qSsOD4kX+hfm9IE6SB/rTnTk1pWCAiMYyXBYCPv04d1lfBfzT+pPIjApXuHg0JRIhA0ZWe3XU2wiGUnNEMTqu6mpBVr5E=
Received: from MWHPR11MB1791.namprd11.prod.outlook.com (10.175.53.138) by MWHPR11MB2046.namprd11.prod.outlook.com (10.169.236.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.17; Wed, 20 Nov 2019 09:32:03 +0000
Received: from MWHPR11MB1791.namprd11.prod.outlook.com ([fe80::c92f:7001:f28:fa7a]) by MWHPR11MB1791.namprd11.prod.outlook.com ([fe80::c92f:7001:f28:fa7a%10]) with mapi id 15.20.2451.031; Wed, 20 Nov 2019 09:32:03 +0000
From: "Nancy Cam-Winget (ncamwing)" 
To: "saag@ietf.org" 
Thread-Topic: MILE report
Thread-Index: AQHVn4VezuU8k5jKzE6sGa6OJlcB5g==
Date: Wed, 20 Nov 2019 09:32:03 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.10.191111
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ncamwing@cisco.com; 
x-originating-ip: [2001:420:c0c8:1008::62]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5434626e-9e7a-49d5-5968-08d76d9c80ca
x-ms-traffictypediagnostic: MWHPR11MB2046:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:6430;
x-forefront-prvs: 02272225C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(346002)(396003)(136003)(39860400002)(199004)(189003)(6486002)(76116006)(606006)(2616005)(316002)(66946007)(8936002)(478600001)(5660300002)(46003)(91956017)(64756008)(66446008)(66556008)(486006)(256004)(86362001)(1730700003)(14444005)(8676002)(66476007)(81156014)(81166006)(476003)(4744005)(71200400001)(58126008)(2906002)(186003)(5640700003)(3480700005)(99286004)(6916009)(33656002)(7736002)(71190400001)(221733001)(6116002)(2501003)(966005)(14454004)(6436002)(7116003)(102836004)(236005)(6512007)(25786009)(6506007)(36756003)(54896002)(6306002)(2351001); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB2046; H:MWHPR11MB1791.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: jNVJvkzMJssCRF7M9KBSpcW3Z3qPhvfYvYbeyX2rSObuyz5A3YZe/GabtdRqd5Ro1QQVa9KDET3JOe5lnO7uLDPFfke/636xVEFBy+vI8tDsfHK4IffLjkmuarIsgYXsc43tKqQa5TXfaSBQ9qwAUsvqEciTHnyNUYBldEsBV24FICTrefYhlYp4BbSXQrL0E9weqjrds4rknGA1+lFzhgsn4A7XxPVBC4omaDSKxgPmcm9DcPhdCcrKJjR+E5+xpxO57aTu3rG/UrvGipANvWL5wI+NLlaDfKrsTyfDDOy7D4D+KMz6vq21LgdDSQnigU0/NKWbc4jcjzK1AnFRfkrEYNDJHm0J6Mb233W5NiIcKAv2+W86BHYlI4iY8VF/oLXkCujgWfX0uC6xx2sU2A85cuuy6lD69vfkxpfSqw4AFEGEjIjLrrYKcqNs2F+dG7sYS4jXgaCYhBsAhyepC8W3V/DAW/76b8z+mEkz6oc=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_A0CCA0734BF04CE0BE37427FA69D9C7Eciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 5434626e-9e7a-49d5-5968-08d76d9c80ca
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2019 09:32:03.7285 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ZpR9lLoqD6bYuZSGuYwkG0i1a5Xdvr69q3FlEx762Hkk82e49y9pEv0Of9T0KKajIwyb9x7KierYy7ow39djmg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB2046
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: 
Subject: [saag] MILE report
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Nov 2019 09:32:13 -0000

--_000_A0CCA0734BF04CE0BE37427FA69D9C7Eciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIE1JTEUgV0cgaXMgbm90IG1lZXRpbmcgYXQgSUVURiAxMDYsIHRoZXJlIGFyZSBvbmx5IHR3
byBkb2N1bWVudHMgbGVmdCBvbiBvdXIgZG9ja2V0IGFuZCBoYXZlIGdvbmUgdGhydSBXR0xDIHdp
dGggbWlub3IgZWRpdHMgcmVtYWluaW5nLg0KVGhlIG5leHQgc3RlcCBpcyBmb3IgdGhlbSB0byBn
byB0aHJ1IHNoZXBoZXJkaW5nIGZvciBJRVNHIHJlcXVlc3QgZm9yIHB1YmxpY2F0aW9uLCB0aGUg
ZHJhZnRzIGFyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt
bWlsZS1yb2xpZS1jc2lydC8NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0
LWlldGYtbWlsZS1yb2xpZS12dWxuLw0KDQpCZXN0LCBOYW5jeQ0KDQo=

--_000_A0CCA0734BF04CE0BE37427FA69D9C7Eciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz
cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z
b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g
MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp
b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBs
YW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i
V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij5UaGUgTUlMRSBXRyBpcyBub3QgbWVldGluZyBhdCBJRVRGIDEwNiwgdGhlcmUg
YXJlIG9ubHkgdHdvIGRvY3VtZW50cyBsZWZ0IG9uIG91ciBkb2NrZXQgYW5kIGhhdmUgZ29uZSB0
aHJ1IFdHTEMgd2l0aCBtaW5vciBlZGl0cyByZW1haW5pbmcuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRo
ZSBuZXh0IHN0ZXAgaXMgZm9yIHRoZW0gdG8gZ28gdGhydSBzaGVwaGVyZGluZyBmb3IgSUVTRyBy
ZXF1ZXN0IGZvciBwdWJsaWNhdGlvbiwgdGhlIGRyYWZ0cyBhcmU6PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p
ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1taWxlLXJvbGllLWNzaXJ0LyI+aHR0cHM6Ly9kYXRhdHJh
Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1taWxlLXJvbGllLWNzaXJ0LzwvYT48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr
ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbWlsZS1yb2xpZS12dWxuLyI+aHR0cHM6Ly9kYXRh
dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1taWxlLXJvbGllLXZ1bG4vPC9hPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5CZXN0LCBOYW5jeTxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt
bD4NCg==

--_000_A0CCA0734BF04CE0BE37427FA69D9C7Eciscocom_--


From nobody Wed Nov 20 01:54:03 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335DE1208C6 for ; Wed, 20 Nov 2019 01:54:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpGaOnchtynt for ; Wed, 20 Nov 2019 01:53:59 -0800 (PST)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 2EDC21200B2 for ; Wed, 20 Nov 2019 01:53:59 -0800 (PST)
Received: by mail-wr1-x435.google.com with SMTP id t1so27332537wrv.4 for ; Wed, 20 Nov 2019 01:53:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=E2UbQ5bsyGim0i1T0+gYIEkDeyfJiFOe8qI6X5Fvt/4=; b=Sm3UpDaLnsoloR4rPqWnCXeYioLvkDrwtxueOn9oowwlwaPx1/lC6I0ylZY5t6rMzx Cf373driHxtcEF/B7sto60AAofO4trK8UXD6RiY6u7sV4zR4V2A3ejvZJG9o7+yjOoVB KEwF4R6wKPYGpd7lrYm+FV3HuS35fVva/4dZkhWacc4A9WMlJ9RTwv6unpeZZCV/cp4c I7dnaqpMqB3kQQFa7xqGqvhMwcOt0iUKJ3u9LQBLBCNbfLIsSK41P6xg0JOrT0IxhYfD Rg3nStl/iXEdkVKeReIbH8AibUXsf0fOCEld2PbjSVbkXt6+HkAckEa4yEJnpI4LdUvw 9v4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=E2UbQ5bsyGim0i1T0+gYIEkDeyfJiFOe8qI6X5Fvt/4=; b=g+Nn9RSK3XoW9ZEHJMVhfX9L64OvhTRVYpkkbUDqfPON0yQACm2A45X2+TTdiI/22K NmY5Avd2EOJZ5HNOcSd8xeTWMs0zb1NeUIZ45ApzLVR3NOAOKMBZlgV8icNFJrjK4ZXm A6f1+0zwZ8bTpM7JS4V2iqosY/mqRgDcCQvhrFA9CZQpCB6nwb5rrtgBWszVwi2WCP9W PukDfXSd0juFOvEGBeoQYLOJgx1iGWL+KPWowrWwtVB3qKuMa0MuTjMBdbx69FJHjd0E 0sJZqcY1/J0cDkWTn0BnU1Y+sbMLlPWmv7B2Kva9n5upsEur24T1/fXb+WINcoQpDka/ DnUw==
X-Gm-Message-State: APjAAAWhtngj582NfVCq7SkqOOjCLrQ36GlJbBxcqJmLCaFO+rj/2kOJ C6c0TRXYYuurNhUIwYqQx3TBHqJjr52XAF6P8OpeSuHZa4Y=
X-Google-Smtp-Source: APXvYqx2tKx/FZyd/t7O4gSN8JhrHXDispjiNpRx+6bUzA6Qy0ratR1Wzw+I4XpGVP54MFZqRSUuT1r/OVt4ffuvW/Q=
X-Received: by 2002:adf:cf0c:: with SMTP id o12mr2060968wrj.102.1574243637152;  Wed, 20 Nov 2019 01:53:57 -0800 (PST)
MIME-Version: 1.0
From: Ivaylo Petrov 
Date: Wed, 20 Nov 2019 17:53:31 +0800
Message-ID: 
To: saag@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c861d20597c4282c"
Archived-At: 
Subject: [saag] COSE WG Report
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Nov 2019 09:54:01 -0000

--000000000000c861d20597c4282c
Content-Type: text/plain; charset="UTF-8"

Dear all,

COSE WG will be meeting after saag meeting - on Thursday from 15:50. We
will be discussing the WG drafts that are not submitted to IESG as well as
a possible need for a new draft. Following are the details:

* draft-ietf-cose-rfc8152-algs, which is past WGLC, it needs a shepherd
writeup to progress
* draft-ietf-cose-rfc8152-struct, which is past WGLC, it needs a shepherd
writeup to progress
* draft-ietf-cose-hash-algs, which is currently in WGLC, chairs will
provide feedback by the end of the week
* draft-ietf-cose-x509, which has no pending issues, a WGLC is expected to
be started soon
* draft-ietf-cose-webauthn-algorithms, which is currently in WGLC with
ongoing discussions
* draft-schaad-cose-more-algs, which is the proposal for a new draft on
additional algorithms

Best regards,
- Matthew and Ivaylo
COSE Chairs

--000000000000c861d20597c4282c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Dear all,

COSE WG will be meeting after sa=
ag meeting - on Thursday from 15:50. We will be discussing the WG drafts th=
at are not submitted to IESG as well as a possible=C2=A0need for a new draf=
t. Following are the details:

* draft-ietf-cose-rfc8152-algs, which =
is past WGLC, it needs a shepherd writeup to progress
* draft-ietf-cose-=
rfc8152-struct, which is past WGLC, it needs a shepherd writeup to progress=

* draft-ietf-cose-hash-algs, which is currently in WGLC, chairs will pr=
ovide feedback by the end of the week
* draft-ietf-cose-x509, which has =
no pending issues, a WGLC is expected to be started soon
* draft-ietf-co=
se-webauthn-algorithms, which is currently in WGLC with ongoing discussions=

*=C2=A0draft-schaad-cose-more-algs, which is the proposal fo=
r a new draft on additional algorithms

Best regards,
- Matthew an=
d Ivaylo
COSE Chairs
<=
div style=3D"margin:8px 0px 0px;padding:0px">


--000000000000c861d20597c4282c--


From nobody Wed Nov 20 02:34:35 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31A41200D8; Wed, 20 Nov 2019 02:34:33 -0800 (PST)
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,  DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMA1l6Mhfy-B; Wed, 20 Nov 2019 02:34:31 -0800 (PST)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740094.outbound.protection.outlook.com [40.107.74.94]) (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 45E65120047; Wed, 20 Nov 2019 02:34:31 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dAfgfADVoQUpuUKa3IfJKBfXtxp1lcdHS5x0nxklJp++z/xLYDGbc+/1R5Jcb0v1FkmOkPr9xtTYU3OKoKLPd4zll8dk9pe7y2W+AacPkFXn4UpZTFDyP9AVbJpETB0d9eCnVJ87mmK4dySeHz9N7hPU+rN2Y8GnWyxX9cBomZbH2exPUCPNi7FKoBn9Dh/7Ahc5/fasbuVYIn7QuB5GyPboSadxKzp+ddM3LUf+EHUDR/oZPeyn40TbsKDlAHtl3Fg65+aFb8D7s640e5yEeF7LdoJiV/oHq7bz2X0D0qbYxL1LKsqHhxuBD9ruf8XHCwRbb5gt3Kmqz9tWU8zTEg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xfVpxvjkwSB12Nsw6d/hhvOkFK2bUTuhL9MlUZ16c3I=; b=cOV34ZHBUfB3hWUWhXobLfItqNTTvuUc/yzPHnDxQnJqafgK1lCZIdMU5dXL3V5zr55dtyxC1k9PaVMKgrvOvIcBe5UvIsiN7xoEsjL+NcXAVtoEe9sX3lB34cFImfFispsK5Fd0kY0yA89cA7v8aeW8WxB8cqA4AAPvb81K7ESMHsbBXHJOpLJara4hBqtlT8fospF2pGh/6O7ptXvGIr4h7jTsYsqVz+6f+lljWJRGR7j0KTgGLieDgDWQ8GRRR0vQATpIejq3WvGJn2QqmF/N6/CFfpU/uZPACxT90P6YOxLf+/muhoMAwC4zjtXCpZ5H7U0OYs6HPV1gvTt19w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xfVpxvjkwSB12Nsw6d/hhvOkFK2bUTuhL9MlUZ16c3I=; b=TIblqUKevWlmap1WTFGyh0ffLVmOyQiyQZusjiXyqDVAR+Evdqurvoeyh+xj2OFmzAk8HZE3lH8j89uPunxcnJj5S3fBXjMpUb2RFt6wVTNpqfvWL/MnHijM3WgEgUJgA3KwmQA+LLiwShafS8Z5mcLa74o7SQh0JsDKSMgVxQ8=
Received: from MWHPR21MB0784.namprd21.prod.outlook.com (10.173.51.150) by MWHPR21MB0848.namprd21.prod.outlook.com (10.173.51.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.3; Wed, 20 Nov 2019 10:34:29 +0000
Received: from MWHPR21MB0784.namprd21.prod.outlook.com ([fe80::8d41:8f86:8654:8439]) by MWHPR21MB0784.namprd21.prod.outlook.com ([fe80::8d41:8f86:8654:8439%12]) with mapi id 15.20.2495.006; Wed, 20 Nov 2019 10:34:29 +0000
From: Dave Thaler 
To: "saag@ietf.org" 
CC: "suit-chairs@ietf.org" 
Thread-Topic: SUIT WG report
Thread-Index: AdWfjQ/PHDAuTdLfT6SQ8d0rP9f9sA==
Date: Wed, 20 Nov 2019 10:34:29 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-11-20T10:34:27.6249314Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=2b66e656-f65b-4eaa-90d6-5e15d44b881c; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; 
x-originating-ip: [2001:67c:370:128:a927:f2ec:f838:2498]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 42503cc5-aff8-4c65-d3fd-08d76da53956
x-ms-traffictypediagnostic: MWHPR21MB0848:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-forefront-prvs: 02272225C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(39860400002)(396003)(136003)(199004)(189003)(236005)(8936002)(1730700003)(5640700003)(66556008)(66946007)(25786009)(64756008)(66446008)(66476007)(10090500001)(76116006)(22452003)(316002)(10290500003)(6916009)(14454004)(52536014)(478600001)(5660300002)(7116003)(486006)(86362001)(476003)(33656002)(2906002)(46003)(450100002)(8676002)(81166006)(81156014)(7736002)(4326008)(790700001)(2351001)(71200400001)(71190400001)(3480700005)(2501003)(99286004)(606006)(8990500004)(6436002)(6506007)(6306002)(54896002)(14444005)(9686003)(7696005)(186003)(74316002)(102836004)(256004)(6116002)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0848; H:MWHPR21MB0784.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Pov9FzJwTMMfTq2CxFNr9I9m+IvBbwRSvKYcNLKoO3IZicBw4UnaQEMES1q02efq6cs6emgfsMv2R7QhkRStZDkd/wYEcYfeO6Jlv02kd6mLDnArqtAwT5UwXNcEbWo1g6FbJT5/aMoTePdyNeIznEt0EfbfpwpnTDeJ2ZH4YXt9QYhe6kvBL3LRenz0ExkwKg6pHJBGoacQr7/37oyY0c+3MSEzfz7hksTW8S0b18yjxnCqrg/v6U1RCs7Rep2Ln1sWYhsQnDKdIXXFIC21mFu49EmWtwM4BOTnOfrKkq7RHQ6Qn4yc+wevtf8AphLFDG72m27yMVeEgS4kPALgViZ4lPFeaVEabz+RV8WPd+qh0V+Wc2zhtw5w4cwvGuQkExtYUTx/epvnsduXyAw98qVpi0kkmQRzySMVY6MTEmGvwLq+53uT8c1df67qTo7g14PqHKgDuW/qStk8/TE5Dbb+NI6eoh5RHrJZK0/rFDM=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0784EE34FC862B87551E42D2A34F0MWHPR21MB0784namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 42503cc5-aff8-4c65-d3fd-08d76da53956
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2019 10:34:29.3928 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: vjAdNCJni43OisRO4RWUNVf+01zr6RD8/5SlQul7f9M2Ljihn0w1mF3rjTwKto2jx4dkK9SHbKFB5GhdJ9UgsgQROPwRBkKRXuUE6uFbc7Q=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0848
Archived-At: 
Subject: [saag] SUIT WG report
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Nov 2019 10:34:34 -0000

--_000_MWHPR21MB0784EE34FC862B87551E42D2A34F0MWHPR21MB0784namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The SUIT WG met on Tuesday November 19.

draft-ietf-suit-architecture previously completed WGLC and the WG reviewed the
latest state and had some additional feedback during the meeting.  The auth=
ors
agreed to make a change as a result, and the chairs plan to submit the revi=
sed
draft to the IESG.  (An updated draft was just submitted today, so the chai=
rs
now need to verify it and submit to the IESG if ready.)

draft-ietf-suit-information-model also completed WGLC with a bunch of feedback
that resulted in changes to the doc.  Additional discussion occurred during=
 the
meeting on whether to define a maximum size of payloads embedded into manif=
ests,
as opposed to being referenced from manifests.  The author will work on lan=
guage to
post to the list in the next couple days. The WG will have 2 weeks to provi=
de any final
feedback on the draft. After addressing any final feedback, the draft
will be sent to the IESG.

draft-ietf-suit-manifest is making good progress and there was good discussion
on it. The TEEP WG is now taking a dependency on the SUIT WG output for the=
 TEEP
protocol, and relayed requirements to the SUIT WG which appear to be easy t=
o meet.

Some SUIT WG participants are planning to join some TEEP and RATS WG partic=
ipants
for a joint hackathon in Berlin in February.

--_000_MWHPR21MB0784EE34FC862B87551E42D2A34F0MWHPR21MB0784namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











The SUIT WG met on Tuesday November 19.

 


dr=
aft-ietf-suit-architecture previously completed WGLC and the WG =
reviewed the


latest state and had some additional feedback during=
 the meeting.  The authors


agreed to make a change as a result, and the chairs =
plan to submit the revised


draft to the IESG.  (An updated draft was just =
submitted today, so the chairs


now need to verify it and submit to the IESG if read=
y.)


 


draft-ietf-suit-information-model also completed WGLC with a =
bunch of feedback


that resulted in changes to the doc.  Additiona=
l discussion occurred during the


meeting on whether to define a maximum size of paylo=
ads embedded into manifests,


as opposed to being referenced from manifests. =
 The author will work on language to

post to the list in the next couple days. The WG will have 2 weeks to provi=
de any final


feedback on the draft. After addressing any final fe=
edback, the draft


will be sent to the IESG.


 


draft-=
ietf-suit-manifest is making good progress and there was good di=
scussion


on it. The TEEP WG is now taking a dependency on the=
 SUIT WG output for the TEEP

protocol, and relayed requirements to the SUIT WG which appear to be easy t=
o meet.


 


Some SUIT WG participants are planning to join some =
TEEP and RATS WG participants


for a joint hackathon in Berlin in February.  <=
o:p>






--_000_MWHPR21MB0784EE34FC862B87551E42D2A34F0MWHPR21MB0784namp_--


From nobody Wed Nov 20 06:17:01 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEFF1208DA for ; Wed, 20 Nov 2019 06:17:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=gXm7koc0; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=v3PpuVlW
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 hYU5TzFA7xqS for ; Wed, 20 Nov 2019 06:16:58 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 101301200EB for ; Wed, 20 Nov 2019 06:16:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11159; q=dns/txt; s=iport; t=1574259418; x=1575469018; h=from:to:subject:date:message-id:mime-version; bh=HUSETVCe1Xu023UkMZnBwNxODLzzRtpzgEtfalSfXVw=; b=gXm7koc0W3AHspwWboCn/Gmfidkf3GEkchGvZ2zSMSQjgxfZfLH1nIgJ v2QTw2gVoq2zNTV8fCewwxd5+YGi4l4BjUmxmGym2q/bwPo2in6WScoAq VDn/LRzip7l4+K1/+mcMJuBytKnUGkw1E5B2iJaPi11WAZ3ZSCyFZah0W c=;
IronPort-PHdr: =?us-ascii?q?9a23=3AxrXWVRZeB4fIFl19BJam6kr/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavsZCU/A8VEW3du/mqwNg5eH8OtL1A=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AiMACJSdVd/51dJa1lHAMpBwMGBAS?= =?us-ascii?q?BZAKBGi8kLAVsWCAECyqEKoNGA4prTpUuhGKCUgNUCQEBAQwBASMKAgEBhEA?= =?us-ascii?q?ZNQmBUiQ3Bg4CAw0BAQQBAQECAQUEbYU3AQuFahEdAQE4EQEaMAIEMA8IEAQ?= =?us-ascii?q?uB4MAAYF5TQMuAQ6lDQKBOIhgdYEygn4BAQWBSEFAgjwYghcDBoE2AYwUGIF?= =?us-ascii?q?/gREnH4NzgXkCAwGBPQEBS4JjMoIskBWFSJhVCoIrhxqONRuaFIZGiAKIOJF?= =?us-ascii?q?UAgQCBAUCDgEBBYFoI4FYcBU7KgGCQVARFIo5gmSCMIU/dIEoi1yCMQEB?=
X-IronPort-AV: E=Sophos;i="5.69,222,1571702400";  d="scan'208,217";a="374515605"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Nov 2019 14:16:57 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id xAKEGvfN015010 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 20 Nov 2019 14:16:57 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Nov 2019 08:16:56 -0600
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Nov 2019 08:16:56 -0600
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 20 Nov 2019 09:16:56 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DzD/5IEsBl+aY31ilx8VRF3Do4PHOlKHNPWEXazBx4P3s0xcFx5erp3xwtPKDtsncQ7QhhCqWLSEqH/z/ypdor2eL1yQKkf4Zj/p+Ox1EAzQTvaQejZGFF05JS3LirSNxwXOMW7bU2uLVexWr5/0lAJh2bdwABfAK8mOy+9iX0+ZYtOIOwyS54RkyTB9mBLn9KMG2REVWOF2w/nhxkRKVbSjre8mviiONBfyqbJI9mPzlBM9lDTiKu0u34cOtNJGEJSGPyRBvb63eXlmoGv+Q2bGYAY5GFaSI1i2l45ipIpaC+BSArnxadxAmx06bi6lO2SpqGqvgaZF/XUqb6XHYw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HUSETVCe1Xu023UkMZnBwNxODLzzRtpzgEtfalSfXVw=; b=bUFu85aqNjbfnS8bPG9iVL3CwL5oBWt6mPPAO2+KQ0G4WVZ4XfDm4U3rj0ueIAQB9aUQHvXnVL+7U+1oPlRGweJWm121/3ILlbBVQEzVN3LFZO1PkZ0QEFs3i8UqtEGKhjxvO7dPnLt7KYQeBgobHHGaO2860LejoG3+dZ17VJjdCb47GDqdQ4M5UhyVgYHbOGNxqgSH+92cPLlbo/ami6zCOf44FruxUfpdgbCO3hXwfBre/XDpiPlVxWzZMtt0QObqhhMraP83eZZVdZI55lEfWG5iGReBe03qBc/r69rqKAa6HOnHN4U5/8bDauDkF8EUtFeEVZX6+vvei5ck3A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com;  s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HUSETVCe1Xu023UkMZnBwNxODLzzRtpzgEtfalSfXVw=; b=v3PpuVlWjJRW1otgy5jD9T+Soz+9NfU3tHwGve7j0FCLvGraQ6LHDzrZ/ws73gXhVTjG5UAomLOIdRXKNukJC6zJxfHPJFGR2MUkm9VHXF+Ftrg+/uvOpny/sxOFf9yHcDxoptQR3H0sm6PbXR6O54DvZvuWuH1eM1Fhq+TrSCo=
Received: from MWHPR11MB1791.namprd11.prod.outlook.com (10.175.53.138) by MWHPR11MB1374.namprd11.prod.outlook.com (10.169.234.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.18; Wed, 20 Nov 2019 14:16:55 +0000
Received: from MWHPR11MB1791.namprd11.prod.outlook.com ([fe80::c92f:7001:f28:fa7a]) by MWHPR11MB1791.namprd11.prod.outlook.com ([fe80::c92f:7001:f28:fa7a%10]) with mapi id 15.20.2451.031; Wed, 20 Nov 2019 14:16:54 +0000
From: "Nancy Cam-Winget (ncamwing)" 
To: "saag@ietf.org" 
Thread-Topic: TEEP report
Thread-Index: AQHVn60pEKR6IztFIU6yE8rjqKkGrw==
Date: Wed, 20 Nov 2019 14:16:54 +0000
Message-ID: <03FEBD3B-DB6E-4C6A-ADD0-CFB4016AB90C@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.10.191111
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ncamwing@cisco.com; 
x-originating-ip: [2001:420:c0c8:1008::62]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8b950575-5b49-4bd6-55b4-08d76dc44bda
x-ms-traffictypediagnostic: MWHPR11MB1374:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 02272225C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(366004)(376002)(346002)(136003)(199004)(189003)(478600001)(966005)(14454004)(6436002)(316002)(6486002)(58126008)(46003)(81166006)(8676002)(2501003)(6116002)(486006)(71190400001)(476003)(91956017)(5640700003)(76116006)(71200400001)(3480700005)(2616005)(86362001)(25786009)(66946007)(66446008)(6506007)(66476007)(6916009)(2351001)(64756008)(66556008)(186003)(7736002)(102836004)(99286004)(36756003)(606006)(8936002)(1730700003)(7116003)(81156014)(6306002)(5660300002)(6512007)(221733001)(256004)(2906002)(54896002)(236005)(14444005)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1374; H:MWHPR11MB1791.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: porHsb4JTmpy8Gg4dHVi1dLeo+eOqZfZvjezTX09XrcysastXVh9JVXOgwHGTEd6P9ZT1ZJ7RXf/uTR0g0LIzJCtRAyB0NvTeIFZ+UGYyJM0sR4Ffeo62coGNvku0rIvP7oaAuyH95F2tOOuXS02k2T46CcEFeoATYZFoHwfZSzZPVBj12QJoWyozrHb7k6RkBN33dBCiVtq8JDI3ekArOadG6KaPg4Eejs6zvGuOj3Af17A9k1pHKK90XEC/4bjStCF/7cHDmTJJeVU8ECGYAy2NU5268PLY5iizZQUsAcZAJAXjk4sHYbeEcor+0rwL68FOnyGl0C5ptup5TbXrRBY6vX4fYNzKS1XDECJjfG+gg0dcuh0R9OVI0rcZ8MhQW33mngxuXp2U7wknwxcR4FnFnjo8clzg5hgk1VG7x6jKv9bM89GxulfW6wxqnvpOwJQfLSsVAhzSL4KS3hf7yqyOTFu5kb1EorXkZdntwQ=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_03FEBD3BDB6E4C6AADD0CFB4016AB90Cciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 8b950575-5b49-4bd6-55b4-08d76dc44bda
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2019 14:16:54.7673 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 8gdV8hXbjw5N4ID/HmXXEQpKVI1vlPH714wUIKFXRpXxY/mb9aRcuoeA2f+raeB5Cf1P4RuJcR49+l+iIuwWBw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1374
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: 
Subject: [saag] TEEP report
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Nov 2019 14:17:00 -0000

--_000_03FEBD3BDB6E4C6AADD0CFB4016AB90Cciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VEVFUCBtZXQgb24gVHVlc2RheSBOb3ZlbWJlciAxOSBhbmQgV2VkbmVzZGF5IE5vdmVtYmVyIDIw
LCAxMGFtLW5vb24uDQoNCmRyYWZ0LWlldGYtdGVlcC1hcmNoaXRlY3R1cmU8aHR0cHM6Ly9kYXRh
dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10ZWVwLWFyY2hpdGVjdHVyZS8+IGlzIHBy
b2dyZXNzaW5nLCBzZXZlcmFsIGlzc3VlcyB3ZXJlIGRpc2N1c3NlZCB3aXRoIHByb3Bvc2VkIHJl
c29sdXRpb25zLiAgVGhlIGV4cGVjdGF0aW9uIGlzIHRvIGhhdmUgYSBkcmFmdCByZWFkeSBmb3Ig
V0dMQyBpbiBEZWNlbWJlciAyMDE5Lg0KVGhlcmUgd2FzIGRpc2N1c3Npb24gYW5kIGNvbnNlbnN1
cyB0byBhZG9wdCBkcmFmdC10c2Nob2ZlbmlnLXRlZXAtcHJvdG9jb2w8aHR0cHM6Ly9kYXRhdHJh
Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdHNjaG9mZW5pZy10ZWVwLXByb3RvY29sLz4gYXMgdGhl
IG5ldyBzb2x1dGlvbiBwcm90b2NvbCBmb3IgVEVFUC4gRmluYWwgY29uZmlybWF0aW9uIGZvciBh
ZG9wdGlvbiB3aWxsIGJlIHBvc3RlZCBvbiB0aGUgbWFpbCBsaXN0LiAgV2l0aCB0aGUgYWRvcHRp
b24gb2YgdGhpcyBkcmFmdCwgdGhlcmUgd2FzIGFsc28gY29uc2Vuc3VzIHRvIGxldCB0aGUgZHJh
ZnQtaWV0Zi10ZWVwLW9wZW50cnVzdHByb3RvY29sPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v
cmcvZG9jL2RyYWZ0LWlldGYtdGVlcC1vcGVudHJ1c3Rwcm90b2NvbC8+IGV4cGlyZSAoaXQgYWxy
ZWFkeSBpcyEpLg0KDQpEcmFmdC1pZXRmLXRlZXAtb3RycC1vdmVyLWh0dHA8aHR0cHM6Ly9kYXRh
dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10ZWVwLW90cnAtb3Zlci1odHRwLz4gaGFz
IGJlZW4gdXBkYXRlZCB0byByZWZsZWN0IHRoZSBuZXcgcmVmZXJlbmNlIHRvIHRoZSBURUVQIHBy
b3RvY29sIHdpdGggZGlzY3Vzc2lvbnMgYXMgdG8gd2hldGhlciBpdCBzaG91bGQgcmV0YWluIGRl
c2NyaXB0aW9ucyBmb3IgaG93IHRvIGNhcnJ5IE9UclB2MSAoYXMgZGVmaW5lZCBieSBHbG9iYWwg
UGxhdGZvcm0pLiAgV2UgaGF2ZSBleHRlbmRlZCBhbiBpbnF1aXJ5IHRvIGEgR2xvYmFsIFBsYXRm
b3JtIHJlcHJlc2VudGF0aW9uIHRvIGNvbmZpcm0gaWYgdGhhdCBpcyBzdGlsbCBkZXNpcmVkLiAg
T25jZSB0aGF0IHF1ZXN0aW9uIGlzIHJlc29sdmVkLCB0aGUgb3RoZXIgaXNzdWVzIGhhdmUgYWNj
ZXB0ZWQgcmVzb2x1dGlvbnMgdGhhdCBjYW4gYmUgZm9sZGVkIGludG8gYSBuZXcgZHJhZnQgdmVy
c2lvbiB0aGF0IGNhbiBhbGxvdyB0aGUgZG9jdW1lbnQgdG8gcHJvY2VlZCB0byBXR0xDLg0KDQpB
IEhhY2thdGhvbiB0byBhZHZhbmNlIHdvcmsgaW4gVEVFUCwgU1VJVCBhbmQgUkFUUyBpcyBiZWlu
ZyBzY2hlZHVsZWQgZm9yIEZlYi4gMTctMTkgMjAyMCBpbiBCZXJsaW4sIGZvciBtb3JlIGluZm9y
bWF0aW9uIGdvIHRvIGh0dHBzOi8vc2lvdC1oYWNrYXRob24uZ2l0aHViLmlvDQoNCg0KDQoNCg==

--_000_03FEBD3BDB6E4C6AADD0CFB4016AB90Cciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <7C396752BC63934895D2C8182AB217CE@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz
cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z
b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g
MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp
b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0
IGwwDQoJe21zby1saXN0LWlkOjMwNDYzMTUwNzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCglt
c28tbGlzdC10ZW1wbGF0ZS1pZHM6MTk2MjkzNjExOCAtNTg2OTEzODAwIC0yMDUyMzY3OTYgLTY1
NDA0Mzg0NiAtMTg0NjM4NzI1MiAtMTAwODgyMjIwNiAtMTcyOTgzMzY1MCAtNzM3MjI3NjIyIC03
MjcyNzYyOTAgNzU4MjYzNjMyO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ64oCiOw0KCW1zby1sZXZlbC10YWItc3Rv
cDouMjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6
LjI1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsc2Fucy1z
ZXJpZjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBs
MDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0OuKAojsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Ljc1aW47DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0Oi43NWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsN
Cglmb250LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6
IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt
Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrigKI7DQoJbXNvLWxldmVsLXRhYi1zdG9w
OjEuMjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6
MS4yNWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQXJpYWwiLHNhbnMt
c2VyaWY7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3Qg
bDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrigKI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNzVpbjsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MS43NWluOw0KCXRleHQtaW5kZW50Oi0uMjVp
bjsNCglmb250LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJbXNvLWJpZGktZm9udC1mYW1p
bHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrigKI7DQoJbXNvLWxldmVsLXRhYi1z
dG9wOjIuMjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxl
ZnQ6Mi4yNWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQXJpYWwiLHNh
bnMtc2VyaWY7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxp
c3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2
ZWwtdGV4dDrigKI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNzVpbjsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6Mi43NWluOw0KCXRleHQtaW5kZW50Oi0u
MjVpbjsNCglmb250LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJbXNvLWJpZGktZm9udC1m
YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrigKI7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOjMuMjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2lu
LWxlZnQ6My4yNWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQXJpYWwi
LHNhbnMtc2VyaWY7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0K
QGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDrigKI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNzVpbjsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6My43NWluOw0KCXRleHQtaW5kZW50
Oi0uMjVpbjsNCglmb250LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJbXNvLWJpZGktZm9u
dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrigKI7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOjQuMjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFy
Z2luLWxlZnQ6NC4yNWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQXJp
YWwiLHNhbnMtc2VyaWY7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7
fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K
LS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2
bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRFRVAgbWV0IG9uIFR1ZXNk
YXkgTm92ZW1iZXIgMTkgYW5kIFdlZG5lc2RheSBOb3ZlbWJlciAyMCwgMTBhbS1ub29uLiZuYnNw
Ow0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjx1PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YSBocmVm
PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRlZXAtYXJjaGl0
ZWN0dXJlLyI+ZHJhZnQtaWV0Zi10ZWVwLWFyY2hpdGVjdHVyZTwvYT48L3NwYW4+PC91PjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4gaXMgcHJvZ3Jlc3NpbmcsIHNldmVyYWwgaXNzdWVz
IHdlcmUgZGlzY3Vzc2VkIHdpdGggcHJvcG9zZWQNCiByZXNvbHV0aW9ucy4mbmJzcDsgVGhlIGV4
cGVjdGF0aW9uIGlzIHRvIGhhdmUgYSBkcmFmdCByZWFkeSBmb3IgV0dMQyBpbiBEZWNlbWJlciAy
MDE5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlcmUgd2FzIGRpc2N1
c3Npb24gYW5kIGNvbnNlbnN1cyB0byBhZG9wdA0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRzY2hvZmVuaWctdGVlcC1wcm90b2NvbC8iPmRy
YWZ0LXRzY2hvZmVuaWctdGVlcC1wcm90b2NvbDwvYT4gYXMgdGhlIG5ldyBzb2x1dGlvbiBwcm90
b2NvbCBmb3IgVEVFUC4gRmluYWwgY29uZmlybWF0aW9uIGZvciBhZG9wdGlvbiB3aWxsIGJlIHBv
c3RlZCBvbiB0aGUgbWFpbCBsaXN0LiZuYnNwOyBXaXRoIHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRy
YWZ0LCB0aGVyZQ0KIHdhcyBhbHNvIGNvbnNlbnN1cyB0byBsZXQgdGhlIDxhIGhyZWY9Imh0dHBz
Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGVlcC1vcGVudHJ1c3Rwcm90
b2NvbC8iPg0KZHJhZnQtaWV0Zi10ZWVwLW9wZW50cnVzdHByb3RvY29sPC9hPiBleHBpcmUgKGl0
IGFscmVhZHkgaXMhKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9k
YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10ZWVwLW90cnAtb3Zlci1odHRwLyI+
RHJhZnQtaWV0Zi10ZWVwLW90cnAtb3Zlci1odHRwPC9hPiBoYXMgYmVlbiB1cGRhdGVkIHRvIHJl
ZmxlY3QgdGhlIG5ldyByZWZlcmVuY2UgdG8gdGhlIFRFRVAgcHJvdG9jb2wgd2l0aCBkaXNjdXNz
aW9ucyBhcyB0byB3aGV0aGVyIGl0IHNob3VsZCByZXRhaW4gZGVzY3JpcHRpb25zDQogZm9yIGhv
dyB0byBjYXJyeSBPVHJQdjEgKGFzIGRlZmluZWQgYnkgR2xvYmFsIFBsYXRmb3JtKS4mbmJzcDsg
V2UgaGF2ZSBleHRlbmRlZCBhbiBpbnF1aXJ5IHRvIGEgR2xvYmFsIFBsYXRmb3JtIHJlcHJlc2Vu
dGF0aW9uIHRvIGNvbmZpcm0gaWYgdGhhdCBpcyBzdGlsbCBkZXNpcmVkLiZuYnNwOyBPbmNlIHRo
YXQgcXVlc3Rpb24gaXMgcmVzb2x2ZWQsIHRoZSBvdGhlciBpc3N1ZXMgaGF2ZSBhY2NlcHRlZCBy
ZXNvbHV0aW9ucyB0aGF0IGNhbiBiZSBmb2xkZWQgaW50bw0KIGEgbmV3IGRyYWZ0IHZlcnNpb24g
dGhhdCBjYW4gYWxsb3cgdGhlIGRvY3VtZW50IHRvIHByb2NlZWQgdG8gV0dMQy48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+QSBIYWNrYXRob24gdG8gYWR2YW5jZSB3b3JrIGluIFRFRVAsIFNVSVQg
YW5kIFJBVFMgaXMgYmVpbmcgc2NoZWR1bGVkIGZvciBGZWIuIDE3LTE5IDIwMjAgaW4gQmVybGlu
LCBmb3IgbW9yZSBpbmZvcm1hdGlvbiBnbyB0bw0KPGI+aHR0cHM6Ly9zaW90LWhhY2thdGhvbi5n
aXRodWIuaW88L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s
Pg0K

--_000_03FEBD3BDB6E4C6AADD0CFB4016AB90Cciscocom_--


From nobody Wed Nov 20 07:32:04 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE27E120AC4 for ; Wed, 20 Nov 2019 07:31:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.642
X-Spam-Level: 
X-Spam-Status: No, score=-0.642 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, MALFORMED_FREEMAIL=1.355, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtRhVxDLYnwG for ; Wed, 20 Nov 2019 07:31:58 -0800 (PST)
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 D798E1208CC for ; Wed, 20 Nov 2019 07:31:58 -0800 (PST)
Received: by mail-pf1-x42e.google.com with SMTP id q13so14391503pff.2 for ; Wed, 20 Nov 2019 07:31:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version; bh=RuCYRYqyq+1tgZX8J7UiZSeqmuAHNUVUnlTAYPRdbXU=; b=PTws9zIoZI3yGmH2Io1SG33UuVp/zcVm3kexjpaiCh+Ixad5RjsbWWufTW8t1FepJF c02JIn0JxJBal0D3h8A8zKYf89sboFNS/Q52xMuYJnLM+IlWgtnlhqLmjRzeBVoSvmbK sSkSlowaXEqLoyoJ0R/YKt2lPozdi6WK58lBLEOK1R5TKr7XWoaESvQdtnYe2Xya/9P6 vIi/GaFChC/5h6BDX/RUF0nICqbfexUekUQ++HeIITkoW6ndLDjaLPjdkzmoazb8+rmy DDd6ugqxe5Tf1ftk7QS7LaVujiAnW+gmP7+EWPa6ii6c86+uPTZvSCgitzBDt16a/58S iwWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version; bh=RuCYRYqyq+1tgZX8J7UiZSeqmuAHNUVUnlTAYPRdbXU=; b=d0hzKC4oo2Q3S8TWBNJQz8uo9s3OtNUsvbu157VyO0IBNOvCw3UF/EyD5Iy1YZGS0p wu3O0mG4YIvq1Z25BBTNegUyGc5mYaQeE34HGs7dPQCL5jsHahlrcvC6i2y2dLn4ebCx 9e0wWEXq7tNP2tivzP38ZHwvJUw1h1ePFQyP+jdFRMenL5tn+r5glBQRl5UtbOQcq7VH IFuSf8Llb4ej+UqEVfKd5qEelJUJxpb0PapXQvtolzvMZXsEynMCk9342Gzg5l5u0Sq5 FRDOSQnuaFihyj6Q7nLnYPLhqWjHZKeDDDPGqNscoeAeSNaNe3jtKU091cx2EbZi9Hsm X2Zg==
X-Gm-Message-State: APjAAAVIJ37qUeSsuwR3E2qTEzSVLvYclLUm40/EsII4AnFS8SupSCHC PgogIQCwf5SaMBFIHu+xiXcaW1kj+sQ=
X-Google-Smtp-Source: APXvYqxWKobowMrfHbmI+5Crp5s+OeICpAfs7LO2MVP3OFjLB7Q5xa4ZcXnoPZMb0VTr/RZmj54EAQ==
X-Received: by 2002:aa7:9f0e:: with SMTP id g14mr4901481pfr.202.1574263918263;  Wed, 20 Nov 2019 07:31:58 -0800 (PST)
Received: from [172.16.1.155] ([118.200.243.218]) by smtp.gmail.com with ESMTPSA id s24sm30316247pfh.108.2019.11.20.07.31.57 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Nov 2019 07:31:57 -0800 (PST)
User-Agent: Microsoft-MacOutlook/10.1f.0.191110
Date: Wed, 20 Nov 2019 23:31:55 +0800
From: Yaron Sheffer 
To: "saag@ietf.org" 
Message-ID: <444AEE91-1462-4AF5-A3B0-ED5FCD75C372@gmail.com>
Thread-Topic: SecEvent WG report
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3657137517_1802267620"
Archived-At: 
Subject: [saag] SecEvent WG report
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Nov 2019 15:32:03 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3657137517_1802267620
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

SecEvent did not meet in Singapore. As of today, we have two documents in =E2=
=80=9Cpublication requested=E2=80=9D (push and poll SET transport). We decided to drop=
 our third outstanding document and asked the authors to publish elsewhere. =
We plan to formally wrap up the working group once the documents have gone t=
hrough IESG review.

=20

Thanks,

=20

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Dick and Yaron

=20

=20


--B_3657137517_1802267620
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


SecEvent di=
d not meet in Singapore. As of today, we have two documents in =E2=80=9Cpublicatio=
n requested=E2=80=9D (push and poll SET transport). We decided to drop our third o=
utstanding document and asked the authors to publish elsewhere. We plan to f=
ormally wrap up the working group once the documents have gone through IESG =
review.
 
Thanks,
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Dick and Yaron
 <=
/p>
 


--B_3657137517_1802267620--



From nobody Wed Nov 20 12:18:25 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E27D1200D7 for ; Wed, 20 Nov 2019 12:18:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pd74eX69tsvC for ; Wed, 20 Nov 2019 12:18:21 -0800 (PST)
Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC04120020 for ; Wed, 20 Nov 2019 12:18:21 -0800 (PST)
Received: by mail-oi1-x22d.google.com with SMTP id o12so972074oic.9 for ; Wed, 20 Nov 2019 12:18:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=hMzZiLdLbVYOaRSgTIRJjZUqq3eQulnmB2LRkRtqC9g=; b=TdJDGmky/tCqlucZidSCQfaJ441EInm/J5guH8TfMTw8uL4Si3L93yA5ID7GrrpXnZ 6100AF/Lb9DMNKoMCsxni9fiqgA7yvdolEFUOw07n+sqy9IS7l5TYp3a6X21v/twhqrZ 9V4G2Ni8O2wWeh7ww4d7y2iSpTxGPNa3wj4PWfXgGwzcdSkkuq42embEqnBjF6QIcQUS fB03NBbquo3jQjHZnQ+aEJIVi2Ro7y1bnQ4Gq74XiaBQYp/IaKcHqvB6dVK1k8wTJLKP W8ArvCBd50Gas0e8ETJDmYPKF5Ksc55jNtl46VmhqhrT4/tqFa1cYrRbV49zpolexEFk Xanw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hMzZiLdLbVYOaRSgTIRJjZUqq3eQulnmB2LRkRtqC9g=; b=gJ5KQK12mX94734ReuA30C3GGVuC0uX1mC68aS+PXZgf5f6nNVYZU3shLIhuWAjyBn XiHUBqhQgEpCROh4D21LOBEqrQDlgErKXz2tpz9C06keGR3nrSqSDYQpTSj2SrcLqVf5 lyD5sWU+kJsPEdZ4qoa+4TBAejVu/bpE08quBWsAGH0Y1bRjZpTkVxe3LltQoO8tm14e v6gwZ8p7kkjYlNISoa+Q/VPloMuV+rnx5rJoxyQL+BnNpxEOD/cULC6Ecugt2idWBrhk yTAXdA0emQOa2JizjE0JvfdpedoyM0WeG3lgpXaa0DvQFOKnFM61/RrI19iy7PKifEW5 aS1w==
X-Gm-Message-State: APjAAAXOrcVl4sUbW4Xwx9SKCh/Jkenv97YWW/FOoQVLfLDYiOefLg49 TP1q4rMv6JV8o2soupd2OpKnQs4/GPMUXbA1RW+WJ89XIM0=
X-Google-Smtp-Source: APXvYqwUIfMAnGo7BXpfj4j8K4/+98xcWXD1Ea8MXY5r9+RW9l69SByRbDUZIt/uVkverVRznl9KBeU1Vo5daDIka+k=
X-Received: by 2002:a05:6808:498:: with SMTP id z24mr4469123oid.114.1574281100390;  Wed, 20 Nov 2019 12:18:20 -0800 (PST)
MIME-Version: 1.0
From: Kathleen Moriarty 
Date: Wed, 20 Nov 2019 15:17:44 -0500
Message-ID: 
To: saag@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c3f6260597cce11b"
Archived-At: 
Subject: [saag] RATS Report
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Nov 2019 20:18:24 -0000

--000000000000c3f6260597cce11b
Content-Type: text/plain; charset="UTF-8"

Greetings!

The RATS working group had it's first session on Tuesday, focused on
adopted material, the Entity Attestation Token draft.
https://datatracker.ietf.org/doc/draft-ietf-rats-eat/
Decision points on open issues were discussed and clarified, prioritizing
work to move towards completion of the draft.  The consensus calls will be
taken to the list and include types of EATs (supporting use cases) and
specific claims.

A briefing was also provided on Qualcomm Wireless Edge Services, where
attestation is a key service.

Friday's session will cover several drafts in active development, with the
goal of gaining adoption on a few of them.  The architecture draft, RIV,
and data model will be discussed.  The information model will be discussed
in an interim to be held soon.

The WG is likely to hold several interim sessions between now and the next
meeting as this has been helpful to the group to drive progress.

-- 

Best regards,
Kathleen

--000000000000c3f6260597cce11b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Greetings!

The RATS wor=
king group had it's first session on Tuesday, focused on adopted materi=
al, the Entity Attestation Token draft.
Decision=C2=A0points on open issues w=
ere discussed and clarified, prioritizing work to move towards completion o=
f the draft.=C2=A0 The consensus calls will be taken to the list and includ=
e types of EATs (supporting use cases) and specific claims.

<=
/div>
A briefing=C2=A0was also provided on Qualcomm Wireless Edge Servi=
ces, where attestation is a key service.

Friday=
9;s session will cover several drafts in active development, with the goal =
of gaining adoption on a few of them.=C2=A0 The architecture draft, RIV, an=
d data model will be discussed.=C2=A0 The information model will be discuss=
ed in an interim to be held soon.

The WG is likely=
 to hold several interim sessions between now and the next meeting as this =
has been helpful to the group to drive progress.

-- 

Best regards,
Kathleen
<=
/div>


--000000000000c3f6260597cce11b--


From nobody Wed Nov 20 14:25:57 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72025120820 for ; Wed, 20 Nov 2019 14:25:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkO8JZxmjO9h for ; Wed, 20 Nov 2019 14:25:54 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE0D41200CE for ; Wed, 20 Nov 2019 14:25:54 -0800 (PST)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAKMN0Qx004630 for ; Wed, 20 Nov 2019 22:25:54 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=I93XHrCzhtm/mo4u/2mt3i/JWrqjX5h+e9Mgr4M/LfU=; b=MUHPj6i8E0yZVFdYjGNKKz/DbBNuvmKKQndzE5F3yXxWqYvYOEI4wQXKFAd5/4rKfYX7 N3gZgLWd1HSddabjs38JNtBghRO02uEri34W+FcbjTezEIJNHMa/j4HuW3bDvELvSL6d CUxC6YzFuRvLH19cjF6qEOeW8snCuvaB9eT1ZlSFgYCfogGjxnKd7Z1ZeQ/1cTlaId+v iXgqAhrqrpHniclSay0JtfVH2SaX9bAr311JceDV15miGfuSus2Eu7SQls/PoxLVo+YQ yVyHwSfxwxdzwrJZlqSWiTvEeb1cD3GSBBW6tAX6JVBBzBDWBa19Z7/7o9NZdnicKdmk Cg== 
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2wafutvdqq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 20 Nov 2019 22:25:54 +0000
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAKMHKxa012202 for ; Wed, 20 Nov 2019 17:25:53 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2wadayngke-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 20 Nov 2019 17:25:53 -0500
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Nov 2019 17:25:52 -0500
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Wed, 20 Nov 2019 17:25:52 -0500
From: "Salz, Rich" 
To: saag 
Thread-Topic: ACME report
Thread-Index: AQHVn/F3V+bXrJ8ln0+59rKpn2pbow==
Date: Wed, 20 Nov 2019 22:25:51 +0000
Message-ID: <571383E6-0EF3-46F4-B2E8-8E5EA30C6AD4@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1f.0.191110
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.216.64]
Content-Type: multipart/alternative; boundary="_000_571383E60EF346F4B2E88E5EA30C6AD4akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-20_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=436 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911200189
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-20_07:2019-11-20,2019-11-20 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 mlxscore=0 priorityscore=1501 mlxlogscore=412 adultscore=0 bulkscore=0 malwarescore=0 lowpriorityscore=0 clxscore=1011 impostorscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911200189
Archived-At: 
Subject: [saag] ACME report
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Nov 2019 22:25:56 -0000

--_000_571383E60EF346F4B2E88E5EA30C6AD4akamaicom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QUNNRSBmYWxscyBiYWNrIHRvIGl0cyB1c3VhbCDigJxsYXN0IG1lZXRpbmcgb2YgdGhlIHdlZWvi
gJ0gc2xvdC4gOigNCldlIGhhdmUgc2V2ZXJhbCBkcmFmdHMgaW4gdGhlIHF1ZXVlLCBhIGNvdXBs
ZSBtb3JlIHdlIGFyZSBwcm9ncmVzc2luZywgYSBjb3VwbGUgb2YgY2FuZGlkYXRlcyBmb3IgYWRv
cHRpb24uDQoNCg==

--_000_571383E60EF346F4B2E88E5EA30C6AD4akamaicom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz
cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z
b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g
MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp
b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBs
YW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i
V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij5BQ01FIGZhbGxzIGJhY2sgdG8gaXRzIHVzdWFsIOKAnGxhc3QgbWVldGluZyBv
ZiB0aGUgd2Vla+KAnSBzbG90LiA6KDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5XZSBoYXZlIHNldmVyYWwg
ZHJhZnRzIGluIHRoZSBxdWV1ZSwgYSBjb3VwbGUgbW9yZSB3ZSBhcmUgcHJvZ3Jlc3NpbmcsIGEg
Y291cGxlIG9mIGNhbmRpZGF0ZXMgZm9yIGFkb3B0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_571383E60EF346F4B2E88E5EA30C6AD4akamaicom_--


From nobody Wed Nov 20 14:28:31 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E8C120820 for ; Wed, 20 Nov 2019 14:28:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GX13ROtJCzNI for ; Wed, 20 Nov 2019 14:28:27 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B42CC1200CE for ; Wed, 20 Nov 2019 14:28:27 -0800 (PST)
Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAKMN7Yv004829; Wed, 20 Nov 2019 22:28:14 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=bPeqMce7JHpoHLq/eyW+1c3ycwZ/Ev1rXFmrtmmABvo=; b=FzhQkXhJrHq1fQ105OVy2Oj0DkXGzJoSb4/dWJKUb0cWdFXqUzfr6WB1YhNenPpXZMTV GBaw824keXn7IAEOnpompXSEAPocMeUIeQaUFO9tGr8v4kDs+23pireCAYMFl3ssD071 kMemMlwH+Osxqydcegcq+AhEMiXczwhq421TxNLlZ/agamN0S61GVp/K82wNjS2nDNYi K6Ntx2p3x5mpxzn3sKqRUCpCPEP7VhjWa//gGumzDRO9AzAN93fR4OhXNehIbOIZNlc1 qkjZ5yva/3A3OvmcJnWaqjpZQDBjwj7gZES6hB2B+qkFz2aaBTu+OZzVjU7mPIYVXoeM GA== 
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2wafq0cdwm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Nov 2019 22:28:13 +0000
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAKMHK5Q021191; Wed, 20 Nov 2019 17:28:12 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2wadb05eqe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 20 Nov 2019 17:28:12 -0500
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Nov 2019 17:28:11 -0500
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Wed, 20 Nov 2019 17:28:11 -0500
From: "Salz, Rich" 
To: saag 
Thread-Topic: MATHMESH report
Thread-Index: AQHVn/HKE80dqS8NF0uVAlTXQ2/snA==
Date: Wed, 20 Nov 2019 22:28:11 +0000
Message-ID: <224B472E-E367-48FD-BB05-DB0F8FAF25D5@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1f.0.191110
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.216.64]
Content-Type: multipart/alternative; boundary="_000_224B472EE36748FDBB05DB0F8FAF25D5akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-20_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=569 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911200189
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-20_07:2019-11-20,2019-11-20 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 phishscore=0 malwarescore=0 spamscore=0 adultscore=0 lowpriorityscore=0 priorityscore=1501 mlxscore=0 bulkscore=0 clxscore=1015 mlxlogscore=545 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911200189
Archived-At: 
Subject: [saag] MATHMESH report
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Nov 2019 22:28:30 -0000

--_000_224B472EE36748FDBB05DB0F8FAF25D5akamaicom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIE1hdGhlbWF0aWNhbCBNZXNoIChNQVRITUVTSCkgQm9GIG1ldCBNb25kYXkuICBJdCB3YXMg
d2VsbC1hdHRlbmRlZCB3aXRoIGxpdmVseSBkaXNjdXNzaW9uLiAgTW9yZSBkaXNjdXNzaW9uIGlz
IG5lZWRlZC4gVGhlIGFjdHVhbCBzdHJ1Y3R1cmUgb2YgdGhhdCBkaXNjdXNzaW9ucyBJIGxlYXZl
IHRvIHRoZSBTZWNBROKAmXMgdG8gZXhwbGFpbiBvbiB0aGlzIHRocmVhZCBhcyB0aGUgc2Vzc2lv
biBlbmRlZCB1cCB3aXRoIHRoZW0gdHJ5aW5nIHRvIHB1YmxpY2FsbHkgbXVkZGxlIHRocm91Z2gg
dG8gZ2V0IHNvbWUgY29uY2x1c2l2ZSBxdWVzdGlvbnMuDQo=

--_000_224B472EE36748FDBB05DB0F8FAF25D5akamaicom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz
cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z
b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6
IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g
MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp
b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBs
YW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i
V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij5UaGUgTWF0aGVtYXRpY2FsIE1lc2ggKE1BVEhNRVNIKSBCb0YgbWV0IE1vbmRh
eS4mbmJzcDsgSXQgd2FzIHdlbGwtYXR0ZW5kZWQgd2l0aCBsaXZlbHkgZGlzY3Vzc2lvbi4mbmJz
cDsgTW9yZSBkaXNjdXNzaW9uIGlzIG5lZWRlZC4gVGhlIGFjdHVhbCBzdHJ1Y3R1cmUgb2YgdGhh
dCBkaXNjdXNzaW9ucyBJIGxlYXZlIHRvIHRoZSBTZWNBROKAmXMgdG8gZXhwbGFpbiBvbiB0aGlz
DQogdGhyZWFkIGFzIHRoZSBzZXNzaW9uIGVuZGVkIHVwIHdpdGggdGhlbSB0cnlpbmcgdG8gcHVi
bGljYWxseSBtdWRkbGUgdGhyb3VnaCB0byBnZXQgc29tZSBjb25jbHVzaXZlIHF1ZXN0aW9ucy48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_224B472EE36748FDBB05DB0F8FAF25D5akamaicom_--


From nobody Wed Nov 20 15:56:22 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437601208AD for ; Wed, 20 Nov 2019 15:56:21 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 IuBDtuFx-ZnV for ; Wed, 20 Nov 2019 15:56:19 -0800 (PST)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 8BF3A120884 for ; Wed, 20 Nov 2019 15:56:19 -0800 (PST)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id xAKNuIdb016216 for ; Wed, 20 Nov 2019 18:56:18 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu xAKNuIdb016216
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1574294178; bh=SfdoaI1yEIQSCOxaz7r6Ez86zuAQ0vT/KaCPQevB1i4=; h=From:To:Subject:Date:From; b=dcU2A4Bbzsny7C2pBn9j5yHsFdbUxxRBgMdSXFWm65BCZaKqGe1IgTvrhraO9l+Qg WgJh9zE46lYtf4tl7yZI/gupJadXydB9+yo4rcgxLkidxiGn4IJk4NhM4FJ+IMXRRW vAklQjI0/tLxZaGhWg5co9CuWzsTmJAJaXeEQFAY=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id xAKNuDpj003704 for ; Wed, 20 Nov 2019 18:56:14 -0500
Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0468.000; Wed, 20 Nov 2019 18:56:13 -0500
From: Chris Inacio 
To: "saag@ietf.org" 
Thread-Topic: SACM report
Thread-Index: AQHVn/4WX2iGe/lfgUGpJN8dUSAvpQ==
Date: Wed, 20 Nov 2019 23:56:13 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.201.19]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: [saag] SACM report
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Nov 2019 23:56:21 -0000

U0FDTSBtZXQgZmlyc3QgdGhpbmcgb24gVHVlc2RheSBtb3JuaW5nLiAgDQoNClRoZSBXR0xDIGlz
IGNvbXBsZXRlIGFuZCB0aGUgV0cgd2lsbCBwcm9ncmVzcyBST0xJRSBzb2Z0d2FyZSBkZXNjcmlw
dG9yIChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNhY20tcm9s
aWUtc29mdHdhcmVkZXNjcmlwdG9yLykgdG8gdGhlIElFU0cuDQoNClRoZSBFbmRwb2ludCBQb3N0
dXJlIENvbGxlY3Rpb24gUHJvZmlsZSAoaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv
ZHJhZnQtaWV0Zi1zYWNtLWVwY3AvKSBjb21wbGV0ZWQgb25lIHJvdW5kIG9mIFdHTEMsIGJ1dCBy
ZXF1aXJlcyBhbm90aGVyIHNldCBvZiByZXZpZXdzIGJhc2VkIG9uIHRoZSBudW1iZXIgb2YgZWRp
dHMgZnJvbSB0aGUgV0dMQy4gIFJldmlld2VycyBhcmUgaWRlbnRpZmllZCBhbmQgdGhlIFdHIGV4
cGVjdHMgdG8gcHJvZ3Jlc3MgdGhlIGRvY3VtZW50IGJlZm9yZSBJRVRGLTEwNy4NCg0KQ29zd2lk
IChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNhY20tY29zd2lk
LykgaGFzIGNvbXBsZXRlZCBtdWx0aXBsZSBXR0xD4oCZcyBidXQgYSBsYXRlIGFkZGVkIGNvbW1l
bnQgYWJvdXQgc2lnbmluZyB0aGUgaW52ZW50b3J5IHN0YXRlbWVudHMgbmVlZHMgdG8gYmUgcmVz
b2x2ZWQgYmVmb3JlIHRoZSBkb2N1bWVudCBwcm9ncmVzc2VzIHRvIElFU0cuDQoNClRoZSBXRyBh
bHNvIGRpc2N1c3NlZCBhbmQgbWFkZSBwcm9ncmVzcyBvbiB0aGUgYXJjaGl0ZWN0dXJlIChodHRw
czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNhY20tYXJjaC8pIGRyYWZ0
IGFuZCBpdHMgbGlua3MgYW5kIHJlbGF0aW9uc2hpcHMgdG8gYW4gaW5mbyBtb2RlbCBkcmFmdCAo
aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaW5hY2lvLXNhY20taW5mb21v
ZGVsLykgYW5kIHRoZSB0ZXJtaW5vbG9neSBkcmFmdC4NCg0KQ2hyaXMgSW5hY2lvDQoNCg0K


From nobody Wed Nov 20 16:04:46 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3449120168 for ; Wed, 20 Nov 2019 16:04:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEVK723wZrvy for ; Wed, 20 Nov 2019 16:04:42 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130077.outbound.protection.outlook.com [40.107.13.77]) (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 7CE26120130 for ; Wed, 20 Nov 2019 16:04:42 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bwKNwU5ALerM/iuei9NY/PgnembtPcKE8APFbTt4Va0YgwogEZZXVG2NK0zrHTrXYMhNifHLekc3Zf84ja/m+T149ccMdCeUVx2SGf4f9dbAZITCPJW5cb0unNhLNKuxpGmKjuYD3cPTBKJL9Y/hqaNY857+6kyf4a5bfUf1Hg4F6GW2uhloSXExGutEb35TA4pSjUeI3Nbx1jfYz7or4fa1scMxAA6NZWH/i0OLGro1kJBnMJHez5TMqtiU00oXfQ34/lhsv2s9dZCJSaRMLPdQFWvW6A6FEOmwsUxo/Z5wszdCtgMRTeUD3XW/nBUMushsULAWIRafbE7WROs8gA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HEk5ZMLapRD2RYVPwaaaBUrf17nbQEk5dKBhOROMbAc=; b=F9c8lpABV8jAELgFjcxhfd63merUlRUIVA4hlZCVQoE55KI3KN+l3c+JA15nlCeHcgtoo9pUlDZHo4yvakjuIMVPVqzuBoqd6PNyC24zCB9oOYlPlfoUVrHqeBGEvL3PPpMEFuarPsLDsilSnApIlGRS4qRCj8xH+xqro3pR9m+6mE8hE0vEgLKmVWAU/VNlpyf+upx6lVXKWVEq+b5D3coq7SJNhFmZWL6r6O/1PxG2gRvc2s1RAf9LokFY5ORZdd+1kJTI8AyBiZMlaJ2CUUMsT+AleE2U5vAgIIE5tkIDj2vpWGKLcuDNotqk3RBpfXJnpeKXt39h439Wj5TxeQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HEk5ZMLapRD2RYVPwaaaBUrf17nbQEk5dKBhOROMbAc=; b=qgAZj0ZS2edi78iXtYXC5tIdIAo2/V4gxI1KLV1Ad9Y5CA8GAvItuomTIQxYOJuKCOmvv69TZFy6KZemvEkBgPTJjUOnVbyuZ1slrnmt/1lRvBsUrCy7uxQwVRE3tZVe8LhNtrSjdPnJ6QRF82Degaa+v5cUZoTGdBBG0ysDWdc=
Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2858.eurprd07.prod.outlook.com (10.168.91.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.13; Thu, 21 Nov 2019 00:04:39 +0000
Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::88e5:d23a:73a5:b78e]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::88e5:d23a:73a5:b78e%6]) with mapi id 15.20.2474.015; Thu, 21 Nov 2019 00:04:39 +0000
From: Mohit Sethi M 
To: "saag@ietf.org" 
Thread-Topic: EMU report
Thread-Index: AQHVn/9EviF3mRqxo0S48G7JrUvqQw==
Date: Thu, 21 Nov 2019 00:04:39 +0000
Message-ID: <341e8655-ddd6-a3b2-aaf9-4630191774ad@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; 
x-originating-ip: [31.133.156.79]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 519b9a2b-370e-4cfe-fe32-08d76e166739
x-ms-traffictypediagnostic: HE1PR0701MB2858:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 0228DDDDD7
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(366004)(396003)(346002)(39860400002)(189003)(199004)(486006)(6486002)(99286004)(6506007)(256004)(58126008)(5660300002)(71200400001)(71190400001)(478600001)(2616005)(36756003)(26005)(4744005)(476003)(102836004)(316002)(186003)(6116002)(3846002)(3480700005)(6436002)(14454004)(5640700003)(6512007)(31696002)(2906002)(86362001)(2351001)(25786009)(8936002)(66066001)(66946007)(65806001)(221733001)(64756008)(65956001)(2501003)(76116006)(66556008)(305945005)(66446008)(66476007)(91956017)(7736002)(81156014)(81166006)(1730700003)(31686004)(6916009)(8676002)(7116003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2858; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: TGFg7V7VswmMtgGJOoMP1SQUcV/9XWYg7bFuUQ7RmXDVIZ7+sTLId/SwEpNM48f6GFD3Ekc7j/Eksv8S+KMUGJqRXFF3100FHq11Et21u/U9dLURMmLEmuPli4XKKGtkiLKIOl0mRjSeTDAwslgcsHeO0xY77DytjY8epxdWi1ChwO7TBIlJOvF4tgGk1CRBm41onAX457DdDg1NXWfB523zcACsmHAwdWjusGhnjWAP7ukVG1fLC2agMaJHltVEoYBtRCOHEdSsqH3V9SEQD507wAH5UAqhBntVQPuuojAmA1ygwUof8fLddnrf8NZfHxFe5IZs/JZG6LzwQP12EHUyugbJz5YL+rIURs6czmlJ4/UydXp7njMaqCuCt9s58eNICMJLO/oOBQlzPBzQ+VpoYswhqt+J84tcWdFezkaAHy/O3QisXlN77+PqXd8A
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <3E24075D30F394478D8CC4C120EDAA22@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 519b9a2b-370e-4cfe-fe32-08d76e166739
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2019 00:04:39.5214 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bT5us6dY6EN055zZ7a/vwO4ThAXlYB19bxFrgtoyEPaylW3oU833cdSx3kWQvV8GHdn1yNCvBScONwGsPERYx/biGyB0uP2kYRDXDkeI4lY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2858
Archived-At: 
Subject: [saag] EMU report
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Nov 2019 00:04:45 -0000

VGhlwqBFTVXCoFdHwqBtZXTCoG9uwqBNb25kYXnCoChOb3ZlbWJlcsKgMTgpwqBiZXR3ZWVuwqAx
NTo1MMKgLcKgMTc6NTAuDQoNClVwZGF0ZXPCoHRvwqB0aGXCoGZvbGxvd2luZ8Kgd29ya2luZ8Kg
Z3JvdXDCoGRvY3VtZW50c8Kgd2VyZcKgcHJlc2VudGVkOg0KDQotIGRyYWZ0LWlldGYtZW11LXJm
YzU0NDhiaXMtMDYgKFB1YmxpY2F0aW9uIGFzIEluZm9ybWF0aW9uYWwgUkZDIGhhcyANCmJlZW7C
oHJlcXVlc3RlZCkNCi0gZHJhZnQtaWV0Zi1lbXUtZWFwLXRsczEzLTA3IChEaXNjdXNzZWQgaG93
IHRvIGRlYWwgd2l0aCBUTFMgMS4zIA0KZXh0ZXJuYWzCoFBTS8KgbW9kZSkNCi3CoGRyYWZ0LWll
dGYtZW11LWVhcHRsc2NlcnQtMDHCoChEZWNpZGVkwqB0b8KgaXNzdWXCoHdvcmtpbmfCoGdyb3Vw
wqBsYXN0wqBjYWxsKQ0KLSBkcmFmdC1pZXRmLWVtdS1ha2EtcGZzLTAxIChEaXNjdXNzZWQgdXBk
YXRlcyB0byB0aGUgZG9jdW1lbnQgc2luY2UgDQp3b3JraW5nwqBncm91cMKgYWRvcHRpb24pDQoN
ClRoZcKgZm9sbG93aW5nwqBub24td29ya2luZ8KgZ3JvdXDCoGRvY3VtZW50c8Kgd2VyZcKgcHJl
c2VudGVkOg0KDQotwqBkcmFmdC1kZWtvay1lbXUtdGxzLWVhcC10eXBlcy0wMA0KLcKgZHJhZnQt
YXVyYS1lYXAtbm9vYi0wNw0KLcKgZHJhZnQtbGVhci1lYXAtdGVhcC1icnNraS0wNQ0KLcKgZHJh
ZnQtcGFsYS1lYXAtY3JlZHMtMDUNCi3CoGRyYWZ0LXJpZWNrZXJzLWVhcHBhcmFtZXRlcmV4dGVu
c2lvbi0wMA0KLcKgZHJhZnQtZnJpZWwtYWNtZS1pbnRlZ3JhdGlvbnMtMDINCg0KV2UgYXJlIG5v
dyB3YWl0aW5nIGZvciB0aGUgcmV2aXNlZCBjaGFydGVyIHRvIGJlIGFwcHJvdmVkIGJ5IHRoZSBJ
RVNHLg0KDQpKb2XCoGFuZMKgTW9oaXQNCg0K


From nobody Wed Nov 20 16:33:15 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411051208CA for ; Wed, 20 Nov 2019 16:33:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level: 
X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 F7wAR0RGkt88 for ; Wed, 20 Nov 2019 16:33:12 -0800 (PST)
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 B03E01200B5 for ; Wed, 20 Nov 2019 16:33:11 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4F56BBE5B; Thu, 21 Nov 2019 00:33:09 +0000 (GMT)
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 sQIsdasg1khV; Thu, 21 Nov 2019 00:33:06 +0000 (GMT)
Received: from [31.133.134.154] (unknown [31.133.134.154]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 240D7BE5C; Thu, 21 Nov 2019 00:33:04 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1574296386; bh=2U+B8oyYkcSE4oVBIbZZwPQxjgHZVqM4RKeQSlG5ISk=; h=To:Cc:From:Subject:Date:From; b=z3eSmylJ1uv8DyrbLVZ9oHvAmOLnIkGsVLzAnTAjiou1BbabjwYxad84ob589EDH0 tMIcNU5GVYHBi5KxwfVrHCGNSeO4paffKasbXW6V3g0UK6lolS/X8XdwkH8+G9nmDz JpwO99+7VY+DyBTKH7zDNqcHPucG5Hf1v1GvcrNI=
To: "saag@ietf.org" 
Cc: =?UTF-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= 
From: Stephen Farrell 
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: 
Date: Thu, 21 Nov 2019 00:32:55 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Sie8zpxXS7GyUKzCfdw182OqrA9HmnJa0"
Archived-At: 
Subject: [saag] lake WG report
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Nov 2019 00:33:14 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Sie8zpxXS7GyUKzCfdw182OqrA9HmnJa0
Content-Type: multipart/mixed; boundary="JO0CnI9AC0HrA0uLAzyegSOTU4Rzd4Gkd";
 protected-headers="v1"
From: Stephen Farrell 
To: "saag@ietf.org" 
Cc: =?UTF-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= 
Message-ID: 
Subject: lake WG report

--JO0CnI9AC0HrA0uLAzyegSOTU4Rzd4Gkd
Content-Type: multipart/mixed;
 boundary="------------F0D6B77734DF9192C26F2D50"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------F0D6B77734DF9192C26F2D50
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

The lake wg met for the first time to work on lightweight
authenticated key exchange. Initial work is focused on
requirements. The people in the room seemed happy to adopt
a draft [1] and there was constructive discussion of some
issues that were previously raised on the list. We'll
confirm that on the list and go from there.

Cheers,
Stephen &  Mali=C5=A1a.

[1] https://tools.ietf.org/html/draft-selander-lake-reqs

--------------F0D6B77734DF9192C26F2D50
Content-Type: application/pgp-keys;
 name="0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem
CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT
q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE
gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy
+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5
iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9
to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV
B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5
FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK
7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t
lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB
tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9
UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG
CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk
rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr
sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ
sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG
nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk
d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG
FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV
N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v
ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv
tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9
UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok
Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm
uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT
AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ
IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5
DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X
CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq
Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h
cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp
MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB
ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ
yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V
4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy
I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv
X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg
2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc
/MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu
4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8
pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh
jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm
bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6
+uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh
5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K
LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv
8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5
6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB
g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs
QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC
HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO
M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP
2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s
/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj
Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k
4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl
AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg
vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r
wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o
4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA
xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd
8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6
NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc
Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY
tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1
WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E
DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv
e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK
CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP
GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT
MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9
gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX
ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF
L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D
Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb
hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M
SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt
GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA
5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+
ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb
tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/
l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX
4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo
7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj
CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR
Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg
Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx
mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88
zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2
EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI
z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr
Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB
4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF
CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl
vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk
bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB
p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE
5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3
berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL
3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy
ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R
WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc
EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI
6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h
qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y
BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1
n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq
hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw
2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY
m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T
5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB
LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H
Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S
oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06
TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs
0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk
mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9
M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo
DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK
BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0
H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO
JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh
B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB
KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48
ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw
nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool
sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ
lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws
4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd
AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY
zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk
rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04
fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N
kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+
FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8
AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB
BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt
tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg
evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7
vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB
HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD
8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M
sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE
4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb
TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3
vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm
oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r
+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f
Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7
Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1
gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF
6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd
n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25
2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN
JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw
rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs
okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY
o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk
d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU
yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk
vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3
YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST
=3DYzQY
-----END PGP PUBLIC KEY BLOCK-----

--------------F0D6B77734DF9192C26F2D50--

--JO0CnI9AC0HrA0uLAzyegSOTU4Rzd4Gkd--

--Sie8zpxXS7GyUKzCfdw182OqrA9HmnJa0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl3V2zcACgkQWrL68XsX
K+oXYA//aZXUmfkE9U/k7Y/wNnDDMDvU2ga11n1nLCS0BbS0dPVGBsoIH197FTSN
5/cheeJcRFlw+Vob/Wb7qSDiBZIxBdryUrsAfuyeKqPJWMP5rTU8MSymUWRGyy3I
1+FquZBSYUKQwK9S5hlppSv9zAO6dXn9u9DuRiHQiAOBiRrePaCJQpschVJ+mvhw
mXBpZLmLSBmBeJzYAM7SE3YdJaZeQGS6C1qW6M45TvCOoZq9wwrO/bvnbygp6vQw
W745SY4PKxq/+QB6ad8oGgqnLKcMKgRG25w7GXeo++JfMg73uLzkvcnhFQQMoPGQ
TWMXUkA/v/NqkuG1hA3Aw7Xk24PzFqjrYYWhcGTOgHFHQ8lB3ktd6CjIqappQKPb
eSrz/JN6G/4hTJ1wTWuuTItnpBngM5AeLAGhBg7UUpgSfuhXogihPJ3qovxXFOA+
JItHE3ctYnz1DtAJl85St/OwxqN7OJ/k8L9x9xa75eqKLtjvHR+/KMdNzhA0ud08
ubGYlE1KhPLTbQvahsYtciS2RgTdKvtqxEB2ohn9tUGBmJwuSdtp6RR+t3PGHCDd
m2nUJK3xkwKrDo5TMO+texy82rkRKp378hTCo2b6ygbtZ0Lr8+YEd34ZsERxOeId
3c2OZjXVTHLGGQcCPFhf5eIGTH5m848G0tj1rJ9cbuDOkxs7UJY=
=gaoI
-----END PGP SIGNATURE-----

--Sie8zpxXS7GyUKzCfdw182OqrA9HmnJa0--


From nobody Wed Nov 20 17:25:21 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24E1120901 for ; Wed, 20 Nov 2019 17:25:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjMDHfJlcu5w for ; Wed, 20 Nov 2019 17:25:13 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD2D120900 for ; Wed, 20 Nov 2019 17:25:13 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id EF446300B0F for ; Wed, 20 Nov 2019 20:25:11 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BbILaz1T5CbG for ; Wed, 20 Nov 2019 20:25:11 -0500 (EST)
Received: from [5.5.33.66] (unknown [204.194.23.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 59E32300AE1; Wed, 20 Nov 2019 20:25:10 -0500 (EST)
From: Russ Housley 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: 
Date: Wed, 20 Nov 2019 20:25:07 -0500
Cc: IETF STIR Mail List 
To: IETF SAAG 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: [saag] STIR Summary
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Nov 2019 01:25:17 -0000

STIR WG has two documents with the IESG;  the group is ready to resolve =
comments, if any are raised.  The two documents are:
   -- draft-ietf-stir-oob
   -- draft-ietf-stir-passport-divert

STIR WG at IETF 106 talked about three documents at the session in =
Singapore:

The Certificate Delegation document (draft-ietf-stir-cert-delegation) is =
nearing completion.  Expect WG Last Call in January 2020.

The PASSporT Extension for Rich Call Data document =
(draft-ietf-stir-passport-rcd) has seen many updates, and it is making =
steady progress.

The individual Internet-Draft to support calls to emergency services =
(draft-dolly-stir-rph-emergency-services) was discussed, and the group =
expressed interest in adopting it.  A call for adoption will begin =
shortly.


From nobody Wed Nov 20 17:43:16 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A134120900 for ; Wed, 20 Nov 2019 17:43:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.405
X-Spam-Level: 
X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.244, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpZKSQJRh6rg for ; Wed, 20 Nov 2019 17:43:13 -0800 (PST)
Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) (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 39EC412011B for ; Wed, 20 Nov 2019 17:43:13 -0800 (PST)
Received: by mail-vs1-f45.google.com with SMTP id n9so1113724vsa.12 for ; Wed, 20 Nov 2019 17:43:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=jiQTlsHyJaEQWF+NzgYj7+NhMzSng7G93GEj6ddPLX8=; b=FSy3WclFAf2bYafIBPUJuDxx+TpBn+0NNta8GKrjtOQDVSGb9J5nQV9/uj2Xl+ldwE O6dVLDHLQ2CeLbQ7++GMmsnJu1RWpu7wY7gJQIwdbZpVp/YjQAtVM5m6bp/zGWyQRD92 Gjzwy1Mz6rqDvTRH3qDk8ZsA7FHhpErasxHLmtbsdsVScWlcbuE0kvblkoc8ZaoaB+Rj RSHpnjYgZoQMOEHd1ABWcx+6oFGmLqbreGc+K6Hx3kgHq9GACUcfvXKSwoMP5dkgNN7Y 2CqugzzQe59E678/JjgDZQivNphna8+ecQKaC7xVT/AGXDLBCgHAMod5vHh/4GxIPgO4 Vl9Q==
X-Gm-Message-State: APjAAAWuR4smSDOWNuggAqDIffuJd4P+NOru9wflpO0NIhBt72ny5XcB bEj9KH9ZD8y4ruMSo7Jr3omsl/rtD0IPlh9o0X1Ufx6W
X-Google-Smtp-Source: APXvYqzRHCVBDbqx7IhZ5jYwdVroi74R4ANjpHf9Ty7oT7hx1SfttvX8DAUX7ziU+4XyeIVaPwkFtasDZKVFQKIuEJY=
X-Received: by 2002:a67:7a8d:: with SMTP id v135mr4135757vsc.97.1574300592001;  Wed, 20 Nov 2019 17:43:12 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Daniel Migault 
Date: Thu, 21 Nov 2019 09:43:00 +0800
Message-ID: 
To: "saag@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000008e54fd0597d16bb6"
Archived-At: 
Subject: [saag] ACE WG report
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Nov 2019 01:43:14 -0000

--0000000000008e54fd0597d16bb6
Content-Type: text/plain; charset="UTF-8"

 The ACE working group met this week.

Since last IETF the following document has been shipped in the RFC editor
queue:
* draft-ietf-ace-cwt-proof-of-possession-11


The following document are under IESG review:

   - draft-ietf-ace-coap-est-16
   
   - draft-ietf-ace-dtls-authorize-08
   
   - draft-ietf-ace-oauth-authz-26
   
   - draft-ietf-ace-oauth-params-06
   
   - draft-ietf-ace-oscore-profile-08
   


The following drafts are active within the WG:

   - draft-ietf-ace-key-groupcomm-03
   
   - draft-ietf-ace-key-groupcomm-oscore-03
   
   - draft-ietf-ace-mqtt-tls-profile-02
   

The following draft is in call for adoption:

   - draft-palombini-ace-coap-pubsub-profile-06
   

--0000000000008e54fd0597d16bb6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


=C2=A0=
The ACE working group met this week.=C2=A0

Since l=
ast IETF the following=C2=A0document has been shipped in the RFC editor que=
ue:

The following document are under =
IESG review:

The fol=
lowing drafts are active within the WG:
=C2=A0


--0000000000008e54fd0597d16bb6--


From nobody Wed Nov 20 18:11:23 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8DC120840; Wed, 20 Nov 2019 18:11:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlIhQ_lNfCc7; Wed, 20 Nov 2019 18:11:16 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 CECC3120144; Wed, 20 Nov 2019 18:11:15 -0800 (PST)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 879566EDD92B17C363D5; Thu, 21 Nov 2019 02:11:13 +0000 (GMT)
Received: from lhreml718-chm.china.huawei.com (10.201.108.69) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 21 Nov 2019 02:11:12 +0000
Received: from lhreml718-chm.china.huawei.com (10.201.108.69) by lhreml718-chm.china.huawei.com (10.201.108.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 21 Nov 2019 02:11:13 +0000
Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml718-chm.china.huawei.com (10.201.108.69) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Thu, 21 Nov 2019 02:11:12 +0000
Received: from DGGEMM511-MBX.china.huawei.com ([169.254.1.140]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0439.000; Thu, 21 Nov 2019 10:11:05 +0800
From: "Xialiang (Frank, Network Standard & Patent Dept)" 
To: IETF SAAG 
CC: "dots@ietf.org" 
Thread-Topic: DOTS WG report for IETF 106:
Thread-Index: AdWgD1wa61NCe9H9QAqeDNWajQdKJg==
Date: Thu, 21 Nov 2019 02:11:05 +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.52.44.23]
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F13EA62360dggemm511mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [saag] DOTS WG report for IETF 106:
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Nov 2019 02:11:18 -0000

--_000_C02846B1344F344EB4FAA6FA7AF481F13EA62360dggemm511mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
DOTS session will be held in VIP A at 12:20-13:50 (Friday Morning session I=
I).
Here is the summary of the latest progress we have in the past months:

Submit to IESG for publish: draft-ietf-dots-use-cases, draft-ietf-dots-sign=
al-filter-control

Finish WGLC and Wait for Write-Up: draft-ietf-dots-signal-call-home, draft-=
ietf-dots-server-discovery

Be near for RFC publish: draft-ietf-dots-data-channel, draft-ietf-dots-sign=
al-channel

Be still in progress: draft-ietf-dots-architecture, draft-ietf-dots-multiho=
ming and some individual drafts

We will progress them in Friday session, hope to see guys then.

B.R.
Valery & Frank

--_000_C02846B1344F344EB4FAA6FA7AF481F13EA62360dggemm511mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


DOTS session will be held in VI=
P A at 12:20-13:50 (Friday Morning session II).


Here is the summary of the late=
st progress we have in the past months:


 


Submit to IESG for publish: dra=
ft-ietf-dots-use-cases, draft-ietf-dots-signal-filter-control


 


Finish WGLC and Wait for Write-Up: draft-ietf-dots-signal-call-home, draft-ietf-dots-server-disc=
overy


 


Be near for RFC publish: draft-=
ietf-dots-data-channel, draft-ietf-dots-signal-channel

 


Be still in progress: draft-iet=
f-dots-architecture, draft-ietf-dots-multihoming and some individual drafts=



 


We will progress them in Friday=
 session, hope to see guys then.


 


B.R.


Valery & Frank






--_000_C02846B1344F344EB4FAA6FA7AF481F13EA62360dggemm511mbxchi_--


From nobody Wed Nov 20 18:12:50 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7D8120144 for ; Wed, 20 Nov 2019 18:12:48 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smyslov.net
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 5T6rLLEZU6Bp for ; Wed, 20 Nov 2019 18:12:47 -0800 (PST)
Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (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 F0E1E120077 for ; Wed, 20 Nov 2019 18:12:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:To:From:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=fUwJgmzpKXSdr/OEWx2NrAtlVWlVftdYDw75tK9MiBs=; b=rbUrFQBPWkg9a7IP4JrJ6uzw0b 4jVe987zBkZq6dxjN/lZ0VCrscH4wDB5rCOxmCtKs3EU9aL6iHjywcdFXc/gl3tfE9CuM+D1LnJtS 0J4kAZ3Iye3EfWzcK+xGhCaA6lId5b+ScLcn58La+TVILJcPVP9c4MmqDusjJOYdxQvdJeNxEXgin uvHX8Kf8X8QQxeU6nbgnLObSx3r/sXsuAU4CbVeWP3RbAjb+kKEmidyKldZzwUH1r6Hwqo0rSvkWo +zjeTVrK9lDOiyXECL4rsByJ59NmDu0CzuY9s17hWbLCnuGS1lclf/MO8N6emogMSVZK17FhmNJqI 9RqeNDLQ==;
Received: from dhcp-89e8.meeting.ietf.org ([31.133.137.232]:56885 helo=svannotebook) by direct.host-care.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iXbxd-0006v7-6E; Wed, 20 Nov 2019 21:12:45 -0500
From: "Valery Smyslov" 
To: 
Date: Thu, 21 Nov 2019 05:12:41 +0300
Message-ID: <065801d5a011$29643960$7c2cac20$@smyslov.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdWgEEnF1BSYNFgkRqasIw35U275Eg==
Content-Language: ru
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - direct.host-care.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - smyslov.net
X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net
X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: [saag] UTA WG report
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Nov 2019 02:12:48 -0000

UTA doesn't meet at IETF106.

We have one WG draft (draft-ietf-uta-smtp-require-tls-09) in AUTH48 state
now.
For the other WG draft  (draft-ietf-uta-tls-for-email-03) the WGLC will be
issued soon.

Regards,
Leif & Valery.


From nobody Wed Nov 20 18:24:09 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F022312098B for ; Wed, 20 Nov 2019 18:24:07 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smyslov.net
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 yIiCYP7QdepO for ; Wed, 20 Nov 2019 18:24:06 -0800 (PST)
Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (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 D2D07120955 for ; Wed, 20 Nov 2019 18:24:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:To:From:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=YN0YaHoj8daJWA7Kc8w20TY3SnRSMepEfAVWkv/JnlM=; b=WRmlTxXonMT5XP3XvA9h8cHvlp bPEIlC7zAFrRrIwli8pDnHMNKOorifj1Z7oo+CGvwO9PHLQHvDi4ZeA39296ENDI0BJZ9xihtsk5p sgjK0vXIw92ht6CHcZOcLP/mJiazAteEefd9eCVDEH+ITP5u/FNC/8Iixhw3kb5vVT0MGFZ4mjVOH 0zClIjChTrlWMEovbqMfjSjSslklRc0doAYxAxro/2ZR2wbYkhfBo1V1YcdFya8P2qdHLzDfQEVX0 y0CahahYfJ70c6DJWct4V9vguwEEHm6+I0WGVM3tw+mkpyY3C4pN7uq/jFBAi9b6leBRz9W7qM21b hUjr/CyQ==;
Received: from dhcp-89e8.meeting.ietf.org ([31.133.137.232]:56906 helo=svannotebook) by direct.host-care.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iXc8Z-0000KQ-MG; Wed, 20 Nov 2019 21:24:04 -0500
From: "Valery Smyslov" 
To: 
Date: Thu, 21 Nov 2019 05:23:58 +0300
Message-ID: <066201d5a012$bdce0a30$396a1e90$@smyslov.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdWgETxzoPzsRuQnR6upKNUOP6FKJQ==
Content-Language: ru
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - direct.host-care.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - smyslov.net
X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net
X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: [saag] DOTS WG report
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Nov 2019 02:24:08 -0000

DOTS will meet on Friday.

We have progress in resolving of TSV AD DISCUSS for
draft-ietf-dots-signal-channel-38.
One draft (draft-ietf-dots-data-channel-31) is in RFC Editor queue waiting
for missing reference.
Three drafts (draft-ietf-dots-architecture-14,
draft-ietf-dots-signal-filter-control-02 and draft-ietf-dots-use-cases-20)
are in Publication Requested state waiting for AD review. 
Two drafts (draft-ietf-dots-server-discovery-06 and
draft-ietf-dots-signal-call-home-07) 
have passed WGLC and will be send to IESG soon.
There wasn't much discussion on the list regarding
draft-ietf-dots-multihoming-02,
but the authors expressed an intention to update it soon.

Regards,
Frank & Valery.


From nobody Wed Nov 20 19:10:50 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8D7120926; Wed, 20 Nov 2019 19:10:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level: 
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
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 O0vlmTpCeH65; Wed, 20 Nov 2019 19:10:45 -0800 (PST)
Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 2C7D71207FF; Wed, 20 Nov 2019 19:10:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1574305846; x=1605841846; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XzCXBHi3aSkoJfU+gpREN6dMC56Gm668jZKSffNhPtc=; b=jjGbooZFOHqV9oPeVL/ohHDsIHmp9wdKztX+pGNVDOVRzdLBRo44Oko8 45ABnRfjMfkQ97k2auB7ELqbwYb9ePLCZQh5AurV6E8o66SV09I6izMcy Ly8duZ6RU8DTuBWRmweIkr7DWxt81/Iry/cbjNe1W/6jr2mD3+jOMVpVo TL71HldEuF+tb8qB6TqaYGG0zvICvN3wfzvakuUh51RbhD4xFBwyXd2In wdzZ5aDyPAWbu/G61Ae6DCHluL1+fuvhQWpBlALR1b7DALkOlizly6WUz o6rs7FlSOoCHq4TTtqGg9zN9GBnirtuOJg9CXD8xLavhq18gXbeJeg9/j w==;
X-IronPort-AV: E=Sophos;i="5.69,224,1571655600"; d="scan'208";a="100921991"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing
Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-d.UoA.auckland.ac.nz) ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 21 Nov 2019 16:10:43 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 21 Nov 2019 16:10:42 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Thu, 21 Nov 2019 16:10:42 +1300
From: Peter Gutmann 
To: Tom Herbert 
CC: Stephen Farrell , David Schinazi , Joe Touch , "gorry@erg.abdn.ac.uk" , Mirja Kuehlewind , tsvwg IETF list , "saag@ietf.org" 
Thread-Topic: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
Thread-Index: AQHVlYavl0m+OZkGmkq1dk9tU/YKeqeHJEC3///AeQCADiJ0+g==
Date: Thu, 21 Nov 2019 03:10:41 +0000
Message-ID: <1574305843485.83458@cs.auckland.ac.nz>
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com>  <1573035094775.62307@cs.auckland.ac.nz> <87d3bcef-42e4-1535-db1f-06a8408d38d5@cs.tcd.ie> <1573109463764.56084@cs.auckland.ac.nz>  <1573542420083.60501@cs.auckland.ac.nz>, 
In-Reply-To: 
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Nov 2019 03:10:48 -0000

Tom Herbert  writes:=0A=
=0A=
>https://www.iab.org/wp-content/IAB-uploads/2014/12/semi2015_huitema.pdf=0A=
>describes with some detail how encryption of the transport layer is=0A=
>beneficial to resolve the tussel that results in protocol ossification.=0A=
=0A=
I'd always assumed the push for header encryption was due to some vague=0A=
handwaving about privacy or something else that's never really been made=0A=
clear, but from the above document it looks like the motivation is purely=
=0A=
ideological ("If we want to break that ossification, we have to do somethin=
g=0A=
drastic", "we can score at least a partial win for end-to-end connectivity"=
,=0A=
"application developers win a similar tussle", "reverses the balance of pow=
er=0A=
between end-to-end and middle-boxes"), which indicates that it'll end up as=
 a=0A=
repeat of the IPsec debacle ("Let's make sure IPsec breaks NAT, because IPs=
ec=0A=
will be bigger than NAT and so NAT will have to go away").=0A=
=0A=
Someone really needs to do a proper design document and threat model for th=
is=0A=
if it's that unclear what the goals of header protection are - is it for so=
me=0A=
sort of privacy thing, an ideological move because people don't like=0A=
middleboxes, something to thwart the lizard people, to impress Jodie Foster=
,=0A=
or what?=0A=
=0A=
Might I suggest that the IETF suspend any further push towards header=0A=
encryption until someone can figure out:=0A=
=0A=
a. Why we're doing this.=0A=
=0A=
b. What its intended goals and effects are.=0A=
=0A=
c. Whether those goals will be met in practice.=0A=
=0A=
d. Whether it will work when deployed in the real world.=0A=
=0A=
At the moment it looks like (a) is at best very unclear and (b), (c), and (=
d)=0A=
are pretty much nonexistent.=0A=
=0A=
Peter.=0A=


From nobody Wed Nov 20 19:54:58 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166F01209CF for ; Wed, 20 Nov 2019 19:54:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.642
X-Spam-Level: 
X-Spam-Status: No, score=-0.642 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, MALFORMED_FREEMAIL=1.355, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RK2SqZ4yPfZa for ; Wed, 20 Nov 2019 19:54:54 -0800 (PST)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 26B0A120988 for ; Wed, 20 Nov 2019 19:54:53 -0800 (PST)
Received: by mail-pl1-x636.google.com with SMTP id az9so892531plb.11 for ; Wed, 20 Nov 2019 19:54:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version; bh=9LEcgsQvr4qsyU4wPdLKfjN16IfLNkMoENmGRIYs3y8=; b=BfXa/C0mWAwGEP/WYMuJVZKjmGmDJb5SuEo2elzWX+YaiHav9DnAdyU/YABML/GNof UOvKlZIThxP7VaVU8kqh8/hFEl25Fi+We+zvvMrzlNG+5l1zDZNLeEn1Bk96/2q6dHi+ cK0BjscZyHacYpKsSEYvsXyMJTq0vPTxkhtx6bSPRC99QR20dqRTR9poghYvsGKrxf5j Su9katBAU5NlldXSUXEO62glrFjq5xmJHp/3PQs468Wn5BGkmGxlyHeCGuXotQOpvo3w B3bdJpAxXt+74j+mfjbBiWx7NvdoVZBBGotblfFsZWNSddNHU5qokzZ1XUq+xS5crhXB JAhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version; bh=9LEcgsQvr4qsyU4wPdLKfjN16IfLNkMoENmGRIYs3y8=; b=H48R+WyIDhXMX5xRNC/HZlDCYtPcJDoHpozks2QE9rkDjZSH8lWoL1tSdH0AuzWy/A ig1wLBSGxUoz3O5cjLTXHlARU7iXt8jKwQJ2Gn/iDPY/oVM9rWE1Q112e9YVPlyR+hje 6TIrtU1Eorfjgsz8SkxxxfAEY0a37OT0yWhYfjC3maritwL8RODL41j/LR9xAPcYZ9cI XGdViU7t6xPNZhestBjl/bAbHBSJWo63xkFqsg2VicLOsM+PbP9rcM6sJcYuvN8bwu91 Ic2v7qUtFEbNhVi5cTiaCblGF3r8lV8xvYsv4td2UvdRtbyZL2WtLYwHJwX55GKWKwvS GKdA==
X-Gm-Message-State: APjAAAXfakuVb7OYJIPrh2MOKedEkG2vYnhwhFFKk46bwtZ2VusKuwbV VoO7MbEB0WH/RIkCVJfLDaj95GkmgN4=
X-Google-Smtp-Source: APXvYqyVk6ULhTxwBrdbVvWzYANrOUfDEiANlXWhuRmGx7fykETQDDQtVAoYP9aGA8i7yuMGkp4S4Q==
X-Received: by 2002:a17:902:362:: with SMTP id 89mr6347202pld.71.1574308492425;  Wed, 20 Nov 2019 19:54:52 -0800 (PST)
Received: from [31.133.155.172] (dhcp-9bac.meeting.ietf.org. [31.133.155.172]) by smtp.gmail.com with ESMTPSA id r203sm937861pfr.184.2019.11.20.19.54.51 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Nov 2019 19:54:51 -0800 (PST)
User-Agent: Microsoft-MacOutlook/10.1f.0.191110
Date: Thu, 21 Nov 2019 11:54:50 +0800
From: Yaron Sheffer 
To: "saag@ietf.org" 
Message-ID: <9BBCC9EC-B95A-48E5-916F-6B8F695F5B60@gmail.com>
Thread-Topic: TxAuth BoF report
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3657182091_506932243"
Archived-At: 
Subject: [saag] TxAuth BoF report
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Nov 2019 03:54:56 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3657182091_506932243
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

TxAuth is a non-WG forming BoF that met on Monday. We discussed several iss=
ues with the OAuth 2.0 protocol, identified new use cases. Two proposals wer=
e presented: one to rework the underlying protocol, and a second to extend t=
he current protocol proposed solutions. We reached common understanding on t=
he problems, but we are still far from consensus on solutions. There was no =
consensus to pursue one solution, or another, or to pursue both.

=20

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Dick and Yaron


--B_3657182091_506932243
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


TxAuth is a=
 non-WG forming BoF that met on Monday. We discussed several issues with the=
 OAuth 2.0 protocol, identified new use cases. Two proposals were presented:=
 one to rework the underlying protocol, and a second to extend the current p=
rotocol proposed solutions. We reached common understanding on the problems,=
 but we are still far from consensus on solutions. There was no consensus to=
 pursue one solution, or another, or to pursue both.
 
=

Thanks,<=
/p>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 Dick and Yaron


--B_3657182091_506932243--



From nobody Wed Nov 20 20:55:31 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62FA12095C for ; Wed, 20 Nov 2019 20:55:29 -0800 (PST)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WroCJMvCAc9l for ; Wed, 20 Nov 2019 20:55:28 -0800 (PST)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 758E21200F1 for ; Wed, 20 Nov 2019 20:55:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1574312127; d=isode.com; s=june2016; i=@isode.com; bh=RGuDaSvrzIhYPDsP6JQPybmb6CUkHZrPxd2UJv1du5s=; 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=OuXBkvlfURU1zhOv2l4HpMRZ6zMF+yTZwbhbv8rj1Opc9PKetyT7rfrYrf+PsPM62NJXHX i8BiOlaIKqt6VFfXpMxwpZ6NpKkZXMvpwMrHqc/bf69xILhv0twtSsRJaoiSoGt9xUMfOb EwUO/2GX9SPfZjYKu7K6KzFyHpChfh8=;
Received: from [31.133.159.56] (dhcp-9f38.meeting.ietf.org [31.133.159.56])  by waldorf.isode.com (submission channel) via TCP with ESMTPSA  id ; Thu, 21 Nov 2019 04:55:27 +0000
From: Alexey Melnikov 
Message-Id: <186534BC-643C-4BF3-821F-68C1A37B557A@isode.com>
Date: Thu, 21 Nov 2019 12:55:25 +0800
To: saag@ietf.org
X-Mailer: iPad Mail (16G102)
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Archived-At: 
Subject: [saag] CFRG report
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Nov 2019 04:55:30 -0000

IRTF CFRG met yesterday for 1.5 hours.

We had an update on PAKE selection. The process is not complete, but based o=
n CFRG reviews and Crypto Panel review we narrowed down choices to  4 candid=
ates (2 augmented and 2 balanced) from the initial 8. The next phase of sele=
ction started with soliciting more questions from the CFRG mailing list. New=
 timeline was proposed that would last till Vancouver IETF in March 2020.

There were also updates on HPKE and hash-to-curve drafts, as well as a coupl=
e of invited presentations on AEADs.

Chairs also received lots of good nominations for Crypto Review Panel for th=
e following 2 years. Chairs have made the decision and will announce new mem=
bership next week.




From nobody Wed Nov 20 21:27:27 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30C8120818 for ; Wed, 20 Nov 2019 21:27:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level: 
X-Spam-Status: No, score=-4.298 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ltVgyjQaxo6 for ; Wed, 20 Nov 2019 21:27:24 -0800 (PST)
Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 387A7120143 for ; Wed, 20 Nov 2019 21:27:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574314043; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=NqUl2+GFqA2a4cn7H3uIH0OnbP0NB8dEwO+g905ZIEc=; b=BnHddMJmCUiih/WAP3I04iUOTXhVuVyK39gT8btFydXQN2wbCVcF0n4XsqT0LVLDeCATP7 JcLw3koam9x7DHDMWiLDCJB/k6Qj+AOcrcUdC2SOAhS6/VTgRXOu//RLP5tBV89REiG3Dt Mp/2WOH9/onJayWGRZUamV0QrU6YLpA=
Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-101-jiZGZ53xMkCsBLEI6zpGEA-1; Thu, 21 Nov 2019 00:27:20 -0500
Received: by mail-lf1-f71.google.com with SMTP id w1so558859lfc.8 for ; Wed, 20 Nov 2019 21:27:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=lpS2KHJhG5tK9fUYD2vKsCJbzJm8gPpxaqkfx3a2LI4=; b=f4sGwLvkjdwZJqSuAT7IL2fwrq8yWh3EJXMOGGHRiD/95nLU8ULeqx7YSXW9NeKVos Jo83aboe4XlpNnH6+NEeNuVWHlIubdnxmVBGgqMQja2fXqsr2i45OBY+GSPq/CaQg2v2 JRvTrcsGUE4NpfHVcQrwtLwHgc+Vmui1q+COD1ruSfisB6DfsqOTPBPRgEp3zt+h6YNJ LW6t53kxStojhqm0oZP22fkEgCn6txjmRzAyWpCQObqU1e9IZ44psrdW6RL5rjsX3odv LiSfOO7HVwGBCivzAWdnRWxuPVOcKlGHpVpLZEHQ31bJBEC8PLmZb1iG9DPw2ZEpQMcc kRrw==
X-Gm-Message-State: APjAAAXqsS20cFxjECJdstk4E6tZoD+0ZT5cs9nYdw1Vl+caOlPnLvTB LqDDAYWD64OXsultjKHoa/JHLi2Jfm8kNEWLR1+7Z0YtUWBTVqUtCHCp+3ceU8aBNOgLmghMoUh gbWJOlFET+09i0HgcvMn/
X-Received: by 2002:a2e:9d84:: with SMTP id c4mr5399286ljj.187.1574314039045;  Wed, 20 Nov 2019 21:27:19 -0800 (PST)
X-Google-Smtp-Source: APXvYqz72Am7hWbpOZ7icKTDrzAJWVjISfyOhkk5DNkIgRJdoSs2x1RrqEF8H3m87DqPbe/odazdvKJa5qVucS0jilI=
X-Received: by 2002:a2e:9d84:: with SMTP id c4mr5399279ljj.187.1574314038827;  Wed, 20 Nov 2019 21:27:18 -0800 (PST)
MIME-Version: 1.0
From: Paul Wouters 
Date: Thu, 21 Nov 2019 13:27:07 +0800
Message-ID: 
To: saag@ietf.org
X-MC-Unique: jiZGZ53xMkCsBLEI6zpGEA-1
X-Mimecast-Spam-Score: 0
Content-Type: multipart/alternative; boundary="0000000000000ccd400597d48d28"
Archived-At: 
Subject: [saag] TRANS report
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Nov 2019 05:27:26 -0000

--0000000000000ccd400597d48d28
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Trans did not meet.

The 6962bis document was updated two weeks ago and should address all open
DISCUSS items. But we have three IESG members that need to update/review
the changes and close their DISCUSS or re-raise an issue.

So we are (once again, still) hopeful that we can close the WG very soon.

https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-34


Paul & Melinda

--0000000000000ccd400597d48d28
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Trans did not meet.

The 6962bis document was updated two weeks ago and should address al=
l open DISCUSS items. But we have three IESG members that need to update/re=
view the changes and close their DISCUSS or re-raise an issue.
So we are (once again, still) hopeful that we can close the WG=
 very soon.



Paul & M=
elinda


--0000000000000ccd400597d48d28--


From nobody Wed Nov 20 21:29:51 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867BD120143 for ; Wed, 20 Nov 2019 21:29:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.419
X-Spam-Level: 
X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvpWbcucMB_V for ; Wed, 20 Nov 2019 21:29:43 -0800 (PST)
Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62AB2120971 for ; Wed, 20 Nov 2019 21:29:43 -0800 (PST)
Received: by fireball.acr.fi (Postfix, from userid 15204) id 8D93C25C1226; Thu, 21 Nov 2019 07:29:40 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <24022.8388.525363.486253@fireball.acr.fi>
Date: Thu, 21 Nov 2019 07:29:40 +0200
From: Tero Kivinen 
To: saag@ietf.org
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 1 min
X-Total-Time: 1 min
Archived-At: 
Subject: [saag] IPsecME status
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Nov 2019 05:29:47 -0000

IPsecME will be meeting just after saag, but here is the status update
posted to the datatracker:

----------------------------------------------------------------------
Split DNS was published as RFC8598. Implicit IV is now in the RFC
editor queue. Publication requested has been issued for Quantum
resistance draft. We have finished last call for IPv6 and IPv4 status
codes, and it should be ready for publication now.

For the existing work items, the IKEv2 intermediate should be ready
for WGLC soon, and the labeled IPsec has had some back and forth
design choices.

We have adopted hybrid QSKE, and G-DOI IKev2 drafts, and we also
already adopted IP traffic flow security draft, even when it is
waiting for charter update.

IKE1 IPsec graveyard draft is not yet adopted, but should be ready for
adoption call, after it is updated to include instructions for IANA to
mark all IKEv1 related registries as closed.

Clarifications and Implementation guidelines for using TCP
encapsulation in IKEv2 is waiting for the charter update before it is
adopted as WG document.
-- 
kivinen@iki.fi


From nobody Wed Nov 20 21:32:16 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B72120971 for ; Wed, 20 Nov 2019 21:32:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=RIZw2a2T; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HBwtUxmP
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 YSd4vyVaHq-n for ; Wed, 20 Nov 2019 21:32:12 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A41D3120143 for ; Wed, 20 Nov 2019 21:32:12 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id BF1A6220BD for ; Thu, 21 Nov 2019 00:32:11 -0500 (EST)
Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Thu, 21 Nov 2019 00:32:11 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm2; bh=Mc67T8dNNTdugovpYQVLP6bKBPteuslcYq4BcAUke+8=; b=RIZw2a2T PwUioeWET0edYmJXsiAbyhk1swHrBCZEDhM9IU/0Ew8F6ZU4EMMrvwhukly9IDE+ aYAWwjEhjHiIftNbwC0ScUHmNvVzX1zcFewchCWkzy1q7bc3K+D8FMHGtX4W8+ft OhVrq5j2NpJSAtKGVLBcpg220LPY9CHAyMtJbhj5XQs1JXYowAWNgqwGCuutv86s VH4cJldcbE+GN4Zl/Cs5x6nXajgVydqvMpT8rGei5GkfGDK88x8Jj13UQzjUrfnC IqsMS6jJqmgmptN+BA6+M83rKisu2Qyq6Hu7B7BXJ6mtVvD39FREe20u0iJZJPJd B6YC9fw2Og4CUw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=Mc67T8dNNTdugovpYQVLP6bKBPteu slcYq4BcAUke+8=; b=HBwtUxmP433yu2b2lr+TpSpkw5TY1OJg24ivuTqCg3tnT u4Vzs1YxFESEK52+8MqO0vgGeDFwjwkuwaiQ07Lp/izyXeoL6OcR9Lv09m7M+vvC 1t70js6EcsDt5f7bHI+4pqI5ZuMOQpH2l1IslrxmSuy13eQRVmSOwLqW3m+zeiDt /k1jyiOXxJ354mswrz4MqaRKEv/UAvKEVmCC4Is4MNhb6uL7/dP+5zLrLvua+fob OCsTJ1taec+8rdiurGSWpvJELBmCMSGCGdWBH4iLVpiS2vrgsnlBLvokZpSlFCWe Vt+bhH2hbGrf/XoEWXYnjgrKekiNlWLScU1hKQ4Bg==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehuddgkeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsehttdertd erredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgifsehh vggrphhinhhgsghithhsrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomheptggrfi eshhgvrghpihhnghgsihhtshdrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6EA383C00A1; Thu, 21 Nov 2019 00:32:11 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1
Mime-Version: 1.0
Message-Id: 
Date: Thu, 21 Nov 2019 13:31:51 +0800
From: "Christopher Wood" 
To: saag@ietf.org
Content-Type: text/plain
Archived-At: 
Subject: [saag] TLS report
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Nov 2019 05:32:15 -0000

TLS met Thursday morning and will meet again Thursday afternoon. 

TLS External PSK was discussed. There was agreement to revise the document and move forward with a few minor revisions.  The WG will also start a design team to document and clarify external PSK usage and more sophisticated mitigations for Selfie-style attacks. Final updates to the Exported Authenticators draft were presented based on last call comments. An existing PR to clarify comments exists yet did not have consensus in the room. Discussion on the list will continue. Changes to the Delegated Credentials (DC) draft were presented. The WG seems to be in favor of adding a signature algorithms list to the DC extension citing possible benefits for semi-static DH as a use case. 

The WG received new work on an extended key schedule for TLS 1.3 to support better security and consistency for additional use cases such as Hybrid Key Exchange, ESNI, External PSK, and Semi-Static DH. The design injects secret into key schedule in a predictable and composable way. There will be more discussion on the list. Compact TLS (cTLS) was presented. The design introduces a variety of changes (removal of legacy fields, variable-length encoding, pre-defined extensions) that aim to help better use TLS in other contexts, such as QUIC, LAKE, and EAP.  Strong support in the room to adopt this in the working group pending rechartering.  A proposal on a 1-RTT Semi-Static DH handshake mode was presented.  There was support to adopt this draft as a WG item. The WG will confirm on the list. A new proposal for batch signing was presented.  There was support to adopt this draft as a WG item. The WG will confirm on the list.

The afternoon TLS session will cover Encrypted SNI and the ongoing work to deprecate MD5+SHA1 signature hash algorithms. 

Best,
Chris


From nobody Wed Nov 20 21:49:46 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAA41200FB for ; Wed, 20 Nov 2019 21:49:44 -0800 (PST)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eDkfOj0fR9U for ; Wed, 20 Nov 2019 21:49:43 -0800 (PST)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 10CDF12009C for ; Wed, 20 Nov 2019 21:49:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 6638E62113 for ; Thu, 21 Nov 2019 00:49:42 -0500 (EST)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vVavKAiGNahZ for ; Thu, 21 Nov 2019 00:49:35 -0500 (EST)
Received: from lx140e.htt-consult.com (dhcp-9f34.meeting.ietf.org [31.133.159.52]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id E1399620D4 for ; Thu, 21 Nov 2019 00:49:33 -0500 (EST)
To: saag@ietf.org
From: Robert Moskowitz 
Message-ID: <79b96b82-b1b9-7121-5304-757a5fd42af0@htt-consult.com>
Date: Thu, 21 Nov 2019 13:49:27 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: [saag] TMRID and hashes of prior messages in the Auth message
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Nov 2019 05:49:44 -0000

First to the SAAG list, the TMRID BOF covered the work todate on 
RemoteID for Unmanned Aircraft Systems and this is expected to be 
chartered as a working group.

I direct people's attention to:

draft-wiethuechter-tmrid-auth

The purpose of the auth message in the ASTM standard is to authenticate 
prior sent really short messages.  But the ASTM standard really does not 
say how to do this.

In the above draft we are proposing to hash those messages, put those 
hashes in the digitally signed Auth message.

This is an interesting problem and we make no claim that we got it well 
in hand and request review and comment by others.

Please read the draft (and others for TMRID) and address the tmrid list 
or me or Adam directly.

Thank you

Robert Moskowitz


From nobody Fri Nov 22 08:31:57 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A391208C5 for ; Fri, 22 Nov 2019 08:31:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com header.b=HtQtHh2D; dkim=pass (1024-bit key) header.d=digicert.com header.b=KOoqkK1o
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 lpvWH5ktD5FD for ; Fri, 22 Nov 2019 08:31:53 -0800 (PST)
Received: from us-smtp-delivery-173.mimecast.com (us-smtp-delivery-173.mimecast.com [216.205.24.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBC4E1208D7 for ; Fri, 22 Nov 2019 08:31:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1574440311; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=znA1fTUZITX4C/KG7vs65+mQv8XsaF3MlE/0cxSv1SM=; b=HtQtHh2DpvhQSD21pef36hp6i4bh8Y2rCcib2hrP1X7M3h+CnNVGH7c8qQmpW73dDPOSVv 8CjpL0CofIoM2yrLAq6PJMbmUcoQQtRw929J5yJwymK0WYM2BCjIj8px8Uue7RnZ++N2Z5 J2N7nEO4fSWYJGYkQKypy8JTL/VQsZ0=
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2052.outbound.protection.outlook.com [104.47.36.52]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-67-EdmRzlpVOkSXJ2cDS3ru5A-1; Fri, 22 Nov 2019 11:31:49 -0500
X-MC-Unique: EdmRzlpVOkSXJ2cDS3ru5A-1
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ha9X3bLHhMnbKm3jBd0AKEeMV1LKAF8ZksBEkVbXj3iHf2sqdgZV3uscyXqZ+Dbk/rSTN46en+Ttphh6b/868CgoHJnUh1PrX3/GibM1cDeQOL2qPM1pqqo04lIohSiAvRISxr0sd4ogJc7qrE8q5Yl3j5NJXaBXWZN+fv2fy1hZQGuipkIC9Mfho42kP57DNST6VT18Y4YmqSWybBkKNc5AtZTQiG2OrzkCSdmKTPMVV/9TGVTcZCNNATa50be1BRZIOjTrZOIyA5ilw+gcj6rqmV8CXu/4D3/O5VJjD9TsXYovnMOKvzT4wXZR5WvM6JwZNo9QTCpgNnKTO8Fvvg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=znA1fTUZITX4C/KG7vs65+mQv8XsaF3MlE/0cxSv1SM=; b=dDJ2DM85YPTCrYPIoigqOMwnfJvwpE5fnNI1XqVPFeh/rzjVj5aHvO1VIHnB9hORHMe5MTpAPLoiLToAUqn4phx7A+SQMOmdjHsg35OtDsY9vd8HQskdnOHLlgv1w/72phGDdLSHsYSXKAl+MPVTjVuX6+lQ0BkPyqjHbXtSRiiDEdFUBfum81UgHadShws3HsUDtKvoa/uxqdyq5x+sqR70V3YwxeleDCWieAou7otTjGEFl6Runwfg/Tv0phK+zPJjlcnqZYSsw52Ue93261x4vggFQSL408nrnB5qJkyBEGPXZgR+OpN/usI2CEuVkLVFKncvUzwfgpXqvHqYKw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=digicert.com; dmarc=pass action=none header.from=digicert.com; dkim=pass header.d=digicert.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=znA1fTUZITX4C/KG7vs65+mQv8XsaF3MlE/0cxSv1SM=; b=KOoqkK1ozBkNNhkmVaphR0Pskl/ttDl6q81xpk9bUEwzB/n6CZbDQk+E9ZKqrPUHd1uUWxaPNPpv1Ox8Dkrjp6BDJqqGHPJwlqgv+j9TrFix/oyacNAAfhvsWF+E9F0ndJzbSRNbf1HRgPKTRUdrjDjTD/n1A0QVuTJAaGVRlu4=
Received: from CH2PR14MB3644.namprd14.prod.outlook.com (10.186.137.20) by CH2PR14MB3926.namprd14.prod.outlook.com (20.180.16.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.19; Fri, 22 Nov 2019 16:31:47 +0000
Received: from CH2PR14MB3644.namprd14.prod.outlook.com ([fe80::f4a8:8f67:3f90:2736]) by CH2PR14MB3644.namprd14.prod.outlook.com ([fe80::f4a8:8f67:3f90:2736%4]) with mapi id 15.20.2474.019; Fri, 22 Nov 2019 16:31:47 +0000
From: Tim Hollebeek 
To: saag 
Thread-Topic: LAMPS report
Thread-Index: AdWhUXSvM5ZoZN7vQ0ez1YVOwHYVRw==
Date: Fri, 22 Nov 2019 16:31:47 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=tim.hollebeek@digicert.com; 
x-originating-ip: [98.111.253.32]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 56b7d303-e696-438d-7120-08d76f697849
x-ms-traffictypediagnostic: CH2PR14MB3926:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 02296943FF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(396003)(136003)(346002)(366004)(189003)(199004)(6116002)(66556008)(26005)(14444005)(102836004)(66446008)(7736002)(256004)(6506007)(2906002)(44832011)(4744005)(74316002)(5660300002)(66946007)(76116006)(7696005)(66616009)(66066001)(99286004)(64756008)(186003)(52536014)(86362001)(66476007)(316002)(221733001)(8936002)(54896002)(8676002)(81166006)(3480700005)(6306002)(55016002)(478600001)(9686003)(81156014)(7116003)(14454004)(790700001)(71190400001)(71200400001)(6916009)(6436002)(3846002)(25786009)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CH2PR14MB3926; H:CH2PR14MB3644.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: bQdM7KxWDcySlo413xMcwr0DdhQN76P7bLQSWDR6+nKnWRP1LSyCl22oK87jQmMBhzufxeq66NLfxBQwgXd0SCfODwzRXlzkWvQcHmNGD0RUNGFwT37uBYo3tdbjK2HjEMJfEdg+T7Rcys0xeFBh9U338xcDm3CI267USz6OmmHCU3wv8UdS8R2e/Ezo7IhgvFJWkHNUyP/lGhW8oStcjvkc1FyUyf+MNHo2HknM577Cm3laaqL/3HulAtfY0NTUw2VwiURVHj3sAysU54P7ZWImZHV7RWYFQA2NcaB4bvPnZ6XVoowoc3EVmg++JFsocO3Zr9GwIqYHAUiSkyy15z3pGqIi91CgnEZWg9cLbyyUUz4H64v9z+N2KHBfFuW/3Fqiz0K6GZBa2sDoqK7L0YPZsNZmU06c455lyrr4Cqag9OSLFFb4LIeiu633Fpjv
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0599_01D5A128.69DF66F0"
MIME-Version: 1.0
X-OriginatorOrg: digicert.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 56b7d303-e696-438d-7120-08d76f697849
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2019 16:31:47.4810 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ztkMbDzrBvB3r0EyuS+qbhA8B5ZczAgaLtYsmgOCZGEgLdRNbd2IvWRgFO4fPac1qQw7pnblXjbFaj+WJa1vzigbmKoHheN5TUGetlS1cTE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR14MB3926
Archived-At: 
Subject: [saag] LAMPS report
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Nov 2019 16:31:56 -0000

------=_NextPart_000_0599_01D5A128.69DF66F0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_059A_01D5A128.69DF8E00"


------=_NextPart_001_059A_01D5A128.69DF8E00
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

 

LAMPS met Monday morning.

 

Most of the discussion was about continuing work on the header protection
work for S/MIME emails.  Backwards compatibility with clients which do not
understand the new header protection methods are the biggest concern.  There
is a need for more testing with existing legacy clients to determine exactly
how they behave.  If people could assist with testing various clients and
posting screenshots to the list, that would be helpful.

 

The CMP profile was also discussed and the changes since the initial draft
were presented.  Additional work on the ANS.1 modules is still necessary,
and the document needs to be polished.

 

Sean Turner and Michael Richardson also have two documents they would like
adopted, but those are waiting for a pending recharter.

 

-Tim

 


------=_NextPart_001_059A_01D5A128.69DF8E00
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
LAMPS met =
Monday morning.
 
Most of the =
discussion was about continuing work on the header protection work for =
S/MIME emails.  Backwards compatibility with clients which do not =
understand the new header protection methods are the biggest =
concern.  There is a need for more testing with existing legacy =
clients to determine exactly how they behave.  If people could =
assist with testing various clients and posting screenshots to the list, =
that would be helpful.
 
The CMP =
profile was also discussed and the changes since the initial draft were =
presented.  Additional work on the ANS.1 modules is still =
necessary, and the document needs to be polished.
 
Sean Turner =
and Michael Richardson also have two documents they would like adopted, =
but those are waiting for a pending recharter.
 
-Tim
 

------=_NextPart_001_059A_01D5A128.69DF8E00--

------=_NextPart_000_0599_01D5A128.69DF66F0
Content-Type: application/pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw
ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi
BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx
MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT
EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71
IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS
Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+
WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh
5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y
d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr
oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG
SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS
TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ
s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx
vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76
jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ
Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM
RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy
dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw
CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl
cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw
05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW
sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF
YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP
QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn
AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T
AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E
BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9
bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E
gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ
RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz
c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw
LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp
Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k
76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX
mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP
KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx
e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5
oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN
AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz
MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD
ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB
MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A
J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+
yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo
8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh
rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy
czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV
HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp
Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp
Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E
aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME
MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6
Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA
ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0
AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA
ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh
AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA
YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg
AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP
2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN
AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ
pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI
EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB
VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG
QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j
b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes
EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMTkxMTIyMTYzMTQyWjAvBgkqhkiG9w0BCQQxIgQgwtG8JJutDdZF644NBi+yVx3r9sj1
XYNr3o58YfDj9pUwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp
Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg
U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw
ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj
ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth
tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq
hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG
SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA
BIIBAKFjXulza1ESrHIBsOgHJGQZZWX5YXK7xoqegjvcrhkGvvOq5XmHhDyfTsfNcwAQDvJ8z9PL
d5WAWyey0LAFRXoHkWcTN9h80SNACucpD6l6loMrj/PJXvyAwR2Qmhjkh/jqgjZeVa6fh9skpMK4
HG8GiXpwa2vZ335TgkOz/CSLorn51wqcHLJkIttpaUsd8T1gSFN/EFVI8eDuq+EknxTdceswIAQ9
zRWY8VB5N74xBEubbCgvJZGEzPxSEIMz+hvJy72ZnzjveZzPexeIeU+8nnYYNuDjMQTYUJvhnn4M
dv+nr9z/lcUwLpZieNmWylk/pknLR4bJnyP6IzwdqIkAAAAAAAA=

------=_NextPart_000_0599_01D5A128.69DF66F0--


From nobody Sat Nov 23 17:48:50 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E60120045 for ; Sat, 23 Nov 2019 17:48:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level: 
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGrJoEtdLR-O for ; Sat, 23 Nov 2019 17:48:32 -0800 (PST)
Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 CE5FD120073 for ; Sat, 23 Nov 2019 17:48:31 -0800 (PST)
Received: by mail-vs1-xe2f.google.com with SMTP id i13so2720461vso.13 for ; Sat, 23 Nov 2019 17:48:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bOR6UovPst7G2nTFYlF/FvrqxJCHgfoBtmK4NOKgzWs=; b=NHDNX6FNyzF87nn6YywhLlL+2VWrvb3IUG6HYll4JvSwLQcYKg0d2NT2knmwqP34UT P3DoGvFTfWQLwmNYP80G9Qyqq2gIHC/72NfrwzDXZoOfFRagqqStp/HWWi6UwOVVc5Ld 0UElOEIz4XPjpuGRl+8M65hW+bp/hPJSy3ALLUhEfba9ueSM/08m7hAtsf1/SHHo9Ej7 sJ3tk4HxIrE1nAI+1CFzsM4/as3sZrpn7K9F/Jfmx5P/3I5tk2oLlRCOUPgAYW6/bB1B PnQ1m8/Ltc/3uhvcUfvPdtT2uxAJp1RKodFGJ9P8J16471mxw+feFwNgql03u40GXVOO tRPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bOR6UovPst7G2nTFYlF/FvrqxJCHgfoBtmK4NOKgzWs=; b=h2ONH4V7CDwR6vXCU+WHdOBB5NGnb0pwsd0LUR4I9jMkgUcvgWnMgKdxPDXVeOrC3h f7JIy5fY3o+RsUJvpljN82dPxLyVkK5inACK+cXkm2SpRrAk9zTeaw3V9fRDiHFpPzBk tmhNS8qOcgGYHDlkVbIlzwwOrnUQPGCUqkfqF+kri1shEml1291LLKsdz6bDmJx3fQGT yT5ARF8gdn07gMXNoGmVx5V/LLcC6eOFmNFKZ+G9oxoxfDmW/X+ukdrFHGR3KDTv5K3r v8/5liP3FG+jd87DFBEHlw5TU+7zvLxBt8GG019KegMdzumwzpaaQZpCpfvz3cKx4UpA wFzg==
X-Gm-Message-State: APjAAAXd9T7Y7dkiRoSgYMEQo7Kf3dSP1xQoGPoRa1UKDbvYxkKAIocV ZXhwG1wTmD2GeLcbNSRHQ278tqKzzHCvqfqkZBIhPA==
X-Google-Smtp-Source: APXvYqxvLW0PLf/sKrZNLuLeJU/D8CBoPmVlWHCNElECLku/2qKzAyRXjmPFGjZwxfEFny9bI0gOaXMl/skruv93KmI=
X-Received: by 2002:a67:e417:: with SMTP id d23mr4093118vsf.208.1574560109944;  Sat, 23 Nov 2019 17:48:29 -0800 (PST)
MIME-Version: 1.0
References:  <4460_1571933453_5DB1CD0D_4460_57_4_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931F030A0@OPEXCAUBM44.corporate.adroot.infra.ftgroup> <1572918247420.10381@cs.auckland.ac.nz>   <5df30dd2-6841-7140-43bf-8c1b9603653f@erg.abdn.ac.uk>
In-Reply-To: <5df30dd2-6841-7140-43bf-8c1b9603653f@erg.abdn.ac.uk>
From: Ian Swett 
Date: Sat, 23 Nov 2019 20:48:17 -0500
Message-ID: 
To: Gorry Fairhurst 
Cc: "Joel M. Halpern" , Peter Gutmann ,  "tsvwg@ietf.org" , "IETF IPPM WG (ippm@ietf.org)" , tsvwg-chairs ,  "opsawg@ietf.org" , "quic@ietf.org" , "saag@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000008409405980dd87a"
Archived-At: 
Subject: Re: [saag] [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Nov 2019 01:48:35 -0000

--00000000000008409405980dd87a
Content-Type: text/plain; charset="UTF-8"

I think it's ok to publish a document with the stated goals, but I think
this needs to be done with great care and the current document implies some
value judgements and implications I don't think are fully justified by the
document.  A 3rd author with a slightly different perspective may help
achieve the right balance.

In section 2, I believe you should note that the reason transport headers
have been exposed in the past is largely an accident, and what is exposed
may not be optimal for network monitoring and management purposes.  For
example, TCPs ACKs are a suboptimal way to measure network RTT unless
timestamps are available. And tracking losses requires substantial state
and assumptions about the loss detection algorithm on the part of the
observer.

The section(2.1) on transport ossification and middleboxes is well done,
thanks!


*Detailed points: *

2: Context and Rationale
 "To achieve stable Internet operations, the IETF transport community
   has to date relied heavily on the results of measurements and the
   insights of the network operations.."

The use of 'stable' here implies that without these measurements the
internet would be unstable.  I understand what you're trying to say, but
this needs a reword to avoid the implied collapse of the internet.  I'd
suggest you remove the word stable from this document, as it occurs 2 other
times in similar context.

2.3

I think this section is too vague.  The phrase "can be used" is used
frequently, but without a clear understanding of what the transport headers
are used for.  After reading further, some of this is defined in section
3.1.2, so maybe a forward reference is in order.

3.1.2:

"Throughput and Goodput" - Throughput seems to overlap with "Traffic Rate
and Volume".   I'd suggest reorganizing these into two items, one for
Goodput and one for Throughput/Traffic Rate/etc.

6.5:

"Concealing transport header..." Do you mean encrypting, or is there some
other method you have in mind?  This word is used 9 times in the document
and I don't think it's a good word choice.

7:

 "To achieve stable Internet operations, the IETF transport community
   has, to date, relied heavily on measurement and insights of the
   network operations community to understand the trade-offs, and to
   inform selection of appropriate mechanisms, to ensure a safe,
   reliable, and robust Internet (e.g., [RFC1273],[RFC2914])."

I don't believe RFC2914 should be grouped with RFC1273.  2914 is about
principles, and 1273 is about measurement.  Based on my reading, 2914 does
not provide evidence that measurement is necessary in order to achieve the
desired principles.

Also, one of these RFCs is almost 20 years old and the other is almost 30.
I don't think these are good support for the thesis that network operators
measurement abilities have been critical to what you're claiming, even if
it is still true today.

Thanks, Ian


On Tue, Nov 5, 2019 at 5:27 AM Gorry Fairhurst  wrote:

> Thanks for the various comments on process.
>
> I expect both editors and the Chairs to work with our AD to confirm the
> intended scope, and then to decide on the next steps. This author wants
> to clarify how IETF transport protocols have been designed and have
> been/are being used.
>
> Gorry (as one of the editors of this document).
>
>
> On 05/11/2019 02:39, Joel M. Halpern wrote:
> > If the authors want to publish it as an RFC so as to comment on other
> > RFCs, they could approach the Independent Stream Editor.  That sort of
> > publication is one of the explicit purposes of the Independent Stream.
> >
> > Yours,
> > Joel
> >
> > On 11/4/2019 9:34 PM, Eric Rescorla wrote:
> >>
> >>
> >> On Mon, Nov 4, 2019 at 5:44 PM Peter Gutmann
> >> > wrote:
> >>
> >>     I actually think it's a pretty good summary, and delivers exactly
> >> what's
> >>     promised in the title.  OTOH I can also see that it's going to get
> >>     bikeshedded
> >>     to death, and will probably never be editable into a form where
> >>     people won't
> >>     complain about it no matter how many changes are made.
> >> Alternatively, it'll
> >>     end up watered down to a point where no-one can complain any more
> >>     but it won't
> >>     say anything terribly useful by then.
> >>
> >>     Perhaps it could be published as is with a comment that it
> >>     represents the
> >>     opinions of the authors?  Although given that it's Informational
> >> and not
> >>     Standards-track or a BCP, that should be a given anyway.
> >>
> >>
> >> Actually, no. Most IETF documents, even informational ones, bear a
> >> statement that they have IETF Consensus.
> >>
> >> See: https://tools.ietf.org/html/rfc5741#section-3.2.1
> >> 
> >>
> >> -Ekr
> >>
> >>
> >>     Peter.
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> OPSAWG mailing list
> >> OPSAWG@ietf.org
> >> https://www.ietf.org/mailman/listinfo/opsawg
> >>
>
>

--00000000000008409405980dd87a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I think it's ok to publish a document with the st=
ated goals, but I think this needs to be done with great care and the curre=
nt document implies some value judgements and implications I don't thin=
k are fully justified by the document.=C2=A0 A 3rd author with a slightly d=
ifferent perspective may help achieve the right balance.

In section 2, I believe you should note that the reason transport he=
aders have been exposed in the past is largely an accident, and what is exp=
osed may not be optimal for network monitoring and management purposes.=C2=
=A0 For example, TCPs ACKs are a suboptimal way to measure network RTT unle=
ss timestamps are available. And tracking losses requires substantial state=
 and assumptions about the loss detection algorithm on the part of the obse=
rver.

The section(2.1) on transport ossif=
ication and middleboxes is well done, thanks!


Detailed points:=C2=A0=C2=A0
<=
div>
2: Context and Rationale
=C2=A0"To achiev=
e stable Internet operations, the IETF transport community
=C2=A0 =C2=
=A0has to date relied heavily on the results of measurements and the
=C2=
=A0 =C2=A0insights of the network operations.."

The=
 use of 'stable' here implies that without these measurements the i=
nternet would be unstable.=C2=A0 I understand what you're trying to say=
, but this needs a reword to avoid the implied collapse of the internet.=C2=
=A0 I'd suggest you remove the word stable from this document, as it oc=
curs 2 other times in similar context.

2.3

I think this section is too vague.=C2=A0 The phrase=
 "can be used" is used frequently, but without a clear understand=
ing of what the transport headers are used for.=C2=A0 After reading further=
, some of this is defined in section 3.1.2, so maybe a forward reference is=
 in order.

3.1.2:

"T=
hroughput and Goodput" - Throughput seems to overlap with "Traffi=
c Rate and Volume".=C2=A0 =C2=A0I'd suggest reorganizing these int=
o two items, one for Goodput and one for Throughput/Traffic Rate/etc.
=


6.5:

"Concealing transpor=
t header..." Do you mean encrypting, or is there some other method you=
 have in mind?=C2=A0 This word is used 9 times in the document and I don=
9;t think it's a good word choice.

7:

=C2=A0"To achieve stable Internet operations, the IET=
F transport community
=C2=A0 =C2=A0has, to date, relied heavily on measu=
rement and insights of the
=C2=A0 =C2=A0network operations community to =
understand the trade-offs, and to
=C2=A0 =C2=A0inform selection of appro=
priate mechanisms, to ensure a safe,
=C2=A0 =C2=A0reliable, and robust I=
nternet (e.g., [RFC1273],[RFC2914])."

I d=
on't believe RFC2914 should be grouped with RFC1273.=C2=A0 2914 is abou=
t principles, and 1273 is about measurement.=C2=A0 Based on my reading, 291=
4 does not provide evidence that measurement is necessary in order to achie=
ve=C2=A0the desired principles.

Also, one of these=
 RFCs is almost 20 years old and the other is almost 30.=C2=A0 I don't =
think these are good support for the thesis that network operators measurem=
ent abilities have been critical to what you're claiming, even if it is=
 still true today.

Thanks, Ian


On Tue, Nov 5, 2019 at 5:27 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
<=
/div>
Thanks for the vario=
us comments on process.



I expect both editors and the Chairs to work with our AD to confirm the 
intended scope, and then to decide on the next steps. This author wants 
to clarify how IETF transport protocols have been designed and have 

been/are being used.



Gorry (as one of the editors of this document).





On 05/11/2019 02:39, Joel M. Halpern wrote:

> If the authors want to publish it as an RFC so as to comment on other =


> RFCs, they could approach the Independent Stream Editor.=C2=A0 That so=
rt of 

> publication is one of the explicit purposes of the Independent Stream.=


>

> Yours,

> Joel

>

> On 11/4/2019 9:34 PM, Eric Rescorla wrote:

>>

>>

>> On Mon, Nov 4, 2019 at 5:44 PM Peter Gutmann 

>> <pgut001@cs.auckland.ac.nz <mailto:pgut001@cs.auckland.ac.nz>> wrote:<=
br>
>>

>> =C2=A0=C2=A0=C2=A0 I actually think it's a pretty good summary=
, and delivers exactly 

>> what's

>> =C2=A0=C2=A0=C2=A0 promised in the title.=C2=A0 OTOH I can also se=
e that it's going to get

>> =C2=A0=C2=A0=C2=A0 bikeshedded

>> =C2=A0=C2=A0=C2=A0 to death, and will probably never be editable i=
nto a form where

>> =C2=A0=C2=A0=C2=A0 people won't

>> =C2=A0=C2=A0=C2=A0 complain about it no matter how many changes ar=
e made. 

>> Alternatively, it'll

>> =C2=A0=C2=A0=C2=A0 end up watered down to a point where no-one can=
 complain any more

>> =C2=A0=C2=A0=C2=A0 but it won't

>> =C2=A0=C2=A0=C2=A0 say anything terribly useful by then.

>>

>> =C2=A0=C2=A0=C2=A0 Perhaps it could be published as is with a comm=
ent that it

>> =C2=A0=C2=A0=C2=A0 represents the

>> =C2=A0=C2=A0=C2=A0 opinions of the authors?=C2=A0 Although given t=
hat it's Informational 

>> and not

>> =C2=A0=C2=A0=C2=A0 Standards-track or a BCP, that should be a give=
n anyway.

>>

>>

>> Actually, no. Most IETF documents, even informational ones, bear a=
 

>> statement that they have IETF Consensus.

>>

>> See: https://tools.ietf.org/html/rfc5741#s=
ection-3.2.1 

>> <https://tools.ietf.org/html/rfc5741#s=
ection-3..2.1>

>>

>> -Ekr

>>

>>

>> =C2=A0=C2=A0=C2=A0 Peter.

>>

>>

>>

>>

>> _______________________________________________

>> OPSAWG mailing list

>> OPSAWG@ietf.o=
rg

>> https://www.ietf.org/mailman/listinfo/opsawg

>>






--00000000000008409405980dd87a--


From nobody Sun Nov 24 10:46:18 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1521200B3; Sun, 24 Nov 2019 04:52:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.498
X-Spam-Level: 
X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQ66iKY9Xi9z; Sun, 24 Nov 2019 04:52:42 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 E456D120137; Sun, 24 Nov 2019 04:52:41 -0800 (PST)
Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id xAOCZAbU014999; Sun, 24 Nov 2019 07:52:23 -0500
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049463.ppops.net-00191d01. with ESMTP id 2wf219pdhm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 24 Nov 2019 07:52:22 -0500
Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id xAOCqLuW031242; Sun, 24 Nov 2019 06:52:21 -0600
Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [135.46.181.159]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id xAOCqFRF031135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 24 Nov 2019 06:52:15 -0600
Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [127.0.0.1]) by zlp30494.vci.att.com (Service) with ESMTP id 3A2EE4009E7D; Sun, 24 Nov 2019 12:52:15 +0000 (GMT)
Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30494.vci.att.com (Service) with ESMTP id 1452B4009E71; Sun, 24 Nov 2019 12:52:15 +0000 (GMT)
Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id xAOCqEbV011077; Sun, 24 Nov 2019 06:52:14 -0600
Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id xAOCq4FO010213; Sun, 24 Nov 2019 06:52:05 -0600
Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-azure.research.att.com (Postfix) with ESMTP id 24548E12A2; Sun, 24 Nov 2019 07:50:53 -0500 (EST)
Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0468.000; Sun, 24 Nov 2019 07:52:03 -0500
From: "MORTON, ALFRED C (AL)" 
To: Ian Swett , Gorry Fairhurst 
CC: "quic@ietf.org" , "tsvwg@ietf.org" , "IETF IPPM WG (ippm@ietf.org)" , Peter Gutmann , tsvwg-chairs , "opsawg@ietf.org" , "Joel M. Halpern" , "saag@ietf.org" 
Thread-Topic: [ippm] [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
Thread-Index: AQHVk8OXusCW74gvz0mDwZDg62wUHaeZ/saAgABcwdA=
Date: Sun, 24 Nov 2019 12:52:03 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CFA6F001FB@njmtexg5.research.att.com>
References:  <4460_1571933453_5DB1CD0D_4460_57_4_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931F030A0@OPEXCAUBM44.corporate.adroot.infra.ftgroup> <1572918247420.10381@cs.auckland.ac.nz>   <5df30dd2-6841-7140-43bf-8c1b9603653f@erg.abdn.ac.uk> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [69.141.203.172]
Content-Type: multipart/alternative; boundary="_000_4D7F4AD313D3FC43A053B309F97543CFA6F001FBnjmtexg5researc_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-23_06:2019-11-21,2019-11-23 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 phishscore=0 malwarescore=0 spamscore=0 bulkscore=0 impostorscore=0 priorityscore=1501 adultscore=0 mlxscore=0 clxscore=1011 mlxlogscore=999 suspectscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911240126
Archived-At: 
X-Mailman-Approved-At: Sun, 24 Nov 2019 10:46:16 -0800
Subject: Re: [saag] [ippm] [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Nov 2019 12:52:44 -0000

--_000_4D7F4AD313D3FC43A053B309F97543CFA6F001FBnjmtexg5researc_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgSWFuLCBHb3JyeSBhbmQgQ29saW4sDQoNCnBsZWFzZSBzZWUgYSBmZXcgaGFyZC1lYXJuZWQg
Y29tbWVudHMgYmVsb3csIG1hcmtlZCBbYWNtXSwNCg0KQWwNCg0KRnJvbTogaXBwbSBbbWFpbHRv
OmlwcG0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElhbiBTd2V0dA0KU2VudDogU2F0
dXJkYXksIE5vdmVtYmVyIDIzLCAyMDE5IDg6NDggUE0NClRvOiBHb3JyeSBGYWlyaHVyc3QgPGdv
cnJ5QGVyZy5hYmRuLmFjLnVrPg0KQ2M6IHF1aWNAaWV0Zi5vcmc7IHRzdndnQGlldGYub3JnOyBJ
RVRGIElQUE0gV0cgKGlwcG1AaWV0Zi5vcmcpIDxpcHBtQGlldGYub3JnPjsgUGV0ZXIgR3V0bWFu
biA8cGd1dDAwMUBjcy5hdWNrbGFuZC5hYy5uej47IHRzdndnLWNoYWlycyA8dHN2d2ctY2hhaXJz
QGlldGYub3JnPjsgb3BzYXdnQGlldGYub3JnOyBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFs
cGVybi5jb20+OyBzYWFnQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2lwcG1dIFtPUFNBV0ddIFRT
VldHIFdHTEM6IGRyYWZ0LWlldGYtdHN2d2ctdHJhbnNwb3J0LWVuY3J5cHQtMDgsIGNsb3NlcyAy
MyBPY3RvYmVyIDIwMTkNCg0KSSB0aGluayBpdCdzIG9rIHRvIHB1Ymxpc2ggYSBkb2N1bWVudCB3
aXRoIHRoZSBzdGF0ZWQgZ29hbHMsIGJ1dCBJIHRoaW5rIHRoaXMgbmVlZHMgdG8gYmUgZG9uZSB3
aXRoIGdyZWF0IGNhcmUgYW5kIHRoZSBjdXJyZW50IGRvY3VtZW50IGltcGxpZXMgc29tZSB2YWx1
ZSBqdWRnZW1lbnRzIGFuZCBpbXBsaWNhdGlvbnMgSSBkb24ndCB0aGluayBhcmUgZnVsbHkganVz
dGlmaWVkIGJ5IHRoZSBkb2N1bWVudC4gIEEgM3JkIGF1dGhvciB3aXRoIGEgc2xpZ2h0bHkgZGlm
ZmVyZW50IHBlcnNwZWN0aXZlIG1heSBoZWxwIGFjaGlldmUgdGhlIHJpZ2h0IGJhbGFuY2UuDQpb
YWNtXQ0KSXTigJlzIGEgZGlmZmljdWx0IGJ1dCB3b3J0aHdoaWxlIHRoaW5nIHRvIGFjaGlldmUg
TlBPViBvbiBhIGNvbnRyb3ZlcnNpYWwgdG9waWMuDQoNCklNTywgdGhpcyBjYW4gYmUgYXBwcm9h
Y2hlZCBieSBhc2tpbmcgYWxsIGNvbW1lbnRlcnMgdG8gcHJvdmlkZSB0ZXh0IGZvciB0aGUgbWVt
bw0Kb24gdGhlIHRvcGljIG9mIGludGVyZXN0LCB3aGljaCB3aWxsIHJldmVhbCB0aGVpciB2YWx1
ZSBqdWRnZW1lbnRzIGFuZCBvcGluaW9ucw0KZm9yIHRoZSByZXZpZXdpbmcgY29tbXVuaXR5LiBF
ZGl0aW5nIHByb2NlZWRzIGJ5IHRha2luZyBtYW55IFBPViBpbnRvIGFjY291bnQsDQppbiB0aGUg
Zm9ybSBvZiB0ZXh0IGNvbnRyaWJ1dGlvbnMgcmV2aXNlZCBtYW55IHRpbWVzLCBub3Qgb3Bpbmlv
biBvbmx5Lg0KDQo8c25pcCBsb3RzIG9mIHByZXZpb3VzIG1lc3NhZ2VzPg0KPj4gT24gTW9uLCBO
b3YgNCwgMjAxOSBhdCA1OjQ0IFBNIFBldGVyIEd1dG1hbm4NCj4+IDxwZ3V0MDAxQGNzLmF1Y2ts
YW5kLmFjLm56PG1haWx0bzpwZ3V0MDAxQGNzLmF1Y2tsYW5kLmFjLm56PiA8bWFpbHRvOnBndXQw
MDFAY3MuYXVja2xhbmQuYWMubno8bWFpbHRvOnBndXQwMDFAY3MuYXVja2xhbmQuYWMubno+Pj4g
d3JvdGU6DQo+Pg0KPj4gICAgIEkgYWN0dWFsbHkgdGhpbmsgaXQncyBhIHByZXR0eSBnb29kIHN1
bW1hcnksIGFuZCBkZWxpdmVycyBleGFjdGx5DQo+PiB3aGF0J3MNCj4+ICAgICBwcm9taXNlZCBp
biB0aGUgdGl0bGUuICBPVE9IIEkgY2FuIGFsc28gc2VlIHRoYXQgaXQncyBnb2luZyB0byBnZXQN
Cj4+ICAgICBiaWtlc2hlZGRlZA0KPj4gICAgIHRvIGRlYXRoLCBhbmQgd2lsbCBwcm9iYWJseSBu
ZXZlciBiZSBlZGl0YWJsZSBpbnRvIGEgZm9ybSB3aGVyZQ0KPj4gICAgIHBlb3BsZSB3b24ndA0K
Pj4gICAgIGNvbXBsYWluIGFib3V0IGl0IG5vIG1hdHRlciBob3cgbWFueSBjaGFuZ2VzIGFyZSBt
YWRlLg0KPj4gQWx0ZXJuYXRpdmVseSwgaXQnbGwNCj4+ICAgICBlbmQgdXAgd2F0ZXJlZCBkb3du
IHRvIGEgcG9pbnQgd2hlcmUgbm8tb25lIGNhbiBjb21wbGFpbiBhbnkgbW9yZQ0KPj4gICAgIGJ1
dCBpdCB3b24ndA0KPj4gICAgIHNheSBhbnl0aGluZyB0ZXJyaWJseSB1c2VmdWwgYnkgdGhlbi4N
Cj4+DQo+PiAgICAgUGVyaGFwcyBpdCBjb3VsZCBiZSBwdWJsaXNoZWQgYXMgaXMgd2l0aCBhIGNv
bW1lbnQgdGhhdCBpdA0KPj4gICAgIHJlcHJlc2VudHMgdGhlDQo+PiAgICAgb3BpbmlvbnMgb2Yg
dGhlIGF1dGhvcnM/ICBBbHRob3VnaCBnaXZlbiB0aGF0IGl0J3MgSW5mb3JtYXRpb25hbA0KPj4g
YW5kIG5vdA0KPj4gICAgIFN0YW5kYXJkcy10cmFjayBvciBhIEJDUCwgdGhhdCBzaG91bGQgYmUg
YSBnaXZlbiBhbnl3YXkuDQo+Pg0KPj4NCj4+IEFjdHVhbGx5LCBuby4gTW9zdCBJRVRGIGRvY3Vt
ZW50cywgZXZlbiBpbmZvcm1hdGlvbmFsIG9uZXMsIGJlYXIgYQ0KPj4gc3RhdGVtZW50IHRoYXQg
dGhleSBoYXZlIElFVEYgQ29uc2Vuc3VzLg0KPj4NCj4+IFNlZTogaHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL3JmYzU3NDEjc2VjdGlvbi0zLjIuMTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zw
b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfcmZjNTc0MS0y
M3NlY3Rpb24tMkQzLjIuMSZkPUR3TUZhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1PZnNT
dThrVElsdFZ5RDFvTDcyY0J3Jm09VDVMZ3NNQnpGT3M0S1JkaVdJeFg1cFpRN3hiV0FYZ3VMa0gz
Z1gxRFNyZyZzPWVIeTR3OGxWRjNfNVJWTmRpV1FhY1RYeElIOVF1MUNRMFVRNmJEN3lSME0mZT0+
DQo+PiA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU3NDEjc2VjdGlvbi0zLi4yLjE8
aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29s
cy5pZXRmLm9yZ19odG1sX3JmYzU3NDEtMjNzZWN0aW9uLTJEMy4uMi4xJmQ9RHdNRmFRJmM9TEZZ
Wi1vOV9IVU1lTVRTUWljdmpJZyZyPU9mc1N1OGtUSWx0VnlEMW9MNzJjQncmbT1UNUxnc01CekZP
czRLUmRpV0l4WDVwWlE3eGJXQVhndUxrSDNnWDFEU3JnJnM9Mm5qemZUYWJDSVRFRk9QNHlDbDJp
SVl4VUN1MGd1dGxOYXVHWWk4MU85QSZlPT4+DQo+Pg0KPj4gLUVrcg0KPj4NCj4+DQo+PiAgICAg
UGV0ZXIuDQpbYWNtXSBBY3R1YWxseSwgdGhpcyBpcyB0aGUgcmVsZXZhbnQgY2xhc3NpZmljYXRp
b246DQoNCjQuMi4yIEluZm9ybWF0aW9uYWwNCg0KQW4gIkluZm9ybWF0aW9uYWwiIHNwZWNpZmlj
YXRpb24gaXMgcHVibGlzaGVkIGZvciB0aGUgZ2VuZXJhbCBpbmZvcm1hdGlvbiBvZiB0aGUgSW50
ZXJuZXQgY29tbXVuaXR5LCBhbmQgZG9lcyBub3QgcmVwcmVzZW50IGFuIEludGVybmV0IGNvbW11
bml0eSBjb25zZW5zdXMgb3IgcmVjb21tZW5kYXRpb24uDQpGcm9tIGh0dHBzOi8vaWV0Zi5vcmcv
c3RhbmRhcmRzL3Byb2Nlc3MvaW5mb3JtYXRpb25hbC12cy1leHBlcmltZW50YWwvDQpDaG9vc2lu
ZyBiZXR3ZWVuIEluZm9ybWF0aW9uYWwgYW5kIEV4cGVyaW1lbnRhbCBTdGF0dXMNClRoaXMgZG9j
dW1lbnQgcmVwcm9kdWNlcyB0aGUgcnVsZXMgZm9yIGNsYXNzaWZ5aW5nIGRvY3VtZW50cyBhcyBJ
bmZvcm1hdGlvbmFsIGFuZCBFeHBlcmltZW50YWwgZnJvbSBSRkMgMjAyNiwgYW5kIGFtcGxpZmll
cyB0aG9zZSBydWxlcyB3aXRoIGd1aWRlbGluZXMgcmVsZXZhbnQgdG8gb25nb2luZyBJRVNHIGV2
YWx1YXRpb25zLiBJdCBpcyBub3QgaW50ZW5kZWQgdG8gY2hhbmdlIGFueSBvZiB0aGUgdW5kZXJs
eWluZyBwcmluY2lwbGVzLg0KYW5kIGl04oCZcyBhIGTDqWrDoCB2dSBtb21lbnQgZm9yIG1lLg0K
DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCj4+IE9QU0FXRyBtYWlsaW5nIGxpc3QNCj4+IE9QU0FXR0BpZXRmLm9yZzxt
YWlsdG86T1BTQVdHQGlldGYub3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9vcHNhd2c8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91
PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19vcHNhd2cmZD1Ed01GYVEm
Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9T2ZzU3U4a1RJbHRWeUQxb0w3MmNCdyZtPVQ1TGdz
TUJ6Rk9zNEtSZGlXSXhYNXBaUTd4YldBWGd1TGtIM2dYMURTcmcmcz1MRlB6ZFZwRUxNd2VFNUp6
aFNsZi1NQ2ktMV9UZlVHd3ZqWGVTQjFPVDg0JmU9Pg0KPj4NCg==

--_000_4D7F4AD313D3FC43A053B309F97543CFA6F001FBnjmtexg5researc_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQpoMQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAx
IENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6
ZToyNC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJZm9udC13
ZWlnaHQ6Ym9sZDt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2
aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t
cmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBp
bjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNl
cmlmO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5
Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IZWFk
aW5nMUNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMSBDaGFyIjsNCgltc28tc3R5bGUt
cHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAxIjsNCglmb250LWZhbWlseToi
VGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCglmb250LXdlaWdodDpib2xkO30NCnAuaW50cm8sIGxp
LmludHJvLCBkaXYuaW50cm8NCgl7bXNvLXN0eWxlLW5hbWU6aW50cm87DQoJbXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt
dHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpA
cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu
MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7
fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg
djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm
IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw
IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm
XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw
bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBJYW4sIEdvcnJ5IGFuZCBDb2xpbiw8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7
Y29sb3I6YmxhY2siPnBsZWFzZSBzZWUgYSBmZXcgaGFyZC1lYXJuZWQgY29tbWVudHMgYmVsb3cs
IG1hcmtlZCBbYWNtXSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkFsPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxk
aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu
ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmIj4gaXBwbSBbbWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZ10NCjxi
Pk9uIEJlaGFsZiBPZiA8L2I+SWFuIFN3ZXR0PGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBO
b3ZlbWJlciAyMywgMjAxOSA4OjQ4IFBNPGJyPg0KPGI+VG86PC9iPiBHb3JyeSBGYWlyaHVyc3Qg
Jmx0O2dvcnJ5QGVyZy5hYmRuLmFjLnVrJmd0Ozxicj4NCjxiPkNjOjwvYj4gcXVpY0BpZXRmLm9y
ZzsgdHN2d2dAaWV0Zi5vcmc7IElFVEYgSVBQTSBXRyAoaXBwbUBpZXRmLm9yZykgJmx0O2lwcG1A
aWV0Zi5vcmcmZ3Q7OyBQZXRlciBHdXRtYW5uICZsdDtwZ3V0MDAxQGNzLmF1Y2tsYW5kLmFjLm56
Jmd0OzsgdHN2d2ctY2hhaXJzICZsdDt0c3Z3Zy1jaGFpcnNAaWV0Zi5vcmcmZ3Q7OyBvcHNhd2dA
aWV0Zi5vcmc7IEpvZWwgTS4gSGFscGVybiAmbHQ7am1oQGpvZWxoYWxwZXJuLmNvbSZndDs7IHNh
YWdAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtpcHBtXSBbT1BTQVdHXSBUU1ZX
RyBXR0xDOiBkcmFmdC1pZXRmLXRzdndnLXRyYW5zcG9ydC1lbmNyeXB0LTA4LCBjbG9zZXMgMjMg
T2N0b2JlciAyMDE5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIGl0J3Mgb2sgdG8gcHVibGlzaCBhIGRvY3VtZW50IHdp
dGggdGhlIHN0YXRlZCBnb2FscywgYnV0IEkgdGhpbmsgdGhpcyBuZWVkcyB0byBiZSBkb25lIHdp
dGggZ3JlYXQgY2FyZSBhbmQgdGhlIGN1cnJlbnQgZG9jdW1lbnQgaW1wbGllcyBzb21lIHZhbHVl
IGp1ZGdlbWVudHMgYW5kIGltcGxpY2F0aW9ucyBJIGRvbid0IHRoaW5rIGFyZSBmdWxseSBqdXN0
aWZpZWQgYnkgdGhlIGRvY3VtZW50LiZuYnNwOyBBDQogM3JkIGF1dGhvciB3aXRoIGEgc2xpZ2h0
bHkgZGlmZmVyZW50IHBlcnNwZWN0aXZlIG1heSBoZWxwIGFjaGlldmUgdGhlIHJpZ2h0IGJhbGFu
Y2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj
b2xvcjpibGFjayI+W2FjbV0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkl04oCZcyBhIGRpZmZpY3VsdCBi
dXQgd29ydGh3aGlsZSB0aGluZyB0byBhY2hpZXZlIE5QT1Ygb24gYSBjb250cm92ZXJzaWFsIHRv
cGljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SU1PLCB0aGlzIGNhbiBiZSBhcHByb2FjaGVk
IGJ5IGFza2luZyBhbGwgY29tbWVudGVycyB0byBwcm92aWRlIHRleHQgZm9yIHRoZSBtZW1vDQo8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv
cjpibGFjayI+b24gdGhlIHRvcGljIG9mIGludGVyZXN0LCB3aGljaCB3aWxsIHJldmVhbCB0aGVp
ciB2YWx1ZSBqdWRnZW1lbnRzIGFuZCBvcGluaW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5mb3IgdGhlIHJldmlld2lu
ZyBjb21tdW5pdHkuIEVkaXRpbmcgcHJvY2VlZHMgYnkgdGFraW5nIG1hbnkgUE9WIGludG8gYWNj
b3VudCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
Oztjb2xvcjpibGFjayI+aW4gdGhlIGZvcm0gb2YgdGV4dCBjb250cmlidXRpb25zIHJldmlzZWQg
bWFueSB0aW1lcywgbm90IG9waW5pb24gb25seS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl
ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn
aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbHQ7
c25pcCBsb3RzIG9mIHByZXZpb3VzIG1lc3NhZ2VzJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jmd0OyZn
dDsgT24gTW9uLCBOb3YgNCwgMjAxOSBhdCA1OjQ0IFBNIFBldGVyIEd1dG1hbm4NCjxicj4NCiZn
dDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cGd1dDAwMUBjcy5hdWNrbGFuZC5hYy5ueiIgdGFy
Z2V0PSJfYmxhbmsiPnBndXQwMDFAY3MuYXVja2xhbmQuYWMubno8L2E+ICZsdDttYWlsdG86PGEg
aHJlZj0ibWFpbHRvOnBndXQwMDFAY3MuYXVja2xhbmQuYWMubnoiIHRhcmdldD0iX2JsYW5rIj5w
Z3V0MDAxQGNzLmF1Y2tsYW5kLmFjLm56PC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7
PGJyPg0KJmd0OyZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IEkgYWN0dWFsbHkgdGhpbmsgaXQncyBh
IHByZXR0eSBnb29kIHN1bW1hcnksIGFuZCBkZWxpdmVycyBleGFjdGx5IDxicj4NCiZndDsmZ3Q7
IHdoYXQnczxicj4NCiZndDsmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyBwcm9taXNlZCBpbiB0aGUg
dGl0bGUuJm5ic3A7IE9UT0ggSSBjYW4gYWxzbyBzZWUgdGhhdCBpdCdzIGdvaW5nIHRvIGdldDxi
cj4NCiZndDsmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyBiaWtlc2hlZGRlZDxicj4NCiZndDsmZ3Q7
ICZuYnNwOyZuYnNwOyZuYnNwOyB0byBkZWF0aCwgYW5kIHdpbGwgcHJvYmFibHkgbmV2ZXIgYmUg
ZWRpdGFibGUgaW50byBhIGZvcm0gd2hlcmU8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsmbmJzcDsmbmJz
cDsgcGVvcGxlIHdvbid0PGJyPg0KJmd0OyZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbXBsYWlu
IGFib3V0IGl0IG5vIG1hdHRlciBob3cgbWFueSBjaGFuZ2VzIGFyZSBtYWRlLiA8YnI+DQomZ3Q7
Jmd0OyBBbHRlcm5hdGl2ZWx5LCBpdCdsbDxicj4NCiZndDsmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNw
OyBlbmQgdXAgd2F0ZXJlZCBkb3duIHRvIGEgcG9pbnQgd2hlcmUgbm8tb25lIGNhbiBjb21wbGFp
biBhbnkgbW9yZTxicj4NCiZndDsmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyBidXQgaXQgd29uJ3Q8
YnI+DQomZ3Q7Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsgc2F5IGFueXRoaW5nIHRlcnJpYmx5IHVz
ZWZ1bCBieSB0aGVuLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7Jm5ic3A7Jm5i
c3A7IFBlcmhhcHMgaXQgY291bGQgYmUgcHVibGlzaGVkIGFzIGlzIHdpdGggYSBjb21tZW50IHRo
YXQgaXQ8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsgcmVwcmVzZW50cyB0aGU8YnI+
DQomZ3Q7Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsgb3BpbmlvbnMgb2YgdGhlIGF1dGhvcnM/Jm5i
c3A7IEFsdGhvdWdoIGdpdmVuIHRoYXQgaXQncyBJbmZvcm1hdGlvbmFsIDxicj4NCiZndDsmZ3Q7
IGFuZCBub3Q8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsmbmJzcDsmbmJzcDsgU3RhbmRhcmRzLXRyYWNr
IG9yIGEgQkNQLCB0aGF0IHNob3VsZCBiZSBhIGdpdmVuIGFueXdheS48YnI+DQomZ3Q7Jmd0Ozxi
cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQWN0dWFsbHksIG5vLiBNb3N0IElFVEYgZG9jdW1l
bnRzLCBldmVuIGluZm9ybWF0aW9uYWwgb25lcywgYmVhciBhIDxicj4NCiZndDsmZ3Q7IHN0YXRl
bWVudCB0aGF0IHRoZXkgaGF2ZSBJRVRGIENvbnNlbnN1cy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7IFNlZTogPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy
L3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX3JmYzU3NDEtMjNzZWN0aW9uLTJE
My4yLjEmYW1wO2Q9RHdNRmFRJmFtcDtjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmYW1wO3I9T2Zz
U3U4a1RJbHRWeUQxb0w3MmNCdyZhbXA7bT1UNUxnc01CekZPczRLUmRpV0l4WDVwWlE3eGJXQVhn
dUxrSDNnWDFEU3JnJmFtcDtzPWVIeTR3OGxWRjNfNVJWTmRpV1FhY1RYeElIOVF1MUNRMFVRNmJE
N3lSME0mYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvcmZjNTc0MSNzZWN0aW9uLTMuMi4xPC9hPiA8YnI+DQomZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0i
aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29s
cy5pZXRmLm9yZ19odG1sX3JmYzU3NDEtMjNzZWN0aW9uLTJEMy4uMi4xJmFtcDtkPUR3TUZhUSZh
bXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJmFtcDtyPU9mc1N1OGtUSWx0VnlEMW9MNzJjQncm
YW1wO209VDVMZ3NNQnpGT3M0S1JkaVdJeFg1cFpRN3hiV0FYZ3VMa0gzZ1gxRFNyZyZhbXA7cz0y
bmp6ZlRhYkNJVEVGT1A0eUNsMmlJWXhVQ3UwZ3V0bE5hdUdZaTgxTzlBJmFtcDtlPSIgdGFyZ2V0
PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzQxI3NlY3Rpb24tMy4u
Mi4xPC9hPiZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC1Fa3I8YnI+DQomZ3Q7Jmd0
Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IFBldGVyLjxz
cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48aT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj
b2xvcjpibGFjayI+W2FjbV0NCjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5B
Y3R1YWxseSwgdGhpcyBpcyB0aGUgcmVsZXZhbnQgY2xhc3NpZmljYXRpb246PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHA+PGI+NC4yLjIgSW5mb3JtYXRpb25hbDwvYj48bzpwPjwvbzpwPjwvcD4N
CjxwPkFuICZxdW90O0luZm9ybWF0aW9uYWwmcXVvdDsgc3BlY2lmaWNhdGlvbiBpcyBwdWJsaXNo
ZWQgZm9yIHRoZSBnZW5lcmFsIGluZm9ybWF0aW9uIG9mIHRoZSBJbnRlcm5ldCBjb21tdW5pdHks
IGFuZCBkb2VzIG5vdCByZXByZXNlbnQgYW4gSW50ZXJuZXQgY29tbXVuaXR5IGNvbnNlbnN1cyBv
ciByZWNvbW1lbmRhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkZyb20NCjxh
IGhyZWY9Imh0dHBzOi8vaWV0Zi5vcmcvc3RhbmRhcmRzL3Byb2Nlc3MvaW5mb3JtYXRpb25hbC12
cy1leHBlcmltZW50YWwvIj5odHRwczovL2lldGYub3JnL3N0YW5kYXJkcy9wcm9jZXNzL2luZm9y
bWF0aW9uYWwtdnMtZXhwZXJpbWVudGFsLzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTguMHB0Ij5DaG9v
c2luZyBiZXR3ZWVuIEluZm9ybWF0aW9uYWwgYW5kIEV4cGVyaW1lbnRhbCBTdGF0dXM8bzpwPjwv
bzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIGRvY3VtZW50
IHJlcHJvZHVjZXMgdGhlIHJ1bGVzIGZvciBjbGFzc2lmeWluZyBkb2N1bWVudHMgYXMgSW5mb3Jt
YXRpb25hbCBhbmQgRXhwZXJpbWVudGFsIGZyb20gUkZDIDIwMjYsIGFuZCBhbXBsaWZpZXMgdGhv
c2UgcnVsZXMgd2l0aCBndWlkZWxpbmVzIHJlbGV2YW50IHRvIG9uZ29pbmcgSUVTRw0KIGV2YWx1
YXRpb25zLiBJdCBpcyBub3QgaW50ZW5kZWQgdG8gY2hhbmdlIGFueSBvZiB0aGUgdW5kZXJseWlu
ZyBwcmluY2lwbGVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+YW5kIGl04oCZcyBh
IGTDqWrDoCB2dSBtb21lbnQgZm9yIG1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KJmd0OyZndDs8
YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsm
Z3Q7IE9QU0FXRyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T1BT
QVdHQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T1BTQVdHQGlldGYub3JnPC9hPjxicj4NCiZn
dDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/
dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fb3BzYXdnJmFtcDtkPUR3
TUZhUSZhbXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJmFtcDtyPU9mc1N1OGtUSWx0VnlEMW9M
NzJjQncmYW1wO209VDVMZ3NNQnpGT3M0S1JkaVdJeFg1cFpRN3hiV0FYZ3VMa0gzZ1gxRFNyZyZh
bXA7cz1MRlB6ZFZwRUxNd2VFNUp6aFNsZi1NQ2ktMV9UZlVHd3ZqWGVTQjFPVDg0JmFtcDtlPSIg
dGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v
cHNhd2c8L2E+PGJyPg0KJmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_4D7F4AD313D3FC43A053B309F97543CFA6F001FBnjmtexg5researc_--


From nobody Wed Nov 27 03:14:02 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4139120867 for ; Wed, 27 Nov 2019 03:14:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hVpF2RGBUY5 for ; Wed, 27 Nov 2019 03:13:58 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130082.outbound.protection.outlook.com [40.107.13.82]) (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 7A4E9120865 for ; Wed, 27 Nov 2019 03:13:58 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TwAoxr/S8ReYpxXZq44Sxr9BZ/RXisDNVDcE/tPABEvEF4fyiKTRw6EsHKBJ0s/jv1FEfAcEa3Xr+/yLSKH/4OE8Pb5IVCA/wnVZpj3vC1KMNyQ2x9I5C1vgTx/YDApi98jGtjibgNZb1xCNzYWnTHBDGKoht5hc0iYNbCJ+TqYN3cotpWp/eujZqnRw9xByDVbpK95tEBVsMqHCAXMYUZAdKhHzv210Fv8zv+8iDQ0pCwU49hW6L7plVO/AochdIT8agiyFXISnVCCTtsFwHHTFfWqJLX1aemoi89sLbsWib1QqqVtyptSsit2iofwesfllOk2qbz3Lf9Pf6WxjpQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=02DGuFqoUk4kKFLihW/bz81f/sdyJXljhfSnOhRpV6A=; b=K5G6PIE2zkcFRD112lfCh+y/MEzhrRyf0pxYXk5Thevqg4+1H5dJ5bWrOfgjqhxzZcXiEoST0/5Lz2CLx+gP+zElMF0ee9QlPjeyk4ptGSo/SETNjg2DPJfakIzM3lmMGCEMYFen9GYmKlQN7K7lMYELyHdU+oGO+nrjV/GuA5ZmZ33SDoYZ85H6r1mCr+gQYZueyJq/GNxrNYNLk4RogqsuDztUeDpmzar8nyBV5eIQ1pJVA+znNHJkNBxaHKg5CKUMeEicpO2xGfV0gE5IeTDks9Pgcdhv82edDeyBogFC7Yy1M7H/AzMCb01kW58UtoVOhVDID21VaF+Vz8uUsw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=02DGuFqoUk4kKFLihW/bz81f/sdyJXljhfSnOhRpV6A=; b=DaUbztDguhB1BxHA6hvGhov7Yoak+8m2eS2gaTbJVvGhGJ+MF4KhSOp68ZkVWrJDRY7d1aifdagWw5Twr+M0q1An+JDPbtBWe4/OHP///BQ6Auw/3xVOZL/hdFtFf2R2LTTsjai7Tbfs20qcjvGPom/P/vyE0sYw6a9b6/qhxLc=
Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB4348.eurprd07.prod.outlook.com (20.176.167.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.10; Wed, 27 Nov 2019 11:13:56 +0000
Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::21e5:eaae:99ed:41ac]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::21e5:eaae:99ed:41ac%3]) with mapi id 15.20.2495.014; Wed, 27 Nov 2019 11:13:55 +0000
From: John Mattsson 
To: "cfrg@irtf.org" , "saag@ietf.org" 
Thread-Topic: Recommendations Regarding Deterministic Signatures
Thread-Index: AQHVpRPCzwhjXo0nk0GZjF6FACZgbw==
Date: Wed, 27 Nov 2019 11:13:55 +0000
Message-ID: <08737FB3-C63E-453D-BF4E-45BD2A3ABB55@ericsson.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.1f.0.191110
authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; 
x-originating-ip: [82.214.46.143]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6cd7e587-297b-4b3e-8e16-08d7732ae4b4
x-ms-traffictypediagnostic: HE1PR07MB4348:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 023495660C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(136003)(39860400002)(396003)(366004)(189003)(199004)(2501003)(26005)(110136005)(44832011)(66066001)(2616005)(316002)(186003)(966005)(58126008)(102836004)(81166006)(81156014)(66556008)(64756008)(8676002)(66476007)(6506007)(7736002)(66446008)(91956017)(76116006)(66946007)(3846002)(256004)(5660300002)(478600001)(6436002)(6116002)(99286004)(305945005)(8936002)(6512007)(25786009)(6306002)(14454004)(86362001)(71200400001)(2906002)(71190400001)(6486002)(36756003)(33656002)(3480700005)(14444005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4348; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: E+2R9ey4M3GIBEhCmrvDF++6ABDNj0w3Ce20kZtTV4HxbH8waqCBaV6Qfl5wlP0ZbnfJMTdy35v6Zpe3hHFEvTGWDs1UA4zZqF47F8Bku3JdlKYUAdzCdD/mQFUhdfQJl2tMtHh1NBW8ihgEckl2uo2h5z9PA3CIQ4jLxFYirQpKhsmjstivixRDdDIbQ2s1BQclNpSD+8a6gwUi7knrSKS1mcncdKwcJ8DWsVkyE8y9PznszUy/4Cvy8AefeQ4hx+mGQETYz6i9awfiux5D+SrId7UUJf6L39OyUxdAuBzyCCH1lhorI06zWTCS1rjIPm20zr3FnLYXlN2cIVTYQQx4/Irxyj0nJe+ObNhcohKMxWGTYmom4tjRf5lCNcoAiu6onD6CVIfWbnc7VRtbii0LxFoFUfeGbNQUsxfhjMx1Fw8WHiOJe1rUhe6RFyxtgObT/gJhPXTVbPOaIzm5jQV4aKn5Wut2Ye/eMcHuNqA=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <3DC9D5C29655174FA3FCA3BD1403588B@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6cd7e587-297b-4b3e-8e16-08d7732ae4b4
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2019 11:13:55.7614 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hIfRMBPn1K5yqw4LFu+szUrHXznIwr1FZDC0oi/dIwsWmy0hDjd6KKxfWZMZjCgbVosdXdV/xG4urqBtUdFkHKQylfPwYo8FgmsysWR8n9M=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4348
Archived-At: 
Subject: [saag] Recommendations Regarding Deterministic Signatures
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Nov 2019 11:14:01 -0000

SVJURi9JRVRGIGhhcyB0aGUgbGFzdCB5ZWFycyBoZWF2aWx5IHByb21vdGVkIHB1cmVseSBkZXRl
cm1pbmlzdGljIHNpZ25hdHVyZXM6DQoNCiAgUkZDIDgxNTIgKEVkRFNBKToNCiAgICAiRWREU0Eg
c2lnbmF0dXJlcyBhcmUgZGV0ZXJtaW5pc3RpYy4iDQoNCiAgUkZDIDgxNTIgYW5kIFJGQzgxNTJi
aXMgKENPU0UpOiANCiAgICAiSW1wbGVtZW50YXRpb25zIFNIT1VMRCB1c2UgYSBkZXRlcm1pbmlz
dGljIHZlcnNpb24gb2YgRUNEU0EiDQoNCiAgICAiTm90ZTogVXNlIG9mIGEgZGV0ZXJtaW5pc3Rp
YyBzaWduYXR1cmUgdGVjaG5pcXVlIGlzIGEgZ29vZCBpZGVhDQogICAgIGV2ZW4gd2hlbiBnb29k
IHJhbmRvbSBudW1iZXIgZ2VuZXJhdGlvbiBleGlzdHMuIg0KDQogIFJGQyA4NDQ2IChUTFMgMS4z
KQ0KICAgICJJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IGltcGxlbWVudGF0aW9ucyBpbXBsZW1lbnQg
ImRldGVybWluaXN0aWMgRUNEU0EiIg0KDQpOSVNUIGhhcyBqdXN0IHJlbGVhc2VkIEZJUFMgMTg2
LTUgKERyYWZ0KSB3aGVyZSB0aGV5IHBsYW4gdG8gaW5jbHVkZSBkZXRlcm1pbmlzdGljIEVDRFNB
IGJ1dCBkb2VzIG5vdCByZWNvbW1lbmQgaXQgaW4gZ2VuZXJhbCBkdWUgdG8gc2lkZS1jaGFubmVs
IGFuZCBmYXVsdCBpbmplY3Rpb24gYXR0YWNrczoNCg0KICAicmVjZW50IHNlY3VyaXR5IHJlc2Vh
cmNoIGhhcyBmb3VuZCB0aGF0IGltcGxlbWVudGF0aW9ucyBvZg0KICAgdGhlc2UgZGV0ZXJtaW5p
c3RpYyBzaWduYXR1cmUgYWxnb3JpdGhtcyBtYXkgYmUgdnVsbmVyYWJsZQ0KICAgdG8gY2VydGFp
biBraW5kcyBvZiBzaWRlLWNoYW5uZWwgb3IgZmF1bHQgaW5qZWN0aW9uIGF0dGFja3MuIg0KDQog
ICJUaGUgdXNlIG9mIGRldGVybWluaXN0aWMgRUNEU0EgbWF5IGJlIGRlc2lyYWJsZSBmb3IgZGV2
aWNlcw0KICAgdGhhdCBkbyBub3QgaGF2ZSBhIGdvb2Qgc291cmNlIG9mIHF1YWxpdHkgcmFuZG9t
IG51bWJlcnMuIiANCg0KICBodHRwczovL3d3dy5mZWRlcmFscmVnaXN0ZXIuZ292L2RvY3VtZW50
cy8yMDE5LzEwLzMxLzIwMTktMjM3NDIvcmVxdWVzdC1mb3ItY29tbWVudHMtb24tZmlwcy0xODYt
NS1hbmQtc3AtODAwLTE4Ng0KDQogIGh0dHBzOi8vY3NyYy5uaXN0Lmdvdi9wdWJsaWNhdGlvbnMv
ZGV0YWlsL2ZpcHMvMTg2LzUvZHJhZnQNCg0KUmVjZW50IHJlc2VhcmNoIHBhcGVycyBvbiBkZXRl
cm1pbmlzdGljIHNpZ25hdHVyZXM6DQoNCiAgWzFdIGh0dHBzOi8vZXByaW50LmlhY3Iub3JnLzIw
MTcvOTc1DQogIFsyXSBodHRwczovL2VwcmludC5pYWNyLm9yZy8yMDE3LzEwMTQNCiAgWzNdIGh0
dHBzOi8vbGluay5zcHJpbmdlci5jb20vY2hhcHRlci8xMC4xMDA3Lzk3OC0zLTMxOS00NDUyNC0z
XzExDQoNCkNvdW50ZXJtZWFzdXJlcyBkaXNjdXNzZWQgaW4gYm90aCBbMV0gYW5kIFsyXSBpcyB0
byBhZGQgc29tZSAiYWRkaXRpb25hbCByYW5kb21uZXNzIiAvICJub2lzZSIgdG8gdGhlIGRldGVy
bWluaXN0aWMgY2FsY3VsYXRpb24gb2YgJ2snLg0KDQpNeSBjdXJyZW50IHZpZXcgaXMgdGhhdCBi
ZXN0IHByYWN0aWNlIHNlZW1zIHRvIGJlIHRvIHVzZSBkZXRlcm1pbmlzdGljIGFsZ29yaXRobXMg
KGRldGVybWluaXN0aWMgRUNEU0Egb3IgRWREU0EpIHdpdGggImFkZGl0aW9uYWwgcmFuZG9tbmVz
cyIgLyAibm9pc2UiIGxpa2UgaW4gWEVkRFNBLiBUaGlzIGFsc28gbWl0aWdhdGVzIGF0dGFja3Mg
b24gdGhlb3JldGljYWwgdXNlIGNhc2VzIHdoZXJlIGRldGVybWluaXN0aWNhbGx5IHNpZ25pbmcg
dGhlIHNhbWUgbWVzc2FnZSB0d2ljZSBsZWFrcyBpbmZvcm1hdGlvbi4NCg0KaHR0cHM6Ly9zaWdu
YWwub3JnL2RvY3Mvc3BlY2lmaWNhdGlvbnMveGVkZHNhLw0KDQpUaGUgYWRkaXRpb25hbCByYW5k
b21uZXNzIChhbmQgYWxsIG90aGVyIHJhbmRvbW5lc3MpIHNob3VsZCBiZSBnZW5lcmF0ZWQgd2l0
aCBhIGNvbnN0cnVjdGlvbiBsaWtlIGRyYWZ0LWlydGYtY2ZyZy1yYW5kb21uZXNzLWltcHJvdmVt
ZW50cyB0aGF0IGZlZWRzIGEgcHNldWRvIHJhbmRvbSBudW1iZXIgZ2VuZXJhdG9yIHdpdGggYSBy
YW5kb20gc2VlZCwgYSBzZWNyZXQga2V5LCBhIGNvbnRleHQgc3RyaW5nLCBhbmQgYSBub25jZS4N
Cg0KRm9yIGdsb2JhbCBjb21wYW5pZXMgbGlrZSBFcmljc3NvbiB0aGF0IHdvdWxkIGxpa2UgdG8g
YmUgY29tcGxpYW50IHdpdGggYm90aCBSRkNzIGFuZCBOSVNUIHB1YmxpY2F0aW9ucywgaXQgd291
bGQgYmUgZ29vZCB3aXRoIGFsaWdubWVudCBiZXR3ZWVuIElSVEYvSUVURi9OSVNULg0KDQpDaGVl
cnMsDQpKb2huDQoNCg==


From nobody Wed Nov 27 09:10:52 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95889120809 for ; Wed, 27 Nov 2019 09:10:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFIWI7d60JKP for ; Wed, 27 Nov 2019 09:10:39 -0800 (PST)
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::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 DD61F12004D for ; Wed, 27 Nov 2019 09:10:38 -0800 (PST)
Received: by mail-oi1-x231.google.com with SMTP id e9so20758765oif.8 for ; Wed, 27 Nov 2019 09:10:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i33esFxqJZqL2ot8DhAC5kMOiJfM9t65gLrn65ATwUI=; b=HbMijUfBVEkHlt0v/kIr0eJe4Itb/lx2gP2bFkaccZkx+NRTVLbO+heOSL2a/NPv0I 1M8WTysQ7Y86ZCLCct0AP5g4M4uULpHpALLaaswz5T99Efvv8/Zv0XDzfUxr6sSg+GUH y99Wx4879/WkKGs8j7/cWdYAhUOXRJ4pWe4oSRHeuFpsSF6SXcBsYIpkw6H5ciPxDRLu M3InjwzmK0JUHl41XtVJkA8shyWvRb72mNMSgB99n/APvOxgYRH0yVMENK1hpWkhL0nj 2dUbegWMcecUpWMQKRzAt+xG34bQ5ZL12UxIGI0W7oa9YTZerau/b85XyfcdzaT/2SyW Mz7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i33esFxqJZqL2ot8DhAC5kMOiJfM9t65gLrn65ATwUI=; b=PughbWB8oAsZNwDtSNu+d6kLpPW0VuGbtqbBRtKZQULxyc+L5pz3X/UKpIZbuJhVH0 BdTXkJvNiDcNvflY2RTtvv0iXP2muTh9FgJCk5P/Nwx0kgmfpMkm3KiO44sVW0Q6O/v8 /8xJ3crCoaschrgWsikeQV0WcfGi5oY9o+BJLbVDPzvHmBOWnWmeID/DYsiCuocqIEV6 I1u+iSaMod2iko/Uxl4ZXgg8wNvOXZjHs1H0UGaNyzdPb0X2w9WlqHbPCmf5FONubLDS BZmBJDu8NtsaFPTRXeMmrOFSkcNo4m+z/xxjLZ5UHtJtW4bAiy49MHX+2lKFVewp4iMv l42A==
X-Gm-Message-State: APjAAAVQaFqiJPGBcEPuyAC1HvUPIWW+SpL+UAl30FJMkrNYrTT9PvcZ 9mSWzRwK2vHg43XtRXkJoQg1kw3ynNcoigffb9dMoROF
X-Google-Smtp-Source: APXvYqyYg0QckU6nf4meGqs/p44Iwkc9NC++JD0CQsrtxH41glDYZPBxNX3+w4mmRYGmLYpmPcjalKOtfAvP6EVJeks=
X-Received: by 2002:aca:ded4:: with SMTP id v203mr5176747oig.96.1574874638090;  Wed, 27 Nov 2019 09:10:38 -0800 (PST)
MIME-Version: 1.0
References: <08737FB3-C63E-453D-BF4E-45BD2A3ABB55@ericsson.com>
In-Reply-To: <08737FB3-C63E-453D-BF4E-45BD2A3ABB55@ericsson.com>
From: Tony Arcieri 
Date: Wed, 27 Nov 2019 09:10:27 -0800
Message-ID: 
To: John Mattsson 
Cc: "cfrg@irtf.org" , "saag@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000005e89bb05985713c6"
Archived-At: 
Subject: Re: [saag] [Cfrg] Recommendations Regarding Deterministic Signatures
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Nov 2019 17:10:42 -0000

--0000000000005e89bb05985713c6
Content-Type: text/plain; charset="UTF-8"

On Wed, Nov 27, 2019 at 3:14 AM John Mattsson  wrote:

> My current view is that best practice seems to be to use deterministic
> algorithms (deterministic ECDSA or EdDSA) with "additional randomness" /
> "noise" like in XEdDSA.


I'll +1 this, but also noting that for existing deterministic signature
algorithms, one potential mitigation for fault injection attacks against
these algorithms (depending on whether circumstances / threat models permit
it) is verifying generated signatures before releasing them.

That doesn't help with the issue of leaking message equivalence, however
I'll also note that some applications of deterministic signatures I work on
personally benefit from the determinism from a fault-tolerance perspective,
as it allows for recomputing a signature on a message which may or may not
have been lost in a protocol where inconsistent signature generation in and
of itself is considered a fault.

-- 
Tony Arcieri

--0000000000005e89bb05985713c6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


My current view is t=
hat best practice seems to be to use deterministic algorithms (deterministi=
c ECDSA or EdDSA) with "additional randomness" / "noise"=
; like in XEdDSA.

I'll=C2=A0+1 this, bu=
t also noting that for existing deterministic signature algorithms, one pot=
ential mitigation for fault injection attacks against these algorithms (dep=
ending on whether circumstances / threat models permit it) is verifying gen=
erated signatures before releasing them.

That does=
n't help with the issue of leaking message equivalence, however I'l=
l also note that some applications of deterministic signatures I work on pe=
rsonally benefit from the determinism from a fault-tolerance perspective, a=
s it allows for recomputing a signature on a message which may or may not h=
ave been lost in a protocol where inconsistent signature generation in and =
of itself is considered a fault.

-- 
Tony Arcieri


--0000000000005e89bb05985713c6--


From nobody Thu Nov 28 11:38:15 2019
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB361208C6; Thu, 28 Nov 2019 11:38:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZbbh99qOG6x; Thu, 28 Nov 2019 11:38:08 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 011BA120823; Thu, 28 Nov 2019 11:38:07 -0800 (PST)
Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xASJc2sN017885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Nov 2019 14:38:04 -0500
Date: Thu, 28 Nov 2019 11:38:01 -0800
From: Benjamin Kaduk 
To: John Mattsson 
Cc: "cfrg@irtf.org" , "saag@ietf.org" 
Message-ID: <20191128193801.GU32847@mit.edu>
References: <08737FB3-C63E-453D-BF4E-45BD2A3ABB55@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <08737FB3-C63E-453D-BF4E-45BD2A3ABB55@ericsson.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [saag] Recommendations Regarding Deterministic Signatures
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Nov 2019 19:38:09 -0000

On Wed, Nov 27, 2019 at 11:13:55AM +0000, John Mattsson wrote:
> IRTF/IETF has the last years heavily promoted purely deterministic signatures:
> 
>   RFC 8152 (EdDSA):
>     "EdDSA signatures are deterministic."
> 
>   RFC 8152 and RFC8152bis (COSE): 
>     "Implementations SHOULD use a deterministic version of ECDSA"
> 
>     "Note: Use of a deterministic signature technique is a good idea
>      even when good random number generation exists."
> 
>   RFC 8446 (TLS 1.3)
>     "It is RECOMMENDED that implementations implement "deterministic ECDSA""
> 
> NIST has just released FIPS 186-5 (Draft) where they plan to include deterministic ECDSA but does not recommend it in general due to side-channel and fault injection attacks:

Can anyone comment on the relative weight that NIST gives to hardware vs.
software-only implementations?  My understanding is that these attacks can
be quite severe for hardware implementations.

> My current view is that best practice seems to be to use deterministic algorithms (deterministic ECDSA or EdDSA) with "additional randomness" / "noise" like in XEdDSA. This also mitigates attacks on theoretical use cases where deterministically signing the same message twice leaks information.
> 

This does seem like an attractive proposition on first inspection.

Thanks,

Ben