Subject: Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Feb 2012 18:26:27 +0000

Down below, for the proposed HTTP/2.0 work it says:

 > * Reflecting modern security requirements and practices

In some earlier discussion I asked what "modern" means
there. It seems to mean at least working well with TLS,
but I'm not sure what else is meant, if anything.

In particular, I think it'd be good to try get better
(more usable, more secure etc.) HTTP authentication
defined as a built-in part of HTTP/2.0.

My initial take is that if we're not going to do this
for a major revision of the protocol, then when are we
going to do it? So I'd like to see that included.

The counter argument offered was that better HTTP
authentication is complex and probably hard to get right
and so would be better handled separately.

While that's not an unreasonable point, my counter-counter
argument is that it doesn't seem to have worked very well
so far.

It was also argued that this charter is scoped to just
allow for selection of an initial candidate for HTTP/2.0
and there'd be another re-charter to follow based on that
selected candidate, so that discussion of specific
security features would be better done after that when
there's a specific protocol on which to do work.

My worry about that is that in practice the main
security aspects of a putative HTTP/2.0 will be very
hard to change at that point, so I'd like to see it
discussed as part of this phase of the work.

What do others think?

Thanks,
Stephen.

PS: When I say "like" above, that's what I'd personally
like, not a position that I'm adopting as a security AD.
(Alhough that'd be a fairly predictable position I guess:-)

On 02/21/2012 06:10 PM, IESG Secretary wrote:
> A modified charter has been submitted for the Hypertext Transfer
> Protocol Bis (httpbis) working group in the Applications Area of the
> IETF.  The IESG has not made any determination as yet.  The modified
> charter is provided below for informational purposes only.  Please send
> your comments to the IESG mailing list ([email-masked]) by Tuesday,
> February 28, 2012.
>
> Hypertext Transfer Protocol Bis (httpbis)
> =========================================
>
> Charter
> Last Modified: 2012-02-09
>
> Current Status: Active Working Group
>
> Chair(s):
>      Mark Nottingham<[email-masked]>
>
> Applications Area Director(s):
>      Pete Resnick<[email-masked]>
>      Peter Saint-Andre<[email-masked]>
>
> Applications Area Advisor:
>      Peter Saint-Andre<[email-masked]>
>
> Mailing Lists:
>      General Discussion:[email-masked]
>      To Subscribe:      [email-masked]
>          In Body:       subscribe
>      Archive:           http://lists.w3.org/Archives/Public/ietf-http-wg/
>
> Description of Working Group
> ----------------------------
>
> This Working Group is charged with maintaining and developing
> the "core" specifications for HTTP.
>
> The Working Group's specification deliverables are:
> * A document (or set of documents) that is suitable to supersede RFC
>   2616 (HTTP/1.1) and move RFC 2817 to Historic status
> * A document cataloguing the security properties of HTTP/1.1
> * A document that specifies HTTP/2.0 an improved binding of HTTP's
>   semantics to the underlying transport.
>
> ### HTTP/1.1
>
> HTTP is one of the most successful and widely-used protocols on the
> Internet today. However, its specification has several editorial issues.
> Additionally, after years of implementation and extension, several
> ambiguities have become evident, impairing interoperability and the
> ability to easily implement and use HTTP.
>
> The working group will refine RFC2616 to:
> * Incorporate errata and updates (e.g., references, IANA registries,
>   ABNF)
> * Fix editorial problems which have led to misunderstandings of the
>   specification
> * Clarify conformance requirements
> * Remove known ambiguities where they affect interoperability
> * Clarify existing methods of extensibility
> * Remove or deprecate those features that are not widely implemented
>   and also unduly affect interoperability
> * Where necessary, add implementation advice
> * Document the security properties of HTTP and its associated
>   mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for
>   common applications
>
> It will also incorporate the generic authentication framework from RFC
> 2617, without obsoleting or updating that specification's definition of
> the Basic and Digest schemes.
>
> Finally, it will incorporate relevant portions of RFC 2817 (in
> particular, the CONNECT method and advice on the use of Upgrade), so
> that that specification can be moved to Historic status.
>
> In doing so, it should consider:
> * Implementer experience
> * Demonstrated use of HTTP
> * Impact on existing implementations and deployments
>
> ### HTTP/2.0
>
> There is emerging implementation experience and interest in a protocol
> that retains the semantics of HTTP, without the legacy of HTTP/1.x
> message framing and syntax, which have been identified as hampering
> performance and encouraging misuse of the underlying transport.
>
> As such, there is an opportunity to create a new major
> (non-wire-compatible) version of HTTP.
>
> To do this, the Working Group will solicit candidates for this work from
> the community, to be submitted as Internet-Drafts. Expected focus areas
> for candidates include:
>
> * Significantly improved perceived performance in common use cases
>   (e.g., browsers, mobile)
> * More efficient use of network resources; in particular, reducing the
>   need to use multiple TCP connections
> * Ability to be deployed on today's Internet, using IPv4 and IPv6, in
>   the presence of NATs
> * Maintaining HTTP's ease of deployment
> * Reflecting modern security requirements and practices
>
> Although proposals are not required to meet all of these goals, it is
> expected that the resulting work (if undertaken) will be chartered to
> meet them (and therefore, selecting one that meets the majority of them
> as a starting point is in everyone's interest).
>
> The Working Group will then select a starting point for the new work
> based upon the following criteria:
>
> * Compatibility with HTTP/1.1 semantics; i.e., it must be possible to
>   pass through a HTTP/1.1 message with reasonable fidelity
> * Broad implementer interest (e.g., from Web browsers, "back-end"
>   or "web api" uses of HTTP, servers, intermediaries, CDNs, etc.)
>
> Changes to the existing semantics of HTTP are out of scope in order to
> preserve the meaning of messages that might cross a 1.1 -->  2.0 -->  1.1
> request chain. However, the resulting effort may define new semantics to
> further the goals above, along with suitable extensibility mechanisms
> for defining additional semantics.
>
> If the Working Group forms consensus around a proposal to use as a
> starting point, it is expected it will re-charter to begin work on that
> document (or set of documents). The resulting work will be known as
> "HTTP/2.0", unless the Working Group determines that this isn't suitable
> (e.g., for interoperability).
>
> Although work on this new version will begin in parallel with completion
> of work on HTTP/1.1, the Working Group will prioritize HTTP/1.1 work
> until it is complete.
>
> Goals and Milestones
> ---------------------
>
>    Done        First HTTP/1.1 Revision Internet Draft
>
>    Done        First HTTP Security Properties Internet Draft
>
>    Feb 2012    Working Group Last Call for HTTP/1.1 Revision
>
>    Feb 2012    Working Group Last Call for HTTP Security Properties
>
>    Feb 2012    Call for Proposals for HTTP/2.0
>
>    Apr 2012    Submit HTTP/1.1 Revision to IESG for consideration as a
>                Proposed Standard
>
>    Apr 2012    Submit HTTP Security Properties to IESG for
>                consideration as Informational RFC
>
>    June 2012   Re-charter to work on HTTP/2.0
>
> ###
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 21 Feb 2012 19:33:08 +0100

> and so would be better handled separately.

I believe this should be orthogonal to HTTP/2.0. Is there a specific 
thing that makes it impossible to use the existing authentication framework?

> ...

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Feb 2012 18:37:12 +0000

> thing that makes it impossible to use the existing authentication

Who knows? We don't have a protocol on the table yet. I
would imagine that some level of backwards compatibility
would be a requirement of course, or at least an issue to
be considered.

But the existing HTTP client authentication is also not
necessarily very useful, and there have been a number of
efforts to improve on that, none of which seem to have
gotten sufficient traction to get widely deployed/used.
Maybe HTTP/2.0 is a good time to try fix that.

S.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 21 Feb 2012 19:50:04 +0100

> Maybe HTTP/2.0 is a good time to try fix that.

Well, we have an existing authentication framework. It would be 
interesting to find out what's missing from it.

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Feb 2012 22:19:28 +0000

Hi Julian,

> interesting to find out what's missing from it.

Fair point.

I would wonder whether that framework could be used
as-is if HTTP/2.0 does do away "with the of HTTP/1.x
message framing and syntax" but I guess some equivalent
functionality could be defined in that case.

So as in my initial mail the 1st question here is, what
does "modern" mean in this draft charter? E.g. does it
mean "same as the current framework with different
bits" or something else? If so, what?

And then should it include adding some new options
or MTI auth schemes as part of HTTP/2.0 or even looking
at that? (I think it ought to include trying for that
personally, even if there is a higher-than-usual risk
of failure.)

S

---

From: Barry Leiba <[email-masked]>
Date: Tue, 21 Feb 2012 17:36:11 -0500

>
> browser id, openid, and oauth are all authentication frameworks built
> on top of HTTP
>

OAuth is an authorization framework, not an authentication one.  Please be
careful to make the distinction.

What we're looking at here is the need for an HTTP authentication system
that (for example) doesn't send reusable credentials, is less susceptible
to spoofing attacks, and so on.

Barry

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 22 Feb 2012 09:40:02 +1100

> functionality could be defined in that case.

That shouldn't affect the framework at all. At most, you'd have to define how to re-serialise the current syntax if you don't have a way to "tunnel" it (since HTTP/1.1 passthrough is required).

> bits" or something else? If so, what?

As discussed off-list, I'd be happy to drop this phrase from *this* charter, in anticipation of it being worked out in discussions about the *next* one.

> personally, even if there is a higher-than-usual risk

Based on past experience, I think the risk is very high, and we don't need to pile any more risk onto this particular project. 

Also, most of the discussions about authentication and associated problems on the Web are *not* exclusive to HTTP or even protocol artefacts; they include concerns like UI and human factors, integration into hypertext, etc. As such, what we really need is a "whole of stack" focus on Web authentication; shoving it into this particular WG will, IMO, lead to a predictable failure.

Regards,

--
Mark Nottingham
http://www.mnot.net/

---

From: Tim Bray <[email-masked]>
Date: Tue, 21 Feb 2012 14:46:14 -0800

[in-line]

> Based on past experience, I think the risk is very high, and we don't need to pile any more risk onto this particular project.

+1

HTTP's ability to be equipped with security technology has been
adequate, and I haven't heard much argument that its semantics were
the big obstacle to newer/better security.  Preserving its semantics
means its successor should be equally adequate.

Mnot is *understating* the risk of loading up the charter with this stuff. -T

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Feb 2012 22:53:12 +0000

> As discussed off-list, I'd be happy to drop this phrase from *this* charter, in anticipation of it being worked out in discussions about the *next* one.

Well, I think the phrase does need to be replaced
by something else all right.

I'm reluctant to omit mention of security entirely
of course and do want to know what's gonna be done
for authentication in a putative HTTP/2.0.

Like I said, I'm pretty skeptical that any significant
change to security properties will be achievable at
that next charter stage.

> Based on past experience, I think the risk is very high, and we don't need to pile any more risk onto this particular project.

Based on past experience the milestones for this will be
wildly optimistic and it'll really take five years so at
the end of 2017 we'll be right where we are in terms of
HTTP authentication for all of which time HTTP authentication
will be the "next thing" to do. (Ok, I'm exaggerating a
bit there.)

I think both experiences are valid.

> Also, most of the discussions about authentication and associated problems on the Web are *not* exclusive to HTTP or even protocol artefacts; they include concerns like UI and human factors, integr…

It is true that many sites don't use HTTP authentication
for UI reasons. I don't think it follows that doing nothing
is the right approach. (Well, one could argue to remove all
user authentication from HTTP I guess - is that one of the
proposals?)

Cheers,
S.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 22 Feb 2012 09:55:41 +1100

Stephen, 

The approach we're advocating for this WG is to solicit well-formed proposals, select one and develop it. 

If there isn't one for HTTP authentication, how are you advocating we proceed?

Regards,

--
Mark Nottingham
http://www.mnot.net/

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Feb 2012 23:01:09 +0000

> If there isn't one for HTTP authentication, how are you advocating we proceed?

I'm not thinking now in terms of advocating a specific
proposal for how to proceed.

Right now, I'm interested in what others reviewing the
draft charter think about this topic. That's the point
of having this discussion in the open like this.

(So maybe I should shut up for a while:-)

S

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Feb 2012 22:14:29 -0500

>>>>> "Barry" == Barry Leiba <[email-masked]> writes:
    Barry> OAuth is an authorization framework, not an authentication
    Barry> one.  Please be careful to make the distinction.

    Barry> What we're looking at here is the need for an HTTP
    Barry> authentication system that (for example) doesn't send
    Barry> reusable credentials, is less susceptible to spoofing
    Barry> attacks, and so on.

and is implemented in HTTP, not in terms of HTML forms, yet has all the 
flexibility of the HTML form method?

Or is that still out of scope?

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: David Morris <[email-masked]>
Date: Tue, 21 Feb 2012 23:04:45 -0800 (PST)

> flexibility of the HTML form method?

And includes the ability for the user to logoff / the server reset the 
login?

---

From: Julian Reschke <[email-masked]>
Date: Wed, 22 Feb 2012 09:39:33 +0100

On 2012-02-22 08:04, David Morris wrote:
>>>>>>> "Barry" == Barry Leiba<[email-masked]>  writes:

Is that a protocol problem or a user agent problem?

-- > <http://lists.w3.org/Archives/Public/www-archive/2012Jan/0023.html>

Best regards, Julian

---

From: Hector Santos <[email-masked]>
Date: Wed, 22 Feb 2012 05:06:47 -0500

> -- > <http://lists.w3.org/Archives/Public/www-archive/2012Jan/0023.html>

Possibly both.

First, its a non-issue with cookie based authentication methods 
(server side fancy login forms) but it is by using a cookie condition 
can you emulate a "Logoff" concept with HTTP BASIC/DIGEST AUTH due to 
the browser current persistent nature to continue reissing 
BASIC/DIGEST authenticated credentials until a 403 is issued.

The cookie i.e. "SESSION-OVER" is required to trap/trigger/recognized 
when a 403 condition should be used upon subsequent requests.  That 
will cause the Browser to forget (either full or partially the current 
credentials). Depending on the browser, it could mean a lost of 
reusing them without typing them until the browser is completely closed.

But without a cookie, there is no logoff button concept with HTTP 
AUTH.   So the question is does HTTP AUTH requires cookies to work. 
Since it does not, if a clearing of the credentials perhaps with a new 
40x or redefinition of the existing 40x, is desired, it also has to be 
based on not requiring a cookie.

In regards to the generic problem statement Barry stated, sounds to me 
that this calls for a persistent IP session level management concept. 
  A related question is to decide who is going to be asking for the 
initial credentials, the browser or a server-side login form concept?

-- 
Hector Santos, CTO
http://www.santronics.com

---

From: Hector Santos <[email-masked]>
Date: Wed, 22 Feb 2012 05:48:51 -0500

> to spoofing attacks, and so on.

Hi Barry, maybe I should review the drafts (or not), but if its hasn't
been considered, this sounds like the only way possible is with a
persistent IP connection session management concept.

I can relate it based on our PCI framework for the web server and much
of the modeling was based on our existing non-http multi-device
hosting servers already 100% based on a persistent connection IP or
line, channel.  Definitely works in areas where only one browser or
machine is allowed.

I was looking forwarding to further exploring WebSockets to possible
be part of (revitaling) this solution as well, since it work nicely
with the persistent IP concept with the backend.

On a related note, some web sites do this and I first saw it with
facebook where it knows where I am logging in from. In a recent philly
trip, I tried to log on and interestingly got a new login form where
it indicated I was at a different location. I had to verify who I was
again, if I recall via my email/login account at gmail.com.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 22 Feb 2012 07:03:37 -0800

>>>>> On Tue, 21 Feb 2012 23:01:09 +0000, Stephen Farrell <[email-masked]> said:

>> If there isn't one for HTTP authentication, how are you advocating we proceed?

SF> Right now, I'm interested in what others reviewing the
SF> draft charter think about this topic. That's the point
SF> of having this discussion in the open like this.

IMHO, if you want security to be well integrated into the next version
of the protocol, then it should be thought about up front.  The IETF
doesn't have a great track record of adding security later to protocols
in a way that is seamless and integrated.

And if you don't put thinking about security in the "solicitation
request" charter version, then you may well end up in the state that
Mark is worried about: none of the answers have security considered.

I think the charter should definitely have a requirement indicating that
proposals must explain how security techniques would fit into it in the
future, even if they don't fully define the solution/extension itself.
-- 
Wes Hardaker
SPARTA, Inc.

---

From: David Morris <[email-masked]>
Date: Wed, 22 Feb 2012 07:25:16 -0800 (PST)

> -- > <http://lists.w3.org/Archives/Public/www-archive/2012Jan/0023.html>

I consider it a protocol issue in the same way that authentication is a
protocol issue.

The question I was responding to was one of adoption by application
developers and is in addition to the lack of application control over
the current authenticate dialog. A "use case" if you will.

The JS approach isn't really adequate because not all user agents
execute the payload. Second 1/2 of the "use case."

I'm not advocating that this be solved as part of the Recharter/2.0
activity, I'm neutral on the where question.

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 22 Feb 2012 11:38:05 +1300

Hi Julian,

> interesting to find out what's missing from it.

session support with login and logout would be good.  I know it's a can 
of worms, with some serious security implications.

But this is why no websites use HTTP auth to speak of, which makes it 
difficult to do integrated authentication.

Adrien

---

From: Hector Santos <[email-masked]>
Date: Wed, 22 Feb 2012 05:44:49 -0500

-- 
Sincerely

Hector Santos
http://www.santronics.com
jabber: [email-masked]

---

From: David Harrington <[email-masked]>
Date: Wed, 22 Feb 2012 08:04:54 -0500

Hi,

Having been involved in adding security after-the-fact to SNMP, and to
Syslog, and adding authorization after-the-fact to netconf, I know it is
extremely difficult to add security "later".

I strongly believe that if http is going to be redesigned enough to
justify a 2.0 label, then security should be part of its design from the
start. Therefore I think that security should be addressed as part of the
http 2.0 effort, not after the fact.

I can understand the concerns about doing both at the same time increasing
the risk to both, and that serializing the work might reduce the risk. So
I suggest you COULD design the web security standard first, and then
design HTTP 2.0 to take the updated web security standards into
consideration. Web security will be easier if it doesn't need to somehow
fit into an HTTP 2.0 that didn't consider a viable security approach
up-front.

--
David Harrington
Director, Transport Area
Internet Engineering Task Force (IETF)
[email-masked]
+1-603-828-1401

On 2/21/12 6:01 PM, "Stephen Farrell" <[email-masked]> wrote:

>>>> As discussed off-list, I'd be happy to drop this phrase from *this*
>>>>charter, in anticipation of it being worked out in discussions about
>>>>the *next* one.
>>>
>>>> Based on past experience, I think the risk is very high, and we don't
>>>>need to pile any more risk onto this particular project.
>>>
>>>> Also, most of the discussions about authentication and associated
>>>>problems on the Web are *not* exclusive to HTTP or even protocol
>>>>artefacts; they include concerns like UI and human factors,
>>>>integration into hypertext, etc. As such, what we really need is a
>>>>"whole of stack" focus on Web authentication; shoving it into this
>>>>particular WG will, IMO, lead to a predictable failure.
>>>

---

From: Albert Lunde <[email-masked]>
Date: Wed, 22 Feb 2012 10:32:19 -0600

It seems like what would be useful would be a way of bringing in trusted 
third-parties into authentication that didn't look like a 
man-in-the-middle attack, and didn't rely on JavaScript.

SAML "federation" (e.g. Shibboleth) is layered on top of HTML+HTTP,
but it, and most of the other existing WebSSO systems, rely on 
JavaScript tricks somewhere in their process.

Trusted third parties are presently more the domain of certificates or 
Kerberos, than HTTP as such.

SASL is another framework for layering authentication onto protocols, 
that's been worked on considerably. But I don't know if it can meet the 
needs of the browser-based market now being served by 
forms+cookies+JavaScript.

Finding a single authentication/authorization framework that serves the 
needs of both browser and non-broswer clients is hard.

Scott Cantor has written a lot about why global logout for Shibboleth is 
hard to implement. Part of that may rest on the underlying legacy 
mechanisms they are using, but it's also a communication problem.

Having a local logout that really meant "stop sending cookies and 
credentials for realm X to these servers" and/or authentication realms 
that spanned servers might help, I don't know.

-- 
     Albert Lunde  [email-masked]
                   [email-masked]  (address for personal mail)

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Feb 2012 09:31:50 -0800

The earnest calls for better authentication on this thread appear to ignore the fact that the very things that are being requested were put out of scope for the websec WG in their charter. I hope that no one things that a WG in the Applications Area will be better equipped to come up with a better authentication mechanism than one in the Security Area.

Asking the HTTPheads to guess what the securityheads might want is not a good way to design HTTP 2.0.

Proposal: leave the httpbis WG charter as-is and re-charter the websec WG to consider what is needed in the HTTP authentication model. Later, recharter the websec WG to, you know, actually do the security work for authentication.

--Paul Hoffman

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Feb 2012 10:39:14 -0700

On 2/22/12 10:31 AM, Paul Hoffman wrote:
> The earnest calls for better authentication on this thread appear to
> ignore the fact that the very things that are being requested were
> put out of scope for the websec WG in their charter. I hope that no
> one things that a WG in the Applications Area will be better equipped
> to come up with a better authentication mechanism than one in the
> Security Area.

The WebSec WG is in the Applications Area.

> not a good way to design HTTP 2.0.

Probably not.

> Proposal: leave the httpbis WG charter as-is and re-charter the
> websec WG to consider what is needed in the HTTP authentication
> model. Later, recharter the websec WG to, you know, actually do the
> security work for authentication.

Or charter a separate WG to focus on HTTP authentication. (You might
recall that the BoF leading to formation of the WebSec WG was entitled
HASMAT = "HTTP Application Security Minus Authentication and Transport"
or somesuch.)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Feb 2012 09:52:37 -0800

> The WebSec WG is in the Applications Area.

Yeeps! My apologies. I guess seeing a room full of security regulars made me forget.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 22 Feb 2012 18:35:17 +0000

> Yeeps! My apologies. I guess seeing a room full of security regulars made me forget.

Regardless of that you do have a fair point that asking
apps folks to do stuff that'll please security folks might
be asking for trouble:-)

However, the counter to that is that security folks doing
stuff without enough apps input might produce something that
won't get adopted which also doesn't produce the right end
result.

Anyway, I think this topic, if tackled, won't lack
interested participants and will get plenty of security
and apps input no matter how we organise it.

S.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Feb 2012 10:39:49 -0800

> and apps input no matter how we organise it.

Peter St.Andre's suggestion of a separate WG to deal specifically with HTTP authentication seems like the best way to be sure both sets of parties are fully involved. If the IESG charters it within the next few months, the HTTP 2.0 work can be informed by any changes (if any) that are needed.

--Paul Hoffman

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Feb 2012 14:18:46 -0700

On 2/22/12 11:39 AM, Paul Hoffman wrote:
>> Regardless of that you do have a fair point that asking apps folks
>> to do stuff that'll please security folks might be asking for
>> trouble:-)
>> 
>> However, the counter to that is that security folks doing stuff
>> without enough apps input might produce something that won't get
>> adopted which also doesn't produce the right end result.
>> 
>> Anyway, I think this topic, if tackled, won't lack interested
>> participants and will get plenty of security and apps input no
>> matter how we organise it.
> 
> 
> Peter St.Andre's suggestion of a separate WG to deal specifically
> with HTTP authentication seems like the best way to be sure both sets
> of parties are fully involved. If the IESG charters it within the
> next few months, the HTTP 2.0 work can be informed by any changes (if
> any) that are needed.

By the way, I forwarded this message to the [email-masked] list
(yes, we already have a discussion list for these topics). The small
sample of replies indicates that (1) folks would prefer to broaden the
topic to web authentication, not strictly HTTP authentication and (2)
not everyone who is interested in these topics subscribes to the more
general [email-masked] list.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 23 Feb 2012 10:04:10 +0200

On 2/22/12 12:40 AM, Mark Nottingham wrote:
> Also, most of the discussions about authentication and associated problems on the Web are*not*  exclusive to HTTP or even protocol artefacts; they include concerns like UI and human factors, integration into hypertext, etc. As such, what we really need is a "whole of stack" focus on Web authentication; shoving it into this particular WG will, IMO, lead to a predictable failure.
I agree with Mark on this point

/Salvatore

---

From: David Harrington <[email-masked]>
Date: Wed, 22 Feb 2012 12:37:34 -0500

Point taken.

On 2/22/12 12:31 PM, "Paul Hoffman" <[email-masked]> wrote:

>ignore the fact that the very things that are being requested were put
>out of scope for the websec WG in their charter. I hope that no one
>things that a WG in the Applications Area will be better equipped to come
>up with a better authentication mechanism than one in the Security Area.
>
>Proposal: leave the httpbis WG charter as-is and re-charter the websec WG
>to consider what is needed in the HTTP authentication model. Later,
>recharter the websec WG to, you know, actually do the security work for
>authentication.
>
>--Paul Hoffman

---

From: Doug Barton <[email-masked]>
Date: Thu, 23 Feb 2012 14:38:23 -0800

For my money it would be quite important for an HTTP 2.0 definition to
make SRV DNS records a full-fledged participant in the standard. Minimum
once a month there is someone asking for help on bind-users@ for which
the answer is, "The solution to that _would_ be SRV records, if they
were supported."

2782 was published 12 years ago this month. I suppose it can be
considered mature enough to deploy at this point? :)

Doug

-- 

	It's always a long day; 86400 doesn't fit into a short.

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 23 Feb 2012 17:13:53 -0800

> HASMAT = "HTTP Application Security Minus Authentication and Transport"

Please understand that this exact same discussion was had in 1994 and
the IESG decided that the applications area couldn't possibly do this
work on their own, so they created a security area working group to
handle it.  That HTTP Security group, which was dominated by folks who
did not have any implementations of HTTP, decided to ignore the problem
for which they were chartered and instead invented SHTTP.

More importantly, the effect of that decision was that the people who
get work done at the IETF were prevented from improving HTTP's auth
mechanisms because it was out of scope, while the people who had it
in scope had no corresponding incentive to get it DONE.

Every time this topic comes up, people want to shove it off to some
other working group that is somehow going to magically get off its
collective ass and do real work.  Why?  It doesn't work.  It never
has worked.  We've gone through four iterations now of revising HTTP,
each one starting off with the same discussion, and each one concluding
that auth would be better owned by someone else.

There is nobody else.

How many times do we have to do this before we declare insanity?
I don't care how much risk it adds to the HTTP charter.  They are
all just meaningless deadlines anyway.  If we want HTTP to have
something other than Basic (1993) and Digest (1995) authentication,
then it had better be part of *this* charter so that the proposals
can address them.

....Roy

---

From: Tim Bray <[email-masked]>
Date: Thu, 23 Feb 2012 17:18:56 -0800

> then it had better be part of *this* charter so that the proposals

Well, Digest already isn't used by anyone :)

Seriously, someone needs to propose some charter language or this
discussion is a no-op.  -Tim

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 23 Feb 2012 17:23:45 -0800

> then it had better be part of *this* charter so that the proposals

