Subject: [mile] Eric Rescorla's No Objection on draft-ietf-mile-rolie-11: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Oct 2017 13:29:23 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-mile-rolie-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mile-rolie/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

OVERALL
I share Martin Thomson's concerns about the restriction on 0-RTT. In
the discussion, I saw two sets of concerns about 0-RTT:

- Replay
- Lack of FS

As Martin says, the replay issue is an issue for the HTTP profile, so
any concerns should be directed there. I agree that 0-RTT has inferior
FS properties, but it's worth noting that TLS 1.2 session resumption
with tickets has FS properties that are as bad or worse than those
with TLS 1.3 0-RTT, and I don't see a prohibition here on session
resumption. This leaves me a bit unclear on the security rationale
here, and I think this needs to be consistent.

INLINE COMMENTS
      or serialization.  This approach allows the provider to support
      multiple, compatible formats allowing the consumer to select the
      most suitable version.
What does "compatible" mean here. Do you mean isomorphic?

   supporting interactive user logins by members of the consortium
   SHOULD support client authentication via a federated identity scheme.
Such as?

   Proper usage of TLS as described in Section 5.3 will in many cases
   aid in the mitigation of these issues.
You should also note that TLS 1.2 and lower client auth leaks the user's
identity to on-the-wire attackers.

   supported.  TLS 1.2 SHOULD be implemented according to all
   recommendations and best practices present in [RFC7525].
You need a citation to 6125 about valiation, though I realize that 7525 cites
it.

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 21 Oct 2017 07:08:23 -0400

Hi EKR,

Thanks for your review.

Sent from my iPhone

> On Oct 20, 2017, at 4:29 PM, Eric Rescorla <[email-masked]> wrote:
> 

We upgrade to new protocols with the aim of improving security.  I think that's a fine assumption for the WG.

The profile isn't far enough along at this point and isn't necessary if they just want to ensure 0-RTT is disabled.  This is a community that deals with vulnerabilities as their day job, with systems that they want hardened as much as possible to avoid issues. I know Martin mentioned wanting a test case, but that's not fair when they are not ready and have different priorities.

Best,
Kathleen 
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 21 Oct 2017 05:56:19 -0700

On Sat, Oct 21, 2017 at 4:08 AM, Kathleen Moriarty <
[email-masked]> wrote:

> The profile isn't far enough along at this point and isn't necessary if
> they just want to ensure 0-RTT is disabled.  This is a community that deals
> with vulnerabilities as their day job, with systems that they want hardened
> as much as possible to avoid issues. I know Martin mentioned wanting a test
> case, but that's not fair when they are not ready and have different
> priorities.
>

Hi Kathleen,

I don't think I'm following you. I agree that they don't need to depend on
the profile if they want to disable 0-RTT. My question is *why* they want
to disable 0-RTT. I heard two reasons cited: (1) concern about replay
attacks and (2) lack of FS. Is lack of FS in fact a concern here?

-Ekr

---

From: Kathleen Moriarty <[email-masked]>
Date: Sun, 22 Oct 2017 07:24:13 -0400

Sent from my iPhone

> On Oct 21, 2017, at 8:56 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
>> On Sat, Oct 21, 2017 at 4:08 AM, Kathleen Moriarty <[email-masked]> wrote:
>> Hi EKR,
>> 
>> Thanks for your review.
>> 
>> Sent from my iPhone
>> 
> I don't think I'm following you. I agree that they don't need to depend on the profile if they want to disable 0-RTT. My question is *why* they want to disable 0-RTT. I heard two reasons cited: (1) concern about replay attacks and (2) lack of FS. Is lack of FS in fact a concern here?

Hi EKR,

Lack of FS is a concern, so that should be added to the text.  

They don't care about the performance increase as it's not worth the trade off.  Even with mitigations, you have to worry that the developer got it right, the implementer didn't have a configuration mistake, or there's something wrong with the spec.  For sensitive data exchange, it's just a lot easier to eliminate possible threats.

