Y/DS chains).
Yup, exactly. Thanks.
Melinda
--
Melinda Shore
No Mountain Software
melinda.sh...@nomountain.net
"Software longa, hardware brevis."
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
tension but opted not to. The
one advantage of an X.509 extension would have been that it wouldn't
require protocol changes, but it still would have required modifying
both the server and the endpoint.
Melinda
--
Melinda Shore
No Mountain Software
melinda.sh...@nomountain.net
"S
the performance improvement over
existing redirect models is marginal, there may be some
unpleasant middlebox interactions, and it would require
API changes. The cost/benefit tradeoff isn't favorable,
on balance.
Melinda
--
Melinda Shore
No Mountain Software
melinda.sh...@nomountain.net
Hi, all:
We haven't been pushing on this because we recognize that getting
TLS 1.3 published is top priority, but we've got a new version
posted
(https://tools.ietf.org/html/draft-shore-tls-dnssec-chain-extension-02)
that addresses many of the concerns raised both here and on the DANE
mailing l
ussion, even
in passing, and if I recall correctly, no drafts and no agenda
time in meetings.
Melinda
--
Melinda Shore
melinda.sh...@nomountain.net
Software longa, hardware brevis
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On 6/25/23 9:21 AM, Soni L. wrote:
Python doesn't expose raw AES, etc. But it does expose a fairly rich TLS
library.
If you're not comfortable using the Python cryptography hazmat module,
check out pycryptodome.
Melinda
--
Melinda Shore
melinda.sh...@nomountain.net
Software longa
On 3/9/18 12:57 PM, Kathleen Moriarty wrote:
> The hummed answer to that question was very close to 50/50 in the
> room, inconclusive.
From the perspective of consensus decision-making that's
actually very clear - there's no consensus. What that
means in practice depends on the question that was
On 3/13/18 8:09 AM, nalini elkins wrote:
> I agree that the room hummed to "continue the discussion".
This might be a good time to review RFC 7282 ("On Consensus
and Humming in the IETF") so that everybody is more-or-less
on the same page with respect to what a roughly 50/50 split
hum means.
Meli
On 3/13/18 6:48 AM, Jim Reid wrote:
> Stephen, the opposite PoV is equally valid. There was no consensus in
> Prague NOT to work on the topic. The mood of the room was evenly
> divided.
To clarify, this isn't voting. If there's no agreement in
either direction there's no agreement (and I hope the
On 3/13/18 10:44 AM, Kathleen Moriarty wrote:
> And then there are other options too, like another WG. Even from
> Stephen's list of who is in agreement with him, I've received a few
> messages saying their text wasn't what he thinks it was. More
> discussion here would be good to figure out a wa
On 4/4/18 2:53 PM, Richard Barnes wrote:
> I support publication of the document as is. I would also be
> comfortable with a minor modification to say that TLSA certificate
> usages 0 and 1 (the restrictive ones) MUST NOT be used with this mechanism.
The addition of text that clarifies that seems
On 4/10/18 3:53 PM, Nico Williams wrote:
> The earlier consensus is not just applicable, as if it were, we would
> not be having this LC.
I have no idea what that even means, to be honest. We're through
last call, and it's not that the earlier wg consensus isn't
"applicable," it's that you've rai
On 4/12/18 9:54 AM, Benjamin Kaduk wrote:
> I'm waiting to see if anything else comes out of this thread.
> In particular, I am hoping that some authors/proponents of leaving the
> document in the RFC Editor queue would speak to the question of the
> target scope, given the arguments that have been
On 4/12/18 1:47 PM, Martin Thomson wrote:
> If this is indeed about adding [goo], what prevents Viktor or Paul
> from proposing a new addition to the protocol in the form of a new I-D
> that enacts the changes they wish to see?
Clearly nothing, and I think this would be a reasonable way forward.
On 4/12/18 6:55 PM, Viktor Dukhovni wrote:
> If you'd like me to craft revised option (A) text, that includes a suitable
> caveat, I can try.
I'm okay with putting denial-of-existence in there as a should,
but I do feel strongly that pinning belongs in a separate document.
As I said earlier, I
On 4/18/18 10:22 AM, Joseph Salowey wrote:
> Concerns have been raised about the trade-offs associated with pinning
> and I do not think we currently have consensus to add pinning. While I
> think it may be possible to come to consensus on pinning I think it may
> take some time. I believe we can
On 4/25/18 7:33 AM, Viktor Dukhovni wrote:
> Perhaps a concrete proposal will make it
> easier to reach a mutually-agreeable consensus position, and make it
> clear that the requested 16-bits are a reasonable consensus outcome.
Hi, Viktor:
This doesn't actually reflect the consensus called by the
We've had this discussion already, at terrific length.
To my knowledge it's still the case that nobody intends
to implement the proposed changes, and it's still the
case that should there be interest in implementing the
new functionality there's the option of a new extension.
At any rate this is
On 5/15/18 8:22 PM, Viktor Dukhovni wrote:
> It just leaves
> the door open going forward, at negligible cost (two bytes on the
> wire in bandwidth, and zero in implementation).
I would be grateful if you would have a consistent story on this.
Clearly, it's not just two bytes, or there wouldn't be
We really need to get this published, and in the interest of
making progress I will not block the addition of two bytes
to the extension. I am highly reassured by Viktor's suggestion
that they will never be used, as unused fields with murky
semantics have never been shown to be a problem in IETF
p
On 5/16/18 2:20 PM, James Cloos wrote:
> The sixteen bit field harms no one, and when defined and used provides
> significant benefit to many.
It is one of the peculiarities of the IETF (and engineers
in general, I guess) that when we sit down to design a
protocol most people will start talking ab
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
On 7/4/18 6:33 PM, Viktor Dukhovni wrote:
> I thought the authors wanted this done quickly, but lately they
> seem to be in no rush to get the document finished.
I'm still trying to figure out a way forward that's useful
for the people who intend to use this extension and that doesn't
add cruft o
On 8/8/18 9:07 PM, Subodh Iyengar wrote:
> So far we've been doing interop with Cloudflare's OID of
> 1.3.6.1.4.1.44363.44. I'd be fine with putting that as the final OID
> the draft. Does anyone have any thoughts on whether we should / should
> not do this and use a different OID instead.
One th
On 12/5/18 7:27 AM, Salz, Rich wrote:
> That’s not the way it works. When deciding whether or not to adopt
> something as a WG item, unless there is consensus to DO it, then the
> consensus is DO NOT do it. There is no tie. A decision was made, and
> by not adopting this work, the WG decided to
On 3/22/19 7:28 AM, Wang Haiguang wrote:
> [HG] Regarding the revocation, we did not mention it in the draft, but
> we have
>
> considered it in the design. In practice, an
>
> expiring time can be included in the identity for the IBC system.
>
> In fact, in RFC 6507 page 7-8, authors have menti
On 3/24/19 4:16 AM, Wang Haiguang wrote:
> We do plan to include an expire date in the identity design. The
> valid period is a decision that should be decide either by the user
> or the PKG manager.
The problem here is that you do not want to get into the
position of allowing a known compromised
lease say so by
> 2359UTC on 22 April 2019 (and say why).
I support adoption.
Melinda
--
Melinda Shore
melinda.sh...@nomountain.net
Software longa, hardware brevis
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
ess to the token ("all
technical problems can be solved by introducing a layer of
indirection").
Melinda
--
Melinda Shore
melinda.sh...@nomountain.net
Software longa, hardware brevis
signature.asc
Description: OpenPGP digital signature
_
I share the more broadly-stated concern that this draft
introduces terminology and architectural framings that
don't match how things work either in practice or in
existing documents. I understand that the authors are
looking for a tool to get a better handle on the protocol,
but if there's a nee
On 9/28/16 3:08 PM, Bill Frantz wrote:
> On 9/28/16 at 2:01 AM, m...@sap.com wrote:
>> I'm sorry, but I'm still violently opposed to the IETF endorsing
>> backdooring of security protocols.
> I find myself in violent agreement with Martin, and many others in the
> IETF.
This seems uncontroversial
On 9/28/16 4:36 PM, Tony Arcieri wrote:
> The IETF is doing great work. This entire thread is a distraction, and I
> hope it does not result in changes which weaken TLS 1.3's security.
I think it's quite clearly the case that that is not going to happen.
But, that doesn't mean that these guys don'
On 11/18/16 2:18 PM, Martin Thomson wrote:
> In the end, it's just a label.
Well, there are some semantics to it - I think a label
can be more than just a label.
It occurred to me that it's guaranteed that if it's
rebranded as TLS 4 we'll have people showing up with
internet drafts proposing TLS
On 3/21/17 4:20 PM, Eric Rescorla wrote:
> SUBSTANTIVE
>
>Servers receiving a "dnssec_chain" extension in the client hello, and
>which are capable of being authenticated via DANE, SHOULD return a
>serialized authentication chain in the Certificate message, using the
>format describ
Thanks - I've updated those, as well.
Our sense right now is that the pieces that need completion
prior to going to working group last call are to add
some pseudocode to clarify construction of the chain, and
test vectors. The draft could definitely benefit from
additional review.
Thanks,
Melin
Thanks for the thorough review, Viktor. I'll get the straightforward
bits into the draft over the weekend and plan on discussing the ones
proposing changes to the extension or to chain construction and
processing in the working group session.
Melinda
signature.asc
Description: OpenPGP digital
On 3/23/17 8:14 AM, Viktor Dukhovni wrote:
> I don't know how many other folks on the TLS WG list are prepared
> to do a thorough review the DNSSEC aspects of this draft...
> Perhaps the TLS and DNS communities overlap sufficiently that my
> concern is not warranted?
I think it's quite warranted,
On 4/12/17 11:31 AM, Sean Turner wrote:
> At our IETF 98 session, there was support in the room to adopt
> draft-rescorla-tls-subcerts [0]. We need to confirm this support on
> the list so please let the list know whether you support adoption of
> the draft and are willing to review/comment on the
On 4/24/17 7:39 AM, Hannes Tschofenig wrote:
>> There is enormous amount of red tape obtaining intermediates, even
>> technically constrained ones. And as consequence, it is enormously
>> expensive (through not nearly as expensive as public CA).
> In essence you are doing this through the extension
Thanks for the careful review, Ilari. It's a long weekend in the US
but we'll get some proposed text out mid-to-late this week.
Melinda
signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailma
On 7/14/17 6:45 PM, Yoav Nir wrote:
>> On 14 Jul 2017, at 18:35, Joseph Lorenzo Hall wrote:
>> Just want to +1 the notion that this should be opt-in for both sides and in
>> an extension!
> It’s a good notion, but “we have to change one side” usually wins over “we
> have to change both sides”
S
On 7/15/17 4:01 PM, Sean Turner wrote:
> draft-ietf-tls-dnssec-chain-extension is getting moved back to Monday
> because that’s the only time Melinda can make.
No, I'm afraid that I *cannot* make it Monday, and need to have
our slot stay on Wednesday.
Melinda
signature.asc
Description: OpenPGP
On 7/16/17 7:55 AM, Salz, Rich wrote:
> I am not offended. I am saying that if it terminates the connection it
> is an endpoint not a middlebox.
Well, maybe. That's certainly the general understanding of middleboxes
(i.e that they they are not directly addressed [well, NATs, but] and
that they d
On 7/17/17 1:23 AM, Daniel Kahn Gillmor wrote:
> Could you point me (and the list) to those requirements, please? More
> specificity than "some countries" would be a useful contribution to this
> discussion.
At the time when I was working on VoIP there were a few countries,
such as South Africa,
On 11/2/17 8:40 AM, Salz, Rich wrote:
>> Due to some unforeseen circumstances neither author of
>> draft-rhrd-tls-tls13-visibility is able to attend IETF 100. As a
>> result, they’ve withdrawn their request for agenda time.
> I think it would still be worthwhile to have time for the WG to see
> i
On 11/5/17 7:14 AM, Ted Lemon wrote:
> My point here is that that's not the reason to reject the document.
> The reason in this case is that there already exist better ways to solve
> the problem, and the proposal would clearly make TLS 1.3 worse, even
> though there is disagreement about how /mu
46 matches
Mail list logo
