Re: [Taps] Comments on draft-ietf-taps-transport-security-01

[Gorry (erg)]

Just on the discovery of PMTU...

On 23 May 2018, at 06:36, Michael Welzl  wrote:

>>> Section 3.2.3: Path MTU Discovery surprised me here. What does that mean?
>> That DTLS relies on an application implementing PMTUD (as it’s over UDP),
>> and then telling DTLS about it? Doesn’t DTLS do this on its own? Why not?
>> Sorry for asking a DTLS question, surely it’s me… but just listing PMTUD as
>> a dependency isn’t a good enough explanation, I think.
>> 
>> Clients have to set the maximum DTLS fragment (record) size, as each record
>> must fit within a single datagram.
> 
> Oh, wow, so it is true -- you have to do PMTUD in your application to 
> properly use DTLS??
> Note the previous comment from Mikael Abrahamsson in his email about minset: 
> he wondered if a TAPS system should offer PMTUD.
> If using DTLS is such a hassle, maybe the answer should be yes?   (being 
> application-independent, for UDP, I think this could only be done with a 
> mechanism such as draft-ietf-tsvwg-datagram-plpmtud )
> Sorry for the digression!
> 
> Cheers,
> Michael

That is fine - the reality is you do not need PMTUD. However, if you choose a 
low PMTU this impacts efficiency.

If you use a larger PMTU - then you impact robustness - unless you provide 
black hole detection. That does not help efficiency, for that the endpoint 
would need to probe. If the transport system  offered PMTUD the system could do 
this with the Apps blessing, but likely without the Apps involvement.

The difference between tcp and udp  is that the API needs to support this. This 
is needed for the stack to do PMTUD. Otherwise an app could ask the stack to do 
black hole detection. Some apps may instead just do all the PMTUD via an API. 
That is three ways of working. All of which can be used with Dplpmtud.


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

Re: [Taps] Comments on draft-ietf-taps-transport-security-01

[Michael Welzl]

Hi,


> On May 22, 2018, at 8:13 PM, Christopher Wood  
> wrote:
> 
> Hi Michael,
> 
> Many thanks for reading the document and taking time to provide comments!

> They are greatly appreciated. I've filed #33 (

Gee, thanks to you for this friendly response after getting so much work thrown 
in your face!  :)   seriously, sorry for this!
I’m only keeping and answering things that I think call for an answer - 
everything I removed has my implicit positive ACK…
and I mark my response with [MW].


>> Similarly, what is the rationale for making some features mandatory and
> some optional in section 4? Reasons for this choice should be explicitly
> laid out at the beginning of section 4.
> 
> In general, our rationale for mandatory features is that they were offered
> by most popular protocols and are "critical" for the security protocol to
> operate correctly. Optional features are those protocols can work around.

[MW] I think that’s fine - but please state this in the draft.


>> This brings me to the next issue: I think there’s a terminology problem
> with this document. The terminology section, in line with all other TAPS
> documents, mentions “confidentiality” as an example of a “Transport
> Feature”. Further down, “Security Feature” is introduced. Given the
> description of Transport Feature, a Security Feature is a special case of a
> Transport Feature. Maybe the first sentence of the Security Feature
> definition could be changed to say “A Transport Feature that a network
> security layer provides to applications.”  Section 3 then talks about
> “Protocol features”; these are maybe not offered to applications, so I
> think it’s fine to use this term, but you should also define it in the
> Terminology section. Then, Section 5 talks about Transport Security
> Protocol Interfaces - but that term isn’t defined anywhere. I think these
> “interfaces” are really Security Features, no?
> 
> Not quite. They're interfaces to the security protocols. Those interfaces
> may of course drive or control certain features.

I see where you’re coming from… but the way the terminology is, and was 
interpreted in other TAPS documents so far, is that “provides to applications” 
in the phrase "a specific feature that a network security layer provides to 
applications” really means that this is visible in the API. You already use the 
(new) term “protocol feature” to talk about things that may not be visible in 
the API. Do you need yet another term, then?  If so, maybe you should define 
“Interface” in the Terminology section too to clarify how this is different.


>> Section 3.2.3: Path MTU Discovery surprised me here. What does that mean?
> That DTLS relies on an application implementing PMTUD (as it’s over UDP),
> and then telling DTLS about it? Doesn’t DTLS do this on its own? Why not?
> Sorry for asking a DTLS question, surely it’s me… but just listing PMTUD as
> a dependency isn’t a good enough explanation, I think.
> 
> Clients have to set the maximum DTLS fragment (record) size, as each record
> must fit within a single datagram.