Kathleen 
> -Ek

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 22 Oct 2017 06:05:06 -0700

On Sun, Oct 22, 2017 at 4:24 AM, Kathleen Moriarty <
[email-masked]> wrote:

> They don't care about the performance increase as it's not worth the trade
> off.  Even with mitigations, you have to worry that the developer got it
> right, the implementer didn't have a configuration mistake, or there's
> something wrong with the spec.  For sensitive data exchange, it's just a
> lot easier to eliminate possible threats.
>

In that case, it seems like this text ought to also recommend against using
TLS 1.2 session resumption.

-Ekr

Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Sun, 22 Oct 2017 11:50:20 -0400

Sent from my iPhone

> On Oct 22, 2017, at 9:05 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
>> On Sun, Oct 22, 2017 at 4:24 AM, Kathleen Moriarty <[email-masked]> wrote:
>> 
>> 
>> Sent from my iPhone
>> 
> In that case, it seems like this text ought to also recommend against using TLS 1.2 session resumption.

There may have been text to that effect in the version Martin reviewed and they can certainly add that or add it back.  My review had them add 7525, meaning to take out duplicative text and then they removed a bunch after Martin made the same comment.

Kathleen

---

From: "Banghart, Stephen A. (Fed)" <[email-masked]>
Date: Mon, 23 Oct 2017 20:59:51 +0000

All,

The primary issue we have with 0-RTT is the possibility of replay attacks. ROLIE is RESTful, and can accept data-altering requests.

For example, an automated ROLIE repository that updates very frequently may receive a PUT request against a given resource a few times an hour (or more). An attacker may store the first PUT request, and at the end of the resumption window replay the PUT request, reverting the resource to an old version. Not only could an attacker be doing this replay continuously to cause havoc on the server, but the client is completely unaware of the attack taking place.

The performance gain is, for us, not worth the risk of replay.

Text similar to the example and justification in this e-mail will be added to the specification to make our reasoning more clear. This should help make it clear why we think 0-RTT is undesirable for any future readers of the specification. As Martin said earlier, it’s important that we don’t lose track of the why.

Thanks,
Stephen Banghart

From: Kathleen Moriarty [mailto:[email-masked]]
Sent: Sunday, October 22, 2017 11:50 AM
To: Eric Rescorla <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mile] Eric Rescorla's No Objection on draft-ietf-mile-rolie-11: (with COMMENT)

Sent from my iPhone

On Oct 22, 2017, at 9:05 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Sun, Oct 22, 2017 at 4:24 AM, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:

Sent from my iPhone

On Oct 21, 2017, at 8:56 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Sat, Oct 21, 2017 at 4:08 AM, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:
Hi EKR,

Thanks for your review.

Sent from my iPhone

> On Oct 20, 2017, at 4:29 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data=02%7C01%7Cstephen.banghart%40nist.gov%7Ca420f00f1935428debdf08d519649d9f%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636442842295813034&sdata=ScSKg2M%2FpPQbx1BQYGEMfZMVcPuuTMA6BOYd39pC72Y%3D&reserved=0>
> https://datatracker.ietf.org/doc/draft-ietf-mile-rolie/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-mile-rolie%2F&data=02%7C01%7Cstephen.banghart%40nist.gov%7Ca420f00f1935428debdf08d519649d9f%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636442842295813034&sdata=ZS2lhxL9YYbhSy6k9AD%2FCLVGfJLP8Wgkkb5Z7kfdli8%3D&reserved=0>
>
>
>

Hi Kathleen,

Hi EKR,

Kathleen

-Ekr

Kathleen

-Ek

Best,
Kathleen
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mile<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmile&data=02%7C01%7Cstephen.banghart%40nist.gov%7Ca420f00f1935428debdf08d519649d9f%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636442842295813034&sdata=pAZI7%2FNO5YeVsgKZgoWCKb3Y5DSH5bDl7Roj2PjN2Sk%3D&reserved=0>