If only it were that simple. If the answer is "design an HTTP auth mechanism that is better than Digest", then this is a tractable goal. If it is "get IETF consensus on that auth mechanism", then it isn't. The latter has proven to be impossible because people say (possibly rightly) that web developers don't want auth mechanisms that use the browser chrome: they want auth in HTML, and anything that relies on the browser chrome is insufficient.

Notice how the topic changed from "HTTP" to "web" for the security discussion but not for the httpbis charter discussion? That topic-change has derailed the HTTP authentication discussions at recent (and not-so-recent) IETF meetings.

If the charter has "develop HTTP authentication mechanisms beyond Digest", that's great: we already have seen about five proposals in the past few years for those, some of them with security analyses. If the charter says "...and specify one that is mandatory to implement", that seems prone to consensus failure because of religion about zero-knowledge proofs versus operational simplicity, but I would be overjoyed to be wrong about that.

--Paul Hoffman

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 23 Feb 2012 17:24:07 -0800

> Well, Digest already isn't used by anyone :)

A popular misconception because it works unseen.  See tools.ietf.org

> discussion is a no-op.  -Tim

"Proposals for new HTTP authentication schemes are in scope."

....Roy

---

From: Tim Bray <[email-masked]>
Date: Thu, 23 Feb 2012 17:34:22 -0800

+1

I don’t think we’ll get one, but in the unlikely event someone can
build consensus for something, there’s no reason to brand it as
out-of-bounds.  -T

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 23 Feb 2012 18:21:14 -0800

> If only it were that simple. If the answer is "design an HTTP auth mechanism that is better than Digest", then this is a tractable goal. If it is "get IETF consensus on that auth mechanism", then i…

I don't need IETF consensus, just rough consensus and running code,
and I have no need to satisfy folks who think the Web is a browser.
The hard part is deploying anything that is incompatible with
already-deployed clients without letting them fall back to basic.

It is a trivial problem compared to choosing a new, non-MIME syntax.

What "web developers" want is based on what they can do today,
not what they can expect from an entirely new protocol.

> Notice how the topic changed from "HTTP" to "web" for the security discussion but not for the httpbis charter discussion? That topic-change has derailed the HTTP authentication discussions at recen…

It didn't derail them.  They were not on any rails to begin with.

The problem with defining security in a separate group without
shipping implementations is that there is no need to compromise,
no need to identify and resolve specific use cases, and no need
to do something better than nothing.

If we add a requirement to HTTP/2.0 that user authentication MUST
be accomplished via a mechanism not subject to UI spoofing,
then that's what people will implement (if they implement at all).
The protocol can give the server all the control it wants over the
display of a background or separate window explaining what to do
in that other mechanism-not-subject-to-spoofing.  Give people just
enough rope to solve that problem without hanging themselves, and
the rest of HTTP (non-browser clients) can implement right now.

> If the charter has "develop HTTP authentication mechanisms beyond Digest", that's great: we already have seen about five proposals in the past few years for those, some of them with security analys…

I'd be happy with several imperfect mechanisms with differing
trade-offs that can be implemented in parallel.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Feb 2012 13:47:18 +1100

> "Proposals for new HTTP authentication schemes are in scope."

No one has said they're out of scope; this discussion has been about whether -- at this point in time, before we have proposals -- we require the outcome to jump through some particular hoop regarding security. 

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Mark Andrews <[email-masked]>
Date: Fri, 24 Feb 2012 13:54:32 +1100

> considered mature enough to deploy at this point? :)

+1000

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 24 Feb 2012 07:18:00 +0100

>> considered mature enough to deploy at this point? :)

Indeed. Including how to handle the comparison of domain name in the URL / domain name in the target in the SRV with the domain name in a cert. I.e. relationship with DANE.

   Patrik

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Feb 2012 12:54:10 +0000

On 02/24/2012 01:24 AM, Roy T. Fielding wrote:
>> On Thu, Feb 23, 2012 at 5:13 PM, Roy T. Fielding<[email-masked]>  wrote:
>>

How would a plan like the following look to folks:

- httpbis is chartered to include auth mechanism work as
   per the above (or whatever text goes into the charter)
- that'll generate a slew of proposals, some good, some
   bad, some better-than-current and some too complex
- plan is for httpbis to pick something (one or more if
   they want, but one better-than-current one is the goal)
- give all the above a short timeframe (this year, pick
   which to work on at the same time as re-chartering for
   the details of HTTP/2.0 maybe)
- httpbis pick what they want, (zero or more) and go
   do their stuff

- if there's still enough interest in some proposals
   that were not picked by httpbis we then try charter a sec
   area wg to develop experimental specs for those so
   they're off the critical path for httpbis (the rest die
   unloved;-)
- those experimental specs would be REQUIRED to work with
   http/1.1 and/or http/2.0 (as appropriate) with no change
   required to http; that'd be in the charter for that
   putative sec wg
- that sec wg charter might also say that the putative
   wg is not allowed to add new schemes until the
   originally chartered ones are completed (to avoid
   people turning up every week with their shiny new
   scheme)

Might that be a way forward that'll give enough folks
enough of what they want/need?

Cheers,
S.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 24 Feb 2012 07:02:38 -0800

> enough of what they want/need?

It would, but I would like to give a counter-proposal that I think will use people's different talents better:

- new wg on developing http authentication mechanisms is chartered soon (BoF in Paris); call it the ham wg
- httpbis is chartered to follow the work of the ham wg and is required to make sure that the authentication framework in http 2.0 works for as many of the proposals from the ham wg as possible
- ham wg is responsible for most of what you list above
- http2.0 document says "the mandatory to implement auth mechanisms are named in that RFC over there", which comes from the ham wg

There will be overlap in wg membership, but not nearly as much as would be needed for your proposal.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Feb 2012 10:38:19 -0500

> > considered mature enough to deploy at this point? :)

Over in spfbis, people are arguing that the SPF RRTYPE should be
deprecated and abandoned in SPF because nobody uses it because of
practical difficulties in getting new RRTYPEs deployed.  What makes us
think that the arguments in favour of SRV are going to find more
fertile ground?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 24 Feb 2012 16:58:36 +0100

> think that the arguments in favour of SRV are going to find more

Because people disagree on whether it is actually hard to get new RRTYPEs deployed.

I for example do completely disagree on it being hard. Sure, your user interface in the gui of your favorite $EDITOR might not support the new RRTYPE, but should that constrain deployment of good standards?

   Patrik

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 24 Feb 2012 08:25:03 +0100

On Thu, Feb 23, 2012 at 05:23:45PM -0800, Paul Hoffman wrote:
> If only it were that simple. If the answer is "design an HTTP auth mechanism
> that is better than Digest", then this is a tractable goal. If it is "get
> IETF consensus on that auth mechanism", then it isn't. The latter has proven
> to be impossible because people say (possibly rightly) that web developers
> don't want auth mechanisms that use the browser chrome: they want auth in
> HTML, and anything that relies on the browser chrome is insufficient.

Maybe but you still need HTTP-based auth for proxies anyway. Also, I
partially disagree with your point, seeing the number of applications
in enterprise which rely on the hated NTLM auth which is also HTTP-based ;
they're using it because it's transparent to the user, and enterprise
customers do ask for such transparent auth schemes.

There would also be much less need for cookies if auth was carried by the
browser, and this would let the user log off. So I think there's a need
for this.

Regards,
Willy

---

From: John C Klensin <[email-masked]>
Date: Fri, 24 Feb 2012 11:43:31 -0500

--On Friday, February 24, 2012 16:58 +0100 Patrik Fältström
<[email-masked]> wrote:

>> Over in spfbis, people are arguing that the SPF RRTYPE should
>> be deprecated and abandoned in SPF because nobody uses it
>> because of practical difficulties in getting new RRTYPEs
>> deployed.  What makes us think that the arguments in favour
>> of SRV are going to find more fertile ground?
> 
> I for example do completely disagree on it being hard. Sure,
> your user interface in the gui of your favorite $EDITOR might
> not support the new RRTYPE, but should that constrain
> deployment of good standards?

Patrik,

While I don't see it as hard as Andrew does, I don't see it as
easy either.  The problem isn't one's favorite $EDITOR.  It is
the number of folks who, for lots of reasons, haven't upgraded
from operating systems, resolvers, etc., that don't support
newer RRTYPES.   Remember that, while Windows 7 is getting some
of the market share that Vista never did, there are still a huge
number of XP systems out there -- many of them in the hands of
people and organizations who aren't going to make the hardware
investment to upgrade in a difficult economy.  The situation
with the Mac platform actually isn't much better -- I know a lot
of people who haven't (and can't) upgrade from OS 9, much less
to the latest carnivorous feline.  

SRV has the advantage of many year's head start and more utility
to more protocols over, e.g., SPF but the reality remains that,
if some users have support for an important new RRTYPE and
others don't, we have either an inconsistent user experience
(more confusion, more support calls, etc.) or, as we have seen
with DNAME, a need to carry around complex workarounds that can
lead to bugs, vunerabilities, or, ahem, inconsistent user
experience.

And, fwiw, I'm actually much more concerned about use of the DNS
for any part of the process if we don't have broad consensus in
and between the IETF and the implementer community about whether
IRIs or URIs are authoritative and about how domain names
containing IDN labels are encoded in either.   I'm equally
concerned if some organization of our mutual acquaintance is
determined to declare the existence of equivalent names in the
DNS that will create user expectations that certs and comparison
mechanisms cannot support.

> considered mature enough to deploy at this point? :)

One might wish.  But real maturity has to be based on
implementation and deployment, not just publication dates.   I
note, for example, that RFC 736 (an old favorite example of mine
for several reasons) was published over 34 years ago is, like
2782, still at Proposed Standard, and, sadly, hasn't gone
anywhere (at least in the last decade or so).   Certainly it is
elderly as Internet protocols go, but I don't think the leap
from "elderly" to "mature" is obviously justified.

    john

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Feb 2012 12:14:28 -0500

cc:s trimmed.  I'm not on the w3c list anyway, and I don't think the
IESG cares about this detail.

> I for example do completely disagree on it being hard. Sure, your user interface in the gui of your favorite $EDITOR might not support the new RRTYPE, but should that constrain deployment of good s…

Before those who think DNS weenies never listen to real-world problems
jump in, I want to point out what _I_ understand to be a problem.  If
you're a DNS geek, then the natural thing to think is, "This is easy.
You just send a well-crafted UDP packet.  How hard could that be?
Once the typecode is assigned, what's the problem with sending an
unknown RR?"

If you're most application programmers, however, the entire conversation
ended at "send a well-crafted UDP packet".  Your libraries don't
support injecting well-crafted UDP packets, and you have no idea how
to do that, and it's incredibly stupid, and why would anyone think
that was reasonable anyway?

If you're most sysadmins, the entire conversation ended at "My tools
don't know what TYPE1234 is."  

If we seriously think that DNS RRTYPEs ought to be useful extensions
to people, we're going to have to make them _easy_ to deploy, not just
possible.  I have no idea how to solve this problem, though.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 24 Feb 2012 12:47:10 -0500

On Friday, February 24, 2012 12:14:28 PM Andrew Sullivan wrote:
> > I for example do completely disagree on it being hard. Sure, your user
> > interface in the gui of your favorite $EDITOR might not support the new
> > RRTYPE, but should that constrain deployment of good standards?

It's occured to me that it might be useful to pre-allocate some new types 
without a current use assigned (e.g. TXT1, TXT2, TXT3) so that there's time 
for them to be integrated into tools before they are needed.  Of course not 
everyone will implement an unused, but allocated type, but it might be enough 
to make a worthwhile difference in this problem.

The biggest issue with new type deployment is that for a new protocol to get 
deployment it needs the new type assigned.  For a new type to get assigned, 
there needs to be some indication it will get deployed.  So there is often a 
work around using existing types, but then once the new protocol is deployed 
with the workaround old type there's no incentive to migrate.  The only way to 
break this cycle is to have something readily available for initial use with 
protocol experimentation.

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Feb 2012 12:57:49 -0500

On Fri, Feb 24, 2012 at 12:47:10PM -0500, Scott Kitterman wrote:

> It's occured to me that it might be useful to pre-allocate some new
> types without a current use assigned (e.g. TXT1, TXT2, TXT3) so that
> there's time for them to be integrated into tools before they are
> needed.

How could you integrate a pre-allocated type when you don't know what
its format is?  If you knew how to do that, you could just deal with
unknown RRTPYEs, and then having TYPE99 wouldn't be a problem anyway.

> protocol to get deployment it needs the new type assigned.  For a
> new type to get assigned, there needs to be some indication it will
> get deployed. 

Absolutely false.  RRTYPE assignment is by expert review, and the last
reviews, while late and a little careless about process, were not in
any way held up by the possibility (or lack thereof) of use.  Nobody
is reluctant to assign RRTPYEs.  We have lots of numbers.  There may
have been problems with this in the past, but not at least since I've
been DNSEXT WG co-chair, which is several years now.

> type there's no incentive to migrate.  The only way to break this
> cycle is to have something readily available for initial use with

There's lots of room for that, too.  The range 65280-65534 is for
private use.  You can do whatever you like there.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 24 Feb 2012 13:06:38 -0500

> unknown RRTPYEs, and then having TYPE99 wouldn't be a problem anyway.

If there had been a TXT1 ... N in 2004, SPF (to put an example) could have 
picked TXT1 (assuming it wasn't used by something else).  Then later the label 
could have been changed to SPF once usage was established and standardized.

Then a few years later, DomainKeys could have used TXT2 (or whatever) for it's 
key records.  As it was, a new rr type wasn't (AFAICT) given serious 
consideration.

I'd give them all a format of text and if a protocol needs something more 
specific than that it can interpret it at the application level.

> been DNSEXT WG co-chair, which is several years now.

OK.  My one experience with this was the assignment of Type 99 as Type SPF.  
It wasn't done until very shortly before RFC 4408 was published (and by then 
it was far too late).  If it's different now, then my idea my well be obsolete.

