Sprints, indeed, depend on the days off. If you have ten day sprints, it's the same as having two week sprints if your team doesn't work on Saturday and Sunday.
This also means that you have to be very clear with everyone what does the duration of the sprint mean. If you tell that your sprints are ten days long, some people will understand it as two weeks, others—as one week and three days. Having a publicly available formal schedule such as:
Sprint 14: November 18th—December 2nd (10 days)
Sprint 15: December 2nd—December 18th (11 days; december 4th: attending the conference in NYC)
...
may help.
The same goes with vacations, days off and other exceptional events (such as an important power outage in your office). If you know that two of the five members of the team are on vacation for the next three weeks, there are chances you won't perform as fast as usual during the next sprint (if you do, consider firing someone).
I would suggest two options:
Option 1
Keep two weeks sprints even during holidays (unless all of your team members are not working for the entire period of a sprint), but adjust the amount of work which should be done during the sprint.
Consider how many team members are available (some may be on vacation), how critical is their presence, how would their absence impact other people, what would go wrong (for instance, Joel is the only one who knows the password of the server, and he went to Himalayas for two weeks and will not be reachable), etc.
Move the sprint date slightly if major participants cannot attend the meeting. Doing it two days later or earlier wouldn't be too much trouble, but moving it a week towards or backwards would be an issue.
Also note that moving the date of the meeting may have a negative impact on some participants who may consider that the meetings are not that important than they are. You certainly don't want one of the participants to call you later telling that you should move the meeting from today to tomorrow, because he can't attend it today, because he has done another appointment for today.
I would probably find this option more intuitive. Keeping sprints regular ensures better visibility of the project, and keeping sprints short is essential. Unless the communication between the team members is excellent, a four-weeks sprint may have a negative impact.
Moreover, team members may not remember well what they did three weeks ago (especially after holidays). Personally, I can't even remember what I did yesterday; I can take notes, but if I know that the meeting will be only in four weeks, I will be inclined much more to skip notes as well.
Option 2
Make the next sprint much longer than usual (such as four weeks vs. the usual two weeks).
This approach is better in a case where you're sure that the progress will be too small otherwise. Having nothing to say during the sprint review and the retrospective may have two negative effects:
The team members themselves may have an impression that they "did nothing" during two weeks. In that case, they may be less motivated for the next sprint.
If the customer or your boss attends the meeting and has an impression that the team wasn't working too much, this could result in even worse consequences.
