Subject: [Uta] Stephen Farrell's Yes on draft-ietf-uta-tls-attacks-04: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Mon, 13 Oct 2014 09:27:38 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-uta-tls-attacks-04: Yes

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 http://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:
http://datatracker.ietf.org/doc/draft-ietf-uta-tls-attacks/

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

I have a number of nits. Please treat them as such.

- Is "current" correct in the name for an RFC? Perhaps
"known" is better.

- intro, para 2: s/is tasked/was tasked/

- s2, 2nd para: "a more systemic solution" is left hanging
- do you mean TLS1.3? If so, maybe say so?

- 2.5, 2nd para: draft-ietf-tls-prohibiting-rc4 does not
itself provide those details, maybe say "see the
references in" that draft?

- 2.6: should the RFC editor wait on the official
allocation of the BEAST CVE number? I don't think that's
happened already has it? 

- 2.7, is Bleichenbacher really a certificate attack?  I
think its not, but is a pkcs#1 encryption attack.  (It
would apply just as well to OOB keys in TLS.) I'm not sure
if Klima is or is not the same in that respect.  Also the
timing attacks in the 2nd para, don't seem to be
certificate related are they? So perhaps only the last
para is really certificate related?

- 2.8: I forget if this has been discussed - should three
be a reference to draft-ietf-tls-negotiated-ff-dhe

- 2.10: isn't TRIPLE-HS published yet?

- 2.12: A reference would be good here if we have one,
esp. for the "It is known" point.

- 2.13, para1: "fully specified" isn't really correct
there, I think you mean 'properly specified, so that
implementations should be "secure"' but maybe some other
wording would be better.

- 2.13: Doesn't that paper also blame hard-to-use APIs as
well as the IETF protocols and their complexity? Worth a
mention?

---

From: Leif Johansson <[email-masked]>
Date: Mon, 13 Oct 2014 18:44:13 +0200

> http://datatracker.ietf.org/doc/draft-ietf-uta-tls-attacks/

These mostly seem ok to me (with my chair hat on) but lets see what the
authors say.

	Cheers Leif

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 13 Oct 2014 23:06:46 +0300

Hi Stephen,

Thanks for your review. Here are a few comments to your comments.

> - do you mean TLS1.3? If so, maybe say so?

Actually this is a leftover from the unified attacks+BCP draft, and 
that's what is meant.

> allocation of the BEAST CVE number? I don't think that's

BEAST is fine, this is about BREACH. the CVE number is allocated but 
that's about it, and people are citing it. I am not familiar with the 
CVE allocation procedures, for all I know it may remain 
reserved-but-unofficial forever. I certainly don't want to hold the RFC 
waiting for it.
> para is really certificate related?

You're right I believe. Need to recheck and maybe rework the title.
> - 2.10: isn't TRIPLE-HS published yet?
Yes. 
http://prosecco.gforge.inria.fr/bibtexbrowser.php?key=BhargavanDFPS14&bib=ourpubs.bib

> esp. for the "It is known" point.

[Private communication]...

http://www.ietf.org/mail-archive/web/uta/current/msg00387.html

> well as the IETF protocols and their complexity? Worth a

Personally, I don't think it's worth a mention. As they say, it is not 
"actionable".

---

From: Watson Ladd <[email-masked]>
Date: Mon, 13 Oct 2014 13:13:03 -0700

that's what is meant.
> BEAST is fine, this is about BREACH. the CVE number is allocated but
that's about it, and people are citing it. I am not familiar with the CVE
allocation procedures, for all I know it may remain reserved-but-unofficial
forever. I certainly don't want to hold the RFC waiting for it.
"actionable".

It absolutely is actionable. Don't use complex APIs, switch
implementations, and conduct negative testing.
>
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta