Re: [TLS] who do I poke to fix the URLs in the header?

Stephen Farrell <> Thu, 30 April 2015 13:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F38B21B2A89 for <>; Thu, 30 Apr 2015 06:50:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IzykAU1MQ9Cl for <>; Thu, 30 Apr 2015 06:50:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31DEB1B2A86 for <>; Thu, 30 Apr 2015 06:50:06 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6EAD6BE64; Thu, 30 Apr 2015 14:50:04 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nhFVHCTCo3F8; Thu, 30 Apr 2015 14:50:02 +0100 (IST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 82357BE53; Thu, 30 Apr 2015 14:50:02 +0100 (IST)
Message-ID: <>
Date: Thu, 30 Apr 2015 14:50:02 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Roland Zink <>,
References: <> <> <>
In-Reply-To: <>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [TLS] who do I poke to fix the URLs in the header?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Apr 2015 13:50:13 -0000


On 30/04/15 14:38, Roland Zink wrote:
> Hi Stephen,
> does this mean 

Well, no there is no "this" that means anything yet:-) Like I said, I'll
bring it to the IESG and bring any conclusions back (probably not to
this list but somewhere more appropriate though I'll send a pointer
here so those who care can follow up.)

> that in order to implement TLS (read the specification)
> you need to use TLS (know how it is working)? 

No. For RFCs and I-Ds there are many mirrors and we just finished a
discussion on the main IETF list (about ftp) where I think it was
clear that we have a bunch of folks who want things available in
cleartext even if the defaults become to access things via TLS.
(There wasn't a consensus call on exactly that though, so that's
just my synopsis.)

> Is it possible to let the
> client decide and offer alternate services when the client does not use
> https?

It is quite possible. I'd even not be surprised if the outcome were
to default to https URIs but to ensure http equivalents are available.

But the main thing is that nobody ought get scared that we'll make
some mad change without chatting with the community about that first.
We (the IESG) know exactly how badly beaten up we'd deserve to be
if we did that.


> Regards,
> Roland
> On 30.04.2015 10:06, Stephen Farrell wrote:
>> Hi Dave,
>> That brings in a bunch of things including tools, boilerplate
>> issues and policy stuff ("do we want an https-everything like
>> thing for the IETF?"). Good questions to ask though so I'll put
>> that on the IESG's agenda for some meetings we're having next
>> week. Please hassle me in 2-3 weeks if you don't hear something
>> back.
>> Cheers,
>> S.
>> On 30/04/15 01:35, Dave Garrett wrote:
>>> Where does the "Status of This Memo" and "Copyright Notice" text get
>>> pulled from? There seems to be some black magic involved in the build
>>> process, and I don't see where that text lives. I'd like to request
>>> the two URLs be updated, but I don't know where to ask.
>>> status has:
>>> which redirects to:
>>> which does support TLS, and should be:
>>> copyright has:
>>> which redirects to:
>>> which does support TLS, and should be:
>>> the initial URL also supports TLS, so this works:
>>> however that redirects to HTTP, not HTTPS (...sigh)
>>> So, yeah... I'd like the new TLS spec to actually attempt to use TLS
>>> in its URLs, where possible. To do this needs:
>>> 1) Update those two URLs in the template for these sections to use
>>> the HTTPS equivalent (in the case of "status", also change "current"
>>> to "active").
>>> 2) Get someone to fix the redirects on to redirect
>>> to HTTPS, at minimum when already coming from HTTPS.
>>> Actually using TLS by default might also be a plan...
>>> As to other URLs in the document, I added a couple 's'es in my minor
>>> fixes branch/PR. There are additional domains that do support HTTPS,
>>> technically, but they get cert errors... because of course they do.
>>> The RFC references have an odd inconsistency here. In the numbered
>>> working group drafts, they properly generate with HTTPS links:
>>> However, in the editor's copy (draft-ietf-tls-tls13-latest), they
>>> generate with HTTP links:
>>> That needs fixing if just for consistency.
>>> Also, should of course be using HTTPS by default, but
>>> it's not.
>>> Dave
>>> _______________________________________________
>>> TLS mailing list
>> _______________________________________________
>> TLS mailing list
> _______________________________________________
> TLS mailing list