Closed Bug 1323104 Opened 8 years ago Closed 7 years ago

Add support for experimental TLS 1.3 short header extension

Categories

(NSS :: Libraries, defect)

Product:
NSS
Component:
Libraries
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: ekr, Unassigned)

References

Details

Backed out for build bustage
This did land. https://hg.mozilla.org/projects/nss/rev/c0f11838ab65
Flags: needinfo?(martin.thomson)
We need to uplift this to 3.28 so we can put 3.28 on FF 51 (which I am getting approval for now). Kai? Process? Objections?
Flags: needinfo?(kaie)
(In reply to Eric Rescorla (:ekr) from comment #3) > https://hg.mozilla.org/projects/nss/rev/c0f11838ab65 (In reply to Eric Rescorla (:ekr) from comment #4) > We need to uplift this to 3.28 so we can put 3.28 on FF 51 (which I am > getting approval for now). > > Kai? Process? Objections? I'm surprised you want to do that, but besides doing this very large uplift while we're in mozilla-beta phase, I currently cannot think of an argument against it. The initial three chunks of the patch (to gtests) don't apply cleanly, but it's just a context problem, and I just merged them manually, and it builds. As I had mentioned in another private email recently, before we uplift to beta, we must complete the official release process of NSS 3.28, so that consumers of firefox beta, who build NSS separately, are able to find the required NSS release archive. We are slightly late with finalizing 3.28, because I had to land more functional changes into the 3.28, less than 2 days ago, and our usual rule is, that we wait one week, before declaring an NSS release as stable. So, I'd be ready to land an NSS 3.28 release candidate into aurora 52 by monday. If that goes without trouble (and a try build from yesterday suggests it should be fine), we could declare the release as final by wednesday dec 21, and this could be also the day to uplift to the beta 51 branch. Would that timing work for you? Where did you ask for nss 3.28 uplift to beta 51, do you have a tracking bug for that already? If not, maybe we could extend bug 1305970, and you could ask for beta approval in that bug, too?
Flags: needinfo?(kaie)
(In reply to Kai Engert (:kaie) from comment #5) > We are slightly late with finalizing 3.28, because I had to land more > functional changes into the 3.28, less than 2 days ago, and our usual rule > is, that we wait one week, before declaring an NSS release as stable. Well, and this also means, if you land this change into the 3.28 branch now, our usual rules would require that we start testing this snapshot with some firefox branch immediately, and then wait one week before we declare that nss version as final. In other words, if you land this patch in the 3.28 branch by saturday, you'd have to get approval to uplift this additional functional change into aurora 52, also get that landed into aurora asap during the weekend. And once that is done, the one week timer towards the final 3.28 starts to tick. Which would mean, we couldn't declare the 3.28 as final, and couldn't uplift into beta 51 prior to dec 24 as the earliest. Doing things earlier requires that we violate our usual rules (either wait less than one week before declaring 3.28 as final, or uplifting into beta 51 while 3.28 hasn't been declared as a final release yet).
Right(In reply to Kai Engert (:kaie) from comment #5) > (In reply to Eric Rescorla (:ekr) from comment #3) > > https://hg.mozilla.org/projects/nss/rev/c0f11838ab65 > > (In reply to Eric Rescorla (:ekr) from comment #4) > > We need to uplift this to 3.28 so we can put 3.28 on FF 51 (which I am > > getting approval for now). > > > > Kai? Process? Objections? > > I'm surprised you want to do that, but besides doing this very large uplift > while we're in mozilla-beta phase, I currently cannot think of an argument > against it. Yeah, we just don't get much testing value out of Aurora, and we do badly need to test this change. > The initial three chunks of the patch (to gtests) don't apply cleanly, but > it's just a context problem, and I just merged them manually, and it builds. > > As I had mentioned in another private email recently, before we uplift to > beta, we must complete the official release process of NSS 3.28, so that > consumers of firefox beta, who build NSS separately, are able to find the > required NSS release archive. > > We are slightly late with finalizing 3.28, because I had to land more > functional changes into the 3.28, less than 2 days ago, and our usual rule > is, that we wait one week, before declaring an NSS release as stable. Well, we already have a bunch of experience with 3.28 minus this patch in Aurora, so I think we could potentially waive this rule. Alternately, we can just declare 3.28 final and then land this experiment as a local patch in Firefox. That would actually not be crazy given that it's not really something we expect people to exercise in their own NSS builds (it will be in the code but will be disabled in a way you can't really turn on via standard APIs.) > So, I'd be ready to land an NSS 3.28 release candidate into aurora 52 by > monday. If that goes without trouble (and a try build from yesterday > suggests it should be fine), we could declare the release as final by > wednesday dec 21, and this could be also the day to uplift to the beta 51 > branch. > > Would that timing work for you? Yes. > Where did you ask for nss 3.28 uplift to beta 51, do you have a tracking bug > for that already? If not, maybe we could extend bug 1305970, and you could > ask for beta approval in that bug, too? It was in private e-mail. I will do as you suggest tomorrow AM.
Clearing n-i. If I missed something, let me know.
Flags: needinfo?(martin.thomson)
OK, landing this in m-c showed that this is busted. I'll have a fixup patch ready for review in a few minutes. ekr, you will have to get this landed in 3.28 and all the other places. The issue is twofold: 1. The client sends this unconditionally, even if it only wants TLS 1.2. 2. The server kills the handshake if it sees this, even if it negotiated TLS 1.2 because it was configured that way. We're generating a TLS 1.2 ClientHello in the mochitest that I tested. I don't know why, maybe I was looking at a fallback handshake. That triggers problem 1. More generally, TLS 1.2 is the default version for the server, which leads to problem 2.
Blocks: 1317947
Adding some people to CC, please see previous comment.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.