> private use.  You can do whatever you like there.

Yes, but that still assumes a transition to a new rr type when the protocol 
matures.  The one experience that we have with trying to do this (that I know 
of) doesn't inspire confidence that this is a reasonable expectation.

Scott K

---

From: Edward Lewis <[email-masked]>
Date: Fri, 24 Feb 2012 13:18:24 -0500

>key records.  As it was, a new rr type wasn't (AFAICT) given serious

What is described here is a problem with registering the types rather 
than getting the DNS protocol to handle the new types.  Perhaps we 
need the registry of types to have rudimentary parsing rules for the 
type (a "flying car" dream).

The barrier to reserving a number was, at one time, undefined.  Then 
it was defined.  (I can't say it's ever been lowered, but in a sense, 
merely defining it lowers it.)  Perhaps the barrier is still too high.

The fear is that if numbers are assigned too easily they will be 
toyed with and discarded and someday we will run out.  The fear is 
that we cannot reclaim the numbers.  If we can over come the latter 
fear, the first should also disappear.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!

---

From: Hector <[email-masked]>
Date: Fri, 24 Feb 2012 16:49:51 -0500

+1

As an implementator of all these new mouse trap protocols with TXT 
based solutions, some borrowing the same namespace, some using 
different namespaces, it doesn't escape me to continue getting the 
utopian idea (ignoring the technical issues) that it will be "sweet" 
if they all can be collected under one single DNS call.

Edward Lewis wrote:
> than getting the DNS protocol to handle the new types.  Perhaps we need 
> the registry of types to have rudimentary parsing rules for the type (a 
> "flying car" dream).
> 
> The barrier to reserving a number was, at one time, undefined.  Then it 
> was defined.  (I can't say it's ever been lowered, but in a sense, 
> The fear is that if numbers are assigned too easily they will be toyed 
> with and discarded and someday we will run out.  The fear is that we 
> cannot reclaim the numbers.  If we can over come the latter fear, the 
> first should also disappear.
>

---

From: Yoav Nir <[email-masked]>
Date: Sat, 25 Feb 2012 00:16:09 +0200

>> per the above (or whatever text goes into the charter)

<snip/>

> There will be overlap in wg membership, but not nearly as much as would be needed for your proposal.

I like the idea, but there is always the danger of the HAM working group either getting stuck with multiple non-interoperable proposals like we've seen at IPsecME with the PAKE work.

There is also the possibility of getting stuck with conflicting requirements. For example, there will be a need to use existing user databases (RADIUS/DIAMETER servers, LDAP directories), but that is hard to reconcile with the preference for ZKPs.

I'm not really worried, because HTTP/2.0 is bound to take a long time, and there will be plenty of opportunity for chair and ADs to step in and intervene if the wg actually does that.

On a more technical note, we are 12 days past the cutoff date for new BoF session requests, so it's probably too late for a BoF in Paris. 

Yoav

---

From: Mark Andrews <[email-masked]>
Date: Sat, 25 Feb 2012 09:56:03 +1100

> possible.  I have no idea how to solve this problem, though.

It's a simple library call in Windows to get SRV records returned.  What
windows doesn't have is the ability to lookup new types but SRV has been
supported for over a decade now.

	DNS_STATUS WINAPI DnsQuery(
	  __in         PCTSTR lpstrName,
	  __in         WORD wType,
	  __in         DWORD Options,
	  __inout_opt  PVOID pExtra,
	  __out_opt    PDNS_RECORD *ppQueryResultsSet,
	  __out_opt    PVOID *pReserved
	);

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682016(v=vs.85).aspx

Posix: though you do have to parse the result.
int
res_query(const char *dname, int class, int type, u_char *answer, int anslen);

There are libraries that will extact the records and return them
as a list of length data blobs.  You just need to parse the individual
records.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 25 Feb 2012 13:05:00 +1100

Hi Stephen,

> - httpbis pick what they want, (zero or more) and go

Is the goal for HTTPbis "one or more" or "zero or more"? I see both above.

Again - I'm absolutely fine with soliciting proposals, but requiring output is a different thing.

Thanks,

---

From: Doug Barton <[email-masked]>
Date: Fri, 24 Feb 2012 19:57:22 -0800

> think that the arguments in favour of SRV are going to find more

Because I emphasized the point that SRV has been around for 12 years? I
have enough experience to know how difficult it is to deploy new RRs.
SRV is not new.

Doug

--

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 25 Feb 2012 13:46:20 +0000

Hiya,

> Again - I'm absolutely fine with soliciting proposals, but requiring output is a different thing.

Yeah that's a tricky one. While one might like to
see "one or more" in both places that might not be
practical.

In the proposal above the goal is that httpbis pick one
or more but recognising the reality that we might not get
a new proposal that httpbis will accept and that folks
will really implement and deploy.

So:
    Goal = one or more
    Reluctant recognition of reality = zero or more

With this plan if httpbis in fact select zero new proposals
that would represent a failure for all concerned. The "zero
or more" term is absolutely not intended to provide a way to
just punt on the question.

Such a failure at the point where httpbis was re-chartering
to work on a HTTP/2.0 selection with no better security than
we now have is probably better evaluated as a whole - I
guess the question for the IETF/IESG at that point would
be whether the Internet would be better with or without
such a beast, or better waiting a while until the security
thing did get fixed.

I can imagine an argument might ensue about that;-)

S

---

From: Julian Reschke <[email-masked]>
Date: Sat, 25 Feb 2012 15:03:55 +0100

> I can imagine an argument might ensue about that;-)

If we just need a new authentication scheme, nothing stops people from 
working on that right now. I don't see how that should affect HTTP/2.0.

If the "right" way to do security needs changes in the HTTP/1.1 
authentication framework, then we should fix/augment/tune HTTP/1.1. It's 
not going to go away anytime soon.

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 25 Feb 2012 14:13:27 +0000

On 02/25/2012 02:03 PM, Julian Reschke wrote:
> working on that right now.

I don't agree with you there - the perceived low probability that
something will be deployed is a real disincentive here. We have had
people wanting to do work on this and have been told there's no point
because it won't get adopted.

 > I don't see how that should affect HTTP/2.0.

Well, a number of people have noticed that current schemes
are getting long in the tooth and fixing stuff like that when
you do a major rev of a protocol is quite a reasonable thing
to do.

> not going to go away anytime soon.

Sure, I agree with that and think the plan above allows for it.

S

---

From: Julian Reschke <[email-masked]>
Date: Sat, 25 Feb 2012 15:20:36 +0100

> because it won't get adopted.

Just checking: so you think what's needed is a normative requirement to 
implement the new scheme? Do you really believe that that's what holding 
up improvements in this area?

> you do a major rev of a protocol is quite a reasonable thing

If there's something from with the framework, let's fix the framework. 
That's already covered by the current charter, no?

> Sure, I agree with that and think the plan above allows for it.

My point being: this is something we already do in httpbis. What's 
missing is concrete bug reports.

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 25 Feb 2012 17:44:34 +0000

> up improvements in this area?

The first thing is not something I said and I don't know quite what
it means so its also not something I believe. I therefore also do not
believe the 2nd thing.

> That's already covered by the current charter, no?

I don't think fixing or changing the framework will give us better
auth schemes by itself. (Better auth schemes may or may not require
changes to the framework, I dunno.)

So I think you're raising a side issue here really.

S

---

From: Julian Reschke <[email-masked]>
Date: Sat, 25 Feb 2012 19:23:24 +0100

> So I think you're raising a side issue here really.

Well, I'm one of the editors of the authentication framework spec, so if 
there's something wrong with it, I'd like to know.

So if we collectively think that the framework probably is ok, and that 
we *do* need a new authentication scheme, what's stopping us to start 
that activity *right now*?

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 25 Feb 2012 18:29:10 +0000

> that activity *right now*?

I believe I answered just that question from you earlier today.
So you must be looking for someone else's answer I guess. Or
perhaps I'm confused.

S

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 26 Feb 2012 10:25:00 +1100

> because it won't get adopted.

Let's speak plainly here.

It's not hard for new things to be deployed -- there are lots of new things being deployed on the Web right now.

What IS hard is forcing browser vendors to deploy something that they don't think is going to work, or that they're not terribly interested in.

They are VERY VERY VERY interested in security, as are many other people in the broader community. If the IETF were to come up with a viable proposal that solves their problems, they would beat down this organisation's doors.

The IETF may have some smart people, and they may have ideas about Web security, but that doesn't necessarily make them into workable solutions for the various stakeholders. The discussion about Web security is much broader, involving not only the browser vendors, but also organisations like the W3C, IIW, etc.

Using HTTP/2.0 as a mechanism to shortcut all of this and force what people in the IETF think is a good solution down implementers' throats is going to lead to a very predictable and messy fail.

> just punt on the question.

This makes me very uncomfortable. How hard and long do we have to try before we convince you that we're not punting?

> such a beast, or better waiting a while until the security

If we "wait a while until the security thing [does] get fixed", I'll gladly bet any amount of money you care to name that SPDY will gain market traction so quickly as to make any HTTP/2.0 effort in IETF completely backwards-looking. Refer to the debacle with Cookies for one such example.

So, again, I'm fine with allowing new authentication schemes to be proposed, in the off chance that some genius will suddenly propose something that meets all of the myriad requirements (that still aren't well-defined) and gets consensus and buy-in from implementers. 

However, requiring us to output such a beast and gating HTTP/2.0 on it is effectively asking us to spin our wheels for n years. And the folks working on SPDY will - quite rightly - walk away and do their work somewhere more sane.

And I still don't see why it's necessary to do this all in one effort. Julian's point was that the only technical reason to combine authentication work with re-specifying HTTP is to make the new authentication scheme MTI. Otherwise, the work can be done separately. Roy has expressed interest in coming up with a new scheme that isn't necessarily targeted at browsers -- which is great, but I don't see why it has to be part of this WG.

We potentially have a LOT of work on our plate, and that work is channeling the energy behind a new serialisation of HTTP into something worthy of being called HTTP. Doing research and development on Web security is a very different kind of work, and the two don't mix well, IME.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 26 Feb 2012 00:40:13 +0000

Mark,

I was going to respond blow-by-blow but there's not much
point in that, other than to say that your mail seems to
me a tad over the top.

(Maybe you misinterpreted me describing what might happen
as some kind of threat to try slow people down or something,
I don't know. I do know that I don't do that kind of thing
and if I tried I probably wouldn't be very good at it anyway;-)

Anyway, I think we should focus on a way forward that attempts
progress on what we appear to agree is the desirable outcome:

 > They are VERY VERY VERY interested in security, as are many other
 > people in the broader community. If the IETF were to come up with a
 > viable proposal that solves their problems, they would beat down this
 > organisation's doors.

I proposed a plan that I think might allow us to make progress
on that. I believe we could.

S

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 26 Feb 2012 11:44:29 +1100

> point in that, other than to say that your mail seems to

Sorry if you think so. I'm VERY sensitive to the risks that we're undertaking here, and I want to be crystal-clear about what we're going to do. As I saw it, your path forward was a risky one.

> and if I tried I probably wouldn't be very good at it anyway;-)

It may not have been your intent; my concern was that the effect would be the same.

> on that. I believe we could.

OK, great. 

Could you please explain why you think tying this effort to HTTP/2.0 is necessary to achieve that? To me that's the critical bit, and I still haven't seen the reasoning (perhaps I missed it).

Thanks,

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 26 Feb 2012 01:32:11 +0000

On 02/26/2012 12:44 AM, Mark Nottingham wrote:
> Sorry if you think so. I'm VERY sensitive to the risks that we're undertaking here,

Fair 'nuff. I consider my self fairly insensitive generally
which of course means I don't care what others think about
that:-)

 > and I want to be crystal-clear about what we're going to do.
 > As I saw it, your path forward was a risky one.

I don't get that. I'd be interested in why it appears that way
to you and if there are ways to reduce risk but still try
make progress on security stuff.

> It may not have been your intent; my concern was that the effect would be the same.

Don't get that either. I think I just pointed out the obvious
based on the proposed charter - at the point of the next proposed
re-charter, there'll be IETF/IESG review.

> Could you please explain why you think tying this effort to HTTP/2.0 is necessary to achieve that? To me that's the critical bit, and I still haven't seen the reasoning (perhaps I missed it).

That's a fair question that doesn't have a good and quick
answer, and some of the argument applies to the httpbis wg
and not to HTTP/2.0 per se.

Caveats: this is probably something that needs more bandwidth
than mail; most of the points below were already raised by
others on this thread (though I didn't go back through all
the mail yet) and this is not in any particular ordering.

- We've not really improved this in over a decade. Its time.
- The community's appreciation of better security has
   changed in that time as well so maybe its more tractable
   now and we've more experience of real attacks.
- Improving security after the fact is not a good plan.
- Thinking a separate security WG could provide an answer
   that'd be adopted seems less likely to work to some. (It
   does seem more likely to work for some others admittedly.)
- A backwards-incompatible change (if needed) could be
   done much more easily when changing HTTP. Its at least
   time to explore the area with that possibility in mind..
- A scheme less susceptible to phishing that got deployed
   could be very valuable. Its not ridiculous to think that
   might require breaking backwards compatibility somehow.

So, a bunch of things. Maybe none individually compelling.
But arguably taken together sufficiently convincing that
not attempting again to do something here would really be
inexcusable.

And yes, I do recognise that attempting to solve this does
add some risk. Most good things do.

S.

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 26 Feb 2012 12:54:02 +1100

> and not to HTTP/2.0 per se.

Aha. If we can decouple the auth work from the HTTP/2.0 deliverable, I'm less concerned -- although we're going to be quite busy. 

For *this* re-charter, can we only solicit proposals for auth, and make the decision about what/if we'll go ahead in the *next* re-charter? 

I.e., I'd like to wait before we decide on both pieces (the wire protocol and auth) before making commitments, or even plans. Part of the selection process for the wire protocol is determining implementer interest, and gathering the same information about the auth proposals will shed a lot more light on this conversation, I think.

> the mail yet) and this is not in any particular ordering.

That's OK - we'll be in Paris soon.

> - We've not really improved this in over a decade. Its time.

Don't disagree.

> - Improving security after the fact is not a good plan.

Of course.

>  does seem more likely to work for some others admittedly.)

Yes, there are arguments on both sides.

>  time to explore the area with that possibility in mind..

Hmm. One of the core ideas we're moving forward with is that 2.0 is semantically compatible with 1.x, even if it isn't syntactically. 

>  might require breaking backwards compatibility somehow.

Agreed, but I think that's much more about the browser UI than about the wire protocol.

> add some risk. Most good things do.

Absolutely.

Cheers,

---

From: Yoav Nir <[email-masked]>
Date: Sun, 26 Feb 2012 11:44:22 +0200

> Could you please explain why you think tying this effort to HTTP/2.0 is necessary to achieve that? To me that's the critical bit, and I still haven't seen the reasoning (perhaps I missed it).

I think I have *an* answer to this, though probably not *the* answer.

There's two stages to adoption - implementation and roll-out. Obviously you can't roll out "new authentication" before the browsers and servers implement it. For my website, I wouldn't roll out new auth if only one or two of the browsers out there implemented it. Even if all the big ones (IE, Firefox, Chrome, Opera) did, I would still have to provide a backwards compatibility authentication scheme to support older browsers. This would lead to both inconsistent UI and to ugly javascript that detects the browser version, and makes the roll-out slower.

If any HTTP/2.0 browser is bound to have "new authentication" it makes things much easier.

This could be circumvented by adding request headers that advertise capabilities, but I don't think we like those much.

Yoav

---

From: Julian Reschke <[email-masked]>
Date: Sun, 26 Feb 2012 15:54:10 +0100

> There's two stages to adoption - implementation and roll-out. Obviously you can't roll out "new authentication" before the browsers and servers implement it. For my website, I wouldn't roll out new…

You can send multiple challenges in one response.

We could also define a way to make HTML-form-based login an HTTP scheme 
(see <http://tools.ietf.org/id/draft-broyer-http-cookie-auth-00.txt>) to 
integrate better what people use today.

> This could be circumvented by adding request headers that advertise capabilities, but I don't think we like those much.

I don't believe we need those. If we do, we should retrofit this into 
1.1 as well.

Anyway, I see lots of theoretical discussion about process. What's 
needed is people doing the actual work, both spec-wise and 
implementation-wise. That's the critical problem.

Best regards, Julian

---

From: TEVFİK ŞAHİN <[email-masked]>
Date: Sun, 26 Feb 2012 15:04:38 +0000

Zc
-----Original Message-----
From: Yoav Nir
Sent:  26.02.2012, 11:45
To: Mark Nottingham
Cc: The IESG; [email-masked] Group; IETF-Discussion Discussion
Subject: Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Yoav

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

“This Message (including any attachments) contains confidential information and is intended only for the individual named. If you are not the named adressee or not related with the content of this Message, you are forbidden to read, disseminate, distribute, copy, reproduce or modify this mail by our Company. Please notfy the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmisson can not be guaranteed to be secure or error-free as the mail may arrive late or incomplete or the information could be intercepted, corrupted, lost, destroyed, amended, , or contain viruses. The sender therefore does not accept liability for any errors, loss of integrity or confidentiality or ommissions in the contents of this Message or for the information transmission, reception, storage of use of such in any way whatsoever, which arise as a result of e-mail transmission. Any opinions expressed in this message are those of the author and may not necessarily reflect the opinions of Our Company.

Copyright in documents created by or on behalf of our Company remains vested in us, and we assert all of our moral and intellectual property rights.”

“Bu mesaj (ve ekleri) gizli bilgi içermektedir ve sadece gönderilen kişiye yöneliktir. Bu e-mailin muhatabı değilseniz veya içeriği ile ilginiz yoksa, Şirketimizin onayı olmaksızın bu mesajın okunması, değiştirilmesi, kopyalanması, üçüncü kişilere açıklanması, yayınlanması, ifşa edilmesi veya iletilmesi yasaktır. Bu mesajın gönderilmek istendiği kişi değilseniz (ya da bu e-posta'yı yanlışlıkla aldıysanız), lütfen yollayan kişiyi hemen haberdar ediniz ve mesajı sisteminizden derhal siliniz. E-mail iletiminin güvenli veya hatasız olduğunun garantisi olmadığından geç veya eksik iletim veya içerik ve bilgilerde eksiklik, kayıp, değişiklik veya virüs olabilir. Bu nedenle, bu mesajın iletiminden dolayı, gönderen, içerikteki hata, eksiklik, doğruluğun ve gizliliğin ihlalinden veya bu yolla bilgi paylaşımı, iletimi, depolanması gibi herhangi bir kullanımından hiçbir şekilde sorumlu değildir. Bu mesajın içeriği yazarına ait olup, Şirketimizin görüşlerini içermeyebilir.

Bu mesajın içeriğinde geçen Şirketimizin ad veya nanıma yaratılan fikri ve sınai haklar Şirketimize ait olup, maddi ve manevi tüm hakları Şirketimizde saklıdır.”

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 26 Feb 2012 21:49:30 +0000

> I.e., I'd like to wait before we decide on both pieces (the wire protocol and auth) before making commitments, or even plans. Part of the selection process for the wire protocol is determining impl…

Right, that's pretty close to what I proposed.

Let's see if we hear supportive noises or howls of outrage or silence.

I think I'd suggest to keep the idea of chartering a sec wg to pick up
the pieces that httpbis doesn't want to progress, once that situation 
becomes clear. All going well, that'd result in some experimental RFCs
that could be picked up with little effort should events warrant. But
that doesn't directly impact on httpbis I guess.

S.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 27 Feb 2012 11:44:04 +0100

> specific than that it can interpret it at the application level.

Publishing RRs requires proper formatting, though.  In most cases,
tools could work equally well without knowing whether a type is
registered or not.  They could rely upon symbolic specifications, see
http://datatracker.ietf.org/doc/draft-levine-dnsextlang/ , leaving it
to sysadmins to install official specs.

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 24 Feb 2012 17:57:31 +0100

On 24 feb 2012, at 17:43, John C Klensin <[email-masked]> wrote:

> It is
> newer RRTYPES.

As I said, people disagree... ;-)

As far as I know, there is nothing in any of the operating systems you mention that prohibits an application to send a random udp packet, and because of that your application can include a resolver library.

What is a problem are the cases where DNS is not used at all at the end node, but instead other name binding/lookup protocols combined with a firewall policy that because of this can and is blocking udp+tcp/53 in various ways.

That said, I still ask when it is, in general, time to just move forward. I see for example many other reasons why people should not use that old software. IE6 for example. Yes, economically constrained situations exists, but that problem do not go away by having us not start using SRV or HTTP/1.1 or SNI or HTML5.0 or...pick your favourite. And with SPF, that is not used by the edge node either.

I am asking more generally why specifically this DNS issue is so stuck, because I think that is unfair. We upgrade other protocols...

But my point is, people disagree. As we see here ;-)

   Patrik

---

From: Adrien de Croy <[email-masked]>
Date: Sun, 26 Feb 2012 14:54:01 +1300

I wonder if it would be helpful for people to outline what they expect 
are the issues to be solved by doing more work on an HTTP auth mechanism.

I get the feeling that some think the scope would encompass providing 
auth support for web applications, whereas others are mainly concerned 
with the transport level auth.

IMO http auth is not particularly suited to solve the issues required 
for web site authors, for the simple issue of administrative boundaries 
and realms of accounts.

For example the web server that sits on an OS that has 1 user database, 
yet hosts 10 web sites each of which require their own independent user 
database, and require the ability to create and destroy accounts, and 
these accounts NOT be OS ones (i.e. not grant any access to the OS).  
Sure these issues could be engineered around, but it would add to the 
current scope (for change) every web application that currently manages 
accounts (a great deal of them).

If we're just talking about transport auth, then what's wrong with 
something like kerberos.  As for server logging a client out, the auth 
mechanism would need a token that can be revoked by the server, since 
one cannot rely on client co-operation in such a matter.  A kerberos 
ticket seems to fit this bill.  then we'd just need a mechanism for a 
client to request revokation (logout).  It is also AFAIK supported on 
all server platforms, unlike any auth mechanism that requires access to 
plaintext passwords at the server end - these are not always available.

Adrien

On 26/02/2012 3:03 a.m., Julian Reschke wrote:
> authentication framework, then we should fix/augment/tune HTTP/1.1. 
> It's not going to go away anytime soon.
>
> Best regards, Julian
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 26 Feb 2012 07:28:18 +0100

Hi Adrien,

> with the transport level auth.

I am personally concerned with the risk that new auth schemes continue
to mix messages and transport. I don't think we need to define these new
schemes, we just need to ensure the new protocol offers provision for
doing the things right. I'd like to ensure we never get a new NTLM-like
design error which forces every implementation to break the HTTP model
to try to be compatible.

Also, (that's not directly related to auth) it would be nice if we could
have a random session ID in messages that browsers would send to help the
whole intermediary chain select the appropriate server. A simple hash on
this session ID would make load balancing much easier and much more reliable
than any other algorithm right now and would definitely help when challenge
based auth schemes are needed.

(...)
> plaintext passwords at the server end - these are not always available.

It is comparable to what is already done with cookies in most applications
(ie I have nothing against this). We just have to keep in mind that auth
methods will change with time. Many applications right now expect two-factor
auth and/or some complex UI adaptations to protect against malware. That's
why I think that our work on supporting auth should mainly ensure we offer
the solid blocks for building new auth schemes and don't necessarily need
to define these schemes ourselves.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 26 Feb 2012 07:40:25 +0100

On Fri, Feb 24, 2012 at 05:57:31PM +0100, Patrik Fältström wrote:
> I am asking more generally why specifically this DNS issue is so stuck,
> because I think that is unfair. We upgrade other protocols...

Because in HTTP, anybody can be anywhere. You can have client-side proxies,
server-side gateways, load balancers, etc... everyone in this chain may or
may not resolve, it's only a matter of configuration and architecture choice.
There are plenty of places where clients won't access public resolvers at all
and rely on their proxies for this. So you can't make use of DNS to improve
these users' experience.

Also, DNS is SLLLLOOOOWWWWW. It's fast enough to send a mail. But for HTTP
it adds too much latency. Some people in the mobile world would like to be
able to configure an explicit proxy on their smartphones in order to avoid
a very expensive round trip before fetching an object : at 20 host names
on a web page, 300 ms round trip means 6 seconds are lost to resolve these
objects if they can't be totally parallelized.

DNS suggestion is something going back and forth regularly. I think that
people who try to push it hard only see the very simple case where users
have a direct low-latency internet connection. The reality is much much
different. This well reflected by the fact that in the end, after many
proposals, it has still not been adopted !

Regards,
Willy

---

From: Hector <[email-masked]>
Date: Mon, 27 Feb 2012 12:33:17 -0500

> to sysadmins to install official specs.

I am extremely interested to know how RFC3597 "Handling of Unknown DNS 
Resource Record (RR) Types" is viewed today as a still ongoing 
prevalent issues.

Back around that time from (up to around 2007/2008), I would never 
even bother with any protocol consideration using new RR types or more 
specifically, allows the publishing with a high confidence the 
passthru recursive necessary would be feasibly successful.

I would like to poise this general question to the IETF/DNS community:

     Given higher modern DNS server support for unnamed types, should
     new protocols continues to pursue new RR types or does the
     DNS Community believe this original infrastructure ideal is no longer
     necessary and new protocols can use TXT records with a high
     degree of DNS support confidence for robustness.

Many new protocols use the TXT records simply as a fast entry, high 
support mechanism to store data on DNS.  Is the mindset today such 
that this is still desirable, is there an DNS impact with this on 
going direction?

Consider the point of view of a developer exploring a new protocol, 
should he focus on using TXT only and now sweat any IETF/DNS community 
endorsement or should he/she also include a considering for a new RR 
type in the design?

Thanks

---
Hector Santos/CTO
Santronics Software, Inc.

---

From: John C Klensin <[email-masked]>
Date: Mon, 27 Feb 2012 14:41:15 -0500

> As far as I know, there is nothing in any of the operating
> systems you mention that prohibits an application to send a
> random udp packet, and because of that your application can
> include a resolver library.
> 
> What is a problem are the cases where DNS is not used at all
> at the end node, but instead other name binding/lookup
> protocols combined with a firewall policy that because of this
> can and is blocking udp+tcp/53 in various ways.

I'd suggest that there are two other problems.  One is that
per-application resolver setups pretty much prevent caching of
any flavor (possibly not an issue if one opens applications,
keeps them open for a long time, and uses different target sites
with different applications, but, if that scenario has been
studied wrt frequency, I'm not aware of it).  The other, more
important, issue is that it just about guarantees an
inconsistent user experience wrt the treatment of names.  

Of course those are tradeoffs against locally-improved
functionality and reasonable people can disagree about how
important those issues are wrt the other considerations.

> That said, I still ask when it is, in general, time to just
> move forward. I see for example many other reasons why people
> should not use that old software. IE6 for example. Yes,
> economically constrained situations exists, but that problem
> do not go away by having us not start using SRV or HTTP/1.1 or
> SNI or HTML5.0 or...pick your favourite. And with SPF, that is
> not used by the edge node either.
> 
> I am asking more generally why specifically this DNS issue is
> so stuck, because I think that is unfair. We upgrade other
> protocols...

Where I probably agree with you is that I think that we need to
evaluate costs, benefits, and risks and to do so against an
understanding and hope that we will have _many_ more Internet
users a decade from now than we do today.  Accepting the latter
may justify changes even more painful than transition to a new
RRTYPE if we understand that we are inconveniencing a relatively
small number of people today in order to make things much better
for a far larger future number.  And that is why I have never
believed in arguments for guaranteed absolute forward
compatibility in Internet, and Internet-like, situations.

> But my point is, people disagree. As we see here ;-)

Indeed.  Even though I would hope that we can at least mostly
agree about the facts even if we disagree about the tradeoffs to
which they lead.

    john

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 27 Feb 2012 20:43:04 +0100

On 27 feb 2012, at 18:33, Hector wrote:

> Many new protocols use the TXT records simply as a fast entry, high support mechanism to store data on DNS. Is the mindset today such that this is still desirable, is there an DNS impact with this on going direction?

I have not heard anything else than arguments in RFC5507 against reusing same RRType for many different kind of use.

5507 Design Choices When Expanding the DNS. IAB, P. Faltstrom, Ed., R.
     Austein, Ed., P. Koch, Ed.. April 2009. (Format: TXT=44045 bytes)
     (Status: INFORMATIONAL)

So, still, no, you should not reuse TXT. You should have your own RRType. Other choices makes your design very complex.

Yes, many people will still disagree with me, using arguments I do not agree with...

  Patrik

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Feb 2012 19:57:58 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Patrik Fältström
> Sent: Monday, February 27, 2012 11:43 AM
> To: Hector
> Cc: [email-masked]
> Subject: Re: DNS RRTYPEs, the difficulty with
> 
> I have not heard anything else than arguments in RFC5507 against
> reusing same RRType for many different kind of use.
> 
> So, still, no, you should not reuse TXT. You should have your own
> RRType. Other choices makes your design very complex.
> 

The conclusion of Section 3.5 of that document doesn't really address the first bullet in the same section, namely that the user interface by which the new RRType would get added to a zone often doesn't support doing so.  That's turned out to be a serious problem with, for example, the deployment of the SPF record (RRType 99).

To accommodate user interface limitations, the RFC that defined SPF (2006) included use of TXT as a "backup" to enable a period of transition.  Collected evidence shows that a lot of clients do query the type, but fewer than 5% of participating sites ever publish it even after six years.

In an ideal world I'd also like to see us move in the direction that RFC5507 promotes, but it seems we still aren't there yet.

-MSK

---

From: Hector <[email-masked]>
Date: Mon, 27 Feb 2012 15:19:36 -0500

Thanks Patrick.

Is there an element, or include, the "Simplicity" argument that has 
been presented to you?

Thats the feeling I am getting - Fast entry, don' sweat the DNS impact 
and today, its high OS/software, DB speeds and overall robustness is 
good enough.  Once upon a time, the idea of redundancy (calls) was a 
concern, at least that seem to be the general mindset, but over time, 
I have seen statements that we shouldn't worry about it - just do it! 
  Better caching resolves much of the redundancy related overhead 
concerns.

PS: I agree with your position.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 27 Feb 2012 21:30:37 +0100

On 27 feb 2012, at 21:19, Hector wrote:

> Thanks Patrick.
> 
> Is there an element, or include, the "Simplicity" argument that has been presented to you?
> 
> Thats the feeling I am getting - Fast entry, don' sweat the DNS impact and today, its high OS/software, DB speeds and overall robustness is good enough.  Once upon a time, the idea of redundancy (calls) was a concern, at least that seem to be the general mindset, but over time, I have seen statements that we shouldn't worry about it - just do it!  Better caching resolves much of the redundancy related overhead concerns.
> 

The arguments I hear are I think very unfortunate, but I of course understand them. They include for example:

- GUI (as in actual web interface or such) does not support the RRType

Example: Many DNS hosting providers do not allow even NAPTR or SRV RRTypes today. Even fewer URI or SPF.

- Code in for example bind and other name server software do not support the new RRType

Example: Even if one use Emacs, VI or whatever else txt tool one have to add the RR using hex which for complicated RRTypes might be very hard to calculate.

- The protocol used in clients is not DNS

Example: The actual lookup can only be of data that is proxied to various RRTypes that are "known"

- Local software do not handle new RRTypes

Example: Programmer want to use some resolver library that only support a subset of RRTypes that exists, and to use other RRTypes one must use "unknown" RRType or be able to at least enumerate exactly the #id of the RRType itself, and then parse the raw data that comes back.

- Firewall software do not handle new RRTypes

Example: Deep packet inspection of DNS flow(s) do only allow certain DNS RRTypes to pass through

...and more...

I do though think limiting us to certain types will have impact not only for effective use of HTTP and other protocols (I think we need SRV, URI etc), but also have impact on for example deployment of DNSSEC.

The first (successful) step was to ensure DNS core software do understand "unknown RRTypes" which I claim is now deployed "in the core". Edge is still questionable (see above).

I do not want to give up proper deployment though. I just do not do that.

Some people with very old software that can not be updated will loose. They will not get the new features new RRTypes can give.

Yes, a pain. But...we just must be able to get new RRTypes deployed. And not give up.

   Patrik

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 27 Feb 2012 12:32:11 -0800

> The conclusion of Section 3.5 of that document doesn't really address the first bullet in the same section, namely that the user interface by which the new RRType would get added to a zone often do…

Which user interfaces are people using to add RRtype 99? If you are having them edit zone files by hand well, yes, that would not work real well for SPF. If there is a simple tool that takes the needed information and create a standard-formatted record that can be copy-and-pasted, it would make use of that RRtype much easier. If no such tool exists, I propose that it can be created easily.

--Paul Hoffman

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 27 Feb 2012 15:35:11 -0500

On Monday, February 27, 2012 12:32:11 PM Paul Hoffman wrote:
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Patrik Fältström Sent: Monday, February 27, 2012 11:43 AM
> >> To: Hector
> >> Cc: [email-masked]
> > The conclusion of Section 3.5 of that document doesn't really address
> > the first bullet in the same section, namely that the user interface by
> > which the new RRType would get added to a zone often doesn't support
> > doing so.  That's turned out to be a serious problem with, for example,
> > the deployment of the SPF record (RRType 99).
> Which user interfaces are people using to add RRtype 99? If you are having
> them edit zone files by hand well, yes, that would not work real well for
> SPF. If there is a simple tool that takes the needed information and create
> a standard-formatted record that can be copy-and-pasted, it would make use
> of that RRtype much easier. If no such tool exists, I propose that it can
> be created easily.

We've published a script to take a Type TXT SPF record and give a Type SPF 
output as part of the pyspf library since very shortly after Type SPF was 
assigned.  It's been around for years, so the lack of that type of tool isn't 
an issue.

Scott K

---

From: Hector <[email-masked]>
Date: Mon, 27 Feb 2012 16:03:44 -0500

Patrick, I agree 100% with your well stated, outlined functional and 
technical position, which is why I want to get a feel for what is the 
current mindset which seems to be one of simplicity and not one that 
no longer relates or less concern with the original ideals of using 
specific RR types optimizes DNS large scale application usage.  Yes, I 
don't think we should give up.

The specific case is with SPF and it 2006 fast track WG consensus to 
include a registration for a new type 99 SPF type. It help appease 
many of the DNS concerns and perhaps would help with the IETF politics 
(endorsement).  That is how I saw it.

Yet, giving the practically realities, our own implementation disabled 
the SPF type lookup, and like many I believe think, it would be a 
useless wasted call.

Now a new BIS effort has started and to my surprise the original 
environment migration path of first getting clients to support types, 
the data evidence have shown that original intent right on, a short 
term hiccups and expectation for the necessity of getting DNS servers 
to be updated and a long term expectation that the new RR type would 
be eventually be dominate and successful.  In the mean time, some 
initial overhead would be expected.

But what has happen is that its now a "Who's Who" using it criteria as 
a measuring stick to abandon the new type.  I am sure there will be 
those who say that is not the criteria and thats find, I understand it.

It is excludes what the original ideal and intention was and all 
evidence is showing that the migration path expected is on par and 
right on, - get the clients to support both before a new BIS 
specification can safely recommend a pure single RR type to be 
published rather than both    type 99 and TXT.

So I believe revisiting the original ideal goal will help in these 
decisions regarding the exploration of using new RR types - not a 
"who's who" highly subjective criteria that has nothing to do with 
with the fundamental ideal of improving DNS operations.

I'm not getting any traction using this fundamental consideration and 
its odd to me, to be frank.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 28 Feb 2012 08:48:21 +1100

In message <3503462.Q2aCvq3QGU@scott-latitude-e6320>, Scott Kitterman writes:
> > >> Of Patrik F=E4ltstr=F6m Sent: Monday, February 27, 2012 11:43 AM
> > >> To: Hector
> > >> Cc: [email-masked]
> > >> =
> > >> =
> > >> =
> > >>     Austein, Ed., P. Koch, Ed.. April 2009. (Format: TXT=3D44045
> > >>     bytes)
> > >>     (Status: INFORMATIONAL)
> > >> =
> 
> > >> =
> > > =
> > SPF. If there is a simple tool that takes the needed information and crea=
> te
> We've published a script to take a Type TXT SPF record and give a Type SPF =
> 
> output as part of the pyspf library since very shortly after Type SPF was =
> 
> assigned.  It's been around for years, so the lack of that type of tool isn=
> 't =
> 
> an issue.
> 
> Scott K

My user interface is "vi".

RFC 4408 April 2006

revision 1.1
date: 2005-07-14 16:46:44 +1000;  author: marka;  state: Exp;
branches:  1.1.2;
1892.   [func]          Support for SPF rdata type. [RT #15033]

It was first available in BIND 9.4.0 (Feb 2007) earlier still if
you were willing to run alpha/beta/rc.

OS vendors could have supplied it earlier.

cp lib/dns/rdata/generic/txt_16.c lib/dns/rdata/generic/spf_19.c
cp lib/dns/rdata/generic/txt_16.h lib/dns/rdata/generic/spf_19.h

s/TXT/SPF/
s/txt/spf/
s/16/99/

make clean
make

You don't even have to touch a Makefile.   After that all the tools
that come with BIND support SPF.

If I remember correctly someone did something like that and made it
available.  Its definitely been done for a number of new types.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Tue, 28 Feb 2012 08:57:45 +1100

Additionally, java and python both support unknown types.  Adding
new types in both of these appears to be straight forward.  C has
always suppported unkown types.  If your favourite language / OS
doesn't support unknown types complain to the developer / vendor.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Feb 2012 22:16:33 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Andrews
> Sent: Monday, February 27, 2012 1:48 PM
> To: Scott Kitterman
> Cc: [email-masked]

Mine too.

> It was first available in BIND 9.4.0 (Feb 2007) earlier still if you
> were willing to run alpha/beta/rc.
> 

The question is not whether the nameservers themselves support it (we know these days that they do), but rather the user interfaces that many people have to use to create records.  For example, several web-based "domain control panel" things for virtual web site hosting know how to add the common types, but not others.  This has even challenged deployment of DKIM, which doesn't have its own RRType and re-uses TXT, because it's strange for some people to post a big base64 blob into a web form for which the label is "hostname/address" or some such.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 27 Feb 2012 17:17:56 -0500

On Tuesday, February 28, 2012 08:48:21 AM Mark Andrews wrote:
...
> My user interface is "vi".
...
This puts you firmly in the group of technical people who will have no problem 
deploying new RR types.  Most domain owners don't fall into that group and the 
user interfaces they use still don't support Type SPF even after more than 
half a decade.

Scott K

P.S.  That's my user interface too.

---

From: Doug Barton <[email-masked]>
Date: Mon, 27 Feb 2012 14:26:57 -0800

> In an ideal world I'd also like to see us move in the direction that RFC5507 promotes, but it seems we still aren't there yet.

It's important to understand the history here. The problem of "old
software chokes on new RR types" was a known issue way back when, and
3597 came out in Sept. 2003 to help address it. When 4408 came out
defining SPF in April of 2006 support for 3597 was still being rolled
out, and was nowhere near the point where it could be safely assumed in
even a meaningful minority of the deployed base.

The error for SPF came with the TXT bootstrap version. It's easy to see
now (whether it was easy to see then or not is water under the bridge at
this point) that this was a mistake. As painful as it would have been
back in 2006 to wait for support for 3597 and/or the SPF RRtype to
propagate, we would be in a much better situation *now* if we had waited.

So, what we need to do is learn from that experience. 8.5 years later
support for 3597 is a very reasonable thing to expect, and with AAAA,
DNSSEC, etc. we're well past the era where hidebound DNS software is an
acceptable operational model.

Do I believe that insisting on new RRtypes will be a pain-free
experience? Of course not. But if we don't insist on it at this point,
every day we delay it becomes more and more painful, not less.

To circle back to my suggestion that SRV be an integral part of any new
HTTP effort, it's 12 years old, so predates both of the above. :)

Doug

--

---

From: Hector <[email-masked]>
Date: Mon, 27 Feb 2012 17:34:52 -0500

> The question is not whether the nameservers themselves support it (we know these days that they do), but rather the user interfaces that many people have to use to create records.  For example, sev…

These are valid widest total infrastructure support goals, but I don't 
believe its (and I believe RC5507 and Patrick is stating) are valid 
arguments against the usage and promotion of using RR types.  Well 
understood, but not an excuse to abandon the ideal because in my 
personal view a "Simplicity" factor has emerged with many ISPs 
offering WEB-based DNS management frontends. I don' think that means 
it wasn't possible for them to support new RR type record input - some 
simply took the path to least support resistance.

Any-hoo, that is why i poise the question in regards to what are the 
new "ideals."

Just consider, Murray, it isn't a big deal in 2006 for SPF/MARID 
efforts, then it would had never came up as a suggestion as a IETF/DNS 
community endorsement appeasing idea to help mode the I-D for what 
become RFC 4408.  After all, SPF already had a long list of IETF key 
cogs who were militantly against it - and some who are still are now 
deciding its BIS future.

The essence I am getting from limited WG participant leading these 
efforts, is that it doesn't matter any more, don't bother to even 
consider it any more. Its a waste of time.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 28 Feb 2012 09:48:03 +1100

In message <[email-masked]>, Willy Tarreau writes:
> On Fri, Feb 24, 2012 at 05:57:31PM +0100, Patrik F=E4ltstr=F6m wrote:

> may not resolve, it's only a matter of configuration and architecture choic=
> e.
> There are plenty of places where clients won't access public resolvers at a=
> ll

Proxies can lookup SRV records.  They already lookup A and AAAA records.
 
> objects if they can't be totally parallelized.

If they can't be parallelized then you can blame the page developer.

As for SRV you can always do SRV + AAAA + A in parallel.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 28 Feb 2012 10:04:56 +1100

Many web interfaces are little more than line text editors with a pulldown
list for the type.  Very few are more than that.  The data just gets passed,
as text, to a backend which adds it to a database / zone.  Lots of those
backends already support the new type.  The only change that needs to be
made is to add a type to the pull down list.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Feb 2012 23:11:18 +0000

> Sent: Monday, February 27, 2012 3:05 PM
> To: Hector
> Cc: [email-masked]
> Many web interfaces are little more than line text editors with a
> pulldown list for the type.  Very few are more than that.  The data
> just gets passed, as text, to a backend which adds it to a database /
> zone.  Lots of those backends already support the new type.  The only
> change that needs to be made is to add a type to the pull down list.

Right, and I think we're facing the fact that people just aren't doing that despite these fine RFCs we've been citing.  Now what?

-MSK

---

From: Hector <[email-masked]>
Date: Mon, 27 Feb 2012 18:25:58 -0500

> made is to add a type to the pull down list.

In one support case, gigantic isp to remain nameless, the addition of 
new TXT-based protocol support now caused "wildcard conflicts" between 
SPF and DKIM.

Customer to us: What records to I add?

Us: Use our tool-generated records and contact ISP - they should have 
a "Total DNS management" web based system, to add the generated 
records there.

They did, there was a conflict with getting DKIM records and SPF 
records, two different name spaces.

Us: Constant ISP, they should allow you to separate SPF and DKIM records.

ISP to Customer:  Nothing wrong, its all fine.  Just add it under TXT.

Customer to US:  Is this your BUG?

Us: It has to be the ISP, lets check it out - Remote support.

There was no specific way to separate TXT records, it was all lump 
under one input.

US: Contact ISP, tell them what we told you.

Customer to US:  VOILA, fixed, ISP fixed it with a special prefix you 
add to the record.

Basically, what they did was independent of the pull down, the 
editable field allowed you to add the subdomain prefix.

Whatever! :)

Agree, it isn't so far to update the frontend, but we can't always 
blame the ISP when the specification isn't all clear. If the 
impression is that TXT is good enough, then the expense to do code 
change is less justified.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 28 Feb 2012 12:04:40 +1100

> records, two different name spaces.

Which is one of the reasons DNS people argued and argued and argued
that TXT was not the right solution for DKIM.  The IETF can still
correct this by adding a DKIM type and deprecating the prefix. :-)

