Subject: Re: [Taps] I-D Action: draft-ietf-taps-transport-security-03.txt

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 1 Nov 2018 16:34:53 -0500

Hi, Christopher,

On Sat, Oct 27, 2018 at 12:08 AM Christopher Wood <
[email-masked]> wrote:

> Hi Aaron,
>
> On Fri, Oct 26, 2018 at 10:46 AM Aaron Falk <[email-masked]> 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 about
>> Theresa's comments in Bangkok first?
>>
>
> It is not yet ready. We will send it to SecDir when that changes. I don’t
> think Theresa’s comments are blockers here. (I’ll 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/taps
>>
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps
>

---

From: "Christopher Wood" <[email-masked]>
Date: Sun, 04 Nov 2018 07:33:35 +0700

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:
>>
>>
>> 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.

>> 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.

>> 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.

>> 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: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 4 Nov 2018 09:34:53 +0700

Just following up ...

>> 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

---

From: Christopher Wood <[email-masked]>
Date: Mon, 5 Nov 2018 01:05:01 +0000

On Sun, Nov 4, 2018 at 2:35 AM Spencer Dawkins at IETF
<[email-masked]> wrote:
>
> Just following up ...
>
> On Fri, Nov 2, 2018 at 4:34 AM Spencer Dawkins at IETF <[email-masked]> wrote:
>>
>> Hi, Christopher,
>>
>> On Sat, Oct 27, 2018 at 12:08 AM Christopher Wood <[email-masked]> wrote:
>>>
>>> Hi Aaron,
>>>
>>>> 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 about Theresa's comments in Bangkok first?
>>>
>>>
>>> It is not yet ready. We will send it to SecDir when that changes. I don’t think Theresa’s comments are blockers here. (I’ll 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.
>

Thanks, Spencer! We will kick things off this week.

Best,
Chris