Re: [dane] DANE-SRV, SNI functional equivalent and XMPP

[Peter Saint-Andre - &yet <[e-mail]>]

On 5/20/15 1:04 AM, Viktor Dukhovni wrote:
> On Tue, May 19, 2015 at 07:46:07PM -0700, Peter Saint-Andre - &yet wrote:
>
> [ Sorry, I'm on the road, and cycles are limited.  ]

Same here. :-)

>>>> NEW
>>>>     SRV is secure:  The reference identifiers SHALL include both the
>>>>        service domain and the SRV target server host name (e.g., include
>>>>        both "im.example.com" and "xmpp23.hosting.example.net").  The
>>>>        service domain is still the preferred name for TLS SNI or its
>>>>        equivalent (this reduces code complexity and the possibility of
>>>>        interoperability problems).
>>>
>>> I object.  The fix is to delay the decision until the presence of
>>> TLSA records has been checked.
>>
>> Viktor, the text in question is from ?4.1, which begins as follows:
>>
>>     4.1.  SRV Records Only
>>
>>     If the client received zero usable TLSA certificate associations...
>
> In that case, this is a pure legacy use-case, and no incompatible
> behaviour should be introduced.

Yes, agreed. Thus I think it's safest to recommend sending the service 
domain in both SRV-only, non-TLSA cases, as in the adjusted text above.

>> The whole point of 4.1 is to address the case where we have SRV records and
>> no usable TLSA records. Naturally, the client can't know that it has no
>> usable TLSA records "until the presence of TLSA records has been checked" as
>> you say. I'd agree with you if we were proposing to change text in 4.2, but
>> we're not, so I don't see the force of your objection.
>
> I did not get a chance to read the text in context.  Adding the target name
> as a secondary indentifier is fine, but indeed the SNI name should not
> change absent signalling via TLSA RRs.

OK, great, then I think we're in agreement.

Peter

-- 
Peter Saint-Andre
https://andyet.com/