Subject: https at ietf.org

From: Tim Bray <[email-masked]>
Date: Tue, 5 Nov 2013 16:34:54 -0800

Wouldn’t it be a good idea for everything at *.ietf.org to be served by
HTTPS, and only by HTTPS?

---

From: Joe Abley <[email-masked]>
Date: Tue, 5 Nov 2013 17:25:09 -0800

On 2013-11-05, at 16:34, Tim Bray <[email-masked]> wrote:

> Wouldn’t it be a good idea for everything at *.ietf.org to be served by HTTPS, and only by HTTPS? 

Especially with signed TLSA RRSets in the DNS.

Joe

---

From: David Morris <[email-masked]>
Date: Tue, 5 Nov 2013 17:35:39 -0800 (PST)

I don't see reason to use https for delivery of public documents such
as RFCs and Internet Drafts. All that would really accomplish is
reduce caching opportunities.

On Tue, 5 Nov 2013, Tim Bray wrote:

> Wouldn?t it be a good idea for everything at *.ietf.org to be served by

---

From: Eric Burger <[email-masked]>
Date: Tue, 5 Nov 2013 20:45:30 -0500

Because would not someone retrieving an RFC want to know it really came from the IETF, especially when it says
   The protocol MUST provide provisions for lawful intercept and
   MUST post a notification when traitorous speech is detected.

;-)

And, don’t we need to eat our own dog food?

---

From: Paul Wouters <[email-masked]>
Date: Tue, 5 Nov 2013 20:51:55 -0500 (EST)

> reduce caching opportunities.

That's like saying most of the letters you send and receive should be
postcards, because they have nothing to hide. Yet you send/receive more
letters in envelopes than not.

We should abolish all plaintext, regardless of the content. The internet
should be a neutral carrier, and our protocols should not make decisions
on which information needs encryption and which does not. It should
always encrypt.

Paul

---

From: Joe Abley <[email-masked]>
Date: Tue, 5 Nov 2013 18:00:59 -0800

> reduce caching opportunities.

I don't mind random people in the public library seeing me choose a book, but I might object to someone following me around taking notes of every reading choice I ever made, especially if there was no way to know if it was happening.

Funny how that kind of statement sounds less paranoid every year that passes.

Joe

---

From: [email-masked]
Date: Tue, 05 Nov 2013 18:21:28 -0800 (PST)

> reduce caching opportunities.

I don't have any problem with making things available via https, but it needs
to be possible to retrieve things with regular http. Not everything gets
retrieved by a browser and not every tool out there supports https.

				Ned

---

From: Dean Willis <[email-masked]>
Date: Tue, 5 Nov 2013 20:29:21 -0600

> reduce caching opportunities.

For regimes that insist on capturing encrypted data, it certainly increases the work factor.

For regimes that suspect all users of encrypted data are opponents, it should also have a salubrious effect.

—
Dean

---

From: Tim Bray <[email-masked]>
Date: Tue, 5 Nov 2013 18:35:02 -0800

I disagree. I can’t think of an scenario in which a human who wants/needs
to use IETF publications would not have access to an HTTPS-capable user
agent.  -T

---

From: Joe Abley <[email-masked]>
Date: Tue, 5 Nov 2013 18:39:37 -0800

On 2013-11-05, at 18:21, [email-masked] wrote:

> not every tool out there supports https.

That seems like the kind of thing we want to change (security as an afterthought vs. security as a fundamental requirement).

Joe

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Nov 2013 21:41:10 -0500

> I don't mind random people in the public library seeing me choose a book, but I might object to someone following me around taking notes of every reading choice I ever made, especially if there was…

I don't see how HTTPS will prevent this or any other exposure of 
public information already on the IETF site. Unless of course, there 
are channels of private conversations going on that is not generally 
publicly available.

I think this will make it more complex for people who may wish to 
fetch/pull down information using some automated tool, etc.

I suppose this will mean FTPS (or SFTP) will need to be covered as 
well for ftp.ietf.org, and also TLS for SMTP IETF related mail 
transactions?

> Funny how that kind of statement sounds less paranoid every year that passes.

I finally open "my life" to an iPhone and its cloud synchronization, 
etc. Still scary, but as you say, less paranoid.   Its the "new 
normal" I suppose to work/converse/play in such openness and 
integrated sharing.

-- 
HLS

---

From: "Marco Davids (Prive)" <[email-masked]>
Date: Tue, 05 Nov 2013 18:45:21 -0800

> That seems like the kind of thing we want to change (security as an afterthought vs. security as a fundamental requirement).
Enabling 'HTTP Strict Transport Security' (HSTS, RFC6797) might be a
good first step.

--
Marco

---

From: Hector Santos <[email-masked]>
Date: Tue, 05 Nov 2013 21:52:40 -0500

> That seems like the kind of thing we want to change (security as an afterthought vs. security as a fundamental requirement).

+1. But this also requires a fundamental review of all forms of IETF 
electronic communications, including TLS for IETF SMTP transactions 
and FTPS/SFTP for ftp.ietf.org.

-- 
HLS

---

From: [email-masked]
Date: Tue, 05 Nov 2013 19:41:40 -0800 (PST)

> to use IETF publications would not have access to an HTTPS-capable user

I actually doubt that's the case in some countries, but even if it is,
it's completely beside the point.

Sure, I have access to https-capable tools. But as it happens I prefer to
*use* some tools that don't have that capability.

This is, or is supposed to be, an open standards body, one that is
trying to encourage as many qualified people as possible to participate.
It makes no sense at all to restrict access in this way.

				Ned

---

From: Yoav Nir <[email-masked]>
Date: Wed, 6 Nov 2013 04:38:55 +0000

> Enabling 'HTTP Strict Transport Security' (HSTS, RFC6797) might be a

HSTS means that HTTP is off (or just redirects you to HTTPS). The first S stands for "strict" and we mean it. :-)

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 6 Nov 2013 10:00:57 +0100

> reduce caching opportunities.

I'd like to chime in on the side of prefering https; quoting such reasons
as layer separation (the transport should not decide based on content),
paranoia (yesteryears paranoia is SOP this year), and indeed significantly
dogfood. If we're not using this, what kind of message does this send?

Also, ands this is an _important_ part: We do not need perfect
security. We need to work on methods for raising the cost of the
Panopticon. For every activity that does not need good robust security
for some reason, we should make efforts so as to introduce a minimum
of default, always-on privacy. The subscription to our mailing lists
is still open, and the archives are freely accessible which sort of
underlines the idea that not all encrypted activities are secret or
illegal. They are just not up for grabs until so decided.

