Subject: [Taps] comments on draft-pauly-taps-transport-security-02.txt

From: "Aaron Falk" <[email-masked]>
Date: Sat, 17 Mar 2018 14:53:44 +0000

A few comments on the draft below.

--aaron

----

Introduction (sec 1):

* I think it’s missing a statement describing why you chose this set 
of protocols.  You point out why you don’t include auth-only protocols 
but why (only) these?  Are you including all of the IETF transport 
security protocols?  If not, why not?  For the non-IETF protocols, why 
these?  The intro to Sec 3 says they are “security protocols that are 
currently used to protect data”.

Terminology (sec 2):

* Is ‘network security layer’ a well-defined term?  Does it mean 
something like “a security service provided by the network layer to 
the transport layer”?  Maybe worth including a definition.

* Can security features exist above the transport layer?

gQUIC (sec 3.4)

* RFCs take a long time to publish and live forever.  Given that, does 
documenting gQUIC make sense in that context?  Do you expect it to be 
around for a long time?  Are there functional differences from QUIC w/ 
TLS that distinguish it?

MinimalT (sec 3.5)

* I confess I’ve never heard of it.  The draft doesn’t include a 
citation.  Is there no RFC?  Seems odd to me that it is “built on top 
of a widespread directory service” but the directory service isn’t 
identified.

---

From: Christopher Wood <[email-masked]>
Date: Sun, 18 Mar 2018 11:36:04 +0000

Hi Aarron,

Thanks for the feedback. Please see inline for responses.

Best,
Chris

On Mar 17, 2018, 2:53 PM +0000, Aaron Falk <[email-masked]>, wrote:
> I think it’s missing a statement describing why you chose this set of protocols. You point out why you don’t include auth-only protocols but why (only) these?

No particular reason. Are there ones you think we should add?

> Are you including all of the IETF transport security protocols? If not, why not? For the non-IETF protocols, why these? The intro to Sec 3 says they are “security protocols that are currently used to protect data”.

As discussed a while back, we are including any and all transport security protocols, inside and out of the IETF. We could probably clean up the rationale a bit to make that necessary condition more clear.
>
>
> Terminology (sec 2):
>
> • > Is ‘network security layer’ a well-defined term? Does it mean something like “a security service provided by the network layer to the transport layer”? Maybe worth including a definition.
>
Agreed. I filed https://github.com/mami-project/draft-pauly-transport-security/issues/24.
>
> • Can security features exist above the transport layer?
>
Yes — see https://tools.ietf.org/html/draft-friel-tls-over-http-00 as an example.
>
> •
> gQUIC (sec 3.4)
> RFCs take a long time to publish and live forever. Given that, does documenting gQUIC make sense in that context? Do you expect it to be around for a long time? Are there functional differences from QUIC w/ TLS that distinguish it?
>
In my opinion, it makes sense to document gQUIC. The crypto core and integration are fundamentally different and deserving of their own section.
>
>
> MinimalT (sec 3.5)
> I confess I’ve never heard of it. The draft doesn’t include a citation.

There is a citation, though the formatting is borked. I’ll fix this.

> Is there no RFC?

No.

> Seems odd to me that it is “built on top of a widespread directory service” but the directory service isn’t identified.

We can certainly go into more details here. I filed https://github.com/mami-project/draft-pauly-transport-security/issues/23.

---

From: "Aaron Falk" <[email-masked]>
Date: Sun, 18 Mar 2018 11:42:13 +0000

Thanks, Chris.  One reply inline.

--aaron

On 18 Mar 2018, at 11:36, Christopher Wood wrote:

>> I think it’s missing a statement describing why you chose this set 
>> of protocols. You point out why you don’t include auth-only 
>> protocols but why (only) these?
>

The set looks a little random but I’m not knowledgable and perhaps 
that’s a misimpression.  Like, why include MinimalT?  Does anyone use 
it?

>
>> Are you including all of the IETF transport security protocols? If 
>> not, why not? For the non-IETF protocols, why these? The intro to Sec 
>> 3 says they are “security protocols that are currently used to 
>> protect data”.
>
> As discussed a while back, we are including any and all transport 
> security protocols, inside and out of the IETF. We could probably 
> clean up the rationale a bit to make that necessary condition more 
> clear.
>>
>>
>> Terminology (sec 2):
>>
>> • > Is ‘network security layer’ a well-defined term? Does it 
>> mean something like “a security service provided by the network 
>> layer to the transport layer”? Maybe worth including a definition.
>>
> Agreed. I 
> filed https://github.com/mami-project/draft-pauly-transport-security/issues/24.
>>
> Yes — 
> see https://tools.ietf.org/html/draft-friel-tls-over-http-00 as an 
> example.
>>
>> •
>> gQUIC (sec 3.4)
>> RFCs take a long time to publish and live forever. Given that, does 
> In my opinion, it makes sense to document gQUIC. The crypto core and 
> integration are fundamentally different and deserving of their own 
> section.
>>
>>
>> MinimalT (sec 3.5)
>> Seems odd to me that it is “built on top of a widespread directory 
>> service” but the directory service isn’t identified.
>
> We can certainly go into more details here. I 
> filed https://github.com/mami-project/draft-pauly-transport-security/issues/23.
>>
>>

---

From: Christopher Wood <[email-masked]>
Date: Sun, 18 Mar 2018 11:46:13 +0000

On Mar 18, 2018, 11:42 AM +0000, Aaron Falk <[email-masked]>, wrote:
> The set looks a little random but I’m not knowledgable and perhaps that’s a misimpression. Like, why include MinimalT? Does anyone use it?
As far as I know, no. Though the design is sufficiently unique that we felt it best to include. Also, it shares features and inspired designs of newer ((more) widely used) protocols. (I’m speaking of 0-RTT handshakes here.)

Best,
Chris