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

[Stephen Farrell <[e-mail]>]

Hiya,

On 09/03/16 22:24, Wessels, Duane wrote:
> 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.

That's great thanks. You maybe want to mention the base64 encoding
too if you want that to end up exactly as per Appendix A.

> 
> 
> 
>> 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.

Ok, fair point.

> 
>> Wouldn't it be
>> better to do both of those?
> 
> Sorry, I'm not sure what you mean by "do both of those"?

Never mind - bad phraseology from me;-)

> 
>> (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.
> 

Fair enough.

> 
> 
>>
>> (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?

Some people will prefer the latency gain though as we know.

I think in this case all you need to do is highlight that false
start has requirements over and above 7525, e.g. by saying:

"Implementations supporting TLS false start need to be aware
that imposes additional constraints on how one uses TLS,
over and above those stated in BCP195. It is unsafe to use
false start if your implementation and deployment doesn't
adhere to these specific requirements. See [false-start]
for details of those additional constraints."

Cheers,
S.

PS: If the above changes are acceptable then my DISCUSS will
be sorted.



> 
> DW
> 
>