Consequently, the other access methods may be implemented in their own
leisure, as long as there is progress. The IETF MX host is, according to
its greeting banner, using Postfix, where opportunistic TLS is so simple
to activate that I have succeeded in my machine. I suggest this be done
as soon as practical. Just because.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
My CODE of ETHICS is vacationing at famed SCHROON LAKE in upstate New York!!

---

From: Eric Burger <[email-masked]>
Date: Wed, 6 Nov 2013 06:28:50 -0500

How does the use of HTTPS restrict who can participate in the IETF? That is like saying that because we no longer offer Gopher, we have closed off participation to some (possibly null) set of Internet users.

If we do not encourage the use of our own work, why should anyone else use it?

---

From: Dave Cridland <[email-masked]>
Date: Wed, 6 Nov 2013 11:39:53 +0000

On Wed, Nov 6, 2013 at 11:28 AM, Eric Burger <[email-masked]>wrote:

> How does the use of HTTPS restrict who can participate in the IETF? That
> is like saying that because we no longer offer Gopher, we have closed off
> participation to some (possibly null) set of Internet users.
>
Requiring HTTPS, particularly with reasonable cipher suites, might restrict
use of from certain jurisdictions.

Allowing HTTPS, on the other hand, does not. Unfortunately, because of the
nature of HTTP/HTTPS, we cannot perform opportunistic encryption in the
same way as with the mail and XMPP services we use.

---

From: Thiago Marinello <[email-masked]>
Date: Wed, 6 Nov 2013 10:02:39 -0200

I have no problem with additional access via HTTPS, IETF already have it.

It is better to have more ways to deliver content. The interested party has
the freedom to choose the best way to access, HTTPS, HTTP, FTP, anything.

If the issue is privacy for those who access, HTTPS can help partially,
they do not intercept the documents that the person reads, but still be
able to know that there was a connection to the computer with the IP
address of the IETF.

But if the problem is to ensure the integrity of documents (RFCs) I suggest
that the RFC Editor digitally sign each published RFC (using GPG), thus
making it possible to check if the document has not been altered during
communication or storage.

Sincerely,

__
 Thiago Marinello
 +55 19 9248 0860

On Wed, Nov 6, 2013 at 9:39 AM, Dave Cridland <[email-masked]> wrote:

> Requiring HTTPS, particularly with reasonable cipher suites, might
> restrict use of from certain jurisdictions.
>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 06 Nov 2013 13:24:08 +0100

* Joe Abley wrote:
>That seems like the kind of thing we want to change (security as an 
>afterthought vs. security as a fundamental requirement).

A typical problem I have is that I forgot to install Honest Achmed's
certificates and then tools refuse to work and they might not have an
option to ignore the problem. Cygwin tools for instance; apparently
the certificate bundle is not part of the base system. It is also
very very common that certificates are for the wrong hostnames or are
expired leading to tool failure. It can be very frustrating when the
remote host refuses to operate under plain 'http' in such cases.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: John C Klensin <[email-masked]>
Date: Wed, 06 Nov 2013 08:44:43 -0500

--On Tuesday, 05 November, 2013 19:41 -0800
[email-masked] wrote:

> Sure, I have access to https-capable tools. But as it happens
> I prefer to *use* some tools that don't have that capability.

Exactly. To give an example to make this specific, I quite often
read I-Ds directly into an editor that gives me good
regex-search, split-screen, and bookmark capability.   It
supports retrieving documents over FTP and HTTP as well as
locally but, because the author made an (IMO perfectly rational)
decision to avoid either doing certificate management or doing a
half-a**ed job, there is no HTTPS retrieval support.

> This is, or is supposed to be, an open standards body, one
> that is trying to encourage as many qualified people as
> possible to participate. It makes no sense at all to restrict
> access in this way.

Agreed, ever though I consider this more a matter of subjecting
people to extra work and thereby discouraging them from quickly
looking at related documents rather then "restricting access".
In any case where I would be inclined to read a document
directly into a editor or other reading tool, I could read it
through a web browser, store it locally, read it in the editor,
and then try to remember to delete it later.  But, unless the
document is really important, I'm frankly less likely to bother
actually checking it -- and that is ultimately not in the IETF's
best interest as well as not in mine.

   john

---

From: John C Klensin <[email-masked]>
Date: Wed, 06 Nov 2013 09:01:05 -0500

--On Tuesday, 05 November, 2013 20:45 -0500 Eric Burger
<[email-masked]> wrote:

> Because would not someone retrieving an RFC want to know it
> really came from the IETF, especially when it says    The
> protocol MUST provide provisions for lawful intercept and

Eric,

I think your joke illustrates the other part of the problem.  If
I really want to "know it really came from the IETF", then I
want a digital signature on the document that I can verify after
it is retrieved, regardless of the retrieval mechanism used.  

At least until and unless we (and the rest of the community)
manage to clean up the server CA mess --including both killing
off the CAs with bad behavior patterns and making sure that all
HTTPS clients do really careful cert validation-- https may give
me a warm and fuzzy feeling, but it doesn't guarantee document
authorship and integrity.    Worse, part of the problem today if
that, if those HTTPS-related tools work well, there is some
history of false negatives (e.g., letting certs expire) that
keep people from getting to documents for no good reason.

I believe in eating our own dogfood, but think an appeal to that
principle requires careful attention to whether the food is
suitable for purpose and safe and nutritious for canine
consumption.  In today's environment, claims about HTTPS for
document authenticity and/or integrity fail that test.

I strongly defend keeping HTTPS available for those who want it,
but oppose getting rid of it to punish those who have reasons to
not use it.

     john

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Nov 2013 14:09:50 +0000

On Nov 6, 2013, at 3:39 AM, Dave Cridland <[email-masked]> wrote:
> On Wed, Nov 6, 2013 at 11:28 AM, Eric Burger <[email-masked]> wrote:
> Requiring HTTPS, particularly with reasonable cipher suites, might restrict use of from certain jurisdictions.

I assume that what we want is a mechanism for authenticating the content; in this case there is no need to encrypt the content.   We are just talking about HTTPS because no mechanism exists to do the one without the other.   So the problem you are talking about, which I agree is real, is simply evidence of a missing feature; maybe that is where this debate ought to go.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 06 Nov 2013 06:56:42 -0800

