Re: Service Bindings DNS Records (draft-nygren-service-bindings-00)

On Jul 8, 2014 6:24 PM, "Erik Nygren" <erik@nygren.org> wrote:
>
> Yes, this is single blocking lookup for browsing, although it can be done
opportunistically
> in parallel with the A/AAAA lookups.  Depending on TTL settings and how
the records
> are handled relative to additional records, it's possible that the impact
will be quite minimal.
> It would also be reasonable for a client to only wait a bounded amount of
time after an A/AAAA
> response before using that, similar to how Chromium bounds how long it
waits for an AAAA
> after it gets an A response.
>
> I'd read that SRV record thread which influenced some aspects of the
design --- in particular,
> to have a single record that can vector off and provide information about
other records that
> are needed and when they are needed, as well as to provide other hints
(eg, that a DANE/TLSA
> record is available).  There may be cases where doing this lookup
serially could actually improve
> performance:
>
> * For example, with TLS 1.3 and handshake encryption, it could
potentially even save
>     TCP round-trip while being cacheable in resolvers.
> * If it can allow immediate negotiation to alpn=h2 for http scheme then
that also improves overall performance.
> * If it allows clients supporting TLS SNI to be assigned to servers
closer to them
>   than more central servers with IPv4 VIPs per cert, that also improves
overall performance.
> * If it allows signalling that clients must use HTTPS (ie, HSTS-style) in
the same record,
>   that also saves multiple TCP round-trips.
>
> In other words, I think it's worth exploring and looking at different
scenarios
> before ruling it out-of-hand purely for latency reasons if there are
enough values gained.

Fair enough. I'll read it more thoroughly tomorrow. Note that the happy
eyeballs for ipv6 is different, because origins have to opt into serving
AAAA responses. They get to make that latency tradeoff decision themselves,
rather than Chrome version X launching and being slower for all websites.

>
>           Erik
>
>
>
> On Tue, Jul 8, 2014 at 8:53 PM, William Chan (陈智昌) <willchan@chromium.org>
wrote:
>>
>> Sorry, I only skimmed this and I didn't find it anywhere. Is this a
blocking lookup for browsing? If so, the current Chromium stance is likely
"no". If a parallel lookup, then there are complications and we'd have to
evaluate more closely. More details and history of our stance on SRV
records: https://code.google.com/p/chromium/issues/detail?id=22423.
>>
>> Cheers.
>>
>>
>> On Tue, Jul 8, 2014 at 7:36 AM, Erik Nygren <erik@nygren.org> wrote:
>>>
>>> Following some discussion in both the TLS and HTTPBIS working groups at
past meetings, it became clear that there was a need for a mechanism more
flexible and powerful than SRV records.  In particular, we've discussed the
desire for an (optional) DNS-based mechanism for upgrading to HTTP/2
in-addition to AltSvc, especially for "http" scheme.
>>>
>>> One of the major browser concerns is limiting the number of DNS lookups
that need to be performed before establishing a connection, especially when
multiple records that may only exist a small fraction of the time need to
be hunted for.  This proposal attempts to limit that while also enabling
future flexibility.  There are some related problems in the TLS wg that
this also provides a path to address.  Regarding the concern that the
adoption rate for new record types is slow, this is explicitly an
additional mechanism for now (such that clients should fall back to A/AAAA
address records and such when unavailable).
>>>
>>> Feedback is most welcome and I'm happy to discuss more in Toronto.
This does not yet have a working group home yet, especially as it spans the
interests of a number of WGs.  There are also plenty of open issues, and
I'd like to land on the concepts before getting into final details of
encoding:
>>>
>>>       http://tools.ietf.org/html/draft-nygren-service-bindings-00
>>>
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: <internet-drafts@ietf.org>
>>> Date: Fri, Jul 4, 2014 at 12:39 AM
>>> Subject: I-D Action: draft-nygren-service-bindings-00.txt
>>> To: i-d-announce@ietf.org
>>>
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>>>
>>>
>>>         Title           : Service Binding DNS Records (DNS B)
>>>         Author          : Erik Nygren
>>>         Filename        : draft-nygren-service-bindings-00.txt
>>>         Pages           : 16
>>>         Date            : 2014-07-03
>>>
>>> Abstract:
>>>    This document describes a DNS "B" RR which binds together information
>>>    needed to establish connection to a service across multiple protocol
>>>    layers, including the location of the server, the application-level
>>>    protocol, and security bootstrap information.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-nygren-service-bindings/
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-nygren-service-bindings-00
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> I-D-Announce@ietf.org
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>
>