Re: [tsvwg] [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020
Ruediger.Geib@telekom.de Wed, 01 July 2020 13:56 UTC
Return-Path: <Ruediger.Geib@telekom.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CF03A05A4; Wed, 1 Jul 2020 06:56:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=telekom.de
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 K6SBlgdNGHwQ; Wed, 1 Jul 2020 06:56:04 -0700 (PDT)
Received: from mailout31.telekom.de (mailout31.telekom.de [194.25.225.143]) (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 7F31D3A0813; Wed, 1 Jul 2020 06:56:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1593611764; x=1625147764; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8GyhitH691JGocfS3HOI5xTjtLpjblCc6WKzjcv9SHk=; b=ikP9qYs7XO9T96eusjWQXsph281P6pfWuM7/ziJvbZdO3YUyhx1bQFVR yo8MS84B17AcRN5KceEUmzGEdyVXOS+Hjcgs8UEM9bdQb1f7aXCXKvSOH cVfdkr32Oi/TAE2EvBjIzOke7pGeORV97REYOVzs/s21kfElayLiRt9ur BPwsdIb4YHCVgrukUDf3xVGfA0xDn20dZFAk+jwmhpacSUTR9+vLcUhy+ 1H7MIb0YvRMbudMrS10uawwCHF+lg8sCw8QkOZfy9G+McClGJGvyLfgD2 96CMSqe3L0pzN+BB2kkKrDf00lidyffH1sMHkPNfDUoNd6uXb7cCni7mG A==;
IronPort-SDR: mDNL4j2aLHkYP3nkM+Nb/d/Dopqe6ZhGuSaYX2ZcFtU4ogUE29TLP0EQKXqsKQyJeJqO1rRR1v g0k8Y8YfvTug==
Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2020 15:56:00 +0200
IronPort-SDR: w7wTjtQP3BYpVA36UOHt26rTwBCAv7P3lQO8ttE+xQ1cAabcWGs3HaVkeRIcxRij4XJ+cho8X3 WNI9kNHn39Xb2ng8g8omb8PiM3zp/FQnk=
X-IronPort-AV: E=Sophos;i="5.75,300,1589234400"; d="scan'208,217";a="818479383"
X-MGA-submission: MDFw0BvpBE4sc6qocZZrYNMDC7TvJuQ+qTYXKy+74pGlmJ7mpeE+/rzEGnlmxRPpTQagkwcYEre0sNdzIbonmrnwN9l6IcoA5RX5Op1mTya782MnyUjWE6xhQ5n/iJHjFEXEPXyIV5+iW6VS9KPRUGuQONNUqecSmAmRv75zA8GhZg==
Received: from he105867.emea1.cds.t-internal.com ([10.169.119.44]) by QDE8PP.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 01 Jul 2020 15:56:00 +0200
Received: from HE105864.EMEA1.cds.t-internal.com (10.169.119.41) by HE105867.emea1.cds.t-internal.com (10.169.119.44) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 1 Jul 2020 15:56:00 +0200
Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE105864.EMEA1.cds.t-internal.com (10.169.119.41) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 1 Jul 2020 15:56:00 +0200
Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.16) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 1 Jul 2020 15:55:58 +0200
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GIW2uh5IxtTHsIiRBljDTgRHt9efLoh9Uv9Sw8Tzx5udDuIH3dNJFj+4uR9npQ7jVWdH+F3aNS55nhP6iIW2w6WSjNb3ktwJyOS5cZU5aZWsklDp0p7eOVFhDnRLB72wOLpymBFifY236FZxhR233/MUMIwJrUTZ376m5PJ+7TDPGiJzdTgi/Q5iaWhueEk2w5x/tvsrTcLabiVMHDmxhbZJ3OF978n4gN6p/yq59sqLixnUEZ09hOG46sYZotQqN8Z29qdEHa5rTGELLrnDVV1jrDH1TluMbhOoDwZRJFPjMXYxQa+S0Ox56XKWL86rU/f9njT2UmNi5iEVFR10gQ==
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=8GyhitH691JGocfS3HOI5xTjtLpjblCc6WKzjcv9SHk=; b=CE5PFqeNJu+UUCLhkghpGKS+aJ/3mWLw0DQzI1a/1B8pi92CKK93YoohqvFm45oUmmPg9A7C6RDy+CNtgLzpIYKOmeuvyU8N2fqiWEZonHRgYUw4ncyrY+olilSzC7SEq6B/gmND9zQSLXbHLmJyPEESDElUgTnim6a2CL2VGgug2rflzBBId1bvWwNhM8gMJdXGtQtTVynZWbqrz+cjjK9opo2N8+gKYWe9LV+bK/RNrJ+/wN2S+IZ/mqUhgoao1uIv8jAoICuQPFrH7/knpgPnBdVHoukZq77Q5HEAXUhBGRzFaiWJXV+HFeE9h3AdBjDY8q3QkSGFNR0+CmmFKg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none
Received: from LEXPR01MB1040.DEUPRD01.PROD.OUTLOOK.DE (2a01:4180:c013:10::18) by LEXPR01MB0701.DEUPRD01.PROD.OUTLOOK.DE (2a01:4180:c013:d::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.25; Wed, 1 Jul 2020 13:55:59 +0000
Received: from LEXPR01MB1040.DEUPRD01.PROD.OUTLOOK.DE ([fe80::9570:5376:d64e:6584]) by LEXPR01MB1040.DEUPRD01.PROD.OUTLOOK.DE ([fe80::9570:5376:d64e:6584%8]) with mapi id 15.20.3131.030; Wed, 1 Jul 2020 13:55:59 +0000
From: Ruediger.Geib@telekom.de
To: Hannes.Tschofenig@arm.com
CC: int-area@ietf.org, tsvwg@ietf.org, saag@ietf.org
Thread-Topic: [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020
Thread-Index: AQHWTqKKcYDEsnf9FUGfSu5ndzzjXqjysTaAgAAGTICAAAUUoA==
Date: Wed, 01 Jul 2020 13:55:59 +0000
Message-ID: <LEXPR01MB1040C937CACB87CB953E29869C6C0@LEXPR01MB1040.DEUPRD01.PROD.OUTLOOK.DE>
References: <MN2PR19MB40450EE357BEECD723AB06F183820@MN2PR19MB4045.namprd19.prod.outlook.com> <CABcZeBM9A1RxOiHGZdBznTb7zzArG5GTQs=bhNtBy90tSXs3Pg@mail.gmail.com> <AM0PR08MB3716528B48BCF9447002B551FA6F0@AM0PR08MB3716.eurprd08.prod.outlook.com> <21886_1593608278_5EFC8856_21886_470_1_787AE7BB302AE849A7480A190F8B9330314EBA5C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <AM0PR08MB371604E04179C212341100EEFA6C0@AM0PR08MB3716.eurprd08.prod.outlook.com>
In-Reply-To: <AM0PR08MB371604E04179C212341100EEFA6C0@AM0PR08MB3716.eurprd08.prod.outlook.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=telekom.de;
x-originating-ip: [164.19.3.232]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7040420d-8d58-48ef-867d-08d81dc67bee
x-ms-traffictypediagnostic: LEXPR01MB0701:
x-microsoft-antispam-prvs: <LEXPR01MB0701EF722405A34DC9D740EF9C6C0@LEXPR01MB0701.DEUPRD01.PROD.OUTLOOK.DE>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 04519BA941
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: XKS9TKoTwxFdWX8liOx3JRMSkW/Ic8a+L0PhOl7UiBk5h/s1uzSPlECbIxvwG2Kd8uywqX4ZZsFkV+byRfDwSuQ8m6Ym+w6ajlVoyMJBvgNCp02tOuGfY22hnkKtx4BOpGt2hcKc8Zz+yElru5Ukw4bxVTjn5ItKnXmH9EYPiqZ7wGtIxbaWrnSMLD4kBeejuoyif5qE8lqbTltwwqeSNnYaTZNfBg91BnYimjEO2tkgv2JJIPR325Udq/jiFF2aICD/dTYErLSReoA890qm6jwN9hZBSViFaoec/Onx3d2dsnrelTcAXs739BGgFkLrLKx152ITHd7job2r50USYxsTSXLXWeKwmnFIyoHq8ymKpN7VTU+au+YOZXVz3t5qHUsk0s54GtlnowyCmN1TTMxEAxxtHigMtDB4lqDSU9c=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LEXPR01MB1040.DEUPRD01.PROD.OUTLOOK.DE; PTR:; CAT:NONE; SFTY:; SFS:(396003)(346002)(376002)(39860400002)(136003)(366004)(26005)(966005)(8676002)(6916009)(166002)(9326002)(478600001)(53546011)(8936002)(5660300002)(7696005)(9686003)(55016002)(33656002)(186003)(19627235002)(71200400001)(66476007)(66946007)(66574015)(85182001)(316002)(83380400001)(86362001)(85202003)(76116006)(54906003)(66556008)(64756008)(66446008)(4326008)(2906002)(777600001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 71N6C4dIjJQ3//SXR8cmZuThte4fwCuB8IKGGkhG3xHf0VDRHK+cY1doYj7tSn0vxw4ZQf1D5SYfg8P7VWCsnz5Izk70x2LrUfCY0EfdInYWe9IiyAjTOJHoZAyRpK92WyyZaav+af8pD3FMeQnUEVrEXU43oG2Jvctq11h9OTnG9mctJif3T+LP9qnkffVOWCGP8WxeIp23NTbwpMHpwg7Zl84+C2Bs7QuvlK0G4S61tI1uLGFLQREcB03+UoauCkQ2IC6+0dhj4sMr3zW2rlyTP0bdXH+iQLeJn/pFeC83DhIQP/v7BxR6yOpwgl4Wkozk65z+Z+Fv9JxzGrF0MFNyAVvxgaySHOgDV0oAl7Za7VD+0R1qQTmRtjsLFszv6C+MZ5CWT8nbRRP3vAUTpQUYyO50xW/4r7gliXpegvkwZ+VuBm9/FrCK4tibA8p3QiY68O6cp7XaQqfW9OYLF87z+lXHlUvGPDiU7PzBrdw=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_LEXPR01MB1040C937CACB87CB953E29869C6C0LEXPR01MB1040DEUP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: LEXPR01MB1040.DEUPRD01.PROD.OUTLOOK.DE
X-MS-Exchange-CrossTenant-Network-Message-Id: 7040420d-8d58-48ef-867d-08d81dc67bee
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2020 13:55:59.2165 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: EDSsEVpXeUoPdUAb/bnfXuBbhXGA/oMhFKe69xmCqXluSfzLBJSiPvkxpuj6XRPDDTmGPAwCOrCuNx1woqZWN7bXAY0bO7WoIxvitNezZ/s=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB0701
X-TM-SNTS-SMTP: 1B9C38F24E9A3E54780CCE2D6720B825E8010E5A3230BF21EB708244B7B0E3B22000:8
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/SEJgbIlNHGdtbctiNPbVKOrHcdA>
Subject: Re: [tsvwg] [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2020 13:56:08 -0000
Hi Hannes, do I understand you correctly that exposing transport information to calculate a flow RTT or a flow loss rate by a passive observer along a path is a break in security to you ( sorry if I’m asking something where you’ve expressed your opinion already elsewhere, I didn’t follow the transport exposure vs encryption discussion) ? Just to understand whether there is absolutely no common ground. Regards, Ruediger Von: tsvwg <tsvwg-bounces@ietf.org> Im Auftrag von Hannes Tschofenig Gesendet: Mittwoch, 1. Juli 2020 15:20 An: mohamed.boucadair@orange.com; Black, David <David.Black@dell.com> Cc: int-area <int-area@ietf.org>; tsvwg@ietf.org; IETF SAAG <saag@ietf.org> Betreff: Re: [tsvwg] [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 I noticed this in various IETF discussions and so I will describe it in the abstract. A group of people propose an idea. Those who do not like the idea are then asked to convince the original contributors that their idea is not sound or contribute text so make it look nicer. Not only is this requiring me to spend my time on something I don’t agree with but it turns out that no discussions will change the mind of the original contributors. They just strongly believe in their ideas. They will keep proposing the same idea over and over again (for years) till it gets published as an RFC. Ciao Hannes From: mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> Sent: Wednesday, July 1, 2020 2:58 PM To: Hannes Tschofenig <Hannes.Tschofenig@arm.com<mailto:Hannes.Tschofenig@arm.com>>; Black, David <David.Black@dell.com<mailto:David.Black@dell.com>> Cc: int-area <int-area@ietf.org<mailto:int-area@ietf.org>>; tsvwg@ietf.org<mailto:tsvwg@ietf.org>; IETF SAAG <saag@ietf.org<mailto:saag@ietf.org>> Subject: RE: [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 Hi Hannes, It would be helpful if you can explicit the “wrong message” you are referring to, and preferably with text from the draft conveying that message. Thank you. Cheers, Med De : Int-area [mailto:int-area-bounces@ietf.org] De la part de Hannes Tschofenig Envoyé : mardi 30 juin 2020 07:50 À : Eric Rescorla; Black, David Cc : int-area; tsvwg@ietf.org<mailto:tsvwg@ietf.org>; IETF SAAG Objet : Re: [Int-area] [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 I believe this document signals a wrong message to the wider Internet community. I agree that it should not be published as a consensus document. I understand that some people are unhappy about encrypting more meta-data. This prevents them from doing things they used to do in the past, some of which they should have never done in the first place. Improving the protection of meta-data is important and well supported by a large number of activities in the IETF (the notable exception being CoAP+OSCORE). Ciao Hannes From: saag <saag-bounces@ietf.org<mailto:saag-bounces@ietf.org>> On Behalf Of Eric Rescorla Sent: Tuesday, June 30, 2020 3:00 AM To: Black, David <David.Black@dell.com<mailto:David.Black@dell.com>> Cc: int-area <int-area@ietf.org<mailto:int-area@ietf.org>>; tsvwg@ietf.org<mailto:tsvwg@ietf.org>; IETF SAAG <saag@ietf.org<mailto:saag@ietf.org>> Subject: Re: [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 > > This 3rd WGLC is limited to the following two topics: > > > Whether or not to proceed with a request for RFC publication > > of the draft. The decision on whether or not to proceed will > be based on rough consensus of the WG, see RFC 7282. > During the 2nd WGLC, Eric Rescorla and David Schinazi expressed > strong views that this draft should not be published – those > concerns have not been resolved and are carried forward to > this WGLC. This email message was an attempt to summarize > those concerns: > > https://mailarchive.ietf.org/arch/msg/tsvwg/i4qyY1HRqKwm0Jme9UtEb6DyhXU/ > > Further explanation from both Eric Rescorla and David Schinazi > is welcome and encouraged to ensure that their concerns are > clearly understood. Well, I'll try again, but I'm not sure that I can do better than I have before. For reasons that are laid out in RFC 7258, the trend in protocol design in IETF is towards encrypting more and more. The last two transport protocols that were designed and widely deployed (SCTP over DTLS and QUIC) both encrypt the vast majority of the protocol metadata. This document advertises itself as "considerations" for design of such protocols: The transport protocols developed for the Internet are used across a wide range of paths across network segments with many different regulatory, commercial, and engineering considerations. This document considers some of the costs and changes to network management and research that are implied by widespread use of transport protocols that encrypt their transport header information. It reviews the implications of developing transport protocols that use end-to-end encryption to provide confidentiality of their transport layer headers, and considers the effect of such changes on transport protocol design, transport protocol evolution, and network operations. It also considers some anticipated implications on application evolution. This provides considerations relating to the design of transport protocols and features where the transport protocol encrypts some or all of their header information. However, as I said above, the new transport protocols that are actually being designed already feature metadata encryption and as far as I can tell, there is no prospective protocol new transport protocol design project for which these issues might be live. In that context, it's hard not to read this document with its long litany of practices which are impacted by metadata encryption as a critique of the decisions by SCTP/DTLS and QUIC to encrypt most of the metadata. This impression is reinforced by the description of the actual practices themselves, which focuses almost entirely on practices which appear to be benignly motivated (e.g., performance monitoring, troubleshooting, etc.) However, we also know that metadata is widely used for practices in which the network operator is adversarial to the user, for instance: - Blocking traffic based on TCP port, IP address, SNI, etc. - Performance-based traffic class discrimination - Monitoring the user's behavior via indicia like the ones above or via traffic analysis (see [0]) Yes, I understand that the authors explicitly disclaim judgement on these practices, and the document does briefly touch on the general idea, though the "concerns...have been voiced" tends to minimize those concerns [1] but the selection of practices to focus on is extremely telling. Focusing on the downsides of encryption for (at least arguably well-meaning) network players while mostly ignoring the large class of non-benign behaviors which encryption is intended to protect against has the effect of overemphasizing the costs of encryption to those players and minimizing the benefits to the endpoints whom it is intended to protect. To be maximally clear: I don't object to this document existing and I don't think that the opinions implicit in it are ones that should not be expressed. I merely don't think that it should be published as an IETF Consensus document. -Ekr [0] https://tools.ietf.org/html/draft-wood-pearg-website-fingerprinting-00#section-5 [1] Another motivation stems from increased concerns about privacy and surveillance. Users value the ability to protect their identity and location, and defend against analysis of the traffic. Revelations about the use of pervasive surveillance [RFC7624] have, to some extent, eroded trust in the service offered by network operators and have led to an increased use of encryption to avoid unwanted eavesdropping on communications. Concerns have also been voiced about the addition of information to packets by third parties to provide analytics, customisation, advertising, cross-site tracking of users, to bill the customer, or to selectively allow or block content. Whatever the reasons, the IETF is designing protocols that include transport header encryption (e.g., QUIC [I-D.ietf-quic-transport]) to supplement the already widespread payload encryption, and to further limit exposure of transport metadata to the network. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
- [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvw… Black, David
- Re: [tsvwg] [saag] 3rd WGLC (limited-scope): draf… mohamed.boucadair
- Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-… Paul Vixie
- Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-… Mike Bishop
- Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-… Paul Vixie
- Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-… Spencer Dawkins at IETF
- Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-… Eric Rescorla
- Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-… Joseph Touch
- Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-… Black, David
- Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-… Spencer Dawkins at IETF
- Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-… Kathleen Moriarty
- Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-… Spencer Dawkins at IETF
- Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-… Joe Touch
- Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-… Rodney W. Grimes
- Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-… Mike Bishop
- Re: [tsvwg] [saag] 3rd WGLC (limited-scope): draf… Kyle Rose
- Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-… Eric Rescorla
- Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-… Roni Even
- Re: [tsvwg] [Int-area] 3rd WGLC (limited-scope): … Tom Herbert
- Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-… Holland, Jake
- Re: [tsvwg] [Int-area] 3rd WGLC (limited-scope): … Gorry Fairhurst
- Re: [tsvwg] [saag] 3rd WGLC (limited-scope): draf… Eric Rescorla
- Re: [tsvwg] [saag] 3rd WGLC (limited-scope): draf… Christopher Wood
- Re: [tsvwg] [saag] 3rd WGLC (limited-scope): draf… Hannes Tschofenig
- Re: [tsvwg] [saag] 3rd WGLC (limited-scope): draf… Gorry Fairhurst
- Re: [tsvwg] [saag] 3rd WGLC (limited-scope): draf… Martin Thomson
- Re: [tsvwg] [saag] 3rd WGLC (limited-scope): draf… Spencer Dawkins at IETF
- Re: [tsvwg] [saag] 3rd WGLC (limited-scope): draf… Colin Perkins
- Re: [tsvwg] [saag] 3rd WGLC (limited-scope): draf… Colin Perkins
- Re: [tsvwg] [saag] 3rd WGLC (limited-scope): draf… mohamed.boucadair
- Re: [tsvwg] [saag] 3rd WGLC (limited-scope): draf… Hannes Tschofenig
- Re: [tsvwg] [saag] 3rd WGLC (limited-scope): draf… Ruediger.Geib
- Re: [tsvwg] [saag] 3rd WGLC (limited-scope): draf… Kyle Rose
- Re: [tsvwg] [Int-area] [saag] 3rd WGLC (limited-s… Dirk.von-Hugo
- Re: [tsvwg] [Int-area] [saag] 3rd WGLC (limited-s… Joseph Touch
- Re: [tsvwg] [saag] [Int-area] 3rd WGLC (limited-s… Behcet Sarikaya
- Re: [tsvwg] [Int-area] [saag] 3rd WGLC (limited-s… tom petch
- Re: [tsvwg] [Int-area] [saag] 3rd WGLC (limited-s… Spencer Dawkins at IETF