Home page logo
/

oss-sec logo oss-sec mailing list archives

Re: CVE request: TLS CBC padding timing flaw in various SSL / TLS implementations
From: Vincent Danen <vdanen () redhat com>
Date: Tue, 5 Feb 2013 11:22:39 -0700

* [2013-02-05 12:45:48 -0500] cve-assign () mitre org wrote:

cc'ing cve-assign to see if they can provide some guidance here.  I also
noticed that OpenSSL has a CVE for this (I'm assuming that the
CVE-2012-2686 issue is _not_ the same thing, but that CVE-2013-0169 is
this issue).

Since it's a weakness in TLS/DTLS itself, from my understanding, and not
necessarily in a particular implementation, I'm not sure if this
qualifies as one CVE for the weakness, or if it needs one per
implementation.

MITRE, can someone provide some guidance on this?

[ This is mostly directed to Red Hat at this point. We'll expand to
the other recipients or vendors later. ]

We're not exactly sure that MITRE has the next step here. A CVE
exists, CVE-2013-0169, that was issued by the Red Hat CNA. When the
CVE assignment was made, presumably one or more persons at Red Hat had
a working understanding of what the name CVE-2013-0169 means. (For
example: was the CVE assigned with a multi-vendor scope in mind? Was
the CVE assigned to cover the entirety of the content of the
www.isg.rhul.ac.uk/tls/TLStiming.pdf research paper?) MITRE would, in
general, want to preserve this original meaning if it makes sense to
do that. Because there's no specific statement on this list about what
CVE-2013-0169 means, we'd next go to

 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-0169

to see if that may be a canonical statement of what CVE-2013-0169
means. But there's nothing there yet.

Before offering a guess from MITRE, we'll wait for some more
information.

Yes, you're right, this did come from our pool.

We did provide this CVE to the OpenSSL team (at the time the request was
made we did not receive any disclosure on the issue and were not aware
of other affected implementations).  The intention was then just for
OpenSSL (perhaps under the assumption this was for an OpenSSL-specific
issue, again, unaware of the details of the flaw).

If MITRE wants to use it as a general name for the other affected
implementations (GnuTLS, NSS, etc.) as well, and not just OpenSSL,
that's fine.  We have not allocated any CVEs for these other
implementations, nor did we provide this CVE name to the authors of the
paper.

The long and short of it is a private (unspecified) request came from
the OpenSSL team and we provided it, so there was no specific intention
on our part as to how the name was used or what it meant.

I hope that clarifies things a bit.  We have no particular preference
either way, so we'll leave this to your discretion.

Thanks.

--
Vincent Danen / Red Hat Security Response Team

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]