On 11/6/2013 6:09 AM, Ted Lemon wrote:
> I assume that what we want is a mechanism for authenticating the
> content; in this case there is no need to encrypt the content.   We
> are just talking about HTTPS because no mechanism exists to do the
> one without the other.   So the problem you are talking about, which
> I agree is real, is simply evidence of a missing feature; maybe that
> is where this debate ought to go.

G'day.

I'm glad this discussion has distinguished between wanting content 
authentication vs. content confidentiality.  While some uses of https 
can do both, it's good to note that a) it can't do only authentication, 
and b) requiring https prohibits many current, legitimate scenarios.

I take this state of affairs -- combining the goal of authentication 
with a desire to preserve an extensive operational base -- as meaning 
that we need to create something to solve the problem.  This would, of 
course, mean that participants in the new mechanism do need to adopt new 
software, but it also would mean that non-adopters do not -- and won't 
be bothered by the presence of the signature, if it's packaging is 
designed properly.

There happens to be a solution lurking close by, just the other side of 
this door...  The door is marked "transparent authentication of content".

The base technology is DKIM:

      http:dkim.org

which affixes a signature using a special header-field to email.  The 
signature is transparent to any engine that doesn't recognize it, 
including human readers who are typically being shown a common subset of 
the full email header.

(DKIM semantics do not match the authentication goal here.  It uses 
authentication technology, but it uses it only to authenticate an 
identifier it affixes to the message; the presence of that identifier 
means that its owner of the identifier is taking 'some' responsibility 
for the message, not that the owner is certifying the content or 
claiming ownership of the content. So my suggestion is about underlying 
DKIM technology, not DKIM itself.)

The mechanisms of DKIM could be rather easily adapted to provide content 
authentication semantics, with the signature carried in a header field. 
  It would therefore provide authentication for any web client that 
upgraded and would be transparent to others.

There's been an effort to define a flexible version of this underlying 
mechanism, for just this sort of adaptation.  It's called DOSETA:

      http://www.trusteddomain.org/doseta.html

This leaves some real engineering work to be done, but provides a very 
high point of departure for solving the problem of content 
authentication that does not bother the legacy installed base.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: [email-masked]
Date: Wed, 06 Nov 2013 06:52:45 -0800 (PST)

> How does the use of HTTPS restrict who can participate in the IETF?

It does so by limiting the set of tools that can be used to access our stuff.
Additionally, there may be places where the use of https is inherently
problematic.

> That is like saying that because we no longer offer Gopher, we have closed
> off participation to some (possibly null) set of Internet users.

And that would indeed be the case if there was a set of potential users and
useful tools out there that supported nothing but gopher. AFAIK that's not the
case. In the case of http access I know it to be true.

> If we do not encourage the use of our own work, why should anyone else use it?

Encouraging the use of our work - our standards - is exactly the issue here.
You're trying to impose privacy requirements on a use-case where they simply
don't make sense.

And if you think forcing the use of https on our web site provides https with
some sort of much-needed usage boost to that protocol, you're in serious need
of a reality check.

Again, by all means offer https. And make sure that once in the https
sphere the links you find cause you to stay in that sphere.

But requiring it goes too far. What, is the next step to shut down things
like rsync because there is no secure version?

				Ned

---

From: [email-masked]
Date: Wed, 06 Nov 2013 07:01:58 -0800 (PST)

> same way as with the mail and XMPP services we use.

Perhaps that is a problem that deserves further attention.

				Ned

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Nov 2013 15:18:50 +0000

Without taking a position on the particular technology being proposed (which I haven't looked at yet), I am happy to hear that I am not the only one thinking about this.   Of course we already have examples of mechanisms that do authenticated integrity checking of content—e.g., RPM, bittorrent and debian's apt—but these have not been generalized into a service that would solve the problem we are talking about here.   I'm curious to know whether anybody besides Dave and me thinks this is a problem worth solving.

---

From: "MAISONNEUVE, JULIEN (JULIEN)" <[email-masked]>
Date: Wed, 6 Nov 2013 02:45:49 +0000

Unfortunately there are scénarios in which you have the adéquate agent but not the corresponding proxy.

(JM, ex mobilum)

Le 5 nov. 2013 à 18:35, "Tim Bray" <[email-masked]<mailto:[email-masked]>> a écrit :

I disagree. I can’t think of an scenario in which a human who wants/needs to use IETF publications would not have access to an HTTPS-capable user agent.  -T

                                Ned

---

From: Eric Burger <[email-masked]>
Date: Wed, 6 Nov 2013 16:39:12 -0500

Here I agree. [The value of discourse]

1. We already offer https, so if you want to go https, you can.

2. We should figure out a way of signing (and doing the appropriate PKI) documents. The fact we think we cannot says we basically say NO ONE can trust the Internet. I am willing to believe S/MIME with a known set of roots is a start.

Do we really believe #2 is not a solvable problem? If it is not solvable (or solved), we are totally hosed.

---

From: "Marco Davids (Prive)" <[email-masked]>
Date: Wed, 06 Nov 2013 16:16:47 -0800

> HSTS means that HTTP is off (or just redirects you to HTTPS). The first S stands for "strict" and we mean it. :-)
Well, not entirely; the redirect is strictly not part of HSTS. Without a
redirect we give visitors an option; if you come in via http, fine... If
you come in via https with a browser that understands HSTS, then it's
https from that moment on.

And once we're all used to that, we can add the redirect ;-)

--
Marco

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Nov 2013 02:24:28 +0000

On Nov 6, 2013, at 4:16 PM, Marco Davids (Prive) <[email-masked]> wrote:

> Well, not entirely; the redirect is strictly not part of HSTS. 

Sure it is:

7.2.  HTTP Request Type

   If an HSTS Host receives an HTTP request message over a non-secure
   transport, it SHOULD send an HTTP response message containing a
   status code indicating a permanent redirect, such as status code 301
   (Section 10.3.2 of [RFC2616]), and a Location header field value
   containing either the HTTP request's original Effective Request URI
   (see Section 9 ("Constructing an Effective Request URI")) altered as
   necessary to have a URI scheme of "https", or a URI generated
   according to local policy with a URI scheme of "https".

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 7 Nov 2013 05:56:29 +0100

> You're trying to impose privacy requirements on a use-case where they simply

