On Thu, Aug 27, 2015 at 1:18 PM, Eric Rescorla wrote:
>
>
> On Thu, Aug 27, 2015 at 2:14 AM, Viktor S. Wold Eide <
> viktor.s.wold.e...@gmail.com> wrote:
>
>> On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla wrote:
>>
>>>
>>>
>>> TLS 1.3 encrypts both the client's and server's certificates alread
On Fri, Aug 28, 2015 at 04:27:28PM +0200, Viktor S. Wold Eide wrote:
> > I don't think this matches most TLS use cases very well, since the client
> > generally isn't authenticated at all, so there's no point in the server
> > progressively
> > revealing more.
> >
> >
> Although the client general
Having discussions through github is a really bad idea. Mail formatting can
get even more mangled, and we lose the IETF mail archive and participation. I
think we need to be more diligent and avoid doing that.
> There's just no statement of what to do when it's required and not given.
That's
On Friday, August 28, 2015 11:08:35 am Salz, Rich wrote:
> Having discussions through github is a really bad idea.
You're right. I posted a stupidly long side-note in there. I intended to bring
it to the list too, which I'll do now.
On Friday, August 28, 2015 10:49:33 am Viktor Dukhovni wrote:
>
On Fri, Aug 28, 2015 at 12:13:03PM -0400, Dave Garrett wrote:
> The idea I had the other day is that we can technically do SNI encryption
> with the current TLS 1.3 draft, as-is. All that needs to really be done
> is stick it in a 0-RTT EncryptedExtensions, preferably only when the server
> specif
> > The idea I had the other day is that we can technically do SNI
> > encryption with the current TLS 1.3 draft, as-is.
Yeah, some of us talked about this in Dallas, etc., when the "semi-static EDH
key" really started to take hold. I showed slides at the interim before IETF
90 in Toronto, that
On Friday, August 28, 2015 12:33:31 pm Salz, Rich wrote:
> > And how often will the same client visit multiple servers at the same
> > transport address?
>
> Anyone who visits sites hosted by a CDN. And, I suspect, many large portals.
How's it done with IPv6, generally? Are there setups where ev
> How's it done with IPv6, generally?
We don't see address-sharing with IPv6, although I wonder if that will change
when the routing tables get too big. :) We also don't see anyone willing to go
IPv6-only; it's not close to universal enough yet.
> I agree that it's a lot of effort for relative
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security Working Group of the
IETF.
Title : The Transport Layer Security (TLS) Protocol Version
1.3
Author : Eric Rescorla
Folks,
I've just posted draft-08 which includes the changes discussed on-list
to require digital signatures from the client even if you are re-using
a previous configuration in 0-RTT (per WG discussion).
This version also includes a bunch of other cleanup, as detailed below:
- Remove support for
https://github.com/tlswg/tls13-spec/issues/233
Folks,
We presently have some support for DH_anon cipher suites. I agree that this
is a useful use case, but it's yet another mode.
I would like to suggest that we instead deprecate it and instead always use
Raw Public Key mode (https://tools.ietf.o
I actually had this in my old a la carte proposal. Here's the relevant section
posted separately, unedited, except for keeping the current list of RFCs with
anon that weren't in that proposal:
https://github.com/tlswg/tls13-spec/compare/master...davegarrett:unauthenticated
Dave
__
This seems fine to me, though I'll note that 7250 only really saves
you space when it comes down to it. You can wrap your raw public key
in a certificate, just like we do in WebRTC, and then you don't need
7250 support in your library. Noting you can only do any of these
variations in a context w
On Fri, Aug 28, 2015 at 11:07 AM, Martin Thomson
wrote:
> This seems fine to me, though I'll note that 7250 only really saves
> you space when it comes down to it. You can wrap your raw public key
> in a certificate, just like we do in WebRTC, and then you don't need
> 7250 support in your libra
On Fri, Aug 28, 2015 at 11:07:02AM -0700, Martin Thomson wrote:
> This seems fine to me, though I'll note that 7250 only really saves
> you space when it comes down to it. You can wrap your raw public key
> in a certificate, just like we do in WebRTC, and then you don't need
> 7250 support in you
On Fri, Aug 28, 2015 at 11:33 AM, Viktor Dukhovni
wrote:
> On Fri, Aug 28, 2015 at 11:07:02AM -0700, Martin Thomson wrote:
>
> > This seems fine to me, though I'll note that 7250 only really saves
> > you space when it comes down to it. You can wrap your raw public key
> > in a certificate, just
On 28 August 2015 at 11:36, Eric Rescorla wrote:
> How does anon-DH have different privacy properties than doing
> RFC 7250 with a fresh signing key for each connection?
Or what we do in WebRTC, which uses a certificate that has no good
information in it?
On 28 August 2015 at 11:33, Viktor Dukhovni wrote:
> On the other hand, it allows servers to detect that a
> client is not planning to authenticate the server, which has forensic
> value, and can be used to grant appropriately restricted access.
I think that these are potentially useful properti
Hi all,
DSA is supported in the previous versions of TLS. It would be nice if someone
who uses DSA can use it in TLS 1.3 as well.
People who don't use DSA, then they don't use DSA. People who use DSA right, it
should be fine for them to use DSA.
I don't see a convincing reason to remove sup
"Or what we do in WebRTC, which uses a certificate that has no good
information in it?”
+1. Anxiously waiting for response on this, as I am currently helping
non-profit groups build a private and secure P2P Messaging System using WebRTC,
which of course utilizes encrypted P2P connection between
On Fri, Aug 28, 2015 at 07:17:39PM +, Dang, Quynh wrote:
> Hi all,
>
> DSA is supported in the previous versions of TLS. It would be nice
> if someone who uses DSA can use it in TLS 1.3 as well.
Well, at least for the web, DSA is no longer an option because
major browsers have dropped support
Quynh,
You must have been reading my mind because I’m working on something that will
help Joe and I judge consensus on what to do about DSA.
Let’s hold off on this thread for a bit while I get that msg together.
spt
On Aug 28, 2015, at 15:17, Dang, Quynh wrote:
> Hi all,
>
> DSA is support
On Fri, 28 Aug 2015 19:17:39 +
"Dang, Quynh" wrote:
> DSA is supported in the previous versions of TLS. It would be nice if
> someone who uses DSA can use it in TLS 1.3 as well.
Do you have a plausible reason why you want to use DSA? Or is this
purely a theoretical consideration?
Because thi
On Friday, August 28, 2015, Dang, Quynh wrote:
>
> People who don't use DSA, then they don't use DSA. People who use DSA
> right, it should be fine for them to use DSA.
>
Can you name one of these people? If not, you seem to be arguing for
including legacy protocols with no real-world use case in
On Fri, Aug 28, 2015 at 01:27:57PM -0700, Tony Arcieri wrote:
> On Friday, August 28, 2015, Dang, Quynh wrote:
> >
> > People who don't use DSA, then they don't use DSA. People who use DSA
> > right, it should be fine for them to use DSA.
> >
> Can you name one of these people? If not, you seem t
On Friday, August 28, 2015 04:21:53 pm Hanno Böck wrote:
> On Fri, 28 Aug 2015 19:17:39 +
> "Dang, Quynh" wrote:
> > I don't see a convincing reason to remove support of DSA in TLS 1.3.
>
> The reason is avoiding feature bloat. I think it makes a lot of sense
> to question the support of feat
On Fri, Aug 28, 2015 at 1:59 PM, Dave Garrett
wrote:
> I'd rather just declare it obsolete and no longer permitted to avoid the
> attack surface and complexity, and I get an impression that this is a
> common opinion in the WG.
+1. Most people seem to oppose its inclusion, and the people asking
On 8/28/15, Dang, Quynh wrote:
> Hi all,
>
>
> DSA is supported in the previous versions of TLS. It would be nice if
> someone who uses DSA can use it in TLS 1.3 as well.
>
>
> People who don't use DSA, then they don't use DSA. People who use DSA right,
> it should be fine for them to use DSA.
>
>
On Friday, August 28, 2015 08:41:23 pm Jacob Appelbaum wrote:
> What do you suggest for the construction of the k value in DSA?
https://tools.ietf.org/html/rfc6979#section-3.2 ?
Also, we still have ECDSA, so the 'k' issue isn't going away. Should we cite
this RFC?
Dave
___
>
> Also, if DSA was to be supported, one would need to specify how to
> determine the hash function (use of fixed SHA-1 doesn't fly). And
> 1024-bit prime is too small.
>
FIPS186-4 (http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf)
partially remediates the issue. DSA now includes 2048 and
Jeffrey Walton writes:
> >
> > Also, if DSA was to be supported, one would need to specify how to
> > determine the hash function (use of fixed SHA-1 doesn't fly). And
> > 1024-bit prime is too small.
> >
> FIPS186-4 (http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf)
> partially remediat
> "ECDSA can be smaller, faster, and more secure all at once; and if you don't
> like ECDSA or want an alternative, there's RSA."
>
Isn't that a step backward reverting to RSA?
Ron F. Del Rosario
CONFIDENTIALITY NOTICE: This e-mail and any files attached may con
32 matches
Mail list logo
