From nobody Thu Nov 1 14:35:10 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210CA127B92; Thu, 1 Nov 2018 14:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rA1xGyRnyMu9; Thu, 1 Nov 2018 14:35:06 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9977612D4E8; Thu, 1 Nov 2018 14:35:05 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id k19-v6so10890018lji.11; Thu, 01 Nov 2018 14:35:05 -0700 (PDT) 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=FzxYsxt+tolJO6QxYM3NLMxYest/lNf8OOQZLBo+0Y8=; b=fsfBnixt3vOgo08SoFtmKFnZ490z2nezJqNsebS6YjghZ51768o20VBPDIJ4KdTUFS A0BEktKYc0Gy0A75AMJivVRC7rISDfIRke6yzs5It1wFHnpbfEdvMrpwnkz9FemvyKat NyWo+ZILYH/Dmbnxoby/wF3B2uaNpRt4QDidIZBkneUYbu8hT/OvoYv1X7T24JH8vPPj ZlRVrvBPASbzhcSlNU+C2HCrk6bBfkIv0SiX3pvPLf3vwldoa59P5qEGQqJSsNzZAy1w oFC8yOMSizqc8xh00zCDYbSjY47YkIchZTnoFkr7s8j3El4Axec8fS7jz0OOfmP7btb7 rg5A== 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=FzxYsxt+tolJO6QxYM3NLMxYest/lNf8OOQZLBo+0Y8=; b=AcyNtfIiWyu4XCzWaNJ7BoIzIxcnLEbDnMM4iCetGw9aS2ydS6IK219y37SmR4Rc9E FJsOxNZ9XGFrVgidnypqZ1iseexULWJvfdx+GWgCe+DrpomMlGbkOGcS8Gla96Fl7X1l 8BtxQtCFAxj5s3qabOMwWPF884weCaV0mW9HCz3QXIM0O/6uICpcKY+2ulLvpZeDYfRK 1ECQWqH5etdpvYk8wnmfNg/g7X8MI/0tgJFAjFrmPjHpE99iNjUjcXXJenFvcHNQP8V4 fbrMkJQBRdYqk8VQd4w0o2fXYdOnfcyiQjYNWWurhigp0lBnSSd8Qt2MoXItg35wL844 cArA== X-Gm-Message-State: AGRZ1gI642vCqe18lBAzvCOxSqgH2DvsnqBUSZ3uFLOexxndasN33PFS TF+WzC4fAsQWtIDzLw++ql8cGLNGtyS6j4rcvY8= X-Google-Smtp-Source: AJdET5d78RXMb6Tc3bFKlzEHxKNkpIuas1EoeNJjze+dDD3D0hQL5QCX4ceTDZCvsHlc4nsWmgV8PTxGuTn9jJRP8Bk= X-Received: by 2002:a2e:320c:: with SMTP id y12-v6mr5902545ljy.163.1541108103630; Thu, 01 Nov 2018 14:35:03 -0700 (PDT) MIME-Version: 1.0 References: <154022748014.6890.5464777930050299508@ietfa.amsl.com> <6fb7824e-b24e-1b88-f8eb-3e8005906e1b@inet.tu-berlin.de> In-Reply-To: From: Spencer Dawkins at IETF Date: Thu, 1 Nov 2018 16:34:53 -0500 Message-ID: To: Christopher Wood Cc: "Falk, Aaron" , taps WG , Theresa Enghardt , draft-ietf-taps-transport-security@ietf.org Content-Type: multipart/alternative; boundary="00000000000013d5a00579a1310a" Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transport-security-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 21:35:08 -0000 --00000000000013d5a00579a1310a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Christopher, On Sat, Oct 27, 2018 at 12:08 AM Christopher Wood < christopherwood07@gmail.com> wrote: > Hi Aaron, > > On Fri, Oct 26, 2018 at 10:46 AM Aaron Falk wrote: > >> Dear Authors, >> >> We agreed at the last IETF that the authors would send a note when this >> draft was ready for SecDir review. Is it ready? Do you want to talk abou= t >> Theresa's comments in Bangkok first? >> > > It is not yet ready. We will send it to SecDir when that changes. I don= =E2=80=99t > think Theresa=E2=80=99s comments are blockers here. (I=E2=80=99ll spin a = new version with > her comments for submission when the tracker reopen.) > Given that TAPS meets fairly late on Wednesday, if you think there will be discussion that a SECDIR reviewer might benefit from, it is likely possible to let the secdir secretaries at https://datatracker.ietf.org/group/secdir/about/ know that a request for early review will be coming, so that a reviewer could be identified early enough to be present. If that won't be a helpful discussion for a reviewer to listen to, of course, no need. Do the right thing :-) Spencer > Best, > Chris > > >> --aaron >> >> On 26 Oct 2018, at 5:15, Theresa Enghardt wrote: >> >> Dear TAPS, >> >> having shepherded the minset draft, and, in the process, having seen a >> lot of discussion around security, where we mostly pointed to the >> security survey draft, I gave this draft another read in the current >> version, with a focus on Section 5. >> >> Thanks for the update, this document was a good read. >> >> However, I have some comments, which I'm sharing now rather than later, >> just in case there's anything which is better discussed in-person in >> Bangkok. >> >> >> Right now, the abstract states that this document is a survey of >> security protocols. I suggest to add text saying that the document also >> provides a minimal set of security features. Essentially, this document >> and minset together cover the "minimum requirements of a secure >> transport system". >> >> >> In Section 5, the document groups security features into mandatory and >> optional features, and states their transport dependency and application >> dependency. Application dependency, for me, relates to whether a feature >> is "functional", "optimizing", or "automatable" (in minset terminology). >> For example, if there is no application dependency, the feature is >> "automatable" and does not have to be exposed to the application. In >> contrast, a "function" feature needs to be exposed to the application. >> >> In Section 5.1, I am missing transport dependency and application >> dependency for the mandatory transport features. For example, I would be >> interested to know what is the minimum that the transport system needs >> to expose to the application for public-key based authentication? >> >> In Section 5.1, what is "unilateral responder authentication", which I >> haven't found in other places in the document under this name? >> >> In Section 5.2, "Session caching and management" has no application >> dependency. However, later in Section 6.1, we do expose Session Cache >> Management to the application. My interpretation is that this is just an >> "optimizing" feature, which is why there is no application dependency, >> but it is still useful to expose. It might help to make this explicit in >> the text. >> >> In Section 5, do we want to mention any security features related to >> integrity protection? >> >> >> As far as I can see, none of the protocols we survey provide any >> features explicitly providing privacy. Maybe this is worth highlighting >> in the Security considerations section, beyond saying that no claims of >> privacy properties are made. >> >> >> Finally, I would be in favor of asking for a Secdir early review to make >> sure we're not missing anything in the survey. >> >> >> Thank you again for this draft. I really appreciate that we're >> discussing transport security features in this way. >> >> >> Best, >> Theresa >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >> > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > --00000000000013d5a00579a1310a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Christopher,=C2=A0

On Sat, Oct 27, 2018 at 12:08 AM Christop= her Wood <christopherwood= 07@gmail.com> wrote:
Hi Aaron,

On Fri, Oct 26, 2018 at 10:46 AM Aaron Fa= lk <aafalk@akamai= .com> wrote:

Dear Authors,

We agreed at the last IETF that the authors would send a no= te when this draft was ready for SecDir review. Is it ready? Do you want = to talk about Theresa's comments in Bangkok first?


It is not yet ready. We wil= l send it to SecDir when that changes. I don=E2=80=99t think Theresa=E2=80= =99s comments are blockers here. (I=E2=80=99ll spin a new version with her = comments for submission when the tracker reopen.)

Given that TAPS meets fairly late on Wednesday, if= you think there will be discussion that a SECDIR reviewer might benefit fr= om, it is likely possible to let the secdir secretaries at=C2=A0https://datatracker.ietf.= org/group/secdir/about/ know that a request for early review will be co= ming, so that a reviewer could be identified early enough to be present.=C2= =A0

If that won't be a helpful discussion for = a reviewer to listen to, of course, no need. Do the right thing :-)

Spencer
=C2=A0
Be= st,
Chris


--aaron

On 26 Oct 2018, at 5:15, Theresa Enghardt wrote:

Dear TAPS,

having shepherded the minset draft, and, in the process, having seen a
lot of discussion around security, where we mostly pointed to the
security survey draft, I gave this draft another read in the current
version, with a focus on Section 5.

Thanks for the update, this document was a good read.

However, I have some comments, which I'm sharing now rather than later,=
just in case there's anything which is better discussed in-person in Bangkok.


Right now, the abstract states that this document is a survey of
security protocols. I suggest to add text saying that the document also
provides a minimal set of security features. Essentially, this document
and minset together cover the "minimum requirements of a secure
transport system".


In Section 5, the document groups security features into mandatory and
optional features, and states their transport dependency and application dependency. Application dependency, for me, relates to whether a feature is "functional", "optimizing", or "automatable&quo= t; (in minset terminology).
For example, if there is no application dependency, the feature is
"automatable" and does not have to be exposed to the application.= In
contrast, a "function" feature needs to be exposed to the applica= tion.

In Section 5.1, I am missing transport dependency and application
dependency for the mandatory transport features. For example, I would be interested to know what is the minimum that the transport system needs
to expose to the application for public-key based authentication?

In Section 5.1, what is "unilateral responder authentication", wh= ich I
haven't found in other places in the document under this name?

In Section 5.2, "Session caching and management" has no applicati= on
dependency. However, later in Section 6.1, we do expose Session Cache
Management to the application. My interpretation is that this is just an "optimizing" feature, which is why there is no application depend= ency,
but it is still useful to expose. It might help to make this explicit in the text.

In Section 5, do we want to mention any security features related to
integrity protection?


As far as I can see, none of the protocols we survey provide any
features explicitly providing privacy. Maybe this is worth highlighting
in the Security considerations section, beyond saying that no claims of
privacy properties are made.


Finally, I would be in favor of asking for a Secdir early review to make sure we're not missing anything in the survey.


Thank you again for this draft. I really appreciate that we're
discussing transport security features in this way.


Best,
Theresa

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
--00000000000013d5a00579a1310a-- From nobody Sat Nov 3 17:34:12 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC97C128BCC for ; Sat, 3 Nov 2018 17:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 jsneicOD1Tis for ; Sat, 3 Nov 2018 17:34:08 -0700 (PDT) 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 2AB8012D4E9 for ; Sat, 3 Nov 2018 17:34:07 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id f12-v6so1514529plo.1 for ; Sat, 03 Nov 2018 17:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=vfoKi0xnV4HI0S5bUUDWFBCCJMn92fiQfDNCbyOUEpc=; b=Y8KIsj49pVBLV1vBJqS/rK8Db2ybC/BA69ppNHqZ90Co8nKpH18PIpd3aTas5NaR+n KsiLvII0FAr/3Qy4bgx7aKAC7oOuGJAGtWQBtbif/hIUsCfkOqRiC1oIyWenxvUEhY/v 4/jlMSGF5dP/jwVgzBfar9wGcheYZ1CWFY/HKffNcscHXY4gDFzUQ0aU//qUHqOPtb9O ziE1gQa2n5vQul4wwBlMLigaAj2hYT5jhEJyD1+ZpMCq10szW9Bx97FMjCk4Wn756N+p hcHQCLm8zDBWGqXlwcxcq+sfacBFxziq5mvVWic7FH/ljkKBFVz9WZzYZGlj017f/QS/ sjaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=vfoKi0xnV4HI0S5bUUDWFBCCJMn92fiQfDNCbyOUEpc=; b=IhFxk5OWeWCFmVa7C+5bOHKWq7hjpegGUxWys5Z8LD1KJWW0xvC2OzTTJMXNuaH/Fj uNkSVja974I3JulULcD4O8LoZBTWa4CJefpkk4M1TVt2SDqI5VHx1t1SmbS1Q9uCmJoM /5nf6o/UuU9OLPc2kubRpYj70onGAT7jybgh+4QI2h3z3LYVcq0pPUy/0c2MQwvr7aPF 8beetxcfv7HOYLEbRv9IBxTq9KYsOpnDU5WkAkwbEhNrUJm2/tQ1WQBe2sjhmTX3Yj1b nP7OUrFXGEztiKZ0vgx3St1sS5VmeNP4VnOhueDWB6h06hUDDDuh41sQx/zbq2JeaEB1 QL5g== X-Gm-Message-State: AGRZ1gIHJyOCknLpsKEdnk7dR91urgyQfNG6z5q2Mg4Q64Sj4Y4GVZvR aIYFfECNx1JnfQOdXaRER8Rn9qGS X-Google-Smtp-Source: AJdET5cDt5tFbF80cEFONVRd1so1T4YngVOKlaZ6gKsGBBkueCpgFIfzMm25NuvMwahnC1O5+0Gc0g== X-Received: by 2002:a17:902:404:: with SMTP id 4-v6mr17302498ple.331.1541291646478; Sat, 03 Nov 2018 17:34:06 -0700 (PDT) Received: from [31.133.146.108] ([2001:67c:1232:144:18b9:d957:a87e:caee]) by smtp.gmail.com with ESMTPSA id u76-v6sm26945122pfa.176.2018.11.03.17.34.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Nov 2018 17:34:05 -0700 (PDT) From: "Christopher Wood" To: "Theresa Enghardt" Cc: taps@ietf.org Date: Sun, 04 Nov 2018 07:33:35 +0700 X-Mailer: MailMate (1.12r5523) Message-ID: In-Reply-To: <302b8870-2473-8ae3-b196-7c62850c97c1@inet.tu-berlin.de> References: <154022748014.6890.5464777930050299508@ietfa.amsl.com> <6fb7824e-b24e-1b88-f8eb-3e8005906e1b@inet.tu-berlin.de> <302b8870-2473-8ae3-b196-7c62850c97c1@inet.tu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transport-security-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2018 00:34:11 -0000 Hi Theresa, Apologies for the delayed response. Please see inline below. On 27 Oct 2018, at 1:03, Theresa Enghardt wrote: > Hi Chris, > > I'm replying to your questions inline: > > On 27.10.2018 07:05, Christopher Wood wrote: >> >> >> In Section 5, the document groups security features into >> mandatory and >> optional features, and states their transport dependency and >> application >> dependency. Application dependency, for me, relates to whether a >> feature >> is "functional", "optimizing", or "automatable" (in minset >> terminology). >> For example, if there is no application dependency, the feature >> is >> "automatable" and does not have to be exposed to the application. >> In >> contrast, a "function" feature needs to be exposed to the >> application. >> >> >> What specifically do you think should change here? > > I suggest to define "application dependency" at the beginning of > Section > 5 -- it states what the application needs to know about the security > feature for it to work, right? Is the application knowing about the > feature always mandatory, or is this sometimes optional? Thanks for clarifying. I addressed this in the following PR: https://github.com/mami-project/draft-pauly-transport-security/pull/46/ > > Additionally, it might be useful to define what we mean by "transport > dependency". If this means that a security feature can only be > provided > when a certain transport feature is in place, then I'm not sure I > understand the transport dependency of "Source validation". Does this > mean that source validation only works with streams? Or does it work > differently depending on whether we have streams or datagrams? Indeed, the transport dependencies as written are not really clear. For source validation, the intent was to capture that this feature is only “available” (and useful) for connectionless transports. I ended up removing them in the PR above since, upon reflection, they seem to only add noise. > >> >> In Section 5.1, I am missing transport dependency and application >> dependency for the mandatory transport features. For example, I >> would be >> interested to know what is the minimum that the transport system >> needs >> to expose to the application for public-key based authentication? >> >> >> The mandatory features are those which must be provided regardless of >> the transport features. Thus, we list no transport dependencies. > > I see, and I think it would help me to reduce confusion to clarify > this > in the document. > > Are there any application dependencies for mandatory transport > features? > For example, I would expect at least public-key authentication and > pre-shared key support to be application-dependent. Fair point. Upon reflection it seems that the PSK feature should certainly not be mandatory for a security protocol, since (a) it’s not supported by all surveyed protocols and (b) it necessarily requires application input. Most modern operating systems have a default trust store which aids in certificate-based authentication, so I think it’s fine to omit any application dependency there. I updated the relevant text in the PR listed above. > >> >> >> In Section 5, do we want to mention any security features related >> to >> integrity protection? >> >> >> No, I don’t think so. What would be the purpose? > > For example, "Record (channel or datagram) confidentiality and > integrity" is defined as a security feature in Section 3, but then not > mentioned in Section 5 at all. This surprises me as a reader, I would > have expected it to be listed as a mandatory feature. > Perhaps it is reflected as "segment or datagram encryption and > authentication", which was actually the definition of "Record (channel > or datagram) confidentiality and integrity" given in Section 3, but > then > I'm confused about the change in terminology. This is another instance of terminology mismatch that I corrected in the PR above. Indeed, the first mandatory feature listed in -03 as “Segment or datagram encryption and authentication” is meant to be the same thing. > > As another example: "Optional record integrity" shows up in Section 3 > but not in Section 5. > > If Section 5 is just a subset of the security features listed in > Section > 3, I would appreciate some text in Section 5 to explain why these > features were chosen and not others. This is another oversight :-) I hope the PR above clears this up. > >> As far as I can see, none of the protocols we survey provide any >> features explicitly providing privacy. Maybe this is worth >> highlighting >> in the Security considerations section, beyond saying that no >> claims of >> privacy properties are made. >> >> >> This is a tough one. Depending on one’s level of pessimism, none of >> these protocols provide much in the way of privacy. However, in the >> case of TLS, we often think of privacy as confidentiality of data >> involved. Information is often leaked in other ways, e.g., via the >> SNI. It all boils down to your definition of privacy, of which we >> have >> no formal definition. Thus, I’m hesitant to say more than, e.g., >> “we >> do not consider privacy aspects of security protocols.” > > I understand, but I would also find it very interesting to at least > mention, e.g., (reduction of) information leakage as an aspect related > to privacy. I'm not sure it could be formalized as a security > features, > given the lack of formal definition of privacy. Noted. I filed this PR: https://github.com/mami-project/draft-pauly-transport-security/pull/45 > > > Thanks, and thanks for the discussion! My pleasure! Thank you again for the comments and feedback. Best, Chris From nobody Sat Nov 3 19:35:11 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D273812F1A6; Sat, 3 Nov 2018 19:35:09 -0700 (PDT) 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_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 50eLcRHB-kT8; Sat, 3 Nov 2018 19:35:07 -0700 (PDT) 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 DA89112F1A5; Sat, 3 Nov 2018 19:35:06 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id u6-v6so5002425ljd.1; Sat, 03 Nov 2018 19:35:06 -0700 (PDT) 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=iNJEnZkvV2SUt3pe1Qu4TrfwwC5Jvk4j0y6RK8QdPK8=; b=BM1uu2zUX2cL/QVJaElgYxutW1AnRFRiAx1UEi2E49x5NXQTRL1a/VJwN1nWFBfSVe fRQ7u63t9AZ+ReZOIkdHBNGbfT88mGhz40pquL+r++6yvWMc9Rv+ms1anOzqbrgxaK2w +RfQ2wQX7Ao+Tgi8Qo68BbHElasHRtuitzSKyslGb1Qui0q/5FiOaunplHrLPjuglukI 3SirmG37lTNv+d8H+6vW463Snd6DZ8mr/oOZ+4o05TavJRyCvF6eZ7Ba3sZhvw1F3kjz x2V1p7iAPL8bA/RN1HImQdNgXMcmK1VA70TUdIVsgPfPwL881Z1bY4dE/cHIJ5wX72PY RYuQ== 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=iNJEnZkvV2SUt3pe1Qu4TrfwwC5Jvk4j0y6RK8QdPK8=; b=bScAsJVIbWdn/KVRZJM2iABxNyPMOyOtwEyqTPRmiD/+UV70bxtwt8qh6dwZQnJ+Mr gyfhftd4G5TOtiSw9QmdKKHg1WgLcQLH3QmUSR7Q4Ltwn4gZoUXD7k1avw978x0U6vhk LEX+akaFarbnZWYTuvSxUQ/uSZaAn83INinL6ffq7kKareW5jUuzbBbvtCRpwq71zll+ m0wUfMZJucRPVEyP2DNoyVoXj37NyTANsyOIQTuHEEWIZoy3ni1ALeQwcHjNfUVjMq6u Jz85/t9x5T6XP0RuOrzPlIqgVHRFt6lAY3n7hsTG5aq4Q2C9ZvdD8vkZW6OgjWzJoJ+O Eo+g== X-Gm-Message-State: AGRZ1gIkL5QOrQsb2XABnP/KBtBM7sOPrsy5Qt3EpB2G6qXic3FJehlg HRPUAfMrGlS12cNrB7/p8qgL0r5RLIeZzoz4quw= X-Google-Smtp-Source: AJdET5fxNT/R1FfS5i7U1PSt6Ob8iEywK83KjRzQfmUSEpOi+iBnOZQG6g0HUzu2lEA+iGsFhddX3uFwa6rWZBrTmM4= X-Received: by 2002:a2e:851a:: with SMTP id j26-v6mr1060626lji.163.1541298904637; Sat, 03 Nov 2018 19:35:04 -0700 (PDT) MIME-Version: 1.0 References: <154022748014.6890.5464777930050299508@ietfa.amsl.com> <6fb7824e-b24e-1b88-f8eb-3e8005906e1b@inet.tu-berlin.de> In-Reply-To: From: Spencer Dawkins at IETF Date: Sun, 4 Nov 2018 09:34:53 +0700 Message-ID: To: Christopher Wood Cc: "Falk, Aaron" , taps WG , Theresa Enghardt , draft-ietf-taps-transport-security@ietf.org Content-Type: multipart/alternative; boundary="000000000000b426e60579cd9d1a" Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transport-security-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2018 02:35:10 -0000 --000000000000b426e60579cd9d1a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just following up ... On Fri, Nov 2, 2018 at 4:34 AM Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, Christopher, > > On Sat, Oct 27, 2018 at 12:08 AM Christopher Wood < > christopherwood07@gmail.com> wrote: > >> Hi Aaron, >> >> On Fri, Oct 26, 2018 at 10:46 AM Aaron Falk wrote: >> >>> Dear Authors, >>> >>> We agreed at the last IETF that the authors would send a note when this >>> draft was ready for SecDir review. Is it ready? Do you want to talk abo= ut >>> Theresa's comments in Bangkok first? >>> >> >> It is not yet ready. We will send it to SecDir when that changes. I don= =E2=80=99t >> think Theresa=E2=80=99s comments are blockers here. (I=E2=80=99ll spin a= new version with >> her comments for submission when the tracker reopen.) >> > I spoke to Tero, who is the SecDir secretary, and he told me that they get requests for early SecDir review that say "this document isn't ready for a reviewer to look at all of it, but what we think is stable, is Section Foo, on Bar, and we'd like for you to look at that" (or, "we finished everything except Section Mumble on Fratz, so you don't need to look at that"). He's OK with assigning those reviews, and providing those directions. So, there's that possibility as well. Spencer > Given that TAPS meets fairly late on Wednesday, if you think there will b= e > discussion that a SECDIR reviewer might benefit from, it is likely possib= le > to let the secdir secretaries at > https://datatracker.ietf.org/group/secdir/about/ know that a request for > early review will be coming, so that a reviewer could be identified early > enough to be present. > > If that won't be a helpful discussion for a reviewer to listen to, of > course, no need. Do the right thing :-) > > Spencer > > >> Best, >> Chris >> >> >>> --aaron >>> >>> On 26 Oct 2018, at 5:15, Theresa Enghardt wrote: >>> >>> Dear TAPS, >>> >>> having shepherded the minset draft, and, in the process, having seen a >>> lot of discussion around security, where we mostly pointed to the >>> security survey draft, I gave this draft another read in the current >>> version, with a focus on Section 5. >>> >>> Thanks for the update, this document was a good read. >>> >>> However, I have some comments, which I'm sharing now rather than later, >>> just in case there's anything which is better discussed in-person in >>> Bangkok. >>> >>> >>> Right now, the abstract states that this document is a survey of >>> security protocols. I suggest to add text saying that the document also >>> provides a minimal set of security features. Essentially, this document >>> and minset together cover the "minimum requirements of a secure >>> transport system". >>> >>> >>> In Section 5, the document groups security features into mandatory and >>> optional features, and states their transport dependency and applicatio= n >>> dependency. Application dependency, for me, relates to whether a featur= e >>> is "functional", "optimizing", or "automatable" (in minset terminology)= . >>> For example, if there is no application dependency, the feature is >>> "automatable" and does not have to be exposed to the application. In >>> contrast, a "function" feature needs to be exposed to the application. >>> >>> In Section 5.1, I am missing transport dependency and application >>> dependency for the mandatory transport features. For example, I would b= e >>> interested to know what is the minimum that the transport system needs >>> to expose to the application for public-key based authentication? >>> >>> In Section 5.1, what is "unilateral responder authentication", which I >>> haven't found in other places in the document under this name? >>> >>> In Section 5.2, "Session caching and management" has no application >>> dependency. However, later in Section 6.1, we do expose Session Cache >>> Management to the application. My interpretation is that this is just a= n >>> "optimizing" feature, which is why there is no application dependency, >>> but it is still useful to expose. It might help to make this explicit i= n >>> the text. >>> >>> In Section 5, do we want to mention any security features related to >>> integrity protection? >>> >>> >>> As far as I can see, none of the protocols we survey provide any >>> features explicitly providing privacy. Maybe this is worth highlighting >>> in the Security considerations section, beyond saying that no claims of >>> privacy properties are made. >>> >>> >>> Finally, I would be in favor of asking for a Secdir early review to mak= e >>> sure we're not missing anything in the survey. >>> >>> >>> Thank you again for this draft. I really appreciate that we're >>> discussing transport security features in this way. >>> >>> >>> Best, >>> Theresa >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >> >> --000000000000b426e60579cd9d1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just following up ...=C2=A0

On Fri, Nov 2, 2018 at 4:34 AM Spencer Dawkins at IET= F <spencerdawkins.ietf@= gmail.com> wrote:
Hi, Christopher,=C2=A0

On Sat, Oct 27, 2018 at 12:08 AM Christopher Wood= <chris= topherwood07@gmail.com> wrote:
Hi Aaron,

=
On Fri, Oct 26, 2018 at 10:46 A= M Aaron Falk <aaf= alk@akamai.com> wrote:

Dear Authors,

We agreed at the last IETF that the authors would send a no= te when this draft was ready for SecDir review. Is it ready? Do you want = to talk about Theresa's comments in Bangkok first?


It is not yet ready. We wil= l send it to SecDir when that changes. I don=E2=80=99t think Theresa=E2=80= =99s comments are blockers here. (I=E2=80=99ll spin a new version with her = comments for submission when the tracker reopen.)

I spoke to Te= ro, who is the SecDir secretary, and he told me that they get requests for = early SecDir review that say "this document isn't ready for a revi= ewer to look at all of it, but what we think is stable, is Section Foo, on = Bar, and we'd like for you to look at that" (or, "we finished= everything except Section Mumble on Fratz, so you don't need to look a= t that"). He's OK with assigning those reviews, and providing thos= e directions.=C2=A0

So, there's that possibili= ty as well.=C2=A0

Spencer
=C2=A0
Given that TAPS meets fairly late on Wednesday, if yo= u think there will be discussion that a SECDIR reviewer might benefit from,= it is likely possible to let the secdir secretaries at=C2=A0https://da= tatracker.ietf.org/group/secdir/about/ know that a request for early re= view will be coming, so that a reviewer could be identified early enough to= be present.=C2=A0

If that won't be a help= ful discussion for a reviewer to listen to, of course, no need. Do the righ= t thing :-)

Spencer
=C2=A0
<= div dir=3D"auto">Best,
Chris
=

<= /div>

--aaron

On 26 Oct 2018, at 5:15, Theresa Enghardt wrote:

Dear TAPS,

having shepherded the minset draft, and, in the process, having seen a
lot of discussion around security, where we mostly pointed to the
security survey draft, I gave this draft another read in the current
version, with a focus on Section 5.

Thanks for the update, this document was a good read.

However, I have some comments, which I'm sharing now rather than later,=
just in case there's anything which is better discussed in-person in Bangkok.


Right now, the abstract states that this document is a survey of
security protocols. I suggest to add text saying that the document also
provides a minimal set of security features. Essentially, this document
and minset together cover the "minimum requirements of a secure
transport system".


In Section 5, the document groups security features into mandatory and
optional features, and states their transport dependency and application dependency. Application dependency, for me, relates to whether a feature is "functional", "optimizing", or "automatable&quo= t; (in minset terminology).
For example, if there is no application dependency, the feature is
"automatable" and does not have to be exposed to the application.= In
contrast, a "function" feature needs to be exposed to the applica= tion.

In Section 5.1, I am missing transport dependency and application
dependency for the mandatory transport features. For example, I would be interested to know what is the minimum that the transport system needs
to expose to the application for public-key based authentication?

In Section 5.1, what is "unilateral responder authentication", wh= ich I
haven't found in other places in the document under this name?

In Section 5.2, "Session caching and management" has no applicati= on
dependency. However, later in Section 6.1, we do expose Session Cache
Management to the application. My interpretation is that this is just an "optimizing" feature, which is why there is no application depend= ency,
but it is still useful to expose. It might help to make this explicit in the text.

In Section 5, do we want to mention any security features related to
integrity protection?


As far as I can see, none of the protocols we survey provide any
features explicitly providing privacy. Maybe this is worth highlighting
in the Security considerations section, beyond saying that no claims of
privacy properties are made.


Finally, I would be in favor of asking for a Secdir early review to make sure we're not missing anything in the survey.


Thank you again for this draft. I really appreciate that we're
discussing transport security features in this way.


Best,
Theresa

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

--000000000000b426e60579cd9d1a-- From nobody Sun Nov 4 16:19:49 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291BD130DE8; Sun, 4 Nov 2018 16:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 (2048-bit key) header.d=apple.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 STKxlEx87DnV; Sun, 4 Nov 2018 16:19:46 -0800 (PST) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (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 CB335130DD2; Sun, 4 Nov 2018 16:19:46 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.22/8.16.0.22) with SMTP id wA501v8g043560; Sun, 4 Nov 2018 16:19:46 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : from : subject : message-id : date : cc : to; s=20180706; bh=ihHB94T+RYxYUQl2XCrgZ3S2dCq0OSXk36DaaGU3Lew=; b=Snk2BGngAq/KC47rp2XITz0TOdzPB/LDwu2joJXzXKsgS+hftjkDJzOrjnUk9crVcwDA Cq+2FlIyD/0tBg3QSOCr8hLghN2MjQ4s2KOaUGX90SsRpuxykZjcJTEbjjur3ey2JodN v3derIwxZQVt8QtEX/SEripKeU0E5laTmWRPcBNa5eiWsi6QsrtsrHoy+3WLYPmlWN35 /P0YdRVIYqFgZ4MhR55SjW4Db+uKyWOgjtdwJBpkZVz0+LaiKBW1hIrH7D38+RN3Opyb ovjr3teX+D3oToO4/La7Lbt2/CR9t+kpSjCTECkq41TMLTaOFG9m9Wui/V+DvGMYIOBf Sw== Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2nh88mre8n-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 04 Nov 2018 16:19:46 -0800 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ma1-mmpp-sz11.apple.com (ma1-mmpp-sz11.apple.com [17.171.128.33]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PHP00BGJ28W2R20@mr2-mtap-s03.rno.apple.com>; Sun, 04 Nov 2018 16:19:45 -0800 (PST) Received: from process_viserion-daemon.ma1-mmpp-sz11.apple.com by ma1-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PHP00N001CW0Y00@ma1-mmpp-sz11.apple.com>; Sun, 04 Nov 2018 16:19:44 -0800 (PST) X-Va-A: X-Va-T-CD: 4fc7fc2a6ed6f60e40832e4273217f25 X-Va-E-CD: 5696625a64fb3e3ab7bb9ce5f5e748e0 X-Va-R-CD: 913bf984ad5e215a2d7f0ecaaaef9567 X-Va-CD: 0 X-Va-ID: 7de0bf90-693b-49af-b46b-4e6408a5fb45 X-V-A: X-V-T-CD: ad9399c1dd33874217dd92d101f0d74f X-V-E-CD: 5696625a64fb3e3ab7bb9ce5f5e748e0 X-V-R-CD: 913bf984ad5e215a2d7f0ecaaaef9567 X-V-CD: 0 X-V-ID: b73e2937-f19d-448e-9242-ee27b555b46e Received: from process_milters-daemon.ma1-mmpp-sz11.apple.com by ma1-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PHP004001MGK300@ma1-mmpp-sz11.apple.com>; Sun, 04 Nov 2018 16:19:44 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-11-04_17:,, signatures=0 Received: from [17.234.143.171] (unknown [17.234.143.171]) by ma1-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PHP00BEB28QQW20@ma1-mmpp-sz11.apple.com>; Sun, 04 Nov 2018 16:19:44 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Mon, 05 Nov 2018 07:19:35 +0700 Cc: TAPS WG IETF list To: QUIC WG X-Mailer: Apple Mail (2.3445.100.36) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-04_17:, , signatures=0 Archived-At: Subject: [Taps] Discussing QUIC API mappings in TAPS X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 00:19:48 -0000 Hello QUIC, I wanted to highlight to the working group that this week we'll be having a discussion around transport API mappings for QUIC in the Transport Services (TAPS) working group. The goal is to ensure that applications are able to smoothly migrate to QUIC from other protocols, even when not using HTTP over QUIC. If you're interested in this topic, please join us and chime in! Wednesday, November 7 1540-1710 Afternoon Session II Transport Services WG Room: Meeting 2 Thanks, Tommy From nobody Sun Nov 4 16:20:08 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159EE130DD2; Sun, 4 Nov 2018 16:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 (2048-bit key) header.d=apple.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 C50MjzapoU73; Sun, 4 Nov 2018 16:19:47 -0800 (PST) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 B0CCF130E01; Sun, 4 Nov 2018 16:19:47 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.22/8.16.0.22) with SMTP id wA501xCd024738; Sun, 4 Nov 2018 16:19:46 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : from : subject : message-id : date : cc : to; s=20180706; bh=gkL4CMVPiZWKRiHnhTR/c4jXteFPT04uGfGofkSHqPA=; b=wl7rExabYmj8aYwK9D2hmUuvcAbIChEkWjQAu83L+bvaK1tupdPxQafy3USmRMevPccU eo3Ha6wa7OVfPqz7yaT3FRZXWR0H+HVMBdKSQOImioLW+iTdKAZzk5CTLPigqZlqGCcd iq8CB5sUcpp+J4HKm6ZRleqWbMgorcWlvKQs48xGvgwXp1RauMRJ3Ar0ZtCAJgNNDd03 14AB7uHKwVowa5T+HVgb0k4pJLK4IrrAb4P3xCVqyWHqeq0a7sjXC7MJc2O/S7yAEfep M0Skj0HJ1ERkBn/b6Qo2qM7Ti17nrLlgZKx6+DoxjI+iofaCKSUZgeiOcEx7DoeQiaAL HA== Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2nhab730nh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 04 Nov 2018 16:19:46 -0800 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ma1-mmpp-sz11.apple.com (ma1-mmpp-sz11.apple.com [17.171.128.33]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PHP00GUL28YPR30@ma1-mtap-s01.corp.apple.com>; Sun, 04 Nov 2018 16:19:46 -0800 (PST) Received: from process_viserion-daemon.ma1-mmpp-sz11.apple.com by ma1-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PHP00N001CW0Y00@ma1-mmpp-sz11.apple.com>; Sun, 04 Nov 2018 16:19:46 -0800 (PST) X-Va-A: X-Va-T-CD: 8f06955753c9914ccee2ead7b013056e X-Va-E-CD: 3aff4d1e31abfdf3d4431ab8fb3cfe87 X-Va-R-CD: b7ef2668a01b66eb24691e801e63c290 X-Va-CD: 0 X-Va-ID: 64d0c7fc-3806-4743-ba75-8d66e52c8010 X-V-A: X-V-T-CD: 8f06955753c9914ccee2ead7b013056e X-V-E-CD: 3aff4d1e31abfdf3d4431ab8fb3cfe87 X-V-R-CD: b7ef2668a01b66eb24691e801e63c290 X-V-CD: 0 X-V-ID: a541b8fd-c7d7-49a5-8785-919b25dc6ef4 Received: from process_milters-daemon.ma1-mmpp-sz11.apple.com by ma1-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PHP004001MGK300@ma1-mmpp-sz11.apple.com>; Sun, 04 Nov 2018 16:19:46 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-11-04_17:,, signatures=0 Received: from [17.234.143.171] (unknown [17.234.143.171]) by ma1-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PHP00BEB28QQW20@ma1-mmpp-sz11.apple.com>; Sun, 04 Nov 2018 16:19:46 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <9FB4DA1B-B45C-41A0-85FF-A7E09199F380@apple.com> Date: Mon, 05 Nov 2018 07:19:36 +0700 Cc: TAPS WG IETF list To: rtcweb@ietf.org X-Mailer: Apple Mail (2.3445.100.36) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-04_17:, , signatures=0 Archived-At: Subject: [Taps] Discussing WebRTC API mappings in TAPS X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 00:19:49 -0000 Hello rtcweb, Based on recent proposals for WebRTC APIs to run over QUIC, the Transport Services (TAPS) working group will be spending some time this week looking at the usefulness and applicability of our flexible transport APIs for use in WebRTC. One of the main goals is providing an API surface that will work well across protocols and require minimal application effort to adopt, as well as being able to dynamically use newer protocols. We'd like to get input and feedback on how well such a model can serve the WebRTC use case. Please join us in our discussion if you're interested! Wednesday, November 7 1540-1710 Afternoon Session II Transport Services WG Room: Meeting 2 Thanks, Tommy From nobody Sun Nov 4 17:05:18 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A992C128CF2; Sun, 4 Nov 2018 17:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 LhBsi-Ex0ov2; Sun, 4 Nov 2018 17:05:16 -0800 (PST) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 E60AE128CB7; Sun, 4 Nov 2018 17:05:15 -0800 (PST) Received: by mail-it1-x133.google.com with SMTP id b7-v6so10469307itd.5; Sun, 04 Nov 2018 17:05:15 -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:content-transfer-encoding; bh=Rc3K4CpgK1/G+LZ9iDauwQNwQCBtPRQ3DjrtVhHwl5g=; b=kqvPb+66OOjAlI0wVGRJc4b2kAnoOYj9H2B5a2SNfJHzLV3MJLtlN1qpsPzuUnfrvY rpboVTY291uev4T0ATNYpiQeH47c/gZHc6rLZtk7hRKUYhOjDVGb5VLPh5qkw9ctYmiD wbWtyl7Qgd6AVnQhHOootSsADb/OAZ2JJqYcsln/VPImlWa0g2JZcRIFxpcayWds+Ct4 FaMmX6vIEWHBXjhq3WVO6YY4b5Ud+I//mM6d+uNJfT6iDdrAG6TKLW/JfBU51ybGCBmS qWa2dbr09fwKSnjW70Ztbbtkgz59PLzB2dcoThjr2ZhZ3xKwju/pt8bA7n+RCGGUMvZd sSvQ== 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=Rc3K4CpgK1/G+LZ9iDauwQNwQCBtPRQ3DjrtVhHwl5g=; b=XY7onXtP6iFXiB9Oos6A4yHWJeFAmEimT+5gKzH4pDL4iWjClM9yXU3vNcm54X0ZHd 3UOTXd2TdZG+l4k3fNaIv6VI/h2bQCGAyyZFe/2Lv7ZtkmNsupxxhzCt/outMb3UoHo5 1b5/LZTZRaTm7hy0ko++55/G4S3YhqrgGeww55/1dtRxzY/MUQTvViC+lBMv7+vcOVQ1 M3JW5+1I/l4ItSJwWWMUxI9qgW3c8fkj7W7bMatovwiaSJcv44fSw+f/eUboARanpivE /l/smdHUaLHyZOJJUZqur3aQTZsUdZ1InlCTHQa38FeEMQJvuvUle1946Q6tRr9KE5Fd F+xg== X-Gm-Message-State: AGRZ1gKBlX0Oz/nUoULFaWhDRHtvkve0zzpnz5Rc2JICjVfZ0MOY+1y+ Y9LiTUDUIaJqFji60wOIekXd/f05toDlvZxYZzQ= X-Google-Smtp-Source: AJdET5c4lkgfD08xUblhE32woJKR2UzHKjQvOsvviiRpfQs5Vellz63wBY96LwYA3kmcifkKxVI51NjI8RrydyStptA= X-Received: by 2002:a02:3f19:: with SMTP id d25-v6mr18774798jaa.101.1541379915114; Sun, 04 Nov 2018 17:05:15 -0800 (PST) MIME-Version: 1.0 References: <154022748014.6890.5464777930050299508@ietfa.amsl.com> <6fb7824e-b24e-1b88-f8eb-3e8005906e1b@inet.tu-berlin.de> In-Reply-To: From: Christopher Wood Date: Mon, 5 Nov 2018 01:05:01 +0000 Message-ID: To: Spencer Dawkins at IETF Cc: Aaron Falk , taps WG , Theresa Enghardt , draft-ietf-taps-transport-security@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transport-security-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 01:05:18 -0000 On Sun, Nov 4, 2018 at 2:35 AM Spencer Dawkins at IETF wrote: > > Just following up ... > > On Fri, Nov 2, 2018 at 4:34 AM Spencer Dawkins at IETF wrote: >> >> Hi, Christopher, >> >> On Sat, Oct 27, 2018 at 12:08 AM Christopher Wood wrote: >>> >>> Hi Aaron, >>> >>> On Fri, Oct 26, 2018 at 10:46 AM Aaron Falk wrote: >>>> >>>> Dear Authors, >>>> >>>> We agreed at the last IETF that the authors would send a note when thi= s draft was ready for SecDir review. Is it ready? Do you want to talk about= Theresa's comments in Bangkok first? >>> >>> >>> It is not yet ready. We will send it to SecDir when that changes. I don= =E2=80=99t think Theresa=E2=80=99s comments are blockers here. (I=E2=80=99l= l spin a new version with her comments for submission when the tracker reop= en.) > > > I spoke to Tero, who is the SecDir secretary, and he told me that they ge= t requests for early SecDir review that say "this document isn't ready for = a reviewer to look at all of it, but what we think is stable, is Section Fo= o, on Bar, and we'd like for you to look at that" (or, "we finished everyth= ing except Section Mumble on Fratz, so you don't need to look at that"). He= 's OK with assigning those reviews, and providing those directions. > > So, there's that possibility as well. Thanks, Spencer! We will kick things off this week. Best, Chris From nobody Sun Nov 4 18:30:59 2018 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2CD130EB0; Sun, 4 Nov 2018 18:30:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: taps@ietf.org Message-ID: <154138504762.31758.7957391593556294817@ietfa.amsl.com> Date: Sun, 04 Nov 2018 18:30:47 -0800 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-transport-security-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 02:30:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : A Survey of Transport Security Protocols Authors : Tommy Pauly Colin Perkins Kyle Rose Christopher A. Wood Filename : draft-ietf-taps-transport-security-04.txt Pages : 34 Date : 2018-11-04 Abstract: This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog transport services [RFC8095] by describing the interfaces required to add security protocols. It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and WireGuard. This survey is not limited to protocols developed within the scope or context of the IETF, and those included represent a superset of features a TAPS system may need to support. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-transport-security-04 https://datatracker.ietf.org/doc/html/draft-ietf-taps-transport-security-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transport-security-04 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 5 10:56:31 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C2C1294D7 for ; Mon, 5 Nov 2018 10:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 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_PASS=-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 iR63ITr_D7OB for ; Mon, 5 Nov 2018 10:56:19 -0800 (PST) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 2C3D8130E00 for ; Mon, 5 Nov 2018 10:56:19 -0800 (PST) Received: by mail-wm1-x32e.google.com with SMTP id p2-v6so9105134wmc.2 for ; Mon, 05 Nov 2018 10:56:19 -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=TBQbV3Emr6ioXpt4EodO1vtF0fsx2RYtF0ndtxbk4gw=; b=mJ2gOWFz3dny2IgXbZ2RbtPncyk7MfM+pwkcTBBf7vc5pgSBzGCkwvAPSfRQpW3bwJ 3al0n140OWCZZaufalzYMzdVxCMJPm4o22gsndwBEh1HIWB5DRZGfFTg3nBLO5G6TK3w gPYnwmQs1568H3ermWi+1gHgCNCZCkFOyzjj0uZn+enASRkZ7E3mvDVY+LXDAsmjZKZU pFDoLcvlII9cupXtPN1nCPJ45ZCsQG40bM9exeVxcFqhQsapBAaOynlkRNyhZ2sW9PND oYxFJ/CnUA4xOs8jwOeRco7dgkWRs9bc9tge02GTFr8wbPKvoK3EtHgfzCGNNQDV7FKP mpYw== 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=TBQbV3Emr6ioXpt4EodO1vtF0fsx2RYtF0ndtxbk4gw=; b=FS+MBIOiOilt09nz45rJCBe5NzlR1x/1sblfmQu+ylUarqJjbofj19j3kQjThwzYdU buw8pA/3gUg1YFe01q7PIABg+Wwis1AROBZ6jwvryKBe/94koBcuFjo47+aMzF+yNP0C o8oHZWF2z1VgOt9WL3bClAf2KWDLGeTIpPzEbdNCQzeOnjVWTcgzKn3+cFaOkrznkvRc e6tEjv3x5qtR/VJGJn6mHvGHbAVW/5Ectie1eFsukCCMAbxvpS7gX/Y/h6TqkudOtevW FmgXsT+tSfDMsqAO3yjMijBSEHwNBq9J+/aDmUhbMzYLvC5JSsswCe2sFCTMru811oya 0RMA== X-Gm-Message-State: AGRZ1gLW8NIw5Llw+61s2ufxSpqI1Btyufpdaok8FFKpsOMdvFnIiRPP IuGVTUHR981zmNmAAanqZHtq+yTf91QcR33TiRlcUg== X-Google-Smtp-Source: AJdET5evV0X0+0F5HdcrjUCVY275l7Ydy92XJSueuo48STTqtE2rWV3K4Bns7clMF2WX0PxRU//joSCf17P4wNnupLA= X-Received: by 2002:a1c:9f01:: with SMTP id i1-v6mr7066299wme.8.1541444176977; Mon, 05 Nov 2018 10:56:16 -0800 (PST) MIME-Version: 1.0 References: <9FB4DA1B-B45C-41A0-85FF-A7E09199F380@apple.com> In-Reply-To: <9FB4DA1B-B45C-41A0-85FF-A7E09199F380@apple.com> From: Peter Thatcher Date: Mon, 5 Nov 2018 10:56:04 -0800 Message-ID: To: Tommy Pauly Cc: rtcweb@ietf.org, TAPS WG IETF list Content-Type: multipart/alternative; boundary="0000000000009cf3e40579ef7024" Archived-At: Subject: Re: [Taps] [rtcweb] Discussing WebRTC API mappings in TAPS X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 18:56:22 -0000 --0000000000009cf3e40579ef7024 Content-Type: text/plain; charset="UTF-8" FYI, the rtcweb WG has not been involved in the discussion around the WebRTC API for QUIC. It's only been discussed in the W3C. Naturally, some people are in both groups, but as a group, this WG has not discussed QUIC before (as far as I know). It might make more sense to reach out to the W3C WebRTC WG. However, if you want to talk to people in person IETF 103 might be a good opportunity to find people. And since we're discussing TAPS and RTCWEB here, there is an area that the experience of the RTCWEB WG can probably help the TAPS WG: the use of ICE. I recently read through the TAPS documents and it seems that TAPS is attempting to make an API that includes the use of ICE (it's basically a superset of ICE, much like the combination the WebRTC protocols). In the context of the web, that can lead to some tricky issues. If you wish to extend TAPS to the web, one issue you will run into is the same that RTCWEB did around the IP privacy handling of ICE (and the subsequent use of mDNS). Another is consent freshness. There may be others that I can't recall. But you'll probably want to learn how the RTCWEB WG solved these problems (for some definition of solved :) rather than retreading them. On Sun, Nov 4, 2018 at 4:20 PM Tommy Pauly wrote: > Hello rtcweb, > > Based on recent proposals for WebRTC APIs to run over QUIC, the Transport > Services (TAPS) working group will be spending some time this week looking > at the usefulness and applicability of our flexible transport APIs for use > in WebRTC. One of the main goals is providing an API surface that will work > well across protocols and require minimal application effort to adopt, as > well as being able to dynamically use newer protocols. We'd like to get > input and feedback on how well such a model can serve the WebRTC use case. > > Please join us in our discussion if you're interested! > > Wednesday, November 7 > 1540-1710 Afternoon Session II > Transport Services WG > Room: Meeting 2 > > Thanks, > Tommy > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000009cf3e40579ef7024 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FYI, the rtcweb WG has not been involved in the discussion= around the WebRTC API for QUIC.=C2=A0 It's only been discussed in the = W3C.=C2=A0 Naturally, some people are in both groups, but as a group, this = WG has not discussed QUIC before (as far as I know).=C2=A0 It might make mo= re sense to reach out to the W3C WebRTC WG.=C2=A0 However, if you want to t= alk to people in person IETF 103 might be a good opportunity to find people= .=C2=A0

And since we're discussing TAPS and RTC= WEB here, there is an area that the experience of the RTCWEB WG can probabl= y help the TAPS WG: the use of ICE.=C2=A0 I recently read through the TAPS = documents and it seems that TAPS is attempting to make an API that includes= the use of ICE (it's basically a superset of ICE, much like the combin= ation the WebRTC protocols).=C2=A0 In the context of the web, that can lead= to some tricky issues.