Oh, wow, so it is true -- you have to do PMTUD in your application to properly 
use DTLS??
Note the previous comment from Mikael Abrahamsson in his email about minset: he 
wondered if a TAPS system should offer PMTUD.
If using DTLS is such a hassle, maybe the answer should be yes?   (being 
application-independent, for UDP, I think this could only be done with a 
mechanism such as draft-ietf-tsvwg-datagram-plpmtud )
Sorry for the digression!

Cheers,
Michael

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

Re: [Taps] Comments on draft-ietf-taps-transport-security-01

[Christopher Wood]

Hi Michael,

Many thanks for reading the document and taking time to provide comments!
They are greatly appreciated. I've filed #33 (
https://github.com/mami-project/draft-pauly-transport-security/issues/33)
to address them. Please see inline below for responses.

Best,
Chris

> The main problem that I see is a missing "red thread” - e.g. when
deriving the security features in section 4: as a reader, I would expect
there to be a 1:1 mapping from the protocol features in section 3 to the
security features in section 4, yet there isn’t. For example: sec. 3.10,
CurveCP, has, in sec. 3.10.2, protocol features such as “1-RTT session
bootstrapping” and “Sender-chosen explicit nonces, …”, and these are not
listed in section 4 as such. I guess this is okay because “Protocol
features” are internal details, not exposed to an application? But then
this should be made clear in section 3, and the security features that we
see listed in section 4 should be listed in sec. 3 per protocol with the
same wording so that we can see a connection from section 3 to section 4.

Excellent point. Tying the two together will go a long way in making
selection for mandatory and optional protocol features more clear.

> Similarly, what is the rationale for making some features mandatory and
some optional in section 4? Reasons for this choice should be explicitly
laid out at the beginning of section 4.

In general, our rationale for mandatory features is that they were offered
by most popular protocols and are "critical" for the security protocol to
operate correctly. Optional features are those protocols can work around.

> Maybe the reason can be derived from section 5… see below:

> Once you’ve laid out the “interface” (I’ll come to that) as you do in
section 5, just from looking at this list, it’s easy to see that TLS gives
us everything except:
> - Authentication Delegation
> - Explicit (as opposed to “direct”) pre-shared key import
> - Transport mobility
> … and none of these are mandatory according to section 4 (so maybe that
could be seen as a reason to not make them mandatory?). TLS could be a
general recommendation, combined with an explanation that, if you want one
of these things listed above, you need to implement a protocol other than
TLS, but then you need to be aware of the protocol dependencies that such a
protocol choice brings with it.

> Generally, as an implementer of a transport system, this document now
tells me quite clearly which features I must offer (and it tells me which
protocols I then must support). However, the trade-offs are not so clear. I
see trade-offs in the protocol dependencies that you list in section 3;
then there are Transport Dependencies listed in section 4, but only for the
optional features, and it says “None” almost everywhere… yet, in section 3,
there are tons of “Protocol Dependencies”, so I find this surprising.

Indeed. These sections fell out of sync. I'll fix that.

> Another missing “red thread”: why do the transport features have
different names in sections 4 and 5? I would expect to find “Transport
mobility” in section 4, but there it’s “Connection mobility”. Similarly,
I’d expect to find “Session cache management” (from sec. 5.1) in section 4,
but there it’s called “Session caching and management”. I think the whole
document would look much more uniform and better structured with some
clearer mappings - from section 3 to the listed security features in
section 4 and the “interfaces” in section 5.

This is a simple oversight. In addressing your first comment, I'll make we
unify the terminology too.

> This brings me to the next issue: I think there’s a terminology problem
with this document. The terminology section, in line with all other TAPS
documents, mentions “confidentiality” as an example of a “Transport
Feature”. Further down, “Security Feature” is introduced. Given the
description of Transport Feature, a Security Feature is a special case of a
Transport Feature. Maybe the first sentence of the Security Feature
definition could be changed to say “A Transport Feature that a network
security layer provides to applications.”  Section 3 then talks about
“Protocol features”; these are maybe not offered to applications, so I
think it’s fine to use this term, but you should also define it in the
Terminology section. Then, Section 5 talks about Transport Security
Protocol Interfaces - but that term isn’t defined anywhere. I think these
“interfaces” are really Security Features, no?

Not quite. They're interfaces to the security protocols. Those interfaces
may of course drive or control certain features.

> Actually, given that they seem to be the same but with slightly different
wording, I wonder if sections 4 and 5 could be merged … or maybe they
should be switched in order: section 5 should appear first, calling them
Security Features, and then what is now Section 4 could come after,
deriving which ones of them are mandatory and optional, as well as list
transport / application