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
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 restr
> 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:
>
>Primaril
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
player
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-
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
__
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 tri
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 co
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, fail
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 DigitalSignatur
> 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.
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 u
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 tha
[ 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
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 th
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
htt
> 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, otherwi
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 t
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) numbe
19 matches
Mail list logo