> Customer to US:  VOILA, fixed, ISP fixed it with a special prefix you 

No.  You just need a interface that lets you specify the domain name of
the record you are adding.

---

From: "John Levine" <[email-masked]>
Date: 28 Feb 2012 01:46:47 -0000

>In an ideal world I'd also like to see us move in the direction that
>RFC5507 promotes, but it seems we still aren't there yet.

I'm still hoping to get some more feedback on

draft-levine-dnsextlang-02.txt

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 28 Feb 2012 01:49:41 -0000

>> new TXT-based protocol support now caused "wildcard conflicts" between 

Since DKIM uses prefixed names, this is not a problem on any actual
deployment of DKIM.  

It's true, you can't do _domainkey.*.example.com, but this is a well
known limitation on prefixed names at least since they were invented
for SRV records.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 28 Feb 2012 01:56:06 -0000

>acceptable operational model.

There are indeed very few current DNS servers that can't be persuaded
to serve up arbitrary record types, but as we've been saying over and
over, that's not the problem.

The problem is provisioning software.  We weenies can stuff anything
into our DNS servers we want, because we use vi and emacs and (in my
case) custom perl scripts.  For the other 99.5% of the world, what
they can put in their DNS zones is limited to whatever the web
provisioning software at their registrar or ISP or web host supports,
and I challenge you to find any that supports SPF records.

R's,
John

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 27 Feb 2012 18:13:39 -0800

> and I challenge you to find any that supports SPF records.

Er, so? If the tool to bundle up the needed bits for SPF-as-text and SPF-as-binary are similarly trivial, why should we care if people who want to use a feature of the Internet can't persuade their provider to make a trivial change.

Soon, y'all will be saying we should give up on DNSSEC because so few registrars support it in their web UIs.

--Paul Hoffman

---

From: "John Levine" <[email-masked]>
Date: 28 Feb 2012 02:46:20 -0000

>Er, so? If the tool to bundle up the needed bits for SPF-as-text and
>SPF-as-binary are similarly trivial, why should we care if people who
>want to use a feature of the Internet can't persuade their provider to
>make a trivial change.

Because there's no point in checking records that don't exist.  RFC
4408 has been out for six years, and people who run large mail systems
report that the number of type 99 records is basically zero.  To
several significant digits, all type 99 queries are wasted traffic.

>registrars support it in their web UIs.

Registrars will because they have to. The registries (or maybe ICANN)
will beat them up.

I'm looking forward to a couple of decades of the DNS crowd
complaining that there's no DNSSEC at zone cuts below TLDs, while
remaining impervious to the concept that it's because upgrading
provisioning to handle them is even harder than upgrades for simple
records like type 99.

R's,
John

---

From: Hector <[email-masked]>
Date: Mon, 27 Feb 2012 21:58:06 -0500

> several significant digits, all type 99 queries are wasted traffic.

However, that was the original migration path expected which has 
finally materialized - Getting clients to support both record types 99 
and TXT first before recommending type 99 only publishing can be 
considered.  It would not have been feasible nor reasonable to 
recommend type 99 only publishing in 4408.

To the surprise of many, clients are doing the expected behavior of 
dual type queries - all expected to come with a short term waste.

Now its time for the BIS update to declare, pardon the pun, "Route 99" 
is now paved and safe to drive (begin publishing type 99 records).

--
HLS

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 28 Feb 2012 13:32:58 +0100

> deployed. And not give up.

I agree it is a praiseworthy task to pursue the diffusion of unknown
RRTypes.  However, it cannot be piggybacked on client protocols, that
have their own difficulties and version life cycles.  When it will be
possible to deploy unknown types, protocols that nowadays reuse TXT
will convert to their own type, taking advantage of binary formats and
unambiguous querying.

There have to be transition periods, during which TXT records are
accepted for backward compatibility.  However, when a new protocol's
version implies using a different record type, backward compatibility
should result from supporting the old version.  To allow both TXT and
a specific RRType --especially one that uses multiple bytes to encode
a 4-bit version number-- to serve exactly the same protocol versions
is an /unfounded excuse/ that does nothing to encourage the diffusion
of that RRType.  For SPF, it just doubled the number of queries.

---

From: John Leslie <[email-masked]>
Date: Tue, 28 Feb 2012 11:42:22 -0500

> draft-levine-dnsextlang-02.txt

   "We believe in rough consensus and running code."

   I'm happy to contribute to the "rough consensus" once I see running
code, perpaps for bind and perl-script registrar interfaces.

--
John Leslie <[email-masked]>

---

From: Hector <[email-masked]>
Date: Tue, 28 Feb 2012 17:07:03 -0500

> code, perpaps for bind and perl-script registrar interfaces.

How people do it, is how people learn.  :)

--
HLS

---

From: Doug Barton <[email-masked]>
Date: Tue, 28 Feb 2012 14:23:30 -0800

> and I challenge you to find any that supports SPF records.

I have been both the author and a consumer of the types of interfaces
that you're describing, and I had a very peripheral role in the work to
evangelize interface support for new TLDs, IPv6, and DNSSEC; so I'm
familiar with the issue. My experience with these issues tells me that
when there is demand to support a new RRtype, it will be supported.

So, once again, we need to learn from the mistakes that were made with
SPF. Here is how life goes in most busy enterprise environments:

Intelligent sysadmin: We need to deploy SPF
Boss: How does it work?
I: Well, eventually it will have its own DNS RR, but for now it works
with TXT records
B: Ok, put those TXT records in
<time passes>
I: It's now possible to use SPF RRs for SPF, so I need to make some
changes, do some testing, etc.
B: Are the TXT records working now?
I: Well yes, but ...
B: We have more important priorities that I need you to spend your time
on, leave the thing that's working alone.

Or, put more simply, your conclusion seems to be that we can never add
new RRs. Given that adding new RRs is crucial to the growth of the
Internet, I reject that conclusion completely.

Doug

-- 
    If you're never wrong, you're not trying hard enough

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 28 Feb 2012 17:31:36 -0500

>Internet, I reject that conclusion completely.

The original SPF work was done outside the IETF, so no amount of "Hey, you can't do that" would have made a difference. Unless it's dead easy for new designs to use new RR Types it will be very difficult to get them deployed.

It's not dead easy until the more global deployment problems are solved.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 28 Feb 2012 22:35:28 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Doug Barton
> Sent: Tuesday, February 28, 2012 2:24 PM
> To: John Levine
> Cc: [email-masked]

Your scenario illustrated the problem nicely: People started SPF with TXT records because they were available and the road to a new RRType was seen as a steep one.  Once that was even a little bit deployed, it became practically irreversible.  The same happened with DKIM, and then VBR, and now it's basically common practice to use naming tricks to sidestep the RRType arguments.

I think the right endgame here is to make sure new RRTypes are accessible to those that want to have them.  This will remove the temptation to start with TXT and, ultimately, stay there.

-MSK

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Feb 2012 09:59:18 +1100

In message <[email-masked]>, Scott Kitte
rman writes:
> The original SPF work was done outside the IETF, so no amount of "Hey, you can
> 't do that" would have made a difference. Unless it's dead easy for new design
> s to use new RR Types it will be very difficult to get them deployed.
> 

As someone who has deploy a new type globally it isn't that hard.
The hardest part as convincing the IESG that I wasn't trying to
cirumvent what was happening with DNSSEC.  I've even taken it from
a private type (65323) to a documented type (32769).

	http://tools.ietf.org/html/rfc4431

Yes, I work for a name server vendor but nothing I did couldn't
have been done by anyone else.  We get have the occassional submission
of code to support a new type.  We also get requests to add a new type.

Mark

---

From: "John R. Levine" <[email-masked]>
Date: 28 Feb 2012 18:06:38 -0500

In your little dialog, the boss was entirely reasonable -- the practical 
benefit from implementing SPF records would be zip.

> Internet, I reject that conclusion completely.

No, I'm saying that it would be a lot more productive to help people 
improve their provisioning systems, rather than say how stupid they are 
for not doing what we want.  Even now, there are precious few provisioning 
systems that support AAAA records, and even fewer that support DNSSEC.  I 
hacked support for AAAA into mine, but as far as I can tell, none of my 
users other than me is using them.  I added SPF records, but then took 
them out when my DNS mirror complained that he was getting strange error 
messages.

By the way, what's your opinion of draft-levine-dnsextlang-02?

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: Mark Andrews <[email-masked]>
Date: Wed, 29 Feb 2012 10:17:52 +1100

In message <[email-masked]
m>, "Murray S. Kucherawy" writes:
> Your scenario illustrated the problem nicely: People started SPF with TXT reco
> rds because they were available and the road to a new RRType was seen as a ste
> ep one.  Once that was even a little bit deployed, it became practically irrev
> ersible.  The same happened with DKIM, and then VBR, and now it's basically co
> mmon practice to use naming tricks to sidestep the RRType arguments.
> 
> I think the right endgame here is to make sure new RRTypes are accessible to t
> hose that want to have them.  This will remove the temptation to start with TX
> T and, ultimately, stay there.

They are there.  They were there when SPF was being developed.  They
were there when DKIM was being developed.  It's just the neigh
sayers won out.

Libresolv has supported unknown types for 25 years.  Other C libraries
support them.  dnspython supports them.  dnsjava supports them.  It
really isn't hard to get a length tagged blob of data back to the
application.

Authoritative nameservers support them.  Recursive nameservers
support them and always have modulo bugs.

If your DNS hosting company doesn't support them find another one
or complain to them.  You are paying them to host your DNS services
and this is a basic part of the job.

Mark

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 28 Feb 2012 18:38:45 -0500

On Wednesday, February 29, 2012 10:17:52 AM Mark Andrews wrote:
> In message
> <[email-masked]
> > > Of Doug>  
> >  Barton
> > Your scenario illustrated the problem nicely: People started SPF with
> > TXT reco rds because they were available and the road to a new RRType
> > was seen as a ste ep one.  Once that was even a little bit deployed, it
> > became practically irrev ersible.  The same happened with DKIM, and
> > then VBR, and now it's basically co mmon practice to use naming tricks
> > to sidestep the RRType arguments.
> > 
> > I think the right endgame here is to make sure new RRTypes are
> > accessible to t hose that want to have them.  This will remove the
> > temptation to start with TX T and, ultimately, stay there.
> 

To what hosting company should I switch if I want to publish SPF records of 
Type SPF?

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 28 Feb 2012 18:42:39 -0500

> Internet, I reject that conclusion completely.

Here is a suggestion for those who are convinced using a new RR type in 
getting a new protocol deployed is now trivially easy and people who don't 
want to do it are lazy/whiners/ignorant/whatever:

A few weeks ago a new effort was announced in the mail authentication space 
called DMARC (see dmarc.org).  It's a brand new protocol that so far has 
minimal deployment.  It currently uses and underscored TXT subdomain, but it 
should be an ideal candidate for a new RR.

Why don't you volunteer to help them navigate through what needs to be done to 
succeed in getting deployment with a new RR type.  If you can manage it, 
that'll be the existence proof that it can be done.

Scott K

---

From: Hector <[email-masked]>
Date: Tue, 28 Feb 2012 19:52:37 -0500

> To what hosting company should I switch if I want to publish SPF records of 

SMTP hosting systems are not stuck using their ISP's primary name 
servers currently limited in their customer's UI management of 
domain(s) zone file(s).

You could always use your own name server or use another that is more 
flexible. No need to switch ISPs. Some may even allow you to do 
offline editing (export/import) of your zone files.

If you don't wish to have your own primary DNS server, there are many 
out there you can switch to, some even free, and perhaps for only 
using a faster, more 24x7 reliable name server than their ISP's name 
servers who could be tier limiting the customer.

I've gone through this issue a # of times just with SRV with customers 
and their ISPs was limited in the UI in some way. Not an issue today 
with SRV,  but the idea of installing or switching the name servers 
was always a last recourse option considered.

Yet, even if the ISP or with your own name server you added the SPF 
type, that still didn't mean all query paths taken would be 
successful. It could work 100% with testing short distance paths and 
locally, but from a remote different path?  It may not work.  That was 
the early RFC3597 issues I experienced that basically made you just 
punt of the idea of using new RR type with the obvious overhead waste. 
  But my experience today, the RFC3597 issues are much less.  I would 
not hesitate to finally enabling SPF type as a default option in our 
wares, at least give a new look for reasonable feasible results on par 
with the migration that has materialized.

--
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 28 Feb 2012 20:23:38 -0500

On Tuesday, February 28, 2012 07:52:37 PM Hector wrote:
> > To what hosting company should I switch if I want to publish SPF records
> > of Type SPF?
> 

Hector,

I know all about how I could publish SPF records.  You are missing my point.

In the previous message it was suggested that people who use a hosted DNS 
service should switch if their service doesn't support Type SPF.  The problem 
is that, as far as I'm aware, none of them do.  

I have not determined any source of economic motivation to get that to change.  
"Support this or I'll take my business to someone that does" is an empty 
threat unless someone actually does.  It's also not something anyone other 
than DNS purists would worry about.  No one is going to switch providers and 
risk downtime in order to publish a record that to a very, very close 
approximation accomplished nothing.

Scott K

---

From: Hector <[email-masked]>
Date: Tue, 28 Feb 2012 20:24:26 -0500

> and this is a basic part of the job.

+1.

We have our own primary server and use GoDaddy as my domains 
registrar. I have all my domains  name server fields pointing to our 
name servers, except for one testing domain specifically left to use 
the Godaddy hosting and name servers for this exact purpose of seeing 
what GUI DNS management and hosting features are available and how it 
evolved.

I just went to the site now to see whats there now and saw two new things:

1) The GUI is now pushing the addition of DNSSEC records with splash 
box shown when you start the DNS manager.

          "No DNSSEC record found"

and a URL link to explain more and a link to begin adding one.  It was 
becoming annoying to continue to popup up.

2) Promotion of a premium DNS management service. Curious to see if

         "New! Add new RR type support!"

was an premium feature, I didn't see it outlined. Nothing screams out 
regarding support for new RR types or adding your own.

You were always able to always download, edit, upload  your zone file. 
Didn't check to see if that was still available or removed.

--
HLS

---

From: "John Levine" <[email-masked]>
Date: 29 Feb 2012 01:36:32 -0000

>and this is a basic part of the job.

Can you suggest some DNS hosting companies that provide support for
provisioning SPF records?  I'm not aware of any.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Feb 2012 12:53:30 +1100

> provisioning SPF records?  I'm not aware of any.

SPF is listed.  http://dyn.com/dns/dns-comparison/

---

From: "John R. Levine" <[email-masked]>
Date: 28 Feb 2012 20:56:59 -0500

> SPF is listed.  http://dyn.com/dns/dns-comparison/

Hmmn, only on the premium $30/mo and up packages, not on the cheap ones. 
There must be a moral here.

By the way, what do you think of draft-levine-dnsextlang-02 ?

Regards,

---

From: [email-masked]
Date: Tue, 28 Feb 2012 17:54:58 -0800 (PST)

> is that, as far as I'm aware, none of them do.

Perhaps in some cases it's because the person or persons who want to publish
SPF records are not the ones who make the decision about which hosted DNS
service provider to use, and are unable to make a sufficient case for a change
to those who do have the authority to make it.

It's also the case that even when the ability to publish such records exists,
the person or persons who want to do so may not have the necessary access or
authority and have no way to get it.

Only today we were dealing with a customer who was asking about what options
our product provides for overriding entries in his own DNS domain with local
information. Yes, you read that right: The companies DNS has bogus stuff in it
that cannot or will not be corrected. Such requests are unfortunately not
uncommon.

All that said, a suggestion: Patrik published a pretty good list of most of the 
issues that arise when attempting to deploy new RRTYPEs. Some of those, like
the lack of GUI pulldowns in some hosting provider web interfaces, are clearly
beyond the IETF's purview to address. But others, like the formatting issues in
zone master files that arise when a new RRTYPE is defined, are things we can
address. (And no, external scripts to do the format conversion are not a
sufficient solution to this problem.)

So might I suggest that instead of arging about the operational realities of
deploying new RRTYPEs - which  appears to be turning into yet another retelling
of the parable about the blind men and the elephant - we instead turn our
attention to activities that would actually address parts of the problem.

In particular, John Levine has already written a draft that attempts to address
the formatting issues by defining a simple format extension language. That
might be a good place to start. (I've already sent him my review comments in
private email.)

				Ned

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 29 Feb 2012 02:51:24 +0000

Godaddy, basic domain hosting at $10 per .com, allows you to set an SPF
record.
Stephan

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 28 Feb 2012 23:28:56 -0500

> Godaddy, basic domain hosting at $10 per .com, allows you to set an SPF

Of type TXT or type SPF?  I checked with someone who has domains at Go Daddy 
and they couldn't find a mechanism for publishing Type SPF records.

Scott K

---

From: Hector <[email-masked]>
Date: Wed, 29 Feb 2012 00:02:13 -0500

> and they couldn't find a mechanism for publishing Type SPF records.

Long time customer of GoDaddy, I don't ever recall support for SPF 
type or any new RR type outside the common ones, and even then I 
believe SRV came later with newer UIs and as I see today, a BIG PUSH 
to get you to add a DNSSEC record with an annoying POPUP box when you 
enter the DNS manager.

I don't know if it does it on a cookie basis, but I just noticed it today.

The only way I can see with GoDaddy is to export your zone file, edit 
offline and then import.

What I think Stephan is pointing out, is that even though you always 
had the ability to add a TXT record, there was an advanced special SPF 
"marketing" option to select to got it started to add the TXT record. 
  I don't recall it being a SPF rule wizard though, unless its changed 
today.

--
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 29 Feb 2012 00:11:09 -0500

On Wednesday, February 29, 2012 12:02:13 AM Hector wrote:
> > Of type TXT or type SPF?  I checked with someone who has domains at Go
> > Daddy and they couldn't find a mechanism for publishing Type SPF
> > records.

I checked again and I'm told when adding a record there's an option to add an 
SPF record, but the record it adds is of Type TXT.

Scott K

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 29 Feb 2012 05:27:02 +0000

Confirmed.  The menu option says "add SPF", but you end up with a TXT
record.
Embarrassed,
Stephan

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 29 Feb 2012 13:06:52 +0100

On 29/Feb/12 02:54, [email-masked] wrote:
> 
> All that said, a suggestion: Patrik published a pretty good list of
> most of the issues that arise when attempting to deploy new
> RRTYPEs. Some of those, like the lack of GUI pulldowns in some
> hosting provider web interfaces, are clearly beyond the IETF's
> purview to address. But others, like the formatting issues in zone
> master files that arise when a new RRTYPE is defined, are things we
> can address. (And no, external scripts to do the format conversion
> are not a sufficient solution to this problem.)

Why?  I realize there's lots of wisdom in those words, but I can
hardly catch sight of it.  LIFO, why are RR2txt/txt2RR not sufficient
for formatting master zones?  And why cannot those same scripts be
invoked by a provider's web form?

For responses and zone transfers, Patrik distinguished between "core"
and "edge" deployments.  I heard about NotImp responses and mirroring
difficulties.  What is the current status?

> So might I suggest that instead of arguing about the operational
> realities of deploying new RRTYPEs - which  appears to be turning
> into yet another retelling of the parable about the blind men and
> the elephant - we instead turn our attention to activities that
> would actually address parts of the problem.

The phrase "rough consensus and running code" must be meant to be in
that order, because consensus makes the difference between /runnable/
and /running/ code.  Indeed, that parable often ends with "Then the
king/president explained to the blind men...", so we'd have to replace
that part with something that we can believe in, anyway.

> In particular, John Levine has already written a draft that
> attempts to address the formatting issues by defining a simple
> format extension language. That might be a good place to start.
> (I've already sent him my review comments in private email.)

I agree it's a clever spec, and I believe it's not overly hard to code
a couple of generic RR2txt/txt2RR scripts that use such symbolic
descriptions.  However, if we want to tackle some protocols, we had
better add an alternative stanza syntax for "tag=value" kinds of
record, and/or provide for type-specific external utilities.

But shouldn't we reach consensus on a migration strategy before we
discuss the tactics?  RFC 6195 says a new RR type should not be
allocated in case:

 5.  An excessive number of RRTYPE values is being requested when the
     purpose could be met with a smaller number or with Private Use
     values.

That criterion apparently matches requesting a new type and at the
same time reusing TXT.  RFC 5507 elucidates good principles and
reasons why adding a new RR type is a better solution than reusing
TXT, but it doesn't say that doing both solutions at the same time
results in a parody of those principles.

---

From: Hector Santos <[email-masked]>
Date: Tue, 28 Feb 2012 21:01:28 -0500

Offlist. I will have an public reply to the message, maybe. I just 
want to hopefully show some basic more friendly approach to your 
statements from one that basically begins a friction:

Scott:

    I know all about how I could publish SPF records.  You are missing 
my point.

Revised friendly, no friction.

    Yes, but perhaps you may missed my points....

Why? because I did not miss your point and I could easily say:

    "Scott, I always saw your point, the problem is you are missing the
     point of others."

So in essence, it shows we are talking pass each other and the way you 
stated just feeds into the people like Murray's who will now say, "He 
is always missing the point."

So understand your  MAIN point and always did and that is why I 
started with this thread when I asked:

And why you see most, if not all of the infrastructure people who 
posted, including Patrick, Mark, Paul and others like Burton express 
the same belief that new RR types are preferred.

Every one of us agreed that there are valid arguments and issues, and 
that is why I am saying

    "Ok, is it still a preferred ideal and are the issues are too 
problematic,
     and also importantly, the HARDWARE/SOFTWARE and DATABASES have 
improved
     so much that it means many of the early and current concerns 
obsolete."

See that last point - even current concerns regarding wasted calls. 
If you argue the point that it is WASTED CALLS, then you are making an 
infrastructure consideration that it will benefit DNS large scale 
usage by not use new RR types that already have a TXT backup.

But that is not the argument you are making, you are using low usage, 
and its even harder to see that as valid, when A) its not "honest" and 
B) the migration we wanted is exactly that happen.

Try to understand these subtle points because if you believe it was 
important, then you may see that the solution is to now promote the 
publishing in order to begin getting a payoff with the clients already 
doing the SPF type call.  I would also suggest that we help embark a 
technical sales marketing campaign to get hosting companies to begin 
supporting  the new IETF protocols with their specific RR types.

Scott say:

    No one is going to switch providers and risk downtime in order to 
publish a
    record that to a very, very close approximation accomplished nothing.

Revised friendly text:

    I suspect or don't have the confidence domain owners will switch 
providers
    and risk downtime in order to publish a record that to a very, very
    close approximation accomplished nothing.

Why?

Highly subjective.  Its a crystal ball opinion and one that comes with 
very high potential to see  domains beginning to use SPF types, 
especially those who have an Infrastructure Optimizing belief that it 
will help with contributing to a lesser SPF TXT only impact on DNS.

You completely ignore that I stated. Before the migration evidence 
shown that has proved the original intent was correct, I was 100% with 
you.  But the migration path that was discovered, I am 100% eager now 
to support it.

You ignored the next step for the migration now that clients are 
ready, promoting SPF type publishing perhaps starting with a dual 
publishing as well as the next migration expected.

And finally, you might be not aware of, but if you are, then ignoring, 
the very important points in the DNSOPS thread I started with Paul 
Vixie input showing perhaps what is the solution we should be repeated 
with Additional Info queries like it was with A/MX records.

    http://www.ietf.org/mail-archive/web/dnsop/current/msg09447.html
    http://www.ietf.org/mail-archive/web/dnsop/current/msg09451.html
    http://www.ietf.org/mail-archive/web/dnsop/current/msg09453.html

What I am saying use a solid engineering logic based on technical 
merit, and not a "practically factor" to dismiss what is still 
important considerations.  The reason overall is that you are are 
saying these ISP will never change and that is a "prediction" that can 
be very easily become untrue.

All it takes a better IETF promotion and marketing to get more ISP to 
support new RR types.

-- 
Sincerely

Hector Santos