> On Oct 11, 2016, at 6:11 AM, Martin Thomson <[email protected]> wrote:
>
> On 10 October 2016 at 20:24, Martin Rex <[email protected]> wrote:
>> The description of the problem sounds vaguely familiar.
>>
>> https://www.ietf.org/mail-archive/web/dane/current/msg03737.html
>
> If only they had listened eh? And they went ahead and published anyway.
I am confused as to what "they went ahead anyway" this references.
The linked message from 2011, was part of the discussion of RFC6698.
RFC6698 makes no mention of eliding hostname checks. The UKS issue
that is the subject of this thread pertains to RFC7671, work on which
did not begin until May of 2013, and which was published in Oct 2015.
> I didn't do a complete search of mailing list archives when writing
> this. Unsurprisingly, your concerns turned out to be well-founded.
Well, the UKS issue is rather narrowly applicable to special TLS
applications in which cross-origin concerns apply. That's
basically just browsers, and browsers are not doing DANE, and
certainly not DANE-EE(3).
No browsers support DANE at this time. One of the recommendations
of RFC7671 is that in each DANE application a decision be made
whether to support PKIX-TA(0)/PKIX-EE(1) or alternatively
DANE-TA(2)/DANE-EE(3). One might expect DANE in browsers to
only support the PKIX-?? TLSA variants...
Also, as the draft notes, DNSSEC record discovery for DANE with
HTTPS will likely be server-mediated (via TLS extensions), which
entirely addresses the issue, since the TLSA record is then signed
by the EE key.
In any case, the suggested remediation in the UKS draft is too
broad. It needlessly requires name checks across the board,
even in applications where none UKS is not a concern. It
consequently substantially limits the applicability of RFC7250
raw public keys.
While I support the publication of the draft, I'd like to see
the recommendations changed from MUST check names to SHOULD
check names. Or, if you prefer, MUST unless UKS is not a concern.
As I mentioned, OpenSSL 1.1.0 performs name checks for all
DANE certificate usages by default, but provides a flag
to disable them for usage DANE-EE(3). The documentation
of the flag notes the UKS issue.
--
--
Viktor.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
