On Wed, Jul 15, 2015 at 1:58 PM, Deirdre Connolly
wrote:
>
>> So, should it stay or should it go now? Opinions?
>
> +1 that sect571r1 be removed.
I also believe that it should be removed.
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imp
ted by 1RTT maximum there).
I think we quite possibly didn't understand the concern here. Could
you spell it out at more length?
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
he property we're looking for here, isn't
> it?
I don't believe that there's any reason to include the sequence number in
the AD input of an AEAD. I think that an empty AD for TLS would be fine now
that the content type is encrypted. (Not that I deeply care either way.)
Che
s, would have to authenticate their
nonces internally. RFC 5297 basically says that already
(https://tools.ietf.org/html/rfc5297#section-3). That might mean that
the nonce is prepended to the AD inside the AEAD abstraction, but that
wouldn't be TLS's concern.
Cheers
AGL
--
Adam Langl
or Transport Layer
> Security (TLS)
> Authors : Adam Langley
> Wan-Teh Chang
> Nikos Mavrogiannopoulos
> Joachim Strombergson
> Simon Josefsson
> Fi
alue for the TLS version in use.
Saving a single Poly1305 block per record isn't a big deal and it
looks like we'll get it anyway with TLS 1.3. So, for the moment, I'm
not planning on adding anything to that effect.
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www
and is being addressed
elsewhere in future versions of TLS.
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
he 64-bit record sequence number is serialized as an 8-byte,
big-endian value and padded on the left with four 0x00 bytes."
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
development,
supported this via the CREDENTIAL frame. That also avoided a confused
deputy problem: with connection pooling over HTTP/2, there seems to be
a risk of confusion about which requests are authenticated with which
client certificate.
Cheers
AGL
--
Adam Langley a
; in -01 and changed one key length to bits, but
otherwise I think each use is about right.
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
8 (30),
// Signature curves.
eddsa_ed25519 (31), eddsa_ed448 (32),
I'd like to request that these code points for early assignment.
[1]
https://mailarchive.ietf.org/arch/msg/ietf-announce/MWmqSxBZxWPEt6glXJZvXg5lMS4
[2] https://tlswg.github.io/tls13-spec/#rfc.section.6.3.2.2
Cheers
AGL
--
Ad
ts are not since the
signature work in CFRG is ongoing. I'll leave that to the chairs.
(While we would use early code-point assignments for X25519/X448 we
don't have plans for using the signature code points at this time.)
Cheers
AGL
--
Adam Langley a...@imperial
not sure that a slower, software implementation of SHA-256 would be a
big problem.
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
mentations SHOULD reject inputs with the high-bit set.
I think that should be dropped. The X25519 function is specified in
terms of bytes in draft-irtf-cfrg-curves and I think the TLS spec
should just use that draft.
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperial
about things like this. I think TLS should handle
the byte strings opaquely so that we have uniform behaviour for
X25519/X448 and only a single place where it needs to be tested. The
behaviour of X25519/X448 for non-reduced values is also specified in
the CFRG document.
Cheers
A
erhaps, even achievable for a spec).
So at this point I'd like to nail down the existing behaviour with
tests, try to make it uniform across most implementations, and try to
avoid other specs interpreting the byte strings.
[1] http://cr.yp.to/ecdh/curve25519-20060
On Wed, Dec 30, 2015 at 4:03 PM, Brian Smith wrote:
> I think it is a good idea to implement the session hash extension, in
> general. However, I think it is a bad idea to prescribe it as the solution
> for this particular problem because:
>
> 1. draft-irtf-cfrg-curves-11, in sections 6.1 and sec
ero check should (or must) be done because I think that it should
be done in general.
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
their thing no matter what the
standard says, so I wouldn't have an objection to putting a "SHOULD"
in the spec for RFC 6979. I suspect that adherence would be poor,
however. As for using that RFC over what I came up with or anything
else: at least RFC 6979 has been written down alr
igin confusion attacks[2]
etc.)
Cheers
AGL
[1] https://tools.ietf.org/html/draft-ietf-tokbind-protocol-04
[2] http://antoine.delignat-lavaud.fr/doc/www15.pdf
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Tue, Dec 19, 2017 at 5:07 AM, Stephen Farrell
wrote:
> I'm not sure I agree renumbering is the right reaction,
> though I don't object to that. This could be a case where
> it's overall better that those specific devices suffer
> breakage, and hopefully then do get firmware updated to
> suppor
e cited motivation
(https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-00) is
DTLS-only. Probably this draft needs to be too.
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
htt
ernel might keep retransmitting some part of the
half-connection's data that doesn't include the connection id at all.)
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
ht
.3, which presumably LTS clients would not, so maybe there's
something you could use there.
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
value in
https://tools.ietf.org/html/draft-ietf-quic-tls-12#section-9.2, authored by
Sean :)
So we have a triple collision on 26, albeit with one candidate being much
more official.
Sean: do you want to kick quic_transport_parameters off 26 then? Move it to
a high, random value until assigned?
--
ues with concurrent applications and I offer
0xbb31 as a high-quality, random number. Since we had a triple
collision in this case, random-assignment's virtues are currently
particularly clear.)
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
48-bit RSA minimum
in the client as the CA/BF rules suffice for the vast, vast majority
of users.
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
y clients getting established in the mean
time. We are painfully aware that limiting our server-side deployment
allowed this bug to become established and, while we did it to ease
middlebox issues, it may have been a mistake.
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.i
265024
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Tue, Jul 23, 2019 at 5:23 PM Watson Ladd wrote:
> Suppose the following sequence of events happen:
>
> 1: A CA uses a new intermediate for reasons (no longer cross-signing, etc.)
> 2: A site gets a certificate from the new intermediate.
> 3: An older firefox version connects and thinks it know
On Tue, Jul 23, 2019 at 3:09 PM Chris Inacio wrote:
> I really want the savings on the wire that TLS flags extension provides – and
> so I think it’s really good for the future cTLS but I’m not sure when I get
> to use it in TLS 1.3 negotiation. It goes in the clientHello message, but
> how wi
On Mon, Nov 11, 2019 at 11:33 AM Christopher Wood
wrote:
> The adoption call is now (belatedly) finished. At this time, there's not
> enough interest to take this on as a WG item. We encourage further
> discussion on the list, perhaps based on subsequent draft updates, and will
> revisit adoption
s://github.com/openssl/openssl/blob/OpenSSL_1_0_1-stable/ssl/t1_lib.c#L1066
– note that the data pointer is not updated.
[3] https://tools.ietf.org/html/rfc4366#section-3.1
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
__
On Thu, Mar 3, 2016 at 10:56 AM, Eric Rescorla wrote:
> Note: it's already the case that it's forbidden to send >1 of any given type
> of name. NSS does not presently enforce this rule but will do so soon.
(We have enforced that for a while without issues.)
Cheers
AGL
her than a new SNI
type. Additionally, I'm suggesting that, in general, it's a good idea
to avoid nesting extension-like structures inside an extension in
favour of adding top-level extensions as needed.
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
On Wed, Mar 16, 2016 at 6:14 PM, Paterson, Kenny
wrote:
>>provokes me to bring it up. Here's the crux of it; is it really a
>>security win to recommend the AEAD cipher suites for TLS 1.2 users?
I'm skeptical about the benefit of padding to 16 bytes. While it does
increase the size classes in your
;s a lot of work to do it
right and it's unclear that we would be able to get a useful mass of
devices supporting such a scheme. The mostly likely outcome seems to
be that we would end up with a complex addition that's rarely used and
thus doesn't justify the cost.
Chee
mple code for
all the vendors, deal with the resulting bugs in implementations and
many smaller things besides.
That's not to say that we wouldn't be willing to put the effort in,
but the demand hasn't been evinced yet.
Cheers
AGL
--
Adam Langley a...@imperialviole
to the padding extension
(RFC 7685).
On the other hand, we've seen what's happened to the version field,
which is moving too slowly to resist rusting.
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS
On Thu, Aug 18, 2016 at 11:55 AM, David Benjamin
wrote:
> It seems desired_minimum_receive_generation can only be
> current_receive_generation or current_receive_generation + 1. In that
> case, a boolean should be sufficient and saves 7 bytes.
>
Given that simplification, is there a purpose for
On Thu, Aug 18, 2016 at 12:20 PM, Keith Winstein
wrote:
> Yes, you need current_receive_generation, or something like it, to get
> P3. This is the subject of our PR #426/580.
>
The KeyUpdate messages are encrypted and thus sequenced with all the
application data. Apart from the Heartbeat message
On Thu, Aug 18, 2016 at 1:36 PM, Keith Winstein
wrote:
> On the value of P3, I think you're giving us a crimped reading. We
> gave three use cases in Berlin and in my email:
>
I think I was because I hadn't seen your Berlin presentation. But I'm still
going to hijack this thread and ask you to e
k that
IoTish devices would care this much about doing the right thing, although I
suspect we're more likely to get more fodder for Matthew Garrett (
https://mjg59.dreamwidth.org/43486.html).
I would still tend towards not including the generation because I don't
believe that it's going to be used. But if, in a blaze of optimism, people
think it will, I'm not going to be too upset.
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
d keys outstanding,
> but these cannot be used to produce the write keys. However, this probably
> isn't simpler than just running two ladders if we think this is important.
That works but I agree that splitting the ladders is nicer and I think
that we should do
On Sun, Sep 25, 2016 at 2:06 PM, Henrick Hellström wrote:
> Have you noticed that BoringSSL seems to abort handshakes with an
> illegal_parameter alert, if the server certificate uses the standard
> compliant (albeit highly unusual) DER encoding of NULL OPTIONAL as the empty
> string, instead of t
irically has very good
compatibility and we don't like adding flexibility without good
reason.
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
27;d hope
that a default would work for the vast majority of TLS 1.3 users.
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Wed, Nov 9, 2016 at 11:42 AM, Martin Rex wrote:
> in reality, the Google servers perform pathological fragmentation
> of the AppData and use a whooping 36 TLS records for the response
> (curiously no TLS AppData record split between header and body).
>
At the beginning of a connection we aim
On Fri, Nov 18, 2016 at 7:49 AM, Will Serumgard
wrote:
> At this point it is a little late to change. I say stay with TLS1.3. As
> some others pointed out maybe we can make a jump in the next version.
>
Renumbering SSL 3.1 as TLS 1.0 was a mistake in the first place, but I
don't believe that cha
On Thu, Dec 8, 2016 at 10:56 AM, Eric Rescorla wrote:
> +1
>
I'm not sure whether I could as an independent voice on this topic, but I
strongly support adoption of this draft.
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperia
.org/doc/draft-green-tls-static-dh-in-tls13/
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Thu, Dec 29, 2016 at 11:28 AM, Martin Rex wrote:
> First of all, forward secrecy is equally defeated by TLS session caching
> (traditional as well as session tickets), and the effect of rfc5077
> TLS session tickets is likely at least a magnitude worse--and cannot
> be "fixed" by clients purgin
On Thu, Dec 29, 2016 at 11:08 AM, Eric Rescorla wrote:
>> >> As an individual, I'd be in favour of this change but reading
>> >> over [1], section 5, I wondered if we'd analysed the effects of
>> >> 0rtt/replayable-data with that kind of cross-domain re-use in mind?
>> >> The situation being where
> such a mechanism probably isn't going to have much effect on the
> latter intentional badness.
I much prefer people who are going to backdoor their TLS to use DH as
the mechanism rather than something less detectable. I don't expect a
MUST NOT will slow them down at all. I ju
On Mon, Jan 2, 2017 at 11:43 AM, Yoav Nir wrote:
> I’m assuming that the server generates private keys and saves them to a file
> along with the time period that they were used, and another machine in a
> different part of the network records traffic. It’s not so much that the
> clocks need to be
On Mon, Jan 2, 2017 at 3:57 PM, Adam Langley wrote:
> I don't expect that those who want to intercept TLS connections will
> see a MUST NOT and go do something else. Rather I think they should
> understand that TLS isn't supposed to be intercepted and, if they want
> to
On Fri, Jan 20, 2017 at 11:29 AM, Brian Smith wrote:
> RSA PSS with a zero-length salt is a deterministic,
> subliminal-channel-free signature scheme. It is one of the few
> signature schemes that structurally prevent an HSM from directly
> leaking (parts of) the private key in an undetectable way
On Mon, Jan 30, 2017 at 1:41 PM, Scott Fluhrer (sfluhrer)
wrote:
> My question: in TLS 1.3, if the client inserts an extension of a type that
> the server does not recognize, how must the server behave? Is it required
> that the server just ignore the extension, or can it take some other action
>
but I hope to do so in the coming weeks.)
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
number in rcx: leaq maskOffset(%rax),
%rbx ; xorq (%rbx), %rcx ; movbeq %rcx, 4(%rdi)
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
en at some point.
So which are we talking about adopting? While drafts evolve during the WG
process, there's a big gap between the two ideas and I'd support one but
not the other.
Thus I'm not sure that the draft is ready for an adoption call at this time.
Cheers
AGL
On Fri, Aug 4, 2017 at 11:03 AM, Tony Arcieri wrote:
> On Fri, Aug 4, 2017 at 10:39 AM, Adam Langley
> wrote:
>
>> If it wants to be a technical document, then the draft includes two very
>> different designs with a note saying that one will be chosen at some point.
>&
ventually we have to pick one, right? I feel that drafts are generally
more opinionated before a call for adoption, although the chairs might well
feel that the design-space span is this document is focused enough already.
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialv
e willing to review/comment on the draft before 20170818. If you
> object to its adoption, please let us know why.
>
I support adoption.
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
emonstrates
the sort of change in thinking that is needed, but that we need to go
further.
Cheers
AGL
--
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
65 matches
Mail list logo
