[TLS] Draft minutes for TLS, Monday session

[Salz, Rich]

Draft minutes attached; please post corrections to the list.


Minutes  for TLS at IETF 103, Monday

Did administrivia (scribes, agenda, bluesheets)

Reviewed document status

DTLS 1.3 update, ekr
- New unified packet header that is flexible and more tightly packed
- Sequence (record) number is now encrypted
- DTLS 1.3 MUST NOT use compatibility mode 
- Removing end of early data marker
- Changes to allow ConnectionID flexibility
- Next version would go into WGLC

Deprecating TLS 1.0 and 1.1, Stephen Farrell
- Details about which RFC's, BCP's are affected
- Will remove the 'measurements' part
- Remove SHA-1 deprecation from this document
- Discussion of timeline; will do new draft and WGLC soon

Encrypted SNI, Nick Sullivan
- Early drafts deployed by CloudFlare and FF Nightly, for experimentation
- Changes from initial draft: two key shares, none, AEAD, replay 
protection, version
- Major pending change: new DNS RRType instead of TXT
- Proposal from floor: have list of ESNI records, for middleboxes (and 
others); DNSSEC
  implications and other discussion
- Operational issues: DNS/server out of sync, multi-CDN usecase

Discussion of re-Chartering, chairs
- Detailed text was sent to the mailing list
- Discuss DTLS items in the charter (e.g., are they already done?)
- Discuss timing of this; maybe wait for DTLS 1.3 to be done

External PSK, Russ Housley
- Determine way forward via series of hum's
- Decided to adopt the draft, which has only "external PSKs with 
certificates"

TLS Authentication using ITS ETSI and IEEE Certificates, Mounira Msahli
- These are apparently smaller certificates than X509; used in vehicles
- Description of new certificate types; will ask for IANA registration

External PSK Importers, Christopher A. Wood
- Motivation was TLS 1.2 and 1.3 hashed differently
- An importer takes an existing PSK, adds hash and optional label as base 
key,
  then generate key per hash supported
- Comparison of this and "universal hash" document by David Benjamin

TLS Ticket Request, Christopher A. Wood
- Clients want more/less tickets than servers send by default
- Add ClientHello extension that hints number of tickets desired
- Consensus to adopt as a WG document, to be confirmed on the list




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

[TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics

[Benjamin Kaduk]

Hi all,

I do not know whether Wednesday's discussions will end up in a place where
these thoughts will be useful, but in the spirit of having discussions on
the list, I decided to write up some thoughts I've been pondering for a
while.  Hopefully the written form will be more clear than if I had to try
to express them in the mic line, and perhaps they will even inspire
thoughts from other people as well.

That said, I recognize that I am posting this pretty late and the one day
between now and then is already packed with meeting sessions, so I do not
expect to have a complete discussion on the list before the Wednesday
session.  (As always, happy to be proven wrong.)  So...

Once we start talking about pinning of any sort, we move from this
extension just being "transport some DNS records" into conveying some
sort of additional semantics.

It seems that we have not really had a structured discussion about what
semantics and information flows we might or might not want to convey in
this extension (in one or both directions!), and I'm reluctant to consider
adding such semantics without such a discussion.

If we accept the premise that the intention of DANE as relevant in this
space is to allow the server to convey to the client the server's
preferences for how the client should authenticate the server, we may also
want to consider the case where a server operator wants to eventually get
to a DANE-only state where it can ignore the web PKI.  (There may not be
many or any servers that actually end up wanting to do this, but it's not
unreasonable to consider the possibility.)  In order for a server to do
that, the server needs to know that all clients are not only willing to do
DANE, but able to get the records they need, whether via this extension or
otherwise!  Without such information, the server risks breaking clients
with the transition, and not knowing what population of clients have been
broken.

Doing some brainstorming on what the client might be able to tell the
server in this space, I can come up with things like:

(1) the client is willing to use DANE to authenticate the server
(2) the client already has the DANE records it needs to do (1)
(3) the client needs the server to give it the DANE records to do (1)
(4) the client requires the server to be DANE authenticated
(5) the client already has the DANE records it needs to do (4)
(6) the client needs the server to give it the DANE records to do (4)
(7) the client is willing to commit to one or more of the above for some
time period

Similarly, the server may want to indicate things like:

(a) the server wants to be authenticated via DANE (yes, this is just the
contents of the DNS)
(b) the server can provide DANE/DoE records in a TLS extension
(c) the server will commit to (a) for some time
(d) the server will commit to (b) for some time

Some of these might be always a consequence of or very strongly implied by
the presence of some information (e.g, sending the extension probably
implies (1), and having TLSA records at all probably implies (a)).  My
understanding is that the pinning proponents want a field in the server
response that conveys (d).  Note that this does not necessarily imply (a)
or (c), at least not with the same timer!

I deliberately am not trying to come to a conclusion in this message, as I
am not confident that I have even come up with all the potential semantics
worth thinking about, and I think that any motion in this space should only
be taken with WG consensus.

I would love to hear others' thoughts on what I am missing from the above
lists, reasoning for/against including protocol elements to indicate
the listed semantics, and whether/which existing protocol elements already
convey which of the enumerated semantics.

Thanks,

Ben

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

Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics

[Viktor Dukhovni]

> On Nov 5, 2018, at 8:01 AM, Benjamin Kaduk  wrote:
> 
> Once we start talking about pinning of any sort, we move from this
> extension just being "transport some DNS records" into conveying some
> sort of additional semantics.

Transporting some bits *always* carries additional semantics, otherwise
why carry the bits.  For example, already in -07 there is clear text
specifying that the transported records can be cached for their DNS TTL,
and that once delivered DANE records should not be ignored on failure.

   
https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-07#section-6

   A TLS client making use of this specification, and which receives a
   DNSSEC authentication chain extension from a server, MUST use this
   information to perform DANE authentication of the server.  In order
   to do this, it uses the mechanism specified by the DNSSEC protocol
   [RFC4035] [RFC5155].  This mechanism is sometimes implemented in a
   DNSSEC validation engine or library.

   Clients MAY cache the server's validated TLSA RRset or other
   validated portions of the chain as an optimization to save signature
   verification work for future connections.  The period of such caching
   MUST NOT exceed the TTL associated with those records.  A client that
   possesses a validated and unexpired TLSA RRset or the full chain in
   its cache does not need to send the dnssec_chain extension for
   subsequent connections to the same TLS server.  It can use the cached
   information to perform DANE authentication.

That rather looks like semantics to me, much more than transport some bits.

> It seems that we have not really had a structured discussion about what
> semantics and information flows we might or might not want to convey in
> this extension (in one or both directions!), and I'm reluctant to consider
> adding such semantics without such a discussion.

I really don't think that at this juncture it is productive to wipe the
slate clean and consider all possible proposals, even ones that nobody
has put forward as yet.  Why would we want to do that.  There is clearly
just one primary contentious issue to resolve, and I rather think your
train of thought is a distraction from the issue at hand.

> If we accept the premise that the intention of DANE as relevant in this
> space is to allow the server to convey to the client the server's
> preferences for how the client should authenticate the server, we may also
> want to consider the case where a server operator wants to eventually get
> to a DANE-only state where it can ignore the web PKI.

Nobody is looking for this.  There's no point.  WebPKI certificates are
free (and worth every penny).  DANE adoption is far too light to even
begin to contemplate abandoning WebPKI, and we're probably two decades
away from being able to do that, by which point the quantum computer
apocalypse may have made many of the current designs moot.

> (There may not be
> many or any servers that actually end up wanting to do this, but it's not
> unreasonable to consider the possibility.)

It seems unreasonable to me, because no such signalling was for example
proposed for raw public keys or various PSK methods, etc.  And of course
the server operator can log the use of the extension and draw conclusions
about client support based on that, and the overall technology landscape.
There's no need to include this in the discussion.

> Similarly, the server may want to indicate things like:
> 
> (a) the server wants to be authenticated via DANE (yes, this is just the
>contents of the DNS)

And any client with a decent network environment can just query the
DNS directly, and never use the extension and have the record hot
in the local cache.  So there's no need for anything to complicated
here.  We just need to provide as much of the downgrade-resistance
that DNSSEC gives automatically, also to clients that for some time
will be able to do DNSSEC.

> I deliberately am not trying to come to a conclusion in this message, as I
> am not confident that I have even come up with all the potential semantics
> worth thinking about, and I think that any motion in this space should only
> be taken with WG consensus.

I think at this point hypothetical semantics is not a helpful direction.
If you have a concrete proposal, that has merit in addition to or in
place of what has been proposed, please explain.  If there are problems
or lack of clarity with what has been proposed, please explain.

I very much fear that the only possible outcome of sky's-the-limit
brainstorming is paralysis.  Please try and focus on actual proposals.

> I would love to hear others' thoughts on what I am missing from the above
> lists, reasoning for/against including protocol elements to indicate
> the listed semantics, and whether/which existing protocol elements already
> convey which of the enumerated semantics.

The proposal on the table is to a minimal form of time-limited commitment
to the extension by mutual agreem

Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics

[Salz, Rich]

Is it fair to describe the draft as enabling a trust model based on DNSSEC, 
rather than the default X.509 hierarchy and trust store which is implemented by 
default?

Please try very hard to keep the answer brief.
 

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

Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics

[Benjamin Kaduk]

On Mon, Nov 05, 2018 at 02:37:26PM +, Salz, Rich wrote:
> Is it fair to describe the draft as enabling a trust model based on DNSSEC, 
> rather than the default X.509 hierarchy and trust store which is implemented 
> by default?
> 
> Please try very hard to keep the answer brief.

In my mind that's one of the things it could do, but need not be the only one.
In https://www.ietf.org/mail-archive/web/tls/current/msg27088.html I
tried to consider the possibility for clients that currently default to
the X.509 hierarchy but also clients that use opportunistic TLS or other
default behaviors.  The analysis of the security properties of adding
DANE depends on what we use as a starting point.

-Ben

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

Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics

[Viktor Dukhovni]

[ I hope the below is short enough...]

> On Nov 5, 2018, at 9:37 AM, Salz, Rich  wrote:
> 
> Is it fair to describe the draft as enabling a trust model based on DNSSEC, 
> rather than the default X.509 hierarchy and trust store which is implemented 
> by default?
> 
> Please try very hard to keep the answer brief.

The original (-07) draft only does the job for applications that
go all in on DANE and statically skip the WebPKI.

What we're trying to do is to make DANE meaningfully available
also to existing applications where the WebPKI still rules the
roost, and where clients can only determine which servers support
DANE "opportunistically", but for that to be useful, the signal
needs some downgrade resistance.

The ultimate goal is to be able to use DANE either instead of,
or in combination with the WebPKI.  Which it is depends on the
DANE certificate usages that the application supports and server
publishes.  We're not trying to kill the WebPKI, rather we want
the *option* to use DANE when client and server opt-in.

Finally, of course, the reason for the extension is last-mile
issues with DNSSEC in captive portals and behind DNS-challenged
home routers, plus a bit of latency concern (that may be overblown,
but still seems an issue for some).

-- 
Viktor.



-- 
Viktor.

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

Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics

[Nico Williams]

On Mon, Nov 05, 2018 at 07:01:57AM -0600, Benjamin Kaduk wrote:
> Once we start talking about pinning of any sort, we move from this
> extension just being "transport some DNS records" into conveying some
> sort of additional semantics.

The I-D lost consensus over one issue.  We should resolve that issue.

There are some minor other things (like the fact that TLSA RR names
include a port number and the TLS server needs to know, or that we
shouldn't specify an RR sort order, or that the age of the chain payload
needs to be included), but they are minor by comparison.  Whether we
discuss those first or the main event is not that interesting to me, but
if we're going to make progress I think we should have time for the main
event.

Nico
-- 

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

[TLS] draft-wood-tls-external-psk-importer-00

[Subodh Iyengar]

I brought up an alternate construction in BKK for 
draft-wood-tls-external-psk-importer-00 which might have some potentially 
better properties. I didn't get time to explain then, so here it is:

One issue I think with the current construction in the draft with external psk 
is that if the client uses the external psk with a different hash function due 
to configuration error, then it turns into a fatal connection error because TLS 
endpoints are required to tear down the connections on binder mismatch. The 
client does not recover until it stops using the external psk..

An alternate approach to solve this could be to have a construction like:

[hash of (psk identity + ImportedIdentity)] [psk identity]

A server that uses the psk would perform the following steps during the 
resumption


  1.  Negotiate the cipher suite to use
  2.  If an external psk is used, strip off the first hash length of the psk 
identity where the hash length depends on the cipher suite.
  3.  Compute the hash of pskidentity + imported identity and compare it 
against (2)
  4.  If it doesn't match, don't use the PSK and fallback to full handshake..

I think this a subtle change, because if you treat this case as if you were not 
willing to use the PSK, then you can ignore the binder. This might be 
operationally easier to deploy and reason about than a hard failure.

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

Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics

[Viktor Dukhovni]

> On Nov 5, 2018, at 1:22 PM, Salz, Rich  wrote:
> 
> I need to review things some more, but FYI I believe I will say that mixing
> trust models is a bad idea, and opportunistic fallback seems both premature
> optimization and adding in the risk. I would support bringing back -07 
> semantics.

That's the trouble with "short responses", they are too short to get the key
details across.  This is NOT a simple issue that can adequately be reduced
to a couple of pithy paragraphs.

The -07 document is broken and has lost consensus.  It has a broken unilateral
client-side TOFU pinning downgrade protection mechanism, that nobody wants.
Removing it entirely severely limits the scope of the draft to much less than
was intended and was promised in the introduction.

We're not "mixing" trust models, DANE explicitly supports either augmenting
WebPKI (certificate usage 0/1) with CA or EE certificate assertions, or 
bypassing it with usages 2/3.  SMTP does 2/3 only, I would expect browsers
to look to do 0/1, which has the benefit of getting both DANE and CT, DANE
provides stronger authentication than DV cert issuances, while CT provides
some measure of auditability.

There are many problems with -07 beyond just pinning, various gaps in the
smaller design that really should be addressed.

I could write more, but then folks are liable to stop reading, I don't know
how to get past that, except by becoming an author, and finally issuing
a new version of the draft for review (~25 commits pending on github waiting
for the green light), that folks might have to actually read all the way
through... :-(

-- 
Viktor.

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

[TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)

[Viktor Dukhovni]

TL;DR:  Should TLS client abort DHE-RSA handshakes with a peer
certificate that *only* lists:

X509v3 Key Usage: 
Key Encipherment, Data Encipherment

(which one might take to mean that only RSA key exchange is allowed,
and DHE-RSA is not, for lack of the DigitalSignature bit?

[ In the unlikely case it matters, the record the certificate
  in question is self-signed, and has a DANE TLSA "3 0 1" record. ]

-- Background:

I am somewhat sympathetic to forbidding RSA key exchange when
"Key Encipherment" is not listed, in order to reduce the risk of
Bleichenbacher-type attacks, but it is not obvious at first blush
why one might the converse restriction...

The reason I ask is that the Haskell TLS library has recently added
enforcement in both directions, and I am finding some SMTP servers
with whose STARTTLS implementation my DANE scan engine no longer
interoperates.

And yet, FWIW, OpenSSL 1.1.1 continues to connect just fine.  Is
this an oversight in OpenSSL?  Overly strict enforcement in Haskell's
Network.TLS?  Should the language in RFC8446 apply also to TLS 1.2
and earlier, where no mention of "keyUsage" is to be found in the
relevant specifications?

The text in 8446 is not crystal clear on the intent.  Is keyUsage
enforcement (absent OID filters from the peer) a MUST?  A SHOULD?
A BCP?  And which directions should it apply in?  That is, does
it make sense to require RSA key transport when DHE appears to
be disallowed?

In appendix E.8 of TLS 1.3 RFC8446 

we find:

   E.8.  Attacks on Static RSA

   Although TLS 1.3 does not use RSA key transport and so is not
   directly susceptible to Bleichenbacher-type attacks [Blei98], if TLS
   1.3 servers also support static RSA in the context of previous
   versions of TLS, then it may be possible to impersonate the server
   for TLS 1.3 connections [JSS15].  TLS 1.3 implementations can prevent
   this attack by disabling support for static RSA across all versions
   of TLS.  In principle, implementations might also be able to separate
   certificates with different keyUsage bits for static RSA decryption
   and RSA signature, but this technique relies on clients refusing to
   accept signatures using keys in certificates that do not have the
   digitalSignature bit set, and many clients do not enforce this
   restriction.

In 4.2.5  we
also find:

   This document defines matching rules for two standard certificate
   extensions defined in [RFC5280]:

   -  The Key Usage extension in a certificate matches the request when
  all key usage bits asserted in the request are also asserted in
  the Key Usage certificate extension.

But that's about explicit OID filters from the peer, not a-priori
constraints.

-- 
Viktor.

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

Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics

[Paul Wouters]

On Mon, 5 Nov 2018, Salz, Rich wrote:


Is it fair to describe the draft as enabling a trust model based on DNSSEC, 
rather than the default X.509 hierarchy and trust store which is implemented by 
default?


The draft tries to enable a trust model based on DNSSEC, but due to
missing pinning, fails to deliver that.

A better way is saying the draft enables a trust model that restricts
the webpki, addressing the problems of too many unrestricted root CA
players being accepted by  TLS clients these days [provided the draft
adds a mechanism like pinning to prevent downgrade attacks]

Paul

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

Re: [TLS] draft-wood-tls-external-psk-importer-00

[Christopher Wood]

On Tue, Nov 6, 2018 at 12:56 AM Subodh Iyengar  wrote:
>
> I brought up an alternate construction in BKK for 
> draft-wood-tls-external-psk-importer-00 which might have some potentially 
> better properties. I didn't get time to explain then, so here it is:
>
> One issue I think with the current construction in the draft with external 
> psk is that if the client uses the external psk with a different hash 
> function due to configuration error, then it turns into a fatal connection 
> error because TLS endpoints are required to tear down the connections on 
> binder mismatch. The client does not recover until it stops using the 
> external psk.
>
> An alternate approach to solve this could be to have a construction like:
>
> [hash of (psk identity + ImportedIdentity)] [psk identity]
>
> A server that uses the psk would perform the following steps during the 
> resumption
>
> Negotiate the cipher suite to use
> If an external psk is used, strip off the first hash length of the psk 
> identity where the hash length depends on the cipher suite.
> Compute the hash of pskidentity + imported identity and compare it against (2)
> If it doesn't match, don't use the PSK and fallback to full handshake.
>
>
> I think this a subtle change, because if you treat this case as if you were 
> not willing to use the PSK, then you can ignore the binder. This might be 
> operationally easier to deploy and reason about than a hard failure.

Thanks for writing this down! This is certainly an interesting
proposal. That said, in cases where one might use external PSKs,
failing hard seems like a fine (and probably preferred?) outcome. I'd
be happy to hear of cases where one might want to fall back to a full
handshake.

Best,
Chris

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

Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics

[Benjamin Kaduk]

On Mon, Nov 05, 2018 at 09:54:19PM -0500, Paul Wouters wrote:
> On Mon, 5 Nov 2018, Salz, Rich wrote:
> 
> >Is it fair to describe the draft as enabling a trust model based on DNSSEC, 
> >rather than the default X.509 hierarchy and trust store which is implemented 
> >by default?
> 
> The draft tries to enable a trust model based on DNSSEC, but due to
> missing pinning, fails to deliver that.
> 
> A better way is saying the draft enables a trust model that restricts
> the webpki, addressing the problems of too many unrestricted root CA
> players being accepted by  TLS clients these days [provided the draft
> adds a mechanism like pinning to prevent downgrade attacks]

If we don't agree on what the draft is trying to do, it seems rather
difficult to attempt to claim that there is WG consensus to publish it.

This seems to suggest that we may need more precise text in the
document about what it is (and is not) trying to do.  The slides Sean
posted for the Wednesday session note that fairly early in the timeline
we thought:

Primarily aimed at making
DANE practical for HTTPS,
where last-mile considerations
on the client end are a
significant part of the adoption
barrier.

Paul, are you proposing that this would only be PKIX-{EE,CA} to the
exclusion of DANE-{EE,CA}?  (In terms of "restricts the webpki".)

Thanks,

Ben

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

Re: [TLS] draft-wood-tls-external-psk-importer-00

[Subodh Iyengar]

Ya I think failing hard depends on the use case for the external psk. For 
example if external psk is your own source of identity then ya you can't really 
fallback, however if you are using external psk as an optimization or something 
else, then falling back might be desirable.

Subodh

From: Christopher Wood 
Sent: Monday, November 5, 2018 6:56:57 PM
To: Subodh Iyengar
Cc: 
Subject: Re: [TLS] draft-wood-tls-external-psk-importer-00

On Tue, Nov 6, 2018 at 12:56 AM Subodh Iyengar  wrote:
>
> I brought up an alternate construction in BKK for 
> draft-wood-tls-external-psk-importer-00 which might have some potentially 
> better properties. I didn't get time to explain then, so here it is:
>
> One issue I think with the current construction in the draft with external 
> psk is that if the client uses the external psk with a different hash 
> function due to configuration error, then it turns into a fatal connection 
> error because TLS endpoints are required to tear down the connections on 
> binder mismatch. The client does not recover until it stops using the 
> external psk.
>
> An alternate approach to solve this could be to have a construction like:
>
> [hash of (psk identity + ImportedIdentity)] [psk identity]
>
> A server that uses the psk would perform the following steps during the 
> resumption
>
> Negotiate the cipher suite to use
> If an external psk is used, strip off the first hash length of the psk 
> identity where the hash length depends on the cipher suite.
> Compute the hash of pskidentity + imported identity and compare it against (2)
> If it doesn't match, don't use the PSK and fallback to full handshake.
>
>
> I think this a subtle change, because if you treat this case as if you were 
> not willing to use the PSK, then you can ignore the binder. This might be 
> operationally easier to deploy and reason about than a hard failure.

Thanks for writing this down! This is certainly an interesting
proposal. That said, in cases where one might use external PSKs,
failing hard seems like a fine (and probably preferred?) outcome. I'd
be happy to hear of cases where one might want to fall back to a full
handshake.

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

Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)

[Geoffrey Keating]

Viktor Dukhovni  writes:

> TL;DR:  Should TLS client abort DHE-RSA handshakes with a peer
> certificate that *only* lists:
> 
> X509v3 Key Usage: 
> Key Encipherment, Data Encipherment

Yes, because in DHE-RSA, the RSA key is used for signing, and this is
an encryption-only key.

It's much more important in the DHE-ECDSA case, because using an
encryption-only EC key for signing can lead to key compromise (IIRC).
As far as I know there's no similar attack on RSA, but I think this is
not a well-examined area.

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

Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics

[Paul Wouters]

On Mon, 5 Nov 2018, Benjamin Kaduk wrote:


The draft tries to enable a trust model based on DNSSEC, but due to
missing pinning, fails to deliver that.

A better way is saying the draft enables a trust model that restricts
the webpki, addressing the problems of too many unrestricted root CA
players being accepted by  TLS clients these days [provided the draft
adds a mechanism like pinning to prevent downgrade attacks]


If we don't agree on what the draft is trying to do, it seems rather
difficult to attempt to claim that there is WG consensus to publish it.

This seems to suggest that we may need more precise text in the
document about what it is (and is not) trying to do.  The slides Sean
posted for the Wednesday session note that fairly early in the timeline
we thought:


I havent looked at the slides yet, I didnt see anything last time I
looked to see what te Wednesday slot would be like.


   Primarily aimed at making
   DANE practical for HTTPS,
   where last-mile considerations
   on the client end are a
   significant part of the adoption
   barrier.

Paul, are you proposing that this would only be PKIX-{EE,CA} to the
exclusion of DANE-{EE,CA}?  (In terms of "restricts the webpki".)


No. The restriction of webpki can be to restrict to 0 webpki root CA's
and instead restrict to an EE cert or public key, as per TLSA usage selectors.

I was trying to be as short as possible for Rich, and keep the focus on
ensuring the draft gains support for restricting, for which we currently
have one proposal (pinning).

Paul

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

Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics

[Viktor Dukhovni]

> On Nov 5, 2018, at 10:27 PM, Benjamin Kaduk  wrote:
> 
> This seems to suggest that we may need more precise text in the
> document about what it is (and is not) trying to do.  The slides Sean
> posted for the Wednesday session note that fairly early in the timeline
> we thought:
> 
>Primarily aimed at making
>DANE practical for HTTPS,
>where last-mile considerations
>on the client end are a
>significant part of the adoption
>barrier.
> 
> Paul, are you proposing that this would only be PKIX-{EE,CA} to the
> exclusion of DANE-{EE,CA}?  (In terms of "restricts the webpki".)

I think that deciding which DANE usage are most appropriate for
browsers is up to the folks who think deeply about Web browsers
and Web servers, and I would not presume to tell them which model
they should find more attractive.  My expectation would be that
they would be more comfortable with PKIX-{EE,TA}, because that
gives both the strongest security guarantee and preserves
certificate transparency as an option.

In SMTP, I got consensus for just specifying DANE-{EE,TA}, but
for HTTP I can well imagine a different outcome.  The key reason
for the divergence is that SMTP security depends critically on
the integrity of MX records, so if you DNS is compromised PKI
does not help much.

HTTP does not use MX, SRV or similar indirection, so the analysis
comes out differently.

This draft will not define a single approach for all applications,
that's up to the various application area specialists to figure out.

-- 
-- 
Viktor.

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

Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics

[Benjamin Kaduk]

On Tue, Nov 06, 2018 at 12:01:52AM -0500, Paul Wouters wrote:
> On Mon, 5 Nov 2018, Benjamin Kaduk wrote:
> 
> >>The draft tries to enable a trust model based on DNSSEC, but due to
> >>missing pinning, fails to deliver that.
> >>
> >>A better way is saying the draft enables a trust model that restricts
> >>the webpki, addressing the problems of too many unrestricted root CA
> >>players being accepted by  TLS clients these days [provided the draft
> >>adds a mechanism like pinning to prevent downgrade attacks]
> >
> >If we don't agree on what the draft is trying to do, it seems rather
> >difficult to attempt to claim that there is WG consensus to publish it.
> >
> >This seems to suggest that we may need more precise text in the
> >document about what it is (and is not) trying to do.  The slides Sean
> >posted for the Wednesday session note that fairly early in the timeline
> >we thought:
> 
> I havent looked at the slides yet, I didnt see anything last time I
> looked to see what te Wednesday slot would be like.
> 
> >   Primarily aimed at making
> >   DANE practical for HTTPS,
> >   where last-mile considerations
> >   on the client end are a
> >   significant part of the adoption
> >   barrier.
> >
> >Paul, are you proposing that this would only be PKIX-{EE,CA} to the
> >exclusion of DANE-{EE,CA}?  (In terms of "restricts the webpki".)
> 
> No. The restriction of webpki can be to restrict to 0 webpki root CA's
> and instead restrict to an EE cert or public key, as per TLSA usage selectors.
> 
> I was trying to be as short as possible for Rich, and keep the focus on
> ensuring the draft gains support for restricting, for which we currently
> have one proposal (pinning).

Okay, thanks.

-Ben

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

[TLS] I-D Action: draft-ietf-tls-dtls13-30.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-30.txt
Pages   : 51
Date: 2018-11-05

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.  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-30
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-30

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


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