Re: [TLS] TLS 1.3 multiple session tickets from the client?
On Wed, 2018-05-16 at 11:30 +0200, Ander Juaristi wrote: > El 2018-05-11 09:05, Nikos Mavrogiannopoulos escribió: > > On Thu, 2018-05-10 at 11:46 -0400, Viktor Dukhovni wrote: > > > > > > Good to know. Does any implementation other than OpenSSL support > > > external PSKs? How do you distinguish between external PSKs and > > > resumption PSKs? > > > > gnutls does. For external PSKs It checks for ticket age being zero > > and > > the username/identity within acceptable bounds. > > Hey Nikos, > > I remember we had this discussion, but wanted to transfer it to the > list > as even though I believe that approach > will work almost always, by reading the current draft my > understanding > is that being the ticket age zero is no more than a hint > that it *might* be a PSK. > > What's wrong with trying to decrypt it first and then if decryption > fails treat it as an external PSK and look up > its identity in the database? GnuTLS encrypts the tickets with EtA > so > with "decrypt" I mean checking the MAC first, > and then decrypting. Isn't this a stronger check? Decrypting a ticket may not always be possible. For example, server keys may get rotated, or a server may receive key which were destined for another server in the pool. > Another option to remove some ambiguity out of here would just be to > change the draft to say that externally set PSKs > MUST have a ticket age of zero (rather than SHOULD). This way a > server > can instantly recognize an external PSK. A real > ticket can never have an obfuscated ticket age of zero, right? Or it > can? I think that ticket age could be zero even for non-preshared keys (not very likely though). A field which could potentially be used to distinguish tickets is the key_name of an rfc5077 formatted ticket. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS DNSSEC chain consensus text, please speak up...
Making things more complicated with no obvious benefit just makes things more complicated. I oppose adding two bytes for some nebulous future purpose. -Tim > -Original Message- > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of James Cloos > Sent: Wednesday, May 16, 2018 6:20 PM > To: Ted Lemon > Cc: > Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... > > > "TL" == Ted Lemon writes: > > TL> Melinda made a pretty serious technical objection. Your response is not > TL> responsive to her objection. She explicitly said that her objection was > TL> not the two bytes. > > I don't see anything in her note today which is a technical objection. > > And I've seen no useful or reasonable objections to Viktor's suggestion. > > The sixteen bit field harms no one, and when defined and used provides > significant benefit to many. > > -JimC > -- > James Cloos OpenPGP: 0x997A9F17ED7DAEA6 > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS DNSSEC chain consensus text, please speak up...
> On May 17, 2018, at 19:44, Tim Hollebeek wrote: > > Making things more complicated with no obvious benefit just makes things > more complicated. > > I oppose adding two bytes for some nebulous future purpose. The consequence of this opinion would be this: https://tools.ietf.org/html/draft-asmithee-tls-dnssec-downprot-00 Which is a lot of complexity for one TLS extension to define the behaviour of another TLS extension. And it still adds two bytes in the 2nd extension. So if you believe more simplicity is better, then you made the wrong choice. Paul ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS DNSSEC chain consensus text, please speak up...
I’m actually fine with that. You have to consider P_{extension implemented and
used}.
Different people will disagree about the value of P.
-Tim
From: Paul Wouters [mailto:p...@nohats.ca]
Sent: Thursday, May 17, 2018 8:18 PM
To: Tim Hollebeek
Cc: James Cloos ; Ted Lemon ;
Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up...
On May 17, 2018, at 19:44, Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote:
Making things more complicated with no obvious benefit just makes things
more complicated.
I oppose adding two bytes for some nebulous future purpose.
The consequence of this opinion would be this:
https://tools.ietf.org/html/draft-asmithee-tls-dnssec-downprot-00
Which is a lot of complexity for one TLS extension to define the behaviour of
another TLS extension. And it still adds two bytes in the 2nd extension.
So if you believe more simplicity is better, then you made the wrong choice.
Paul
smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] I-D Action: draft-ietf-tls-record-limit-03.txt
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 : Record Size Limit Extension for Transport Layer Security (TLS) Author : Martin Thomson Filename: draft-ietf-tls-record-limit-03.txt Pages : 8 Date: 2018-05-17 Abstract: An extension to Transport Layer Security (TLS) is defined that allows endpoints to negotiate the maximum size of protected records that each will send the other. This replaces the maximum fragment length extension defined in RFC 6066. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-record-limit-03 https://datatracker.ietf.org/doc/html/draft-ietf-tls-record-limit-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-record-limit-03 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] I-D Action: draft-ietf-tls-record-limit-03.txt
Just rolling up all the changes discussed in final reviews. On Fri, May 18, 2018 at 10:58 AM wrote: > 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 : Record Size Limit Extension for Transport Layer Security (TLS) > Author : Martin Thomson > Filename: draft-ietf-tls-record-limit-03.txt > Pages : 8 > Date: 2018-05-17 > Abstract: > An extension to Transport Layer Security (TLS) is defined that allows > endpoints to negotiate the maximum size of protected records that > each will send the other. > This replaces the maximum fragment length extension defined in RFC > 6066. > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-record-limit-03 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-record-limit-03 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-record-limit-03 > 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 mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS DNSSEC chain consensus text, please speak up...
And to be clear, it's not that nobody is going to implement the extension
(it's already been done in an IETF hackathon and elsewhere), the work on
the extension was funded by Mozilla, and there's been an outstanding
request for this in Bugzilla. What's not being implemented is the proposed
changes.
But, it's clear that those guys don't intend to compromise and we're going
to be deadlocked pretty much forever unless someone does something. That's
not going to be Viktor and it's not going to be the chairs, so I guess it's
me.
Melinda
On Thu, May 17, 2018, 16:20 Tim Hollebeek
wrote:
> I’m actually fine with that. You have to consider P_{extension
> implemented and used}.
>
>
>
> Different people will disagree about the value of P.
>
>
>
> -Tim
>
>
>
> *From:* Paul Wouters [mailto:p...@nohats.ca]
> *Sent:* Thursday, May 17, 2018 8:18 PM
> *To:* Tim Hollebeek
> *Cc:* James Cloos ; Ted Lemon ; <
> tls@ietf.org>
> *Subject:* Re: [TLS] TLS DNSSEC chain consensus text, please speak up...
>
>
>
>
>
> On May 17, 2018, at 19:44, Tim Hollebeek
> wrote:
>
> Making things more complicated with no obvious benefit just makes things
> more complicated.
>
> I oppose adding two bytes for some nebulous future purpose.
>
>
>
> The consequence of this opinion would be this:
>
>
>
> https://tools.ietf.org/html/draft-asmithee-tls-dnssec-downprot-00
>
>
>
> Which is a lot of complexity for one TLS extension to define the behaviour
> of another TLS extension. And it still adds two bytes in the 2nd extension.
>
>
>
> So if you believe more simplicity is better, then you made the wrong
> choice.
>
>
>
>
>
> Paul
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS DNSSEC chain consensus text, please speak up...
I think there’s room for two people in front of the steamroller. And I have a
towel. How many votes does that get me?
-Tim
From: Melinda Shore [mailto:melinda.sh...@nomountain.net]
Sent: Thursday, May 17, 2018 9:21 PM
To: Tim Hollebeek
Cc: Paul Wouters ;
Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up...
And to be clear, it's not that nobody is going to implement the extension (it's
already been done in an IETF hackathon and elsewhere), the work on the
extension was funded by Mozilla, and there's been an outstanding request for
this in Bugzilla. What's not being implemented is the proposed changes.
But, it's clear that those guys don't intend to compromise and we're going to
be deadlocked pretty much forever unless someone does something. That's not
going to be Viktor and it's not going to be the chairs, so I guess it's me.
Melinda
On Thu, May 17, 2018, 16:20 Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote:
I’m actually fine with that. You have to consider P_{extension implemented and
used}.
Different people will disagree about the value of P.
-Tim
From: Paul Wouters [mailto:p...@nohats.ca ]
Sent: Thursday, May 17, 2018 8:18 PM
To: Tim Hollebeek mailto:tim.holleb...@digicert.com> >
Cc: James Cloos mailto:cl...@jhcloos.com> >; Ted Lemon
mailto:mel...@fugue.com> >; mailto:tls@ietf.org> > mailto:tls@ietf.org> >
Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up...
On May 17, 2018, at 19:44, Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote:
Making things more complicated with no obvious benefit just makes things
more complicated.
I oppose adding two bytes for some nebulous future purpose.
The consequence of this opinion would be this:
https://tools.ietf.org/html/draft-asmithee-tls-dnssec-downprot-00
Which is a lot of complexity for one TLS extension to define the behaviour of
another TLS extension. And it still adds two bytes in the 2nd extension.
So if you believe more simplicity is better, then you made the wrong choice.
Paul
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] Review of draft-asmithee-tls-dnssec-downprot-00
Hi Alan and Alan, Thanks for writing this draft. Even though the intent here is abundantly clear and this email risks me being drawn into the toxic mess of the related discussion, I found this draft to provoke an interesting thought. Though the current design is for a two octet commitment that narrowly addresses one particular extension, it seems that - like the must-staple design - there is an opportunity here. We have potential downgrade attacks on a range of extensions, not just the identified one. For instance, failing to provide the extended master secret extension represents a fairly significant regression in capabilities that could be indicative of an attack. The same for renegotiation info, SCT, and others. I thought supported_versions might be a valid use, but I'm not 100% sure there. The extension could reference itself though. A commitment to continue to provide a particular feature - as identified via its extension - would be a potentially useful capability. Of course, this would need to squarely address the potential for a service to take itself out in the way that such commitments tend to. It also needs to address the scope of the commitment in more than just time. This isn't trivial when you consider that a server can be considered valid for multiple identities. The current draft doesn't really do either topic justice. Having this indicator expire when you get an authenticated denial of existence seems odd. Why not just update the lifetime when the connection is successful unconditionally? Finally, I don't see any value in the "if you use that then you must use this" text in the draft, but that's likely just a consequence of the other discussion. Cheers, Martin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
