Subject: Re: [Model-t] Model-t Perspective and Method Questions

From: Stephen Farrell <[email-masked]>
Date: Thu, 7 Nov 2019 17:25:50 +0000

Hi Ali,

Sorry for the slow response, I had a bunch of travels...

On 23/10/2019 15:42, Rezaki, Ali (Nokia - DE) wrote:
> If this perspective would make sense, would it be helpful then to
> initially work on:
> 
> 1. Examples of attacks that exploited vulnerabilities in IETF
> protocols that could not have been prevented by the current threat
> model in BCP 72, and in what way the threat model in BCP 72 could be
> modified to address these vulnerabilities?

I think that'd be really useful. I'd say documenting those
however you find easiest would be fine - no need to worry
about stuff being in Internet drafts for now anyway.

If doing that you might also want to note cases where the
vulnerability was in the implementation or deployment but
where (perhaps) some change to IETF protocols might have
made exploitation harder. I guess heartbleed might be the
canonical example there: had the TLS hearbeat response
been e.g. a hash of the request then the implementation flaw
might not have been near as bad, and IIRC we nearly did
(but didn't quite) stumble on that change in IESG discussion
of what became RFC6520, so I feel a little responsible
myself for not spotting that then;-(

> 2. Requesting information from related IETF contributors about a map
> of areas that IETF considers to be in scope for its work, and its
> evolution over the years, also identifying the underlying
> principles?

Not as sure about that one - I suspect it could be a major
time sink for you and it might be hard to get people to help
you get it done.

Hope that helps,
S.

---

From: "Rezaki, Ali (Nokia - DE)" <[email-masked]>
Date: Fri, 8 Nov 2019 16:59:58 +0000

Hi Stephen,

Thanks very much for your feedback. It has been very helpful.

I will then start with documenting the attacks that exploited vulnerabilities in IETF protocol specifications, covering also implementation and deployment vulnerabilities, with an eye on mitigation options.

Thanks also for mentioning the heartbleed case for a start. I would appreciate it if other colleagues would also be able to send me pointers to additional cases.

Looking forward to good discussions in Singapore.

Cheers,

Ali

-----Original Message-----
From: Stephen Farrell <[email-masked]> 
Sent: Thursday, November 7, 2019 6:26 PM
To: Rezaki, Ali (Nokia - DE) <[email-masked]>; [email-masked]
Subject: Re: [Model-t] Model-t Perspective and Method Questions

Hi Ali,

> modified to address these vulnerabilities?

I think that'd be really useful. I'd say documenting those however you find easiest would be fine - no need to worry about stuff being in Internet drafts for now anyway.

If doing that you might also want to note cases where the vulnerability was in the implementation or deployment but where (perhaps) some change to IETF protocols might have made exploitation harder. I guess heartbleed might be the canonical example there: had the TLS hearbeat response been e.g. a hash of the request then the implementation flaw might not have been near as bad, and IIRC we nearly did (but didn't quite) stumble on that change in IESG discussion of what became RFC6520, so I feel a little responsible myself for not spotting that then;-(

> evolution over the years, also identifying the underlying principles?

Not as sure about that one - I suspect it could be a major time sink for you and it might be hard to get people to help you get it done.

Hope that helps,
S.