Given this years revelations in the privacy field that is a statement I find slightly bold. 

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Now I'm having INSIPID THOUGHTS about the beatiful, round wives of
HOLLYWOOD MOVIE MOGULS encased in PLEXIGLASS CARS and being approached
by SMALL BOYS selling FRUIT ...

---

From: [email-masked]
Date: Wed, 06 Nov 2013 21:11:01 -0800 (PST)

> Given this years revelations in the privacy field that is a statement I find slightly bold.

You'll have to explain the connection then, because I don't see it. We're
talking about refusing to allow unprotected access to public standards
documents. That's the use-case in question; nothing else.

				Ned

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 6 Nov 2013 21:26:53 -0800

On 06 Nov 2013, at 06:09, Ted Lemon <[email-masked]> wrote:

> I assume that what we want is a mechanism for authenticating the content; in this case there is no need to encrypt the content. 

If that were the problem we are addressing, the best answer would involve RFC 6920.

For privacy, though, STASI*) should not be able to find out that I’m retrieving RFC 1984 so that they can't identify me as a long-haired bomb-throwing leftist (or whatever retrieving RFC 1984 makes you in their minds).

Grüße, Carsten

*) STASI: State-level wire-Tapping Agency with Substantial Infrastructure

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Nov 2013 05:42:01 +0000

> If that were the problem we are addressing, the best answer would involve RFC 6920.

No, that's not what I want, although it is a neat hack.

> For privacy, though, STASI*) should not be able to find out that I’m retrieving RFC 1984 so that they can't identify me as a long-haired bomb-throwing leftist (or whatever retrieving RFC 1984 makes…

If you want encryption, definitely you should be able to get it, and indeed with ietf.org, you can.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 6 Nov 2013 22:36:55 -0800

> If you want encryption, definitely you should be able to get it, and indeed with ietf.org, you can.

No, I want privacy, and all my right-thinking crew-cut friends are using http://ietf.org, so I still stand out for STASI when I’m using https://ietf.org.

The whole debate is not so much about whether privacy is really needed for accessing the IETF site (not really that much) but about whether we want to lead by example.  I think we want to expose the browsable parts of the site such as the front page by https only, but keep tools access for constructible URIs such as http://tools.ietf.org/id/{draft-name}.  And rsync of course.  FTP is legacy anyways.

Grüße, Carsten

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 7 Nov 2013 09:01:03 +0100

> documents. That's the use-case in question; nothing else.

Since it is perfectly innocent to perform this fetching, the Government(s)
need not be privy to this -- and we should encrypt. The trust that the
Government(s) will only tap the traffic of those that are a grave concern
to their security interests has completely vanished.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
I have many CHARTS and DIAGRAMS..

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 7 Nov 2013 09:02:09 +0100

> The whole debate is not so much about whether privacy is really needed for accessing the IETF site (not really that much) but about whether we want to lead by example.  I think we want to expose th…

++;

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Used staples are good with SOY SAUCE!

---

From: t.p. <[email-masked]>
Date: Thu, 7 Nov 2013 11:12:04 +0000

----- Original Message -----
From: "Tim Bray" <[email-masked]>
To: <[email-masked]>
Cc: "IETF-Discussion Discussion" <[email-masked]>
Sent: Wednesday, November 06, 2013 2:35 AM

I disagree. I can’t think of an scenario in which a human who
wants/needs
to use IETF publications would not have access to an HTTPS-capable user
agent.  -T

<tp>
I want access to IETF publications in order to contribute to the
standards process and I have access to a very fine, HTTPS-capable user
agent (supplied by Microsoft).  It works with almost every web site in
the world, but not with the IETF's.

For any https:// link, the initial html is downloaded, the CRL is
downloaded and .....
zilch, nothing, a blank screen and a little globe that spins for hours.

Quite what is wrong with the IETF certificate chain's CRL I do not know,
but I do know that the IETF website is inaccessible with HTTPS.  Of
course, I can turn off CRL checking and it works perfectly.  Which I
think is a good summary of where we have got to with security (and no,
OCSP is not out there yet).

