Re: [dnssd] dnssd privacy draft

[Martin Thomson <[e-mail]>]

On 25 June 2016 at 05:26, Christian Huitema <[e-mail]> wrote:
> Yes. The point is, do we have the appetite to design a pairing protocol in
> this group? If we do, my preference would be to describe this pairing
> protocol in a separate draft.

Sounds like hard work :)  Might be worth doing though.

>> The requirement to use base64 isn't going to work very well with DNS.
>> Or do you expect this to work anyway?  I guess that it could if you use
> the URL
>> and filename safe variant without padding, but I wouldn't have been that
> bold.
>
> It is already a requirement for DNS SD.

OK, my fault for assuming that PTR meant that there was a domain name
in the response.

>> space, and 96 bits seems like plenty.
>
> Are you saying that specifically for the PSK identity encoding? The use of
> time stamp there provides some level of protection against replay attacks,
> described in section 6.5. Otherwise, servers will have to rely on extended
> memory of previously used PSK identifiers.

What sort of replay are you concerned about?  An attacker can replay
the ClientHello, and maybe the 0-RTT data that is included, but that's
all.  The simplest mitigation for that is to not permit 0-RTT; well,
on the first attempt anyway.  At that point, there is fresh entropy
from the server every time.

(I assume here that you aren't looking to aggressively shave every
last RTT from the protocol; you just added a bunch with the
indirection step.)

(That point on resumption makes me think: you might want to add a
fixed octet at the start of psk_identity so that a server can
distinguish between nonces and its own resumption psk_identity values.
It could distinguish based on length, I suppose, but that is a little
inconvenient.)

>> Also, you don't have to base64 the psk_identity, it's just octets, which
> allows
>> you to reclaim some of that space.
>
> Well, section 5.1. of RFC4279 says: "The PSK identity MUST be first
> converted to a character string, and then encoded to octets using UTF-8
> [UTF8]." And I see the character string requirement enforced in some of the
> TLS API. So base64 is just a way of being cautious.

Damn you 4279 for adding useless constraints!  TLS 1.3 says nothing of
the sort about the field.  Nonetheless, I understand the caution now.