Re: [DNSOP] HTTPS upgrades (was Re: Benjamin Kaduk's Discuss on draft-ietf-dnsop-svcb-https-08: (with DISCUSS and COMMENT))

2022-03-01 Thread Benjamin Kaduk
On Wed, Mar 02, 2022 at 02:46:05PM +1100, Martin Thomson wrote:
> On Wed, Mar 2, 2022, at 14:18, Benjamin Kaduk via Datatracker wrote:
> > This (mostly implicit) requirement is a potential barrier for adoption of
> > the HTTPS RRtype, and while the precondition is very often going to be
> > satisfied, I wanted to get a sense for whether we should make the
> > requirement more explicit, and possibly more prominent in the document
> > (e.g., mention it in the Introduction).  I don't know what the right
> > answer is, but it seems important enough to ensure that the topic receives
> > deliberate consideration.
> 
> Your point about highlighting more than loss of functionality is a good one.  
> The idea that request semantics might be altered by swapping the scheme is 
> far more relevant.
> 
> That said, I'm comfortable with deploying with the upgrade requirement as 
> stated.  While we did have a number of examples where the assumed 
> HTTP<->HTTPS equivalence did not hold in the past, the diminishing share of 
> cleartext HTTP usage is overwhelmingly the vestiges that do not have any 
> HTTPS service on the same name.  
> 
> As noted, those servers with a need to maintain distinct resources that 
> differ only in scheme simply cannot use the HTTPS RR.  That is entirely 
> appropriate.
> 

For clarity, I'm also comfortable with the upgrade requirement as stated;
this discuss was intended to just relate to how and how much we talk about
the requirement.

-Ben

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] HTTPS upgrades (was Re: Benjamin Kaduk's Discuss on draft-ietf-dnsop-svcb-https-08: (with DISCUSS and COMMENT))

2022-03-01 Thread Martin Thomson
On Wed, Mar 2, 2022, at 14:18, Benjamin Kaduk via Datatracker wrote:
> This (mostly implicit) requirement is a potential barrier for adoption of
> the HTTPS RRtype, and while the precondition is very often going to be
> satisfied, I wanted to get a sense for whether we should make the
> requirement more explicit, and possibly more prominent in the document
> (e.g., mention it in the Introduction).  I don't know what the right
> answer is, but it seems important enough to ensure that the topic receives
> deliberate consideration.

Your point about highlighting more than loss of functionality is a good one.  
The idea that request semantics might be altered by swapping the scheme is far 
more relevant.

That said, I'm comfortable with deploying with the upgrade requirement as 
stated.  While we did have a number of examples where the assumed HTTP<->HTTPS 
equivalence did not hold in the past, the diminishing share of cleartext HTTP 
usage is overwhelmingly the vestiges that do not have any HTTPS service on the 
same name.  

As noted, those servers with a need to maintain distinct resources that differ 
only in scheme simply cannot use the HTTPS RR.  That is entirely appropriate.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop