Re: [dns-privacy] Stephen Farrell's Discuss on draft-ietf-dprive-dns-over-tls-07: (with DISCUSS and COMMENT)

["Wessels, Duane" <[e-mail]>]

Hi Stephen,


> On Mar 9, 2016, at 6:19 AM, Stephen Farrell <[e-mail]> wrote:
> 
> (1) 4.2: Why didn't you just mandate one way of calculating a
> fingerprint as being mandatory to implement? (E.g. a sha256 hash of
> the DER encoded SPKI?)

I don't think that was intentional.  Happy to add it as a requirement.

   Implementations of this privacy profile MUST support the calculation
   and representation of a fingerprint as the SHA-256 [RFC6234] hash of
   the DER-encoded ASN.1 representation of the Subject Public Key Info
   (SPKI) of an X.509 certificate.  Additional fingerprint types MAY
   also be supported.



> and why is the "don't pin to a CA" rule in
> appendix A not a MUST in the body of the document?

The appendix essentially says "service-specific private CA: good. public CA: bad"

I don't think we can make it a MUST because (a) how do you enforce that and
(b) we don't expect the DNS client to differentiate between private/public CAs.

> Wouldn't it be
> better to do both of those?

Sorry, I'm not sure what you mean by "do both of those"?

> (Or to say why you're not doing them,
> e.g. if current implementations do different things.) Given that
> recursives publishing PINs will pick something, having that
> something supported by all clients would seem like a fine thing.

I agree that it might be better to move the sentence below from the appendix
to the main body.

   Operators of a DNS-over-TLS service in this profile are
   expected to provide pins that are specific to the service being
   pinned (i.e., public keys belonging directly to the end-entity or to
   a service-specific private CA) and not to public key(s) of a generic
   public CA.



> 
> (2) Section 5: Is it ok to (almost:-) recommend TLS false start like
> that?  Don't you need to at least point out that that has additional
> requirements over and above RFC7525? I've not checked those in
> detail though, as I'm waiting for the TLS WG to do their publication
> request for false start. If you've done that checking, then you
> might be just able to say "yeah, that's not a problem" but I'd like
> to know since implementers here are likely to read this as saying
> "Do RFC7525 and you're good."

I don't know.  I need to defer to TLS experts on this one.

This may be a case where the risks (of getting it wrong) outweigh the benefits
(of sometimes lower latency) so maybe it should be removed?

DW