[TLS] I-D Action: draft-ietf-tls-dtls-connection-id-06.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : Connection Identifiers for DTLS 1.2
Authors : Eric Rescorla
  Hannes Tschofenig
  Thomas Fossati
Filename: draft-ietf-tls-dtls-connection-id-06.txt
Pages   : 15
Date: 2019-07-08

Abstract:
   This document specifies the Connection ID (CID) construct for the
   Datagram Transport Layer Security (DTLS) protocol version 1.2.

   A CID is an identifier carried in the record layer header that gives
   the recipient additional information for selecting the appropriate
   security association.  In "classical" DTLS, selecting a security
   association of an incoming DTLS record is accomplished with the help
   of the 5-tuple.  If the source IP address and/or source port changes
   during the lifetime of an ongoing DTLS session then the receiver will
   be unable to locate the correct security context.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-06
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls-connection-id-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls-connection-id-06


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/

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Delegated Credentials in Client certificates

[Nick Sullivan]

Hello TLSWG,

At previous meetings (and I think on the list?) there were requests to
extend the Delegated Credentials in TLS (
https://tools.ietf.org/html/draft-ietf-tls-subcerts) draft to support
client certificates. This turns out to be a pretty minor change to the
document. I've put up a PR:

https://github.com/tlswg/tls-subcerts/pull/26/files/a502f3055c3eefe59a4b36642cd062267ac0fff7

Let me know if there is opposition to this change. I'm planning on
submitting -04 later today.

Nick
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-dtls13-32.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : The Datagram Transport Layer Security (DTLS) Protocol 
Version 1.3
Authors : Eric Rescorla
  Hannes Tschofenig
  Nagendra Modadugu
Filename: draft-ietf-tls-dtls13-32.txt
Pages   : 52
Date: 2019-07-08

Abstract:
   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees with the exception of order protection/non-replayability.
   Datagram semantics of the underlying transport are preserved by the
   DTLS protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-32
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-32

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-32


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/

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Delegated Credentials in Client certificates

[Subodh Iyengar]

Thanks for writing this up Nick. I support this change.


I think one interesting addition to this PR might be a discussion of what could 
happen if you use the same DC as both a client and server. I suspect this is 
what a lot of people might do in a datacenter environment and that this is safe 
(because of the signature context), but it might push people to think a little 
more about this topic.


Subodh


From: TLS  on behalf of Nick Sullivan 

Sent: Monday, July 8, 2019 1:12:00 PM
To: 
Subject: [TLS] Delegated Credentials in Client certificates

Hello TLSWG,

At previous meetings (and I think on the list?) there were requests to extend 
the Delegated Credentials in TLS 
(https://tools.ietf.org/html/draft-ietf-tls-subcerts)
 draft to support client certificates. This turns out to be a pretty minor 
change to the document. I've put up a PR:

https://github.com/tlswg/tls-subcerts/pull/26/files/a502f3055c3eefe59a4b36642cd062267ac0fff7

Let me know if there is opposition to this change. I'm planning on submitting 
-04 later today.

Nick
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] HTTPSSVC record draft - ESNI alternative for HTTPS

[Erik Nygren]

For those not on the HTTP-WG or DNSOP lists, Ben Mike and I have
a draft for an "HTTPSSVC" DNS record.  There's a -03 that incorporates
some feedback from the first version:

https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-03

This attempts to address a number of problems (ESNI, QUIC bootstrapping,
HTTP-to-HTTPS redirection via DNS, SRV-equivalent for HTTP, etc) in a
holistic manner through a new extensible DNS record, rather than in a
piecemeal fashion.  It is based on some previous proposals such as "Alt-Svc
in the DNS" and "Service Bindings" but takes into account feedback received
in DNSOP and elsewhere.

In particular for the TLS WG, we'd be interested in hearing if this would
solve enough of the ESNI-key-delivery-via-DNS needs for the HTTPS use-case.

Feedback is most welcome and we're looking forward to discussing with
people in Montreal.

While this is still an individual draft, we have been tracking it here:
https://github.com/MikeBishop/dns-alt-svc
but as always, commentary on the IETF lists is generally preferable.
There is even a preliminary private type implementation in BIND
of the -01 version (with the -02 wire format supported by ifdefs)
from Mark Andrews:
https://gitlab.isc.org/isc-projects/bind9/merge_requests/2135

>From the abstract:

This document specifies an "HTTPSSVC" DNS resource record type to
facilitate the lookup of information needed to make connections for HTTPS
URIs.  The HTTPSSVC DNS RR mechanism allows an HTTPS origin hostname to be
served from multiple network services, each with associated parameters
(such as transport protocol and keying material for encrypting TLS SNI).
It also provides a solution for the inability of the DNS to allow a CNAME
to be placed at the apex of a domain name.  Finally, it provides a way to
indicate that the origin supports HTTPS without having to resort to
redirects, allowing clients to remove HTTP from the bootstrapping process.

By allowing this information to be bootstrapped in the DNS, it allows for
clients to learn of alternative services before their first contact with
the origin.  This arrangement offers potential benefits to both performance
and privacy.

This proposal is inspired by and based on recent DNS usage proposals such
as ALTSVC, ANAME, and ESNIKEYS (as well as long standing desires to have
SRV or a functional equivalent implemented for HTTP).  These proposals each
provide an important function but are potentially incompatible with each
other, such as when an origin is load-balanced across multiple hosting
providers (multi-CDN). Furthermore, these each add potential cases for
adding additional record lookups in-addition to /A lookups.  This
design attempts to provide a unified framework that encompasses the key
functionality of these proposals, as well as providing some extensibility
for addressing similar future challenges.

--

Some likely FAQs (with some others listed in an appendix):

Q: Why this is HTTP-specific?
A: This is because every protocol has different bootstrap requirements.
This draft is concerned with improving the efficiency and security of
bootstrapping HTTPS connections.  This proposal does offer room for
non-HTTPS protocols, but the nature of DNS requires underscore prefixing to
support protocol-keyed answers within a single RRTYPE.  It's also unlikely
that a single RR format would be the ideal bootstrap mechanism for every
protocol, and there's no reason that multiple protocols should have to
share an RRTYPE.

Q: Why is ESNI addressed directly?
A: This helps make a major motivation of this draft more clear.  Splitting
out those sections to a separate-but-associated "alt-svc attribute for ESNI
keys" draft might make sense, but keeping it here helps work through some
of the issues together.

Q: Why does this try to address the HSTS case?
A: This is a unique opportunity to fix HTTPS bootstrap and avoid providing
insecure defaults.  We'd originally proposed a separate Alt-Svc attribute
to indicate hsts-style behavior, but then realized that it would make sense
to push on that as the default here.

Best, Erik
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] HTTPSSVC record draft - ESNI alternative for HTTPS

[Stephen Farrell]

Hi Erik,

On 08/07/2019 22:27, Erik Nygren wrote:
> 
> In particular for the TLS WG, we'd be interested in hearing if this would
> solve enough of the ESNI-key-delivery-via-DNS needs for the HTTPS use-case.

I'm not clear if you envisage this entirely replacing the
new ESNI RR (as defined in ESNI draft-03), or if you envisage
both being defined, with this one (HTTPSSVC) being used for
the web and the ESNI RR for non-web uses of TLS, or maybe
something else?

It'd seem like a bad plan two have multiple ways of doing
the same thing, but I guess there're trade-offs in various
directions here.

BTW - I read an earlier version of your draft and there
were a few detailed discrepancies vs. the ESNI draft but
those could be resolved later.

Cheers,
S.


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] HTTPSSVC record draft - ESNI alternative for HTTPS

[Erik Nygren]

Hi Stephen,

On Mon, Jul 8, 2019 at 5:39 PM Stephen Farrell 
wrote:

>
> On 08/07/2019 22:27, Erik Nygren wrote:
> >
> > In particular for the TLS WG, we'd be interested in hearing if this would
> > solve enough of the ESNI-key-delivery-via-DNS needs for the HTTPS
> use-case.
>
> I'm not clear if you envisage this entirely replacing the
> new ESNI RR (as defined in ESNI draft-03), or if you envisage
> both being defined, with this one (HTTPSSVC) being used for
> the web and the ESNI RR for non-web uses of TLS, or maybe
> something else?
>
> It'd seem like a bad plan two have multiple ways of doing
> the same thing, but I guess there're trade-offs in various
> directions here.
>

My thinking is that different protocols have different needs
and requirements for key delivery via DNS.  As such, separating
out the ESNI key format from the DNS record for provisioning
makes sense.  EKR had the valid point that it would be valuable
to have a basic way of doing ESNI key provisioning for protocols
lacking complex requirements.

This could end up as "protocols should specify bindings for how
ESNI keys are delivered via DNS", with a HTTPSSVC RR for the HTTPS
use-case, perhaps with other protocol bindings for other things with
specific requirements, and with an ESNI RR (which might be able
to be made simpler if some of the Web requirements can be abstracted)
for generic use-cases.

A downside is that this does add complexity for tools that operate entirely
at the TLS layer such as openssl s_client that would be happier if only
an ESNI record existed.  However, the HTTPS use-case
already has a bunch of other scenarios such as HTTP/3 that break/blur
this abstraction layer such that it may be that this type of HTTPS
connection
management and DNS resolution needs to be done at the HTTP session layer
regardless, with TLS libraries providing an interface to pass in ESNI keys.

Encrypting authoritative DNS from recursives to authorities is in
its early days, but it would not surprise me if similar requirements
show up there and require a new DNS record type.  (eg, an extensible
NS record or an extensible record named by an NS record that includes
information about protocols and ESNI keys and the like.)

Best, Erik
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-subcerts-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : Delegated Credentials for TLS
Authors : Richard Barnes
  Subodh Iyengar
  Nick Sullivan
  Eric Rescorla
Filename: draft-ietf-tls-subcerts-04.txt
Pages   : 13
Date: 2019-07-08

Abstract:
   The organizational separation between the operator of a TLS endpoint
   and the certification authority can create limitations.  For example,
   the lifetime of certificates, how they may be used, and the
   algorithms they support are ultimately determined by the
   certification authority.  This document describes a mechanism by
   which operators may delegate their own credentials for use in TLS,
   without breaking compatibility with peers that do not support this
   specification.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-subcerts-04
https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-04


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/

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] AD review of draft-ietf-tls-grease-02

[David Benjamin]

Thanks for the comments! I've addressed them in
https://github.com/tlswg/draft-ietf-tls-grease/pull/10.

On Wed, Jul 3, 2019 at 1:11 PM Benjamin Kaduk  wrote:

> Section 1
>
>The TLS protocol [RFC8446] includes several points of extensibility,
>including the list of cipher suites and the list of extensions.  The
>values in these lists identify implementation capabilities.  TLS
>
> We could probably make this text a little more precise (for one, there's
> not a single list of extensions since many messages can carry
> extensions).  So, maybe "the list of cipher suites and several lists of
> extensions" and "The values transmitted in these lists"?
>

Done.


> Section 2
>
> Can we add an editorial note that values prefaced with "{TBD}" are
> suggested values but subject to change prior to final allocation by
> IANA?
>

Done. Also made the other such notes match the style used in the TLS 1.3
draft.


>Future versions of TLS or DTLS [RFC6347] MUST NOT use any of the
>above values as versions.
>
> Process-wise, this feels like an attempt to Update: the (D)TLS core
> specs, which we can't do in an Informational document.  So it would
> probably be better to say something "The values thusly allocated are no
> longer available for use as version numbers by (D)TLS implemnetations".
> Things are made somewhat awkward by there not being a registry of
> protocol versions, sadly...
>

Done.


> Section 3.1
>
> Are there any of these for which we want to say "the client MUST NOT
> advertise a list consisting solely of GREASE values"?  It would probably
> be fine to do this for, say, key_share, but not for, say, cipher_suites.
> But perhaps the reader will be smart enough to figure out what works
> without prodding from us...
>

I dunno, I feel like that's a bit overkill, but I can include something in
that vein if others disagree. A cipher suite list full of GREASE is
functionally equivalent to a list containing some weird cipher no one
implements.


>Clients MUST reject GREASE values when negotiated by the server.
>Specifically, the client MUST fail the connection if a GREASE value
>appears any in the following:
>
> I did not attempt to audit the (omitted) list for completeness; the
> first sentence should cover any situations that are not specifically
> listed, right?
>

It should. I replaced "Specifically" with "In particular" so that's clearer..


> Section 3.2
>
>When processing a ClientHello, servers MUST NOT treat GREASE values
>differently from any unknown value.  Servers MUST NOT negotiate any
>GREASE value when offered in a ClientHello.  Servers MUST correctly
>ignore unknown values in a ClientHello and attempt to negotiate with
>one of the remaining parameters.
>
> Similarly to the above, we might consider adding a parenthetical noting
> that there may not be any remaining valid parameters, and that's not
> necessarily fatal.
>

Done.


>Note that these requirements are restatements or corollaries of
>existing server requirements in TLS.
>
> (side note) Some future reviewers might complain about using normative
> language to duplicate exisiting requirements from other documents; in
> this case, I don't mind, myself.
>
> Section 4.1
>
>o  A server MAY select one or more GREASE extension values and
>   advertise corresponding extensions with varying length and
>   contents.
>
> nit: I don't think "corresponding" is quite the right word; maybe
> "advertise those extensions"?
>

Rephrased this and elsewhere.


>o  A server MAY select one or more GREASE signature algorithm values
>   and advertise them in the "signature_algorithms" extension.
>
> I'm not necessarily expecting any action based on this comment, but I
> note that status_request, signed_certificate_timestamp,
> certificate_authorities, oid_filters, and signature_algorithms_cert are
> also currently defined for CertificateRequest but we do not call out any
> extension-specific greasing for them.  Of that list, only
> signature_algorithms_cert seems like it might be calling out for special
> handling, to me...
>

Added signature_algorithms_cert.


> Section 4.2
>
>When processing a CertificateRequest or NewSessionTicket, clients
>MUST NOT treat GREASE values differently from any unknown value.
>Clients MUST NOT negotiate any GREASE value when offered by the
>server.  Clients MUST correctly ignore unknown values offered by the
>server and attempt to negotiate with one of the remaining parameters.
>
> (following the theme) I don't remember any cases where the client can
> succeed if the list becomes empty after pruning unknown values ... if we
> are deciding that we want to say anything on this topic at all.
>

Added a similar parenthetical.


> Section 5
>
>Implementations advertising GREASE values SHOULD select them at
>random.  This is intended to encourage implementations to ignore all
>unknown values rather than any individual value.  Imple

Re: [TLS] HTTPSSVC record draft - ESNI alternative for HTTPS

[Stephen Farrell]

I'm not sure what I think about the general idea TBH but
just on this bit...

On 08/07/2019 23:08, Erik Nygren wrote:
> 
> A downside is that this does add complexity for tools that operate entirely
> at the TLS layer such as openssl s_client that would be happier if only
> an ESNI record existed. 

I don't think that's such a big deal for the library as
that's unlikely to include the code to do DNS queries.
Being able to parse a couple of different wrappers for
ESNIKeys isn't that big a deal.

And at least the code I've done for s_client assumes it
gets the RR value on the command line (for now anyway)
so that's also no biggie. But I figure s_client isn't
that important as an application anwyay;-)

Having different DNS RRTYPEs one might need to probe
or otherwise know about would make like harder for
real application code that does DNS though, and for
servers who might end up having to publish the same
things in different ways. So I hope we don't create
that kind of problem.

Cheers,
S.


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-esni-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : Encrypted Server Name Indication for TLS 1.3
Authors : Eric Rescorla
  Kazuho Oku
  Nick Sullivan
  Christopher A. Wood
Filename: draft-ietf-tls-esni-04.txt
Pages   : 30
Date: 2019-07-08

Abstract:
   This document defines a simple mechanism for encrypting the Server
   Name Indication for TLS 1.3.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-esni/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-esni-04
https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-esni-04


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/

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls