Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-profiles: strict privacy

[Bob Harold <[e-mail]>]

On Thu, Oct 27, 2016 at 12:43 PM, Sara Dickinson <[e-mail]> wrote:

>
>
> I didn’t get any further feedback on this so didn’t include the text in
> the next version (which I really should have). I’d like to think we could
> work on improving this text to paint the correct picture of the 2 classes
> of user and which profile is most suitable for them?
>
>
> I apologize for not giving feedback at the time; I was waiting for other
> people to chime in and then forgot.
>
>
> My bad, I should have included the text regardless.
>
>
> That text is really good. However, instead of at the end of Section 4, I
> would put it right after Table 1, replacing "Since Strict Privacy provides
> the strongest privacy guarantees it is preferable to Opportunistic Privacy”.
>
>
> Yes indeed - I meant at the end of section 4.2 which is exactly there.
>
>
>
> Also: why is "hard failure" the fourth bullet describing Opportunistic
> Privacy? That would only apply to Strict Privacy, correct?
>
>
> Not necessarily. From RFC7435: “Opportunistic security protocols may
> hard-fail with peers for which a
>   security capability fails to function as advertised. “
>
>
> Yes, I saw that there, but it makes no sense in this document because we
> explicitly allow for both going to no TLS and not telling the user about
> whether TLS is in use. I think that bit in RFC 7435 only applies to systems
> where the user sees that TLS is in use. We really should take it out of
> this document; otherwise, we have to add in a lot more about users knowing
> about the use of TLS.
>
>
> So I’m not sure here. The aim here was to try to keep this section
> flexible in terms of the interpretation of OS but perhaps this needs
> discussion.
>
> RFC 7435 says "An OS protocol first determines the capabilities of the
> peer with which it is attempting to communicate.  Peer capabilities may be
> discovered by out-of-band or in-band means.  (Out-of-band mechanisms
> include the use of DANE records….”
> and then allows for the hard failure if the capability isn’t as described.
> So this seems to leave the door open for clients to choose to hard-fail in
> certain circumstances which seem relevant to this document (I don’t see any
> caveats about this only happening if users know what is going on). It seems
> overkill to completely override that here with something like
> "Opportunistic clients MUST fallback to clear text…” unless there is
> consensus that that is how it should work for DNS in all cases?
>
> Sara.
>
>
It seems that there are levels of Opportunistic Security (OS), either
falling back to TLS to an un-authenticated server, or falling back to clear
text (no TLS).  We should make it clear that there are various levels, and
that there should be some way to choose what minimum level is allowed.

-- 
Bob Harold