<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></div></blockquote><div><br></div><div>It could just be that a user is caught in the TTL window after a switch and the IP has already been assigned to another TLS endpoint. This would cause a pin failure. The client *could* use a pin failure as a signal to flush the DNS cache and try again. I think we hold on to these IPs for a bit after we switch to new ones, so I’m confused how this is still happening though.</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;">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>I don't think 1) makes sense.<br><br>Thanks,<br>Monica</div></blockquote></div><br></body></html>