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

From: "Walter H." <[email-masked]>
Date: Sun, 17 Nov 2013 19:57:08 +0100

You may be interested by the following documents:

A new version of I-D, draft-hoehlhubmer-https-addon-03.txt
has been successfully submitted by Walter Hoehlhubmer and posted to the
IETF repository.

Filename: draft-hoehlhubmer-https-addon
Revision: 03
Title: Informational Add-on for HTTP over the Secure Sockets Layer (SSL) 
Protocol and/or the Transport Layer Security (TLS) Protocol
Creation date: 2013-11-17
Group: Individual Submission
Number of pages: 24
URL: 
http://www.ietf.org/internet-drafts/draft-hoehlhubmer-https-addon-03.txt
Status: http://datatracker.ietf.org/doc/draft-hoehlhubmer-https-addon
Htmlized: http://tools.ietf.org/html/draft-hoehlhubmer-https-addon-03
Diff: http://www.ietf.org/rfcdiff?url2=draft-hoehlhubmer-https-addon-03

Abstract:
This document describes an Add-on for websites providing encrypted
connectivity (HTTP over TLS).

The Add-on has two parts, one for the Domain Name System (DNS) -
storing the X.509 certificate hashes - and one for the webserver
itself - an additional webpage providing specific informations.

-- 
Best regards,
Walter Höhlhubmer

---

From: "Walter H." <[email-masked]>
Date: Mon, 18 Nov 2013 07:02:01 +0100

Bug corrected, the example certificates were wrong.

Filename: draft-hoehlhubmer-https-addon
Revision: 04
Title: Informational Add-on for HTTP over the Secure
Sockets Layer (SSL) Protocol
and/or the Transport Layer Security (TLS) Protocol
Creation date: 2013-11-17
Group: Individual Submission
Number of pages: 24
URL:
http://www.ietf.org/internet-drafts/draft-hoehlhubmer-https-addon-04.txt
Status: http://datatracker.ietf.org/doc/draft-hoehlhubmer-https-addon
Htmlized: http://tools.ietf.org/html/draft-hoehlhubmer-https-addon-04
Diff: http://www.ietf.org/rfcdiff?url2=draft-hoehlhubmer-https-addon-04

On Sun, November 17, 2013 19:57, Walter H. wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: "Walter H." <[email-masked]>
Date: Mon, 18 Nov 2013 09:41:00 +0100

Minor formatting done, Byte Mixup corrected.

Filename: draft-hoehlhubmer-https-addon
Revision: 05
Title: Informational Add-on for HTTP over the Secure Sockets Layer (SSL)
Protocol
and/or the Transport Layer Security (TLS) Protocol
Creation date: 2013-11-17
Group: Individual Submission
Number of pages: 24
URL:
http://www.ietf.org/internet-drafts/draft-hoehlhubmer-https-addon-05.txt
Status: http://datatracker.ietf.org/doc/draft-hoehlhubmer-https-addon
Htmlized: http://tools.ietf.org/html/draft-hoehlhubmer-https-addon-05
Diff: http://www.ietf.org/rfcdiff?url2=draft-hoehlhubmer-https-addon-05

---

From: Dave Cridland <[email-masked]>
Date: Mon, 18 Nov 2013 08:42:59 +0000

> Filename: draft-hoehlhubmer-https-addon
I've skimmed this quickly, and what I think you've done here is reinvent
DANE, which is specified in RFC 6698.

I don't *think* you're adding anything new, here, 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.

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

Dave.

---

From: "Walter H." <[email-masked]>
Date: Mon, 18 Nov 2013 10:09:06 +0100

> 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?

> but I do think it's

there is a difference: my variant uses TXT records and these are available
on every DNS software;

> I'd suggest you probably don't want to invest too much more time in your

Walter

---

From: Dave Cridland <[email-masked]>
Date: Mon, 18 Nov 2013 09:48:18 +0000

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

> there is a difference: my variant uses TXT records and these are available
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

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.

---

From: "Walter H." <[email-masked]>
Date: Mon, 18 Nov 2013 12:25:03 +0100

> security, and given there's no formatting, it wouldn't even be possible to

this webpage is more for the user in front of the monitor, not any software;
especially the picked ciphersuite; there shall be an instruction for the
programmers of browsers to make this information available to the user,
too.
the intention for this is not an increase of security;

> So basically, you'd want this to be a .well-known thing in JSON or XML -
JSON, XML?

> TLSA support in this specific case would be pretty low compared to adding

would this work, when only one of the involved DNS servers doesn't support
TLSA?
I think of the fact, that DNSSEC was specified a while ago, and this is new;

> support is holding anything back right now.

the concept in this RFC is good, and compared to my variante very complex.

> as DANE.
but in comparison very simple and ready to implement;

> Your fundamental idea - that certificate information can be put

theoretically, any real implementation within the next few months is
impossible: because DANE is not just adding something to the ZONE files;

> ..., you'd need a really compelling reason to do that, and I

the concept of DANE's framework is not the primary intention of my I-D,
just the webpage for users; because of missing informations on
browser-side;

the other aspect of storing verifyable data in the DNS was an idea from a
workmate, that I formed in a practiable ready-to-implement instruction;

my thoughts were a complete new non existing system, why read my last
statement of this ...

> "SHOULD", rather than a "MUST"

the reason for this is just one:
when the browser supports this checking mechanisms, the user MUST be able
to use the website without DNSSEC and without these DNS entries;
and if the DNS server of the provider supports DNSSEC, there MUST not be
any force for the user to use this.

but one other idea in this connection, that both variants - DANE and mine
will fail: when the DNS is maintained by the same folks as the webserver;
and this is in fact most times.

Walter