Re: [apps-discuss] Add-on for HTTPS websites

[Dave Cridland <[e-mail]>]

On Mon, Nov 18, 2013 at 9:09 AM, Walter H. <[e-mail]>wrote:

> On Mon, November 18, 2013 09:42, Dave Cridland wrote:
> > On Mon, Nov 18, 2013 at 6:02 AM, Walter H.
> > <[e-mail]>wrote:
> >
> >>
> >> Bug corrected, the example certificates were wrong.
> >>
> >> Filename: draft-hoehlhubmer-https-addon
> >> Revision: 04
> >>
> >>
> > I've skimmed this quickly, and what I think you've done here is reinvent
> > DANE, which is specified in RFC 6698.
>
> I didn't notice this RFC;
>
> > I don't *think* you're adding anything new, here,
>
> seen, the additional HTTP webpage in 2.2?
>
>
Ah. I hadn't, but the problem with this is it's only a marginal increase in
security, and given there's no formatting, it wouldn't even be possible to
test automatically.

So basically, you'd want this to be a .well-known thing in JSON or XML -
but if this were typically deployed, then any attacker who'd already
subverted everything else could easily subvert that too at little extra
cost.

I don't think that it'd be worthwhile, to be honest.


> > but I do think it's
> > always interesting when someone independently arrives at roughly the same
> > concept. I'd encourage you to read through RFC 6698, and see if there's
> > any
> > differences between your approaches that should be addressed.
>
> there is a difference: my variant uses TXT records and these are available
> on every DNS software;
>
>
Yes, I did wonder if there would be faster uptake of DANE if it were purely
in TXT records, however I suspect that the marginal difficult of adding
TLSA support in this specific case would be pretty low compared to adding
DNSSEC anyway.

Besides, DANE does TLSA; I don't think there's any evidence that TLSA
support is holding anything back right now.


> > I'd suggest you probably don't want to invest too much more time in your
> > own approach, though.
>

I should expand on this, really.

What you have done is independently come up with largely the same concept
as DANE. This is pretty awesome, and it puts you with a unique insight into
DANE. I don't want to imply that your effort so far is a complete waste of
your time. Your fundamental idea - that certificate information can be put
in DNS to increase security - is a good one, so good that it's been done
already.

However, there's no point in trying to persuade all those involved in DANE
that they should scrap their approach and go with yours - even if there was
some merit in that, you'd need a really compelling reason to do that, and I
don't think you have one. What you should instead do is figure out how to
get your higher-level ideas to work within DANE's framework, and see
whether they make sense.

One interesting point your draft makes is that you have DNSSEC as a
"SHOULD", rather than a "MUST" - I need to think considerably more about
whether running DANE without DNSSEC make sense in some cases - my gut
feeling is that it might be interesting in Certificate Usage 0 and 1 cases
(See RFC 6698 § 2.1.1) - that is, where the TLSA records indicate
constraints on PKIX.

Dave.