<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jun 27, 2014, at 4:19 PM, Monica Chew <<a href="mailto:mmc@mozilla.com">mmc@mozilla.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">----- Original Message -----<br><blockquote type="cite"><br><br>----- Original Message -----<br><blockquote type="cite">60 seconds is still a large enough window for some users to be<br>affected by DNS changes, right? We're just looking for a reason why<br>fxa might be more affected than our other properties, and "it's the<br>only service with such frequent DNS changes" seems like a decent one.<br></blockquote><br>No matter how small you set a window, there will always be someone in it :-)<br><br>Combine that with the fact that there are always resolvers in between clients<br>and our nameservers that can and will mess with things and can have their<br>own ideas about TTLs. It is less common these days but it still happens.<br><br>Do we have a page that explains the pinning we do?<br></blockquote><br><a href="https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning">https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning</a><br><a href="https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning/SiteOperators">https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning/SiteOperators</a><br><br><blockquote type="cite">Maybe for IP changes we need we different strategy? Like keeping the old IP<br>alive for a longer time? Or pin to multiple IPs during changes?<br></blockquote><br>Pinning doesn't have anything to do with IPs directly. It's just a way to assert that the site uses certificates issued by root CA X. If DNS is pointing to the wrong IP, then there are bigger problems. At this point we could either<br><br>1) Broaden the pinset (only makes sense if we think it is incorrect), or<br>2) Turn it on and wait for bugs to flow in.<br>3) Continue waiting an unbounded amount of time for SSL error reporting to be finished to diagnose the problem further.<br><br></div></blockquote><div><br></div><div>We could also add an additional domain distinction in the reporting, i.e., report pinning violations separately for:</div><div><br></div><div><a href="http://accounts.firefox.com">accounts.firefox.com</a> (serves the front end UI)</div><div><a href="http://api.accounts.firefox.com">api.accounts.firefox.com</a> (provides the authentication API)</div><div><br></div><div>Sync runs shortly after browser startup and one of the first things it does is contact <a href="http://api.accounts.firefox.com">api.accounts.firefox.com</a>. If a user is under a captive portal at browser startup, this could account for those violations. If we continue to see a large number of violations at <a href="http://accounts.firefox.com">accounts.firefox.com</a> after this reporting change, that would be curious.</div><div><br></div><div>We have other domains of interest (<a href="http://profile.accounts.firefox.com">profile.accounts.firefox.com</a> and <a href="http://oauth.accounts.firefox.com">oauth.accounts.firefox.com</a>), although they aren’t heavily used in prod right now. This means we’ll still want to enforce a *.<a href="http://accounts.firefox.com">accounts.firefox.com</a> policy going forward.</div><div><br></div><div>-chris</div><div><br></div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">I don't think 1) makes sense.<br><br>Thanks,<br>Monica</div></blockquote></div><br></body></html>