This thread started with a design and, as other messages on this thread
have pointed out, it would seem that that design, https, is largely
irrelevant to the actual requirement, namely authentication; but the
IETF has
designed a very fine hammer, namely https, so let's get to work with the
hammer:-(

Tom Petch

On Tue, Nov 5, 2013 at 6:21 PM, <[email-masked]> wrote:

> I don't have any problem with making things available via https, but
it
> needs

---

From: Dave Cridland <[email-masked]>
Date: Thu, 7 Nov 2013 11:25:37 +0000

> Perhaps that is a problem that deserves further attention.

It would mean getting UA and server support for RFC 2817, though.

Dave.

---

From: David Conrad <[email-masked]>
Date: Thu, 7 Nov 2013 07:40:51 -0800

tp,

On Nov 7, 2013, at 3:12 AM, t.p. <[email-masked]> wrote:
> but I do know that the IETF website is inaccessible with HTTPS.  

A good example of why we should eat our own dogfood, no?

Regards,
-drc

---

From: Arturo Servin <[email-masked]>
Date: Thu, 7 Nov 2013 14:20:34 -0200

May be somebody fixed. Because I can access https://www.ietf.org/ and pages
under without problems.

.as

---

From: [email-masked]
Date: Thu, 07 Nov 2013 08:54:19 -0800 (PST)

> need not be privy to this -- and we should encrypt.

That's a strawman. Nobody has any problem with saying we SHOULD encrypt. The
problem I and others have is saying we MUST encrypt.

> The trust that the

That doesn't trump the need for access to our materials to be as open as
possible.

				Ned

---

From: [email-masked]
Date: Thu, 07 Nov 2013 09:00:17 -0800 (PST)

> It would mean getting UA and server support for RFC 2817, though.

In light of the sentiments expressed at the plenary and in perpass in regards
to opportunistic encryptions, perhaps this is the dogfood we should be eating.

				Ned

---

From: Chris Inacio <[email-masked]>
Date: Thu, 7 Nov 2013 17:28:48 +0000

+1

I don’t care about the transport to get a public document if the goal is to ensure the document hasn’t been tampered with.

Personally, I think HTTPS is a totally missing the point.

To that effect, if we’re really serious about this stuff, shouldn’t we want all email on the lists signed as well?

--
Chris Inacio
[email-masked]

---

From: Tim Bray <[email-masked]>
Date: Thu, 7 Nov 2013 09:45:35 -0800

> That doesn't trump the need for access to our materials to be as open as

Hmm, what does “open” mean? Maximally accessible technologically, or
maximally accessible without any worry about who might be watching?  The
answer isn’t obvious at all.

This is a discussion that needs to happen at much greater length and depth,
and outside not just inside the IETF community.  But, FYI, there are a
substantial number of people who feel like the sane response to pervasive
surveillance is pervasive encryption.  And if you encrypt “only the
controversial stuff”, you make encryption itself controversial, and its use
a red flag for those currently attacking the Internet.  So; I don’t think
I’m insane, or even unreasonably paranoid, but I do think it would be a
very good thing, and would maximize the general usefulness of our
resources, if we switched all public-facing IETF resources to HTTPS-only.

I’m perfectly aware that there are those who disagree.

 -T

---

From: t.p. <[email-masked]>
Date: Thu, 7 Nov 2013 18:17:14 +0000

----- Original Message -----
From: "Tim Bray" <[email-masked]>
To: <[email-masked]>
Cc: "Måns Nilsson" <[email-masked]>; "Ned Freed"
<[email-masked]>; "IETF-Discussion Discussion" <[email-masked]>;
"Eric Burger" <[email-masked]>
Sent: Thursday, November 07, 2013 5:45 PM

<tp>

To me it is obvious, that it is technological access that comes first
e.g. RFC in plain text, e-mails in plain text, e-mails kept short,
unrestricted access to the mailing lists and to the mail archives, basic
protocols (FTP, SMTP) and so on.

Our Introduction says
"The IETF is completely open to newcomers."
Well, open to those who have an adequate level of technology and that we
should keep as low as is practicable.  Demand something more - TLS, CMS,
IMAP etc - and you will start to cut people off from our work.

Keeping what you are doing hidden, from your boss, the police, the
government, your family etc, that comes second.

Tom Petch

This is a discussion that needs to happen at much greater length and
depth,
and outside not just inside the IETF community.  But, FYI, there are a
substantial number of people who feel like the sane response to
pervasive
surveillance is pervasive encryption.  And if you encrypt “only the
controversial stuff”, you make encryption itself controversial, and its
use
a red flag for those currently attacking the Internet.  So; I don’t
think
I’m insane, or even unreasonably paranoid, but I do think it would be a
very good thing, and would maximize the general usefulness of our
resources, if we switched all public-facing IETF resources to
HTTPS-only.

 -T

---

From: [email-masked] (Martin Rex)
Date: Thu, 7 Nov 2013 21:17:41 +0100 (CET)

Tim Bray wrote:
> Wouldn't it be a good idea for everything at *.ietf.org to be served by
> HTTPS

Yes.

https://tools.ietf.org   has been available for a little while
https://www.ietf.org     seems to work

which hosts are left without?

> and only by HTTPS?

Now that would be extremely inconvenient and counterproductive to
create impediments for access to open&public information, am I am
strongly opposed to that latter.

-Martin

---

From: [email-masked]
Date: Thu, 07 Nov 2013 12:02:46 -0800 (PST)

> answer isn’t obvious at all.

Mandating https on IETF web sites won't prevent people from seeing the access.
And thay may well constitute a reason to worry. Indeed, the fact that content
isn't observable may make the access more problematic in certain places, not
less.

So let's not pretend this accomplishes the goal of eliminating worry about
who may be watching, OK?

> a red flag for those currently attacking the Internet.

Ah yes, the old postcard argument. I didn't really buy it when Phil Zimmerman
made it ~20 years ago and I don't really buy it now, because it fails to take
traffic analysis into account. And if there's one thing we have learned from
the recent disclosures, it's that traffic analysis is a big deal.

But this is the thing about opportunistic encryption: We can make the shift to
mostly using envelopes without having to abandon or inconvenience lots of
people and without compromising our mission in the process.

				Ned

---

From: [email-masked] (Martin Rex)
Date: Thu, 7 Nov 2013 21:33:29 +0100 (CET)

Eric Burger wrote:
> 2. We should figure out a way of signing
> (and doing the appropriate PKI) documents. The fact we think
> we cannot says we basically say NO ONE can trust the Internet.
> I am willing to believe S/MIME with a known set of roots is a start.
> 
> Do we really believe #2 is not a solvable problem? If it is not
> solvable (or solved), we are totally hosed.

Forget it, S/Mime and PKI(X) is a dead end road for longterm
signatures on documents.  While it might be OK for I-Ds for
their official 6-month validity period, it is useless for RFCs,
which often have a 10+ years lifetime.  Long beyond the lifetime
of certificates and the willingness of CAs to respond to
revocation status queries.

-Martin

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Nov 2013 20:43:41 +0000

On Nov 6, 2013, at 10:36 PM, Carsten Bormann <[email-masked]> wrote:
> No, I want privacy, and all my right-thinking crew-cut friends are using http://ietf.org, so I still stand out for STASI when I’m usinghttps://ietf.org.

The mere fact that you are going to http(s?)://www.ietf.org already flags you for further monitoring, whether you use SSL or not.   But I see your point.

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 7 Nov 2013 21:44:06 +0100

> government, your family etc, that comes second.

Not everyone are in a position to regard this as secondary. There have
been several good arguments about the usefulness of privacy when accessing
open sources. In Sweden, libraries do not keep logs about who borrowed
what after the books have been returned, and ISTR a case where the
library refused to divulge what information they had to the police unless
a warrant was served.  Because it is nobody's business except mine what I
read.  The IETF, its documents and mailing lists is not exempt from this.
Several of the revelations about government surveillance have concerned
industrial espionage. Keeping track of who reads what is definitely a 
tool in the mapping of interesting activities. 

	Fienden lägger pussel. 
	Behåll din bit.[0] 

Besides, dogfood, etc. 

/Måns, publically taking a position because the world is still free
  enough to do this.
-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
I feel like a wet parking meter on Darvon!

[0] The enemy assembles a puzzle.
    Keep your piece.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Nov 2013 20:53:52 +0000

On Nov 7, 2013, at 3:12 AM, t.p. <[email-masked]> wrote:
> the

+1

---

From: Douglas Otis <[email-masked]>
Date: Thu, 7 Nov 2013 13:10:10 -0800

>> designed a very fine hammer, namely https, so let's get to work with the
Dear Ted,

Agreed.
Anything less would be wrong.  While many https services offer self-signed certs, this situation is understood and permits change detection.

Regards,
Douglas Otis

---

From: Pranesh Prakash <[email-masked]>
Date: Thu, 07 Nov 2013 18:14:19 -0500

> remote host refuses to operate under plain 'http' in such cases.

Does that point to the Cygwin tools needing to be fixed, and for servers
to use certificates properly, or does that point to a need to ensure
that the standard doesn't evolve to cope with current frustrations?

-- 
Pranesh Prakash
Policy Director
Centre for Internet and Society
T: +91 80 40926283 | W: http://cis-india.org
PGP ID: 0x1D5C5F07 | Twitter: @pranesh_prakash
--------------------
Postgraduate Associate & Access to Knowledge Fellow
Information Society Project, Yale Law School
T: +1 520 314 7147 | W: http://yaleisp.org

---

From: Pranesh Prakash <[email-masked]>
Date: Thu, 07 Nov 2013 18:28:51 -0500

> use of from certain jurisdictions.

Could we have more concrete examples, please?  Would these be because of
export restrictions?[1]  For instance, are there any jurisdictions from
where users have to disable the HTTPS by default option in Gmail?

 [1]: http://www.cryptolaw.org/

---

From: [email-masked] (Martin Rex)
Date: Fri, 8 Nov 2013 03:00:33 +0100 (CET)

Pranesh Prakash wrote:

>> Requiring HTTPS, particularly with reasonable cipher suites,
>> might restrict use of from certain jurisdictions.
> 
> Could we have more concrete examples, please?

A significant number of IETF documents (including BCP 78)
contain this statement:

   Distribution of this memo is unlimited.

_Restricting_ access to such documents on the www.ietf.org/tools.ietf.org
to HTTPS only seems to be incompatible with this fundamental principle.

Like prohibiting to put RFC on open bookshelves in public libraries
because other folks could see you taking it out of the shelve.

-Martin

---

From: Dave Cridland <[email-masked]>
Date: Fri, 8 Nov 2013 07:40:53 +0000

>  [1]: http://www.cryptolaw.org/

Examining this website for marginally less than a minute tells me that
encryption is generally banned in Saudi Arabia.

But that's really besides the point. If we "fixed" RFC 2817 support, we
could have opportunistic (better than nothing) crypto on *all* websites,
rather than forcing every website to deploy HTTPS-only - pretty good win
for privacy / anti-pervasive-surveillance.

That is, making encryption optional, but available everywhere, is a bigger
win than making it mandatory in a few places.

Dave.

---

From: Eric Burger <[email-masked]>
Date: Mon, 25 Nov 2013 07:08:16 -0500

I like where this has ended up. I am pretty convinced that HTTPS is mostly a dead end because of the CA problem. However, getting RFC 2817 really, really out there would be a huge advance. Like a lot of security stuff, people need a compelling reason to deploy *or* they will use it if it is “just there.” Let us make it “just be there."

On Nov 8, 2013, at 2:40 AM, Dave Cridland <[email-masked]> wrote:

> On Thu, Nov 7, 2013 at 11:28 PM, Pranesh Prakash <[email-masked]> wrote:
> Examining this website for marginally less than a minute tells me that encryption is generally banned in Saudi Arabia.
> 
> But that's really besides the point. If we "fixed" RFC 2817 support, we could have opportunistic (better than nothing) crypto on *all* websites, rather than forcing every website to deploy HTTPS-only - pretty good win for privacy / anti-pervasive-surveillance.
> 
> That is, making encryption optional, but available everywhere, is a bigger win than making it mandatory in a few places.
> 
> Dave.

---

From: Joe Abley <[email-masked]>
Date: Mon, 25 Nov 2013 10:38:53 -0500

On 2013-11-25, at 07:08, Eric Burger <[email-masked]> wrote:

> I like where this has ended up. I am pretty convinced that HTTPS is mostly a dead end because of the CA problem.

Isn't this at least part of the motivation behind DANE?

(I realise DANE requires moving parts in the client and signatures in the published zone, but it seems odd that it hasn't been mentioned.)

Joe

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Nov 2013 10:42:12 -0500

> (I realise DANE requires moving parts in the client and signatures in the published zone, but it seems odd that it hasn't been mentioned.)

Is the DNSSEC root key secure against National Security Letters?

---

From: Joe Abley <[email-masked]>
Date: Mon, 25 Nov 2013 10:44:46 -0500

> Is the DNSSEC root key secure against National Security Letters?

I don't know. Sounds like a good question to ask ICANN.

Joe

---

From: David Conrad <[email-masked]>
Date: Mon, 25 Nov 2013 09:11:51 -0800

Ted,

> Is the DNSSEC root key secure against National Security Letters?

What does that mean?  Exactly what threat are you imagining an NSL would be used to hide? 

Thanks,
-drc

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Nov 2013 12:24:31 -0500

> What does that mean?  Exactly what threat are you imagining an NSL would be used to hide? 

Hi, this is the FBI, we would like a copy of the DNSSEC root private key please, and don't tell anyone you gave it to us.   The same attack would work on .com as well, of course, without bothering with the root key.

To be clear, this is a threat that can be addressed, but we should be thinking about it as part of the threat model when talking about replacing CA PKI with DANE.   In point of fact, I would argue that the two certificate hierarchies have different threat models, and that we ought to keep both and use them for cross-validation where appropriate, not just throw all our eggs in a different basket and hope for the best.

---

From: David Conrad <[email-masked]>
Date: Mon, 25 Nov 2013 09:33:09 -0800

On Nov 25, 2013, at 9:24 AM, Ted Lemon <[email-masked]> wrote:
> Hi, this is the FBI, we would like a copy of the DNSSEC root private key please, and don't tell anyone you gave it to us.

Ignoring the fact that the private key is stored in an HSM with multiple layers of protection that requires a number of people to even get into the room in which the cage that holds the safe which contains the HSMs are stored, what _exactly_ would the FBI _do_ with the private root key?

Regards,
-drc

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Nov 2013 12:45:44 -0500

> Ignoring the fact that the private key is stored in an HSM with multiple layers of protection that requires a number of people to even get into the room in which the cage that holds the safe which…

The root key (or a TLD key) can be used to create a fake hierarchy, nearly identical to the real hierarchy, but with a few changes.   Install this on a few targeted name servers and you can install fake DANE certs that validate.   If you did this in a pervasive manner, it would be easy to detect, but only if we are checking.   For targeted attacks, it's still probably possible to defend against it, but a DNSSEC validator that could detect that it might be under such an attack would be a fun challenge and would require some careful thinking.

Actually, getting a TLD key like the .COM key would make for a more effective attack, since it's fairly easy to cache all the TLD keys and notice weird changes to them, but it's a lot harder to cache keys for all the registered domains you might ever visit.

My point is simply that we can't just wave our hands and say "DANE" and be satisfied.   If we put all our eggs in the DNSSEC basket, we need to think about what threats that exposes us to, and address those threats.   Simply checking the signatures proves nothing if the trust anchor(s) we use to check have been compromised.

---

From: "John Levine" <[email-masked]>
Date: 25 Nov 2013 18:06:08 -0000

>What does that mean?  Exactly what threat are you imagining an NSL would be used to hide? 

Hijack someone's DNS traffic, provide a chain of fake servers pointing
to a fake mail or web host, all with valid DNSSEC.

I guess that we need to ask the same question about TLDs that are
hosted in the United States.  That would mostly mean Verisign, Afilias
and PIR, and Neustar.

R's,
John

---

From: David Conrad <[email-masked]>
Date: Mon, 25 Nov 2013 15:22:06 -0800

> to a fake mail or web host, all with valid DNSSEC.

As I'm sure you're aware, for this attack to work, not only would the US government need to compromise the root KSK HSMs and a rather Byzantine set of safeguards, they would also presumably need to do so in a way that would reduce the likelihood that the compromised elements would be noticed.  Since the data is public, this might be a bit tricky -- forcing the attack to occur as close to the target as possible to minimize the chances some non-target would notice (which, if it were noticed, would like result in the absolute worst possible case in DNSSEC-land, the need to do an emergency role of the root KSK in every resolver on the planet: something we still don't know how to do). Since the attack would already be down near the validating resolver, I suspect it would be _far_ easier and infinitely less risky to compromise that validating resolver (particularly if that resolver is operated by a third party, like it is for the vast majority of folks -- something I've long felt is fundamentally broken).

> hosted in the United States.  

I would be surprised if only the US has NSLs.

> That would mostly mean Verisign, Afilias and PIR, and Neustar.

ICANN went to significant lengths to make everything done with the KSK extremely well documented and as public as humanly possible. I personally don't know what those organizations do (mostly because I haven't looked) but would be surprised if the level of disclosure is close to what ICANN has done.  As such I feel Joe's response to Ted:

>>>> Sounds like a good question to ask ICANN.

was wrong. Professional Operational Security folk should review the root KSK DPS (https://www.iana.org/dnssec/icann-dps.txt) and identify any weaknesses, including any vulnerabilities to NSL-like attacks so those weaknesses can be remedied. Simply waving "NSL" around like a magic wand is unhelpful.

Regards,
-drc

---

From: John R Levine <[email-masked]>
Date: Mon, 25 Nov 2013 18:34:50 -0500 (EST)

> As I'm sure you're aware, for this attack to work, not only would the US 
> government need to compromise the root KSK HSMs and a rather Byzantine 
> set of safeguards, they would also presumably need to do so in a way 
> that would reduce the likelihood that the compromised elements would be 
> noticed.

Well, sure.  If I were the NSA, I would arrange for a servers that 
mirrored the real data except for a few bits that I wanted to spear phish. 
I think it's reasonable to assume that for high-value targets the NSA can 
bring a lot of money and skilled people to the project.

> ICANN went to significant lengths to make everything done with the KSK 
> extremely well documented and as public as humanly possible.

"Give us the signing keys."

"Sorry, we have all these complicated security procedures."

"The guy standing next to me is a US Marshal.  You can give us the keys by 
COB today, or he can haul your asses to jail.  Your choice.  If there are 
other people whose help you need to get the keys and they're in the US, 
they'll have the same choice.  If they're outside the US, um, depends 
where they are."

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Nov 2013 18:58:14 -0500

(1) I'm not trying to impugn the good work that was done in securing the root key.   It was good work, and I think it was very cool.   I am just asking if, despite that good work, an NSL could get around it.   It's a fair question.   The answer may be "no," or "not without it becoming public," or "with great difficulty."   I doubt it's "easily."   But it's worth asking.   When you did the root signing, we were certainly thinking about this threat model, but it was a bit more academic then than it is now.   I think we still had some illusions that the U.S. government at least would choose a more constrained attack than taking the key to everything; we now know that the government feels no such burden of restraint—they apparently feel that they can be trusted with that key, and we should be willing to provide it.

(2) This attack is actually easier on TLDs than on the root, so I really asked the wrong question.   Although taking the root would be useful, it would be less useful than taking .COM and .ORG and .EDU.   With any of those keys, your chances of doing a mass attack on a single DANE-secured domain are much better.

(3) So, are they all as secure as the root?

---

From: S Moonesamy <[email-masked]>
Date: Mon, 25 Nov 2013 16:53:49 -0800

Hi Ted,
At 15:58 25-11-2013, Ted Lemon wrote:
>(1) I'm not trying to impugn the good work that 
>was done in securing the root key.   It was good 
>work, and I think it was very cool.   I am just 
>asking if, despite that good work, an NSL could 
>get around it.   It's a fair question.   The 
>answer may be "no," or "not without it becoming 
>public," or "with great difficulty."   I doubt 
>it's "easily."   But it's worth asking.   When 
>you did the root signing, we were certainly 
>thinking about this threat model, but it was a 
>bit more academic then than it is now.   I think 
>we still had some illusions that the U.S. 
>government at least would choose a more 
>constrained attack than taking the key to 
>everything; we now know that the government 
>feels no such burden of restraint—they 
>apparently feel that they can be trusted with 
>that key, and we should be willing to provide it.

In my opinion the question was a valid one.  It 
is not clear though.  I agree with Joe that it 
sounds like a question for ICANN.

I asked some questions about the DPS 
previously.  One of the questions was about 
coercion.  I was okay with the response I received at that time.

Regards,
S. Moonesamy

---

From: Michael Richardson <[email-masked]>
Date: Mon, 25 Nov 2013 20:24:57 -0500

Ted Lemon <[email-masked]> wrote:
    > (1) I'm not trying to impugn the good work that was done in securing
    > the root key.  It was good work, and I think it was very cool.  I am
    > just asking if, despite that good work, an NSL could get around it.
    > It's a fair question.  The answer may be "no," or "not without it
    > becoming public," or "with great difficulty."  I doubt it's "easily."
    > But it's worth asking.  When you did the root signing, we were
    > certainly thinking about this threat model, but it was a bit more
    > academic then than it is now.  I think we still had some illusions that
    > the U.S. government at least would choose a more constrained attack
    > than taking the key to everything; we now know that the government
    > feels no such burden of restraint—they apparently feel that they can be
    > trusted with that key, and we should be willing to provide it.

Based upon my reading of:
      http://www.root-dnssec.org/tcr/selection-2010/

and my understanding from careful reading of the site that any three Crypto
Officers are enough to reconstruct the key, it seems that a US NSL would not
suffice.

There are not three US people in any category, but I did not read how the key
was split.  If two Crypto Officers and a backup crypto officer cound as
three, then I'm wrong: a US NSL takes it.

I was also assuming that CO's for east coast do not also have west coast
keys, but I may be wrong here.

I don't know if the EU has an NSL process, but it seems that the EU could
also recover the keys if it wanted to.

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: S Moonesamy <[email-masked]>
Date: Mon, 25 Nov 2013 17:53:57 -0800

Hi Michael,
>Officers are enough to reconstruct the key, it seems that a US NSL would not

This is an individual opinion.  Key reconstruction would require more 
than three
Key Share Holders.

>three, then I'm wrong: a US NSL takes it.

Those roles do not have the ability to do that.

>keys, but I may be wrong here.

The above is ambiguous.

Sorry for being brief.

Regards,
S. Moonesamy

---

From: Randy Bush <[email-masked]>
Date: Tue, 26 Nov 2013 11:06:55 +0900

seems to me that if the amazingly elaborate ceremonies around the root
key do not include m of n needed to open the bottle, with the m and n
distributed among multiple national juristictions, it is merely security
theater.

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 26 Nov 2013 11:40:01 +0900

> distributed among multiple national juristictions, it is merely
> security theater.

from private email, i clearly was being too subtle.

hint: the inverse is also true

randy

---

From: Joe Abley <[email-masked]>
Date: Mon, 25 Nov 2013 21:44:50 -0500

> distributed among multiple national juristictions, it is merely security

Yes, that was what I was getting at.

The quarterly ceremonies are conducted to provide transparency and accountability for the desired, intended processes during which the KSK is necessarily exposed in order to generate signatures (and other key operations).

Safeguarding the process by which signatures are made is important, and so I would not describe the ceremonies as theatre -- but they are not a complete picture of the protection afforded to the KSK.

In between ceremonies, the copies of the KSK and the credentials by which an HSM can be brought on-line should remain in their respective safes. There is no international panel of trusted witnesses to that, nor could there reasonably be (I wouldn't trust anybody who volunteered to sit in an empty machine room for 361 days of the year watching nothing happen).

ICANN has gone to great lengths with internal process and involvement of external auditors (who scrutinise not only the provided documentation for ceremonies and any other operational access to facilities that was required) but who also consider compensatory controls such as unbroken CCTV footage from facility providers, interviews with relevant staff, alarm logs within the key management facility (and as retrieved from the separate, external central station), access logs at the front security desk, etc.

This is all public information, and has been well described in operational forums globally since around 2009.

Shenanigans with the KSK between ceremonies would involve collusion between ICANN staff, auditors, facility staff, central station staff, and potentially others. In ordinary times I would expect all of there to be too much reputational risk individually and across the board for anybody to even consider acting out of turn. However, these are all American companies, and I don't know how to tell whether they have all individually been instructed to act and conceal their action by order of law.

I recall one American company recently who has started making a point of confirming that they have not been subject to any national security letters in their annual reports, the idea being that they would be unable to make such an assertion if the reverse was true; the precedent and routine facilitates future disclosure-by-omission. Perhaps some or all of these companies might consider doing the same thing.

Anyway, cutting to the chase, despite the fact that I believe the system as a whole is about as well-designed as could be done within the requirements, I think the original question is still reasonable and is still one that should be asked of ICANN. I imagine they would enjoy giving a satisfactory response. The staff concerned are also professional and diligent members of this community and have a track record of welcoming and incorporating change from good suggestions.

Joe

---

From: David Conrad <[email-masked]>
Date: Mon, 25 Nov 2013 18:45:30 -0800

Randy,

> distributed among multiple national juristictions, it is merely security

And is it security theater if the "multiple national jurisdictions" only include the 5 Eyes? 

ICANN and Verisign, in a very public manner, tried (given constraints they were placed under) to ensure that opening the bottle was exceedingly public and documented so it didn't matter who actually did it.  Back during the Root Signing Road Show, input was requested many, many times in many, many venues (IETF included).

My point is that trotting NSLs out like a bogeyman is not helpful. Identify possible _realistic_ attacks and the vulnerabilities that those attacks can leverage. The Root KSK DPS is a public document, written under a set of assumption and constraints that may no longer hold and undoubtedly far from perfect. I am not arguing that the question Ted asks isn't valid, I'm saying "send text".

Regards,
-drc

---

From: Sean Turner <[email-masked]>
Date: Sat, 30 Nov 2013 00:17:53 -0500

> And, don’t we need to eat our own dog food?

I went for the eat our own dog food a while ago.   You might have noticed the new IETF servers support TLS 1.2 ;)

spt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 30 Nov 2013 14:08:40 -0500

On Mon, Nov 25, 2013 at 6:22 PM, David Conrad <[email-masked]> wrote:

> government need to compromise the root KSK HSMs and a rather Byzantine set
> of safeguards, they would also presumably need to do so in a way that would
> reduce the likelihood that the compromised elements would be noticed.

You clearly do not understand the nature of those controls. They are
designed to prevent an individual being in sole control of a key and
defecting or being coerced. They are not designed to prevent government
coercion. Separation of duties does not provide an effective control
against government coercion because the government can coerce multiple
parties as easily as one.

The CA based PKI has a similar issue which is why there is interest in
Certificate Transparency. The CA based PKI was designed to protect
commercial assets against criminal attackers. Preventing government
coercion was not considered. The root key management process is identical
in all significant respects to the VeriSign Class 3 root management
process.

If we are positing the failure of those controls in one case then we should
posit the same attack in the other. Unfortunately the argument that is made
is a highly partisan one which seizes on any possible hole in the CA scheme
as damning but ignores the exact same issues in the DANE/DNSSEC scheme.

At least in the CA trust scheme there is a choice of trust providers. If
ICANN were to turn DigiNotar it is the only option, it is not only 'too big
to fail' it is the only possible provider.

-- 
Website: http://hallambaker.com/