[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 5 Feb 2013 11:22:39 -0700
From: Vincent Danen <vdanen@...hat.com>
To: oss-security@...ts.openwall.com
Cc: kseifried@...hat.com, cve-assign@...re.org
Subject: Re: CVE request: TLS CBC padding timing flaw in
various SSL / TLS implementations
* [2013-02-05 12:45:48 -0500] cve-assign@...re.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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
