DTOs. Properties or fields?

The DataMember attribute will work with both public fields and properties, so either would be possible. However, I would recommend sticking with properties.

In particular, if you are using StyleCop, then you would be breaking rule SA1401.

The reason for this rule's existence doesn't really apply in your case, but it would still be a maintenance problem if you are running StyleCop validation as part of a build on a continuous integration server.

You can use either. Since it doesn't affect performance, you'd be safer off going with properties in case you run into some serialization framework or similar that doesn't work with public fields.

Note that WCF proxy generation will create those DTOs on the client side with public properties and their backing private fields, even if you use public fields on the service side. If you somehow don't want that, you need to share a DTO library between the service and the client.

Since these are just bags of data with no functionality, is there any reason I can't just use fields

There are no strong arguments against public fields here. But do realize that it is only because there is no logic (behaviour) inside the DTOs so that the normal argument of encapsulation doesn't hold.

I would still prefer properties but they're not really necessary here.

I mostly favour immutable DTOs with read-only fields if I can get away with it:

public class CustomerDTO
{
    public CustomerDTO(int id, string name)
    {
        Id = id;
        Name = name;
    }

    public readonly int     Id;
    public readonly string  Name;

    // Override Equals and GetHashCode as well...
}

There's lots of advantages to be had from immutable records, such as structural equality, which makes automated test assertions much simpler to write. It also dispenses with the need to write and maintain separate Test Data Builders.

It depends on the serializer, though. JSON.NET can handle immutable records, but many other serializers can't.

For those that handle public fields, I prefer fields over properties, simply because it's more honest; automatically implemented read/write properties provide no encapsulation.

Some serializers insist on public properties, and don't serialize fields. If that's the scenario, you have to go with that.

Honestly, considering how much thought I've put into this, it's not really something that keeps me awake at night, because ultimately, at the boundaries, applications aren't object-oriented. Thus, the rules of OOD don't really apply to DTOs anyway.