Add support for exporters on SHA 384 cipher suites

ASSIGNED
Assigned to

Status

NSS
Libraries
P3
normal
ASSIGNED
2 years ago
7 months ago

People

(Reporter: mt, Assigned: mt)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

2 years ago
We do absolutely the wrong thing for exporting when the PRF hash is SHA-384.

See bug 1310061 for details.
(Assignee)

Comment 1

2 years ago
Created attachment 8806201 [details] [diff] [review]
bug1312976.patch

Bob, we recently discovered that Elio's work on implementing AES-256-GCM and SHA-384 was incomplete.  This makes the TLS 1.2 PRF more generic (it takes a hash argument).  Can you check that my pk11 code isn't completely bonkers?
Assignee: nobody → martin.thomson
Status: NEW → ASSIGNED
Attachment #8806201 - Flags: review?(rrelyea)
(Assignee)

Comment 2

2 years ago
Oh, to be clear here, I am treating mechanisms as requiring ABI compatibility.  On that basis, none of the existing mechanisms are usable here.  The only one to take a variable hash function also limits the size of its output (to the size of the TLS Finished).

Comment 3

2 years ago
if we have problems with the mechansims as defined, we should submit patches back to the OASIS spec rather than define yet another NSS specific version.
(Assignee)

Comment 4

2 years ago
Note that the existing mechanisms I'm talking about are also NSS internal mechanisms.
(Assignee)

Comment 5

2 years ago
Oh, and I think that we should ask OASIS for help here, but TLS 1.3 is a moving target, and clearly TLS 1.2 never got the proper treatment.
(Assignee)

Comment 6

a year ago
OK, this is just a safeguard for the moment.

https://hg.mozilla.org/projects/nss/rev/5a2b0e8da4e1b59c64f5bd8b9256116a753aff70

Updated

7 months ago
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.