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

From: Dave Garrett <[email-masked]>
Date: Wed, 29 Apr 2015 20:35:21 -0400

https://tlswg.github.io/tls13-spec/
https://tools.ietf.org/html/draft-ietf-tls-tls13-05

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:
http://datatracker.ietf.org/drafts/current/
which redirects to:
http://datatracker.ietf.org/doc/active/
which does support TLS, and should be:
https://datatracker.ietf.org/doc/active/

copyright has:
http://trustee.ietf.org/license-info
which redirects to:
http://trustee.ietf.org/trust-legal-provisions.html
which does support TLS, and should be:
https://trustee.ietf.org/trust-legal-provisions.html
the initial URL also supports TLS, so this works:
https://trustee.ietf.org/license-info
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 trustee.ietf.org 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:
https://tools.ietf.org/html/draft-ietf-tls-tls13-05#section-13.1
However, in the editor's copy (draft-ietf-tls-tls13-latest), they generate with HTTP links:
https://tlswg.github.io/tls13-spec/#rfc.references.1

That needs fixing if just for consistency.

Also, tools.ietf.org should of course be using HTTPS by default, but it's not.

Dave

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 30 Apr 2015 09:06:30 +0100

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:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
> 
>

---

From: Dave Garrett <[email-masked]>
Date: Thu, 30 Apr 2015 09:33:49 -0400

Thanks. Note that while I am asking about policy, in that I think having HTTPS used for all IETF servers by default is a good idea, that is not the primary issue I'm bringing up here. At the moment, I'd just like the URLs updated to use HTTPS for what already supports it.

As to the normative & informative references, the I-D uses relative URLs and the Editor's Copy uses absolute HTTP URLs, which is what seems to cause the inconsistency of not using the same scheme when loading the pages over HTTPS. The Editor's Copy could use double-slash relative URLs to get the same effect, at minimum. Just using HTTPS links for everything would be simpler, though.

Dave

---

From: Roland Zink <[email-masked]>
Date: Thu, 30 Apr 2015 15:38:05 +0200

Hi Stephen,

does this mean that in order to implement TLS (read the specification) 
you need to use TLS (know how it is working)? Is it possible to let the 
client decide and offer alternate services when the client does not use 
https?

Regards,
Roland

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 30 Apr 2015 14:50:02 +0100

Hiya,

On 30/04/15 14:38, Roland Zink wrote:
> 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

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.

Cheers,
S.

>>> 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:
>>> 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 trustee.ietf.org to redirect
>>> to HTTPS, at minimum when already coming from HTTPS.
>>>
>>> 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:

---

From: Dave Garrett <[email-masked]>
Date: Thu, 30 Apr 2015 10:54:20 -0400

On Thursday, April 30, 2015 09:50:02 am Stephen Farrell wrote:
> For RFCs and I-Ds there are many mirrors and we just finished a

That sounds like it would be a reasonable consensus, IMO. HTTPS by default everywhere is a good thing, but I agree that the IETF should probably have all documents also available in cleartext somewhere too. (preferably with hashes that can be verified via some secure channel)

Dave

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 30 Apr 2015 15:57:14 +0100

On 30/04/15 15:54, Dave Garrett wrote:
> preferably with hashes that can be verified via some secure channel

See [1] and mostly thank Russ Housley if you like that:-)

S.

[1] https://www.ietf.org/id-info/idsignatures.html