If you wish to extend TAPS= to the web, one issue you will run into is the same that RTCWEB did around= the IP privacy handling of ICE (and the subsequent use of mDNS).=C2=A0 =C2= =A0 Another is consent freshness.=C2=A0 There may be others that I can'= t recall.=C2=A0 But you'll probably want to learn how the RTCWEB WG sol= ved these problems (for some definition of solved :) rather than retreading= them.=C2=A0=C2=A0


On Sun, Nov 4, 2018 at 4:20 PM Tommy Pauly <tpauly@apple.com> wrote:
Hello rtcweb,

Based on recent proposals for WebRTC APIs to run over QUIC, the Transport S= ervices (TAPS) working group will be spending some time this week looking a= t the usefulness and applicability of our flexible transport APIs for use i= n WebRTC. One of the main goals is providing an API surface that will work = well across protocols and require minimal application effort to adopt, as w= ell as being able to dynamically use newer protocols. We'd like to get = input and feedback on how well such a model can serve the WebRTC use case.<= br>
Please join us in our discussion if you're interested!

Wednesday, November 7
1540-1710=C2=A0 Afternoon Session II
Transport Services WG
Room: Meeting 2

Thanks,
Tommy

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000009cf3e40579ef7024-- From nobody Mon Nov 5 12:36:44 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818A7130DCA; Mon, 5 Nov 2018 12:36:41 -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, FREEMAIL_FROM=0.001, 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 (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 3f1lo5uFGBrQ; Mon, 5 Nov 2018 12:36:38 -0800 (PST) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 5DCD612D4E7; Mon, 5 Nov 2018 12:36:38 -0800 (PST) Received: by mail-ua1-x931.google.com with SMTP id v24so3691105uap.13; Mon, 05 Nov 2018 12:36: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=e3qkNPAZldqZuJyP5QktMvJhA5AQH9PNH+OdsYTG1/U=; b=bB4lE4aqI1bRcDOvE4iBKAF4DZrDaKBxqXF3BPJTEmshiJujPTvz1W3A5PpyIi5IdL q21W7SdD0K6m1t/Q3SfJ3s1DsPBRHBoxTNYmlHFKSvNNu95CFCK9q/RH/uSnCaSozeI3 wnCpbiew+mS2nlnQEUuc4O2K4N3MKJ+mw1MOOkUnP2Dqa97Kksrr8/0jF9EbDh1Kp483 hIP4uDwo1XRstxM8TnkfTTW2kCaU30GjYYJMCoS+DkMPtuBEePj6RLaCstnNi+6QyX7d sKZAJrF3oQKVpj0/BG9FJRZuiUz/usbVoMcZt7Pt9uIGMPe7pv32GaFH+rWySnKcqkcr tuxA== 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=e3qkNPAZldqZuJyP5QktMvJhA5AQH9PNH+OdsYTG1/U=; b=nc0Ks37UrsoT+SoPM9oqPCWNgpupkseKgPrV7zoRSs043G3rVHxlnPCRukcUuXnDO6 IIaO0JyFhnRiyz7MdTxnUlHA9/DlyUuXFDG8EJFORD2wU8D06PnOS4LaEgbJW37V11wJ ToQnjIb8ofRLgtb+DU/AzM1Mpr/RTCG0pQXTjXL/JkeL/pggHpVUya1HGdHcXzxxHpPu B9KyN8uk/p+Be+LQsenLpqExAM03HYPFsJOoyDSjUmBVCJsNh/KoGelvnT3jH54lZ/U/ uvLmoQrv4nO/XFEWjkS4bWmyJ+hUGj1dr69UYkdd5c2VLLNsxa6tJ9WICb0j2vqDjlMC 1T4Q== X-Gm-Message-State: AGRZ1gI5FO4aPELDJ6hYCCO+Jq5WeN/pnKsGtAap0cAGqTp7Qr/JPlgM 3uyzQ8CAcx64aw0yJNG9KCHsmSnGFoKQgefog4Q= X-Google-Smtp-Source: AJdET5cRpRS97bTDIhzcJZKkN9nXqUqXHv07yOyPepw5hXxPBZX6sV6XPXuP1mBfPlrGl8ZTg3vV2Q821TsAMSPui2s= X-Received: by 2002:ab0:465:: with SMTP id 92mr7761389uav.28.1541450197016; Mon, 05 Nov 2018 12:36:37 -0800 (PST) MIME-Version: 1.0 References: <9FB4DA1B-B45C-41A0-85FF-A7E09199F380@apple.com> In-Reply-To: From: Bernard Aboba Date: Mon, 5 Nov 2018 15:36:25 -0500 Message-ID: To: Peter Thatcher Cc: tpauly@apple.com, RTCWeb IETF , taps@ietf.org Content-Type: multipart/alternative; boundary="0000000000006eb1ac0579f0d70b" Archived-At: Subject: Re: [Taps] [rtcweb] Discussing WebRTC API mappings in TAPS X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 20:36:42 -0000 --0000000000006eb1ac0579f0d70b Content-Type: text/plain; charset="UTF-8" In terms of background, there are some things to understand about WebRTC-QUIC which may help provide context: 1. The current draft is focussed on peer-to-peer data exchange use cases, based on an RTCQuicTransport object (which models QUIC connections) and an RTCQuicStream object (which models QUIC streams). The RTCQuicTransport object takes after the RTCDtlsTransport object which was originally developed in the ORTC Community Group (see: http://draft.ortc.org) and later integrated in WebRTC (see: https://rawgit.com/w3c/webrtc-pc/master/webrtc.html), so it has been relatively stable. The RTCQuicStream object has undergone quite a few changes in order to evolve along with the IETF QUIC Transport draft (see: https://tools.ietf.org/html/draft-ietf-quic-transport ), and during the latest WEBRTC WG meetings, additional changes were discussed, in order to better align WebRTC-QUIC with the WHAT WG Streams API. On Mon, Nov 5, 2018 at 1:56 PM Peter Thatcher wrote: > FYI, the rtcweb WG has not been involved in the discussion around the > WebRTC API for QUIC. It's only been discussed in the W3C. Naturally, some > people are in both groups, but as a group, this WG has not discussed QUIC > before (as far as I know). It might make more sense to reach out to the > W3C WebRTC WG. However, if you want to talk to people in person IETF 103 > might be a good opportunity to find people.. > > And since we're discussing TAPS and RTCWEB here, there is an area that the > experience of the RTCWEB WG can probably help the TAPS WG: the use of ICE. > I recently read through the TAPS documents and it seems that TAPS is > attempting to make an API that includes the use of ICE (it's basically a > superset of ICE, much like the combination the WebRTC protocols). In the > context of the web, that can lead to some tricky issues. > > If you wish to extend TAPS to the web, one issue you will run into is the > same that RTCWEB did around the IP privacy handling of ICE (and the > subsequent use of mDNS). Another is consent freshness. There may be > others that I can't recall. But you'll probably want to learn how the > RTCWEB WG solved these problems (for some definition of solved :) rather > than retreading them. > > > On Sun, Nov 4, 2018 at 4:20 PM Tommy Pauly wrote: > >> Hello rtcweb, >> >> Based on recent proposals for WebRTC APIs to run over QUIC, the Transport >> Services (TAPS) working group will be spending some time this week looking >> at the usefulness and applicability of our flexible transport APIs for use >> in WebRTC. One of the main goals is providing an API surface that will work >> well across protocols and require minimal application effort to adopt, as >> well as being able to dynamically use newer protocols. We'd like to get >> input and feedback on how well such a model can serve the WebRTC use case. >> >> Please join us in our discussion if you're interested! >> >> Wednesday, November 7 >> 1540-1710 Afternoon Session II >> Transport Services WG >> Room: Meeting 2 >> >> Thanks, >> Tommy >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000006eb1ac0579f0d70b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In terms of background, = there are some things to understand about WebRTC-QUIC which may help provid= e context:

1. The current = draft is focussed on peer-to-peer data exchange use cases, based on an RTCQ= uicTransport object (which models QUIC connections) and an RTCQuicStream ob= ject (which models QUIC streams).=C2=A0=C2=A0
The RTC= QuicTransport object takes after the RTCDtlsTransport object which was orig= inally developed in the ORTC Community Group (see:=C2=A0 http://draft.ortc.org) and later integrated in WebRTC (= see: https:= //rawgit.com/w3c/webrtc-pc/master/webrtc.html), so it has been relative= ly stable.=C2=A0 The RTCQuicStream object has undergone quite a few changes= in order to evolve along with the IETF QUIC Transport draft (see:=C2=A0https://tool= s.ietf.org/html/draft-ietf-quic-transport ), and during the latest WEBR= TC WG meetings, additional changes were discussed, in order to better align= WebRTC-QUIC with the WHAT WG Streams API.=C2=A0

On Mon, Nov 5, 2018 at 1:56 PM Peter= Thatcher <pthatcher=3D40= google.com@dmarc.ietf.org> wrote:
FYI, the rtcweb WG has not been involved in the disc= ussion around the WebRTC API for QUIC.=C2=A0 It's only been discussed i= n the W3C.=C2=A0 Naturally, some people are in both groups, but as a group,= this WG has not discussed QUIC before (as far as I know).=C2=A0 It might m= ake more sense to reach out to the W3C WebRTC WG.=C2=A0 However, if you wan= t to talk to people in person IETF 103 might be a good opportunity to find = people..=C2=A0

And since we're discussing TAPS = and RTCWEB here, there is an area that the experience of the RTCWEB WG can = probably help the TAPS WG: the use of ICE.=C2=A0 I recently read through th= e TAPS documents and it seems that TAPS is attempting to make an API that i= ncludes the use of ICE (it's basically a superset of ICE, much like the= combination the WebRTC protocols).=C2=A0 In the context of the web, that c= an lead to some tricky issues.

If you wish to exte= nd TAPS to the web, one issue you will run into is the same that RTCWEB did= around the IP privacy handling of ICE (and the subsequent use of mDNS).=C2= =A0 =C2=A0 Another is consent freshness.=C2=A0 There may be others that I c= an't recall.=C2=A0 But you'll probably want to learn how the RTCWEB= WG solved these problems (for some definition of solved :) rather than ret= reading them.=C2=A0=C2=A0


On Sun, Nov 4, 2018 at 4:20 PM Tommy Pauly <= ;tpauly@apple.com= > wrote:
Hello rtcweb,

Based on recent proposals for WebRTC APIs to run over QUIC, the Transport S= ervices (TAPS) working group will be spending some time this week looking a= t the usefulness and applicability of our flexible transport APIs for use i= n WebRTC. One of the main goals is providing an API surface that will work = well across protocols and require minimal application effort to adopt, as w= ell as being able to dynamically use newer protocols. We'd like to get = input and feedback on how well such a model can serve the WebRTC use case.<= br>
Please join us in our discussion if you're interested!

Wednesday, November 7
1540-1710=C2=A0 Afternoon Session II
Transport Services WG
Room: Meeting 2

Thanks,
Tommy

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000006eb1ac0579f0d70b-- From nobody Mon Nov 5 20:41:10 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD4112D4EA for ; Mon, 5 Nov 2018 20:41:08 -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, FREEMAIL_FROM=0.001, 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 (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 t89c_zYfXs-T for ; Mon, 5 Nov 2018 20:41:06 -0800 (PST) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 1B07E126BED for ; Mon, 5 Nov 2018 20:41:06 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id 74-v6so11881366wrb.13 for ; Mon, 05 Nov 2018 20:41:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=YhirycziMlLLFrLjj8AaTikSMl1dXKHED5L6aVHKyws=; b=HauG71YTd7jSmJx41YZKvci1f8eGN9PxIqkaRcU7/rVNZzK0oxcIBdBIHvfJm4kPLB dXBlFgum+Ta57k353+1RVpmNEczvjjsYutgcdUO3cQ/TvjilZI9RaeYxeD84sgRa/iiJ 1AwS95MYzuRauCstX/fJ82ogs6uni7WciAgC5ahMtkze298+MfJ+V8tPw7h6w05ifjT4 i1ATiPq9XIYjEjf4hDrVD7D4kaZ9/hD6Ivw8PwdpZfKnwuSUA63GQNKWLVFMlvlezbUl O5HZcX3FClBXLPUg9v6fyV2ky7A2oVVE80W6ZmjY5PVu2Q+ZXSf16w7JScEO1CmZr/Hq Poiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=YhirycziMlLLFrLjj8AaTikSMl1dXKHED5L6aVHKyws=; b=JpdMS9TgkgrID2e9ga3vbk4MFqo0hYnKTrHMEh+/bwfNScql9OUyUBFV718iGuiLjs a4cXIj0VF2znx7dCpdONlHalg5r+1IdtO2ORjFxKu8g4sICb+OJyhVrjY9bL7dkwgyAe E3tcKCkwb6J/Vt4CRsehohKo3WB5kfgc9e90WnPSTHL1i1AZSg1amByLpbFA2sl0dglH bEKKi6/DFn5c0X9MgZRPz8PB6goCyGadSP177Zvy6LHOoFUD0+WfikSfJHHDAGo4LXYQ isfEdQ+rDW1A+eAbLwcAuEJBdc0gc8WosI11ZspE3sPLLZuTNvWN0kKWxsjShJ5RHwRe te2Q== X-Gm-Message-State: AGRZ1gJyeZDLmb558B02uG+6Sju8cAmGCDYmeCEy5KTcnzGhHxQPPTtA upbKSQh2QioXz8A1YfWx9uKgI2rQTjk= X-Google-Smtp-Source: AJdET5d1zoVhpyWtiXXYD0TzZ/Blx0Gdgm5KZ+ywLhNY/XVsSOfD/qU34B2Hpi+8L0BTnooM6wLCdw== X-Received: by 2002:adf:dd49:: with SMTP id u9-v6mr21163857wrm.2.1541479264122; Mon, 05 Nov 2018 20:41:04 -0800 (PST) Received: from [172.19.152.193] ([2001:67c:1232:144:f999:f254:564f:e9bc]) by smtp.gmail.com with ESMTPSA id e7-v6sm15749990wra.10.2018.11.05.20.41.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Nov 2018 20:41:03 -0800 (PST) From: "Aaron Falk" To: "taps WG" Date: Tue, 06 Nov 2018 11:40:58 +0700 X-Mailer: MailMate (1.12.1r5552) Message-ID: <97F45043-3882-41F6-A284-AA6859B6CCB6@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_1625492F-9F5A-40DB-858A-D8EEFC9C9294_=" Archived-At: Subject: [Taps] note taker X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 04:41:08 -0000 --=_MailMate_1625492F-9F5A-40DB-858A-D8EEFC9C9294_= Content-Type: text/plain; format=flowed; markup=markdown I promised Theresa (who's been doing a great job at taking notes) that we would be able to survive this meeting with her excellent minutes. That leaves the group without a note taker for tomorrow. Can I get a volunteer to take minutes? THanks!! --aaron --=_MailMate_1625492F-9F5A-40DB-858A-D8EEFC9C9294_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">I promised Theresa (who's been doing a great job at taking= notes) that we would be able to survive this meeting with her excellent = minutes. That leaves the group without a note taker for tomorrow. Can I= get a volunteer to take minutes?

THanks!!

--aaron

--=_MailMate_1625492F-9F5A-40DB-858A-D8EEFC9C9294_=-- From nobody Thu Nov 8 02:51:36 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007D213103D for ; Thu, 8 Nov 2018 02:51:30 -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_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 C5A_MB9BlVJO for ; Thu, 8 Nov 2018 02:51:28 -0800 (PST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 CF0A1130F9C for ; Thu, 8 Nov 2018 02:51:27 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id r63-v6so775859wma.4 for ; Thu, 08 Nov 2018 02:51:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version; bh=O7551hjO44kfVLr0zEAuX+jInz9WvnGjmu6UVLDv3q0=; b=TnKsU8J3Lr1rXPEpuD9dJz3cTBceSCvNhcg1CXZZLBOCgVvPT/7CeaF43HVhZGHGCm ReIxWUB67nVZxkbYADS44YrN1WiJl6YcIIoo6IT+5on184oWf3qZiZyJpVyHZCRZ+Jv0 mMkTaINY0EitoPH5oproYBFkczYQdIk2G3yTD8u5Qjh+oIIuPcGjlWZbDLDlksTQSTMo vJ5WWeKm5Eh+9cZQwhSoa2byP52f9dwY3N7nixL/deTP+Kd7fJiAEsXvJt23/WfoWyiz N7TiygTydULTNtmw/AXfk/AWWdIZ0XE1AZce91vCrRIY7Z3myqJ74xjatf54YlXOUhaW 5Ggw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version; bh=O7551hjO44kfVLr0zEAuX+jInz9WvnGjmu6UVLDv3q0=; b=E5MWonTKiiAe2NORmNAnv8+jQArnctTMeS/1jFIm37dGIF9nV1CiLpCBoWiu/hZA58 MpUzX2SfSQLs/i8HTI/iANb+1IlsFSHYtsnw/7r1bfL1k2PA1OwY81nHRlLGMwv6U3H6 WUeclBwRoi5xxj5vbNc+pBcLqRIeTBscEkm9yYag+vI7v51psXaSDDLe4k3uuiL8QP43 b+bOEG8UeFBqqmhX9VqEKU4xKV/XfMxaXEQXOWNX15y6t+LkHQsa4/iHGZCh4FSijLfD 8vRFPtICS+XBr1sIi+JPeXxuR2TJ/SVFDcDZ2t0KQdA0MKsa5g+eW79kU1BYc+J8ymiB HeSQ== X-Gm-Message-State: AGRZ1gKDMzQH1aSgaz3CJbN9thfahn7fwTttgbwvh8azV5xe+svgvNq/ 1arfzlAmnF1mg34TfT6M1W+FeDcQcdw= X-Google-Smtp-Source: AJdET5fZt0clrhIzWQ+IgNnzdPq0fj16yWqQ5mh0m6QhJMjZ0A508zO/X1uBZT7Zb7iFUDULeRvSQA== X-Received: by 2002:a1c:b4c1:: with SMTP id d184-v6mr749482wmf.143.1541674285653; Thu, 08 Nov 2018 02:51:25 -0800 (PST) Received: from [172.19.153.2] (dhcp-9abf.meeting.ietf.org. [31.133.154.191]) by smtp.gmail.com with ESMTPSA id a127-v6sm3491544wmh.24.2018.11.08.02.51.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Nov 2018 02:51:25 -0800 (PST) From: "Aaron Falk" To: "taps WG" Cc: "Zaheduzzaman Sarker" , "Spencer Dawkins" Date: Thu, 08 Nov 2018 17:51:14 +0700 X-Mailer: MailMate (1.12.1r5552) Message-ID: <9916DC68-B5C9-4F4E-A8FE-B8FE52785FC1@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_5086853F-ACC4-4106-B34B-CD368E8CA805_=" Archived-At: Subject: [Taps] TAPS interim scheduling (ACTION REQUIRED) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 10:51:35 -0000 --=_MailMate_5086853F-ACC4-4106-B34B-CD368E8CA805_= Content-Type: text/plain; format=flowed; markup=markdown Hi Folks- I received some feedback that scheduling an interim before the end of the year may be a challenge. So, here's a doodle poll to schedule in January: https://doodle.com/poll/5q266sd3997ci4nd. Please complete this poll ASAP. Candidiate topics: * unresolved concepts for arch/interface drafts * draft registry * wg use of GitHub --aaron --=_MailMate_5086853F-ACC4-4106-B34B-CD368E8CA805_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Hi Folks-

I received some feedback that scheduling an interim befor= e the end of the year may be a challenge. So, here's a doodle poll to sc= hedule in January: https://doodle.com/poll/5q266sd3997ci4nd. Ple= ase complete this poll ASAP.

Candidiate topics:

  • unresolved concepts for arch/interface drafts
  • draft registry
  • wg use of GitHub

--aaron

--=_MailMate_5086853F-ACC4-4106-B34B-CD368E8CA805_=-- From nobody Tue Nov 13 13:10:37 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B1A130DE7 for ; Tue, 13 Nov 2018 13:10:35 -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, FREEMAIL_FROM=0.001, 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 (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 wXVya_6VgWEn for ; Tue, 13 Nov 2018 13:10:33 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 F0383130DCB for ; Tue, 13 Nov 2018 13:10:32 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id a132so22123958qkg.1 for ; Tue, 13 Nov 2018 13:10:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=Q445gPO7Xl8bS+b9OU8euEwc8PNT22wdl3hIbRs3dls=; b=cwrFMidkSmQS1yyF46YTVSnsewpg8Hhze4ok6lwGe8rJn8YcqVymuRc+hJxl6EZ3Kt 1NiUpJawAw2VF1DlGMzHQAv0HPb+yM6G3Teauv0ZUfPtTNWOxlPqx+MiGg1sL++1a1PZ t9L9kKDoixL1tow9obK0LmNdjbhRWBDUTSpxzFK4yrF42dtMJ/jO1ZNfQuGoD2UfWwJV cC8gsM5xNlCOCCWo0SyUBMEnlU0h4satNQD+T4FFdAeIunV7tzll8UxYbBx6QFVcDxYJ rR6U/vIRkPmi0oJafqwKcLg4IkvLFjgkTiBHyynYrjD6gqyc3naazzquh/Ej4adVs2dp dsqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=Q445gPO7Xl8bS+b9OU8euEwc8PNT22wdl3hIbRs3dls=; b=BUg3rkzQcTJiiU/B4iI5kLKoN1ThiF4w6zscXUdmxSjq7hWLv6fA4QtqSWwHnIlPMr sYNYkWLjB5z22jTJuFdGxytYy14VLPbp2T3P7E/ubWMhRfH0cZL4vMqLAFemBtYwvpKY pYgSsRFkiI4QPIoDhg4Zh7eWzajtcIChSUUuRYofbSrR7oavTHKOoXhwZYunbxcarXTh Y7jrvqHGNO/vCDEKsv6wzHuc7ozyMPfGRpExxkm2sSy8oLTIg32JJKzC2Z+vnEsN2o5l oa4ODwNtgtlweW6CNddNFjRff6Z3+VkCevCTu0/9GMv4eMkof6Og3jUuydQj9JkHBZj1 6fHg== X-Gm-Message-State: AGRZ1gJe0K9LaUG2kvVbGaCMBxnvWimK35own8CduGtaWKpp+uvTb3yR 9hoI/Z5MvNMx+5TSLttZA5igbxHi X-Google-Smtp-Source: AJdET5cjeXmUQKPW/e3yIMcN1LoXypcjdx4nX0Ez5FkIi+yt+nMAGHJ+kB6S3okUSPpCh0LFemGtVQ== X-Received: by 2002:aed:2185:: with SMTP id l5mr6756655qtc.276.1542143431378; Tue, 13 Nov 2018 13:10:31 -0800 (PST) Received: from [172.19.35.114] ([2001:4878:a000:3000:f44b:6fb7:fcb8:5bf1]) by smtp.gmail.com with ESMTPSA id e5sm4451799qtr.52.2018.11.13.13.10.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Nov 2018 13:10:30 -0800 (PST) From: "Aaron Falk" To: "taps WG" Date: Tue, 13 Nov 2018 16:10:28 -0500 X-Mailer: MailMate (1.12.1r5552) Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_EB69BC51-8C37-44AD-8DEE-4FAB6923E998_=" Archived-At: Subject: [Taps] draft TAPS minutes X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2018 21:10:35 -0000 --=_MailMate_EB69BC51-8C37-44AD-8DEE-4FAB6923E998_= Content-Type: text/plain; format=flowed; markup=markdown See the meeting ether pad for meeting notes. (Thanks, Mike!) Please make any corrections needed. https://etherpad.tools.ietf.org/p/notes-ietf-103-taps --aaron --=_MailMate_EB69BC51-8C37-44AD-8DEE-4FAB6923E998_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">See the meeting ether pad for meeting notes. (Thanks, Mik= e!) Please make any corrections needed.

https://etherpad.tools.ietf.org/p/notes-= ietf-103-taps

--aaron

--=_MailMate_EB69BC51-8C37-44AD-8DEE-4FAB6923E998_=-- From nobody Tue Nov 13 13:23:18 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D560130DE0 for ; Tue, 13 Nov 2018 13:23:17 -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, FREEMAIL_FROM=0.001, 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 (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 k_Whx_x6QLts for ; Tue, 13 Nov 2018 13:23:15 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 5FD89130DCB for ; Tue, 13 Nov 2018 13:23:15 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id m5so22185059qka.9 for ; Tue, 13 Nov 2018 13:23:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version; bh=ObPloX+DUxoU/kETOdkVLyhv9cgq+OT0vysPcssNUDA=; b=svdiwXYl/0OGQJoGa5wUCwr4ybG9XwzOpsgW9zEzRT0DXh4H6f+h9otwxxTtw7eQC0 rP7oKFTFQ115PF30bVAWRRKHfnLGfpBUU2e0PqY/UgHznQPTqh2hMPKI2p34KcsXnqko rOdtSWXdhghy7ms5vvbbsnqw4p1T4eDMfYJpvnR8DRKLFQLlPRGAGH4m8S123wMJAt8u iYTGFRb+oatpeE1EGcOgBJzxuaiwy9hldQQxcB4FMc1pxKqFgUYVeRgqetqcpaUGWBB0 RCIqhnI9LGgWsTPhCBPlA0wW2R+4AZIWBIg+tUfmAVunhUvZEVozjOfRujVo1i2YlN7F dU8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version; bh=ObPloX+DUxoU/kETOdkVLyhv9cgq+OT0vysPcssNUDA=; b=FBL4FCNVlaEeJEJWe27nMw0cbE2gajvLnCkf7pCOG4TgjwfwpjwsysX+kE/LFeqsTr RumkeYbtx2reyml2PX8Rz6J2DrGP2YRZMhkHGJRXStksY3f5PgdoIuyL7WVtkfWp7XAc S8fcLzt0VRewKqEsLVLAjt9DEWQCWG2quBXOHDizB7gHZbBUkc2D7BLZH/JtfDekICP6 QnCnt92k7rd0fucuFg5Vgc4sRXzKzY3xHmhI3ZSQmgTXiP7QNFl4lYUzvmp196WBqU45 inMmJKg+GrSVupP6YxSV/wCx2WDJ4o8j7JlfwwMxyd/XMJBAIKbAvtuVPmZCmC0Wte/R E2YQ== X-Gm-Message-State: AGRZ1gJxEP8Y5pP1Bwm3o8rJFQgA4oMYjtyBt3kMomxfx8+xyfQ67U/t KNSzVdmcNMk31oonvkE89uxmjMZo X-Google-Smtp-Source: AJdET5dTg+C51p59EFnlDyvwLZW7wsgbKgy9nT+BXpbdNiezVGBzTRX1joBQpqBAVHLU9aNX3dzURA== X-Received: by 2002:aed:2dc5:: with SMTP id i63mr6884157qtd.173.1542144193792; Tue, 13 Nov 2018 13:23:13 -0800 (PST) Received: from [172.19.35.114] ([2001:4878:a000:3000:f44b:6fb7:fcb8:5bf1]) by smtp.gmail.com with ESMTPSA id q38sm5060436qtj.65.2018.11.13.13.23.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Nov 2018 13:23:13 -0800 (PST) From: "Aaron Falk" To: "taps WG" Cc: "Zaheduzzaman Sarker" , "Spencer Dawkins" Date: Tue, 13 Nov 2018 16:23:11 -0500 X-Mailer: MailMate (1.12.1r5552) Message-ID: <1D8D4CF6-35B6-4387-872A-2C3F3F846ADB@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_D8949F87-08C6-4578-9786-9D5A2FB99A12_=" Archived-At: Subject: [Taps] document plan / milestone update X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2018 21:23:17 -0000 --=_MailMate_D8949F87-08C6-4578-9786-9D5A2FB99A12_= Content-Type: text/plain; format=flowed; markup=markdown Just recapping the discussion in Bangkok, I think we agreed the to the following plan: March 2019: complete a WG review for draft-ietf-taps-arch *(like a WGLC but don't request for publication until -interface & -impl are done)* March 2019: submit draft-ietf-taps-transport-security to IESG for publication July 2019: complete a WG review for draft-ietf-taps-interface Nov 2019: complete a WG review for draft-ietf-taps-impl Nov 2019: submit -arch, -interface, -impl to IESG for publication Do I have that right? --aaron --=_MailMate_D8949F87-08C6-4578-9786-9D5A2FB99A12_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Just recapping the discussion in Bangkok, I think we agre= ed the to the following plan:

March 2019: complete a WG review for draft-ietf-taps-arch=
(like a WGLC but don't request for publication until -interface &= -impl are done)

March 2019: submit draft-ietf-taps-transport-security to = IESG for publication

July 2019: complete a WG review for draft-ietf-taps-inter= face

Nov 2019: complete a WG review for draft-ietf-taps-impl

Nov 2019: submit -arch, -interface, -impl to IESG for pub= lication

Do I have that right?

--aaron

--=_MailMate_D8949F87-08C6-4578-9786-9D5A2FB99A12_=-- From nobody Tue Nov 13 13:45:16 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C828130DCB for ; Tue, 13 Nov 2018 13:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 (2048-bit key) header.d=apple.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 NDMoFRl1XoRt for ; Tue, 13 Nov 2018 13:45:13 -0800 (PST) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (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 D4A9312DDA3 for ; Tue, 13 Nov 2018 13:45:12 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.22/8.16.0.22) with SMTP id wADLgDj5044864; Tue, 13 Nov 2018 13:45:08 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=3Qbpd/MPjC5IofjW5Dn4wMnl1EkGCdU+VgZbErHB9zg=; b=X2Y7JY0QhB3mxOgN0BV7tgCX5dvaf2AIzVpy0Sex5bNA15Q4FwPgiR+u0mW70pM+qexV QTKo2qHkPzZ7Lc/fwCJtHyQKwvgr+0uwiec8lDxCH68QMpogp2xtowbsPIBxD2K6qWMI DtgQ3MfDQTDofxvI+09iJCKzC8VlR1OReDFYl/x2AAk+EVN15e1lv+XCZU/JmjtzgwGW 2y6505D72sAbp+V1aihPPHYWXH1Iz9UCo/20nM2TuSgmdsZmiA2D6mQgwioJcr7XWj15 rDxYGtDyaaXMJ42sHJG3a3qC+l9SEHF9XogMUP7t5bsQW5oidG1vXJeo4lf+BQGWP59G XA== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2nnvssrtp3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 13 Nov 2018 13:45:08 -0800 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_SNVu/FbOFoSjv7R6TvoiWQ)" Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PI500IOAJ350JE0@ma1-mtap-s03.corp.apple.com>; Tue, 13 Nov 2018 13:45:05 -0800 (PST) Received: from process_viserion-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PI500500HPPA400@nwk-mmpp-sz12.apple.com>; Tue, 13 Nov 2018 13:45:05 -0800 (PST) X-Va-A: X-Va-T-CD: 0325f276f41c42fd3b0ac081f7f3f808 X-Va-E-CD: 8cef555a1c685252348e1182e50cb8d7 X-Va-R-CD: baafec4d6f114ac9b69667105d9bbc35 X-Va-CD: 0 X-Va-ID: a4037348-98c2-4bbf-9ab8-6c762e9658cf X-V-A: X-V-T-CD: 9ea90e61654dad0c8920388428deae70 X-V-E-CD: 8cef555a1c685252348e1182e50cb8d7 X-V-R-CD: baafec4d6f114ac9b69667105d9bbc35 X-V-CD: 0 X-V-ID: c5045bb8-209c-4692-a0ba-16a874f3f58a Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PI500G00IEOLN00@nwk-mmpp-sz12.apple.com>; Tue, 13 Nov 2018 13:45:04 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-11-13_15:,, signatures=0 Received: from [17.234.51.157] (unknown [17.234.51.157]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PI500GVYJ33SJ30@nwk-mmpp-sz12.apple.com>; Tue, 13 Nov 2018 13:45:04 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <54D51372-45CF-4E9E-8683-0007EA70EDD7@apple.com> Date: Tue, 13 Nov 2018 13:44:59 -0800 In-reply-to: <1D8D4CF6-35B6-4387-872A-2C3F3F846ADB@gmail.com> Cc: taps WG , Zaheduzzaman Sarker , Spencer Dawkins To: Aaron Falk References: <1D8D4CF6-35B6-4387-872A-2C3F3F846ADB@gmail.com> X-Mailer: Apple Mail (2.3445.100.36) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-13_15:, , signatures=0 Archived-At: Subject: Re: [Taps] document plan / milestone update X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2018 21:45:15 -0000 --Boundary_(ID_SNVu/FbOFoSjv7R6TvoiWQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT That schedule looks good to me, and is what I recall from the meeting discussion as well! Best, Tommy > On Nov 13, 2018, at 1:23 PM, Aaron Falk wrote: > > Just recapping the discussion in Bangkok, I think we agreed the to the following plan: > > March 2019: complete a WG review for draft-ietf-taps-arch > (like a WGLC but don't request for publication until -interface & -impl are done) > > March 2019: submit draft-ietf-taps-transport-security to IESG for publication > > July 2019: complete a WG review for draft-ietf-taps-interface > > Nov 2019: complete a WG review for draft-ietf-taps-impl > > Nov 2019: submit -arch, -interface, -impl to IESG for publication > > Do I have that right? > > --aaron > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Boundary_(ID_SNVu/FbOFoSjv7R6TvoiWQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT That schedule looks good to me, and is what I recall from the meeting discussion as well!

Best,
Tommy

On Nov 13, 2018, at 1:23 PM, Aaron Falk <aaron.falk@gmail.com> wrote:

Just recapping the discussion in Bangkok, I think we agreed the to the following plan:

March 2019: complete a WG review for draft-ietf-taps-arch
(like a WGLC but don't request for publication until -interface & -impl are done)

March 2019: submit draft-ietf-taps-transport-security to IESG for publication

July 2019: complete a WG review for draft-ietf-taps-interface

Nov 2019: complete a WG review for draft-ietf-taps-impl

Nov 2019: submit -arch, -interface, -impl to IESG for publication

Do I have that right?

--aaron

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

--Boundary_(ID_SNVu/FbOFoSjv7R6TvoiWQ)-- From nobody Tue Nov 13 13:49:52 2018 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E10130DCD for ; Tue, 13 Nov 2018 13:49:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154214579080.27393.1212050739520911192.idtracker@ietfa.amsl.com> Date: Tue, 13 Nov 2018 13:49:50 -0800 From: IETF Secretariat Archived-At: Subject: [Taps] Milestones changed for taps WG X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2018 21:49:51 -0000 Changed milestone "Submit an Informational document to the IESG recommending a minimal set of Transport Services that end systems should support", resolved as "Done". URL: https://datatracker.ietf.org/wg/taps/about/ From nobody Wed Nov 14 11:15:23 2018 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1183A130DF7 for ; Wed, 14 Nov 2018 11:15:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154222292206.19108.17379963283889388808.idtracker@ietfa.amsl.com> Date: Wed, 14 Nov 2018 11:15:22 -0800 From: IETF Secretariat Archived-At: Subject: [Taps] Milestones changed for taps WG X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2018 19:15:22 -0000 Changed milestone "Submit an Informational document defining a set of security-related Transport Services", set due date to March 2019 from July 2018, added draft-ietf-taps-transport-security to milestone. Changed milestone "Submit document(s) to be published as Proposed Standard to the IESG specifying one or more methods to provide applications with the Transport Services identified by the WG", set due date to November 2019 from March 2019, added draft-ietf-taps-arch, draft-ietf-taps-impl, draft-ietf-taps-interface to milestone. Changed milestone "Recharter or conclude.", set due date to November 2019 from July 2019. URL: https://datatracker.ietf.org/wg/taps/about/ From nobody Wed Nov 14 11:16:50 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CE612EB11 for ; Wed, 14 Nov 2018 11:16: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_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 Se7u728TGbRh for ; Wed, 14 Nov 2018 11:16:48 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 B7ECF12D4E8 for ; Wed, 14 Nov 2018 11:16:47 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id r71so27789954qkr.10 for ; Wed, 14 Nov 2018 11:16:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=xDpNcv1vQ7o2/tPCRliCwE3dGZIfUADvWIzxvckyYLc=; b=cmIkoOLs6DsmhkI5EaKHPMsPQUSDgK0uVcp/nR05SE1tmzgnmVrk/0UnANCLCoDvIv LyU6aSDIU38F+86JZ3dCV/mReAmCdUlCTmpZCu0BfcW7RsnF5o6XtuAlQ81La5LQpZ6N ThzHAI1yeVq4Xx15NmLpDN1w6giRtlOixwVJVQ4HJoBxAD1MNCnd+hLk8llApqWUkY9D 5F2xJdVcQINgYg+VaBRWIn5fbpiilvYrCENNB0V12CHlAgbL+BZzDRWEWipoI0TdkaiE 0NOuiOLg7giLBmhQ2BZ8BeCbBm2uokl43txM7Dt3yXUPQdTXxMA5RAWrjiS4oiAzuNQk kfcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=xDpNcv1vQ7o2/tPCRliCwE3dGZIfUADvWIzxvckyYLc=; b=F8ZCWLowoYKxIBTHP55QswhYVeK8g5RtP1FWedxCyH1OClV7bX4YScGlKN2Rym66Aa zWo9tSNhaLQASnSZEYaYK06b7S9Mm4q21cjFjfMmkZQ77Q3/AWcKiPR1DD3DVAnzwjuS 2nNC+X4xqTEO40/HZbzfgx8wL2CstR8qRzJy6hOV9xpFl36sE/UHLMiSphiwqtglgFlr lu2evZlVfeMyFpqCKV6QmpCrEFL7Wvx4NC5q2fwoEzc5Hs7A+sHEdTyLrEWOPZKJ4TwY oCv3/piCGtSkIeQNLJl/vqtjvwS9eP7uvVo4LhoRLdTNVsA4VjKVah6vPs04bS2s6OH7 KyRA== X-Gm-Message-State: AGRZ1gIa1s/gtoquPyJhZNl3iQHzAIY2zWxll5Z0KnjVy8mnvt/EXvaU KWlikyhLSxxi7uk0GBmZklhCD6sb X-Google-Smtp-Source: AJdET5c7/tF9+jUQXN8B1xEbJtS4sT3IZCCmn0QmuLqLHsmhCSVDKvwSIii39XXLsm/tuqvnqWtzSA== X-Received: by 2002:ac8:3715:: with SMTP id o21mr3110716qtb.224.1542223006042; Wed, 14 Nov 2018 11:16:46 -0800 (PST) Received: from [172.19.248.201] ([2001:4878:a000:3000:24cb:44ef:d40a:7571]) by smtp.gmail.com with ESMTPSA id v32sm9526239qta.37.2018.11.14.11.16.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Nov 2018 11:16:45 -0800 (PST) From: "Aaron Falk" To: "taps WG" Cc: "Zaheduzzaman Sarker" , "Spencer Dawkins" Date: Wed, 14 Nov 2018 14:16:39 -0500 X-Mailer: MailMate (1.12.1r5552) Message-ID: <56311A07-0444-414D-BBDC-8D9BF68ECC1A@gmail.com> In-Reply-To: <9916DC68-B5C9-4F4E-A8FE-B8FE52785FC1@gmail.com> References: <9916DC68-B5C9-4F4E-A8FE-B8FE52785FC1@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_C4E7F6D7-FFFC-43B1-BEFE-1986FE90D7A1_=" Archived-At: Subject: Re: [Taps] TAPS interim scheduling (ACTION REQUIRED) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2018 19:16:49 -0000 --=_MailMate_C4E7F6D7-FFFC-43B1-BEFE-1986FE90D7A1_= Content-Type: text/plain; format=flowed; markup=markdown Reminder to put your preferences in ASAP for scheduling a TAPS interim. kthanxbai, --aaron On 8 Nov 2018, at 5:51, Aaron Falk wrote: > Hi Folks- > > I received some feedback that scheduling an interim before the end of > the year may be a challenge. So, here's a doodle poll to schedule in > January: https://doodle.com/poll/5q266sd3997ci4nd. Please complete > this poll ASAP. > > Candidiate topics: > > * unresolved concepts for arch/interface drafts > * draft registry > * wg use of GitHub > > --aaron --=_MailMate_C4E7F6D7-FFFC-43B1-BEFE-1986FE90D7A1_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Reminder to put your preferences in ASAP for scheduling a= TAPS interim.

kthanxbai,

--aaron

On 8 Nov 2018, at 5:51, Aaron Falk wrote:

Hi Folks-

I received some feedback that scheduling an interim befor= e the end of the year may be a challenge. So, here's a doodle poll to sc= hedule in January: https://doodle.com/poll/5q266sd3997ci4nd. Please= complete this poll ASAP.

Candidiate topics:

  • unresolved concepts for arch/interface drafts
  • draft registry
  • wg use of GitHub

--aaron

--=_MailMate_C4E7F6D7-FFFC-43B1-BEFE-1986FE90D7A1_=-- From nobody Fri Nov 16 12:05:37 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB09127332 for ; Fri, 16 Nov 2018 12:05:36 -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_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 NnB7e3051tNj for ; Fri, 16 Nov 2018 12:05:34 -0800 (PST) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 4A948127333 for ; Fri, 16 Nov 2018 12:05:34 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id w204so39443160qka.2 for ; Fri, 16 Nov 2018 12:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=HJW9+u0RH1BMt0OJNPL8WMJD6OLbaVuBAx5K3R89PzA=; b=leGyHHavKONCOXqxZReLgD0PfG8BR6RgzJfexWVwWbJOq4wG7T7tXHY9uh1qqT54K2 hoc5qddHSpOXAIHuZ6sEINS4dgSDLEvbIZotoBhr2457+fS0Awj2XomTSrYOk+0O/Pja nw9R48KQwSS4Nhfpkpef0IIIVPROr/zdm/NL8F7DD9/sCdjHx3HxjZlerRPgWZw0YQbd Mq7VWxPvo5NTKrBXFgypC5ZyJQIP28LNNInQFxNl4/9co/oeU/s3IrdAmcZJARYN8yo1 5683vx6MAn63imjLkW9K6JJ70aTCcVqpN4qJDQyMm7qcS8zfHFK2ZYrpPaEOCz+P3TUp b3Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=HJW9+u0RH1BMt0OJNPL8WMJD6OLbaVuBAx5K3R89PzA=; b=H9p8sYYzD4gZkLxW/wORoC+Qb41xaBn+xDweRZKJZEScO1f3nE5CwQRI3hD6V2Tka5 4ZqxFFFivuPJ2eQnnJUZerFjN9t5innKJVW+BUDQL/+e/l9yscRS8GwNi3aTS88JqwbV L00a5LENxGx2Y3EJ+fchDSKceVExd3zmFJC6ppR29ec1JTUzr4+cjzqKyw8WRJEDSkZw 31zMTn9OOS7dSC6J0/6sHTiWmCIAQ/+24bc7NCI0RVCe5/9mqoo8XAbhxGSp7gJ/Alvx OKkxObHBmU/yFE9lNBQLllgxLSXwuYLe4+G4KTwTv3taTNXgmTIUHcLLssCFi5EnPsci VELA== X-Gm-Message-State: AGRZ1gJsEAfN8HwxNDzWC8IObPqOpbaVvZFhcbnjJKTeQpJhUYPUhlsw vT4iQ6pqmxNeqqdQpxVk4v8kdNpt X-Google-Smtp-Source: AJdET5eluFabFcuiECFdnN4hJ/qhf0ieKXiFtazZERNAedBevgTdzVYOv+7fEFTNMW0VvyDUAJoVVw== X-Received: by 2002:ac8:71d0:: with SMTP id i16mr11796857qtp.386.1542398732593; Fri, 16 Nov 2018 12:05:32 -0800 (PST) Received: from [172.19.34.174] ([2001:4878:a000:3000:78f7:e434:f750:5efb]) by smtp.gmail.com with ESMTPSA id q21sm18415689qtk.79.2018.11.16.12.05.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Nov 2018 12:05:31 -0800 (PST) From: "Aaron Falk" To: "taps WG" Date: Fri, 16 Nov 2018 15:05:30 -0500 X-Mailer: MailMate (1.12.1r5552) Message-ID: <965FD415-BF86-4AA0-A6FE-29EC599A3360@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_D55EA4E8-7273-4E29-A794-B197ADB717A3_=" Archived-At: Subject: [Taps] IETF-103 minutes X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 20:05:36 -0000 --=_MailMate_D55EA4E8-7273-4E29-A794-B197ADB717A3_= Content-Type: text/plain; format=flowed; markup=markdown I've uploaded the minutes [here](https://datatracker.ietf.org/doc/minutes-103-taps/00/). Send corrections or amplifications to me and/or the list. --aaron --=_MailMate_D55EA4E8-7273-4E29-A794-B197ADB717A3_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

I've uploaded the minutes here. Sen= d corrections or amplifications to me and/or the list.

--aaron

--=_MailMate_D55EA4E8-7273-4E29-A794-B197ADB717A3_=-- From nobody Fri Nov 16 12:22:37 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6711F127332 for ; Fri, 16 Nov 2018 12:22:35 -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_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 wF5Df1QZYrEo for ; Fri, 16 Nov 2018 12:22:32 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 A1D16130F50 for ; Fri, 16 Nov 2018 12:20:04 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id o125so39494595qkf.3 for ; Fri, 16 Nov 2018 12:20:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=REn4yuw9VhUbe+x7NcZmMUNyqkLXkUmTlHvujGrbOx8=; b=tTJ0znfjy5eBc39BFUqCOoYa7e9TBu4Ww1x/QR4A6Vnica5DddbdtHkS3vPOumd/gv xoSLAenivfymOAgB3HfWYbb6Wdhs0Km4kbhE020UkTE5Y5k13F/52pcVAR7lMe/ru+Vc zSLDbulOPFQmdSUnsJYkTOhL31TqaSad/tTAv1pMc51WtS1vtUKyJafXtA3Z43Ezo+jL BnRlLAkHGEI95/W0TKpdEgf6DUB2icRsHexdD6YlAbIu2AHCSmDINJh+2A4BeTXIDyrI HslfUbbuqB3zRjn7m3eysZZSJo+5QUDZxUltAr8WfEJuAa5vIH/el5xny0XoQuczgjVT ylxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=REn4yuw9VhUbe+x7NcZmMUNyqkLXkUmTlHvujGrbOx8=; b=O46ZFjRIPDX8OYq6HTDpRjKw5c//tLpyBY+ros6pKgufprj9bJOyaPEmdMYttsdRVH lKrQwVcH4tzcWeUElU+mXQi7wdTLs16CEJouo80NLkWZq63SV6KnvpbTBtQvW0XKPSkg fxjDqwU1cRI/xV2eNy8asPd7l9XWF+uwXbrFERn0qGDZC/9yD9ES+iDWl4PuMvEwM/Rg LSFG6gPA6pW95sb+Z6/4pOrtabwfA4baQVCmNHtPxS7rp59ARxuZwdRcHCSoXbBAbSks +JOnyVBIfBVmpO52Ig5hbo8gPD2lonZS0ZuRFfujJ6cLYD8DXrqAk4Bcvhqm4KbVJODg +sGA== X-Gm-Message-State: AGRZ1gJpdbKvkErGPp6pzpc3MSSiEPlXPUKYX1ICGWhar5Iof20BS0E6 TVyP2lquqjXc0T8nEt2eoH/aU22b X-Google-Smtp-Source: AJdET5eM/vdit+k2NOg6iM+rB+/Gj2R/VEPuLj6voJf/gSldHb7QzJlA/U2zMrmRIIABwhnuvHY4AQ== X-Received: by 2002:a37:7003:: with SMTP id l3mr11945447qkc.80.1542399603097; Fri, 16 Nov 2018 12:20:03 -0800 (PST) Received: from [172.19.34.174] ([2001:4878:a000:3000:78f7:e434:f750:5efb]) by smtp.gmail.com with ESMTPSA id i26sm22964304qtc.13.2018.11.16.12.20.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Nov 2018 12:20:02 -0800 (PST) From: "Aaron Falk" To: "taps WG" Date: Fri, 16 Nov 2018 15:20:00 -0500 X-Mailer: MailMate (1.12.1r5552) Message-ID: <0EBDBEA8-5DBF-4784-B043-59B2B707AD62@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_7DF39FE1-6E79-493A-A838-186F2B1CAF93_=" Archived-At: Subject: [Taps] interim date: Jan 15 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 20:22:35 -0000 --=_MailMate_7DF39FE1-6E79-493A-A838-186F2B1CAF93_= Content-Type: text/plain; markup=markdown Everyone who responded can attend an interim on Tues, Jan 15. Time: 0800-1000 PST 1100-1300 EST 1700-1900 CET https://ietf.webex.com/meet/taps access code: 316 448 940 --=_MailMate_7DF39FE1-6E79-493A-A838-186F2B1CAF93_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Everyone who responded can attend an interim on Tues, Jan = 15.

Time:
0800-1000 PST
1100-1300 EST
1700-1900 CET

https://ietf.webex.com/meet/taps
access code: 316 448 940

--=_MailMate_7DF39FE1-6E79-493A-A838-186F2B1CAF93_=-- From nobody Mon Nov 19 07:05:20 2018 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 255B012426A; Mon, 19 Nov 2018 07:05:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154263991302.5316.9552948877497759981@ietfa.amsl.com> Date: Mon, 19 Nov 2018 07:05:13 -0800 Archived-At: Subject: [Taps] Transport Services (taps) WG Virtual Meeting: 2019-01-15 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 15:05:13 -0000 The Transport Services (taps) Working Group will hold a virtual interim meeting on 2019-01-15 from 11:00 to 13:00 America/New_York. Agenda: Draft agenda: 1. Unresolved architecture topics 2. TAPS Registry proposal 3. Use of GitHub Information about remote participation: https://ietf.webex.com/meet/taps | Access code: 316 448 940 From nobody Sun Nov 25 21:40:40 2018 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E268128CB7; Sun, 25 Nov 2018 21:40:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Paul Wouters To: Cc: ietf@ietf.org, draft-ietf-taps-transport-security.all@ietf.org, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154321083813.24275.4373340388504093292@ietfa.amsl.com> Date: Sun, 25 Nov 2018 21:40:38 -0800 Archived-At: Subject: [Taps] Secdir early review of draft-ietf-taps-transport-security-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 05:40:38 -0000 Reviewer: Paul Wouters Review result: Has Issues Review of draft-ietf-taps-transport-security-04 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is HAS ISSUES. SecDir tools note: The secdir review link refers to an abstract containing the text: This draft summarizes a number of IETF transport security protocols a Note the word "IETF ... protocols". I don't actually see that in any of the revisions 00 to 04? Where did this comment/text come from? Reading the introduction, this draft's goal is: This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog transport services [RFC8095] by describing the interfaces required to add security protocols. My first comment is regarding "commonly used or notable". Especially the latter one is odd. Why should the IETF reader be aware of "notable" but "not commonly used" protocols? And the reason I say this is because it lists CurveCP and MinimalT, which as far as I know are not deployed at all. While openvpn, which has a serious userbase, is not mentioned at all. And openconnect, an open specification compatible with Cisco Anyconnect, which even has a draft, draft-mavrogiannopoulos-openconnect-02, is not mentioned at all. In my opinion, the document would be improved by adding Openvpn and Openconnect, and removing CurveCP and MinimalT. My second comment is regarding IETF vs non-IETF protocols. Or even "specified in a draft or RFC" versus "there is an academic paper and some implementation and it's not clear what's what". The reason I am saying this is that for instance the protocol "specification" of WireGuard keeps changing. Their website lists a "whitepaper" that is changing over time with no changelog, and wild claims that I've spend time in the last few years to counter, upon which it gets rewritten with new misleading or wrong claims. It is kind of hard to do an IETF style summary of protocols when the "specification" includes phrases like: the tunnel simply works. Key exchanges, connections, disconnections, reconnections, discovery, and so forth happen behind the scenes transparently and reliably, and the administrator does not need to worry about these details. In other words, from the perspective of administration, the WireGuard interface appears to be stateless. This is not a white paper but a Public Relations document. None of the other discussed protocols in this document require administrators to "worry" about those "details" either. At the IETF, we recommend IETF protocols. If someone comes up with an alternative protocol that accomplishes the same as an existing one, we tend to tell people to use the existing IETF protocol instead. Or, we think their new protocol merits further standarization, and we ask them to produce either a ISE or IETF stream document that people can reference, comment, improve and discuss openly on its technical merits. It is also clear the white paper is not a good complete formal specification like we do at IETF. For example, if there is packetloss, the "specification" does not at all specify which of the parties (or both?) are responsible for retransmission. Can one spoofed packet lead a WireGuard endpoint to retransmit its response repeatedly? This further weakens their "stateless" claim. (and if it sounds like I am being harsh, I know I am. It is because previously, I had to counter false claims about IPsec speed, and IKE "being noisy" where as having looked again at "the whitepaper" (which keeps changing every time I look at it) it seems to now have a new hobby horse in the word "stateless". the openvpn tun0: is also "stateless", so is the VTI IPsec based interface vti0: Because of these reasons, I am a bit worried that an IETF document is making any claims about WireGuard features, as there is no way to know what the protocol will be like by the time this document is published, and this document cannot even point to a stable reference of te specification at the time of review. If this document wants to mention WireGuard as a protocol to take note of, I would like to see at least some text there urging WireGuard to write up (and version) their protocol in an IETF draft/RFC or other proper/formal specification. Now, having said all of this about WireGuard, I do agree with mentioning WireGuard in this document as it does have an actual userbase. Let's just urge and help them with their specification. (and If the author(s) of WireGuard are reading this, I am more than happy to help you with this) As for CurveCP and MinimalT, as far as I can see, these are just academic exercises with no serious deployment. While the IRTF might be discussing the these, I don't think an IETF document should reference these two proof of concept ideas until they have matured more. Introduction / Abstract: Expand/explain TAPS on first use? Section 4.4.1.1: IKEv2 is a control protocol that runs on UDP port 500 Change to: IKEv2 is a control protocol that runs on UDP or TCP port 4500 and UDP port 500. Note you don't mention the one big drawback, that it cannot be run on any UDP port (although at least now we can run on any TCP port) which is an important problem when networks block IKE/IPsec on purpose compared to non-IETF VPN protocols. It then goes through a phase of authentication in which both peers present blobs signed by a shared secret or private key, after which another set of keys is derived, referred to as the "Child SA". These Child SA keys are used by ESP. This text makes it appear only the blob's are authenticated, but the entire IKE exchange is authenticated. Also sessions keys are not all that is a Child SA. So perhaps: IKE then performs a phase of authentication in which both peers present blobs signed by a shared secret or private key that authenticates the entire IKE exchange and the IKE identities. IKE then derives further sets of keys on demand, which together with traffic policies are referred to as the "Child SA". These Child SA keys are used by ESP. Each proposal may contain an encryption algorithm, an authentication algorithm This is a bit misleading with both the "may" and the lack of AEAD discussion? Perhaps: Each proposal contains an encryption with authentication algorithm or an AEAD algorithm, Any SA used by IKEv2 can be rekeyed upon expiration, Rekeying happens before expiration, not upon (which would imply trafficflow interuption) Similarly to how it is described for tcpcrypt in the document. So perhaps just change "upon" to "before" ? Or go in a little more detail with: Any SA used by IKE/IPsec can be rekeyed before expiration. It does so by negotiating a second SA, and once confirmed up and running, the old SA is deleted. This guarantees there is no slowdown or halt of traffic flow during rekeying. that allows a set of Security Associations to migrate over different addresses and interfaces I would say "different outer IP addresses and interfaces" Each SA is identified by a Security Parameter Index (SPI), which is marked on each encrypted ESP packet. I would avoid the word "mark" here, since to me that more presents internal state inside a kernel (eg iptables MARK) and not something that goes over the wire. So perhaps: The SA of an encrypted packet is identified by its Security Parameter Index (SPI) [which is send as part of the ESP header) an anti-replay service (a form of partial sequence integrity) What is partial about this? Perhaps you meant to say ESP, like UDP, does not provide guaranteed delivery? Anyway, a "partial" security function reads odd :) and limited traffic flow confidentiality. What is "limited" about it? You can generate bogus traffic and pad traffic to any size (most common max mtu). What would you want in additional to make it not "limited" ? One thing I would add to the ESP section is mentioning it acts like UDP. It cannot be reset by a single TCP RST packet, and you don't have two layers of netflows doing retransmission. This feature of ESP (and some UDP based protocols in this document) is fairly important. Section 4.4.2.1: Mutual Authentication It is possible to do server-only or opportunistic/anonymous IKE as well. Maybe add "Usually" ? 4.6.1: Tcpcrypt exposes a universally-unique connection-specific session ID to the application, suitable for application-level endpoint authentication either in-band or out-of-band. This kind of conflicts with the introduction that claims this is only an opportunistic encryption protocol? Maybe merge this part into the description text? 4.6.2: I might say here something about only passive attacker protection? That seems like an important difference compared to the other protocols. Or perhaps make this clear in the introduction text when mentioning opportunistic encryption. 4.7: WireGuard is a layer 3 protocol designed to complement or replace IPsec [WireGuard] for certain use cases. I am confused about how it "complements" IPsec? Perhaps you mean it is an "alternative" (and perhaps a non-IETF alternative) ? I think "replace" is very misleading, as IPsec has a vast number of different use cases compared to WireGuard's "static VPN configuration". WireGuard is designed to be entirely stateless, modulo the CryptoKey routing table, Wouldn't you be able to say the same about the ESP SPD/SAD table? I'm not sure how different the ESP/wireguard statelessness is on a scale or truly stateless to NFS You don't mention anything about port preconfiguartion and the "port knocking" thing? o Record replay prevention (Stateful, timestamp-based). I thought it was stateless module CryptoKey routing? :) You do not mention mobility or session resumption for WireGuard. Since it is all about static inner IP addresses over arbitrary outer addresses, it has mobility. And I guess the 1RTT means it has session resumption? Can you add a description of rekeying for WireGuard similar to IKEv2/ESP? I thought there was an issue there that during rekey, there is no continued data flow possible, so connections briefly slow down or halt when the channel is being rekeyed. Does WireGuard not offer padding or any other kind of Traffic Confidentiality options ? 4.8: The MinimalT section seems to lack some information bullet points compared to the other sections? eg shouldn't it have things like: o Datagram Transport ? Misc: Should tor be added to the list of protocols? Why are MinimalT and CurveCP part of this list? Is there any actual deployment out there? I thought this document described actual transport security protocols people can pick. I don't see CurveCP as a real candidate for this. I don't know about MinimalT. 5: I'm a little confused by the term Application in this section. Is this the enduser application or the userland part of the security protocol (eg IKE). I think you mean the application of the enduser? 5.1: Listed as mandatory feature is: o Public-key certificate based authentication. Yet you have mentioned that neither WireGuard or CurveCP can do authentication based on certificates? 5.2: o Length-hiding padding (LHP): * Application dependency: Knowledge of desired padding policies. This is not (always?) true? For example ESP can do padding after IKE negotiated it, and do it based on MTU ? The (end user) application does not have to be aware of anything? 5.3: The definition of "Mandatory" within this section is confusing. Maybe use another word like "Core" to indicate it is part of the core of the protocol and cannot be disabled? NITS: spelling error: defailt