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

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

> On Mar 10, 2016, at 12:41 AM, Stephen Farrell <[e-mail]> wrote:
> 
> 
> 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.

Okay, it says this now:

   Implementations of this privacy profile MUST support the calculation
   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.  Implementations MUST support the representation
   of a SHA-256 fingerprint as a base 64 encoded character string
   [RFC4648].  Additional fingerprint types MAY also be supported.


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

That sentence has now been moved to the opening paragraph of 4.2.


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

I've added this with just minor edits, thanks.


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

The link below will take you to an rfcdiff of all the changes since starting IESG evaluation

http://goo.gl/Wwsr7M

DW